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のパラレルコピーを検討
・ネットワーク機器やセキュリティ設定による制限
・外部ネットワークプロバイダによる制限と距離的な制限

0 件のコメント:

コメントを投稿