Oracle DB アップグレードや移行作業前のお作法

先日、日本オラクル社の無償セミナーである
 「秘訣を直伝！最新オラクルデータベースへのアップ グレードテクニック」を受講してきた。

 アップグレードや移行に関するチップス・見ておくべき情報、
 手法についてのケーススタディが詰め込まれており、かなり有益だった。

　以下、自分のメモ用に何点かポイントを書いておく。
　※1.以下、文章が長くなるので、特定の理由がない限り
　　　アップグレードや移行を同義語として、移行とする。
　※2.移行≒アップグレードを含む移行として記載している。
　※3.以下、SQL文は環境によっては少なくない負荷を掛ける可能性があるので、
　　　実行タイミングは考えましょう。



　　前回：OralceDB移行・アップグレード前に見ておきたい資料


■サニティ・オペレーション
　　ここで言うサニティ・オペレーションとは、
　　簡単に言うと、移行作業前に移行元の環境を整理・綺麗にしておこうね。
　　この作業は、すべてのアップグレードや移行作業にも有効。


１)INVALIDオブジェクトへの対応
　　1-1)INVALIDオブジェクトのチェック
　　　　　SQL> ｓelect unique OBJECT_NAME,OBJECT_TYPE,
　　　　　　　　　OWNER from DBA_OBJECTS where STATUS='INVALID';

　1-2)移行作業前にすべてのINVALIDオブジェクトを修正
　　　　と資料にはあるが、1-1)の結果を精査して不要なものは削除、
　　　　必要なものは、原因を調査してVALIDにいう感じが妥当かな。
　　　　そもそも、運用中にINVALIDになっているなら削除していんじゃない？
　　　　という考え方はありだと思う。

　1-3)SYSやSYSTEMスキーマのINVALIDオブジェクトをなくす。
　　　　移行作業前にutlrp.sqlでINVALIDオブジェクトを再コンパイルする。
　　　　うーん、1-2)の対応としてもutlrp.sqlは有益かも。

　　　　※utlrp.sqlは$ORACLE_HOME/rdbms/admin/utlrp.sql　SYSで実行。


2)SYS/SYSTEMの重複オブジェクトの対応
　　普通はこんなことはないだろうけど、
　　パッチ適用後の流し忘れや、特定コンポーネント使用時の流し忘れ、
　　実行ユーザ間違いとかで発生する。

　2-1)SYS/SYSTEMの重複オブジェクトをチェック
　　　　SQL> ｓelect  OBJECT_NAME,OBJECT_TYPE　from
　　　　　　　　DBA_OBJECTS where OBJECT_NAME||OBJECT_TYPE
　　　　　　　　in (select OBJECT_NAME||OBJECT_TYPE from DBA_OBJECTS
　　　　　　　　where OWNER='SYS') and OWNER='SYSTEM' and
　　　　　　　　OBJECT_NAME not in ('AQ$_SCHEDULES_PRIMARY',
　　　　　　　　'AQ$_SCHEDULES','DBMS_REPCAT_AUTH');

　2-2)SYS/SYSTEMの重複オブジェクトの修正
　　　　基本は、2-1)で出力されたオブジェクトのSYSTEM側のものを
　　　　削除(drop)するようですが、HELP～というオブジェクトのみはSYSTEM側を残す模様。

　　　　・How to Clean Up Duplicate Objects Owned by SYS and SYSTEM Schema [ID 1030426.6]
　　　　　も合わせて参照とのこと。※大体同じことしか書いてない。


3)INVALIDなコンポーネントの対応
　3-1)INVALIDオブジェクトのチェック
　　　　SQL> ｓelect substr(COMP_ID, 1, 10) compid,
　　　　　　　　substr(COMP_NAME,,24) compname, STATUS,VERSION
　　　　　　　　from DBA_REGISTRY where STATUS != 'INVALID';

　3-2)移行作業前に全てのVALIDではないオブジェクトを修正
　　　　と資料にはあるが、3-1)の結果を精査して不要なものは削除、
　　　　必要なものは、原因を調査してVALIDにいう感じが妥当かな。
　　　　そもそも、運用中にINVALIDになっているなら削除していんじゃない？
　　　　という考え方はありだと思う。

　3-3)utlrp.sqlで再コンパイルしても、ステータスが修正されない場合
　　　　以下の内容により追加の診断が必要

　　　・Information On Installed Database Components and Schemas [ID 472937.1]
　　　　 -各コンポーネントの説明や参考noteが示されており、とても便利。
　　　・How To Diagnose Components With NON VALID Status In DBA_REGISTRY 
　　　　After an Upgrade [ID 753041.1]


4)ゴミ箱を空っぽに
　　10g以降のバージョンからの移行である場合は移行元にてrecyclebinをパージする。
　　SQL> purge DBA_RECYCLEBIN;


5)古いパラメータや隠しパラメータ、イベントパラメータの設定解除
　　アップグレード時間が49分⇒7分になった事例もあるとのこと。


　　-----

　　以上だけど、基本は不要なものやゴミを綺麗にしておきましょうってことですね。
　　アップグレード時や移行時のコンパイル対象や移行対象が減るだけでも、
　　処理時間は短くなるだろうし。
　　そもそも、INVALIDなオブジェクトを事前にチェックしておかないと、
　　アップグレードや移行後に作業によりオブジェクトがINVALIDになったか
　　判断できなくて混乱するよね。


　　一手間の事前準備で作業時間の短縮や作業失敗のリスクを低減出来るなら、
　　是非実施しておきたい作業ですね。