Veritas InfoScale™ 8.0 Oracle データベース用ストレージと可用性管理 - AIX, Linux, Solaris
- 第 I 部 Oracle データベース用 SFHA (Storage Foundation High Availability) 管理ソリューション
- Storage Foundation for Databases の概要
- Oracle 用 Storage Foundation High Availability(SFHA)Solutions の概要
- Veritas File System について
- Veritas Volume Manager の概要
- DMP (Dynamic Multi-Pathing) について
- Cluster Server について
- Cluster Server のエージェントについて
- Veritas InfoScale Operations Manager について
- Veritas InfoScale 8.0 製品の Oracle サポート機能
- Veritas InfoScale 製品の使用例
- Storage Foundation for Databases の概要
- 第 II 部 Veritas InfoScale 製品を使用した Oracle の配備
- Storage Foundation 環境への Oracle オプションの配備
- Storage Foundation 環境の Oracle の配備オプション
- Storage Foundation 環境での Oracle 単一インスタンス
- Storage Foundation 環境でオフホストを使う単一インスタンスの Oracle
- Storage Foundation High Availability を用いた高可用性クラスタの単一インスタンス Oracle
- SF Cluster File System HA 環境の並列クラスタの Oracle の単一インスタンス
- Storage Foundation for Oracle RAC 環境の Oracle RAC について
- レプリケーションされた Storage Foundation 環境での Oracle について
- 仮想化環境での Oracle と Storage Foundation の配備
- Storage Foundation SmartMove およびシンプロビジョニングによる Oracle の配備
- Storage Foundation を使用した Oracle の配備
- Storage Foundation を使用したオフホスト設定での Oracle の配備
- High Availability を使用した Oracle の配備
- ディザスタリカバリ用 VVR (Volume Replicator) を使用した Oracle の配備
- Storage Foundation 環境への Oracle オプションの配備
- 第 III 部 Storage Foundation for Databases (SFDB) ツールの設定
- Storage Foundation for Databases リポジトリデータベースの設定および管理
- SFDB (Storage Foundation for Databases)リポジトリについて
- Storage Foundation for Databases (SFDB) ツールの必要条件
- SFDB(Storage Foundation for Database)ツールの可用性
- Storage Foundation for Databases (SFDB) リポジトリの設定
- Storage Foundation for Databases(SFDB)リポジトリのバックアップと復元
- ノード追加後の SFDB(Storage Foundation for Databases)リポジトリの更新
- ノード削除後の SFDB(Storage Foundation for Databases)リポジトリの更新
- SFDB (Storage Foundation for Databases) リポジトリの削除
- Storage Foundation for Databases (SFDB) ツールの認証の設定
- Storage Foundation for Databases リポジトリデータベースの設定および管理
- 第 IV 部 Oracle データベースのパフォーマンスの向上
- データベースアクセラレータについて
- Veritas Extension for Oracle Disk Manager によるデータベースパフォーマンスの向上
- Veritas Cached Oracle Disk Manager によるデータベースパフォーマンスの向上
- SFHA 環境の Cached ODM について
- SFHA 環境の Cached ODM の設定
- SFHA 環境の Cached ODM Advisor による Cached ODM 設定の管理
- SFHA 環境の Cached ODM Advisor を使用した候補データファイルのレポートの生成
- SFHA 環境の Cached ODM Advisor を使用したデータファイルの Cached ODM の有効化/無効化
- SFHA 環境の Cached ODM Advisor を使用したデータベースファイルの Cached ODM 状態の表示
- SFHA 環境の Cached ODM Advisor を使用した Cached ODM 統計情報の表示
- SFHA 環境の Cached ODM Advisor を使用した ODM I/O 統計情報の表示
- Quick I/O によるデータベースパフォーマンスの向上
- Quick I/O について
- qiomkfile による Quick I/O ファイルとしての Oracle データベースファイルの作成
- setext コマンドによる Quick I/O ファイル領域の事前割り当て
- 通常の VxFS ファイルへの Quick I/O ファイルとしてのアクセス
- Oracle ファイルの Quick I/O ファイルへの変換
- スパースファイルについて
- Oracle データベースにおける一時表領域と Quick I/O の扱い
- Quick I/O の状態とファイル属性の表示
- Quick I/O ファイルの拡張
- Quick I/O ファイルでの Oracle AUTOEXTEND の使用
- データベースのリストア後の Quick I/O ファイルの再作成
- Quick I/O の無効化
- Solaris ローカルゾーンへの Quick I/O ファイルの作成
- Cached Quick I/O によるデータベースパフォーマンスの向上
- 第 V 部 PITC (Point-In-Time Copy) の使用
- PITC 方法の理解
- PITC(Point-In-Time Copy)の概要
- ポイントインタイムコピーを使う状況
- Storage Foundation PITC テクノロジについて
- SFDB ツールによってサポートされている PITC ソリューション
- Storage Foundation for Databases (SFDB) ツールのサポート対象スナップショットモードについて
- ボリュームレベルのスナップショット
- ボリュームレベルのスナップショット(FlashSnap)の逆再同期について
- Storage Checkpoint
- FileSnap について
- Oracle PITC に関する注意事項
- サードミラーブレークオフスナップショットの管理
- 領域最適化スナップショットの管理
- Storage Checkpoint の管理
- Storage Checkpoint について
- リカバリのための Database Storage Checkpoint
- Database Storage Checkpoint の作成
- Database Storage Checkpoint の削除
- Database Storage Checkpoint のマウント
- Database Storage Checkpoint のマウント解除
- Database Storage Checkpoint を使ったデータベースのクローンの作成
- Database Storage Checkpoint からのリストア
- オフラインモード Storage Checkpoint のデータの収集
- FileSnap スナップショットの管理
- SFHA 環境での NetBackup によるバックアップとリストア
- PITC 方法の理解
- 第 VI 部 Oracle に対するストレージコストの最適化
- SmartTier によるストレージの階層化について
- SmartTier の設定と管理
- Oracle での SmartTier のユースケース
- ストレージコストを最適化するためのファイルとデータベースの圧縮
- 圧縮アドバイザツールの使用
- 第 VII 部 Oracle ディザスタリカバリの管理
- 第 VIII 部 Storage Foundation for Databases 管理リファレンス
- Storage Foundation for Databases コマンドリファレンス
- Storage Foundation for Databases のチューニング
- SFDB ツールのトラブルシューティング
- Oracle データベースの手動によるリカバリ
- 6.0 より前のリリースの Storage Foundation for Databases のコマンドリファレンス
- SFDB コマンドの後方互換について
- サポート対象外となった Storage Foundation for Databases(SFDB)ツールの機能
- Database FlashSnap のストレージの準備
- データベーススナップショットの作成について
- FlashSnap コマンド
- Oracle リカバリのガイドライン
- Database Storage Checkpoint のコマンド
- dbed_update を使ったリポジトリの作成または更新
- dbed_ckptcreate を使った Storage Checkpoint の作成
- dbed_ckptdisplay を使った Storage Checkpoint の表示
- dbed_ckptmount を使った Storage Checkpoint のマウント
- dbed_ckptumount を使った Storage Checkpoint のマウント解除
- dbed_ckptrollback を使った Storage Rollback の実行
- dbed_ckptremove を使った Storage Checkpoint の削除
- dbed_clonedb を使った Oracle インスタンスのクローン作成
- 第 IX 部 参照先
アーカイブログと Flashback ログの再配置のスケジュール
アーカイブログは、データの破損状態からリカバリを実行する主要な機構となっているため、通常、データベースログは高い I/O 処理速度と高いデータ信頼性を持つ高価なストレージに保持されます。 アーカイブログの容量が限界に達した場合でさえ、ログは、通常、高速リカバリを目的にオンラインを維持しますが、それも時間が経過すると、このログへの参照はきわめて少なくなる可能性があります。 これは、一定期間参照がなければ、アーカイブ化されたデータベースログを低コストのボリュームに再配置できることを意味します。
同様に、Storage Foundation の Flashback 技術によって、ログが作成されます。このログは、データベースを以前の状態にリストアすることでデータベースの破損からすばやくリカバリするときに使うことができます。 Flashback ログは通常、アーカイブ化されたデータベースログよりも短い期間、維持されます。このログは、使われる場合でも、通常作成されてから数時間の間でしか使われません。 一般的な Flashback ログの存続期間は 2、3 日です。
アーカイブログと Flashback ログの使用率の急速な低下は、一定期間参照がないログを定期的に低コストのストレージへ再配置するという配置ポリシーを実施することによって、オンラインストレージの平均コストを削減できることを意味しています。
たとえば、非常に多くのアクティブセッションで大規模な OLTP Oracle データベースを継続して使っているものとします。このとき、このデータベースは、稼動率 99 % 超の状態で 24 時間体制の稼動が必要とされています。 データベースは、偶発的なエラーをすばやく訂正するために Flashback 技術を使っています。このデータベースでは 1 日に大量のアーカイブログが生成されます。 データベースが何らかの理由で停止した場合、業務上、15 分以内にデータベースをオンラインに戻し、機能を復旧させるという必要条件が発生します。 トランザクション時の Oracle ログの切り替え遅延を防止するために、アーカイブログは高速な EMC アレイに作成する必要があります。 1 週間を超える古いアーカイブログは、ミッドレンジの Clarion アレイに移動できます。15 日を超える古いアーカイブログは、低速の JBOD ディスクに移動できます。アーカイブログは、30 日後にパージされます。現在の Flashback ログはデータベース管理者によって手動で高速な EMC ストレージに作成されており、2 日後に Clarion ストレージに移動できます。データベース管理者は、1 週間後その Flashback ログを削除します。このようにシステムを設定するには、次の例を参照してください。アーカイブログと Flashback ログは同じファイルシステム /oralog 上に作成されることを前提としています。ファイルシステム上の /oralog/archive1 にアーカイブログが作成され、/oralog/flashback に Flashback ログが作成されます。
図: アーカイブログと Flashback ログの自動再配置に適したデータベースストレージ設定 は、アーカイブログと Flashback ログの自動再配置と削除に適した 3 層のボリューム設定を表しています。
この例で実稼動データベースで使われているファイルシステムは、最初は単一ボリューム oralog に存在し、ボリュームとそのボリュームに割り当てられた配置クラスを追加することによって準備する必要があります。
NEW、MEDIUM、OLD のストレージクラスを追加するには
- 次のように、dbdst_admin コマンドを使います。
$ /opt/VRTS/bin/dbdst_admin -S PROD -o addclass=\ NEW:"EMC Storage for Production DB"
$ /opt/VRTS/bin/dbdst_admin -S PROD -o addclass=\ MEDIUM:"Clarion Storage for Production DB"
$ /opt/VRTS/bin/dbdst_admin -S PROD -o addclass=\ OLD:"JBOD Storage for Production DB"
データベースのファイルシステムを変換し、SmartTier for Oracle で使うボリュームを追加するには
- 次のように、dbdst_convert コマンドを使います。
$ /opt/VRTS/bin/dbdst_convert -S PROD \ -M /dev/vx/dsk/oradg/oralog -v emc_v1,clarion_v1,jbod_v1
ボリュームをストレージクラスに分類するには
- 次のように、dbdst_classify コマンドを使います。
$ /opt/VRTS/bin/dbdst_classify -S PROD \ -M /dev/vx/dsk/oradg/oralog -v emc_v1:NEW
$ /opt/VRTS/bin/dbdst_classify -S PROD \ -M /dev/vx/dsk/oradg/oralog -v clarion_v1:MEDIUM
$ /opt/VRTS/bin/dbdst_classify -S PROD \ -M /dev/vx/dsk/oradg/oralog -v jbod_v1:OLD
ボリュームの設定が行われると、管理者は、選択したファイルをアクセスの時系列順に再配置してデータベースのファイルシステムに割り当てるようにファイル配置ポリシーのルールを定義できます。
Flashback ログとアーカイブログを定期的に再配置するルールを定義するには
- 次のように、dbdst_file_move コマンドを使います。
$ /opt/VRTS/bin/dbdst_file_move -S PROD -o flashback -c MEDIUM:2
このコマンドによって、2 日間アクセスされなかった Flashback ディレクトリ内のファイルは、MEDIUM ボリュームに再配置されます。
$ /opt/VRTS/bin/dbdst_file_move -S PROD -o archive1 -c MEDIUM:7 \ -c OLD:15
このコマンドの実行により、7 日間アクセスがなかった archive1 ディレクトリのファイルは MEDIUM ボリュームに再配置され、15 日間アクセスがなかったファイルは、OLD ボリュームに再配置されます。
SmartTier for Oracle では、これらのコマンドを SmartTier アクセスを時系列順に並べたポリシールールに変換してファイルシステムの配置ポリシーで結合するとともに、変換後のポリシーをそのファイルシステムに割り当てます。 デフォルトでは、SmartTier for Oracle で、アクティブポリシーが日単位で施行されます。ポリシーの施行中は、ポリシーの作成に使う dbdst_file_move コマンドで指定したストレージ階層に、新しいルールで対象のファイルが再配置されます。