Blog này xem xét tầm quan trọng của việc chạy chu kỳ ADOP (Application DBA Online Patching Utility) với fs_clone sau khi bất kỳ thay đổi hoặc patch công nghệ nào được thực hiện trên thư mục Weblogic Server (WLS) hoặc Oracle® Fusion Middleware (FMW) home trên patch file system của bạn. Blog khám phá tình huống vấn đề và giải thích cách xử lý các vấn đề liên quan dễ dàng.
Các giai đoạn chu kỳ ADOP (The ADOP cycle phases)
Hình sau hiển thị các giai đoạn của chu kỳ ADOP:
Nguồn ảnh: https://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531065.htm
Lịch sử vấn đề (Problem history)
Sau khi áp dụng Critical Path Update (CPU) patches cho instance Oracle phiên bản R12.2 trên patch file system, ADOP hoàn thành chu kỳ chạy đầy đủ (prepare, apply, finalize, cutover, và cleanup). Sau khi chạy chu kỳ ADOP khác cho hoạt động khác, instance được clone sang server khác.
Tuy nhiên, khi áp dụng WLS patches trên môi trường clone mới, hệ thống gặp xung đột. Patch trỏ đến sự không khớp phiên bản WLS.
Phân tích (Analysis)
Nghiên cứu cho thấy CPU patches trước đó áp dụng cho WLS và FMW Web Tier và Oracle common home directories không được bao gồm trong run và patch file system. Khi điều tra sâu hơn vào ADOP logfiles, chúng tôi nhận thấy file prepare đồng bộ hóa file system, tuy nhiên chúng tôi không thấy các thay đổi được thực hiện trên thư mục Oracle_home và FMW_home trong chu kỳ patching.
Kết luận (Deduction)
Từ phân tích của chúng tôi, chúng tôi rút ra các kết luận sau:
Đồng bộ hóa file trong giai đoạn prepare chỉ dành cho APPL_TOP.
Các file log chúng tôi xem xét chỉ ra việc lan truyền thay đổi file system từ run APPL_TOP sang patch APPL_TOP.
Sau khi Weblogic patches được áp dụng,
fs_clonekhông được chạy trước khi khởi động chu kỳ ADOP tiếp theo. Do đó, các patch mới không xuất hiện trong run tiếp theo ngay cả sau khi chu kỳ ADOP thứ hai hoàn thành, và không có sẵn trong instance clone.
Khuyến nghị (Recommendation)
Trong giai đoạn prepare, patch file system thường được đồng bộ với run file system bằng cách tạo database edition mới. Đây là đồng bộ hóa tăng dần mặc định của các file bị thay đổi trên application top.
Để đồng bộ hóa các patch đã áp dụng, gọi txkADOPPreparePhaseSynchronize.pl tới $APPL_TOP của run file system từ chu kỳ patching cuối hoặc gọi fs_clone. Trong trường hợp này, chúng ta không gọi fs_clone thực tế. Thay vào đó, chúng ta gọi FsCloneStage và FsCloneApply cho $APPL_TOP, rất không đồng bộ.
Phương pháp đồng bộ hóa file system được chọn tự động dựa trên Configuration Change Detector (adConfigChangeDetector.pl -detectConfigChanges).
Các phương pháp đồng bộ hóa file system khác nhau bao gồm các tùy chọn sau:
Tùy chọn 1 – xác định patch từ database được áp dụng trong ADOP cuối. Merge và áp dụng chúng im lặng. Quy trình này tốn ít thời gian vì hệ thống chỉ áp dụng các patch chưa áp dụng.
Tùy chọn 2 – Tạo lại hoặc clone lại run file system $APPL_TOP sang patch file system $APPL_TOP. Đây là cực kỳ không đồng bộ và tiêu tốn nhiều tài nguyên.
Tùy chọn 3 – Dùng phần mềm thứ ba bạn chọn (như rsync) để đồng bộ file system.
Tham số truyền với prepare (Parameters passed with prepare)
Prepare dùng các tham số sau:
a) Dùng tùy chọn Skipsyncerror trong giai đoạn ADOP prepare để bỏ qua lỗi và cảnh báo như giải pháp thay thế cho lỗi và thất bại đồng bộ, có thể xảy ra nếu áp dụng patch thất bại trong chu kỳ patching trước. Giá trị mặc định là NO.
cú pháp: adop phase=prepare skipsyncerror=yes
b) Dùng tùy chọn sync_mode để chỉ định phương pháp đồng bộ patch file system với run file system.
cú pháp: adop phase=prepare sync_mode=(delta|patch)
sync_mode patch – Áp dụng lại patch đã áp dụng cho run file system (chế độ mặc định). sync_mode delta – Sao chép tất cả tùy chỉnh và thay đổi file. Chế độ này dùng lệnh đồng bộ từ file delta_sync_drv.txt và là tính năng mới từ AD-TXK delta 8.
Lệnh ADOP fs_clone (ADOP fs_clone command)
Lệnh fs_clone tạo lại hoặc clone lại toàn bộ patch file system bao gồm thiết lập tất cả cấu hình và tùy chỉnh trên patch file system theo cách giống như run file system. Việc này tốn tài nguyên ngang ngửa với việc backup đầy đủ run file system rồi tạo patch file system.
fs_clone có các lệnh hữu ích sau:
adop phase=fs_clone force=yes- Khởi động lại clone thất bại từ đầu (mặc định=NO).adop phase=fs_clone s_fs_backup_count=1- Đặt số lượng backup của patch file system được bảo toàn trước khi nó được tạo lại từ run file system (mặc định=0 không backup).
Các điểm chính (Key takeaways)
Mặc dù giai đoạn prepare chạy ở đầu mọi chu kỳ patching, các technology stack patches (được áp dụng bởi tiện ích opatch/Smart update) không được đồng bộ trong giai đoạn prepare.
Prepare không đồng bộ bất kỳ thay đổi thủ công nào như:
- Compile user-defined JSPs.
- Sao chép thư viện bên thứ ba.
- Sao chép và compile user-defined concurrent programs.
- Sao chép và generate user-defined forms.
Bạn phải thêm các custom patching actions (như đã mô tả trước) vào custom synchronization driver, adop_sync.drv, trong giai đoạn prepare.
Trong file adop_sync.drv, các loại lệnh sau tồn tại:
- Chạy một lần duy nhất
- Chạy ở mỗi lần đồng bộ file system
Để sao chép tùy chỉnh và thay đổi file trong giai đoạn prepare, dùng lệnh sau:
ADOP phase=prepare sync_mode=(delta|patch)
Nếu bất kỳ patch nào bị abort hoặc bất kỳ bảo trì hoặc Release Update Pack (RUP) patches nào được áp dụng, fs_clone phải chạy ở cuối để tạo lại patch file system thành bản sao chính xác của run file system.
Kết luận
Bất cứ khi nào có thay đổi đối với Weblogic Server hoặc thành phần Fusion Middleware của E-Business Suite Release 12.2, quản trị viên database bắt buộc phải chạy fs_clone để đảm bảo patch file system được cập nhật với tất cả thay đổi mới nhất được thực hiện trên WLS hoặc FMW của run file system.
Sử dụng tab Feedback để bình luận hoặc đặt câu hỏi.
Tìm hiểu thêm về dịch vụ cơ sở dữ liệu của chúng tôi.