home

หน้าแรก
 Computer >> บทช่วยสอนคอมพิวเตอร์ >  >> การเขียนโปรแกรม >> ฐานข้อมูล

Checklist สำคัญสำหรับการ Deploy Oracle CPU Patch

บล็อกนี้ทบทวนความสำคัญของการรัน ADOP (Application DBA Online Patching Utility) Cycle ด้วย fs_clone หลังจากมีการเปลี่ยนแปลงหรือ Technology Patches ใดๆ ถูกทำไปที่ Weblogic Server (WLS) หรือ Oracle® Fusion Middleware (FMW) Home Directories บน Patch File System ของคุณ บล็อกนี้สำรวจ Problem Scenario และอธิบายวิธีจัดการปัญหาที่เกี่ยวข้องอย่างง่ายดาย

Phases ของ ADOP Cycle

ภาพต่อไปนี้แสดง Phases ของ ADOP Cycle:

Checklist สำคัญสำหรับการ Deploy Oracle CPU Patch

Image Source: https://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531065.htm

Problem History

หลังจาก Apply Critical Path Update (CPU) Patches ไปที่ Oracle Version R12.2 Instance บน Patch File System ADOP ทำ Full Cycle Run เสร็จ (Prepare, Apply, Finalize, Cutover และ Cleanup) หลังจากรัน ADOP Cycle อีกครั้งสำหรับกิจกรรมอื่น Instance ถูก Clone ไป Server อื่น

อย่างไรก็ตาม เมื่อ Apply WLS Patches บน Cloned Environment ใหม่ ระบบเจอ Conflict Patch ชี้ไปที่ Version Mismatch ของ WLS

Analysis

การวิจัยแสดงว่า CPU Patches ที่ Apply ไปที่ WLS และ FMW Web Tier และ Oracle Common Home Directories ก่อนหน้านี้ ไม่ได้ถูกรวมอยู่ใน Run และ Patch File System ในการตรวจสอบเพิ่มเติมใน ADOP Logfiles เราสังเกตว่า Prepare File Synchronized File System แต่เราไม่เห็นการเปลี่ยนแปลงที่ทำไปที่ Directories Oracle_home และ FMW_home ระหว่าง Patching Cycle

Deduction:

จากการวิเคราะห์ของเรา เราดึงข้อสรุปดังนี้:

  1. File Synchronization ใน Prepare Phase มีเพียงสำหรับ APPL_TOP เท่านั้น

    Log Files ที่เราทบทวนแสดง Propagating File System Changes จาก Run APPL_TOP ไป Patch APPL_TOP

  2. หลังจาก Weblogic Patches ถูก Apply fs_clone ไม่ได้ถูก Run ก่อนเริ่ม ADOP Cycle ถัดไป ดังนั้น Patches ใหม่จึงไม่ปรากฏใน Successive Run แม้หลังจาก ADOP Cycle ที่สองเสร็จสิ้น และไม่พร้อมใช้งานใน Cloned Instance

Recommendation

ใน Prepare Phase Patch File System ปกติจะ Synchronized กับ Run File System โดยการสร้าง Database Edition ใหม่ นี่คือ Default Incremental Synchronization ของ Files ที่เปลี่ยนแปลงบน Application Top

เพื่อ Synchronize Applied Patches ให้ Invoke txkADOPPreparePhaseSynchronize.pl ไปที่ $APPL_TOP ของ Run File System จาก Patching Cycle ล่าสุด หรือ Invoke fs_clone ในกรณีนี้ เราไม่เรียก fs_clone จริง แทนที่จะเป็นเช่นนั้น เราเรียก FsCloneStage และ FsCloneApply สำหรับ $APPL_TOP ซึ่งเป็น Very Unsynchronized

File System Synchronization Method ถูกเลือกอัตโนมัติตาม Configuration Change Detector (adConfigChangeDetector.pl -detectConfigChanges)

File Synchronization Methods ที่แตกต่างกันรวมถึง Options ต่อไปนี้:

Option 1 – ระบุ Patches จาก Database ที่ Apply ใน ADOP ล่าสุด Merge และ Apply แบบ Silent กระบวนการนี้ใช้เวลาน้อยกว่าเพราะระบบ Apply เฉพาะ Unapplied Patches

