はじめに
最近、パッチ適用について調査しているので、その一環としてこちらにも情報をまとめてみようと思いました。
(パッチ適用入門のお話は、パッチ適用って何？何をするの？の記事もご覧ください！
)
例えば、Patch Post-Installation (datapatch)もユーザが接続した状態でもパッチ適用なのか？ という疑問です。
なかなか情報として落ちていないのでまとめてみました。
本記事は、基本的に以下のブログを参考にし、都度情報を他のソースからも取り入れています。
[Blog] Can I Run Datapatch When Users Are Connected
1. そもそもdatapatchとは？
以下のドキュメントをまとめると、、、
Datapatch：OpatchでOracle Homeへのバイナリ変更した後、DB再起動後に SQL (データディクショナリ) を更新します
※RAC環境の場合、datapatchは1つのノードのみ実行
※全てのDBが新規パッチが適用済みのOracle Home上にある必要あり
変更/更新箇所
- 新規テーブルの作成
- 既存のテーブルの変更
- ビューの作成または変更
- DBMS_STATSのようなPL/SQLパッケージの再作成
datapatch 適用順序
- Java パッチ
- バンドル・パッチ
- 個別パッチ
更に詳しい情報は、以下のドキュメントをご覧ください。
2. では、Opatchとは？
ここでは、詳しくは触れませんが、「Oracle適用の個別パッチインストーラ」です。
DBが停止しているときに、Oracle Homeにパッチをインストールし、新規バイナリを適用します。
また、RAC構成だった場合、以下の３パターンのパッチ適用方法があります。
※対象適用パッチのReadmeに、どのパターンが適用可能かの記載があります。
- シングルインスタンスとしてパッチ適用(All-Node Patch)
- ダウンタイムを最小にするパッチ適用 (Minimum downtime)
- ローリングパッチ適用 - ダウンタイムなし (Rolling Patch)
更に詳しい情報は、以下のドキュメントをご覧ください。
- Oracle Data Server Interim Patch Installation (OPatch) (Doc ID 189489.1)
- ローリングパッチ - RAC のOPatchサポート (Doc ID 244241.1)
3. さて、本題のPatch Post-Installation (datapatch)もユーザが接続した状態でもパッチ適用なのか？
YES！
First, let me state that it is fully supported to run Datapatch on a running database with users connected.
和訳：「ユーザーが接続されている実行中のデータベースでDatapatchを実行することは完全にサポートされています。」
[Blog] Can I Run Datapatch When Users Are Connected
4. では、どのタイミングでユーザ接続が可能になるのか？
以下を参考にすると、
新規Oracle Homeをインストールし、OPatchを使用して必要なパッチを適用する際に、DBをシャットダウンしていますが、
その後、パッチを適用した新規Oracle HomeでDBを再起動した後から、ユーザーによるデータベースへの接続が許可されるようです。
- Install a new Oracle Home and use OPatch to apply the desired patches.
- Shut down the database.
- Restart the database in the new, patched Oracle Home.
- Downtime is over! Users are allowed to connect to the database
- Execute ./datapatch -verbose.
- End of procedure. The patch is now fully applied.
[Blog] Can I Run Datapatch When Users Are Connected
5. 他の製品と組合わせている場合のパッチ適用方法
RAC、Data Guard、GoldenGateを利用している場合で、以下にまとめてみました。
5-1. RAC を使っている場合は？
2章で少し登場した ローリングパッチ適用 を利用することが可能です。(readmeに使用許可がある場合)
→ ダウンタイムが発生しません。バイナリ適用後、どれか一つのnodeでdatapatchを適用。
※全てのデータベースまたはインスタンスのOracle Homeのバージョンが揃うまで、Datapatch を実行しないでください。
5-2. Data Guard を使っている場合は？
Standby-First Patch適用 を利用することが可能です。
→ 先にスタンバイ側DBにバイナリを適用後、プライマリ側DBにバイナリを適用。
その後、プライマリDBでパッチ適用をする。(RAC構成の場合は、5章と同様にどれか一つのnodeでdatapatchを適用)
※全てのデータベースまたはインスタンスのOracle Homeのバージョンが揃うまで、Datapatch を実行しないでください。
Oracle Patch Assurance - Data Guardスタンバイ・ファースト・パッチ適用 (Doc ID 1265700.1)
5-3. GoldenGate を使っている場合は？
datapatchを実行する際は、Oracle GoldenGateを停止する必要があります。
datapatch終了後、Oracle GoldenGateを再起動することができます。
6. datapatchを遅くする設定
少し路線が変わりますが、datapatchの検証をする場合、本番環境にどこまで合わせればいいのか？ 、気にしないといけない設定はあるか？ についてです。
もしかしたら、調べ切れていないだけで以下の他にも要因があるかもしれません。
6-1. Multitenant環境で、CDB$ROOTとPDBに異なるコンポーネントが存在する場合
上記の場合、本番環境のコンポーネントを検証環境も合わせた方が正確なdatapatchの時間が検証できそうです。
というのも、仮にパラレル化でパッチ適用を検討していた場合、そのコンポーネントの差異でパラレル化が選択されるかどうか、内部処理の判断にも影響が出てくるという記事でした。
[Blog] PDBに異なるコンポーネントがある場合、datapatchはどのような処理をするか？
6-2. 統合監査・従来の監査(標準監査)の両方がON設定になっている場合
上記の場合、ある顧客事例では、19.17.0 へのパッチ適用に 7 時間かかったことが以下のブログに記載ありました。
【解決策】以下の引用通り、従来の監査をOFF。その後、DB再起動。
→ 統合監査のみであれば、datapatchは通常の時間枠内で収まるそうです。
Turn off traditional auditing by setting AUDIT_TRAIL=NONE. Unfortunately, as explained above already, this requires a restart of the database. But after it got disabled, datapatch completed within the expected normal time frame.
[Blog] 従来の監査と統合監査がオンになっていると、データパッチが遅くなる場合がある
7. 注意・推奨事項
- OPatch：常に最新のを使用する
・最新バージョンの OPatch をダウンロードおよびインストールする方法 (Doc ID 274526.1)
・OPatch - OPatch(6880880) の最新バージョンはどこにありますか？(Doc ID 224346.1) - Datapatch：常に-verboseフラグを付けて実行。これにより、現状を知るための情報を得ることが可能。
- 消費リソース：Datapatch が必要とする変更は、リソースを大量に消費するものではない
- タイミング：オフピーク時にパッチ適用をする
- パッチ適用手順とダウンタイムを開始する前に、無効なオブジェクトを再コンパイルすることを推奨
まとめ
今回は、自分が知りたかった軸をもとに、有識者さんのブログを参考に情報整理していくことが中心でしたが、
知れば知るほど、分からないことが増えていく。。。そんな感覚に陥っていました
まだまだ、まとめきれていないところもあるので、更新する中で改善していくか、別の記事で書いていこうかなと思っております。