บล็อกนี้ทบทวนความสำคัญของการเรียกใช้วงจร ADOP (Application DBA OnlinePatching Utility) ด้วย fs_clone
หลังจากการเปลี่ยนแปลงหรือแพตช์เทคโนโลยีที่ทำกับโฮมไดเร็กทอรี Weblogic Server (WLS) หรือ Oracle® Fusion Middleware (FMW) บนระบบไฟล์แพตช์ของคุณ บล็อกสำรวจสถานการณ์ปัญหาและอธิบายวิธีจัดการกับปัญหาที่เกี่ยวข้องอย่างง่ายดาย
ระยะของวงจร ADOP
รูปภาพต่อไปนี้แสดงเฟสของวงจร ADOP:
ที่มาของรูปภาพ:https://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531065.htm
ประวัติปัญหา
หลังจากใช้แพตช์ Critical Path Update (CPU) กับอินสแตนซ์ Oracle เวอร์ชัน R12.2 บนระบบไฟล์แพตช์แล้ว ADOP ได้ดำเนินการรอบการทำงานแบบเต็ม (เตรียม ใช้ จบการทำงาน ตัดและล้างข้อมูล) หลังจากเรียกใช้รอบ ADOP อื่นสำหรับกิจกรรมที่แตกต่างกัน อินสแตนซ์จะถูกโคลนไปยังเซิร์ฟเวอร์อื่น
อย่างไรก็ตาม เมื่อใช้แพตช์ WLS ในสภาพแวดล้อมที่โคลนใหม่ ระบบพบข้อขัดแย้ง แพตช์ชี้ไปที่เวอร์ชันที่ไม่ตรงกันของ WLS
การวิเคราะห์
การวิจัยพบว่าแพตช์ CPU ที่ใช้ก่อนหน้านี้กับ WLS และ FMW Web Tier และโฮมไดเร็กทอรีทั่วไปของ Oracle ไม่รวมอยู่ในระบบไฟล์รันและแพตช์ ในการตรวจสอบเพิ่มเติมเกี่ยวกับไฟล์บันทึก ADOP เราสังเกตเห็นว่าเตรียมไฟล์ซิงโครไนซ์กับระบบไฟล์ แต่เราทำไม่ได้ ดูการเปลี่ยนแปลงที่ทำกับOracle_home และ FMW_home ไดเร็กทอรีระหว่างรอบการแพตช์
การหัก:
จากการวิเคราะห์ของเรา เราได้ข้อสรุปดังต่อไปนี้:
-
การซิงโครไนซ์ไฟล์ในขั้นตอนการเตรียมมีไว้สำหรับ APPL_TOP . เท่านั้น .
ไฟล์บันทึกที่เราตรวจสอบพบว่ามีการเผยแพร่การเปลี่ยนแปลงระบบไฟล์จากการเรียกใช้APPL_TOP เพื่อแก้ไข APPL_TOP .
-
หลังจากใช้แพตช์ Weblogic แล้ว
fs_clone
ไม่ทำงานก่อนที่จะเริ่มรอบ ADOP ถัดไป ดังนั้น แพตช์ใหม่จะไม่ปรากฏในการรันต่อเนื่องแม้หลังจากรอบ ADOP ที่สองเสร็จสิ้น และไม่พร้อมใช้งานในอินสแตนซ์ที่ลอกแบบมา
คำแนะนำ
ในขั้นตอนการเตรียม ระบบไฟล์แพตช์มักจะซิงโครไนซ์กับระบบรันไฟล์โดยการสร้างเอดิชันฐานข้อมูลใหม่ นี่คือการซิงโครไนซ์ที่เพิ่มขึ้นตามค่าเริ่มต้นของไฟล์ที่มีการเปลี่ยนแปลงที่ด้านบนของแอปพลิเคชัน
ในการซิงโครไนซ์แพตช์ที่ใช้ ให้เรียกใช้ txkADOPPreparePhaseSynchronize.pl
ไปที่ $APPL_TOP ของการรันระบบไฟล์จากรอบการแพตช์ที่แล้วหรือเรียกใช้fs_clone
. ในกรณีนี้ เราไม่เรียก fs_clone
ที่แท้จริง . แต่เราเรียกFsCloneStage
และ FsCloneApply
สำหรับ $APPL_TOP ซึ่งไม่มีการซิงโครไนซ์มาก
วิธีการซิงโครไนซ์ระบบไฟล์จะถูกเลือกโดยอัตโนมัติตามตัวตรวจจับการเปลี่ยนแปลงการกำหนดค่า (adConfigChangeDetector.pl -detectConfigChanges
)
วิธีการซิงโครไนซ์ไฟล์ต่างๆ ประกอบด้วยตัวเลือกต่อไปนี้:
ตัวเลือกที่ 1 – ระบุแพตช์จากฐานข้อมูลที่ถูกนำไปใช้ใน ADOP ล่าสุด ผสานและใช้สิ่งเหล่านี้อย่างเงียบ ๆ กระบวนการนี้ใช้เวลาน้อยลงเพราะระบบใช้เฉพาะแพตช์ที่ไม่ได้ใช้
ตัวเลือก 2 – สร้างหรือเรียกคืนระบบไฟล์ที่รัน $APPL_TOP ไปยังระบบไฟล์แพตช์ $APPL_TOP . สิ่งนี้ไม่มีการซิงโครไนซ์อย่างมากและใช้ทรัพยากรมากกว่า
ตัวเลือก 3 – ใช้ซอฟต์แวร์บุคคลที่สามที่คุณเลือก (เช่น rsync
) เพื่อซิงโครไนซ์ระบบไฟล์
ส่งพารามิเตอร์พร้อมการเตรียมตัว
Prepare
ใช้พารามิเตอร์ต่อไปนี้:
ก) ใช้ Skipsyncerror
ตัวเลือกในขั้นตอนการเตรียม ADOP เพื่อละเว้นข้อผิดพลาดและคำเตือนเป็นวิธีแก้ปัญหาสำหรับข้อผิดพลาดและความล้มเหลวในการซิงโครไนซ์ ซึ่งอาจเกิดขึ้นได้หากโปรแกรมแก้ไขล้มเหลวในรอบการแพตช์ก่อนหน้า ค่าเริ่มต้นคือ ไม่ .
ไวยากรณ์: adop phase=prepare skipsyncerror=yes
b) ใช้ sync_mode
ตัวเลือกเพื่อระบุวิธีที่จะใช้ซิงค์ระบบไฟล์แพตช์กับระบบไฟล์ที่รัน
ไวยากรณ์: adop phase=prepare sync_mode=(delta|patch)
sync_mode patch
– ใช้แพตช์ที่เคยใช้กับระบบ runfile แล้ว (โหมดเริ่มต้น) อีกครั้งsync_mode delta
– คัดลอกการปรับแต่งและการเปลี่ยนแปลงไฟล์ทั้งหมด โหมดนี้ใช้คำสั่งการซิงโครไนซ์จากไฟล์ delta_sync_drv.txt และเป็นคุณลักษณะใหม่จาก AD-TXK delta 8
.
คำสั่ง ADOP fs_clone
fs_clone
คำสั่งสร้างใหม่หรือเรียกคืนระบบไฟล์แพตช์ทั้งหมดรวมถึงการตั้งค่าคอนฟิกูเรชันและการปรับแต่งทั้งหมดบนระบบไฟล์แพตช์ในลักษณะเดียวกับระบบไฟล์ที่รัน การทำเช่นนี้จะใช้ทรัพยากรมากเท่ากับการสำรองข้อมูลเต็มรูปแบบของระบบไฟล์ที่รัน จากนั้นจึงสร้างระบบไฟล์ apatch
fs_clone
มีคำสั่งที่มีประโยชน์ดังต่อไปนี้:
-
adop phase=fs_clone force=yes
- รีสตาร์ทโคลนที่ล้มเหลวตั้งแต่เริ่มต้น (default=NO) -
adop phase=fs_clone s_fs_backup_count=1
- ตั้งค่าจำนวนการสำรองของระบบไฟล์ thepatch ที่จะรักษาไว้ก่อนที่จะสามารถสร้างใหม่ได้จากระบบ runfile (ค่าเริ่มต้น =0 ไม่มีการสำรองข้อมูล)
ประเด็นสำคัญ
แม้ว่าระยะเตรียมการจะทำงานเมื่อเริ่มต้นรอบการแพตช์ทุกรอบ แพตช์เทคโนโลยีสแต็ก (ใช้โดย opatch/Smart update
ยูทิลิตี้) จะไม่ซิงค์ในขั้นตอนการเตรียม
การจัดเตรียมไม่ซิงโครไนซ์การเปลี่ยนแปลงใดๆ ที่ทำด้วยตนเอง เช่น:
- การรวบรวม JSP ที่ผู้ใช้กำหนด
- คัดลอกไลบรารีของบุคคลที่สาม
- การคัดลอกและคอมไพล์โปรแกรมพร้อมกันที่กำหนดโดยผู้ใช้
- การคัดลอกและสร้างแบบฟอร์มที่ผู้ใช้กำหนด
คุณต้องเพิ่มการดำเนินการแก้ไขแบบกำหนดเอง (เช่นที่อธิบายไว้ก่อนหน้านี้) ในไดรเวอร์การซิงโครไนซ์แบบกำหนดเอง adop_sync.drv
, อยู่ในช่วงเตรียมการ
ในไฟล์ adop_sync.drv
, มีประเภทของคำสั่งดังต่อไปนี้:
- เรียกใช้เพียงครั้งเดียวเท่านั้น
- ทำงานที่การซิงโครไนซ์ระบบไฟล์แต่ละครั้ง
ในการคัดลอกการปรับแต่งและการเปลี่ยนแปลงไฟล์ในขั้นตอนการเตรียม ให้ใช้คำสั่งต่อไปนี้:
ADOP phase=prepare sync_mode=(delta|patch)
หากมีการยกเลิกแพตช์หรือแพตช์การบำรุงรักษาหรือ Release Update Pack (RUP) ใด ๆ fs_clone
ต้องเรียกใช้ในตอนท้ายเพื่อสร้างระบบ patchfile ใหม่เป็นสำเนาที่ถูกต้องของระบบไฟล์ที่รัน
บทสรุป
เมื่อใดก็ตามที่มีการเปลี่ยนแปลงใดๆ กับ Weblogic Server หรือส่วนประกอบ Fusion Middleware ของ E-Business Suite รีลีส 12.2 ผู้ดูแลระบบฐานข้อมูลจะต้องเรียกใช้ fs_clone
เพื่อให้แน่ใจว่าระบบไฟล์แพตช์ได้รับการอัปเดตด้วยการเปลี่ยนแปลงล่าสุดทั้งหมดที่ดำเนินการกับ WLS หรือ FMW ของระบบไฟล์ที่รัน
ใช้แท็บคำติชมเพื่อแสดงความคิดเห็นหรือถามคำถาม
เรียนรู้เพิ่มเติมเกี่ยวกับบริการฐานข้อมูลของเรา