Option 2 – Recreate หรือ Reclone Run File System $APPL_TOP ไป Patch File System $APPL_TOP นี้ Extremely Unsynchronized และ Consume Resources มากกว่า

Option 3 – ใช้ Third-party Software ที่คุณเลือก (เช่น rsync) เพื่อ Synchronize File System

Parameters ที่ส่งมาด้วย Prepare

Prepare ใช้ Parameters ต่อไปนี้:

a) ใช้ Option Skipsyncerror ใน ADOP Prepare Phase เพื่อ Ignore Errors และ Warnings เป็น Workaround สำหรับ Synchronization Errors และ Failures ซึ่งอาจเกิดขึ้นหาก Patch Application Failed ใน Patching Cycle ก่อนหน้า Default Value คือ NO

Syntax: adop phase=prepare skipsyncerror=yes

b) ใช้ Option sync_mode เพื่อระบุ Method ที่ใช้ Sync Patch File System กับ Run File System

Syntax: adop phase=prepare sync_mode=(delta|patch)

sync_mode patch – Reapplies Patches ที่ Apply ไปที่ Run File System แล้ว (Default Mode) sync_mode delta – Copy ทุก Customizations และ File Changes โหมดนี้ใช้ Synchronization Command จาก File delta_sync_drv.txt และเป็น Feature ใหม่จาก AD-TXK delta 8

ADOP fs_clone Command

คำสั่ง fs_clone Recreate หรือ Reclone Entire Patch File System รวมถึงการตั้งค่า Configurations และ Customizations ทั้งหมดบน Patch File System ในลักษณะเดียวกับ Run File System การทำอย่างนี้ Resource Intensive เท่ากับการ Full Backup ของ Run File System แล้วสร้าง Patch File System

fs_clone มี Commands ที่มีประโยชน์ดังนี้:

  • adop phase=fs_clone force=yes - Restart Failed Clone จากต้นทาง (Default=NO)

  • adop phase=fs_clone s_fs_backup_count=1 - ตั้งค่าจำนวน Backups ของ Patch File System ที่จะ Preserve ก่อนที่จะ Recreate จาก Run File System (Default=0 ไม่มี Backups ถูกเก็บ)

Key Takeaways

แม้ Prepare Phase จะรันต้นทุก Patching Cycle Technology Stack Patches (ที่ Apply ด้วย Utility opatch/Smart update) ไม่ได้ Synced ใน Prepare Stage

Prepare ไม่ Synchronize การเปลี่ยนแปลงที่ทำด้วยตนเอง เช่น:

  • Compiling User-defined JSPs
  • Copying Third Party Libraries
  • Copying และ Compiling User-defined Concurrent Programs
  • Copying และ Generating User-defined Forms

คุณต้องเพิ่ม Custom Patching Actions (เช่นที่อธิบายก่อนหน้า) ใน Custom Synchronization Driver adop_sync.drv ใน Prepare Phase

ใน File adop_sync.drv มี Categories ของ Commands ดังนี้:

  • Run One Time Only
  • Run At Each File System Synchronization

เพื่อ Copy Customizations และ File Changes ใน Prepare Phase ใช้คำสั่งต่อไปนี้:

ADOP phase=prepare sync_mode=(delta|patch)

หาก Patches ใด Aborted หรือ Maintenance หรือ Release Update Pack (RUP) Patches ถูก Apply fs_clone ต้องรันที่สิ้นสุดเพื่อ Recreate Patch File System ให้เป็น Exact Copy ของ Run File System

สรุป

ทุกครั้งที่มีการเปลี่ยนแปลงไปที่ Weblogic Server หรือ Fusion Middleware Components ของ E-Business Suite Release 12.2 จำเป็นอย่างยิ่งที่ Database Administrators ต้องรัน fs_clone เพื่อให้แน่ใจว่า Patch File System ถูก Update ด้วยการเปลี่ยนแปลงล่าสุดทั้งหมดที่ทำไปที่ WLS หรือ FMW ของ Run File System

ใช้แท็บ Feedback เพื่อแสดงความคิดเห็นหรือถามคำถาม

เรียนรู้เพิ่มเติมเกี่ยวกับบริการฐานข้อมูลของเรา