2019年12月04日

[JPOUG Advent Calendar] Oracle on Hyper-V 2019

charade_oo4oと申します。今年は「JPOUG Advent Calendar 2019」へ参加致します。

 <2019年>

Oracleは今後数年間の安定版というべき19cがリリースされました。
RATでも新機能追加があるので、19c導入時に評価する予定です。

個人的には、今年はRATと奮闘しました。
AP側にテストの負担を掛けず、DB側のみで変更前後の検証が出来るので、利用出来るなら利用する価値はある機能です。
RATが無ければ、有意義なテストが出来ずに時間だけ浪費して、障害が発覚するのは本番導入後、という事も充分あり得ます。

今回は、11gR2→12cR2バージョン間移行、12cR2パッチ適用、初期化パラメータ変更の検証で使用しました。
事前学習で、Hyper-Vを活用しました。

 <RATで見るべき資料>

1つだけあげるなら下記の資料が判り易い思います。
https://www.oracle.com/technetwork/jp/ondemand/20130228-rat-2199823-ja.pdf

RATの機能概要、導入意義、注意点について一通り記載されています。
問題発生時に、資料を見直して解決した事もありました。

 <RAT キャプチャー/リプレイ方法>

RATのキャプチャーは、ディスク消費量以外には大きな影響はありませんでした。
その為、本番環境の業務スキーマを、月末月初の数日間毎月キャプチャーしています。
expdp、SPAのPL/SQL、DB ReplayのPL/SQLを呼び出すシェルスクリプトをスケジュール実行します。

リプレイは開発環境のRAT用PDBで実行します。
impdp、SPAのPL/SQLをキャプチャーの後続ジョブとして実行します。
他の開発システムが接続不能となる程の高負荷を掛けてしまったDB Replayは個別実行としました。

リプレイした開発環境はキャプチャーした本番環境より少な目のリソース割当でした。
バージョン間の差異、パッチ適用の差異より、環境差異の影響の方が大きかったです。

rat_flow.png

 <RAT CDB注意点>

CDB環境ではRATの接続先に注意する必要があります。
SPAではPDBに対してキャプチャー/リプレイ可能です。
18cまでのDB Replayでは、PDBでのキャプチャー/リプレイは実行出来ず、CDB$ROOTでキャプチャー/リプレイする必要があります。
DB Replayで異なる業務PDBを個別にキャプチャー/リプレイする場合、互いが重ならない様にスケジュール調整する必要があります。

rat_cdb.png

19cから、DB ReplayでもPDBでのキャプチャー/リプレイが可能となった様です。
更にDBA_RAT_CAPTURE_SCHEMA_INFOでキャプチャー時のスキーマ情報が確認出来るようになった様です。
12cR2では差異が出たSQL_IDは判りましたが、どのPDB・スキーマで実行されたのか判らず、 同時キャプチャーしていたSTSから検索するか、SQL内のオブジェクト名から類推していました。
DB Replayも業務AP検証用途で使い易くなる様に改良されている様です。

 <SPA キャプチャー注意点>

SPAではいくつかのSTSのキャプチャー方法があります。
RAC環境の為、DB Replayのstart_captureではcapture_sts=>trueを設定出来ませんでした。
今回はキャプチャー期間中、シェルスクリプトから数分毎にDBMS_SQLTUNE.SELECT_CURSOR_CACHEと DBMS_SQLTUNE.LOAD_SQLSETを呼び出しました。

定期的なキャプチャーを1つのプロシージャで実現するDBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET もありますが、問題がありました。
Unix/Linuxプラットフォームでは実行したPL/SQLを止められません。
呼出元のSQL*PlusのセッションをALTER SYSTEM KILL SESSIONしてもPL/SQLは動き続けます。
何かあった時に止められない。下りの峠道でブレーキが効かなくなった車並に危険です。

plsql_running.png

 <DB Replay 開始注意点>

DB Replayキャプチャー前のデータ取得にはexpdpを使用しました。
トランザクションが全く流れていない時にキャプチャー開始できれば良いのですが、expdp開始とstart_capture開始の時間差、 In-Frightトランザクションが原因で、リプレイ時に件数差異やエラーが発生してしまいました。
結局、DB Replayでの件数差異検出は諦めました。

dbr_start.png

18cから、SPAでもCOMPARE_RESULTSETで結果セット差異が検出可能となった様です。
但し、DB Replayと同様の理由で使用出来ない可能性もあるかも知れません。

 <DB Replay 終了注意点>

検証時、キャプチャーしたはずのSQLが正常にリプレイされない、という問題が発生しました。
問題切り分けの為、キャプチャー期間中にSQL*PlusからDMLを順次投入したのですが、リプレイ時にDMLが途中までしか実行されませんで した。

dbr_finish.png

原因は 20130228-rat-2199823-ja.pdf の「キャプチャ・ファイルに書き出される条件」を見直して判明しました。
仕様上、finish_capture実行後に何も操作していないと、ファイル出力されない場合があります。
クラサバの画面系APは、コネクション確立したまま放置される事も多いので要注意です。

 <RAT レポート注意点>

SPAもDB Replayも、結構な数の誤検出が発生します。
データ移行にData Pumpを使用した為、ROWID不一致によるエラーは除外しました。
モジュール名がData PumpやSQL Developer等の業務AP以外の場合も除外しました。
統計情報取得、動的統計等のシステム発行SQLも除外しました。

ある程度除外した後、RATでエラーや速度低下が検出されたSQLを開発環境で実行して、再現するか確認しました。
再現しなければ、次回以降は除外対象となります。
再現したエラーや速度低下に対して、対策案を検討しました。

誤検出があるという事は、検出漏れもあり得ます。
例えば、データ変動の多いテーブルが空の状態で取得された統計情報による不適切な実行計画、多重処理やロック待ちによる速度低下等は、 静止状態のデータに対してSQLを単独実行するSPAでは再現出来ません。

 <最後に>

RATを運用して躓いた点をピックアップしました。
環境によってはRAT in Cloudも有効かも知れません。
RATも万能ではありませんが、全SQLを調査するより、ある程度絞り込めた方が効率的です。
多少なりともRAT導入の参考になれば幸いです。


posted by charade at 00:00| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。