2012年5月18日金曜日

Oracle DB 移行作業おける事前検討1

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

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

 以下、自分のメモ用に何点かポイントを書いておく。(私の意見も入っています。)
 ※1.以下、文章が長くなるので、特定の理由がない限り
   アップグレードや移行を同義語として、移行とする。
 ※2.移行≒アップグレードを含む移行として記載している。

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

今回はテスト計画とネットワークへの考慮について

1)テスト
 ・移行テスト(リハーサル)
  -手順通り問題なく実施できるか
  -所要時間

  大事ですよね。
  手順に漏れがないか、所要時間を計測して計画停止時間の見積もりや
  移行手順の再検討を行う。
  あと、手順と計画停止時間に関連して、
  切り戻し判定ポイントや切り戻し条件や
  切り戻し手順を移行計画手順書に忘れずに含めることが必要。

 ・移行後の環境でのパフォーマンステスト
   -移行前環境とのパフォーマンス比較
   -レスポンス要件やスループット要件を満たせているか、
    バッチがタイムスケジュール内に終了するか

   新しいOS、マシン、バージョンに移行して遅くなるケースはほとんどないと思うが、
   DB統合などで、複数のDBが1DBサーバ上or RAC上に相乗りするという場合は、
   パフォーマンステストの分析により、
   OSやOracleのパラメータの調整やSQLの実行計画の固定化、
   リソース制御などのチューニング、
   今後ボトルネックとなる箇所の想定などが必要。
   ファイルのレイアウト調整やRAID調整をその時点でやるとしたら、
   設計そのもののミスかしら。。
   ハードリソースの追加は避けたいところ。

   言うまでもないが、移行前の環境でパフォーマンス・データを取得しておかないと
   比較できない。また、移行の計画段階から移行先でどのようなパフォーマンステストを
   どのような手段で実施するのかなどを検討しておく必要がある。
   例)どの時点で?どのようなデータで?どのようなツールで?どのような処理を?

   ※パフォーマンス・データの取得方法はSTATSPACKやAWR、
       サードベンダツールやOSSツールでの取得なんでもいい。


 2)ネットワーク環境の考慮
  物理的な限界は超えられない。


ネットワークインターフェースデータボリューム最大転送速度
100Mbit Ethernet11MB/sec40GB/hour(best case approach)
1Gbit Ethernet110MB/sec400GB/hour(best case approach)
10Gbit Ethernet1.1GB/sec4TB/hour(best case approach)
InfiniBand 4X QDR4GB/sec(theoretical)
3GB/sec(realistic)
10.8TB/hour

・プロトコル転送
 -ftp,scp,NFSのパラレルコピーを検討
・ネットワーク機器やセキュリティ設定による制限
・外部ネットワークプロバイダによる制限と距離的な制限

2012年5月14日月曜日

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

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

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

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



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


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


1)INVALIDオブジェクトへの対応
  1-1)INVALIDオブジェクトのチェック
     SQL> select 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> select  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> select 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になったか
  判断できなくて混乱するよね。


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



2012年5月13日日曜日

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

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

個人的にはセミナーによって、当たり外れの落差が激しいと感じているのだけど、
昨日は当たりだった。ありがとうございました。

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


以下、自分のメモ用に何点かポイントを書いておく。

1.パッチセットのロードマップ
Release Schedule of Current Database Releases [ID 742060.1]
-Release 10.1 to 11.2までのPatch Set Release(PSR)のリリース日やら
   サポート予定が書いてある。
予定だと11.2.0.4.0は来年かぁ。。


2.アップグレード手引書
11.1.0.X(11gR1)
Oracle 11gR1 Upgrade Companion [ID 601807.1]
Oracle Database 11gR1 Upgrade Companion - 目次[KROWN#134166]

11.2.0.X(11gR2)
Oracle 11gR2 Upgrade Companion [ID 785351.1]
Oracle Database 11gR2 Upgrade Companion - 目次[KROWN#141177]

-KROWNめちゃめちゃ分かりやすい。
移行方法別のメリットとデメリットも載ってる。
3.のマニュアルと共に移行の話が上がった際に事前に目を通して
おくべき資料だ。


3.アップグレードマニュアル
Oracle Databaseアップグレード・ガイド11g リリース2(11.2)

   -やっぱりチェックしとかないとね。


4.その他の重要なノート
Complete Checklist for Manual Upgrades to 11gR2 [ID 837570.1]
Complete checklist for manual upgrades of Oracle databases
  from any version to any version on any platform (documents only from 
  7.3.x>>8.0.x>>8.1.x>>9.0.x>>9.2.x>>10.1.x>>10.2.x>>11.1.x>>11.2.x) [ID 421191.1]

-2.よりも、もっと実際的な手順や内容が多い。
移行にくらべ、同一筐体内でのアップグレード案件はあまりないような気がするが、
事前・事後の内容はお作法としても知っておきたい。


5.OTNのOracle Database Upgrade
-中段には今回のセミナー資料の元資料のダウンロードページに行けます。
560ページのPDF資料って、、、


バージョンアップや移行(バージョンアップを含む)のどちらも、
バージョンが変わることによる仕様や動作の変更点や、
バージョンアップ後のリリースのバグ等を押えておくべきなのは変わらない。
移行の場合には、さらに移行方法の検討というタスクが重要。


上の資料だけど、
時間がない場合は、上記資料2のKROWNと4の内容の事前事後の作業部分を
さらさら読むのがいいだろう。

時間があって本腰を入れて取り組む人は、5から入るのが良いと思う。


言うまでもないけど、1,2,4の資料は保守契約がないと読めないのでご注意を。


次回以降もこのセミナーネタをメモメモしていく予定。
※いずれ、セミナー資料自体が公開されると思いますが。