Oracle® Database

高可用性ベスト・プラクティス

11gリリース2(11.2)

B65088-05(原本部品番号:E10803-06)

2014年6月

Oracle Database高可用性ベスト・プラクティス 11g リリース2 (11.2)

B65088-05

Copyright © 2005, 2014, Oracle and/or its affiliates.All rights reserved.

原本著者: Lawrence To, Viv Schupmann, Thomas Van Raalte, Virginia Beecher

原本協力者: Janet Stern

原本協力者: Andrew Babb、Janet Blowney、Larry Carpenter、Timothy Chien、Jay Davison、Senad Dizdar、Ray Dutcher、Mahesh Girkar、Stephan Haisley、Wei Ming Hu、Holger Kalinowski、Nitin Karkhanis、Frank Kobylanski、Rene Kundersma、Joydip Kundu、Barb Lundhild、Roderick Manalac、Pat McElroy、Robert McGuirk、Joe Meeks、Markus Michalewicz、Valarie Moore、Michael Nowak、David Parker、Darryl Presley、Hector Pujol、Michael T.Smith、Vinay Srihari、Mark Townsend、Douglas Utzig、Thomas Van Raalte、James Viscusi、Vern Wagman、Steve Wertheimer、Shari Yamaguchi

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、他社の商標の可能性があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 高可用性ベスト・プラクティスの概要

- 1.1 Oracleデータベースの高可用性アーキテクチャ

- 1.2 Oracleデータベースの高可用性ベスト・プラクティス

- 1.3 Oracle Maximum Availability Architecture

2 可用性を最大化するための運用前提条件

- 2.1 可用性およびパフォーマンスのSLAの理解

- 2.2 高可用性環境の実装

- 2.3 パフォーマンスおよび可用性のSLAの検証

- 2.4 セキュリティ・ベスト・プラクティスの設定および使用

- 2.5 変更管理手順の確立

- 2.6 推奨パッチおよびソフトウェアのテストと適用の計画の提供

- 2.7 適切なテストおよびパッチ適用作業の使用

- 2.7.1 テスト・システムおよびQA環境の構成

- 2.7.2 本番前の検証手順の実行

- 2.8 Data Guardのロール移行の実行

- 2.9 エスカレーション管理手順の確立

- 2.10 高可用性のための監視およびサービス要求インフラストラクチャの構成

- 2.10.1 高可用性のための監視インフラストラクチャの構成

- 2.10.2 サービス要求インフラストラクチャの構成

- 2.11 最新のMAAベスト・プラクティスの確認

3 構成ベスト・プラクティスの概要

4 ストレージの構成

- 4.1 データベース・パフォーマンス要件とストレージ容量要件の評価

- 4.2 自動ストレージ管理(Oracle ASM)を使用したデータベース・ファイルの管理

- 4.2.1 クラスタOracle ASMを使用したストレージ・グリッドの有効化

- 4.2.2 Oracle ASMインスタンス(クラスタ化されていないOracleデータベース)に対するOracle Restartの使用

- 4.3 Oracle ASMの戦略的ベスト・プラクティス

- 4.3.1 ディスクおよびディスク・グループの簡易構成の使用

- 4.3.2 冗長性を使用したディスク障害からの保護

- 4.3.2.1 RAIDに基づくストレージ・アレイ

- 4.3.2.2 Oracle ASMの冗長性

- 4.3.3 Grid InfrastructureホームのOracle ASM

- 4.3.4 同一ディスク・グループ内のディスクへの同じ特性の割当て

- 4.3.5 Oracle ASMの冗長性を使用する際の障害グループの使用

- 4.3.6 インテリジェント・データ配置の使用

- 4.3.7 Oracle ACFSを使用したデータベース外部のファイルの管理

- 4.4 Oracle ASMの構成ベスト・プラクティス

- 4.4.1 ディスクのマルチパス・ソフトウェアを使用したパス障害からの保護

- 4.4.2 SGA_TARGETおよびPGA_AGGREGATE_TARGETパラメータを使用した自動共有メモリー管理の使用

- 4.4.3 PROCESSES初期化パラメータの設定

- 4.4.4 ディスク・ラベルの使用

- 4.4.5 DISK_REPAIR_TIMEディスク・グループ属性の適切な設定

- 4.4.6 ASMLibのサポート対象プラットフォームでの使用

- 4.5 Oracle ASMの運用ベスト・プラクティス

- 4.5.1 Oracle ASM認証でのSYSASMの使用

- 4.5.2 サービス・レベルに影響しない最大限のリバランスの設定

- 4.5.3 単一のコマンドを使用した複数のディスク・グループのマウント

- 4.5.4 単一のコマンドを使用したストレージの追加または削除

- 4.5.5 ディスク・グループの不均衡のチェック

- 4.5.6 ディスク・エラーに備えたベンダー・ログの予防的なマイニング

- 4.5.7 ASMCMDユーティリティを使用したOracle ASMの管理性の簡略化

- 4.5.8 Oracle ASMコンフィギュレーション・アシスタント(ASMCA)の使用

- 4.6 Oracleストレージ・グリッドの使用

- 4.6.1 計画外の停止に関するOracleストレージ・グリッドのベスト・プラクティス

- 4.6.2 計画済のメンテナンスに関するOracleストレージ・グリッドのベスト・プラクティス

5 Oracle Databaseの構成

- 5.1 データベース構成の高可用性および高速リカバリのベスト・プラクティス

- 5.1.1 データベースのARCHIVELOGモードおよびFORCE LOGGINGモードの設定

- 5.1.2 REDOログ・ファイルおよびグループの適切なサイズ構成

- 5.1.3 高速リカバリ領域の使用

- 5.1.4 フラッシュバック・データベースの有効化

- 5.1.5 FAST START MTTR TARGET初期化パラメータの設定

- 5.1.6 データ破損の防止

- 5.1.6.1 データ破損の拡大の防止

- 5.1.6.2 データ破損の検出および監視

- 5.1.7 DISK_ASYNCH_IO初期化パラメータの設定

- 5.1.8 LOG_BUFFER初期化パラメータを8MB以上に設定

- 5.1.9 自動共有メモリー管理の使用およびメモリー・ページングの回避

- 5.1.10 インスタンス・リカバリのためのパラレル・リカバリの無効化

- 5.2 管理性向上のための推奨事項

- 5.2.1 Oracle RACまたはOracle Restartを併用したOracle Clusterwareの使用

- 5.2.2 データ・リカバリ・アドバイザを使用したデータ障害の検出、分析および修復

- 5.2.3 自動パフォーマンス・チューニング機能の使用

- 5.2.4 サーバー・パラメータ・ファイルの使用

- 5.2.5 自動UNDO管理の使用

- 5.2.6 ローカル管理表領域の使用

- 5.2.7 自動セグメント領域管理の使用

- 5.2.8 一時表領域の使用とデフォルト一時表領域の指定

- 5.2.9 再開可能領域割当ての使用

- 5.2.10 データベース・リソース・マネージャの使用

6 Oracle Clusterwareを使用したOracle Databaseの構成

- 6.1 Oracle Clusterwareのベスト・プラクティス

- 6.1.1 クライアントの構成および移行の概要

- 6.1.1.1 サービス

- 6.1.1.2 高速アプリケーション通知(FAN)

- 6.1.1.3 単一クライアント・アクセス名(SCAN)

- 6.2 Oracle Clusterwareの構成ベスト・プラクティス

- 6.2.1 クラスタ検証ユーティリティ(CVU)の使用

- 6.2.2 Oracle ASMによるOracleデータベースおよびOracleクラスタウェアのローカル・ホームの使用

- 6.2.3 サービスの高可用性の保証

- 6.2.4 クライアント構成とFANのベスト・プラクティス

- 6.2.5 サービスおよび単一クライアント・アクセス名(SCAN)を使用したデータベースへの接続

- 6.2.6 クライアント側およびサーバー側でのロード・バランシングの使用

- 6.2.7 Oracle ASMを使用した、Oracle Cluster Registry (OCR)のミラー化と複数の投票ディスクの構成

- 6.2.8 会社全体のクラスタ時間管理

- 6.2.9 Oracle Clusterware、Oracle RACおよびOracle ASMで同じインターコネクト・ネットワークを使用していることの確認

- 6.2.10 Highly Available IP (HAIP)を併用した冗長インターコネクトの使用

- 6.2.11 Intelligent Management Platform Interface (IPMI)による障害分離の構成

- 6.3 Oracle Clusterwareの運用ベスト・プラクティス

- 6.3.1 キャパシティ・プランニング

- 6.3.2 テープまたはオフサイトへのOCRの定期的なバックアップ

7 Oracle RACを使用したOracle Databaseの構成

- 7.1 Oracle RACを使用したOracle Databaseの構成

- 7.1.1 インスタンス・リカバリ時間の最適化

- 7.1.2 トランザクション・リカバリを実行するプロセスの数の最大化

- 7.1.3 非同期I/Oの有効化の確認

- 7.1.4 ノード間の冗長専用接続

- 7.2 Oracle RAC One Nodeを使用したOracle Databaseの構成

- 7.3 拡張クラスタ上のOracle RACを使用したOracle Databaseの構成

- 7.3.1 拡張クラスタのサイトへのワークロードの均等な分散

- 7.3.2 クォーラム・ディスクをホストするための第3の投票ディスクの追加

- 7.3.3 都市圏での近接性を保持するノードの構成

- 7.3.4 Oracle ASM標準冗長性または高冗長性でのホスト・ベースのストレージ・ミラー化の使用

- 7.3.5 拡張クラスタに関する追加のデプロイメントの考慮事項

8 バックアップとリカバリの構成

- 8.1 Oracleデータベースのバックアップおよびリカバリの製品および機能

- 8.1.1 バックアップを使用する状況の理解

- 8.1.2 Recovery Manager (RMAN)を使用したデータベース・ファイルのバックアップ

- 8.1.3 Oracle Secure Backupを使用したテープへのバックアップ

- 8.1.3.1 Oracle Secure Backupを使用したAmazon S3ストレージへのバックアップ

- 8.1.4 データベース・スナップショットを作成するためのリストア・ポイントの使用

- 8.2 バックアップおよびリカバリの構成と管理のベスト・プラクティス

- 8.2.1 バックアップ頻度および保存ポリシーの決定

- 8.2.2 RMANリカバリ・カタログの使用

- 8.2.3 NOCATALOGモードとその後のRESYNC CATALOGによるバックアップの作成

- 8.2.4 増分バックアップ用のブロック変更トラッキングの有効化

- 8.2.5 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの有効化

- 8.2.6 フィジカル・スタンバイ・データベースへのバックアップ負荷の移行

- 8.2.7 フラッシュバック問合せおよびフラッシュバック表のニーズに対するUNDO保存期間の設定

- 8.3 ディスクへのバックアップのベスト・プラクティス

- 8.4 テープへのバックアップのベスト・プラクティス

- 8.4.1 RMANとOracle Secure Backupの初期構成

- 8.4.2 テープ・バックアップに対するOracle Secure Backupメディア・ポリシーの定義

- 8.4.3 高速リカバリ領域からのテープ・バックアップの作成

- 8.4.4 オフサイトのバックアップ・テープの管理

- 8.5 バックアップおよびリカバリの操作とメンテナンスのベスト・プラクティス

- 8.5.1 データ障害の診断と修復オプションの提示

- 8.5.2 データベース・ファイルの破損の定期的なチェック

- 8.5.3 リカバリ手順の定期的なテスト

- 8.5.4 RMANおよびOracle Secure Backupカタログの定期的なバックアップ

- 8.5.5 データベース外部のファイルをバックアップする手順の使用

- 8.6 データベース外部のファイルのバックアップ

- 8.6.1 ACFSスナップショット

- 8.6.2 オラクルのSun ZFS Storage Applianceのスナップショット

- 8.6.3 テープ・バックアップ

9 Oracle Data Guardの構成

- 9.1 Oracle Data Guardの構成ベスト・プラクティス

- 9.2 保護モードとData Guard転送の決定

- 9.2.1 REDO転送サービスのベスト・プラクティスの使用

- 9.2.2 ネットワーク構成案に関するパフォーマンスの評価

- 9.3 Data Guardの一般構成ベスト・プラクティス

- 9.3.1 Oracle Data GuardによるOracle Data Guardブローカの使用

- 9.3.2 Recovery Managerを使用したスタンバイ・データベースの作成

- 9.3.3 フェイルオーバー後の復元のためのフラッシュバック・データベースの使用

- 9.3.4 FORCE LOGGINGモードの使用

- 9.3.5 単純で堅牢なアーカイブ計画および構成の使用

- 9.3.6 スタンバイREDOログの使用と適切なサイズ構成

- 9.3.7 Data Guard転送とネットワーク構成のベスト・プラクティスの使用

- 9.3.7.1 LOG_ARCHIVE_MAX_PROCESSESパラメータの設定

- 9.3.7.2 ネットワーク構成と最大ネットワークREDO速度の設定

- 9.3.8 Data Guard Redo Applyのベスト・プラクティスの使用

- 9.3.8.1 スタンバイREDOログとアーカイブREDOログのI/Oレートの最大化

- 9.3.8.2 リカバリ速度の評価

- 9.3.8.3 DB_BLOCK_CHECKSUM=FULLおよびDB_BLOCK_CHECKING=MEDIUMまたはFULLの設定

- 9.3.8.4 DB_CACHE_SIZEのプライマリ・データベースの同じパラメータより大きい値への設定

- 9.3.8.5 データベース待機イベントの評価

- 9.3.8.6 I/O操作のチューニング

- 9.3.8.7 システム・リソースの評価

- 9.3.9 複数のスタンバイ・データベースの実装

- 9.4 Oracle Data Guardのロール移行のベスト・プラクティス

- 9.4.1 Oracle Data Guardのスイッチオーバーのベスト・プラクティス

- 9.4.2 Oracle Data Guardのフェイルオーバーのベスト・プラクティス

- 9.4.2.1 ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較

- 9.4.2.2 フェイルオーバーのベスト・プラクティス(手動フェイルオーバーとファスト・スタート・フェイルオーバー)

- 9.4.2.3 ファスト・スタート・フェイルオーバーのベスト・プラクティス

- 9.4.2.4 手動フェイルオーバーのベスト・プラクティス

- 9.5 Oracle Active Data Guardのベスト・プラクティスの使用

- 9.6 スナップショット・スタンバイ・データベースのベスト・プラクティスの使用

- 9.7 Data Guardのパフォーマンスの評価

10 Oracle GoldenGateの構成

- 10.1 Oracle GoldenGateの概要

- 10.1.1 Oracle GoldenGateおよびOracle Streams

- 10.1.2 Oracle GoldenGateおよびOracle RAC

- 10.1.3 Oracle GoldenGateとOracle Data Guard/Oracle Active Data Guard

- 10.1.4 Oracle GoldenGateとエディションベース再定義

- 10.2 Oracle GoldenGateの構成ベスト・プラクティス

- 10.2.1 クラスタ化ファイル・システムの使用

- 10.2.2 ASMログ・ファイルの読取りAPIの向上

- 10.2.3 Replicatコミット動作

- 10.2.4 Oracle Clusterwareの構成

- 10.2.5 その他のOracle GoldenGateベスト・プラクティス

- 10.3 Oracle GoldenGateの運用ベスト・プラクティス

11 高速接続フェイルオーバーの構成

- 11.1 JDBCとOCIクライアントへのフェイルオーバーの構成

- 11.2 Oracle RACデータベースのフェイルオーバーの構成

- 11.2.1 データベース・サービスの構成

- 11.2.2 FANのサーバー側コールアウトのオプション構成

- 11.3 Oracle Data Guard環境の構成

- 11.3.1 データベース・サービスの構成

- 11.3.2 Data Guardブローカの使用

- 11.4 スイッチオーバー操作中のクライアント移行

- 11.5 ログイン・ストームの阻止

- 11.6 アプリケーション・サポート

12 高可用性の監視

- 12.1 高可用性の監視と検出の概要

- 12.2 Enterprise Managerを使用したシステム監視

- 12.2.1 Oracle Enterprise Managerの「ホーム」ページ

- 12.2.2 各システムのメトリックと通知ルールの構成

- 12.2.3 データベース・ターゲット・ビューを使用したシステム状態、可用性およびパフォーマンスの監視

- 12.2.4 メトリックを使用したData Guardシステムの可用性の監視

- 12.3 Enterprise Managerを使用した高可用性環境の管理

- 12.3.1 Enterprise Managerポリシー違反のチェック

- 12.3.2 Enterprise Managerを使用したOracleパッチの管理とシステム・ベースラインの維持

- 12.3.3 高可用性コンソールを使用したデータベース可用性の管理

- 12.3.4 MAAアドバイザを使用した高可用性ソリューションの構成

- 12.4 クラスタ状態モニターの使用方法

13 計画外の停止からのリカバリ

- 13.1 計画外の停止の概要

- 13.1.1 プライマリ・サイトでの計画外の停止の管理のベスト・プラクティス

- 13.1.2 スタンバイ・サイトでの計画外の停止の管理のベスト・プラクティス

- 13.2 計画外の停止からのリカバリ

- 13.2.1 サイト・フェイルオーバーの完了(セカンダリ・サイトへのフェイルオーバー)

- 13.2.1.1 完全サイト・フェイルオーバーを使用する時期

- 13.2.1.2 完全サイト・フェイルオーバーのベスト・プラクティス

- 13.2.1.3 修復ソリューション

- 13.2.2 スタンバイ・データベースでのデータベース・フェイルオーバー

- 13.2.2.1 Data Guardフェイルオーバーを実行する時期

- 13.2.2.2 ファスト・スタート・フェイルオーバーを実装するためのベスト・プラクティス

- 13.2.2.3 手動フェイルオーバー実行のベスト・プラクティス

- 13.2.3 計画外の停止からのOracle RACリカバリ(ノードまたはインスタンス障害の場合)

- 13.2.3.1 障害インスタンスの自動インスタンス・リカバリ

- 13.2.3.2 自動サービス再配置

- 13.2.3.3 Oracle Cluster Registryのリカバリ

- 13.2.4 アプリケーション・フェイルオーバー

- 13.2.5 ディスクおよびストレージ障害後のOracle ASMリカバリ

- 13.2.5.1 Oracle ASMインスタンス障害

- 13.2.5.2 Oracle ASMディスク障害

- 13.2.5.3 データ領域ディスク・グループ障害

- 13.2.5.4 高速リカバリ領域ディスク・グループ障害

- 13.2.6 データの破損からのリカバリ

- 13.2.6.1 データ・リカバリ・アドバイザの使用

- 13.2.6.2 Active Data Guardの使用

- 13.2.6.3 RMANとブロック・メディア・リカバリの使用

- 13.2.6.4 Data Guardロール移行の実行

- 13.2.6.5 RMANおよびデータファイル・メディア・リカバリの使用

- 13.2.7 人為的エラーからのリカバリ(フラッシュバックによるリカバリ)

- 13.2.7.1 表の非一貫性の解決

- 13.2.7.2 行およびトランザクションの非一貫性の解決

- 13.2.7.3 データベース全体の非一貫性の解決

- 13.2.7.4 1つまたは複数の表領域の非一貫性の解決

- 13.2.8 分散環境でのデータベースのリカバリ

- 13.3 フォルト・トレランスのリストア

- 13.3.1 Oracle RACおよびOracle RAC One Nodeの障害ノードまたは障害インスタンスのリストア

- 13.3.1.1 Oracle RACのサービス可用性のリカバリ

- 13.3.1.2 Oracle RAC One Nodeのサービス可用性のリカバリ

- 13.3.1.3 Oracle RACインスタンスのリストア後のクライアント接続に関する考慮事項

- 13.3.2 フェイルオーバー後のスタンバイ・データベースのリストア

- 13.3.2.1 ファスト・スタート・フェイルオーバー後の元のプライマリ・データベースの復元

- 13.3.2.2 Enterprise Managerを使用したフェイルオーバー後のスタンバイ・データベースの復元

- 13.3.3 障害後のOracle ASMディスク・グループのリストア

- 13.3.4 セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア

- 13.3.5 スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア

- 13.3.6 RESETLOGSによるプライマリ・データベースのオープン後のフォルト・トレランスのリストア

- 13.3.7 二重障害後のフォルト・トレランスのリストア

14 計画メンテナンスの停止時間の短縮

- 14.1 計画済の停止の概要

- 14.1.1 プライマリ・サイトでの計画済の停止の管理

- 14.1.2 セカンダリ・サイトでの計画済の停止の管理

- 14.2 計画済の停止による停止時間の回避または短縮

- 14.2.1 データベース・スイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス

- 14.2.1.1 Data Guardスイッチオーバーを実行する時期

- 14.2.1.2 Data Guardスイッチオーバーを構成するためのベスト・プラクティス

- 14.2.1.3 Data Guardスイッチオーバーの実行方法

- 14.2.2 オンライン・パッチ

- 14.2.3 Data Guard Standby-First Patchの適用

- 14.2.4 Oracle RACパッチ

- 14.2.4.1 すべてのデータベース・パッチ・アップグレードで停止時間を最小にするためのベスト・プラクティス

- 14.2.4.2 データベースのローリング・アップグレードで停止時間を最小にするためのベスト・プラクティス

- 14.2.4.3 ホーム外ソフトウェアのインストールとパッチ適用

- 14.2.4.4 OPlanを使用したパッチ適用

- 14.2.5 Grid Infrastructureのメンテナンス

- 14.2.5.1 Grid Infrastructureのローリング・アップグレード

- 14.2.5.2 ストレージ・メンテナンス

- 14.2.6 データベース・アップグレード

- 14.2.6.1 Database Upgrade Assistant (DBUA)を使用したアップグレード

- 14.2.6.2 Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード

- 14.2.6.3 Oracle GoldenGateを使用したアップグレード

- 14.2.6.4 トランスポータブル表領域を使用したアップグレード

- 14.2.7 データベースのプラットフォームまたはロケーションの移行

- 14.2.7.1 オプションと移行方針の検討

- 14.2.7.2 移行の計画

- 14.2.7.3 プラットフォームの移行とアップグレードに関するOracleの機能

- 14.2.7.4 プラットフォーム移行のためのフィジカル・スタンバイ・データベース

- 14.2.7.5 プラットフォーム移行のためのトランスポータブル・データベース

- 14.2.7.6 プラットフォーム移行のためのOracle GoldenGate

- 14.2.7.7 プラットフォーム移行のためのOracle Data Pump

- 14.2.7.8 プラットフォーム移行のためのトランスポータブル表領域

- 14.2.7.9 ロケーション移行のためのData Guard REDO Apply(フィジカル・スタンバイ・データベース)

- 14.2.8 オンライン・アプリケーション・メンテナンスおよびアップグレードのエディションベースの再定義

- 14.2.9 オンライン・アプリケーション・アップグレードでのOracle GoldenGate

- 14.2.10 データの再編成と再定義

- 14.2.11 システム・メンテナンスのための自動ワークロード管理

用語集

索引

図一覧

- 4-1 ディスク全体の割当て

- 4-2 各ディスクのパーティション化

- 12-1 Enterprise Managerの「ホーム」ページ

- 12-2 可用性の通知ルールの設定

- 12-3 メトリックの通知ルールの設定

- 12-4 データベースの「ホーム」ページ

- 12-5 ポリシー違反を表示しているターゲットのデータベースの「ホーム」ページ

- 12-6 データベース・ターゲットの「ポリシーの傾向の概要」ページ

- 12-7 ポリシー違反が表示された「コンプライアンス」タブの表示

- 12-8 高可用性コンソールでのプライマリ・データベースの監視

- 12-9 高可用性コンソールでのスタンバイ・データベースの監視

- 12-10 サービスを表示している高可用性コンソールでのクラスタの監視

- 12-11 Enterprise Managerの「最大可用性アーキテクチャ(MAA)アドバイザ」ページ

- 13-1 サイト・フェイルオーバー前のネットワーク・ルート

- 13-2 サイト・フェイルオーバー後のネットワーク・ルート

- 13-3 Enterprise Managerによるディスク障害のレポート

- 13-4 Enterprise ManagerによるOracle ASMディスク・グループ・ステータスのレポート

- 13-5 Enterprise Managerによる保留中のREBAL操作のレポート

- 13-6 パーティション化された2ノードのOracle RACデータベース

- 13-7 パーティション化されたデータベースでのOracle RACインスタンスのフェイルオーバー

- 13-8 パーティション化されていないOracle RACインスタンス

- 13-9 有効化に成功したファスト・スタート・フェイルオーバーとオブザーバ

- 13-10 ファスト・スタート・フェイルオーバー後の元のプライマリ・データベースの復元

- 14-1 一時ロジカル・スタンバイ・データベースを使用したデータベース・ローリング・アップグレード

- 14-2 Oracle Enterprise Managerを使用したデータベース・オブジェクトの再編成

表一覧

- 2-1 各種のテストおよびQA環境のトレードオフ

- 8-1 バックアップおよびリカバリの概要

- 8-2 データベース・バックアップが必要な状況の例

- 8-3 ディスクへのバックアップ・オプションの比較

- 9-1 要件とData Guardデプロイメント・オプション

- 9-2 アーカイブの推奨事項

- 9-3 パラレル・リカバリ・コーディネータの待機イベント

- 9-4 パラレル・リカバリ・スレーブの待機イベント

- 9-5 ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較

- 9-6 FastStartFailoverThresholdの最小値の推奨設定

- 12-1 領域を監視するための推奨事項

- 12-2 アラート・ログを監視するための推奨事項

- 12-3 処理容量を監視するための推奨事項

- 12-4 パフォーマンス関連メトリックに関する推奨事項

- 12-5 Data Guardメトリックを設定するための推奨事項

- 13-1 プライマリ・サイトでの計画外の停止のリカバリ時間および手順

- 13-2 セカンダリ・サイトでの計画外の停止のリカバリ手順

- 13-3 Oracle ASM障害タイプと推奨される修復方法

- 13-4 データ領域ディスク・グループ障害のリカバリ・オプション

- 13-5 高速リカバリ領域ディスク・グループ障害のリカバリ・オプション

- 13-6 様々な障害のフラッシュバック・ソリューション

- 13-7 フラッシュバック機能のまとめ

- 13-8 ノードまたはインスタンスの再起動または再結合時の追加処理

- 13-9 リストアおよび接続フェイルバック

- 13-10 スタンバイ・データベースを起動するためのSQL文

- 13-11 REDO ApplyおよびSQL Applyを開始するためのSQL文

- 13-12 RESETLOGS SCNと現在のSCN OPEN RESETLOGSを確認するための問合せ

- 13-13 スタンバイ・データベースのSCNがプライマリ・データベースのRESETLOGS SCNより遅れている場合のアクション

- 13-14 スタンバイ・データベースのSCNがプライマリ・データベースのリセットログSCNより進んでいる場合のアクション

- 13-15 プライマリ・データベースとスタンバイ・データベースの再作成

- 14-1 プライマリ・サイトでの計画済の停止のソリューション

- 14-2 セカンダリ・サイトでの計画済の停止の管理

- 14-3 データベース・アップグレード・オプション

- 14-4 プラットフォームおよびロケーション移行のオプション

はじめに

このマニュアルは、Oracle Databaseシステムおよびネットワーク・コンポーネントの構成と保守を行うための高可用性のベスト・プラクティスについて説明します。

対象読者

このマニュアルは、次のデータベース、システム、ネットワークおよびアプリケーション・タスクを遂行する情報技術責任者、情報テクノロジ・アーキテクトおよび管理者を対象としています。

- データ・センターの計画

- データ・センター・ポリシーの実装

- 高可用性システムのメンテナンス

- 高可用性ソリューションの計画および構築

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

お客様は、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Databaseのドキュメント・セットを参照してください。特に関連性の高いドキュメントを次に示します。

- 『Oracle Database高可用性概要』を参照してください。

- 『Oracle Data Guard概要および管理』および『Oracle Data Guard Broker』

- 『Oracle Automatic Storage Management管理者ガイド』

- 『Oracle Clusterware管理およびデプロイメント・ガイド』

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

- 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

- Oracle Database管理者ガイド

- Oracle高可用性ベスト・プラクティスに関するホワイトペーパーはOracle Technology Network(OTN)からダウンロードできます。
http://www.oracle.com/goto/maa

- Oracle Enterprise Managerドキュメント・ライブラリ
http://www.oracle.com/technetwork/oem/grid-control/overview/index.html

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 高可用性ベスト・プラクティスの概要

Oracle Maximum Availability Architecture (MAA)のベスト・プラクティスを実装し、使用することで、Oracleデータベースと関連テクノロジの可用性を向上させることができます。

この章には、次の項目が含まれます。

- Oracleデータベースの高可用性アーキテクチャ

- Oracleデータベースの高可用性ベスト・プラクティス

- Oracle Maximum Availability Architecture

1.1 Oracleデータベースの高可用性アーキテクチャ

Oracleテクノロジとハードウェア、ソフトウェアおよびデプロイ・オプションは広い範囲をカバーするため、高可用性アーキテクチャの設計や実装にあたって不安を感じても不思議はありません。作業を成功に導くには、まずビジネス要件を明確に定義し、隅々まで理解しておくことが必要です。ビジネス要件を細かく分析することで、設計を適切に決定し、ビジネス・ニーズを最適のコスト効率で満足させるアーキテクチャを開発することが可能になります。選択するアーキテクチャは、可用性、パフォーマンス、スケーラビリティおよびセキュリティの要求水準を満たすものである必要があります。また、デプロイおよび継続管理に関する計画が明確に定義されているアーキテクチャである必要があります。それにより、簡潔性を高め、ビジネス・リスクを最小限に抑えることができます。

ビジネス要件が確定したら、『Oracle Database高可用性概要』を参照して、Oracle Maximum Availability Architecture (MAA)をはじめとする様々なOracleソリューションの概要を把握し、高可用性アーキテクチャの設計を開始します。そのように設計されたアーキテクチャについては、このマニュアルで説明するベスト・プラクティスを使用して、詳細な調査と検証を行うことができます。

1.2 Oracleデータベースの高可用性ベスト・プラクティス

Oracle高可用性(HA)ベスト・プラクティスは、高可用性アーキテクチャの全社的デプロイを容易にします。構成面と運用面のベスト・プラクティスが、高可用性を実現し、エンタープライズの実装と継続メンテナンスに関するコストを引き下げるために役立ちます。また、システム資源の使用率を最適化することもできます。

HAベスト・プラクティスを実装すると、次のことが可能になります。

- データベース、ストレージ、アプリケーション・フェイルオーバー、バックアップおよびリカバリを構成するための詳細なガイドラインに従うことで、Oracleデータベースの高可用性システムの作成コストを削減できます。詳細は、第3章「構成ベスト・プラクティスの概要」を参照してください。

- 運用ベスト・プラクティスを使用してシステムを保持します。詳細は、第2章「可用性を最大化するための運用前提条件」を参照してください。

- コンピュータ障害、ストレージ障害、人為的エラーまたはデータ破損を原因とする計画外の停止を検出し、迅速にリカバリできます。詳細は、5.1.6項「データ破損の防止」と第13章「計画外の停止からのリカバリ」を参照してください。

- データベースへのパッチ適用やアプリケーション・アップグレードなどの計画済のメンテナンスによる停止時間を回避または削減できます。詳細は、第14章「計画メンテナンスの停止時間の短縮」を参照してください。

1.3 Oracle Maximum Availability Architecture

Oracle Maximum Availability Architecture (MAA)はOracleのベスト・プラクティスのブループリントで、Oracle High Availability (HA)テクノロジや、Oracle MAA開発チームによって実施された幅広い検証、そしてOracleを活用してビジネスに不可欠なアプリケーションを運用してきたユーザーの様々な実証例に基づいています。

MAAの対象となるOracle製品のカテゴリは次のテクノロジです。

- Oracle Database(このマニュアルに記載済)

- Oracle Exadata Database MachineとOracle Exalogic Elastic Cloud

- Oracle Fusion MiddlewareとOracle WebLogic Server

- Oracle Applications (Siebel、Peoplesoft、E-Business Suite)

- Oracle Collaboration Suite

- Oracle Enterprise Manager

このドキュメント、つまり『Oracle Database高可用性ベスト・プラクティス』では、Oracle Databaseの高可用性に関するベスト・プラクティスについて主に説明します。Oracle Maximum Availability Architecture (MAA)のベスト・プラクティスの対象として想定できる、その他のコンポーネントもあります。詳細は、次のサイトを参照してください。

http://www.oracle.com/goto/MAA

関連項目:

- Oracle Fusion Middlewareの高可用性の詳細は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』を参照してください。

- Oracle Fusion Middlewareのバックアップおよびリカバリの詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。

MAAの目的は、コストおよび複雑さを最小限に抑えて最適な高可用性アーキテクチャを実現することです。MAAの特性は次のとおりです。

- ベスト・プラクティスの対象は、Exadata Database Machine、Oracle Database、Oracle Fusion Middleware、Oracle Applications、Oracle Enterprise Manager、およびOracle Partnersで提供されたソリューションです。

- 様々なビジネス要件に対応するため、ベスト・プラクティスを可能なかぎり広範囲に適用できます。

- サーバーとストレージのコスト削減に利用できます。

- ハードウェアやオペレーティング・システムの影響を受けず、Oracleの新バージョンや新機能に適応します。唯一の例外はExadata MAAで、これにはExadata Database Machineに対する固有のカスタマイズされた構成および運用作業が含まれます。

- 様々なビジネスの品質保証契約(SLA)を考慮しながら高可用性ベスト・プラクティスを可能なかぎり広範囲に適用できます。

- データベース・サーバー・グリッドとデータベース・ストレージ・グリッドを使用したOracle Grid Infrastructureを活用して、回復力に優れた、スケーラブルで低コストのインフラストラクチャを提供します。

- 停止状態からのリカバリ時間の長さと、停止時に許容可能なデータ損失の量を制御できます。

MAAの詳細およびすべてのMAAコンポーネントのベスト・プラクティスに関するドキュメントは、次のMAA Webサイトを参照してください。

http://www.oracle.com/goto/maa

2 可用性を最大化するための運用前提条件

MAAの実装を成功させるには、運用ベスト・プラクティスを使用します。

この章には、次の項目が含まれます。

- 可用性およびパフォーマンスのSLAの理解

- 高可用性環境の実装

- パフォーマンスおよび可用性のSLAの検証

- セキュリティ・ベスト・プラクティスの設定および使用

- 変更管理手順の確立

- 推奨パッチおよびソフトウェアのテストと適用の計画の提供

- 適切なテストおよびパッチ適用作業の使用

- Data Guardのロール移行の実行

- エスカレーション管理手順の確立

- 高可用性のための監視およびサービス要求インフラストラクチャの構成

- 最新のMAAベスト・プラクティスの確認

2.1 可用性およびパフォーマンスのSLAの理解

高可用性およびパフォーマンスに関する品質保証契約(SLA)を理解して文書化し、停止およびソリューション・マトリックスを作成します。

- 『Oracle Database高可用性概要』に記載されているシステム停止における、停止時間、リカバリ時間目標(RTOまたはリカバリ時間)、およびリカバリ・ポイント目標(RPOまたはデータ損失許容度)のビジネス上のコストを文書化します。

- 表13-1「プライマリ・サイトでの計画外の停止のリカバリ時間および手順」と表14-1「プライマリ・サイトでの計画済の停止のソリューション」に示されているものと同様の、停止およびソリューション・マトリックスを構築します。

2.2 高可用性環境の実装

最適な高可用性アーキテクチャを構築するための高可用性環境を実装します。

- ソフトウェアのインストール、または最新の認定パッチ・セットによるソフトウェアの更新

- ベスト・プラクティスを使用したソフトウェアの構成

- 選択内容と構成の文書化

2.3 パフォーマンスおよび可用性のSLAの検証

修復作業を検証および自動化して、ターゲットHAの品質保証契約(SLA)に準拠していることを確認します。バックアップ、リストアおよびリカバリの操作を検証して、可能性のある各種の停止に対するすべての修復作業を定期的に評価します(詳細は表13-1を参照してください)。

Oracle Data Guardを障害回復とデータ保護に使用する場合は、定期的なスイッチオーバー作業を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実施することをお薦めします。また、アプリケーションおよびData Guardのスイッチオーバーを定期的に実行して、すべてのロール移行手順を完全に検証します。詳細は、2.8項「Data Guardのロール移行の実行」を参照してください。

2.4 セキュリティ・ベスト・プラクティスの設定および使用

適切なセキュリティ基準のないシステムまたはデータベースに配置された企業データは、深刻なリスクに直面している可能性があります。明確に定義されたセキュリティ・ポリシーは、システムに対する不正アクセスを遮断し、企業の機密情報を破壊行為から保護するのに役立ちます。適切なデータ保護により、セキュリティの侵害によるシステム停止の可能性を抑制できます。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

2.5 変更管理手順の確立

システムの安定性を維持し、テスト・システムで厳密に評価されるまで変更がプライマリ・データベースに適用されないように、変更を管理および制御する手順を設けます。

変更を確認して、変更管理チームからフィードバックと承認を受け取ります。このチームにはビジネス要件、機能性、パフォーマンスおよびシステムの可用性に影響する、あらゆるコンポーネントの代表が含まれることが必要です。たとえば、チームにはエンドユーザー、アプリケーション、データベース、ネットワークおよびシステムの代表を含むことができます。

2.6 推奨パッチおよびソフトウェアのテストと適用の計画の提供

最新の推奨パッチおよびソフトウェア・バージョンに対する定期的なテストと適用によって、最新のセキュリティおよびソフトウェアの修正がシステムで確実に行われるようにします。これは、安定性を維持し、多くの既知の問題を回避するために必要です。本番システムでアップグレードを実行する前に、テスト・システムですべての更新および変更を必ず検証してください。詳細は、次のWebサイトのMy Oracle Support Note 756671.1の『Oracle推奨パッチ - Oracle Database』を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=756671.1

2.7 適切なテストおよびパッチ適用作業の使用

適切なテストとパッチ適用は安定性を維持するための重要な前提条件です。変更はすべてテスト・システムで完全に検証してから、本番環境に適用する必要があります。実際の作業には次のようなものがあります。

- テスト・システムおよびQA環境の構成

- 本番前の検証手順の実行

2.7.1 テスト・システムおよびQA環境の構成

テスト・システムは機能テスト、パフォーマンス・テストおよび可用性テストを実行することを目的とした、本番およびスタンバイの環境とワークロードの精密なレプリカです(詳細は表13-1を参照してください)。変更はすべて、変更の効果とフォールバック手順の評価も含めて最初にテスト環境で検証してから、本番環境にその変更を導入する必要があります。

適切に構成されたテスト・システムによって、多くの問題を回避できます。変更が検証されるのは同等の本番およびスタンバイ・データベース構成で、これには完全なデータ・セットが含まれ、本番を模倣するためのワークロード・フレームワーク(たとえば、Oracle Real Application Testing)が使用されるためです。

テスト・システムの廃止によってコストを削減しようとしないでください。この決断は後々、本番アプリケーションの安定性と可用性に影響を及ぼすことになります。テストおよびQAのためにシステム・リソースのサブセットのみを使用すると、表2-1に示されているトレードオフがあります。

表2-1 各種のテストおよびQA環境のトレードオフ

テスト環境

利点とトレードオフ

本番システムとスタンバイ・システムの完全レプリカ

すべてのパッチとソフトウェアの変更を検証します。

すべての機能テストを検証します。

本番スケールにおける完全パフォーマンス検証。

完全HA検証。

本番システムの完全レプリカ

すべてのパッチとソフトウェアの変更を検証します。

すべての機能テストを検証します。

本番スケールにおける完全パフォーマンス検証。

完全HA検証からスタンバイ・システムをマイナスしたもの。

スタンバイ・データベースによる機能、パフォーマンス、HAおよび障害回復の検証はなし。

スタンバイ・システム

ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。

Data Guardスナップショット・スタンバイの使用時は、完全なパフォーマンス検証。ただし、フェイルオーバーが必要な場合はリカバリ時間が長くなる可能性があります。

ロール移行の検証。

スタンバイ・データベースとテスト・データベースが同じシステムに存在する場合は、リソース管理およびスケジューリングが必要です。

共有システム・リソース

ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。

本番の模倣に十分なシステム・リソースを割当てできれば、この環境はパフォーマンス・テストに適している場合があります。

ただし、通常は、環境に本番システム・リソースのサブセットが含まれ、パフォーマンスのテスト/検証には欠落が生じます。

リソース管理およびスケジューリングが必要です。

システム・リソースの小規模バージョンまたはサブセット

すべてのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。

本番スケールにおけるパフォーマンス・テストなし。

限定的な、完全スケールの高可用性評価。

異なるハードウェアまたはプラットフォームのシステム・リソース(同一オペレーティング・システム)

ほとんどのパッチとソフトウェアの変更を検証します。限定的な、ファームウェア・パッチ適用テスト。

すべての機能テストを、ハードウェアの新機能で制限されていないかぎり、検証します。

限定的な、本番スケールのパフォーマンス・テスト。

限定的な、完全スケールの高可用性評価。

関連項目:
『Oracle Database Real Application Testingユーザーズ・ガイド』

2.7.2 本番前の検証手順の実行

ソフトウェア・パッチまたはすべての変更を本番前に検証およびテストすることは、安定性を維持するために重要です。上位レベルの本番前検証の手順は次のとおりです。

1. パッチまたはアップグレードのドキュメントや、対象の変更に関連するドキュメントを確認します。SLAで停止時間をゼロまたは最小限にすることが必要な場合、ローリング・アップグレードの実行の可能性を評価します。計画済停止時間を最小化または排除するローリング・アップグレードの機会を評価します。パッチがStandby-First Patchingに適格かどうか評価します。

注意:
Standby-First Patchを使用すると、プライマリ・データベースは以前のソフトウェア・リリースのまま、パッチを最初にフィジカル・スタンバイ・データベースに適用できます(この適用対象は特定のパッチ・タイプで、Oracleパッチ・セットおよびメジャー・リリース・アップグレードには適用されません。パッチ・セットおよびメジャー・リリースにはData GuardのTransient Logical Standbyメソッドを使用してください)。変更作業が終了したら、スタンバイ・データベースへのスイッチオーバーを実行します。フォールバックは必要な場合にスイッチオーバーすることです。もう1つの方法として次の手順に進み、本番環境に変更を適用することもできます。詳細は、次のWebサイトのMy Oracle Support Note 1265700.1の『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1

2. テスト環境でアプリケーションを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。手順を自動化して、フォールバック手順の文書化およびテストも確認します。これには、テストでパッチ適用の前後に取得されたメトリックを、本番システムで取得されたメトリックと比較することが必要です。Real Application Testingは、本番システムでワークロードを取得し、それをテスト・システムで再現するために使用できます。AWRとSQLパフォーマンス・アナライザは、パッチによって引き起こされたパフォーマンスの向上または低下を評価するために使用できます。
本番環境を模倣するテスト・システムで新規ソフトウェアを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。パッチまたはアップグレードの手順を自動化して、フォールバックを確認します。この手順を一通り実施することで、パッチまたはアップグレードの実施中および実施後における最も致命的な問題を回避できます。

テスト・システムの構成の詳細は、2.7.1項「テスト・システムおよびQA環境の構成」を参照してください。

3. 任意でOracle Real Application Testingオプションを使用すると、Oracle Databaseを現実的な環境でテストできます。Oracle Real Application Testingは、本番環境へのデプロイメントを行う前に、本番環境でのワークロードを取得し、システムの変更による影響を評価することで、その変更が原因で不安定になるリスクを最小限にします。Oracle GoldenGateは、変更を適用するためのもう1つのロジカル・レプリカとして使用することもできます。
テスト・システムの構成の詳細は、2.7.1項「テスト・システムおよびQA環境の構成」を参照してください。

4. 適用可能な場合、すべての変更の最終的な本番前検証をData Guardスタンバイ・データベースで実行してから、それを本番に適用してください。適用可能な場合、Oracle Data Guard環境で変更を適用します。Data Guardの一時ロジカル・スタンバイ・メソッドの詳細は、14.2.6項「データベースのアップグレード」を参照してください。

5. 本番環境で変更を適用します。

関連項目:

- 『Oracle Database Real Application Testingユーザーズ・ガイド』

- フィジカル・スタンバイ・データベースのスナップショット・スタンバイ・データベースへの変換の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- Oracle GoldenGateの詳細は、『Oracle GoldenGate Windows and UNIX管理者ガイド』を参照してください。

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Data Guardのフィジカル・スタンバイ・データベースの使用によって容易になるデータベース・ローリング・アップグレード』を参照してください。
http://www.oracle.com/goto/maa

- 次のWebサイトのMy Oracle Support Note 1265700.1の『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1

2.8 Data Guardのロール移行の実行

スタンバイ・データベースがある場合、事前に定められたしきい値に従って、プライマリ・データベースが停止または機能が低下した場合はいつでもスタンバイ・データベースを使用できるように、運用およびDBAチームが十分に準備できていることが重要です。効率的に応答および実行すること(フェイルオーバーの検知と決定が含まれます)で、全体的な停止時間を時間単位から分単位に削減できます。

Oracle Data Guardを障害回復とデータ保護に使用する場合は、四半期ごとに定期的なスイッチオーバー作業を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実施することをお薦めします。Oracle Data Guardの構成とロール移行のベスト・プラクティスの詳細は、第9章「Oracle Data Guardの構成」と9.4.1項「Oracle Data Guardのスイッチオーバーのベスト・プラクティス」を参照してください。

関連項目:
My Oracle Supportに用意されているData Guardスイッチオーバーのためのノートは次のとおりです。

- SQL*Plusを使用中の場合、次のWebサイトのMy Oracle Support Note 1304939.1の『SQL*Plusを使用した11.2 Data Guard Physical Standbyのスイッチオーバー・ベスト・プラクティス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1304939.1

- Data GuardブローカまたはEnterprise Managerを使用中の場合、次のWebサイトのMy Oracle Support Note 1305019.1の『Brokerを使用した11.2 Data Guard Physical Standbyのスイッチオーバー・ベスト・プラクティス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1305019.1

2.9 エスカレーション管理手順の確立

修復を妨げないためのエスカレーション管理手順を確立します。ほとんどの修復ソリューションは、適切に実施されていればMAAソリューションで自動的かつ透過的です。問題が発生するのは、プライマリ・データベースまたはシステムが可用性またはパフォーマンスのSLAに適合せず、フェイルオーバー手順がData Guardの一部のフェイルオーバー・シナリオのように自動で行われるのではない場合です。適切なエスカレーション・ポリシーが施行されず、決定が迅速に行われないと、停止時間が長引く可能性があります。

可用性は最優先課題であり、今後の根本原因分析(RCA)のために十分なデータを収集するための代替計画を作成する必要があります。

MAAの停止および修復の詳細は、次のOracle Technology Network(OTN)でMAA Webページを確認してください。

http://www.oracle.com/goto/maa

2.10 高可用性のための監視およびサービス要求インフラストラクチャの構成

高可用性環境を維持するには、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャを構成する必要があります。また、可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したハードウェアを置き換えることができます。

2.10.1 高可用性のための監視インフラストラクチャの構成

可能性のある停止時間を回避するには、Enterprise Managerと、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャの両方を構成および使用する必要があります。監視インフラストラクチャを使用すると、ユーザーは高可用性を監視しやすくなり、次の作業も実行できます。

- システム、ネットワーク、アプリケーション、データベースおよびストレージの統計の監視

- パフォーマンスおよびサービスの統計の監視

- システムまたはアプリケーションの問題の初期警告インジケータとなる、パフォーマンスおよび高可用性のしきい値の作成

関連項目:

- 第12章「高可用性の監視」

- 潜在的な問題および障害の検出と対応の詳細は、『Oracle Enterprise Manager管理者ガイド』を参照してください。

2.10.2 サービス要求インフラストラクチャの構成

Oracle HA環境でのEnterprise Managerによる監視インフラストラクチャに加えて可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したハードウェアを置き換えることができます。たとえば、Oracle Auto Service Request (ASR)は安全かつスケーラブルな、ユーザーがインストール可能なソフトウェア・ソリューションで、これは機能として使用できます。特定のハードウェア障害が発生したとき、OracleのSunサーバーおよびストレージ・システムの自動ケース生成を使用することで、このソフトウェアでは問題をより早く解決します。

関連項目:
次のWebサイトのMy Oracle Support Note 1185493.1の「Oracle Auto Service Request」を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1185493.1

2.11 最新のMAAベスト・プラクティスの確認

MAAソリューションは今後も、すべてのプラットフォームや様々なExadata Database Machineリリースで出現し続けます。次のOracle Technology Network (OTN)で定期的にMAA Webページを確認してください。

http://www.oracle.com/goto/maa

3 構成ベスト・プラクティスの概要

Oracle Enterprise Manager 11gの使用は、可用性の高いすべての環境を構成するためのMAAベスト・プラクティスで推奨されています。Oracle Enterprise Managerは、Oracle Gridとその製品上で稼働するアプリケーションの全側面を管理するための、Oracleの一体的な統合ソリューションです。Oracle Enterprise Manager Grid Controlは、トップダウン型のアプリケーション監視機能と、自動化された構成管理、プロビジョニングおよび管理を組み合せたものです。この強力な組合せにより、あらゆるサイズのOracleデータセンターに優れた管理機能を提供します。

Oracle Enterprise Managerを使用すると、ほとんどの構成作業を実行できます。たとえば次のようなことが可能です。

- Oracle Automatic Storage Management (Oracle ASM)への移行

- 単一インスタンスのOracle Databaseから、OracleクラスタウェアおよびOracle Real Application Clusters(Oracle RAC)への移行

- Oracle Data Guardスタンバイ・データベースの作成

- バックアップとリカバリの構成

- Oracle Active Data Guardの実装

- MAAアドバイザを使用したOracleベスト・プラクティスの実装と高可用性アーキテクチャの実現

Oracle Databaseの構成ベスト・プラクティスの詳細は、次の章を参照してください。

- 第4章「ストレージの構成」

- 第5章「Oracle Databaseの構成」

- 第6章「Oracle Clusterwareを使用したOracle Databaseの構成」

- 第7章「Oracle RACを使用したOracle Databaseの構成」

- 第9章「Oracle Data Guardの構成」

- 第8章「バックアップとリカバリの構成」

- 第10章「Oracle GoldenGateの構成」

- 第11章「高速接続フェイルオーバーの構成」

関連項目:
Oracle Enterprise Managerオンライン・ヘルプ・システムと、ドキュメント・セットは次のWebサイトで利用できます。
http://www.oracle.com/technetwork/oem/grid-control/index.html

4 ストレージの構成

この章では、管理性とパフォーマンスを維持しながらデータを保護するフォルト・トレラントなストレージ・サブシステムを構成するためのベスト・プラクティスについて説明します。これらのプラクティスは、『Oracle Database高可用性概要』に記載されているOracleデータベースのすべての高可用性アーキテクチャに適用されます。

この章には、次の項目が含まれます。

- データベース・パフォーマンス要件とストレージ容量要件の評価

- 自動ストレージ管理(Oracle ASM)を使用したデータベース・ファイルの管理

- Oracle ASMの戦略的ベスト・プラクティス

- Oracle ASMの構成ベスト・プラクティス

- Oracle ASMの運用ベスト・プラクティス

- Oracleストレージ・グリッドの使用

4.1 データベース・パフォーマンス要件とストレージ容量要件の評価

様々なアプリケーション・ワークロードを使用して、現在のデータベースのパフォーマンス要件を分類します。ターゲット・ワークロードの処理中に統計を抽出するため、開始時と終了時の統計スナップショットを収集します。ターゲット・ワークロードの例は、次のとおりです。

- 平均負荷

- ピーク負荷

- バッチ処理などのアプリケーション・ワークロード、オンライン・トランザクション処理(OLTP)、意思決定支援システム(DSS)およびレポート作成、ETL(Extraction, Transformation and Loading)

データベース・パフォーマンス要件の評価

必要な統計は、自動ワークロード・リポジトリ(AWR)・レポートを使用するか、GV$SYSSTATビューを問い合せることで収集できます。データベースのパフォーマンス要件を理解すると同時に、ストレージ・アレイのパフォーマンス性能を評価する必要があります。

ストレージの選択

パフォーマンス要件と容量要件を把握したら、要件に適合するストレージ・プラットフォームを選択します。

関連項目:
自動ワークロード・リポジトリ(AWR)と自動ワークロード・リポジトリ・レポートの生成の概要は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

4.2 自動ストレージ管理(Oracle ASM)を使用したデータベース・ファイルの管理

Oracle ASMは、特にOracleデータベース・ファイル用に構築されたファイル・システムとボリューム・マネージャの両方を垂直統合したものです。Oracle ASMにより、パフォーマンスの最適化のためにすべてのディスクをストライプ化してミラー化する(SAME)という概念が拡張される一方で、手動によるI/Oチューニングを行う必要がなくなります(データファイルのレイアウトはホット・スポットを避けるように分散されます)。Oracle ASMでは、ストレージ割当てを調整するためにデータベースを停止することなくデータベース・サイズを拡張することで、動的にデータベース環境を管理できます。また、Oracle ASMによるミラー化とストライプ化のサポートにより、低コストのモジュール型ストレージで優れたパフォーマンスと高度な可用性を実現できます。

Oracle ASMはドライブやSANの障害に対処するデータ保護を提供します。パフォーマンスはきわめて優秀で、構成や再構成のオプションは非常に柔軟性に富んでいます。Oracle ASMはすべての使用可能なドライバに対してデータを自動的に分散し、ストレージがデータベースから追加または削除された場合、透過的かつ動的にデータを再分散します。

Oracle ASMはすべてのデータベース・ファイルを管理します。最初は高速リカバリ領域のみをサポートして現在の環境にOracle ASMを段階的に導入します。

注意:
Oracle ASMを使用したホスト・ベースのミラーリングをお薦めします。

関連項目:

- Oracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- データベースの複製の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Automatic Storage Management (ASM)への移行』および『Oracle Databaseにて低コスト・ストレージ・グリッドを作成するためのベスト・プラクティス』を参照してください。
http://www.oracle.com/goto/maa

4.2.1 クラスタOracle ASMを使用したストレージ・グリッドの有効化

Grid Infrastructureはエンタープライズ・グリッド・アーキテクチャ用のインフラストラクチャを提供するソフトウェアです。クラスタの場合、このソフトウェアにはOracle Clusterwareと Oracle ASMが含まれます。

クラスタOracle ASMは、Oracleの単一インスタンス・データベースとOracle Real Application Clusters(Oracle RAC)の両方で使用できます。Oracle RAC環境では、各ノードに1つのOracle ASMインスタンスがあり、Oracle ASMインスタンスがpeer-to-peerで相互に通信します。ノード上のデータベース・インスタンスの数にかかわらず、ノードごとに必要で、またサポートされているOracle ASMインスタンスは、1つのみです。Oracle ASMインスタンスをクラスタ化することで、ストレージ・プールにフォルト・トレランス、柔軟性およびスケーラビリティが提供されます。

関連項目:
クラスタOracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.2.2 Oracle ASMインスタンス(クラスタ化されていないOracleデータベース)に対するOracle Restartの使用

Oracle Restartにより、Oracleデータベースの可用性が高まります。スタンドアロン・サーバー用のOracle Grid Infrastructureをインストールすると、Oracle ASMとOracle Restartの両方が組み込まれます。Oracle Restartは、Oracle Databaseホームとは別にインストールするOracle Grid Infrastructureホームから実行されます。

Oracle Restartでは、単一インスタンスの(クラスタ化されていない)Oracle Database、Oracle ASMインスタンス、サービス、リスナー、およびサーバー上で実行されているその他のプロセスの起動および再起動が管理されます。ハードウェア障害またはソフトウェア障害後にサービスの割込みが発生すると、Oracle Restartは自動的にコンポーネントを再起動するために必要な処置を取ります。

サーバー制御ユーティリティ(SRVCTL)を使用すると、Oracle ASMインスタンスなどのコンポーネントをOracle Restartに追加できます。次に、Oracle ASMインスタンスに対してOracle Restart保護を有効にします。SRVCTLを使用して、Oracle Restart保護の削除または無効化も行います。

関連項目:

- Oracle Restartの詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle Restartの使用方法の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.3 Oracle ASMの戦略的ベスト・プラクティス

次のようなOracle ASMの戦略的ベスト・プラクティスを使用します。

- ディスクおよびディスク・グループの簡易構成の使用

- 冗長性を使用したディスク障害からの保護

- Grid InfrastructureホームのOracle ASM

- 同一ディスク・グループ内のディスクへの同じ特性の割当て

- Oracle ASMの冗長性を使用する際の障害グループの使用

- インテリジェント・データ配置の使用

- Oracle ACFSを使用したデータベース外部のファイルの管理

4.3.1 ディスクおよびディスク・グループの簡易構成の使用

ミッション・クリティカルなアプリケーションには、Oracleの高冗長性ディスク・グループ(3通りのミラー化)か、または同等のミラー化復元性を備える外部冗長性ディスク・グループを使用することをお薦めします。この高レベルのミラー化によって、保護レベルが向上し、各種のストレージ障害の許容度も上がります。これは特に、ストレージのサブセットがパッチ適用またはアップグレードのためにオフラインになっている際の計画済メンテナンス・ウィンドウにおいて実現されます。冗長性の詳細は、第4章「冗長性を使用したディスク障害からの保護」を参照してください。

データベース記憶域にOracle ASMを使用する場合、2つのディスク・グループ(データ領域用のディスク・グループと高速リカバリ領域用のディスク・グループ)を作成します。

- データ領域: Oracle ASM冗長性のレベルに応じて、アクティブなデータベース・ファイルおよびその他のファイルが含まれます。Oracle ASMの高冗長性が使用されている場合、データ領域には、OCR、投票、SPFILE、制御ファイル、オンラインREDOログ・ファイル、スタンバイREDOログ・ファイル、ブローカ・メタデータファイル、およびRMANの増分バックアップに使用される変更トラッキング・ファイルなども含まれます。
例(高冗長性の場合):

CREATE DISKGROUP data HIGH REDUNDANCY
FAILGROUP controller1 DISK
'/devices/c1data01' NAME c1data01,\
'/devices/c1data02' NAME c1data02
FAILGROUP controller2 DISK
'/devices/c2data01' NAME c2data01,
'/devices/c2data02' NAME c2data02
FAILGROUP controller3 DISK
'/devices/c3data01' NAME c3data01,
'/devices/c3data02' NAME c3data02
ATTRIBUTE 'au_size'='4M',
'compatible.asm'  = '11.2',
'compatible.rdbms'= '11.2',
'compatible.advm' = '11.2';

- 高速リカバリ領域: 現在の制御ファイルのコピー、各オンラインREDOログ・ファイル・グループのメンバー、アーカイブREDOログ・ファイル、RMANバックアップ、およびフラッシュバック・ログ・ファイルなどのリカバリ関連ファイルが含まれています。
例(通常の冗長性の場合):

CREATE DISKGROUP reco NORMAL REDUNDANCY
FAILGROUP controller1 DISK
'/devices/c1reco01' NAME c1reco01,
'/devices/c1reco02' NAME c1reco02
FAILGROUP controller2 DISK
'/devices/c2reco01' NAME c2reco01,
'/devices/c2reco02' NAME c2reco02
ATTRIBUTE 'au_size'='4M',
'compatible.asm'  = '11.2',
'compatible.rdbms'= '11.2',
'compatible.advm' = '11.2';

注意1:
Linux環境でASMLibを使用する場合、次のようにORACLEASM CREATEDISKコマンドを使用してディスクを作成します。ASMLibはOracle ASMのサポート・ライブラリで、すべてのプラットフォームでサポートされているわけではありません。ASMLibの詳細は、4.4.6項「ASMLibのサポート対象プラットフォームでの使用」を参照してください。
たとえば、次のようになります。

/etc/init.d/oracleasm createdisk lun1 /devices/lun01

次に、ディスク・グループを作成します。たとえば、次のようになります。

CREATE DISKGROUP DATA DISK
'ORCL:lun01','ORCL:lun02','ORCL:lun03','ORCL:lun04';

注意2:
各ディスク・グループでは4つ以上のディスクを使用することをお薦めします。各ディスク・グループに複数のディスクがあると、同じディスクにアクセスまたは問合せを行うカーネル競合を拡散できます。

ファイル管理を簡略化するには、Oracle Managed Filesを使用してファイルの命名作業を制御します。初期化パラメータのDB_CREATE_FILE_DESTおよびDB_CREATE_ONLINE_LOG_DEST_nを設定することで、Oracle Managed Filesを有効化します。

たとえば、次のようになります。

DB_CREATE_FILE_DEST=+DATA
DB_CREATE_ONLINE_LOG_DEST_1=+RECO

Oracle ASMで使用するためにディスクをパーティション化する場合、次の2つのオプションがあります。

- 複数のディスク全体をデータ領域のディスク・グループと高速リカバリ領域のディスク・グループに割り当てます。図4-1は、ディスク全体を割り当てる方法を示しています。

- 各ディスクを2つのパーティションに分割し、1つをデータ領域に、もう1つを高速リカバリ領域に割り当てます。図4-2は、各ディスクの2つのパーティションへのパーティション化を示しています。

図4-1 ディスク全体の割当て

図4-1に示されるオプションのメリットは次のとおりです。

- 各ディスクを1つの大きなパーティションとして分割しているため、オペレーティング・システム・レベルでディスク・パーティションを管理することが容易です。

- ディスク障害後のOracle ASMによるリバランス操作が、1つのディスク・グループのみをリバランスすればよいため、迅速に完了します。

- 障害の分離。これによって、ストレージ障害では影響を受けるディスク・グループのみがオフラインになります。

- パッチ適用の分離。これによって、すべてのディスクに適用しなくても、各ディスクや、個々のディスクのファームウェアにパッチを適用できます。

図4-1に示されるオプションのデメリットは次のとおりです。

- 各ディスク・グループが使用可能なディスクのサブセットに単純に分散されるため、I/O帯域幅が小さくなります。

図4-2は、各ディスクに2つのパーティションが存在するパーティション化オプションを示しています。このオプションでは各ディスクを2つのパーティションに分割する必要があります。各ドライブの高速な外側部分にある小さいパーティションをデータ領域用とし、各ドライブの低速な内側部分にある大きいパーティションを高速リカバリ領域用とします。内側のパーティション・サイズと外側のパーティション・サイズの割合は、データ領域と高速リカバリ領域の推定サイズに応じて変化します。

図4-2 各ディスクのパーティション化

図4-2に示されるパーティション化のオプションのメリットは次のとおりです。

- パフォーマンスおよびスケーラビリティの点で、柔軟性と管理性が向上します。

- 使用可能なすべてのスピンドルに両方のディスク・グループが分散されるため、使用できるI/O帯域幅が大きくなります。このメリットは、I/O集中型のアプリケーションで使用されるデータ領域用のディスク・グループでは重要です。

- I/O容量が十分である場合、オンラインREDOログまたはスタンバイREDOログに、分離された専用のストレージを持つ別個のディスク・グループを作成する必要がありません。

- ディスクの低速な部分を高速リカバリ領域に、またディスクの高速な部分をデータ領域用に使用できます。

図4-2に示されるパーティション化のオプションのデメリットは次のとおりです。

- 二重パートナ・ディスク障害が発生すると、両方のディスク・グループが失われる可能性があります。この場合、リカバリのためにスタンバイ・データベースまたはテープ・バックアップを使用する必要があります。この問題は、高冗長性のASMディスク・グループの使用時には発生しません。

- ディスク障害後のOracle ASMによるリバランス操作は、両方のディスク・グループが対象となるため、時間がかかります。

関連項目:

- ディスク、ディスク・グループおよび障害グループの概要と、通常の冗長性、高冗長性および外部冗長性の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- 高速リカバリ領域の設定とサイズ指定の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- Oracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.3.2 冗長性を使用したディスク障害からの保護

冗長性を設定してハードウェア障害から保護する場合、検討する必要のあるオプションは次の2つです。

- RAIDに基づくストレージ・アレイ

- Oracle ASMの冗長性

関連項目:

- Oracle Automatic Storage Managementの概要は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- ディスク・グループの作成については、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.3.2.1 RAIDに基づくストレージ・アレイ

堅牢な組込みRAIDソリューションを提供するハイエンドなストレージ・アレイを使用する場合、RAID1 (ミラー化)やRAID5 (ストライプ化とパリティ)などのRAID保護を有効化してストレージ・アレイで冗長性を構成することをお薦めします。たとえば、ストレージ・アレイにより冗長性が提供されるOracle ASMディスク・グループを作成するには、まずストレージ・アレイにRAIDで保護された論理ユニット番号(LUN)を作成してから、EXTERNAL REDUNDANCY句を使用して次のようにOracle ASMディスク・グループを作成します。

CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK
'/devices/lun1','/devices/lun2','/devices/lun3','/devices/lun4';

関連項目:

- Oracle ASMのミラー化およびディスク・グループ冗長性の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- ディスク・グループの作成の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

4.3.2.2 Oracle ASMの冗長性

Oracle ASM では、障害グループを使用した冗長性が提供されます(障害グループはディスク・グループ作成時に定義します)。ディスク・グループのタイプによって、Oracle ASMのファイルのミラー化の方法が決定されます。ディスク・グループを作成するとき、そのディスク・グループが 通常の冗長性 ディスク・グループ(デフォルトによる2通りのミラー化)か、 高冗長性 ディスク・グループ(3通りのミラー化)か、または 外部冗長性 ディスク・グループ(Oracle ASMによるミラー化なし)かを指示します。ストレージ・システムがハードウェア・レベルでミラー化されているか、または冗長データを必要としない場合は、外部冗長性ディスク・グループを使用します。デフォルトのディスク・グループ・タイプは、通常の冗長性です。ディスク・グループが作成された後で冗長性レベルを変更することはできません。

障害グループの定義は、各ストレージ設定に固有ですが、次のガイドラインに従う必要があります。

- ディスクのマルチパス・ソフトウェアを使用している場合のように、すべてのI/Oパスを通じてすべてのディスクを使用できる場合、各ディスクはそれぞれ独自の障害グループに残します。これは、障害グループを明示的に定義せずにディスク・グループを作成する場合のOracle ASMのデフォルト動作です。

CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK
'/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4',
'/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

- 2つのコントローラの両方ですべてのディスクを認識しているアレイの場合、各ディスクがそれぞれ独自の障害グループに含まれるディスク・グループを作成します。

CREATE DISKGROUP DATA NORMAL REDUNDANCY
DISK
'/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4',
'/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

- すべてのI/Oパスを通じてすべてのディスクを使用できない場合、障害が懸念されるハードウェアの構成部分から保護するために障害グループを定義します。次に、いくつかの例を示します。

- 2つのコントローラでそれぞれドライブ全体の半分のみを認識しているアレイの場合、コントローラ障害から保護するため、各コントローラに対応する2つの障害グループを持つディスク・グループを作成します。

CREATE DISKGROUP DATA NORMAL REDUNDANCY
FAILGROUP controller1 DISK
'/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4'
FAILGROUP controller2 DISK
'/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

- 複数のストレージ・アレイを備えたストレージ・ネットワークでストレージ・アレイ全体にわたりミラー化を行う場合、アレイ障害から保護するため、各アレイに対応する2つの障害グループを持つディスク・グループを作成します。

CREATE DISKGROUP DATA NORMAL REDUNDANCY
FAILGROUP array1 DISK
'/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4'
FAILGROUP array2 DISK
'/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

Oracle ASMによる冗長性で保護されるディスク・グループの適切なサイズを決定する場合、ディスク・グループには十分な空き領域が存在する必要があります。これは、ディスク障害が発生した場合に、データベースをオンラインに維持したまま、障害ドライブの内容をディスク・グループ内の別のドライブに自動的に再構築できるようにするためです。ディスク障害後にOracle ASMで冗長性を回復するのに必要な領域の容量は、V$ASM_DISKGROUPビューのREQUIRED_MIRROR_FREE_MB列で確認できます。ミラー化を考慮しながらディスク・グループで安全に使用できるとともに、ディスク障害後に冗長性を回復できる空き領域の容量は、V$ASM_DISKGROUPビューのUSABLE_FILE_MB列で確認できます。USABLE_FILE_MB列の値は、常に0(ゼロ)を超えている必要があります。USABLE_FILE_MBが0(ゼロ)未満の場合、ディスク・グループに別のディスクを追加します。

関連項目:
ディスク・グループの作成の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

4.3.3 Grid InfrastructureホームのOracle ASM

Oracle Automatic Storage Management (Oracle ASM)およびOracle Clusterwareは、Gridホームと呼ばれる単一のホーム・ディレクトリにインストールされます。クラスタ・ソフトウェア用のOracle Grid Infrastructureは、組み合された製品のインストールを参照します。Gridホームは、同じサーバー上にインストールされている他のOracleソフトウェア製品のホーム・ディレクトリとは異なります。

関連項目:
Oracle ASMおよびGridホームの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

4.3.4 同一ディスク・グループ内のディスクへの同じ特性の割当て

同一ディスク・グループ内のすべてのディスクに同じサイズとパフォーマンス特性を割り当てる必要はありませんが、そうすることで全体的なパフォーマンスおよび領域使用率が予測しやすくなります。可能であれば、Oracle ASMに対して、ディスクとOracle ASM間に抽象化レイヤーを作成する論理ユニット番号(LUN)ではなく、物理ディスク(スピンドル)を割り当てます。

ディスクが同じサイズであると、Oracle ASMはディスク・グループのすべてのディスクに均等にファイルを分散できます。この割当てパターンでは、すべてのディスクが同じ容量レベルに維持されるため、ディスク・グループのすべてのディスクに同じI/O負荷が割り当てられます。Oracle ASMは、ディスク・グループのすべてのディスク間でワークロードを負荷分散するため、異なるOracle ASMディスクで同じ物理ドライブを共有することはできません。

関連項目:
Oracle ASMディスク・グループの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.3.5 Oracle ASMの冗長性を使用する際の障害グループの使用

障害グループを使用して共通障害コンポーネントを定義することで、そのコンポーネントに障害が発生してもデータに継続的にアクセスできます。保護を最大化する場合、標準冗長性では最低3つの障害グループを使用し、高冗長性では最低5つの障害グループを使用します。これにより、Oracle ASMでは、障害グループの複数の障害に対応でき、完全な冗長性なしでOracle ASMが稼働する混乱状態を回避できます。

注意:
冗長性機能が組み込まれたハイエンドなストレージ・アレイを購入済の場合、オプションとしてベンダーによるそれらの機能を使用してミラー化保護機能を実行し、Oracle ASMディスク・グループを外部冗長性に設定します。同じように、低コストのストレージおよびExadataストレージでは、Oracle ASMの標準冗長性または高冗長性を使用します。

4.3.6 インテリジェント・データ配置の使用

インテリジェント・データ配置により、最高のパフォーマンスを実現するためにOracle ASMディスク上のディスク・リージョンを指定できます。ディスク・リージョン設定を使用すると、アクセス頻度の高いデータを、より高速でバンド幅も大きい一番外側の(ホット)トラックに確実に配置できます。また、アクセス・パターンが似ているファイルは物理的に近くに配置され、待機時間が短縮されます。異なるホット・リージョンまたはコールド・リージョンに、プライマリ・エクステントおよびミラー・エクステントを配置することもできます。

関連項目:
インテリジェント・データ配置の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.3.7 Oracle ACFSを使用したデータベース外部のファイルの管理

Oracle Automatic Storage Management クラスタ・ファイル・システム(Oracle ACFS)は、マルチプラットフォームのスケーラブル・ファイル・システムであり、Oracle Automatic Storage Management (Oracle ASM)機能を拡張して、Oracle Databaseの外部で保持されているカスタマ・ファイルをサポートするストレージ管理テクノロジです。Oracle ACFSにはボリューム管理サービスが含まれ、詳細なセキュリティ・ポリシー、暗号化、スナップショットおよびレプリケーション機能があります。

Oracle ACFSでは、実行可能ファイル、データベース・トレース・ファイル、データベース・アラート・ログ、アプリケーション・レポート、BFILE、構成ファイルなど、様々なデータベース・ファイルおよびアプリケーション・ファイルがサポートされます。サポートされるその他のファイルは、ビデオ、オーディオ、テキスト、イメージ、設計図およびその他の汎用アプリケーション・ファイル・データです。

注意:
Oracleデータベース・バイナリはOracle ACFSに配置できますが、Grid Infrastructureホーム内のバイナリではありません。

関連項目:
Oracle ACFSの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.4 Oracle ASMの構成ベスト・プラクティス

次のようなOracle ASMの構成ベスト・プラクティスを使用します。

- ディスクのマルチパス・ソフトウェアを使用したパス障害からの保護

- SGA_TARGETおよびPGA_AGGREGATE_TARGETパラメータを使用した自動共有メモリー管理の使用

- PROCESSES初期化パラメータの設定

- ディスク・ラベルの使用

- DISK_REPAIR_TIMEディスク・グループ属性の適切な設定

- ASMLibのサポート対象プラットフォームでの使用

4.4.1 ディスクのマルチパス・ソフトウェアを使用したパス障害からの保護

ディスクのマルチパス・ソフトウェアでは、複数の独立したI/Oパスを単一の論理パスに集約します。パスの抽象化により、ホスト・バス・アダプタ(HBA)全体にわたるI/Oのロード・バランシングが実現し、I/Oパスの障害時には無停止のままフェイルオーバーが実行されます。ディスクのマルチパス・ソフトウェアは、Oracle ASMとともに使用してください。

Oracle ASMでのディスク・グループ作成時にディスク名を指定するときに、単一の論理パスを表す論理デバイスを使用します。たとえば、Linux 2.6でデバイス・マッパーを使用する場合、/dev/dm-0の論理デバイス・パスで物理ディスク/dev/sdcおよび/dev/sdhを集約できます。Oracle ASM内では、論理デバイス/dev/dm-0を検出するためにASM_DISKSTRINGパラメータに/dev/dm-*を含め、ディスク・グループ作成時にその論理デバイスを使用する必要があります。

asm_diskstring='/dev/dm-*'

CREATE DISKGROUP DATA DISK
'/dev/dm-0','/dev/dm-1','/dev/dm-2','/dev/dm-3';

注意:
ASMLibとマルチパス・ディスクの組合せの使用の詳細は、次のWebサイトのMy Oracle Support Note 309815.1の『マルチパス・ディスクでのOracle ASMLibの構成』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=309815.1

関連項目:

- Oracle ASMとマルチパスの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- 詳細は、次のWebサイトのMy Oracle Support Note 294869.1の『Oracle ASMとマルチパス・テクノロジ』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=294869.1

4.4.2 SGA_TARGETおよびPGA_AGGREGATE_TARGETパラメータを使用した自動共有メモリー管理の使用

自動共有メモリー管理(ASSM)機能を使用してASMプロセスのメモリーを管理するために、Oracle ASMインスタンスのSGA_TARGETおよびPGA_AGGREGATE_TARGET初期化パラメータを使用します。

自動共有メモリー管理を使用するには、MEMORY_TARGETおよびMEMORY_MAX_TARGETの値を0に設定する必要があります。

注意:
Linux環境では、ASMプロセスのメモリーにHugePagesを使用することをお薦めします。HugePagesの実装方法の詳細は、My Oracle Supportのノート361468.1および401749.1を参照してください。

関連項目:
Oracle ASMにおけるメモリー関連の初期化パラメータの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.4.3 PROCESSES初期化パラメータの設定

PROCESSES初期化パラメータはOracle ASMに影響しますが、ほとんどの場合、デフォルト値が適しています。ただし、複数のデータベース・インスタンスが1つのOracle ASMインスタンスに接続している場合、次の式を使用できます。

ノードごとのインスタンス数が10を下回る場合

ノードごとのインスタンス数が10を上回る場合

PROCESSES = 50 * (n + 1)

PROCESSES = 50 * MIN (n + 1, 11) + 10 * MAX (n - 10, 0)

ここで、nはOracle ASMインスタンスに接続しているデータベース・インスタンスの数です。

関連項目:

- Oracle ASMパラメータ設定の推奨事項の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- PROCESSES初期化パラメータの設定の詳細は、『Oracle Database管理者ガイド』を参照してください。

- PROCESSESパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

4.4.4 ディスク・ラベルの使用

ディスク・ラベルにより、再起動を行ってもディスクへの一貫性のあるアクセスが可能になります。ASMLibは、ディスク・ラベル作成のための推奨ツールです。ASMLibの詳細は、4.4.6項「ASMLibのサポート対象プラットフォームでの使用」を参照してください。

4.4.5 DISK_REPAIR_TIMEディスク・グループ属性の適切な設定

DISK_REPAIR_TIMEディスク・グループ属性では、Oracle ASMでディスクを削除するまでにそのディスクをオフラインのままにしておく期間を指定します。DISK_REPAIR_TIMEパラメータの期限前にディスクを使用可能にする場合、ストレージ管理者は、ONLINE DISKコマンドを発行できます。Oracle ASMでは、ミラー側から失効データが再同期されます。Oracle Database 11gでは、ディスクが稼働中のインスタンスに障害が発生しても、オンライン・ディスク操作は再起動されないことに注意してください。ディスクをオンラインにするには、手動でコマンドを再発行する必要があります。

ディスク修復時間属性をディスク・グループに対して設定することで、オフライン状態がどれくらい続いた場合にディスクを削除するかを指定することができます。環境に適した設定は、典型的な種類の一時的障害がどれくらいの間、持続すると予想されるかによって異なります。

DISK_REPAIR_TIMEディスク・グループ属性には、ディスクが稼働していないと確実にみなせるまでの最大期間を設定してください。

関連項目:
一時的なディスク・パス障害後にOracle ASMディスク・グループの冗長性をリストアする方法の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.4.6 ASMLibのサポート対象プラットフォームでの使用

管理性を向上するため、プラットフォーム上で使用可能な場合にはASMLibを使用してください。ASMLibはOracle ASMのサポート・ライブラリです。

ASMLibはOracle ASMの実行に必要ありませんが、ASMLibを使用すると次のメリットがあります。

- すべてのOracleプロセスでOracle ASMディスクごとにファイル記述子をオープンする必要がなくなるため、システム・リソースの使用率が向上します。

- ディスク・デバイス名の管理が容易になり、検出プロセスが簡単になると同時に、あるノードに追加されたディスクがクラスタ内の他のノードに認識されないといった問題を回避できます。

- システムの再起動時にディスク・デバイス名のマッピングが変化する場合にその影響を回避できます。

注意:
ASMLibはすべてのプラットフォームでサポートされているわけではありません。

関連項目:

- ASMLibのインストールの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

- 次のOracle ASMLib Webサイト
http://www.oracle.com/technetwork/topics/linux/asmlib/index-101839.html

4.5 Oracle ASMの運用ベスト・プラクティス

次のようなOracle ASMの運用ベスト・プラクティスを使用します。

- Oracle ASM認証でのSYSASMの使用

- サービス・レベルに影響しない最大限のリバランスの設定

- 単一のコマンドを使用した複数のディスク・グループのマウント

- 単一のコマンドを使用したストレージの追加または削除

- ディスク・グループの不均衡のチェック

- ディスク・エラーに備えたベンダー・ログの予防的なマイニング

- ASMCMDユーティリティを使用したOracle ASMの管理性の簡略化

- Oracle ASMコンフィギュレーション・アシスタント(ASMCA)の使用

4.5.1 Oracle ASM認証でのSYSASMの使用

Oracle ASMインスタンスは、SYSASMと呼ばれる権限ロールで管理され、これによりOracle ASMディスク・グループへの完全なアクセスが付与されます。SYSASMを使用すると、ストレージ管理者とデータベース管理者の認証を分離できます。Oracle ASM認証用の個別のオペレーティング・システム・グループを構成することで、Oracle ASMインスタンスに対するSYSASMアクセス権を保持し、データベース・インスタンスに対するSYSDBAアクセス権を保持しないユーザーを確保できます。

関連項目:
Oracle ASMインスタンスにアクセスするための認証の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.5.2 サービス・レベルに影響しない最大限のリバランスの設定

Oracle ASMのリバランス能力の限界を上げると、リバランス操作をより高速に実行できますが、同時にアプリケーション・サービス・レベルに影響する可能性があります。能力値を低く抑えると、リバランス操作の時間はかかりますが、データベースなどの他のアプリケーションにより共有される処理リソースとI/Oリソースの消費は少なくて済みます。

計画済メンテナンス(たとえばストレージの追加や削除)を実行したら、続いてリバランスを実行し、データをすべてのディスクに再分散する必要があります。リバランスには能力の限界があります。最大能力を設定して、リバランスを実行するプロセス数を指定することができます。アプリケーションがリバランスによる影響を受けないようにするには、最大能力を低く設定します。リバランスを最小限の時間で完了するには、最大能力を高く設定します。リバランスのデフォルトの最大能力を知るには、Oracle ASMインスタンスのASM_POWER_LIMIT初期化パラメータの値をチェックします。

POWER句がALTER DISKGROUP文に指定されていない場合、またはディスクの追加や削除を行うとリバランスが暗黙的に実行される場合、リバランス能力はデフォルトでASM_POWER_LIMIT初期化パラメータの値に設定されます。このパラメータの値は動的に調整できます。

関連項目:
Oracle ASMディスク・グループのリバランスの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.5.3 単一のコマンドを使用した複数のディスク・グループのマウント

同じコマンドで複数のディスク・グループをマウントすると、ディスク検出の実行が1回のみで済むため、パフォーマンスが向上します。ASM_DISKGROUPS初期化パラメータで指定したディスク・グループは、Oracle ASMインスタンスの起動時に自動的にマウントされます。

手動でディスク・グループをマウントするには、次のようにALTER DISKGROUP...MOUNT文でALLキーワードを指定します。

ALTER DISKGROUP ALL MOUNT;

注意:
ALTER DISKGROUP...MOUNTコマンドは1つのノードのみで機能します。クラスタ・インストールの場合は次のコマンドを使用します。

srvctl start diskgroup -g

関連項目:
ディスク・グループのマウントおよびマウント解除の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.5.4 単一のコマンドを使用したストレージの追加または削除

Oracle ASMでは、データベースの稼働中にディスク・ストレージ・システムを対象にディスクを追加または削除できます。ディスク・グループにディスクを追加すると、Oracle ASMによりデータが自動的に再分散され、ディスク・グループ内で新規ディスクも含むすべてのディスクに均等に分散されます。新たに追加したディスクにもデータが分散されるようにデータの再分散を行うプロセスはリバランスと呼ばれます。同じコマンドでストレージ・メンテナンス・コマンドを実行すると、必要なリバランス操作は1回のみで済むため、データベース・パフォーマンスに与える影響を最小限に抑えることができます。

関連項目:
ディスク・グループの変更の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.5.5 ディスク・グループの不均衡のチェック

定期的にディスク・グループの不均衡をチェックする必要があります。リバランス操作に失敗するなど、特定の操作に失敗すると、ディスク・グループは不均衡な状態になることがあります。定期的にディスク・グループのバランスをチェックし、必要に応じて手動でリバランス操作を行うことで、Oracle ASMの領域使用率とパフォーマンスを最適化してください。

次の方法で、ディスク・グループの不均衡をチェックします。

- マウントされているすべてのディスク・グループの不均衡をチェックするには、次のWebサイトのMy Oracle Support Note 367445.1の『マウントされているすべてのディスク・グループの不均衡の割合をレポートするスクリプト』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=367445.1

- I/O面の不均衡をチェックするには、大規模なSQL*Plus文を使用する前に、V$ASM_DISK_IOSTATビューで統計を問い合せます。たとえば、読取りI/Oのみを実行する大規模な問合せを実行する場合は、READS列およびBYTES_READ列は、ディスク・グループ内のすべてのディスクで、ほぼ同じである必要があります。

4.5.6 ディスク・エラーに備えたベンダー・ログの予防的なマイニング

ディスク・エラーに備えてベンダー・ログを予防的にマイニングし、Oracle ASMでデータを不良ディスク・スポットから移動する必要があります。ディスク・ベンダーは、通常、メディア検出エラーなど、ディスクの一部に問題が発生した場合にユーザーに通知するディスク・スクラブ・ユーティリティを提供しています。問題が検出された場合、ASMCMDユーティリティのREMAPコマンドを使用して、Oracle ASMエクステントを不良スポットから正常スポットに移動します。

この処理は、データベース・インスタンスまたはOracle ASMインスタンスにアクセスされないデータにのみ適用されることに注意してください。アクセスされるデータの場合、メディア検出エラーが発生したエクステントは、Oracle ASMによって自動的に同じディスク上の別の場所に移動されるためです。つまり、ASMCMDユーティリティのREMAPコマンドを使用してデータを予防的に不良ディスク・スポットから正常ディスク・スポットに移動する操作は、そのデータがアプリケーションによりアクセスされる前に行います。

関連項目:
ASMCMDユーティリティの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.5.7 ASMCMDユーティリティを使用したOracle ASMの管理性の簡略化

ASMCMDユーティリティを使用して、日常のストレージ制御作業の管理性を簡略化します。ASMCMDユーティリティを使用すると、Oracle ASMディスク・グループ内のファイルやディレクトリの表示および操作、ディスク・グループの内容のリスト、検索の実行、ディレクトリやエイリアスの作成と削除、領域使用率の表示などを行うことができます。また、ディスク・グループのメタデータのバックアップおよびリストアにもASMCMDユーティリティを使用できます(md_backupコマンドおよびmd_restoreコマンドをそれぞれ使用します)。

注意:
Oracle ASMディスク・グループを作成および削除するためのベスト・プラクティスでは、SQL*Plus、ASMCAまたはOracle Enterprise Managerを使用します。

関連項目:
ASMCMDディスク・グループ管理コマンドの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

4.5.8 Oracle ASMコンフィギュレーション・アシスタント(ASMCA)の使用

Oracle ASMコンフィギュレーション・アシスタント(ASMCA)は、Oracle ASMインスタンス、ディスク・グループ、ボリュームおよびOracle Automatic Storage Management クラスタ・ファイル・システム(Oracle ACFS)のインストールと構成を支援します。また、ASMCAコマンドライン・インタフェースをサイレント・モード・ユーティリティとして使用できます。

関連項目:
『Oracle Automatic Storage Management管理者ガイド』

4.6 Oracleストレージ・グリッドの使用

Oracleストレージ・グリッドは次のいずれかで構成されます。

- Oracle ASMと、外部冗長性を使用するサード・パーティのストレージ。

- Oracle ASMと、Oracle ASM冗長性を使用するOracle Exadataまたはサード・パーティのストレージ。Exadataを使用するOracleストレージ・グリッドは、MAA関連テクノロジをシームレスにサポートし、パフォーマンスを改善し、無制限のI/Oスケーラビリティを提供し、使用も管理も容易で、ミッション・クリティカルな可用性と信頼性を実現します。

関連項目:
『Oracle Automatic Storage Management管理者ガイド』

4.6.1 計画外の停止に関するOracleストレージ・グリッドのベスト・プラクティス

計画外の停止からストレージを保護するには、次のことを行います。

- DB_BLOCK_CHECKSUM初期化パラメータを、TYPICAL(デフォルト)またはFULLに設定します。詳細は、9.3.8.3項「DB_BLOCK_CHECKSUM=FULLおよびDB_BLOCK_CHECKING=MEDIUMまたはFULLの設定」を参照してください。

注意:
Oracle Exadata Database Machineは、Hardware Assisted Resilient Data (HARD)テクノロジをそのソフトウェアに組み込むことで、破損がディスクに書き込まれることも防ぎます。HARDは、ストレージ・サブシステムでOracleブロックの内容を検証するブロック・チェックを使用するため、破損データがディスクに書き込まれるのを防ぐことができます。Oracle ExadataにおけるHARDチェックは完全に透過的に行われ、この目的のためにパラメータをデータベース層またはストレージ層に設定する必要はありません。詳細は、次のWebサイトでホワイト・ペーパー『Oracle Database 11gによるストレージの最適化とデータの保護』を参照してください。
http://www.oracle.com/us/products/database/database-11g-managing-storage-wp-354099.pdf

- 必要な保護レベルと能力要件に基づいて、Oracle ASM冗長性のタイプを選択します(NORMALまたはHIGH)。
NORMAL設定では2つのOracle ASMエクステントが保存されますが、HIGH設定では3つのOracle ASMエクステントが保存されます。標準冗長性を使用すると使用できる容量が増え、高冗長性にすると保護がより高度になります。

- 1つ以上のデータベースの実行中にストレージ・コンポーネントをオフラインにする場合、ストレージ・コンポーネントのオフラインによるOracle ASMディスク・グループおよびデータベース可用性への影響がないことを確認してください。障害グループの削除、またはストレージ・コンポーネントのオフライン化を行う前に、適切なチェックを実行します。

- 停止後にI/Oパフォーマンスが維持されることを確認します。
障害が発生しても、品質保証契約(SLA)を維持できるだけのI/O帯域幅があることを確認します。たとえば、n個のストレージ・コンポーネントを持つストレージ・グリッドの場合に、n-1個のストレージ・コンポーネントでも、(たとえば、ストレージ・コンポーネント障害を処理するために)アプリケーション・サービス・レベルを確実に維持できるようにしておくという手法がよく採用されています。

4.6.2 計画済のメンテナンスに関するOracleストレージ・グリッドのベスト・プラクティス

計画済のメンテナンスのベスト・プラクティスを、次のリストに示します。

- I/Oのサイズは、先にパフォーマンスに合せて設定し、その後で容量に合せて設定します。
Oracleストレージ・グリッドを構築する場合、品質保証要件に適合する、1秒当たりのI/OとMB数をサポートできるだけのドライブがあることを確認します。その後で、十分な容量があることを確認します。容量に見合った量のドライブを購入した後で、そのシステムではパフォーマンス要件に適合しないことが判明すると困るので、この順序は重要です。

サイズ指定をする際は、計画済メンテナンスのためにストレージのサブセットをオフラインにした場合のパフォーマンスへの影響を考慮する必要があります。たとえば、ストレージ全体のサブセットがオフラインになった場合でも、SLAの準拠にとって重要ならば必要な数のIOPSを得られるようにしておく必要があります。また、ストレージのオフライン化によってシステムへのデータベースの追加ができなくなる場合は、そのことを前もって検討しておく必要があります。

- Oracle ASMの最大能力を高速なリバランスに設定します。 詳細は、4.5.2項「サービス・レベルに影響しない最大限のリバランスの設定」を参照してください。

関連項目:

- ASM_POWER_LIMIT初期化パラメータの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- リバランス操作のチューニングの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- ASM_POWER_LIMIT初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

5 Oracle Databaseの構成

この章では、単一インスタンス、Oracle RACデータベース、Oracle RAC One Nodeデータベース、Oracle Data Guard構成のプライマリ・データベースおよびスタンバイ・データベースなどの、すべてのOracleデータベースを構成するためのベスト・プラクティスを説明します(高可用性アーキテクチャの詳細は、『Oracle Database高可用性概要』を参照してください)。停止時間の削減または回避、破損リスクの低減、およびリカバリ・パフォーマンスの向上を図るには、これらのベスト・プラクティスを採用します。

この章には、次の項目が含まれます。

- データベース構成の高可用性および高速リカバリのベスト・プラクティス

- 管理性向上のための推奨事項

関連項目:
高可用性アーキテクチャの詳細は、『Oracle Database高可用性概要』を参照してください。

5.1 データベース構成の高可用性および高速リカバリのベスト・プラクティス

リカバリ時間を短縮し、データベースの可用性と冗長性を向上するには、次のことを行います。

- データベースのARCHIVELOGモードおよびFORCE LOGGINGモードの設定

- REDOログ・ファイルおよびグループの適切なサイズ構成

- 高速リカバリ領域の使用

- フラッシュバック・データベースの有効化

- FAST START MTTR TARGET初期化パラメータの設定

- データ破損の防止

- DISK_ASYNCH_IO初期化パラメータの設定

- LOG_BUFFER初期化パラメータを8MB以上に設定

- 自動共有メモリー管理の使用およびメモリー・ページングの回避

- インスタンス・リカバリのためのパラレル・リカバリの無効化

5.1.1 データベースのARCHIVELOGモードおよびFORCE LOGGINGモードの設定

データベースのARCHIVELOGモードでの実行とデータベースのFORCE LOGGINGモードの使用は、データベースのリカバリ操作のための前提条件です。ARCHIVELOGモードでは、オンラインでのデータベース・バックアップが可能です。リストアされている時点より後の時点にデータベースをリカバリするには、このモードで運用する必要があります。Oracle Data Guardやフラッシュバック・データベースなどの機能を使用する場合、本番データベースはARCHIVELOGモードで実行する必要があります。

特定の表領域内でリカバリの必要がないデータを分離できる場合は、データベースのFORCE LOGGINGモードのかわりに、表領域レベルのFORCE LOGGING属性を使用できます。

関連項目:

- アーカイブ・モードの制御の詳細は、『Oracle Database管理者ガイド』を参照してください。

- FORCE LOGGINGモードの指定の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 次のWebサイトでExadata Database MachineのMAAベスト・プラクティスのエリアから、テクニカル・ホワイト・ペーパー『Oracle Data Guard: Oracle Exadata Database Machineの障害回復』のETL作業中のオーバーヘッドおよびREDOボリュームの削減に関する項を参照してください。
http://www.oracle.com/goto/maa

5.1.2 REDOログ・ファイルおよびグループの適切なサイズ構成

Oracleログの多重化を使用して、データ領域および高速リカバリ領域の各REDOグループに複数のREDOログ・メンバーを作成します(REDOログがOracle ASMの高冗長性ディスク・グループ内にない場合)。これにより、REDOログに関連する障害(いずれかのメンバーのディスク障害やI/O障害、またはオペレーティング・システム・コマンドにより間違ってメンバーを削除するといったユーザー・エラー)からデータを保護できます。少なくとも1つのREDOログ・メンバーが使用できれば、インスタンスは継続して動作できます。

REDOログのファイルおよびグループをサイズ指定するには、次のことを行います。

- ログ・スイッチ後にグループが使用可能になるのをログ・ライター・プロセス(LGWR)が待機することのないように、少なくとも3つのREDOログ・グループを使用します。

- すべてのオンラインREDOログとスタンバイREDOログは同じサイズです。

- REDOログ・サイズ = 4GB、またはREDOログ・サイズ >= ピークREDO速度 x 20分を使用します。

- REDOログを高パフォーマンス・ディスク上に置きます。

- ログ・ファイルを高冗長性のディスク・グループに配置します。または、ASM冗長性を使用中の場合、複数のログ・ファイルを様々な標準冗長性のディスク・グループに配置します。

注意:
スタンバイREDOログは多重化しないでください。

関連項目:

- 第9章「Oracle Data Guardの構成」

- REDOログの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- REDOログ・ファイルの多重化の詳細は、『Oracle Database管理者ガイド』を参照してください。

- オンライン、アーカイブおよびスタンバイREDOログ・ファイルの詳細は、『Oracle Data Guard概要および管理』を参照してください。

5.1.3 高速リカバリ領域の使用

高速リカバリ領域は、Oracleが管理するディスク領域であり、バックアップ・ファイルとリカバリ・ファイルを集中管理するためのディスク上の場所です。

高速リカバリ領域は、次のデータベース初期化パラメータを設定することで定義します。

- DB_RECOVERY_FILE_DEST: 高速リカバリ領域のデフォルトの位置を指定します。

- DB_RECOVERY_FILE_DEST_SIZE: リカバリ領域の場所に作成されるデータベースのリカバリ・ファイルで使用される合計領域に対する厳密な制限(バイト)を指定します。

『Oracle Database 2日でデータベース管理者』で説明されている推奨バックアップ計画では、リカバリのための主要な場所として、高速リカバリ領域を使用することを推奨しています。高速リカバリ領域のサイズが適切であれば、修復に必要なファイルをすぐに使用できます。推奨される最低限のディスク制限値は、データベース、増分バックアップ、テープにコピーされていないすべてのアーカイブREDOログ、およびフラッシュバック・ログの合計サイズです。

関連項目:

- 高速リカバリ領域の指定の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 高速リカバリ領域のサイズ指定および保存期間の設定の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 『Oracle Database 2日でデータベース管理者』

5.1.4 フラッシュバック・データベースの有効化

フラッシュバック・データベースは、意図と異なるデータベースの変更を元に戻すための、ポイント・イン・タイム・リカバリに代わる方法です。フラッシュバック・データベースを使用すると、データベース全体を復元して、一定期間内のデータベースの変更の影響を元に戻すことができます。影響は、データベース・ポイント・イン・タイム・リカバリ(DBPITR)と類似しています。複雑な手順を使用することなく、単一のRMANコマンドまたはSQL*Plus文を発行してデータベースをフラッシュバックできます。

フラッシュバック・データベースを有効にするには、高速リカバリ領域を構成し、フラッシュバック保存目標を設定します。この保存目標によって、フラッシュバック・データベースを使用してデータベースを巻き戻す時点が指定されます。高速リカバリ領域の指定の詳細は、5.1.3項「高速リカバリ領域の使用」を参照してください。

フラッシュバック・データベースを構成して有効化する場合、次のことを確認してください。

- フラッシュバックを有効化する前に、使用するアプリケーションのパフォーマンス・ベースラインを認識しておくと、オーバーヘッドの判断と、フラッシュバック・データベースでのチューニングにおけるアプリケーション・ワークロードの影響の評価に役立ちます。

- フラッシュバック・データベースのフラッシュバック・ログを保持するために、高速リカバリ領域が十分あることを確認します。高速リカバリ領域のサイズ指定の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。一般的な経験則では、フラッシュバック・ログ生成のサイズは、REDOログ生成のサイズと同程度になります。たとえば、DB_FLASHBACK_RETENTION_TARGETを24時間に設定し、1日に20GBのREDOがデータベースで生成される場合は、目安として20から30GBのディスク領域をフラッシュバック・ログに使用できるようにします。同じルールが保証付きリストア・ポイントにも適用されます。たとえば、毎日20GBのREDOがデータベースで生成され、保証付きリストア・ポイントが1日保持される場合は、20GBから30GBのディスク領域を割り当てます。

- 高速リカバリ領域のサイズ指定を判断するもう1つの方法は、フラッシュバック・データベースを有効化して、データベースを短時間(2、3時間)、稼働させることです。高速リカバリ領域に必要な見積もり領域サイズは、V$FLASHBACK_DATABASE_STAT.ESTIMATED_FLASHBACK_SIZEの問合せによって取得できます。

- DB_FLASHBACK_RETENTION_TARGETは目標であり、データベースを同じくらいフラッシュバックできるという保証はありませんので注意してください。フラッシュバック・ログが保存されている高速リカバリ領域で領域圧迫があるような場合は、一番過去のフラッシュバック・ログが削除される可能性があります。高速リカバリ領域の削除ルールの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。フラッシュバックのポイント・イン・タイムを保証するには、保証付きリストア・ポイントを使用する必要があります。

- Oracle Enterprise Managerの監視メトリック、「リカバリ領域空き領域(%)」を、高速リカバリ領域における領域の問題の予防的アラートに設定します。

- 高速リカバリ領域に十分なI/O帯域幅があることを確認します。自動ワークロード・リポジトリ(AWR)レポートで"FLASHBACK BUF FREE BY RVWR"待機イベントが頻繁に発生すると、一般的には、フラッシュバック・データベースにおけるI/O帯域幅が不十分です。

- フラッシュバック・データベースにメモリー内バッファ領域をさらに付与する場合は、LOG_BUFFER初期化パラメータを8MB以上に設定します。4GBを超えるSGAを備える大規模データベースの場合、LOG_BUFFERを32MBから64MBの範囲の値に設定することを想定します(LOG_BUFFERと、32ビットおよび64ビットのオペレーティング・システムでの有効値の詳細は、『Oracle Databaseリファレンス』を参照してください)。

- PARALLEL_EXECUTION_MESSAGE_SIZEパラメータを8192以上に設定します。これによって、あらゆるフラッシュバック・データベース操作のメディア・リカバリ・フェーズが向上します。

- Data Guardスタンバイ・データベースがある場合、DB_FLASHBACK_RETENTION_TARGETを常にスタンバイ・データベース上でプライマリと同じ値に設定します。DB_FLASHBACK_RETENTION_TARGET初期化パラメータを、次のいずれかの適用される条件で指定されている最大値に設定します。

- Data Guardフェイルオーバー後にフラッシュバック・データベースを利用して障害が発生したプライマリ・データベースを復元するには、ほとんどの場合、DB_FLASHBACK_RETENTION_TARGETを60 (分)以上に設定して、障害が発生したプライマリの復元を有効化します。

- 複数の停止が発生したケースを想定してください。たとえば、最初にネットワークの停止、しばらく後にプライマリ・データベースの停止が発生すると、フェイルオーバー時にプライマリ・データベースとスタンバイ・データベース間にトランスポート・ラグが生じる場合があります。このような場合は、DB_FLASHBACK_RETENTION_TARGETを、対応可能な最大トランスポート・ラグを60 (分)にプラスした合計と等しい値に設定します。これによって、障害が発生したプライマリ・データベースを、スタンバイがプライマリになったとき(プライマリ復元の要件)のSCNよりも前のSCNに必ずフラッシュバックできます。

- ユーザー・エラーまたは論理破損からの高速ポイント・イン・タイム・リカバリにフラッシュバック・データベースを使用中の場合、DB_FLASHBACK_RETENTION_TARGETを、データベースのリカバリを行う先の過去の最も遠い時間と等しい値に設定します。

- 高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- フラッシュバック・データベース操作の進捗状況は、V$SESSION_LONGOPSビューを問い合せることによって監視できます。進捗状況を監視するための問合せの例は次のとおりです。

select * from v$session_longops where opname like 'Flashback%';

- 同じポイントにフラッシュバックすることが必要な繰返しのテストについては、フラッシュバック・データベースを有効化するかわりにフラッシュバック・データベースの保証付きリストア・ポイント(GRP)を使用して、領域使用率を最小限に抑えます。

- 一般的に言って、フラッシュバック・データベースを有効化してもパフォーマンスにはほとんど影響がありません。11.2.0.2では著しいパフォーマンスの機能拡張があり、フラッシュバック・データベースを最初に有効化するときと、バッチのダイレクト・ロード中におけるオーバーヘッドがほとんど削減されます。詳細は、次のWebサイトのMy Oracle Support Note 565535.1の『フラッシュバック・データベースのベスト・プラクティスおよびパフォーマンス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=565535.1

関連項目:

- 保証付きリストア・ポイントとフラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 最適なフラッシュバック・データベース・パフォーマンスのための環境構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- Oracle Flashback Databaseおよびリストア・ポイントの構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- ロール移行後のフラッシュバック・データベースの使用の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- フラッシュバック・データベースの使用による、障害が発生したプライマリ・データベースのスタンバイ・データベースへの変換の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 自動ワークロード・リポジトリ(AWR)の使用による、データベース統計の収集の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

- メディア・リカバリのベスト・プラクティスの詳細は、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Active Data Guard 11gのベスト・プラクティス(Redo Applyのベスト・プラクティスを含む)』を参照してください。
http://www.oracle.com/goto/maa

5.1.5 FAST START MTTR TARGET初期化パラメータの設定

ファスト・スタート・リカバリ機能により、クラッシュからのリカバリに必要な時間が短縮されます。また、使用済バッファの数、および最新のREDOレコードと最後のチェックポイントとの間に生成されるREDOレコードの数を制限して、リカバリの制御および予測を行うことができます。

インスタンスのリカバリ時間を制御するには、FAST_START_MTTR_TARGET初期化パラメータを設定します。ファスト・スタート・リカバリ機能では、FAST_START_MTTR_TARGET初期化パラメータによって、インスタンス障害またはシステム障害からのリカバリ時間を簡単に構成できます。このパラメータは、リカバリ時間目標(RTO)の目標値、つまりインスタンスを起動してキャッシュ・リカバリの実行にかかる時間(秒単位)の目標値を指定します。このパラメータを設定すると、データベースはその目標を達成するために増分チェックポイントの書込みを管理します。このパラメータに現実的な値を選択した場合、選択したおおよその平均秒数内でデータベースがリカバリされます。

最初に、FAST_START_MTTR_TARGET初期化パラメータを300 (秒)、またはリカバリ時間目標(RTO)の目標値に必要な値に設定します。

ピーク負荷時のノードやインスタンスの障害などの場合の停止テストをお薦めします。

関連項目:

- インスタンス・リカバリ・パフォーマンス: ファスト・スタート・リカバリのチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- この他のベスト・プラクティスについては、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Oracle ClusterwareとOracle RACを使用した計画外停止時の可用性の最適化』を参照してください。
http://www.oracle.com/goto/maa

5.1.6 データ破損の防止

データ・ブロックは、認識されているOracleデータベース形式ではないか、または内容に内部的な一貫性がないと破損します。データ・ブロック破損は、内部のOracle制御情報やアプリケーションおよびユーザー・データにダメージを与えて、これがクリティカル・データおよびサービスの重大な損失につながる場合があります。Oracleデータベースの破損の防止、検出および修復機能は、保護対象のデータおよびトランザクションの内部知識と、包括的な高可用性ソリューションのインテリジェント統合を基に構築されています。データ破損からのリカバリの詳細は、13.2.6項「データ破損からのリカバリ」を参照してください。

破損が検出されると、OracleはData Guard、ブロック・メディア・リカバリおよびデータファイル・メディア・リカバリを提供してデータをリカバリします。人為的エラーまたはアプリケーション・エラーで引き起こされたデータベース全体の論理破損は、Oracle Flashbackテクノロジによって元に戻すことができます。ツールは論理データ構造の予防的検証にも使用できます。たとえば、SQL*Plus ANALYZE TABLE文はブロック間の破損を検出します。

関連項目:

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『ブロック破損の防止、検出および修復: Database 11g』を参照してください。
http://www.oracle.com/goto/maa

- 次のWebサイトのMy Oracle Support Note 1302539.1の『Data Guard構成における破損の検出、防止および自動修復のベスト・プラクティス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1302539.1

5.1.6.1 データ破損の拡大の防止

最も包括的なデータ破損の防止および検出を実現するには、次のことを行います。

- ブロック破損の拡大を防止するには、フィジカル・スタンバイ・データベースでOracle Data Guardを使用します。Oracle Data Guardは、データの損失および破損や、書込みの欠落からOracleデータを保護する場合に最適なソリューションです。詳細は、9.3項「Data Guardの一般構成ベスト・プラクティス」を参照してください。

- Oracleデータベースのブロック破損初期化パラメータを、Data Guardのプライマリ・データベースおよびスタンバイ・データベースで設定します。

プライマリ・データベース上の設定

スタンバイ・データベース上の設定

DB_BLOCK_CHECKSUM=FULL
DB_LOST_WRITE_PROTECT=TYPICAL
DB_BLOCK_CHECKING=FULL

DB_BLOCK_CHECKSUM=FULL
DB_LOST_WRITE_PROTECT=TYPICAL
DB_BLOCK_CHECKING=FULL

パフォーマンス・オーバーヘッドはブロック変更ごとに発生するため、パフォーマンス・テストはDB_BLOCK_CHECKINGパラメータの設定時に特に重要です。プライマリ・データベースまたはスタンバイ・データベースのいずれかで、DB_BLOCK_CHECKING=MEDIUMを最小の設定(索引ブロックではなくデータ・ブロック上のブロック・チェック)にすることを強くお薦めします。DB_BLOCK_CHECKINGをMEDIUMまたはFULLにすることを有効化するパフォーマンス・オーバーヘッドがプライマリ・データベースで許容されない場合、スタンバイ・データベースでDB_BLOCK_CHECKINGをMEDIUMまたはFULLに設定します。

注意:
これらの設定の変更時は、綿密なパフォーマンス評価が推奨されます。

関連項目:

- 9.3.8項「Data Guard Redo Applyのベスト・プラクティスの使用」

- 最新情報は、次のWebサイトのMy Oracle Support Note 1302539.1の『Data Guard構成における破損の検出、防止および自動修復のベスト・プラクティス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1302539.1

- ディスク障害からの保護にディスクのミラー化を提供する場合は、Oracle Automatic Storage Management (Oracle ASM)を使用します。詳細は、4.2項「自動ストレージ管理(Oracle ASM)を使用したデータベース・ファイルの管理」を参照してください。

- 最適な破損の修復にはOracle ASM HIGH REDUNDANCYを使用します。ディスク・グループでOracle ASM冗長性を使用すると、I/Oエラーまたは破損の発生時にミラー・エクステントをデータベースで使用できます。継続的な保護を目的として、Oracle ASMの冗長性により、I/Oエラーの発生時にエクステントをディスク上の別の領域に移動する機能を提供します。Oracle ASMによる冗長性メカニズムは、メディア検出エラーを戻す不良セクターがある場合に役立ちます。詳細は、4.3.2項「冗長性を使用したディスク障害からの保護」を参照してください。

- 自動ブロック修復にはOracle Active Data Guardオプションを使用します。Active Data Guardの詳細は、9.5項「Oracle Active Data Guardのベスト・プラクティスの使用」を参照してください。

- データ・リカバリ・アドバイザを構成し、その構成を使用してデータ障害を自動的に診断します。詳細は、5.2.2項「データ・リカバリ・アドバイザを使用したデータ障害の検出、分析および修復」を参照してください。

- (ほとんどの場合、人為的エラーによって引き起こされた)論理破損からの高速ポイント・イン・タイム・リカバリと、フェイルオーバー後のプライマリ・データベースの高速復元には、Oracle Flashbackテクノロジを有効化します。詳細は、5.1.4項「フラッシュバック・データベースの有効化」を参照してください。

- Recovery Manager (RMAN)によるバックアップおよびリカバリ計画を実装し、RMANのBACKUP VALIDATE CHECK LOGICAL...スキャンを定期的に使用して破損を検出します。詳細は、第8章「バックアップとリカバリの構成」を参照してください。バックアップおよびリストア操作中の追加的なブロック・チェックにはRMANおよびOracle Secure Backupを使用します。

5.1.6.2 データ破損の検出および監視

破損データがディスクに書き込まれた場合、または正常なデータの書込み後にコンポーネント障害によってそのデータが破損した場合は、破損したブロックをできるだけ早く検出することが重要です。

データベースのエラーおよびアラートを監視するには、次のことを行います。

- Enterprise Managerを使用して、検出されたすべてのターゲットの可用性を監視し、エラーおよびアラートを検出します。HA Consoleから1つのビューですべてのターゲットを参照することもできます。Enterprise Managerの詳細は、第12章「高可用性の監視」を参照してください。

- ブロック破損が検出または修復されると自動的に更新される、V$DATABASE_BLOCK_CORRUPTIONビューを問い合せます。

- データ・リカバリ・アドバイザを構成すると、データ障害の自動診断、適切な修復オプションの判別と提供、およびユーザー・リクエストに応じた修復操作の実行が行われます。詳細は、5.2.2項「データ・リカバリ・アドバイザを使用したデータ障害の検出、分析および修復」を参照してください。

注意:
データ・リカバリ・アドバイザはOracle Enterprise Manager Support Workbench (サポート・ワークベンチ)、 状態モニターおよびRMANと統合されています。

- Data Guardを使用して、物理破損を検出し、書込みの欠落を検出します。
Data Guardは、REDOストリームで破損ブロックのために適用プロセスが停止した場合、または書込みの欠落を検出した場合に、物理破損を検出します。Data Guard構成の管理および監視にはEnterprise Managerを使用します。自動ブロック・メディア・リカバリを利用することで、プライマリ・データベースまたはフィジカル・スタンバイ・データベースのどちらかで検出された破損ブロックは、Active Data Guardオプションが使用されていると自動的に修正できます。自動ブロック・メディア・リカバリの詳細は、13.2.6.2項「Active Data Guardの使用」を参照してください。

- SQL*Plusを使用して、データファイル破損およびブロック間破損を検出します。
ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE SQL*Plus文を発行します。破損の判別後は、表を再作成するか、他の操作を行うことができます。

関連項目:

- 13.2.6項「データ破損からのリカバリ」

- Oracle Active Data Guardオプションおよび自動ブロック修復機能の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- ブロック・メディア・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

5.1.7 DISK_ASYNCH_IO初期化パラメータの設定

ほとんどの環境で、Oracle Databaseは、非同期I/Oが使用可能で、特定のプラットフォームに対して適切であるかどうかを自動的に検出し、DISK_ASYNCH_IO初期化パラメータを通じて非同期I/Oを有効化します。ただし、パフォーマンスを最大限に向上させるには、非同期I/Oが実際に使用されていることを確認することが常にベスト・プラクティスです。V$IOSTAT_FILEビューを問い合せて、非同期I/Oが使用されているかどうか確認します。

SQL> select file_no,filetype_name,asynch_io from v$iostat_file;

非同期I/Oを明示的に有効化するには、次のようにDISK_ASYNCH_IO初期化パラメータをTRUEに設定します。

ALTER SYSTEM SET DISK_ASYNCH_IO=TRUE SCOPE=SPFILE SID='*';

Oracle ASMを使用している場合、デフォルトでI/Oが非同期に実行されていることに注意してください。

関連項目:
DISK_ASYNCH_IO初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

5.1.8 LOG_BUFFER初期化パラメータを8MB以上に設定

LOG_BUFFER初期化パラメータを8MB以上に設定します。

フラッシュバックが有効で、4GB以上のSGAを持つデータベースでは、LOG_BUFFERを64MB以上に設定します。

Oracle Data Guardの非同期REDO転送を使用し、かつREDO生成速度が20より高い値の場合、オンラインREDOログへのディスクI/Oを避けるためにLOG_BUFFERパラメータの値を増やすことが必要な場合があるため、LOG_BUFFER128MB以上に設定します。詳細は、第9章「Oracle Data Guardの構成」を参照してください。

関連項目:

- REDOログ・バッファの構成および使用の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- LOG_BUFFERと、32ビットおよび64ビットのオペレーティング・システムでの有効値の詳細は、『Oracle Databaseリファレンス』を参照してください。

- REDO転送をサポートするログ・バッファの最適なサイズの判別に、バッファ・ヒット率ヒストグラムを使用する場合の詳細は、次のWebサイトのMy Oracle Support Note 951152.1の『X$LOGBUF_READHISTとメモリー内ログ・バッファ・ヒット率ヒストグラムの表示』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=951152.1

5.1.9 自動共有メモリー管理の使用およびメモリー・ページングの回避

4GB以上のメモリーを持つシステムの場合、MEMORY_TARGET=0を設定して自動メモリー管理を無効化し、SGA_TARGETを設定して自動共有メモリー管理を有効化します。

データベース・サーバー上のSGAとPGAのメモリー割当ての合計は、常に、システムの物理メモリーより少なくする必要があり、保守的に考えると合計システム・メモリーの75%より少なくする必要があります。ただし、PGA_AGGREGATE_TARGETは厳密な制限ではなく、一部のデータ・ウェアハウスやレポーティングのアプリケーションでは、PGAメモリーをPGA_AGGREGATE_TARGETの3倍まで拡大できます。

メモリーの使用率を正確に把握するために、Oracle Enterprise Managerを使用するか、v$pgastatおよびオペレーティング・システムの統計を問い合せて、PGAメモリーとホストベースのメモリーの使用率を監視します。

データベースおよびアプリケーションの数を調整するか、または割り当てられたメモリー設定を減らして、メモリー・ページングを回避します。

Linuxオペレーティング・システムでは、ASMおよびデータベース・インスタンスがSGA用にHugePagesを使用できるように、HugePagesを構成することをお薦めします。HugePagesは、リリース2.6からLinuxカーネルに統合された機能です。この機能は、より大きいページを指定する4KBのページ・サイズの代替方法となります。HugePagesを使用するメリットは、メモリーがディスクにページングされていないことを確認する際に、ページ表のオーバーヘッドを減らして、メモリー・リソースを節約することです。これは、メモリー全体のパフォーマンスの向上に役立ちます。この次に、ノード全体の安定性がHugePagesを使用するメリットを享受します。

init.oraパラメータuse_large_pages=onlyを設定して、データベース・インスタンスのSGA全体がHugePagesに格納されていることを確認できます。このパラメータを設定すると、HugePagesからSGAのメモリーのすべてを取得できる場合のみ、確実にインスタンスが起動します。このため、データベース・インスタンスにuse_large_pages=onlyを設定することをお薦めします。

ASMインスタンスの場合、use_large_pages=true (デフォルト値)のままにします。この設定によって、使用可能な場合に確実にHugePagesを使用しますが、さらに、HugePagesが構成されていない場合や構成が不十分な場合には、Grid Infrastructureの一部として確実にASMが起動します。

HugePagesは自動メモリー管理と互換性がないため、自動共有メモリー管理を使用します。

関連項目:

- 詳細は、『Oracle Database管理者ガイド』を参照してください。

- HugePagesの構成の詳細は、次のWebサイトのMy Oracle Supportのノート401749.1および361323.1の『Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration』および『HugePages on Linux: What It Is... and What It Is Not...』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=401749.1

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=361323.1

5.1.10 インスタンス・リカバリのためのパラレル・リカバリの無効化

V$INSTANCE_RECOVERYビューのRECOVERY_ESTIMATED_IOSの値が小さい場合(5000未満など)、パラレル・リカバリのオーバーヘッドがそのメリットを上回っている可能性があります。この状況は、FAST_START_MTTR_TARGETの設定が極端な場合によく発生します。この場合、RECOVERY_PARALLELISMを1に設定してパラレル・リカバリを無効化してください。

関連項目:

- 5.1.5項「FAST START MTTR TARGET初期化パラメータの設定」

- RECOVERY_PARALLELISMパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

5.2 管理性向上のための推奨事項

Oracleデータベースの管理性を向上するには、次のことを行います。

- Oracle RACまたはOracle Restartを併用したOracle Clusterwareの使用

- データ・リカバリ・アドバイザを使用したデータ障害の検出、分析および修復

- 自動パフォーマンス・チューニング機能の使用

- サーバー・パラメータ・ファイルの使用

- 自動UNDO管理の使用

- ローカル管理表領域の使用

- 自動セグメント領域管理の使用

- 一時表領域の使用とデフォルト一時表領域の指定

- 再開可能領域割当ての使用

- データベース・リソース・マネージャの使用

5.2.1 Oracle RACまたはOracle Restartを併用したOracle Clusterwareの使用

Oracle ClusterwareをOracle Real Application Clusters (Oracle RAC)またはOracle Restartとともに構成すると、主要なアプリケーションと、Oracle ASMインスタンス、リスナー、アプリケーション・エージェントおよびプロセスなどのOracleサービスを自動的に再起動できます。

Oracle Restartは、単一インスタンスの(クラスタ化されていない) Oracleデータベースおよびそのコンポーネントの可用性を向上します。Oracle Restartは、単一インスタンス環境でのみ使用されます。Oracle Real Application Clusters(Oracle RAC)環境では、Oracle Clusterwareによってコンポーネントを自動再起動する機能が提供されます。

Oracle Restartを構成すると、ハードウェアまたはソフトウェア障害の後、あるいはデータベースのホスト・コンピュータが再起動するときは必ず、データベース、リスナー、およびその他のOracleコンポーネントは自動的に再起動します。また、Oracleコンポーネントが、コンポーネントの依存性に応じて、確実に正しい順序で再起動します。

Oracle Restartは、Oracle Databaseホームとは別にインストールするOracle Grid Infrastructureホームから実行されます。

関連項目:

- 第6章「Oracle Clusterwareを使用したOracle Databaseの構成」

- Oracle Restartの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

5.2.2 データ・リカバリ・アドバイザを使用したデータ障害の検出、分析および修復

データ・リカバリ・アドバイザを使用し、データ障害の迅速な診断、適切な修復オプションの判別と提供、およびユーザー・リクエスト時の修復を行います。ここでは、データ障害とは、ディスク上の永続的データの破損または損失を指します。自動データ修復を行う集中化されたツールを持つデータ・リカバリ・アドバイザを使用すると、Oracleデータベースの管理性と信頼性が向上し、平均リカバリ時間(MTTR)が減少します。データ・リカバリ・アドバイザは、次のような兆候に基づいて障害を診断します。

- 存在しない、適切なアクセス権限がない、オフラインに移行したなどの理由によりアクセスできないコンポーネント

- ブロック・チェックサムの障害や無効なブロック・ヘッダー・フィールド値などの物理破損

- ソフトウェアの不具合を原因とする論理破損

- 不適切なコンポーネント・バージョンを原因とする非互換性障害

- オープン・ファイル数の制限の超過、チャネル・アクセス障害、ネットワークまたはI/OのエラーなどのI/O障害

- データベースのオープンを妨げる不適切な初期化パラメータ値などの構成エラー

診断された障害は、自動診断リポジトリ(ADR)に記録されます。データ・リカバリ・アドバイザは、次の処理に基づいてリカバリ計画を自動的に決定します。

- 障害がデータベースにより検出されてADRに格納された後にのみ、修復アドバイスを生成して障害を修復します。

- 効率的なリカバリのために複数の障害を集約します。

- 実行可能なリカバリ・オプションのみを提供します。

- オプションごとのデータ損失を示します。

通常、データ・リカバリ・アドバイザは、自動修復オプションと手動修復オプションの両方を提供します。適切であれば、データ・リカバリ・アドバイザに自動的に修復を実行させ、修復の成功を検証し、関連する修復済障害をクローズできます。

注意:
現在のリリースのデータ・リカバリ・アドバイザでは、単一インスタンス・データベースのみがサポートされています。Oracle RACデータベースはサポートされていません。データ・リカバリ・アドバイザでサポートされているデータベース構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

関連項目:

- データ・リカバリ・アドバイザの使用の詳細は、13.2.6項「データ破損からのリカバリ」を参照してください。

- データ・リカバリ・アドバイザによる障害の診断および修復の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

5.2.3 自動パフォーマンス・チューニング機能の使用

パフォーマンス問題を特定および修正するためには、効果的なデータの収集と分析が不可欠です。Oracleは、データベース・パフォーマンスに関する情報を収集する複数のツールを用意しています。

Oracleデータベースの自動パフォーマンス・チューニング機能は、次のもので構成されます。

- 自動ワークロード・リポジトリ(AWR)

- 自動データベース診断モニター(ADDM)

- SQLチューニング・アドバイザ

- SQLアクセス・アドバイザ

- アクティブ・セッション履歴レポート(ASH)

自動ワークロード・リポジトリ(AWR)を使用する際は、次のベスト・プラクティスを検討してください。

- 問題発生時に比較目的で使用するパフォーマンス・データのベースラインを作成します。このベースラインはシステムのピーク負荷の代表値となります。

- ストレス・テスト中にパフォーマンスのピークを取得する場合や、パフォーマンス問題を診断する場合、AWR自動スナップショットの間隔を10から20分に設定します。

- 通常のワークロードの場合、60分間隔で十分です。

関連項目:
自動ワークロード・リポジトリの管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

5.2.4 サーバー・パラメータ・ファイルの使用

サーバー・パラメータ・ファイル(SPFILE)は、データベースのすべてのインスタンスに関連付けられたすべてのデータベース初期化パラメータを保持する単一の集中管理パラメータ・ファイルです。このファイルにより、データベース・パラメータを管理するための簡単で確実な永続的環境が提供されます。Oracle Data Guardブローカを使用する場合、SPFILEは必須です。

関連項目:

- SPFILEで初期化パラメータを管理する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- Real Application Clusters環境での初期化パラメータの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- ブローカを使用する際の他の要件の詳細は、『Oracle Data Guard Broker』を参照してください。

5.2.5 自動UNDO管理の使用

自動UNDO管理を使用すると、Oracleデータベース・サーバーで効果的かつ効率的にUNDO領域を管理できるため、管理作業の複雑さとコストが削減されます。Oracleデータベースで内部的にUNDOセグメントを管理する場合、現在のワークロード要件に合せてUNDOセグメントのサイズと数が自動的に調整されるため、UNDOブロックと読取り一貫性の競合は発生しません。

自動UNDO管理を使用するには、次の初期化パラメータを設定します。

- UNDO_MANAGEMENT
このパラメータをAUTOに設定します。

- UNDO_RETENTION
UNDOデータを保存する希望時間を秒単位で指定します。このパラメータは、すべてのインスタンスで同じに設定する必要があります。

- UNDO_TABLESPACE
インスタンスごとに一意のUNDO表領域を指定します。

フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せ、フラッシュバック表などの高度なオブジェクト・リカバリ機能では、自動UNDO管理が必要です。それらが機能するかどうかは、1つ前の時点でのデータを参照するためにUNDO情報を利用できるかどうかによります。

Oracleデータベースのデフォルトでは、データベース使用統計の収集とUNDO容量要件の評価により、自動的にUNDO保存期間が調整されます。UNDO表領域で保存保証を有効化(CREATE DATABASEまたはCREATE UNDO TABLESPACE文でRETENTION GUARANTEE句を指定)していない場合、Oracle DatabaseではUNDO保存期間がUNDO_RETENTION値を下回ることがあります。

注意:
デフォルトでは、UNDO_RETENTIONパラメータの設定でUNDOデータが維持されるように指定されていても、UNDOデータが実行中のトランザクションによって上書きされる可能性があります。期限切れ前のUNDOデータが上書きされないよう保証するには、UNDO表領域でRETENTION GUARANTEEを有効化する必要があります。

フラッシュバック・テクノロジ機能の使用が要件に組み込まれている場合、ベスト・プラクティス推奨事項は、UNDO表領域でRETENTION GUARANTEEを有効化し、次のガイドラインに基づいてUNDO_RETENTIONの値を設定することです。

1. 間違ったトランザクションが実行された場合に、その検出にかかる時間を算出します。その値に2をかけます。

2. UNDOアドバイザを使用して、UNDO_RETENTIONをステップ1で推奨された値に設定した場合の、最小限のUNDO表領域サイズを計算します。

3. UNDO表領域でAUTOEXTENDオプションが無効にされている場合、ステップ2で算出した容量の領域を割り当てるか、UNDO_RETENTIONパラメータの値を減らします。

4. UNDO表領域でAUTOEXTENDオプションが有効にされている場合は、データファイルをステップ2で算出したサイズまで拡張するために利用できるディスク領域が十分にあることを確認します。指定した自動拡張MAXSIZE値が十分な大きさであることを確認します。

RETENTION GUARANTEEオプションを使用すると、表領域に構成されている領域がトランザクション・スループットの必要量より少ない場合、次の一連のイベントが発生します。

1. 自動拡張可能なファイルがある場合、保存されたUNDOデータを格納できるようそのファイルが自動拡張されます。

2. ディスクが85%フルになったことが警告アラートにより報告されます。

3. ディスクが97%フルになったことがクリティカル・アラートにより報告されます。

4. トランザクションに領域不足エラーが戻されます。

関連項目:

- UNDOアドバイザの使用によるUNDO表領域の最小サイズの計算の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- UNDO_RETENTIONの設定とUNDO表領域のサイズの詳細は、『Oracle Database管理者ガイド』を参照してください。

5.2.6 ローカル管理表領域の使用

ローカル管理表領域は、ディクショナリ管理表領域よりパフォーマンスに優れており、管理が容易で、均一なエクステントと組み合せるとエクステントが断片化する心配もありません。ローカル管理表領域では、データファイルのヘッダーに格納されたビットマップを使用します。ディクショナリ管理表領域とは異なり、領域の割当てと割当て解除において集中管理されたリソースに対する競合は発生しません。

関連項目:
ローカル管理表領域の詳細は、『Oracle Database管理者ガイド』を参照してください

5.2.7 自動セグメント領域管理の使用

自動セグメント領域管理により、領域管理タスクを簡略化することで、人為的エラーの発生を抑制できます。別のメリットとして、領域管理関連のパフォーマンス・チューニングが不要になります。この機能により、表や索引などのオブジェクト内の空き領域の管理が容易になり、領域使用率が向上し、簡単な管理操作でパフォーマンスとスケーラビリティが大幅に改善します。自動セグメント領域管理機能は、デフォルトの属性を使用して作成されたすべての表領域でデフォルトで有効化されます。

関連項目:
自動セグメント領域管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

5.2.8 一時表領域の使用とデフォルト一時表領域の指定

一時表領域により、複数のソート操作の同時実行性の向上、ソート操作のオーバーヘッドの削減、およびデータ・ディクショナリによる領域管理操作の回避が可能になります。これは、システム・リソースの使用とデータベース・パフォーマンスの両方の観点からして、一時セグメントを処理するためのより効率的な方法です。

ベスト・プラクティスは、個々のユーザーに一時表領域が割り当てられているかどうかにかかわらず、最も効率的なソート操作で一時セグメントが確実に使用されるように、データベース全体のデフォルト一時表領域を指定することです。

デフォルト一時表領域の指定時期

その後の手順

データベースの作成時

CREATE DATABASE文のDEFAULT TEMPORARY TABLESPACE句を使用します。

データベースの作成後

ALTER DATABASE文を使用します。

デフォルト一時表領域を使用すると、すべてのディスク・ソート処理は一時表領域で発生し、他の表領域が誤ってソートに使用されることはなくなります。

関連項目:
表領域管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

5.2.9 再開可能領域割当ての使用

再開可能領域割当ては、領域割当て障害が発生した場合にデータベース操作を一時停止して後から再開する方法です。データベースはエラーを戻さず、関連する操作を一時停止します。プロセスを再起動する必要はありません。領域問題が解決すると、一時停止されていた操作は自動的に再開されます。

再開可能領域割当てを使用するには、RESUMABLE_TIMEOUT初期化パラメータを使用して、システム・レベルで指定するか、ALTER SESSION文の句(たとえばALTER SESSION ENABLE RESUMABLE文)を使用して、セッション・レベルで有効化します。新規セッションのデフォルトでは、RESUMABLE_TIMEOUT初期化パラメータをゼロでない値に明示的に設定した場合を除き、再開可能モードは無効です。

関連項目:
再開可能領域割当ての管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

5.2.10 データベース・リソース・マネージャの使用

Oracle Database Resource Manager (リソース・マネージャ)を使用すると、データベース管理者は、リソース割当てがエンタープライズのビジネス目標に合うようにリソース管理の設定を詳細に制御できます。リソース・マネージャでは、Oracleデータベース・サーバー内の作業に優先順位を設定できます。データベースの可用性には、その機能性とパフォーマンスの両方が含まれます。データベースが使用可能であっても、ユーザーの必要とするパフォーマンス・レベルに到達しなければ、可用性とサービス・レベルの目標は満たされません。アプリケーション・パフォーマンスは、データベースにアクセスする各アプリケーションにリソースがどのように配置されるかによって大きく変化します。リソース・マネージャの主な目的は、Oracleデータベース・サーバーでリソース管理の設定をより詳細に制御して、オペレーティング・システムの不十分な管理やオペレーティング・システムのリソース・マネージャを原因として発生する問題を回避することです。

リソース・マネージャを使用する場合、次のことを行います。

- Enterprise Managerを使用して、リソース・プランを管理します。

- リソース・マネージャでテストする際は、CPUリソースの不足を生じさせる十分な負荷がシステム上にあることを確認します。

関連項目:

- Oracle Database Resource Managerの詳細は、『Oracle Database管理者ガイド』を参照してください。

- データベース・リソース・マネージャの構成およびトラブルシューティングの詳細は、次のWebサイトのMy Oracle Support Note 1119407.1の『リソース・マネージャ・トレーニング(11.2の機能を含む)』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1119407.1

6 Oracle Clusterwareを使用したOracle Databaseの構成

Oracle Clusterwareを使用すると、複数のサーバーが相互に通信することにより、1つの集合単位として機能するように見えます。Oracle Clusterwareでは、Oracle Real Application Clusters (Oracle RAC)とOracle RAC One Nodeの実行に必要なインフラストラクチャが提供されます。Grid Infrastructureはエンタープライズ・グリッド・アーキテクチャ用のインフラストラクチャを提供するソフトウェアです。クラスタの場合、このソフトウェアにはOracle Clusterwareと Oracle ASMが含まれます。スタンドアロン・サーバーの場合、Grid InfrastructureにはOracle RestartとOracle ASMが含まれます。Oracle Database 11gリリース2では、これらのインフラストラクチャ製品が、Grid Infrastructureホームと呼ばれる1つのソフトウェア・インストールに組み込まれています。

この章には、次の項目が含まれます。

- Oracle Clusterwareのベスト・プラクティス

- Oracle Clusterwareの構成ベスト・プラクティス

- Oracle Clusterwareの運用ベスト・プラクティス

6.1 Oracle Clusterwareのベスト・プラクティス

Oracle Clusterwareは、Oracle Grid Infrastructureの構成要素で、ユーザー・アプリケーションとOracleデータベースの可用性を管理するソフトウェアです。Oracle RACの稼働するほとんどのプラットフォームで必要なクラスタウェアは、Oracleクラスタウェアのみです。必要ならば、同じシステム上でOracle Clusterwareに加えて他のベンダーのクラスタウェアも使用できます。ただし、Oracleクラスタウェアにより提供されている機能に対して不要なソフトウェア・レイヤーを追加すると、複雑さとコストが増大し、特に計画済のメンテナンスなどでシステムの可用性が低下する可能性があります。

注意:
Oracle RACまたはOracle RAC One Nodeをインストールする前に、Oracle ClusterwareおよびOracle Automatic Storage Management (ASM)で構成されたOracle Grid Infrastructureを最初にインストールする必要があります。Oracle ClusterwareおよびOracle ASMの作動開始後、Oracle Universal Installerを使用してOracle RACコンポーネントとともにOracle Databaseソフトウェアをインストールできます。

Oracleクラスタウェアには、任意のアプリケーションを管理するためのインフラストラクチャを提供する高可用性フレームワークが含まれます。Oracleクラスタウェアにより、システムの起動時に管理対象アプリケーションが開始されることが保証され、アプリケーションが常に使用できるよう監視も行われます。プロセスに障害が発生した場合、Oracleクラスタウェアは、エージェント・プログラム(エージェント)を使用してそのプロセスを再起動します。Oracleクラスタウェアにはビルトイン・エージェントが用意されているため、シェル・スクリプトまたはバッチ・スクリプトを使用してアプリケーションを保護および管理できます。Oracleクラスタウェアには、いくつかのアプリケーション(たとえば、Oracle TimesTen In-Memory Database)のための事前構成済エージェントも用意されています。クラスタ内のノードに障害が発生した場合、通常は障害の発生したノードで稼働するプロセスをプログラムして別のノードで再起動できます。アプリケーションの監視の頻度、アプリケーションの開始と停止、およびアプリケーションの依存性は、構成可能です。

Oracle RAC One Nodeは、クラスタ内の1つのノードで実行されるOracle RACデータベースの単一インスタンスです。Oracle RAC One Nodeの操作の詳細は、7.2項「Oracle RAC One Nodeを使用したOracle Databaseの構成」を参照してください。

関連項目:

- Oracle Clusterwareを使用したアプリケーションの可用性の向上の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- クラスタ用Oracle Grid Infrastructureのインストールの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

6.1.1 クライアントの構成および移行の概要

Oracleに備わっている次の機能を使用すると、ノード間でクライアント接続を移行できます。これらの機能により、クライアントに対するノード障害の影響を最小限に抑えられます。

- クライアント側のロード・バランシングおよび接続ロード・バランシング。詳細は、6.2.6項「クライアント側およびサーバー側でのロード・バランシングの使用」を参照してください。

- 単一クライアント・アクセス名(SCAN)

- 高速アプリケーション通知(FAN)

- 高速接続フェイルオーバー(FCF) (FAN対応クライアントによる使用が適切)

ヒント:
高速接続フェイルオーバー(FCF)の使用および構成の詳細は、第11章「高速接続フェイルオーバーの構成」を参照してください。

6.1.1.1 サービス

高速アプリケーション通知(FAN)を使用するには、サービスの使用が必要です。サービスは、接続要求とOracle RACインスタンス間のあらゆる固有マッピングを切り離します。サービスはOracle RACデータベースのワークロードの管理を可能にする、Oracle RACデータベース用に定義されたエンティティです。サービスは、Oracleデータベースで実行中の全ワークロードを相互に独立したクラスに分割します。各サービスは、共通属性、サービス・レベルのしきい値および優先度を使用してワークロードを表します。グループ化の基準となる属性が属す操作には、呼出し中のアプリケーション、呼出し対象のアプリケーション機能、アプリケーション機能の実行優先度、管理対象のジョブ・クラス、またはアプリケーション機能またはジョブ・クラスで使用されるデータ範囲などがあります。

ワークロードまたはアプリケーションのグループを管理するために、特定のアプリケーションまたはアプリケーションの一部の操作に割り当てるサービスを定義できます。また、作業の種類ごとにサービスとしてグループ化することもできます。たとえば、オンライン・ユーザーはあるサービスを使用し、バッチ処理は別のサービスを使用し、レポートはまた別のサービスを使用してデータベースに接続することができます。

1つのサービスを共有するすべてのユーザーで、サービス・レベルの要件を同じにすることをお薦めします。サービスには個別の特性を定義できるため、各サービスはそれぞれ別々の作業単位にできます。サービスの使用時には、多数のオプションを使用できます。これらのオプションを実装する必要はありませんが、それらを使用すると、アプリケーションのパフォーマンスが最適化できます。

6.1.1.2 高速アプリケーション通知(FAN)

高速アプリケーション通知(FAN)は、登録済クライアントに構成およびサービス・レベルの情報を通知するためにOracle Clusterwareに統合されている通知メカニズムであり、この情報にはUPイベントやDOWNイベントなどのサービス・ステータスの変更が含まれます。アプリケーションはFANイベントに応答して、すぐにアクションを実行できます。FANの UP イベントおよび DOWN イベントは、インスタンス、サービスおよびノードに適用できます。

クラスタの構成が変更されて、クラスタ内で状態の変更が発生した場合、Oracle RACの高可用性フレームワークは、ただちにFANイベントを発行します。アプリケーションでは、データベースをポーリングして問題を検出するまで待機するかわりにFANイベントを受信して、ただちにアクションを実行できます。FANを使用すると、インフライト・トランザクションをただちに終了でき、インスタンスの失敗時にクライアントに通知することができます。

また、FANは、 ロード・バランシング・アドバイザ・イベントも発行します。アプリケーションでFANのロード・バランシング・アドバイザ・イベントを使用して、現在、クラスタ内で最適なサービス品質を提供しているインスタンスに作業要求を割り当てることができます。

関連項目:
高速アプリケーション通知の概要は、『Oracle Database管理者ガイド』を参照してください。

6.1.1.3 単一クライアント・アクセス名(SCAN)

単一クライアント・アクセス名(SCAN)はOracle Real Application Clusters (Oracle RAC) 11gリリース2の新機能で、クラスタで実行中のOracleデータベースにアクセスするための、クライアントの単一名を提供します。SCANを使用するクライアントの利点は、クラスタ内のノードを追加または削除しても接続文字列を変更する必要がないことです。クラスタにアクセスするための単一名を保持することで、クライアントではEZConnectクライアントとシンプルなJDBC thin URLを使用して、クラスタ内のどのサーバーでデータベースがアクティブな場合でも、クラスタで実行中のあらゆるデータベースにアクセスできます。SCANは、データベースへのクライアント接続のロード・バランシングおよびフェイルオーバーを提供します。SCANは、node1-vipのような、仮想IPアドレスに使用される名前に類似した仮想IP名です。ただし、仮想IPと異なり、SCANは個別のノードではなくクラスタ全体と関連付けられており、1つではなく複数のIPアドレスと関連付けられています。

関連項目:

- 単一クライアント・アクセス名(SCAN)の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- EZConnectの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

6.2 Oracle Clusterwareの構成ベスト・プラクティス

次のようなOracle Clusterwareの構成ベスト・プラクティスを使用します。

- クラスタ検証ユーティリティ(CVU)の使用

- Oracle ASMによるOracleデータベースおよびOracleクラスタウェアのローカル・ホームの使用

- サービスの高可用性の保証

- クライアント構成とFANのベスト・プラクティス

- サービスおよび単一クライアント・アクセス名(SCAN)を使用したデータベースへの接続

- クライアント側およびサーバー側でのロード・バランシングの使用

- Oracle ASMを使用した、Oracle Cluster Registry (OCR)のミラー化と複数の投票ディスクの構成

- 会社全体のクラスタ時間管理

- Oracle Clusterware、Oracle RACおよびOracle ASMで同じインターコネクト・ネットワークを使用していることの確認

- Highly Available IP (HAIP)を併用した冗長インターコネクトの使用

- Intelligent Management Platform Interface (IPMI)による障害分離の構成

6.2.1 クラスタ検証ユーティリティ(CVU)の使用

クラスタ検証ユーティリティ(CVU)はインストール中に主なクラスタ・コンポーネントの検証を行い、このユーティリティを使用して構成およびコンポーネントを検証できます。コンポーネントは、ディスクの空き領域などの基本的なコンポーネントの場合と、Oracle Clusterwareの整合性チェックなどの複雑なコンポーネントの場合があります。たとえば、CVUは、Oracle Clusterwareレイヤー全体の複数のOracle Clusterwareサブコンポーネントを検証できます。また、CVUは、ディスク領域、メモリー、プロセスおよびその他の重要なクラスタ・コンポーネントをチェックできます。

関連項目:
クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

6.2.2 Oracle ASMによるOracleデータベースおよびOracleクラスタウェアのローカル・ホームの使用

すべてのローリング・パッチ機能の要件は、パッチの適用を受けるソフトウェア・ホームが、共有されていないローカル・ホームであることです。ソフトウェアは、クラスタ内の各ノードのローカル・ファイル・システムに物理的に存在しており、共有クラスタ・ファイル・システム上には存在していない必要があります。

この要件の理由は、共有クラスタ・ファイル・システムが使用されている場合、1つのノード上のソフトウェアにパッチを適用すると、すべてのノードに影響を与えることになり、すべてのノード上のソフトウェアを使用するすべてのコンポーネントを停止する必要が生じるためです。ローカル・ファイル・システムを使用すると、他のノードに存在するソフトウェアに影響を与えることなく、1つのノードでソフトウェアにパッチを適用できます。

Oracle Grid Infrastructureをインストールし、Oracle Clusterwareを構成する場合は、次の点に注意します。

- Oracle RACデータベースにはデータベース・ファイルのための共有ストレージが必要です。

- Oracle Cluster Registry (OCR)と、Oracle ASMを使用するための投票ファイルを構成します。詳細は、6.2.7項「Oracle ASMを使用した、Oracle Cluster Registry (OCR)のミラー化と複数の投票ディスクの構成」を参照してください。

- 共有記憶域で共有ホームを使用するのではなく、ローカル・ホームにOracle Databaseをインストールすることをお薦めします。Oracle Databaseホームには共有ファイル・システムを使用しないことをお薦めします(共有ホームを使用すると、その共有場所から実行中のすべてのソフトウェアは、パッチを適用する前に停止することが必要なため、ローリング・アップグレードが実行できなくなります)。

- Oracle ClusterwareとOracle ASMは両方とも、Grid Infrastructureホーム(Grid_home)と呼ばれる非共有ファイル・システム上の1つのホームにインストールされます。

関連項目:
Oracle ASMのインストールの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

6.2.3 サービスの高可用性の保証

サービスにただ1つの優先インスタンスが存在する場合、そのサービスは、優先インスタンス上での停止後に、使用可能なインスタンスで即座に起動できるようにする必要があります。サービスを即座に起動すると、影響を受けるクライアントは、即座に再接続して作業を継続できます。Oracleクラスタウェアがこの処理を担当しますが、これは計画外の停止時にきわめて重要です。

計画済のメンテナンス時にサービスの起動をOracleクラスタウェアに任せる場合でも、早めに代替優先インスタンスを手動で起動し、代替インスタンス上でサービスを使用できるようにする方が安全です。代替インスタンスを手動で起動することにより、単一の優先インスタンスに伴うシングル・ポイント障害が排除されます。また、計画済のアクティビティであることから余裕を持ってこの処理を実行できます。サービス定義に少なくとも第2の優先インスタンスを追加し、計画済のメンテナンスの前にそのサービスを起動しておきます。その後、別のサービス・メンバーが使用できることを確認して、メンテナンスを実行するインスタンス上のサービスを停止します。1つ以上の優先インスタンスの追加は、永続的な変更である必要はありません。計画済のメンテナンスの実行後に、元のサービス定義に戻すことができます。

サービス・プロファイルを変更せずにサービスを手動で再配置すると、次のような場合にメリットを得ることができます。

- Oracle XAを使用中の場合は、手動によるサービスの再配置の使用が適切です。XAの指定ではトランザクション・ブランチをTMによって中断および再開できますが、接続ロード・バランシングが利用されている場合は、トランザクション・ブランチが開始されたインスタンスの代替Oracleインスタンスに再開された接続が配置される可能性があり、単一の分散トランザクションが複数のデータベース・インスタンスに及ぶ場合はパフォーマンスに関係してくるためです。

- アプリケーションが複数のサービス・メンバーとともに適切に動作するよう設計されていない場合、アプリケーション・エラーまたはパフォーマンス問題が発生する可能性があります。

すべての構成変更と同じように、本番環境に変更を実装する前に、複数のメンバーを含むサービスの効果をテストし、テスト環境でその存続可能性と影響を評価する必要があります。

関連項目:
Oracle Real Application ClustersのWebサイト(http://www.oracle.com/technetwork/database/clustering/overview/index.html)のテクニカル記事『XAとOracle制御の分散トランザクション』を参照してください。

6.2.4 クライアント構成とFANのベスト・プラクティス

作業中のノードに対して、またはそのノードからクライアント接続を移行できる機能は、計画済のメンテナンスの重要な側面です。クライアント接続の移行は、ソフトウェアの停止を必要とする計画済のメンテナンス・アクティビティ(ローリング・アップグレードの実行時など)において常に最初の手順となります。サービスのスイッチオーバーが開始したときにまだアクティブなデータベース接続があると、問題の発生する可能性が高まります。

計画済メンテナンス中におけるクライアントのリダイレクトのベスト・プラクティス・プロセスの例には、次の手順が含まれる可能性があります。

1. クライアントはFAN通知を受け取るように構成され、実行時接続ロード・バランシングと高速接続フェイルオーバーのために適切に構成されています。

2. Oracleクラスタウェアは、停止されるインスタンス上のサービスを停止するか、それらのサービスを代替インスタンスに再配置します。

3. Oracleクラスタウェアは、Service-Member-Downイベントを戻します。

4. FAN通知を受け取るように構成されているクライアントは、Service-Member-Downイベントの通知を受け取り、サービスを提供する他のインスタンスに接続を移動します。

関連項目:

- 自動ワークロード管理の概要は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- Oracle RAC環境でのクライアント・フェイルオーバーのベスト・プラクティスの詳細は、Oracle Technology Networkの次の場所にあるテクニカル記事『Oracle Real Application Clusters 11gでの自動ワークロード管理』を参照してください。
http://www.oracle.com/technetwork/database/clustering/overview/index.html

6.2.5 サービスおよび単一クライアント・アクセス名(SCAN)を使用したデータベースへの接続

Oracle Database 11gでは、アプリケーション・ワークロードを自動または手動で管理および制御できるように、それらのワークロードをサービスとして定義できます。手動で管理するサービスについて、DBAは、通常運用時と障害対応時において各サービスにどの処理リソースを割り当てるかを制御します。サービスによりパフォーマンス・メトリックが追跡され、一定の値を超えたときにアラートを自動生成するためのしきい値が設定されます。サービスでのCPUリソース割当てとリソース使用量制御は、データベース・リソース・マネージャを通じて管理されます。ジョブ・スケジューラ、パラレル問合せ、Oracle Streamsアドバンスト・キューイングなどのOracleツールおよび機能でも、サービスの使用によりそのワークロードが管理されます。

Oracle Database 11gでは、処理リソースをサービスに自動で割り当てるためのルールを定義できます。Oracle Databaseリリース11gインスタンスのOracle RACは、個々のサービスまたは複数のサービスを処理するために必要に応じて割り当てることが可能です。これらの割当てルールは、変化するビジネス要件に合せて動的に変更できます。たとえば、重要な財務処理を予定どおり完了するのに十分な処理リソースを確保するため、これらのルールを四半期後に変更できます。ルールを定義して、重要度の高いサービスを実行するインスタンスに障害が発生したときに、そのワークロードを重要度の低いワークロードを実行するインスタンスに自動で移行することも可能です。SRVCTLユーティリティまたはOracle Enterprise Managerを使用して、サービスを作成および管理できます。

最高度の可用性と管理性を実現するには、VIPアドレス(可能ならばSCAN)をサービスと組み合せて使用して、データベースへのアプリケーション接続を行います。

VIPアドレスは、クライアント接続で標準のパブリックIPアドレスのかわりに使用される代替パブリック・アドレスです。あるノードに障害が発生すると、そのノードのVIPアドレスは別のノードにフェイルオーバーされますが、そのVIP上にはリスニングするリスナーがいないため、クライアントがそのVIPアドレスに接続を試みると、長い時間TCP接続のタイムアウト・メッセージを待機することなく、接続拒否エラー(ORA-12541)を受信します。このエラーの結果、クライアントはアドレス・リスト内の次のアドレスに迅速に移動して有効なデータベース接続を確立します。新規のクライアント接続はフェイルオーバーしたVIPに最初に接続しようとしますが、そのVIPにリスナーが実行されていなければ、「リスナーがありません。」というエラー・メッセージがクライアントに返されます。クライアントはアドレス・リスト内の次のアドレスに移動します。このリストには、フェイルオーバーしていないVIPがそこで実行中のリスナーとともに示されています。

単一クライアント・アクセス名(SCAN)は完全修飾名(ホスト名+ドメイン)で、SCANに割り当てられたすべての3つのVIPアドレスに解決するように構成されています。アドレスは、DNSサーバー上またはGNS構成のクラスタ内で、ラウンドロビンDNSによって解決します。SCANリスナーはクラスタ内の任意のノードで実行でき、複数のSCANリスナーは1つのノードで実行できます。

Oracle RAC 11g リリース2以降のインスタンスは、デフォルトでリモート・リスナーとしてSCANリスナーに登録されます。

SCANはクラスタ・リソースです。SCAN VIPおよびSCANリスナーはランダム・クラスタ・ノードで実行されます。SCANは、クライアント構成が特定のデータベースを実行するノードに依存する必要がないように、データベースに位置の独立性を提供します。たとえば、クラスタにポリシー管理型のサーバー・プールを構成した場合、サーバー・プールにどのノードが割り当てられているかにかかわらず、SCANによってサーバー・プールのデータベースに接続できます。

SCAN名は仮想クラスタ・アドレスのように機能します。SCANは、クラスタ内の任意のノードで実行される可能性がある3つのSCAN VIPに解決されます。したがってエントリ・ポイントのようなノードごとのVIPアドレスとは異なり、SCANに接続中のクライアントには、仮想IPアドレスが追加、変更、またはクラスタから削除されても接続方法に関する更新は必要ありません。SCANアドレスは特定のノード・アドレスではなく、クラスタに解決されます。

Oracle Grid Infrastructureのインストールでは、SCANを解決するために割り当てられるIPアドレスと同数のSCANリスナーが作成されます。高可用性とスケーラビリティのため、SCANは3つのアドレスに解決することをお薦めします。SCANを3つのアドレスに解決する場合は、3つのSCANリスナーが作成されます。

Oracle RACはノードVIPアドレスを使用した フェイルオーバーを提供します。これは、同じデータベース・サービスに対するクライアント接続要求を管理するために、複数のノードで複数のリスナーを構成することで実現します。ノードに障害が発生した場合、VIPに接続中のサービスは動作可能なノードに透過的に再配置されます。クライアントまたはサービスが透過的アプリケーション・フェイルオーバー・オプションを使用して構成されている場合、そのクライアントは動作可能なノードに再接続されます。SCANリスナーが接続要求を受け取ると、SCANリスナーは最もロードされていない、要求されたサービスを提供しているインスタンスをチェックします。次に、最もロードされていないインスタンスが実行中のノードのローカル・リスナーに接続要求をリダイレクトします。続いて、クライアントにローカル・リスナーのアドレスが付与されます。ローカル・リスナーは最後にデータベース・インスタンスへの接続を作成します。

Oracle Database 11gリリース2より前のOracle DatabaseリリースのIPアドレスを使用するように構成されたクライアントは、既存の接続アドレスを引き続き使用できるため、SCANを使用する必要はありません。この場合、Database 11gリリース2より前のクライアントは、クラスタのノードVIPに解決されるTNS接続記述子を使用します。以前のバージョンのOracle DatabaseをアップグレードするとSCANリスナーに登録されるため、クライアントがSCANを使用してそのデータベースに接続できるようになります。データベースはinit.oraファイルのリモート・リスナー・パラメータを通じてSCANリスナーに登録されます。REMOTE_LISTENERパラメータは、SCAN:PORTに設定する必要があります。SCANをHOST=SCANとして設定した単一のアドレスを持つTNSNAMES別名には設定しないでください。クラスタにアクセスするための単一名を保持することで、クライアントではEZConnectクライアントとシンプルなJDBC thin URLを使用して、クラスタ内のどのサーバーでデータベースがアクティブな場合でも、クラスタで実行中のあらゆるデータベースにアクセスできます。たとえば、次のようになります。

sqlplus system@sales1-scan:1521/oltp

関連項目:

- 自動ワークロード管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- サービスおよびVIPアドレスを使用したOracle Databaseへの接続の概要は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- Oracle Clusterwareネットワーク構成の概要の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- EZConnectの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

6.2.6 クライアント側およびサーバー側でのロード・バランシングの使用

クライアント側のロード・バランシングは、LOAD_BALANCEパラメータをLOAD_BALANCE=ONに設定して、クライアントの接続定義(tnsnames.ora fileファイルなど)に定義します。このパラメータをONに設定した場合は、Oracle Databaseによってアドレス・リストから無作為にアドレスが選択されて、そのノードのリスナーに接続されます。これによって、クラスタ内で使用可能なSCANリスナー間で、クライアント接続が均等に分散されます。

SCANリスナーは、最もロードされていない、要求されたサービスを提供しているインスタンスのローカル・リスナーに接続要求をリダイレクトします。接続要求を受信したリスナーは、要求されたサービスを提供するとリスナーが認識しているインスタンスにユーザーを接続します。リスナーがサポートしているサービスを確認するには、lsnrctlサービス・コマンドを実行します。

クライアントがSCANを使用して接続する場合、Oracle NetはSCANに対して定義された3つのIPアドレスの間でクライアント接続要求のロード・バランシングを自動的に行います。ただし、EZConnectを使用している場合は行いません。

サーバー側のロード・バランシングでは、DBCAを使用してOracle RACデータベースを作成すると次のことが自動的に行われます。

- サーバー側のロード・バランシングの構成および有効化

- リモート・リスナー・パラメータのSCANリスナーへの設定(注意: DBCAを使用しない場合は、REMOTE_LISTENERデータベース・パラメータをscan_name:scan_portに設定する必要があります。)

- サーバー上の tnsnames.ora ファイルにおけるクライアント側のロード・バランシング接続定義のサンプルの作成

注意:
次の機能はデフォルト・データベース・サービスでは動作しません。このような機能を活用するには、クラスタ管理サービスを作成する必要があります。自分が作成したサービスのみ管理できます。データベース・サーバーによって自動的に作成されたサービスはデータベース・サーバーによって管理されます。

接続ロード・バランシングをさらに強化するには、ロード・バランシング・アドバイザを使用して各サービスの接続ロード・バランシングを定義します。ロード・バランシング・アドバイザは、データベースとそのインスタンスが提供する現在のサービス・レベルについてアプリケーションに情報を提供します。ロード・バランシング・アドバイザは、サービス用に定義したポリシーに基づいて最適なサービスを得るために、アプリケーション要求の宛先に関する推奨事項をアプリケーションに提供します。ロード・バランシング・アドバイザのイベントは、ONSを介してパブリッシュされます。ランタイム接続のロード・バランシングにおけるサービス・レベルの目標値には、次の2つのタイプがあります。

SERVICE_TIME: 応答時間に基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の経過時間およびサービスに対して使用可能な帯域幅に基づきます。SERVICE_TIMEの使用例としては、需要が変動するインターネット・ショッピングなどのワークロードがあります。次の例は、オンライン・サービスを使用して、目標を接続のSERVICE_TIMEに設定する方法を示します。

srvctl modify service -d db_unique_name -s online -B SERVICE_TIME -j SHORT

THROUGHPUT: スループットに基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の処理速度およびサービスに対して使用可能な帯域幅に基づきます。THROUGHPUTの使用例としては、前のジョブが完了してから次のジョブを開始するバッチ処理などのワークロードがあります。次の例は、sjobサービスを使用して、目標を接続のTHROUGHPUTに設定する方法を示します。

srvctl modify service -d db_unique_name -s sjob -B THROUGHPUT -j LONG

関連項目:

- 接続ロード・バランシングおよびロード・バランシング・アドバイザの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- ロード・バランシング・アドバイザを使用するための環境の構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- リスナー構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- LOCAL_LISTENERパラメータおよびREMOTE_LISTENERパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

6.2.7 Oracle ASMを使用した、Oracle Cluster Registry (OCR)のミラー化と複数の投票ディスクの構成

Oracle Cluster Registry (OCR)と、Oracle ASMを使用するための投票ファイルを構成します。可能であれば、OCRをミラー化し、Oracle ASMの高冗長性ディスク・グループを使用して複数の投票ディスクを構成することをお薦めします。

Oracle Cluster Registry (OCR)には、クラスタ・リソースに関する重要な構成データが含まれます。たとえばOracle ASMの冗長性ディスク・グループなどを使用して、OCRを常に保護します。Oracle Clusterwareでは、Oracle Cluster Registry(OCR)を使用して、Oracle Clusterwareで制御するOracle RACデータベース、 リスナー、仮想IPアドレス(VIP)、サービスと任意のアプリケーションなどのコンポーネントの情報を格納および管理します。共有クラスタ・ファイル・システムの使用時にクラスタの高可用性を確保するには、Oracle ASMの使用時とは対照的に、複数のOCRの場所を定義することをお薦めします。

さらに、次の場合もあります。

- 最大5つのOCRの場所を使用できます。

- 各OCRの場所は、クラスタ内のすべてのノードがアクセスできる共有記憶域に存在している必要があります。

- 障害が発生したOCRの場所がOCRの唯一の場所でないかぎり、オンラインで交換できます。

- OCRは、Oracle Enterprise Manager、サーバー制御ユーティリティ(SRVCTL)、OCR構成ユーティリティ(OCRCONFIG)、Database Configuration Assistant (DBCA)などのサポートされているユーティリティを介して更新する必要があります。

各OCRの場所は、クラスタ内のすべてのノードがアクセスできる共有ストレージに存在している必要があり、投票ディスクも共有ストレージに存在している必要があります。高可用性を確保するため、可能であれば、コントローラの異なる複数のストレージ・デバイス上に複数の投票ディスクを保持することをお薦めします。Oracleクラスタウェアでは、複数の投票ディスクを使用できますが、投票ディスクの数は3、5などの奇数である必要があります。単一の投票ディスクを定義する場合は、外部冗長ストレージを使用して冗長性を確保します。

拡張されたOracle RACには、メイン・サイト(データ・センター)とは異なる場所にあるアービタ・サイト上に存在するクォーラム(投票)ディスクが必要です。詳細は、7.3.2項「クォーラム・ディスクをホストするための第3の投票ディスクの追加」を参照してください。

関連項目:

- Oracle Cluster Registryの場所の追加、置換、修復および削除の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- OCRおよび投票ディスクの管理方法の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

- 投票ディスクとOracle Cluster Registryの要件の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

6.2.8 会社全体のクラスタ時間管理

Cluster Time Synchronization Service (CTSS)はOracle Clusterwareの要素としてインストールされます。デフォルトでは、時刻同期化サービスまたは時刻同期化サービス構成が、有効でも無効でもシステム上で検知されれば、CTSSはオブザーバ・モードで実行されます。時刻同期化サービスまたは時刻同期化サービス構成がクラスタ内のノードに存在しないことがCTSSで検知されれば、CTSSはアクティブ・モードになり、クラスタの時間管理を継承します。

ネットワーク・タイム・プロトコル(NTP)は、クライアント/サーバー・アプリケーションです。各サーバーにはNTPクライアント・ソフトウェアをインストールし、時刻をネットワーク・タイム・サーバーを同期するように構成する必要があります。Windows TimeサービスはNTPの完全な実装ではありませんが、NTPの仕様に基づいています。

ベスト・プラクティスでは会社全体でNTPを使用します。

関連項目:

- すべてのノードにおける時間の設定の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

- Cluster Time Synchronization Service (CTSS)およびクラスタ時間管理の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

6.2.9 Oracle Clusterware、Oracle RACおよびOracle ASMで同じインターコネクト・ネットワークを使用していることの確認

最も効率的なネットワーク検出およびフェイルオーバーと最適なパフォーマンスを実現するため、Oracle Clusterware、Oracle RACおよびOracle ASMでは、接続とアクセス可能性について同じ認識を共有するように同じ専用インターコネクト・サブネットを使用する必要があります。

次の手順で インターコネクト・サブネットを確認します。

1. Oracle RACおよびOracle ASMインスタンスに対するインターコネクト・サブネットを検証するには、次のいずれかを実行します。

- 次のコマンドを発行します。

SQL> select * from v$cluster_interconnects;

NAME   IP_ADDRESS      IS_PUBLIC    SOURCE
-----  ----------      ---------    -------
bond0  192.168.32.87   NO           cluster_interconnects parameter

- アラート・ログのインスタンス情報を参照して、インターコネクト・サブネットを検証します。

2. クラスタウェアで使用されているインターコネクト・サブネットを検証する手順:

prompt> $GI_HOME/bin/oifcfg getif | grep cluster_interconnect

bond0 192.168.32.0 global cluster_interconnect

関連項目:
アラート・ログの表示方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

6.2.10 Highly Available IP (HAIP)を併用した冗長インターコネクトの使用

冗長インターコネクトを使用するための複数のインタフェースは、インストール時またはインストール後にoifcfg setifコマンドを使用して、インタフェースをプライベートとして分類することで定義できます。これを実行する際、Oracle Clusterwareでは(定義するインスタンスの数に応じて)1つから4つのHighly Available IP (HAIP)アドレスが作成されます。このアドレスは、Oracle DatabaseおよびOracle ASMインスタンスによって使用され、可用性の高いロード・バランシングされた通信が確保されます。HAIPでは、デフォルトで、インターコネクト・トラフィックがすべてのアクティブなインターコネクト・インタフェースに対してロード・バランシングされ、あるアドレスに障害または通信不可が発生すると、対応するHAIPアドレスが他のアダプタに対して透過的にフェイルオーバーされます。

Oracleソフトウェア(Oracle RAC、Oracle ASMおよびOracle ACFS、すべてのOracle Database 11gリリース2 (11.2.0.2)以降のリリースを含む)は、デフォルトでこれらのHAIPアドレスをトラフィックのすべてに使用するため、用意されたクラスタ・インターコネクト・インタフェースのセット全体に対するロード・バランシングが可能になります。定義済クラスタ・インターコネクト・インタフェースに障害が発生するか、または通信できなくなった場合、Oracle Clusterwareは、機能している残りのインタフェースに対応するHAIPアドレスを透過的に移動します。

注意:
Oracle Database 11gリリース2より前のリリースのOracle Databaseでは、冗長インターコネクト使用機能は利用できないため、オペレーティング・システム・ベースのインタフェース関連テクノロジを使用する必要があります。

関連項目:

- HAIPによる冗長インターコネクトの使用の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- インタフェースの定義については、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

- 詳細は、次のWebサイトのMy Oracle Support Note 1210883.1の『11gR2 Grid Infrastructureの冗長インターコネクトとora.cluster_interconnect.haip』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1210883.1

6.2.11 Intelligent Management Platform Interface (IPMI)による障害分離の構成

障害分離は、障害が発生したノードをクラスタの残りのノードから分離させ、障害が発生したノードでデータが失われるのを防ぐプロセスです。理想的なフェンシングには、Oracle Clusterwareまたはそのノードで実行されているオペレーティング・システムとの連携がなくても問題のノードを再起動できる外部メカニズムが含まれます。この機能を提供するために、Oracle Clusterware 11gリリース2(11.2)以降では、業界標準の管理プロトコルであるIntelligent Management Platform Interface仕様(IPMI)をサポートしています。

通常、障害分離はIPMIを使用してGrid Infrastructureのインストール中に構成します。この際、「障害の分離のサポート」画面でIPMIの構成オプションが示されます。インストール中にIPMIを構成しない場合は、インストール後にOracle Clusterware Controlユーティリティ(CRSCTL)を使用して構成できます。

関連項目:
IPMIの詳細と、障害分離のためのIPMIの構成の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

6.3 Oracle Clusterwareの運用ベスト・プラクティス

Oracle Clusterwareの運用ベスト・プラクティスには次のようなものがあります。

- キャパシティ・プランニング

- テープまたはオフサイトへのOCRの定期的なバックアップ

6.3.1 キャパシティ・プランニング

適切なキャパシティ・プランニングは、Oracleのクラスタリング・テクノロジのあらゆる側面にとって重要な成功要因ですが、計画済のメンテナンスにとっては特に重要です。あるクラスタの一部分のみ(ノードなど)が使用できなくなったときでも、そのクラスタの担当する作業が確実に実行されるようにする必要があります。計画済または計画外の停止の発生後にクラスタを実行できなくなると、システム・リソースの不足から連鎖的に問題が発生する可能性が高まります。

クラスタのサイズを決定する場合、一般的な計画済または計画外の停止の発生後に残されるコンピューティング・リソースの量をnパーセントとして、そのクラスタのnパーセントでサービス・レベルを満たすことができるようにする必要があります。たとえば、4ノード構成のクラスタがあり、一度に1つのノードをアップグレードするローリング・アップグレードの方法でパッチを適用する場合、残りの3つのノードでアプリケーションからリクエストされる作業を実行できます。

計画済のメンテナンス時に重要なキャパシティ・プランニングのもう1つの留意点は、計画済のメンテナンスの一部として実行される作業を、可能であればアプリケーション作業から分離することです。たとえば、すべてのノードへのパッチ適用後にSQLスクリプトを実行する必要がある場合のベスト・プラクティスは、パッチが適用される最後のノードで、そのノードを使用してアプリケーションを起動する前にそのスクリプトを実行することです。この方法を使用すると、SQLスクリプトは、ノード上のオペレーティング・システム・リソースをすべて使用できるため、アプリケーションに影響を与える可能性が低下します。たとえば、CATCPU.SQLスクリプトは、CPUパッチをすべてのノードにインストールした後に実行する必要があります。

6.3.2 テープまたはオフサイトへのOCRの定期的なバックアップ

Oracleクラスタウェアでは、クラスタ内の1つのノード上で、4時間ごとに自動的にOracle Cluster Registry (OCR)のバックアップが作成されます。これがOCRマスター・ノードです。Oracleでは、OCRの最新の3つのバックアップ・コピーが常に保存されます。また、バックアップを作成するCRSDプロセスによって、毎日および各週の終わりにもOCRのバックアップが作成され、保存されます。Oracle Secure Backup、標準のオペレーティング・システム・ツールまたはサード・パーティ・ツールを使用して、Oracle Clusterwareで作成されたバックアップ・ファイルをオペレーティング・システム・バックアップの一環としてバックアップします。

注意:
UNIXベースのシステムでOCRバックアップが生成されるデフォルトの場所は、CRS_HOME/cdata/cluster_name(cluster_nameはクラスタ名)です。Windowsベースのシステムでバックアップが生成されるデフォルトの場所は、これと同じパス構成の場所です。バックアップは、OCRマスター・ノードに作成されます。バックアップのノードおよび場所をリストするには、ocrconfig -showbackupコマンドを発行します。

自動作成されたOCRバックアップ・ファイルを使用する他、ocrconfigコマンドで-manualbackupオプションを使用して、リクエストごとに手動バックアップを実行することができます。たとえば、OCRに対して変更(現在の環境でのノードの追加または削除、Oracleクラスタウェア・リソースの変更、データベースの作成など)を行う前後に、手動バックアップを実行できます。ocrconfig -manualbackupコマンドを使用すると、OCRの内容がファイル形式でエクスポートされます。ocrconfigで作成したエクスポート・ファイルは、Oracle Secure Backup、標準のオペレーティング・システム・ツールまたはサード・パーティ・ツールを使用して、オペレーティング・システム・バックアップの一環としてバックアップできます。

関連項目:
OCRのバックアップ方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

7 Oracle RACを使用したOracle Databaseの構成

この章には、次の項目が含まれます。

- Oracle RACを使用したOracle Databaseの構成

- Oracle RAC One Nodeを使用したOracle Databaseの構成

- 拡張クラスタ上のOracle RACを使用したOracle Databaseの構成

関連項目:
『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

7.1 Oracle RACを使用したOracle Databaseの構成

この項に記載されているベスト・プラクティスは、Oracle Real Application Clusters(Oracle RAC)を使用したOracle Database 11gに適用されます。これらのベスト・プラクティスは、第5章「Oracle Databaseの構成」および第6章「Oracle Clusterwareを使用したOracle Databaseの構成」に説明されているOracle Database 11gの構成ベスト・プラクティスを基盤としています。各ベスト・プラクティスは、Oracle RACとData Guardを使用したOracle Database 11g (MAA)環境のData Guardで使用される場合、プライマリ・データベースとスタンバイ・データベースで同一です。一部のベスト・プラクティスでは、停止時間を短縮または排除するためにシステム・リソースを大量に使用することがあります。これにより、パフォーマンス・サービス・レベルが影響を受ける可能性があるため、これらのベスト・プラクティスを本番環境で実装する前に必ずテスト環境でその影響を評価してください。

関連項目:
『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

7.1.1 インスタンス・リカバリ時間の最適化

インスタンス・リカバリは障害インスタンスからREDOスレッドをリカバリするプロセスです。インスタンス・リカバリは、データベースにアクセスするすべてのインスタンスに障害が発生した場合に実行されるクラッシュ・リカバリとは異なります。クラッシュ・リカバリは、単一インスタンスのOracleデータベースを使用するインスタンスに障害が発生した場合に実行される唯一のタイプのリカバリです。

Oracle RACを使用している場合、稼働を続けるいずれかのインスタンスのSMONプロセスが、障害インスタンスのインスタンス・リカバリを実行します。

Oracle RACと単一インスタンス環境の両方で、チェックポイントは、平均リカバリ時間(MTTR)の制限に使用される内部メカニズムです。チェックポイントは、バッファ・キャッシュからディスクに使用済バッファを書き込むプロセスです。チェックポイントの数を増やすと、障害後のリカバリに必要とされるREDOは少なくなります。目的は同じですが、MTTRの調整に使用されるパラメータおよびメトリックは、単一インスタンス環境とOracle RAC環境で異なります。

単一インスタンス環境では、クラッシュ・リカバリで必要とする秒数にFAST_START_MTTR_TARGET初期化パラメータを設定できます。クラッシュ・リカバリ時間には、データベースの起動、マウント、リカバリおよびオープンに要する時間が含まれます。

Oracleには、現在のシステムが達成しているMTTRターゲットと、所定のI/O容量において達成可能なMTTRターゲットを把握するのに役立ついくつかの方法が用意されています。

関連項目:
詳細は、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Oracle ClusterwareとOracle Real Application Clustersを使用して計画外停止時の可用性を最適化するためのベスト・プラクティス』を参照してください。
http://www.oracle.com/goto/maa

7.1.2 トランザクション・リカバリを実行するプロセスの数の最大化

FAST_START_PARALLEL_ROLLBACKパラメータでは、REDO適用後に実行されるトランザクション・リカバリで使用されるプロセスの数が判断されます。トランザクション・リカバリの最適化は、計画外の障害の発生後に効率的なワークロードを確保するために重要です。システムのCPU負荷が高くなければ、このパラメータをHIGHに設定することがベスト・プラクティスです。これにより、Oracleでは、トランザクション・リカバリ用にCPU_COUNTの4倍(4 X CPU_COUNT)のパラレル・プロセスを使用します。このパラメータのデフォルト設定はLOW、またはCPU_COUNTの2倍(2 X CPU_COUNT)です。パラメータは、次のように設定します。

ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK=HIGH SCOPE=BOTH;

関連項目:
パラレルDMLおよびパラレルDDLのリソース使用率に影響するパラメータの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

7.1.3 非同期I/Oの有効化の確認

非同期I/Oの使用は、すべてのOracleデータベースで推奨されるベスト・プラクティスです。詳細は、5.1.7項「DISK_ASYNCH_IO初期化パラメータの設定」を参照してください。

7.1.4 ノード間の冗長専用接続

パブリック・トラフィック、Oracle RACインターコネクトおよびI/Oには、冗長専用接続を使用して十分な帯域幅を確保します。

Oracle用語で拡張クラスタは、ノードが2つの物理的な場所に分けられている、2つ以上のノード構成を指します。拡張クラスタおよびその他のOracle RAC構成には、1つのファイバに基づく個別の専用チャネルが必要になる場合があります。または、オプションで高密度波長分割多重方式(DWDM)を構成して、リピータを使用せずにサイト間で通信することや、サイト間を遠く離す(10km超)ことができます。ただし、デメリットとして、DWDMは非常にコストがかかる可能性があります。

関連項目:
ネットワーク・ハードウェア要件の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

7.2 Oracle RAC One Nodeを使用したOracle Databaseの構成

Oracle RAC One Nodeは、クラスタ内の1つのノードで実行されるOracle Real Application Clusters(Oracle RAC)データベースの単一インスタンスで、同じクラスタ内の他のノードにフェイルオーバーまたは移行するオプションがあります。このオプションによって、Oracleでのデータベース統合の柔軟性が向上します。フェイルオーバーによる保護で高可用性を実現しながら、多くのデータベースを最小限のオーバーヘッドで1つのクラスタに統合でき、オンラインでのローリング・パッチ適用、オペレーティング・システムおよびOracle Clusterwareのローリング・アップグレードも可能になります。

関連項目:
Oracle RAC One Nodeの管理の詳細は『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照

7.3 拡張クラスタ上のOracle RACを使用したOracle Databaseの構成

Oracle RACの拡張クラスタは、サイト障害からの非常に高速なリカバリを実現し、すべてのサイトのすべてのノードで単一のデータベース・クラスタの一部としてアクティブにトランザクションを処理できるアーキテクチャです。拡張クラスタでは、ローカルのOracle RACクラスタより高い可用性を得ることができますが、各サイトは通常同じ都市圏内に存在するため、このアーキテクチャでは組織の障害時リカバリ要件をすべて満たすことができない可能性があります。

この項に記載されているベスト・プラクティスは、拡張クラスタでのOracle RACを使用したOracle Database 11gに適用されるもので、7.1項「Oracle RACを使用したOracle Databaseの構成」に説明されているベスト・プラクティスを基盤としています。

拡張クラスタ環境でOracle RACデータベースを構成する場合は、次のベスト・プラクティスを使用します。

- 拡張クラスタのサイトへのワークロードの均等な分散

- クォーラム・ディスクをホストするための第3の投票ディスクの追加

- 都市圏での近接性を保持するノードの構成

- Oracle ASM標準冗長性または高冗長性でのホスト・ベースのストレージ・ミラー化の使用

- 拡張クラスタに関する追加のデプロイメントの考慮事項

関連項目:

- Oracle Real Application Clusters Webサイト(http://www.oracle.com/technetwork/database/clustering/overview/index.html)の拡張クラスタに関するホワイト・ペーパーを参照してください。

- Oracle RACの高レベルの概要、メリットおよび構成例は、『Oracle Database高可用性概要』を参照してください。

7.3.1 拡張クラスタのサイトへのワークロードの均等な分散

典型的なOracle RACアーキテクチャは、主に単一のデータ・センターに存在するスケーラビリティおよび可用性ソリューションとして設計されています。Oracle RACの拡張クラスタを構成およびデプロイするには、クラスタの各ノードを遠く離して配置します。拡張クラスタ環境でOracle RACデータベースを構成する場合は、次の作業が必要です。

- サイトAにノードの一方のセットを、サイトBにノードのもう一方のセットを構成します。

- 両方のサイトに均等にクラスタ・ワークロードを分散し、設計上追加の競合や待機時間が発生しないようにします。たとえば、クライアント・コンポーネントはサイトAに、サーバー・コンポーネントはサイトBに配置するなどして、クライアントとサーバーのアプリケーション・ワークロードを両方のサイトにわたり実行することは避けます。

7.3.2 クォーラム・ディスクをホストするための第3の投票ディスクの追加

ほとんどの拡張クラスタには、2つのストレージ・システムのみが存在します(各サイトに1つ)。通常の処理では、各ノードは一定の間隔でディスク・ハートビートの書込みと読取りを行いますが、ハートビートが完了できない場合、影響のあるすべてのノードがクラスタから削除されます。これによってプロセスの再起動と、メンバーとしての安全な共有リソースへのアクセスの再試行が強制的に行われます。したがって、投票ディスクの大部分を保持するサイトは、クラスタ全体の潜在的なシングル・ポイント障害となります。可用性を確保するため、いずれかのサイトに障害が発生した場合や、サイト間に通信障害が発生した場合に備え、調停機能を保持する第3のサイトを追加する必要があります。

場合によっては、拡張クラスタで第3の投票ディスクをサポートするため、標準のNFSも使用できます。クォーラム・ディスクは、ネットワーク上の任意の場所で、低価格なローエンドの標準的なNFSマウント・デバイス上に構成できます。NFS投票ディスクは、本番環境に属する専用サーバー上に配置することをお薦めします。

拡張クラスタを使用し、第3のサイトを構成しない場合、2つのサイトのどちらがプライマリ・サイトか認識する必要があります。その後、プライマリ・サイトに障害が発生したら、セカンダリ・サイトを手動で再起動する必要があります。

注意:
Oracle Clusterwareでは、NFS、iSCSI、Direct Attached Storage(DAS)、Storage Area Network(SAN)およびNetwork Attached Storage(NAS)がサポートされます。システムでNFSがサポートされていない場合は、他の方法を使用します。たとえば、WindowsシステムではiSCSIを使用できます。

関連項目:
詳細は、次のWebサイトのテクニカル記事『標準NFSを使用した、拡張クラスタ構成のための第3の投票ファイルのサポート』を参照してください。
http://www.oracle.com/technetwork/database/clustering/overview/index.html

7.3.3 都市圏での近接性を保持するノードの構成

拡張クラスタでは、データ・センターが待機時間と複雑性を低減するのに十分なほど近接していれば、サーバーおよびサイト障害に対して最高レベルの可用性が提供されます。拡張クラスタのサイト間の推奨距離は、都市圏内です。ノード間およびストレージ間の待機時間が長いと、パフォーマンスおよびスループットに深刻な影響を与える可能性があります。パフォーマンス・テストを実行して、待機時間の影響を評価する必要があります。一般的に、50km以下の距離が推奨されます。

テストにより、Oracle RACクラスタ・ノード間の距離(最大ケーブル長)による構成への一般的な影響が次のように判明しました。

- 10km未満の距離には、通常のネットワーク・ケーブルを使用できます。

- 距離が10km以上の場合は、高密度波長分割多重方式(DWDM)リンクが必要です。

- 10から50kmの距離には、距離によるパフォーマンスへの影響を最小限に抑えるため、ストレージ・エリア・ネットワーク(SAN)・バッファ・クレジットが必要です。そうしない場合、距離によるパフォーマンスの低下が深刻なものになる可能性があります。

- 50kmを超える距離の場合、デプロイの影響を示す十分な証拠はまだ存在しません。対応可能なワークロードのタイプや、選択した距離によるパフォーマンスへの影響を識別するには、より多くのテストが必要です。

7.3.4 Oracle ASM標準冗長性または高冗長性でのホスト・ベースのストレージ・ミラー化の使用

Oracle ASM標準冗長性または高冗長性が構成されたディスク・グループで、ホスト・ベースのミラー化を使用して、ストレージ・アレイの障害がアプリケーションとデータベースの可用性に影響を与えないようにします。

2つのストレージ・アレイにわたり内部的にミラー化を実行するOracle ASMを使用したホスト・ベースのミラー化をお薦めします。Oracle ASMでミラー化を実装すると、システムの書込みI/Oがディスクの両方のセットに伝播されるアクティブ/アクティブ・ストレージ環境が提供され、各ディスクはその場所にかかわらず単一のディスク・セットとして認識されます。アレイ・ベースのミラー化は、ただ1つのストレージ・サイトのみがアクティブとなるため、使用しないでください。この場合、アーキテクチャがそのシングル・ポイント障害に対して脆弱となり、リカバリ時間が長期化します。

Oracle ASMボリューム・マネージャには、柔軟なホスト・ベースのミラー化冗長性オプションがあります。外部冗長性を使用して、ミラー化保護機能をハードウェアRAIDストレージ・サブシステムに依存することもできます。Oracle ASMの標準冗長性および高冗長性オプションでは、それぞれ二重および三重のミラー化を使用できます。

注意:
アレイ・ベースのミラー化は、Oracle RAC拡張クラスタで使用できます。このアプローチを使用すると、2つのミラー・サイトがアクティブ・パッシブ構成になり、1つのサイトに障害が発生すると完全な停止状態となります。残りのミラー・サイトが起動されれば、サービスが使用可能になります。このような理由から、HAの観点ではアレイ・ベースのミラー化は推奨されません。2つのアクティブ・サイトで作業するには、ホスト・ベースのミラー化をお薦めします。

Oracle Databaseリリース11g以上では、読取りI/Oがリモート障害グループから不要な読取りをせずにローカル・ストレージにアクセスする優先読取り機能がOracle ASMに含まれます。Oracle ASM障害グループの拡張クラスタを構成する場合、特定のノードがそのノードに最も近い障害グループのエクステント(セカンダリ・エクステントも含む)からデータを読み取るように指定できます。この構成は、パフォーマンスに関してリモート・ノードのアクセスが非対称な拡張クラスタにおいて特に有効であり、可用性の向上とネットワーク負荷の低減につながります。優先読取り障害グループの使用は、拡張クラスタで最も役立ちます。

ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータの値は、特定のインスタンスで優先的に読み取る必要のある障害グループを指定したカンマ区切りの文字列リストです。このパラメータは、インスタンス固有であり、通常はクラスタ化されたOracle ASMインスタンスでのみ使用します。その値には、ノードごとに異なる値を指定できます。たとえば、次のようになります。

diskgroup_name1.failure_group_name1, ...

関連項目:

- 4.2項「自動ストレージ管理(Oracle ASM)を使用したデータベース・ファイルの管理」

- ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータによる優先読取り障害グループの構成の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

7.3.5 拡張クラスタに関する追加のデプロイメントの考慮事項

拡張クラスタ・アーキテクチャを実装する場合、次のことにも留意してください。

- ネットワーク、ストレージおよび管理のコストは増加します。

- 書込みパフォーマンスにより、ネットワーク待機時間のオーバーヘッドが発生します。ワークロード・パフォーマンスをテストして、オーバーヘッドの影響を評価します。

- Oracle Data Guardなしで単一データベースを使用するため、データ破損またはデータ障害に対する保護はありません。

- 拡張クラスタで使用されるOracleリリース、オペレーティング・システムおよびクラスタウェアは、すべて拡張クラスタの存続可能性に影響します。

- サイト間のデータをミラー化する場合、次のことに留意してください。

- ホスト・ベースのミラー化には、アクティブ/アクティブ・ミラー(およびプライマリ/プライマリ・サイト構成)を可能にするクラスタ化された論理ボリューム・マネージャが必要です。クラスタ化された論理ボリューム・マネージャには、Oracle ASMを使用することをお薦めします。

- アレイ・ベースのミラー化では、アクティブ/パッシブ・ミラー(およびプライマリ/セカンダリ構成)を使用できます。

- 拡張クラスタでは、次のような障害に対する追加の破壊テストが必要です。

- サイト障害

- 通信障害

- 完全な障害時リカバリのため、リモートData Guardスタンバイ・データベースで拡張クラスタを強化します。このアーキテクチャには、次の特徴があります。

- プライマリ・データベースの独立した物理レプリカを維持します。

- 局地的災害からデータを保護します。

- データ破損および他の潜在的障害からデータを保護します。

- ローリング・データベース・アップグレードおよびパッチ・セット・アップグレードを実行するためのオプションを提供します。

8 バックアップとリカバリの構成

データ保護計画には、システムおよびストレージのエラーから保護するための適切なバックアップおよびリカバリ戦略が不可欠です。オラクルはOracleデータベースおよび構造化されていないアプリケーション・ファイルのバックアップおよびリカバリのための、包括的なデータ保護スイートを提供します。

この章の主なトピックは、Oracleデータベースのバックアップおよびリカバリのベスト・プラクティスの構成です。ファイル・システム・データ保護機能が、詳細を示す場所のポインタとともに示されます。

この章には、次の項目が含まれます。

- Oracleデータベースのバックアップおよびリカバリの製品および機能

- バックアップおよびリカバリの構成と管理のベスト・プラクティス

- ディスクへのバックアップのベスト・プラクティス

- テープへのバックアップのベスト・プラクティス

- バックアップおよびリカバリの操作とメンテナンスのベスト・プラクティス

- データベース外部のファイルのバックアップ

表8-1にOracleのバックアップおよびリカバリ・スイートの概要のクイック・リファレンスを示します。

表8-1 バックアップおよびリカバリの概要

テクノロジ

Oracleデータベースでの使用の推奨

ファイル・システム・データでの使用の推奨

コメント

Recovery Manager (RMAN)

はい

いいえ

Oracleデータベースのネイティブ・バックアップ・ユーティリティ

Oracle Secure Backup

はい

はい

テープ・バックアップ管理ソフトウェア

Oracle Secure Backup Cloud Module

はい

いいえ

Amazon S3ストレージへのバックアップ

フラッシュバック・テクノロジ

はい

いいえ

OracleデータベースのUNDOデータを利用する論理エラー収集

フラッシュバック・データベース

はい

いいえ

フラッシュバック・ログを利用するContinuous Data Protection (CDP)

Automatic Clustered File System (ACFS)スナップショット(ファイル・システム・クローンおよび障害時リカバリ用)

いいえ

はい

ファイル・システムの読取り専用または読取り/書込みのcopy-on-writeバージョン。レプリケーション使用可能。

ZFSスナップショット(開発/テストなどのデータベース・クローン用)

はい

はい

テストおよび開発用データベースの読取り専用または読取り/書込みのcopy-on-writeバージョン

バックアップ/リストア用のZFSスナップショット

いいえ

はい

テスト、開発およびバックアップ用ファイル・システムの読取り専用または読取り/書込みのcopy-on-writeバージョン

8.1 Oracleデータベースのバックアップおよびリカバリの製品および機能

この項では、Oracleデータベースのリカバリ機能を使用し、Oracleデータベースの機能で可能なバックアップ・オプションおよびバックアップ計画を使用する場合の、データベース・バックアップを適切に管理するための目的意識およびツールについて説明します。

8.1.1 バックアップを使用する状況の理解

本番データベースの計画外の停止を解決するためにバックアップを使用すると、リカバリ時間目標(RTO)とリカバリ・ポイント目標(RPO)、またはサービス・レベル要件を満たすことができない場合があります。たとえば、一部の停止は、フラッシュバック・データベースまたはスタンバイ・データベースを使用することで最も効果的に対処できます。ただし、表8-2に示されている状況のように、データベース・バックアップの使用が必要な状況もあります。

表8-2 データベース・バックアップが必要な状況の例

データベース・バックアップが必要な状況

説明

Data Guard環境の初期設定

スタンバイ・データベースの初期設定時には、セカンダリ・サイトにアクセス可能なプライマリ・データベースのバックアップを使用して初期スタンバイ・データベースを作成するか、RMANネットワーク対応のデータベース複製機能を使用してスタンバイ・データベースを作成します(この場合、バックアップがあらかじめ存在する必要はありません)。ネットワーク経由で複製を実行するには、RMAN FROM ACTIVE DATABASEオプションをDUPLICATEコマンドに含める必要があります。

ファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリ

Data Guardのない環境でブロック破損、メディア障害、またはその他の物理データ障害が発生した場合、唯一のリカバリ方法は、既存のバックアップからのリストアです。

二重障害の解決

二重障害の状況では、本番データベースとスタンバイ・データベースの両方の可用性が影響を受けます。二重障害の例は、セカンダリ・サイトが停止してフォルト・トレランスが失われ、それに続いて本番データベースでメディア障害が発生した場合です。スタンバイを再作成する必要があるどうかは、セカンダリ・サイトの停止タイプにより異なります。セカンダリ・サイトの停止が一時的で、ファイルの物理的破損がなかった場合は、セカンダリ・サイトがオンラインに戻された後で、本番データベースからREDOデータを継続して受信することができます。それ以外の場合、この状況を解決する方法は、使用可能なバックアップから本番データベースを再作成し、次にスタンバイ・データベースを再作成することです。

プライマリ・サイトの停止に続いてセカンダリ・サイトが停止するなど、複数の障害(より適切に言えば、災害)が発生した場合、オフサイトにのみ存在するバックアップを使用する必要があります。したがって、この最悪の事態のシナリオでサービスを再開するには、オフサイトにバックアップ・テープを配布して管理するためのプロセスを開発し、そのプロセスに準拠する必要があります。

関連項目:

- スタンバイ・データベースの作成方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- DUPLICATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.1.2 Recovery Manager (RMAN)を使用したデータベース・ファイルのバックアップ

Recovery Manager (RMAN)は、OracleデータベースをバックアップおよびリカバリするためのOracleのユーティリティです。データベースと緊密に統合されているため、バックアップの必要なファイルがRMANにより自動的に判別されます。さらに重要なのは、メディア・リカバリ操作用にリストアする必要のあるファイルをRMANが把握していることです。RMANでは、サーバー・セッションを使用してバックアップおよびリカバリ操作が実行され、バックアップに関するメタデータがリポジトリに格納されます。RMANには、次に示す一般的なユーザー管理のバックアップ方法に対して多くの利点があります。

- 表領域をバックアップ・モードにする必要のないオンライン・データベース・バックアップ

- 効率的なブロックレベルの増分バックアップ

- バックアップおよびリストア操作中のデータ・ブロック整合性チェック

- 操作を実際に実行しないテスト・バックアップおよびリストア

- フィジカル・スタンバイ・データベースのプライマリ・データベースとの同期化

RMANにより、バックアップとリカバリは自動化されます。ユーザーが管理するやり方では次の作業が必要です。

- 各データファイルのバックアップ場所の特定

- オペレーティング・システム・コマンドを使用した、バックアップの所定の場所へのコピー

- 適用するログの選択

RMANでは、これらのバックアップおよびリカバリのタスクがすべて自動化されます。

RMANを使用している場合にのみ利用可能なOracleバックアップおよびリカバリの機能(表領域の自動ポイント・イン・タイム・リカバリやブロック・メディア・リカバリなど)もあります。

関連項目:
詳細は、次の章を参照してください。

- ブロック・メディア・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- RMANの増分バックアップを使用したフィジカル・スタンバイ・データベースのロールフォワードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

8.1.3 Oracle Secure Backupを使用したテープへのバックアップ

Oracle Secure Backupは、一連のサーバーに対する共通管理インタフェースによって、異機種環境における一体的なデータ保護を提供します。Oracleデータベースおよび未構成データの両方を保護することで、Oracle Secure Backupは、次のような環境を含む、ユーザーのIT環境全体に対する集中的なテープ・バックアップ管理を提供します。

- Oracle Secure BackupのRecovery Manager (RMAN)とのビルトイン統合を通じた、Oracleデータベース

- ファイル・システム・データ保護: UNIX、WindowsおよびLinuxの各サーバー

- Network Data Management Protocol (NDMP)を利用するNetwork Attached Storage (NAS)データ保護

Oracle Secure BackupはRMANと統合されて、Oracleデータベースのテープ・バックアップおよびリストア操作のためのメディア管理層(MML)を提供します。この2製品の緊密な統合によって、パフォーマンスの高いOracleデータベースのテープ・バックアップが実現します。

テープの使用を抑えてバックアップ・パフォーマンスを向上させるRMANおよびOracle Secure Backup間で固有のパフォーマンス最適化には、次のようなものがあります。

- 未使用ブロックの圧縮: 未使用ブロックのバックアップに要する時間および領域の使用を除外します。

- UNDOのバックアップの最適化: 現在のバックアップのリカバリには不要な時間および領域の使用を除外します。

Oracle Secure Backup環境の管理にはコマンドライン、Oracle Secure Backup WebツールおよびOracle Enterprise Managerを使用できます。

RMANとOracle Secure Backupの組合せの使用により、エンドツーエンドのテープ・バックアップ・ソリューションが提供されるため、サード・パーティ製のバックアップ・ソフトウェアを使用する必要がなくなります。

関連項目:

- 未使用ブロックの圧縮とUNDOのバックアップの最適化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- Oracle Secure Backupプラットフォーム、NASおよびテープ・デバイスの互換性マトリクスは、次のWebサイトを参照してください。
http://www.oracle.com/technetwork/database/secure-backup/learnmore/index.html

8.1.3.1 Oracle Secure Backupを使用したAmazon S3ストレージへのバックアップ

データベースのバックアップが必要な場合、Amazon Web Services (AWS)のSimple Storage Service (S3)によって提供されるインターネット・ベースのデータ・ストレージ・サービスを利用できます。OSB Cloud ModuleによってRMANでは、S3をOracleデータベース・バックアップのリポジトリとして使用できます。これは、社内データ・ストレージや詳細に構成されたローカル・バックアップ・インフラストラクチャの管理に適した、管理しやすくコスト効率の高いスケーラブルな代替手段を提供します。OSB Cloud Moduleを使用したRMANは、AWSのElastic Compute Cloud (EC2)で実行中のOracleデータベースをバックアップする際に推奨される手段でもあります。

ユーザーは、ストレージおよびネットワーク転送コストの支払いを適宜行うための、AWSでのアカウントを設定する必要があります。また、セキュリティ要件およびネットワーク・リソースについても検討し、バックアップも適切に構成する必要があります。S3へのバックアップはパブリック・インターネット経由でAWSに送信され、パブリック・クラウド機能上に格納されるため、転送中およびS3での静止中のデータを保護にはバックアップの暗号化が必要です。この要件は、特定のデータベースまたは特定の構成のデータベースには適用されません。たとえば、データベースがEC2上で実行、またはAWSのVirtual Private Cloud (VPC)内で実行されている場合です。

また、ユーザーは、(RMANチャネルを使用する)ネットワーク並列処理の程度を構成して、データベースとS3 (パブリック・インターネットの要素を含む可能性があります)間のネットワーク機能を照合する必要があります。複数の同時チャネルが全体的に最も高いスループットを実現する可能性があります。RMANではこのような並列処理が最大限活用されるためです。

8.1.4 データベース・スナップショットを作成するためのリストア・ポイントの使用

Oracleはリストア・ポイントおよび保証付きリストア・ポイントを備えています。

- リストア・ポイントは、データベース・メンテナンス時のリスクの高いポイントにおける論理障害を防ぎます。通常のリストア・ポイントを作成すると、特定の時点またはSCN、つまりその時点のデータのスナップショットにリストア・ポイント名が割り当てられます。通常のリストア・ポイントは、フラッシュバック表操作、フラッシュバック・データベース操作およびすべてのRMANリカバリ関連の操作で使用できます。

- 保証付きリストア・ポイントは、データベース全体を対象とするメンテナンス(データベースまたはアプリケーションのアップグレードや、バッチ・プロセスの実行など)に推奨されます。保証付きリストア・ポイントはフラッシュバック・データベースと統合され、保証付きリストア・ポイントにフラッシュバックするのに必要なすべてのフラッシュバック・ログが保持されます。メンテナンス・アクティビティの完了後に結果を検証したら、フラッシュバック・ログ領域を再利用するため不要な保証付きリストア・ポイントは削除する必要があります。

関連項目:
フラッシュバック・データベースでのリストア・ポイントおよび保証付きリストア・ポイントの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.2 バックアップおよびリカバリの構成と管理のベスト・プラクティス

この項では、バックアップ頻度の決定、RMANリカバリ・カタログの使用、Oracleデータベースのバックアップ・オプション(ブロック変更トラッキングなど)の使用におけるベスト・プラクティスを説明します。

8.2.1 バックアップ頻度および保存ポリシーの決定

バックアップ頻度ポリシーを決定して、定期的にバックアップを実行することは重要です。バックアップ保存ポリシーは、必要なデータが破棄されないことを保証するのに役立ちます。

バックアップ頻度を決定する要因 頻繁なバックアップは、すべてのリカバリ・スキームにとって不可欠です。バックアップの頻度と内容は、次の基準に基づいて決定します。

- データの重大性: 障害が発生した場合にどれくらいのデータ損失を業務で許容できるかは、リカバリ・ポイント目標(RPO)により決まります。データがより重大で、RPOが低いほど、データのバックアップ頻度を高めます。特定の表領域についてより高いRPOを得るため、その表領域を他の表領域よりも頻繁にバックアップする場合は、リカバリ計画の一環としてTSPITRの実行も予定に入れる必要があります。これには、DBPITRよりもさらに多くの計画および実践が必要です。TSPITRを予定している表領域が自己完結型であることの確認が必要なためです。

- 推定修復時間: リカバリのために必要な時間の許容値は、リカバリ時間目標(RTO)により決まります。修復時間は、リストア時間とリカバリ時間の合計に基づきます。RTOが低いほど、バックアップ頻度は高くなります。つまりバックアップがより最新になるため、リカバリ時間は短縮します。

- 変更されたデータ量: データベースのバックアップ頻度は、データベースの変更率の影響を受けます。

- 読取り専用データの場合、保存ポリシーを確実に守れる頻度でバックアップを実行します。

- 変更頻度の高いデータの場合、バックアップ頻度をさらに高めてRTOを減らします。

データベースのバックアップとリカバリを簡略化するため、推奨バックアップ計画では、高速リカバリ領域、増分バックアップおよび更新増分バックアップ機能を使用します。FRAへの初期イメージ・コピー・バックアップの後、変更されたブロックのみが増分バックアップで取得され、続いてイメージ・コピーに適用されます。これによって、コピーが最新の増分バックアップ時間に更新されます(つまり、バックアップを増分的に更新します)。

関連項目:

- RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- データベースのPoint-in-Timeリカバリの実行の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 推奨バックアップ計画の使用の詳細は、 『Oracle Database 2日でデータベース管理者』を参照してください。

バックアップ保存ポリシーの確定 バックアップ保存ポリシーは、リカバリなどの要件を満たすために、ディスクまたは他のバックアップ・メディアに保存する必要のあるバックアップに関するルール・セットです。特定のバックアップは、より新しいバックアップで置換されているか、テープに保存済であるという理由から、安全に削除することが可能です。また、特定のバックアップは、アーカイブ要件や規制要件など、他の理由により、ディスクに保存する必要があります。バックアップ保存ポリシーを満たすために必要でなくなったバックアップは、不要なバックアップとなります。

バックアップ保存ポリシーは、冗長性やリカバリ・ウィンドウに基づいて決定します。

- 冗長性ベースの保存ポリシーでは、データベース内の各ファイルの個別バックアップを少なくともn個常に保持するように、nという数を指定します。

- リカバリ・ウィンドウ・ベースの保存ポリシーでは、以前の時間間隔(1週間や1か月など)を指定して、その期間内の任意の時点に対してポイント・イン・タイム・リカバリを実行するのに必要なすべてのバックアップを保持します。

アーカイブ・バックアップの保持 ビジネスの中には、日ごとのバックアップ保存ポリシーよりも長期間、バックアップの保持が必要なものもあります。RMANでは、長期アーカイブ・バックアップ機能によってこれが可能です。アーカイブのバックアップは、データベースのバックアップ保存ポリシーに従って不要になるのではなく、まったく不要にならないか、時間制限が切れたときに不要になります。

RMAN BACKUPコマンドをKEEPオプションとともに使用すると、通常の保存ポリシーよりも長期間バックアップを保存できます。このオプションは、バックアップをアーカイブ・バックアップとして指定します。これは、構成済の保存方針から除外される自己完結型のバックアップです。これによって、法定保存要件を満たす場合など必要なときに、特定のバックアップを通常よりも長く保存できます。KEEP FOREVERオプションを使用すると、リカバリ・カタログが必要になります。バックアップ・レコードは最終的に制御ファイルの制御期間を超えてしまうためです(リカバリ・カタログを使用しないと、データベース制御ファイルを使用して通常よりも長くバックアップを保持した場合にデータが消失する可能性があります)。アーカイブ・バックアップの一貫性を維持するのに必要とされるアーカイブREDOログ・ファイルのみが保存されます。RMANリカバリ・カタログの詳細は、8.2.2項「RMANリカバリ・カタログの使用」を参照してください。

関連項目:
長期保管用のアーカイブ・バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.2.2 RMANリカバリ・カタログの使用

制御ファイルの保存期間よりも長くバックアップ・メタデータを保護および維持するために、リカバリ・カタログを作成できます。リカバリ・カタログ・スキーマは、専用のスタンドアロンのデータベースに作成してください。リカバリ・カタログを他の本番データとともに配置しないでください。Oracle Enterprise Managerを使用する場合、Oracle Enterprise Managerリポジトリ・データベースでリカバリ・カタログ・スキーマを作成できます。

リカバリ・カタログを使用することによるメリットは、次のとおりです。

- 制御ファイルで保存が可能な期間よりも長期間のバックアップ情報の保存。制御ファイルのサイズが小さすぎて追加のバックアップ・メタデータを保持できなくなると、既存のバックアップ情報は上書きされるため、それらのバックアップを使用してリストアとリカバリを行うことは困難になります。

- 複数のデータベースのメタデータの保存

- フィジカル・スタンバイ・データベースへのバックアップの負荷の移行と、それらのバックアップを使用したプライマリ・データベースのリストアおよびリカバリ。同様に、プライマリ・データベースの表領域をバックアップし、フィジカル・スタンバイ・データベースでリカバリできます。ただし、ロジカル・スタンバイ・データベースのバックアップはプライマリ・データベースで使用できません。

関連項目:
RMANリポジトリおよびリカバリ・カタログの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.2.3 NOCATALOGモードとその後のRESYNC CATALOGによるバックアップの作成

バックアップをディスクまたはテープに作成する場合、ターゲット・データベースの制御ファイルをRMANリポジトリとして使用します。これにより、バックアップの成功が、リカバリ・カタログへのデータベース接続の可用性に左右されなくなります。ターゲット・データベースの制御ファイルをRMANリポジトリとして使用するには、NOCATALOGオプションを付けてRMANを実行します。バックアップの完了直後に、RESYNC CATALOGコマンドを使用することで、ターゲット・データベースの制御ファイルに格納された新規バックアップ情報がリカバリ・カタログと再同期されます。

関連項目:
RESYNC CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

8.2.4 増分バックアップ用のブロック変更トラッキングの有効化

Oracleデータベースには、増分バックアップ用のBLOCK CHANGE TRACKING機能があります。この機能により、以前のバックアップ以降に変更されたデータベース・ブロックを追跡することで、増分バックアップのパフォーマンスを向上できます。BLOCK CHANGE TRACKINGを有効にすると、RMANでは、ブロック変更トラッキング・ファイルを使用して、増分バックアップに含まれるブロックが識別されます。これにより、データファイルのすべてのブロックをスキャンする必要がなくなるため、バックアップ中のディスク読取り数が減少します。

Oracle Database 11g以上では、プライマリ・データベースおよびフィジカル・スタンバイ・データベースの両方でBLOCK CHANGE TRACKINGを有効にできます。増分バックアップを実行する任意のデータベースで変更トラッキングを有効化する必要があります。たとえば、バックアップの負荷をフィジカル・スタンバイ・データベースに完全に移行している場合、そのデータベースでブロック変更トラッキングを有効化する必要があります(これにはActive Data Guardが必要です)。プライマリ・データベースとフィジカル・スタンバイ・データベースの両方でバックアップを実行する場合、両方のデータベースでブロック変更トラッキングを有効化します。

関連項目:

- ブロック変更トラッキングの有効化および無効化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- ブロック変更トラッキングの詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。

8.2.5 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの有効化

RMANを構成すると、制御ファイルのデータベース構造メタデータが変更された場合、またはバックアップ・レコードが追加された場合は常に、制御ファイルとサーバー・パラメータ・ファイル(SPFILE)を自動的にバックアップできます。

制御ファイルの自動バックアップ・オプションにより、RMANでは、現在の制御ファイル、カタログおよびSPFILEが失われた場合でもデータベースをリカバリできます。RMANの自動バックアップ機能は、CONFIGURE CONTROLFILE AUTOBACKUP ON文を使用して有効化します。

自動バックアップ機能は、プライマリ・データベースとスタンバイ・データベースの両方で有効化する必要があります。たとえば、プライマリ・データベース(ターゲット・データベース)およびリカバリ・カタログに接続した後、次のコマンドを発行します。

CONFIGURE CONTROLFILE AUTOBACKUP ON;

関連項目:

- 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- バックアップが実行されているスタンバイ・データベースのRMAN構成の詳細は、『Oracle Data Guard概要および管理』を参照してください。

8.2.6 フィジカル・スタンバイ・データベースへのバックアップ負荷の移行

Data Guard構成では、制御ファイル、データファイルおよびアーカイブREDOログ・ファイルをバックアップするプロセスの負荷をフィジカル・スタンバイ・システムに移行して、プライマリ・システムに対するバックアップの影響を最小限に抑えることができます。これらのバックアップは、プライマリ・データベースまたはスタンバイ・データベースのリカバリに使用できます。

注意:
ロジカル・スタンバイ・データベースのバックアップは、プライマリ・データベースで使用できません。

関連項目:
RMANを使用したファイルのバックアップおよびリストアの詳細は、『Oracle Data Guard概要および管理』を参照してください。

8.2.7 フラッシュバック問合せおよびフラッシュバック表のニーズに対するUNDO保存期間の設定

フラッシュバック問合せ、フラッシュバック・バージョン問合せおよびフラッシュバック・トランザクション問合せをデータベースで使用可能にするには、次の作業を行います。

- UNDO_MANAGEMENT初期化パラメータをAUTOに設定します。これによってデータベースで必ずUNDO表領域が使用されます。

- UNDO_RETENTION初期化パラメータを、UNDOが、最長の問合せが時間内に戻り成功することが可能な期間保持されるか、人為的エラーからリカバリすることが可能となる値に設定します。

- 期限切れ前のUNDOが上書きされないよう保証するには、UNDO表領域でRETENTION GUARANTEE句を設定します。

フラッシュバック表でも、表のリカバリのためにUNDOデータが利用されます。自動UNDO管理の有効化が推奨されます。UNDO_RETENTIONパラメータは、フラッシュバック表が必要とされる期間に設定してください。指定された表に、フラッシュバック表の後の必須データが含まれていない場合、十分なUNDOデータがあるならば、表をさらにフラッシュバックする、フラッシュフォワードする、あるいは元の状態に戻すことができます。

関連項目:

- フラッシュバックの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- フラッシュバック問合せの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

8.3 ディスクへのバックアップのベスト・プラクティス

次の優先項目を参考にディスク・バックアップ計画を決定してください。

- バックアップ時間全体

- リソース使用量への影響

- バックアップによる使用領域

- リカバリ時間

表8-3では、環境ごとに異なる優先項目に対応する様々なバックアップの選択肢を比較しています。表8-3をガイドとして使用することで、現在の特定のビジネス要件に最適なバックアップ・アプローチを選択できます。リカバリ時間を犠牲にする一方で、バックアップ領域を最小化することが可能です。または、領域を考慮せずに、リカバリ時間とバックアップ時間を優先することも可能です。

表8-3 ディスクへのバックアップ・オプションの比較

バックアップ・オプション

バックアップ時間全体
1: 最も速い
5: 最も遅い

リソース使用量への影響
1: 最小
5: 最大

バックアップによる使用領域
1: 最小
5: 最大

リカバリ時間
1: 最も速い
5: 最も遅い

データファイルのイメージ・コピー

5

5

5

1

リストアなし(高速リカバリ領域コピーに切替え)

全体バックアップ・セットまたはレベル0バックアップ・セット

4

4

3

3

差分増分バックアップ・セット(レベル1)、リカバリ時に以前のレベル0およびレベル1バックアップに適用

1

1

1

5

累積増分バックアップ・セット(レベル1)、リカバリ時に以前のレベル0バックアップに適用

2

2

2

4

更新増分バックアップ(レベル1)、バックアップ後にイメージ・コピーに増分を適用

3

1

5

1

リストアなし(高速リカバリ領域コピーに切替え)

ディスクへのバックアップ: リカバリ時間を最適化するためのベスト・プラクティス リストア時間が主な検討課題の場合、データベース・コピーを実行するか、増分のコピーへの即時適用を行う増分バックアップを実行します。即座に使用できるデータベースのバックアップを提供するのはこれらのオプションのみであり、最後の増分バックアップが実行された後に作成されたアーカイブREDOログ・ファイルを使用することで、障害発生時点までリカバリする必要があります。

ディスクへのバックアップ: 領域使用量を最小化するためのベスト・プラクティス 領域使用量が主な検討課題の場合、増分のコピーへの遅延適用を行う増分バックアップを実行します。累積レベル1の増分バックアップを実行すると、最後のレベル0のバックアップ以降に変更されたブロックのみが保存されます。

- 累積増分バックアップでは、最後のレベル1のバックアップのみをレベル0のバックアップに適用します。

- 差分増分バックアップでは、レベル1のすべてのバックアップをレベル0のバックアップに適用します。

通常、累積増分バックアップは、差分増分バックアップより多くの領域を高速リカバリ領域で使用します。

ディスクへのバックアップ: システム・リソース消費(I/OおよびCPU)を最小化するためのベスト・プラクティス システム・リソース消費が主な検討課題の場合、ブロック変更トラッキング・ファイルを使用する増分バックアップを有効にすると、データベースでのリソース消費量が最小になります。

例

ほとんどのアプリケーションで、トランザクション頻度が非常に高くても、データベース全体で毎日変更される部分の割合は多くありません。多くの場合、アプリケーションは同じブロック・セットを頻繁に更新するため、一意の変更されたブロック・セットの合計サイズは小さくなります。

たとえば、約600GBのユーザー・データを含むデータベースがあるとします(一時ファイルとREDOログは除外します)。24時間ごとに、データベースの約2.5%(約15GBのデータ)が変更されます。この例では、MAAテストで次の結果が得られました。

- レベル0のバックアップには、180分を要します(データ領域からのREAD操作と高速リカバリ領域へのWRITE操作を含む)。

- レベル1のバックアップには、20分を要します(データ領域からのREAD操作と高速リカバリ領域へのWRITE操作を含む)。

- 新規作成された増分バックアップによる、高速リカバリ領域にある既存のイメージ・コピーのロールフォワードとマージには、45分のみを要します(高速リカバリ領域からのREAD操作とWRITE操作を含む)。

この例では、レベル0のバックアップ(イメージ・コピー)には180分を要します。これは全体バックアップ・セットの実行にかかる時間と同じです。

それ以降のバックアップはレベル1(増分)で、所要時間は20分なので、データ領域への潜在的影響は減少します。そのバックアップは次に既存のレベル0バックアップに適用されます。これには45分を要します。このプロセスはデータ領域へのI/Oを実行しないため、影響はありません(フラッシュ・リカバリ領域とデータ領域が個別ストレージを使用する場合)。増分バックアップを作成し、既存のレベル0バックアップに適用する場合の総所要時間は65分です(20+45)。

増分更新バックアップまたは全体バックアップ・セットのどちらを使用しても結果は同じで、データベースの全体バックアップが作成されます。増分アプローチは、単純に全体バックアップ・セットを作成するよりも115分短くなります(64%減少)。また、特に本番データベースのパフォーマンスへの不利な影響を抑制することが必要なデータ領域に対する、I/Oの影響も減少します。

このように、この例で、全体バックアップ・セット計画と、まずイメージ・コピーを行い、増分バックアップのみを実行し、その後でコピーをロールフォワードする場合を比較すると、最終的な削減内容は次のようになります。

このように、この例で、常に全体バックアップ行う場合と、まずレベル0バックアップを行い、増分バックアップのみを実行し、その後でレベル0バックアップをロールフォワードする場合を比較すると、最終的な削減内容は次のようになります。

- 115分または64%の時間を節約して完全なバックアップを作成できます。

- バックアップ中のデータベースのI/Oを削減できます。

関連項目:
データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.4 テープへのバックアップのベスト・プラクティス

Recovery Manager (RMAN)は、Oracleデータベースの自動ディスク・バックアップを提供し、テープへのバックアップのためにOracle Secure Backupなどのメディア管理製品と統合されています。ユーザーのOracleデータベース・バックアップ計画がディスク、テープ、あるいはその両方のどれを使用する場合でも、RMANとOracle Secure Backupの組合せはユーザー固有の要件に対応する包括的なソリューションを実現します。

8.4.1 RMANとOracle Secure Backupの初期構成

Oracle Secure Backupをインストールすると、RMANテープ・バックアップに対するSystem Backup Tape (SBT)ライブラリが自動的にリンクされます。Oracle Enterprise Manager Database Controlを使用すると、Oracle Secure Backupバックアップ・ドメインをテープ・ボールティングからバックアップおよびリストア操作まで管理できます。RMAN、Oracle Enterprise Manager Database ControlおよびOracle Secure Backupが緊密に統合されているため、初期構成はシンプルなプロセスです。

初期構成を実行し、データベースのテープへのバックアップの準備をするため、次の4つの手順を実行します。

1. Oracle Enterprise Manager Database ControlでOracle Secure Backup Administrative Serverを定義して、Oracle Secure BackupドメインをOracle Enterprise Managerから管理できるようにします。

2. RMANで使用するOracle Secure Backupユーザーを事前認可します。これによって、Oracle Secure Backupに明示的にログインしなくても、RMANのバックアップ/リストアを実行できるようになります。

3. RMANバックアップについて使用されるメディア・ポリシーをOracle Secure Backupで設定します。

4. 並列処理および圧縮などのRMANバックアップ設定を決定します。

注意:
Oracle Secure Backupまたはテープ側圧縮を使用する場合、RMAN圧縮も使用することは避けてください。

関連項目:
Recovery ManagerのOracle Secure Backupとの使用方法の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。

8.4.2 テープ・バックアップに対するOracle Secure Backupメディア・ポリシーの定義

テープに保存されたバックアップ・データが一度不要になれば、そのライフサイクルは終了し、テープ・メディアは再利用できます。テープのライフサイクル(保存期間)中の管理要件には、複製と、複数の保存場所におけるボールティングが含まれます。Oracle Secure Backupは、次のようなユーザー定義メディア・ポリシーによって効率的なメディア・ライフサイクル管理を提供します。

- 保存

- テープの複製

- ボールティング: 複数の保存場所間のテープのローテーション

メディア・ライフサイクル管理は、適切な保存設定の定義のように単純な場合もあれば、元のテープと同じ複製、または異なる保存期間およびボールティング要件による複製のように複雑になる場合もあります。Oracle Secure Backupメディア・ファミリ(通例ではテープ・プールと呼ばれます)は、メディア・ライフサイクル管理の基盤を提供します。

推奨されるベスト・プラクティスは、データベースに関連付けられた定義済のRMAN保存パラメータを使用するコンテンツ管理メディア・ファミリを利用して、テープ(効率的には期限切れのテープ)を再利用できる時期を判断することです。特定の有効期限は、時間管理と関連付けられるようにコンテンツ管理テープとは関連付けられていません。これらのテープの期限切れまたはリサイクルは、テープ上のバックアップ・イメージと関連付けられた属性に基づいています。コンテンツ管理テープに自動的に書き込まれたすべてのバックアップ・イメージには、関連付けられたコンテンツ管理再利用の属性があります。コンテンツ管理テープのリサイクルはユーザー定義のRMAN保存設定に従うため、バックアップ・イメージ属性をいつ「削除済」に変更するかは、RMANによってOracle Secure Backupに示されます。

RMANのDELETE OBSOLETEコマンドは、ユーザー定義のRMAN保存期間には不要になったバックアップ・ピース(イメージ)はどれかを伝達します。Oracle Secure Backupがこの通信を受け取ると、バックアップ・イメージ属性は「削除済」に変更されます。実際のバックアップ・イメージは削除されませんが、Oracle Secure Backupカタログ内の属性は更新されます。テープ上のすべてのバックアップ・イメージが削除済という属性になると、Oracle Secure Backupでは、有効期限管理テープと同様に、このテープが再利用可能であると判断されます。

Oracle Secure Backupは、ユーザー定義のDatabase Backup Storage Selectorsを通して、RMANバックアップ操作に対するポリシーベースのメディア管理を提供します。1つのDatabase Backup Storage Selector (SSEL)が複数のデータベースに適用されたり、複数のSSELが1つのデータベースに関連付けられる場合があります。たとえば、RMAN複製の使用時に1つのデータベースに対して2つのSSELを作成し、それぞれのコピーが異なるメディア・ファミリに書き込まれる場合があります。SSELには、次の情報が含まれます。

- データベース名/ ID、またはすべてのデータベースに適用可

- ホスト名、またはすべてのホストに適用可

- コンテンツ: アーカイブ・ログ、完全、増分、自動バックアップ、またはすべてに適用可

- RMANコピー番号(RMAN複製が構成済の際に適用可)

- メディア・ファミリ名

- 操作が制限されるデバイスの名前(デバイス制約が構成されていない場合、Oracle Secure Backupは任意の使用可能デバイスを使用)

- 使用可能なテープ・リソースに対する待機時間(期間)

- 暗号化設定

Oracle Secure BackupはSSEL内で定義されたストレージ選択を自動的に使用するため、ユーザーが設定することは不要です。1回かぎりのバックアップ操作やその他の例外時にストレージ選択を上書きする場合は、RMANバックアップ・スクリプトで代替的なメディア管理パラメータを定義します。詳細は、次の項を参照してください。

http://www.oracle.com/technetwork/database/secure-backup/documentation/index.html

8.4.3 高速リカバリ領域からのテープ・バックアップの作成

高速リカバリ領域(FRA)は、RMANコマンド: BACKUP RECOVERY AREAによって簡単にテープにバックアップできます。テープへの本番データベースの個別バックアップを実行するかわりに、このディスクをテープ・バックアップ・メソッドに使用すると、次のような明確な利点があります。

- 高速リカバリ領域(FRA)の最適なバックアップの作成によって、テープですでに保護されている不要なファイルのバックアップが排除されるため、テープの使用量が抑えられます。

- ディスクからテープへと必要に応じた、より最適なリストア・インテリジェンスがRMANで有効になります。これ以外の場合では、メディア・タイプに関係なく最新のバックアップからリストアされます。

- FRAでは個別ディスク・グループが使用されるため、本番データベース上のI/Oが削減されます。

リストアの際、RMANでは自動的に最適なバックアップが選択され、ディスクまたはテープからリストアされます。必要なバックアップがテープ上にある場合、RMANではリストアされるか、Oracle Secure Backupとの統合によってテープ・メディアから直接データベースがリカバリされます。リカバリに必要なファイルの種類はRMANで熟知されているため、ディスクまたはテープからのリストアは自動化されたプロセスです。

FRAのバックアップや、RMAN外部のテープに対するその他のRMANディスクのバックアップは、メディア管理ソフトウェアを使用してディスク領域のファイル・システム・バックアップを実行すれば可能ですが、推奨されません。RMANでテープ・バックアップが認識されていなければ、リストアがエラーを引き起こしやすい手動プロセスになります。

1. DBAはリストアに必要なファイルを決定する必要があります。

2. メディア・マネージャ管理者は次に、目的のファイルをテープ・バックアップからディスクの場所にリストアします。

3. ファイルがディスク上にリストアされたら、DBAはRMANのリストアまたはリカバリをディスクの場所から開始します。

RMANとOracle Secure Backupの組合せによって、Oracleデータベースの一体的なテープ・バックアップ・ソリューションが提供されます。

関連項目:
高速リカバリ領域の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

8.4.4 オフサイトのバックアップ・テープの管理

バックアップ・テープは携帯性に優れているため、しばしば、障害回復を目的としてオフサイトの場所に保存されます。このようなテープは最初はテープ・デバイス内から作成されますが、ハードウェア・デバイスからは削除されることがほとんどです。バックアップ・テープがハードウェア・デバイスから一度削除されると、テープはオンサイトまたはオフサイトの場所に保存されます。複数の場所におけるテープの移動は、Oracle Secure Backupのローテーション・ポリシーを使用して効率的に管理できます。

Oracleデータベースのリストアの場合、リストア・リクエストはRMANからOracle Secure Backupに送信されます。テープがライブラリ内にある場合、デバイスの可用性が想定されてリストアがすぐに開始します。ただし、リストアに必要なテープがオフサイトに存在する場合、リストア・コマンドを発行する前にテープの場所を確認することが必要です。RMANおよびOracle Secure Backupでは、次のRMANコマンドの発行でこの作業を簡単にできます。

- RESTORE DATABASE PREVIEWコマンドは、オフサイトに存在する、リストアに必要なテープのリストを提供します。

- RESTORE DATABASE PREVIEW RECALLコマンドは、リストアのためにテープをオフサイトからテープ・デバイスに戻すため、Oracle Secure Backupからリコール操作を開始します。テープがオンサイトに戻ったら、RMANリストア操作を開始できます。

関連項目:

- RMANによるオフサイト・バックアップのリコールの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- リストア操作で使用されるバックアップのプレビューの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.5 バックアップおよびリカバリの操作とメンテナンスのベスト・プラクティス

この項では、データ・リカバリ・アドバイザを使用したデータファイルの破損チェック、リカバリ手順のテスト、およびリカバリ・カタログ・データベースのバックアップを定期的にチェックする手順の概要を示します。

8.5.1 データ障害の診断と修復オプションの提示

データ・リカバリ・アドバイザは、データ障害を自動的に診断し、適切な修復オプションを判断して提示し、ユーザーの要求に応じて修復を実行するOracle Databaseツールです。ここでは、データ障害とは、ディスク上の永続的データの破損または損失を指します。自動データ修復を行う集中化されたツールを持つデータ・リカバリ・アドバイザを使用すると、Oracleデータベースの管理性と信頼性が向上し、平均リカバリ時間(MTTR)が減少します。

関連項目:
データ・リカバリ・アドバイザの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.5.2 データベース・ファイルの破損の定期的なチェック

RMAN VALIDATEコマンドを使用して、ユーザー・セッションや通常のバックアップ操作によりまだレポートされていないブロック破損が存在しないかどうか、データベース・ファイルを定期的にチェックします。RMANは、指定されたファイルをスキャンして、物理エラーと論理エラーをチェックしますが、実際のバックアップまたはリカバリ操作は実行しません。Oracle Databaseでは、破損ブロックのアドレスと破損タイプが制御ファイルに記録されます。これらのレコードには、V$DATABASE_BLOCK_CORRUPTIONビューを通じてアクセスします(このビューは、RMANのブロック・メディア・リカバリで使用できます)。

検出可能なすべての破損タイプを検出するには、CHECK LOGICALオプションを指定します。

関連項目:
データベース・ファイルおよびバックアップの検証の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.5.3 リカバリ手順の定期的なテスト

完全で正常なテスト済のバックアップは、リカバリが成功するための基盤となります。異なる停止タイプに対応するテスト計画を作成してください。最も一般的な停止タイプから始め、最も可能性の低いタイプへと作業を進めます。RMAN DUPLICATEコマンドの使用は、リカバリ・テストを実行するためのよい方法です。バックアップからのリストアと、メディア・リカバリの実行が必要であるためです。

バックアップ手順のエラーを監視し、定期的にリカバリ手順をテストしてバックアップを検証します。また、RMANコマンドRESTORE...VALIDATEを使用して、データベースのリストアの実行可能性を検証します。

関連項目:

- DUPLICATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- バックアップをリストアする前の検証の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.5.4 RMANおよびOracle Secure Backupカタログの定期的なバックアップ

リカバリ・カタログ・データベースは、バックアップおよびリカバリ計画に含めます。リカバリ・カタログのバックアップがない状態でリカバリ・カタログ・データベースを破壊するディスク障害が発生すると、カタログ内のメタデータが失われる可能性があります。リカバリ・カタログの内容がない場合は、その他のデータベースのリカバリがより困難になる可能性があります。

Oracle Secure Backupカタログは、バックアップ・ドメインのためのバックアップ・メタデータ、スケジューリングおよび構成の詳細を保持します。RMANカタログまたは制御ファイルの保護が重要であるのと同様に、Oracle Secure Backupカタログも定期的にバックアップする必要があります。

関連項目:

- リカバリ・カタログの管理の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- Oracle Secure Backupの管理サーバー・バックアップ・カタログの詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。

8.5.5 データベース外部のファイルをバックアップする手順の使用

Oracle Secure BackupはOracle以外のファイル用のテープ・バックアップを提供します。Oracle Secure Backupには、データベースのような予防的なチェック機能はありません。データベース外部のファイルのバックアップに有効な機能を使用してください。詳細は、8.6項「データベース外部のファイルのバックアップ」を参照してください。

8.6 データベース外部のファイルのバックアップ

Oracle IT環境には、短期および長期の保存要件のために保護することが必要な、データベースとアプリケーション・ファイルの両方が含まれます。データベースと未構成ファイルの各バックアップには差異が存在します。さらに、バックアップとリカバリの管理は、しばしば組織的領域と交わります。たとえば、データベースに対するDBAとファイル・システム・データに対するシステム管理は、組織的領域と交わる場合があります。Oracleのデータ保護スイートは、OracleデータベースとOracle以外のデータベース・ストレージに対する完全なニーズを満たす統合的なソリューションを提供します。

8.6.1 ACFSスナップショット

Oracle ACFSスナップショットは、Oracle ACFSファイル・システムのオンライン読取り専用ポイント・イン・タイム・コピーです。スナップショット・コピーは領域使用効率がよく、copy-on-write機能を使用します。Oracle ACFSファイル・エクステントの変更または削除前に、その現行値は、ファイル・システムのポイント・イン・タイム・ビューを保持するスナップショットにコピーされます。

Oracle ACFSスナップショットは、不用意に変更、またはファイル・システムから削除してしまったファイルのオンライン・リカバリをサポートできます。ファイル・システムごとに最高63のスナップショット・ビューがサポートされており、複数のビューにわたる柔軟性のあるオンライン・ファイル・リカバリ・ソリューションを利用できます。Oracle ACFSスナップショットは、アクティブ・ファイル・システムの一貫性のある現行オンライン・ビューを提供するために、要求に応じて作成できるので、ファイル・システム・バックアップのソースとしても使用できます。

関連項目:

- Oracle ACFSスナップショットの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- Oracle Enterprise ManagerによるOracle ACFSスナップショットの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

8.6.2 オラクルのSun ZFS Storage Applianceのスナップショット

オラクルのSun ZFS Storage Applianceは、一体的な高パフォーマンスのバックアップ・ソリューションを提供し、同時にデータベース以外のファイルの障害回復における費用効果的なプラットフォームともなります。絶え間なく増え続けるデータ量は、システムおよびデータベースの管理者に多くの課題を示します。中でもひときわ困難なのはバックアップおよびリカバリの複雑なプロセスに関わる課題です。データ保護およびプロセスの信頼性が低ければ、ミッションクリティカルなデータがリスクにさらされます。

オラクルのSun ZFS Storage Applianceはデプロイが容易なユニファイド・ストレージ・システムで、障害発生時にタイムリなリカバリが行われることで、バックアップ・ウィンドウとリカバリ時間目標(RTO)が必ず一致するようになります。

オラクルのSun ZFS Storage Applianceは制約のないスナップショット機能をサポートしています。Oracle ACFSに類似したスナップショットは、ファイル・システムの読取り専用のポイント・イン・タイム・コピーです(Oracle ACFSの詳細は、8.6.1項「ACFSスナップショット」を参照してください)。スナップショットは即時作成され、最初は領域が割り当てらません。ベース・ファイル・システムに変更が行われるに従って、ブロックが割り当てられます(copy-on-write)。スナップショットは手動で開始するか、特定の間隔をスケジューリングして自動化することができます。スナップショット・データは、あらゆるバックアップ目的のために直接アクセスできます。スナップショット・ブロックへの読取りはすべて、ベース・ファイル・システムのブロックで提供されます。ベース・ファイル・システムに変更が発生すると、古い方のブロックがスナップショットで参照されるようになり、新しく変更されたブロックがファイル・システムで参照されます。

オラクルのSun ZFS Storage Applianceは、Data Guard環境のスタンバイ・データベースから取得されたスナップショットである、システムの開発およびテストに対しても推奨されます。

スナップショット・ロールバックは、スナップショットが取得されたポイント・イン・タイムにベース・ファイル・システムを戻すプロセスです。ロールバック・プロセスでは、スナップショットの時刻からロールバックの時刻までのベース・ファイル・システムに対する変更がすべて排除されます。これによってデータ・リストア・プロセスが不要になります。

関連項目:

- オラクルのSun ZFS Storage Applianceのドキュメントについては、http://www.oracle.com/products/servers-storage/storage/nas/resources/index.htmlを参照してください。

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『OracleのSun ZFS Storage ApplianceおよびOracle Data Guardを使用したOracle Databaseのクローニング・ソリューション』を参照してください。
http://www.oracle.com/goto/maa

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Oracle Recovery ManagerおよびSun ZFS Storage Applianceを使用したOracle Databaseのクローニング』を参照してください。
http://www.oracle.com/goto/maa

8.6.3 テープ・バックアップ

Oracle Secure Backupでは、異機種のファイル・システム・データやOracleデータベースに対するテープ・バックアップ集中管理機能が提供されます。Oracle Secure Backupは完全、増分および差分などの複数のバックアップ・レベルを提供します。詳細は、8.4項「テープへのバックアップのベスト・プラクティス」を参照してください。さらに、完全なオフサイト・バックアップ・レベルのスケジューリングも可能で、この場合、通常の完全/増分スケジュールが妨害されることはありません。ファイル・システム・バックアップはファイル、ディレクトリまたはファイル・システムで実行が可能で、ユーザー定義バックアップ・ウィンドウ内で最も厳しい要件にも一致するRAWパーティション・レベルでも実行できます。

ファイル・システム・バックアップ操作では、バックアップする対象を記述するOracle Secure Backupのデータセットを定義します。データセットは軽量の言語を採用したテキスト記述で、保護されるファイルの構築および編成方法を伝達します。Oracleデータベースを認識している場合、Oracle Secure Backupは「exclude oracle database files」ディレクティブをデータセット内で使用することで、ファイル・システム・バックアップ中にデータベース・ファイルをスキップできます。

関連項目:
ファイル・システム・バックアップ操作の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。

9 Oracle Data Guardの構成

スイッチオーバーやフェイルオーバー後にすべてのスタンバイ・データベースが適切に動作し、必要なサービス・レベルの範囲内でそのロールを実行するには、Oracle Data Guardの適切な構成が不可欠です。

Oracle Data Guardのベスト・プラクティスは、第5章「Oracle Databaseの構成」に説明されているベスト・プラクティスを基盤としています。

この章には、次の項目が含まれます。

- Oracle Data Guardの構成ベスト・プラクティス

- 保護モードとData Guard転送の決定

- Data Guardの一般構成ベスト・プラクティス

- Oracle Data Guardのロール移行のベスト・プラクティス

- Oracle Active Data Guardのベスト・プラクティスの使用

- スナップショット・スタンバイ・データベースのベスト・プラクティスの使用

- Data Guardのパフォーマンスの評価

9.1 Oracle Data Guardの構成ベスト・プラクティス

Data Guardは、データの可用性および保護のために最適化されたOracleソリューションです。このソリューションは、高可用性および障害回復を提供するための、完全なOracleデータベースの簡潔かつ高速で信頼性も高い一方向のレプリケーションに優れています。Data Guardは、計画外の停止、本番前のテスト、および計画済のメンテナンスなどに対応する各種のデプロイメント・オプションを備えています。Active Data Guardは、Data Guard基本機能に対する拡張機能で、同期化されたフィジカル・スタンバイ・データベースへの読取り専用ワークロードの本番オフロード、破損ブロックの自動修復、および高速増分バックアップのオフロードが可能になります。

Data Guardの中心機能は高可用性とデータ回復です。Data Guardの設計原則は簡潔性、高パフォーマンスおよびアプリケーション透過性です。

Data Guardはレプリケーション・ソリューションとして全機能を備えているわけではありません。マルチマスター・レプリケーション、データベースのサブセットの詳細レプリケーション、多対1レプリケーション・トポロジ、およびデータ統合などの高度なレプリケーション要件については、Oracle GoldenGateが推奨されるソリューションです。Oracle GoldenGateは、計画済のメンテナンスに伴う停止時間の短縮や、異機種プラットフォームの移行などの追加オプションも備えています。

ユーザー要件によって最も効率的に使用できるソリューションは異なり、Data Guardの単独使用、Oracle GoldenGateを補助的に利用したData Guardの使用、あるいはOracle GoldenGateの単独使用となります。

Data GuardとOracle GoldenGateの詳細は、次のWebサイトでOracle Active Data GuardとOracle GoldenGateに関する製品の技術資料を参照してください。

http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html

表9-1に、ユーザー要件に適したData Guardデプロイメント・オプションの概要を示します。複数の要件に対応するため、オプションを2つ以上組み合せて使用する場合もあります。この章では、各オプションを実装するためのベスト・プラクティスも示します。

表9-1 要件とData Guardデプロイメント・オプション

要件

Data Guardデプロイメント・オプション

データ消失ゼロの保護とOracleデータベースの可用性

Data Guardの「最大保護」または「最大可用性」(SYNC転送)とREDO Apply(フィジカル・スタンバイ)

ほとんどゼロのデータ消失(一桁の秒数)とOracleデータベースの可用性

Data Guardの「最大パフォーマンス」(ASYNC転送)とREDO Apply(フィジカル・スタンバイ)

HAに対するローカルのデータ損失ゼロのスタンバイによるトポロジと、Oracleデータベースに対する地理的災害の回復用のリモート非同期スタンバイを含む、マルチサイトの保護

マルチスタンバイData Guard構成とREDO Apply

可能なかぎり最速のデータベース・フェイルオーバー

自動的な障害検出およびデータベース・フェイルオーバーのための、Data Guardファスト・スタート・フェイルオーバーとOracle Data Guardブローカの併用。新規本番データベースに付属するクライアント・アプリケーションの自動フェイルオーバーは、Oracle Fast Application Notification (FAN)およびOracleクライアント・フェイルオーバーのベスト・プラクティスを使用して実装されます。

詳細は、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Data Guard 11gリリース2のクライアント・フェイルオーバーのベスト・プラクティス』を参照してください。

http://www.oracle.com/goto/maa

同期化されたスタンバイ・データベースへの、読取り専用問合せのオフロードおよび高速増分バックアップ。アプリケーションおよびユーザーに透過的な、スタンバイ・データベースの使用による破損ブロックの自動修復

Active Data Guard。Active Data Guardは、(1) Oracle Database Enterprise Editionのオプション・ライセンスとしてスタンドアロンで、または(2) Oracle GoldenGateライセンスへの同梱として、購入できます。

本番前のテスト

スナップショット・スタンバイ。スナップショット・スタンバイは、プライマリ・データベース・トランザクションとは別に、テストおよびその他の読取り/書込み操作のために一時的に読取り/書込みがオープンされているフィジカル・スタンバイ・データベースです。スナップショット・スタンバイは、テストが終了すると、同期化されたスタンバイ・データベースに簡単に変換して戻されます。スナップショット・スタンバイは、Data Guard Redo Applyに組み込まれている機能で、Oracle Real Application Testingの理想的な補完機能です。

計画済のメンテナンス: WindowsからLinuxなどの特定のプラットフォーム移行、データ・センターの移動、システム・ソフトウェアまたはOracleデータベースのパッチ適用およびアップグレード

Data Guardスイッチオーバー、計画済のロール移行、REDO Applyの使用。11.2.0.1以降のパッチを認定するためのRedo ApplyおよびStandby-First Patch Apply。SQL ApplyおよびData Guardのデータベース・ローリング・アップグレード(10.1以降)。11.1.0.7以降からのData GuardのTransient Logical Standby (Upgrades Made Easy)。

詳細は、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Data Guardのフィジカル・スタンバイ・データベースの使用によって容易になるデータベース・ローリング・アップグレード』を参照してください。

http://www.oracle.com/goto/maa

Oracleデータベース外部に存在するデータのデータ保護

実用では、Oracle Database File System (DBFS)を使用してOracleデータベースにオペレーティング・システムのファイル・システム・データを移動します。Data Guardは、他のOracleデータと同じ方法でDBFSデータを保護します。

オペレーティング・システム・ファイル内の格納が必要なデータは、Oracle ASM Cluster File System (Oracle ACFS)またはストレージのミラー化、およびData Guardを使用して、保護できます。

注意:
Standby-First Patchを使用すると、プライマリ・データベースは以前のソフトウェア・リリースのまま、パッチを最初にフィジカル・スタンバイ・データベースに適用できます(この適用対象は特定のパッチ・タイプで、Oracleパッチ・セットおよびメジャー・リリース・アップグレードには適用されません。パッチ・セットおよびメジャー・リリースにはData GuardのTransient Logical Standbyメソッドを使用してください)。変更作業が終了したら、スタンバイ・データベースへのスイッチオーバーを実行します。フォールバックは必要な場合にスイッチオーバーすることです。詳細は、次のWebサイトのMy Oracle Support Note 1265700.1の『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1

関連項目:

- 高可用性ソリューションの説明と、Oracle Data Guardおよびスタンバイ・データベースの利点の詳細は、『Oracle Database高可用性概要』を参照してください。

- Oracle Data Guardの詳細情報は、『Oracle Data Guard概要および管理』を参照してください。

- DGMGRLコマンドライン・インタフェースの詳細は、『Oracle Data Guard Broker』を参照してください。

9.2 保護モードとData Guard転送の決定

Oracle Data GuardのZero Data Loss保護では、データが保護されている保証と最も簡潔なリカバリの両方が提供されます。この理由により、Zero Data Loss保護モードで、Oracle Data Guardの最大保護または最大可用性のどちらかが推奨されます。両方のモードがOracle Data Guardの同期REDO転送をデフォルトで使用しますが、フェイルオーバー時の動作の制御に使用されるルールセットには、考慮が必要な次のような差異があります。ただし、プライマリ・データベースとスタンバイ・データベース間のラウンドトリップ・ネットワーク待機時間が長すぎる場合、Oracle Data Guard同期REDO転送はプライマリ・データベースのパフォーマンスに影響を与える可能性があります(待機時間は距離とネットワークの正常な状態を測る機能です)。これが当てはまる場合(テストの実行は簡単です。DBAが保護モードおよび転送方法を動的に変更している可能性があります)は、Oracle Data Guardの最大パフォーマンス・モードを使用します。最大パフォーマンス・モードではOracle Data Guardの非同期転送サービスが使用され、ネットワーク待機時間に関係なく、プライマリ・データベースのパフォーマンスには影響を与えません。REDOボリュームに対応する十分な帯域幅がある環境では、最大パフォーマンス・モードの使用時、可能性のあるデータ損失は一桁の秒数内で測定されます。

現在のアプリケーションに適したデータ保護モードを決定するには、『Oracle Data Guard概要および管理』を参照してください。

保護モードのベスト・プラクティスは次のとおりです。

- 最大保護モード: このモードでは、プライマリ・データベースの障害発生時に、それが複数の障害(たとえば、プライマリとスタンバイ間のネットワークに障害が発生し、しばらくしてからプライマリに障害が発生する場合)であっても、データの損失がないことが保証されます。これを実施するため、REDOがディスクに固定されたことを少なくとも1つのData Guardスタンバイが確認応答するまで、プライマリ・データベース・トランザクションのコミット成功は伝達されません。このような確認応答がない場合、プライマリ・データベースでは保護されていないトランザクションのコミットは不可能で、データベースは一時停止して最終的にはシャットダウンします。プライマリ・データベースは操作可能でスタンバイ・データベースは操作不可能な場合に可用性を保つためのベスト・プラクティスは、最大保護構成で同期化されたスタンバイ・データベースを常に2つ以上保持することです。プライマリ・データベースの可用性は、少なくとも1つの同期化されたスタンバイ・データベースから確認応答を受け取っていれば、影響されません。

- 最大可用性モード: このモードでは、プライマリ・データベースで構成に影響を与える最初の障害が発生した場合に、データ損失は起こらないことが保証されます。 前述の保護モードとは異なり、最大可用性モードはスタンバイ・データベースからの確認応答に対してNET_TIMEOUTの最大秒数を待機します。その後、コミット成功をアプリケーションに伝達して、次のトランザクションに移動します。プライマリ・データベースの可用性(つまり保護モードの名前と同じ)は、スタンバイとの通信ができない場合(たとえば、スタンバイまたはネットワークの停止が原因の場合)でも、影響を受けません。Oracle Data Guardは引き続きスタンバイにpingを送信し、可能になったら自動的に接続を再確立して、スタンバイ・データベースを再同期化します。ただし、プライマリとスタンバイが分岐した期間中にデータ損失が発生し、これはプライマリ・データベースに影響を与える二次障害になります。このような理由から、保護レベルを監視(Enterprise Manager Grid Controlの使用が最適)して、プライマリとスタンバイ間の通信の遮断は、二次障害が発生する前に迅速に解決することがベスト・プラクティスとなります。

- 最大パフォーマンス・モード(デフォルト・モード): このモードでは、プライマリ・データベースのパフォーマンスまたは可用性に影響を与えない範囲で最高レベルのデータ保護が提供されます。このモードでは、トランザクションのリカバリに必要なREDOデータがプライマリ・データベースにあるローカルのオンラインREDOログに書き込まれると、即座にそのトランザクションのコミットが許可されます(スタンバイ・データベースが存在しなかった場合と同じ動作)。Oracle Data Guardは、ローカルのオンラインREDOログ書込みと非同期的なプライマリ・ログ・バッファからスタンバイ・データベースに直接、REDOを転送します。スタンバイの確認応答を待機することはありません。最大可用性モードと同様、保護レベルを監視(Enterprise Manager Grid Controlの使用が最適)して、プライマリとスタンバイ間の通信の遮断は、二次障害が発生する前に迅速に解決することがベスト・プラクティスとなります。

関連項目:
Data Guardの保護モードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

9.2.1 REDO転送サービスのベスト・プラクティスの使用

Oracle Data GuardのREDO転送サービスを計画および実装するための、上位レベルにおけるREDO転送ベスト・プラクティスは次のようになります。

- プライマリ・データベースおよびスタンバイ・データベース間の同期の程度を高くする場合は、SYNC REDO転送モードを使用します。データ損失ゼロの保護にはSYNC REDO転送を使用します。ここではネットワーク待機時間によって引き起こされた影響をパフォーマンス・サービス・レベルが許容できます。

- プライマリ・データベースへの影響は最小限に抑えながらも、同期の程度を低くする場合は、ASYNC REDO転送モードを使用します。データ損失ゼロの保護が不要なときや、ネットワーク待機時間によって引き起こされたパフォーマンスの影響でSYNCの使用が非現実的になったときに、ASYNC REDO転送を使用します。

- 9.2.2項「ネットワーク構成案に関するパフォーマンスの評価」に記述されているベスト・プラクティスに従って、ネットワーク・スループットを最適化します。

9.2.2 ネットワーク構成案に関するパフォーマンスの評価

ネットワーク構成案と現在、または将来のピークREDO速度に関するパフォーマンス評価を実行することをお薦めします。プライマリ・データベースとスタンバイ・データベース間のネットワークに対する影響と、プライマリ・データベースのスループットに対する影響を把握する必要があります。プライマリ・データベースとスタンバイ・データベース間のネットワークは2つのデータベースの同期を維持するのに不可欠の要素であるため、そのインフラストラクチャは次の特徴を有している必要があります。

- 最大のREDO生成速度に対応できる十分な帯域幅

- SYNC転送を使用する場合、プライマリ・データベースのパフォーマンスへの影響を減らすために、待機時間が最小限であること

- ネットワーク冗長性のための複数のネットワーク・パス

専用のネットワーク接続を使用する構成では、必要な帯域幅は、プライマリ・データベースの最大REDO速度とネットワーク効率により決定されます。データ保護モードによっては、他の推奨プラクティスとパフォーマンス上の考慮事項があります。最大保護モードと最大可用性モードでは、SYNC転送を使用する必要があります。

最大パフォーマンス保護モードでは、ASYNC REDO転送を使用します。データ損失が許容できるときや、ネットワーク待機時間によって引き起こされたパフォーマンスの影響でSYNCの使用が非現実的になったとき(データ損失ゼロの保護にはSYNC REDO転送を使用)に、ASYNC REDO転送を使用します。

ASYNC転送モードと異なり、SYNC転送モードでは、発生するネットワーク待機時間のために、プライマリ・データベースのパフォーマンスに影響が出る可能性があります。距離とネットワーク構成は、待機時間に直接影響します。待機時間が長いと、潜在的なトランザクション・スループットが低下し、レスポンス時間が迅速化する可能性があります。ネットワーク構成、リピータの数、プロトコル変換のオーバーヘッド、およびルーターの数も、ネットワーク待機時間とトランザクション・レスポンス時間に全体的な影響を与えます。

9.3 Data Guardの一般構成ベスト・プラクティス

Data Guardには、次の構成ベスト・プラクティスを使用します。

- Oracle Data GuardによるOracle Data Guardブローカの使用

- Recovery Managerを使用したスタンバイ・データベースの作成

- フェイルオーバー後の復元のためのフラッシュバック・データベースの使用

- FORCE LOGGINGモードの使用

- 単純で堅牢なアーカイブ計画および構成の使用

- スタンバイREDOログの使用と適切なサイズ構成

- Data Guard転送とネットワーク構成のベスト・プラクティスの使用

- Data Guard Redo Applyのベスト・プラクティスの使用

- 複数のスタンバイ・データベースの実装

9.3.1 Oracle Data GuardによるOracle Data Guardブローカの使用

Data Guard構成の作成、管理および監視には、Oracle Data Guardブローカを使用します。Oracle Data Guardブローカの使いやすいインタフェースである、Oracle Enterprise ManagerのData Guard管理ページ(ブローカのGUI)およびDGMGRLと呼ばれる Data Guardコマンドライン・インタフェースを使用すると、すべてのData Guard管理操作をローカルまたはリモートで実行できます。

ブローカのインタフェースによって利便性が向上し、Data Guard構成の管理と監視が集中化されます。ブローカはOracle DatabaseのEnterprise EditionおよびPersonal Editionの機能として選択可能で、OracleデータベースおよびOracle Enterprise Managerとも統合されます。

Oracle Data Guardブローカを使用するメリットは、次のとおりです。

- 障害時の保護の強化。

- Oracle Real Application Clusters (Oracle RAC)データベースでの高可用性とスケーラビリティ。

- Data Guard構成の自動作成。

- 追加のスタンバイ・データベースの簡単な構成。

- 管理の簡素化、集中化および拡張。

- スイッチオーバー操作とフェイルオーバー操作の簡略化。

- フェイルオーバー後の高速アプリケーション通知(FAN)。

- 組込みの監視、アラートおよび制御メカニズム。

- アプリケーションに対する透過性。

関連項目:
Data Guard Brokerの構成要件の詳細は、『Oracle Data Guard Broker』を参照してください。

9.3.2 Recovery Managerを使用したスタンバイ・データベースの作成

Recovery Manager(RMAN)ユーティリティを使用して、フィジカル・スタンバイ・データベースの作成プロセスを簡略化することをお薦めします。

スタンバイ・データベースは、プライマリ・データベースのバックアップから作成することも、ネットワーク経由で作成することもできます。

- プライマリ・データベースのバックアップからスタンバイ・データベースを作成するには、RMANのDUPLICATE TARGET DATABASE FOR STANDBYコマンドを使用します。
スタンバイ・ホスト上のサーバー・セッションから、データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルにアクセスできる場合、プライマリ・データベースの任意のバックアップ・コピーを使用してフィジカル・スタンバイ・データベースを作成できます。SET UNTILコマンドを実行する場合を除いて、RMANは最新のデータファイルをリストアします。

- 既存のデータベース・バックアップがスタンバイ・システムにアクセスできない場合は、RMANのFROM ACTIVE DATABASEオプションを使用して、ネットワーク経由でスタンバイ・データベースを作成します。
RMANは、プライマリ・データベースからスタンバイ・データベースへ直接データファイルをコピーします。プライマリ・データベースはマウントまたはオープンされている必要があります。

アクティブ複製とバックアップ・ベース複製のいずれかを選択する必要があります。FROM ACTIVE DATABASEオプションを指定しなかった場合、RMANはバックアップ・ベースの複製を実行します。ネットワーク経由でのスタンバイ・データベース作成には、次の利点があります。

- 最初にプライマリ・データベース上でバックアップを実行する手順を終えていなくても、ネットワーク経由で直接、REDOデータをリモート・ホストに転送できます。(リストアには、プライマリ・データベースへのバックアップのローカル保存、ネットワーク経由でのバックアップの転送、スタンバイ・データベースへのバックアップのローカル保存、およびスタンバイ・データベース上でのバックアップのリストアなど、複数の手順が必要です。)

- アクティブ複製では、Oracle ASMから実行中のデータベースをバックアップし、そのバックアップをネットワーク経由でホストにリストアし、Oracle ASMに直接ファイルを配置することができます。
この機能以前のリストアでは、プライマリをバックアップしてそのバックアップ・ファイルをプライマリ・ホスト・ファイル・システムにコピーし、そのバックアップ・ファイルをネットワーク経由で転送し、バックアップ・ファイルをスタンバイ・ホスト・ファイル・システムに配置してから、Oracle ASMにファイルをリストアする手順が必要でした。

関連項目:

- RMANを使用したファイルのバックアップおよびリストアの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- Recovery Managerによるスタンバイ・データベースの作成の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

9.3.3 フェイルオーバー後の復元のためのフラッシュバック・データベースの使用

プライマリ・データベースとスタンバイ・データベースの両方でフラッシュバック・データベースを有効化すると、元のプライマリ・データベースが損害を受けていなかった場合に、フェイルオーバー後に元のプライマリ・データベースを新しいスタンバイ・データベースとして復元できます。フラッシュバック・データベースが有効であれば、スイッチオーバー・プロセスで障害が発生した場合でも、そのプロセスを簡単に元に戻すことができます。詳細は、5.1.4項「フラッシュバック・データベースの有効化」を参照してください。

9.3.4 FORCE LOGGINGモードの使用

プライマリ・データベースをFORCE LOGGINGモードで運用すると、データベースのすべてのデータ変更がログに記録されます。FORCE LOGGINGモードにより、スタンバイ・データベースとプライマリ・データベースとの一貫性が維持されます。NOLOGGING操作によるロード・パフォーマンスが必要なためにこの設定を使用できない場合は、対応するフィジカル・スタンバイ・データファイルを後で確実に同期する必要があります。フィジカル・スタンバイ・データファイルを同期するには、プライマリ・データベースから作成された増分バックアップを適用するか、NOLOGGING操作後に取得されたプライマリ・データファイルのバックアップを使用して関連するスタンバイ・データファイルを置き換えます。ファイル転送の前に、フィジカル・スタンバイ・データベースでREDO Applyを停止する必要があります。

ALTER DATABASE FORCE LOGGING文を発行すると、強制ロギングを即座に有効化できます。FORCE LOGGINGを指定した場合、Oracleは、ログに記録されていない進行中のすべての操作が終了するまで待機します。

関連項目:

- FORCE LOGGINGモードの指定の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 強制ロギングの有効化の詳細は、『Oracle Data Guard概要および管理』を参照してください。

9.3.5 単純で堅牢なアーカイブ計画および構成の使用

ここでのアーカイブ計画は、次の前提に基づきます。

- 各データベースは高速リカバリ領域を使用します。

- プライマリ・データベース・インスタンスは、リモートのただ1つの適用インスタンスにアーカイブされること。

表9-2に、SQL*Plusを通じてData Guard構成を管理する際の堅牢なアーカイブ計画の推奨事項を示します。Oracle Data Guardブローカで構成を管理する場合、次のすべての項目が自動的に処理されます。

表9-2 アーカイブの推奨事項

推奨事項

説明

プライマリおよびスタンバイ・データベースでアーカイブを開始する

スタンバイ・データベースを維持するには、次のようにプライマリ・データベースでアーカイブを有効化して開始する必要があります。

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

ロール移行をサポートする場合も、スタンバイ・データベースでアーカイブを有効化する必要があります。スタンバイ・データベースでアーカイブを有効化するには、次のようにします。

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;

一貫性のあるログ形式(LOG_ARCHIVE_FORMAT)を使用する

LOG_ARCHIVE_FORMATパラメータで、スレッド、順序およびリセットログIDの各属性が指定され、パラメータ設定がすべてのインスタンスで一貫している必要があります。例: LOG_ARCHIVE_FORMAT=arch_%t_%S_%r.arc

注意: 高速リカバリ領域を使用している場合、この形式は無視されます。

リモート・アーカイブは、Oracle RACスタンバイ・データベースごとにただ1つのスタンバイ・インスタンスおよびノードに対して実行する

すべてのプライマリ・データベース・インスタンスは、同じネット・サービス名を使用して1つのスタンバイ宛先にアーカイブします。プライマリ・スタンバイ・インスタンスが停止したときに自動的にセカンダリ・スタンバイ・ホストに切り替える場合、Oracle Net Servicesの接続時フェイルオーバーが使用されます。

高速リカバリ領域でOracle ASMまたはその他の共有ファイル・システムを使用しているためにすべてのノードからアーカイブにアクセスできる場合、Oracle RACスタンバイ・データベースの異なるノード全体にリモート・アーカイブを分散できます。

VALID_FOR属性でロール・ベースの宛先を指定する

VALID_FOR属性を使用すると、ロール移行後もData Guard構成が適切に動作するように、1つのサーバー・パラメータ・ファイル(SPFILE)でプライマリ・データベースとスタンバイ・データベースの両方のロールの宛先属性を構成できます。これにより、ロール移行後にロール固有のパラメータ・ファイルの有効化と無効化を切り替える必要がなくなるため、スイッチオーバーやフェイルオーバーの処理が簡単になります。

次に、フィジカル・スタンバイ・データベースと通信するプライマリ・データベースに推奨される初期化パラメータを示します。最大保護モードで稼働するSALES1およびSALES2という2つのインスタンスがあります。

*.DB_RECOVERY_FILE_DEST=+RECO
*.LOG_ARCHIVE_DEST_1='SERVICE=SALES_stby SYNC AFFIRM NET_TIMEOUT=30
REOPEN=300 VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=SALES_stby'
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE

高速リカバリ領域は、クラスタ内の任意のノードにアクセス可能である必要があります。また、自動ストレージ管理(Oracle ASM)、クラスタ・ファイル・システム、グローバル・ファイル・システム、高可用性ネットワーク・ファイル・システム(HA NFS)などの共有ファイル・システム・テクノロジを使用する必要があります。クラスタ内の任意のノードに手動でファイル・システムをマウントすることも簡単にできます。すべてのアーカイブREDOログ・ファイルにすべてのノードからアクセスできる必要があるため、これはリカバリにとって必須の設定です。

スタンバイ・データベース・ノードでは、REDOを適用しているノードに障害が発生して適用サービスを再起動できない場合、異なるノードからリカバリを実行する必要があります。この場合、異なるノードに存在する既存のスタンバイ・インスタンスのいずれかを使用して、管理リカバリを開始できます。スタンバイ・アーカイブREDOログ・ファイルにアクセスできない場合は、異なるノードの新規管理リカバリ・プロセス(MRP)により、プライマリ・ノードからの直接取得を行うFALサーバーを通じてアーカイブREDOログ・ファイルがフェッチされます。

ハードウェア・ベンダーの共有ファイル・システム・テクノロジを構成する場合は、パフォーマンスと可用性に対する影響を確認してください。この計画を採用する前に、次の項目を調査します。

- ノード障害の数にかかわらず、任意のノードから共有ファイル・システムにアクセスできますか。

- 共有ファイル・システムを実装することによるパフォーマンスへの影響はどの程度ですか。

- インターコネクト・トラフィックに対する影響はありませんか。

9.3.6 スタンバイREDOログの使用と適切なサイズ構成

スタンバイREDOログは、可用性とパフォーマンスを向上するために、すべてのプライマリ・データベースとスタンバイ・データベースで構成する必要があります。

各REDOログ・スレッド(OracleRACデータベース・インスタンスと関連付けられているスレッド)、スタンバイREDOログ数 = REDOログ・グループ数 + 1

追加のスタンバイREDOログにより、スタンバイ・データベースがスタンバイREDOログを待機する可能性がなくなります。たとえば、プライマリ・データベースが2つのインスタンス(スレッド)を持ち、各スレッドが3つのオンライン・ログ・グループを持つ場合、プライマリ・データベースおよび各スタンバイ・データベースに8つのスタンバイREDOログを事前構成する必要があります。さらに、プライマリ・データベースまたはスタンバイ・データベースが対称なReal Application Clusterでない場合(たとえば、2ノードのスタンバイOracle RACクラスタに対して8ノードのプライマリOracle RACクラスタ)であっても、プライマリ・データベースおよびスタンバイ・データベースで同数のスタンバイREDOログを持つ必要があり、すべてのスレッドを示す必要があります。

例9-1の文では、スレッド当たり3つのスタンバイ・ログを作成します。

例9-1 スタンバイ・ログ・メンバーの作成

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 1G;

スタンバイREDOログを作成する際には、次の追加のガイドラインを考慮してください。

- プライマリ・データベース上とスタンバイ・データベース上に、同じ数のスタンバイREDOログを作成します。

- プライマリ・データベースとスタンバイ・データベースの両方で、すべてのオンラインREDOログとスタンバイREDOログのサイズが同じになるように作成します。

- 最初に使用できるASM高冗長性ディスク・グループにスタンバイREDOログを作成するか、ログが外部ストレージ冗長性を使用して保護されていることを確認します。

- Oracle RAC環境では、スタンバイREDOログは共有ディスクに作成します。

- Oracle RAC環境では、スタンバイREDOログが例9-1のように作成されたときにスレッドを割り当てます。

- スタンバイREDOログは多重化しないでください。

REDOログの数およびグループ番号を確認するには、次のようにV$LOGビューを問い合せます。

SQL> SELECT * FROM V$LOG;

ALTER DATABASE ADD STANDBY LOGFILE THREAD文の結果を確認するには、次のようにV$STANDBY_LOGビューを問い合せます。

SQL> SELECT * FROM V$STANDBY_LOG;

関連項目:
スタンバイREDOログの管理については、『Oracle Data Guard概要および管理』を参照してください。

9.3.7 Data Guard転送とネットワーク構成のベスト・プラクティスの使用

Data Guard転送とネットワーク構成のベスト・プラクティスには次のようなものがあります。

- LOG_ARCHIVE_MAX_PROCESSESパラメータの設定

- ネットワーク構成と最大ネットワークREDO速度の設定

9.3.7.1 LOG_ARCHIVE_MAX_PROCESSESパラメータの設定

ほとんどの場合、LOG_ARCHIVE_MAX_PROCESSESのデフォルトで対応できます。ただし、複数のスタンバイ・データベースが存在するData Guard構成では、アーカイブ・プロセスの数を増やすことが必要な場合があります。LOG_ARCHIVE_MAX_PROCESSES初期化パラメータの値は、すべてのリモート宛先数より少なくとも1大きくする必要があります。高可用性環境でLOG_ARCHIVE_MAX_PROCESSESパラメータを設定する場合は、次の式を使用します。

LOG_ARCHIVE_MAX_PROCESSES = sum(remote_destinations) + count(threads)

これらのパラメータ設定は、本番環境での初期設定の評価およびテスト後に、状況に応じて調整できます。

関連項目:
アーカイブ・プロセスの数の調整の詳細は、『Oracle Database管理者ガイド』を参照してください。

9.3.7.2 ネットワーク構成と最大ネットワークREDO速度の設定

ネットワーク構成と最大ネットワークREDO速度を設定するには、次のことを行います。

- TCP送信/受信バッファ・サイズの適切な構成

- SDUサイズの増加

- TCP.NODELAYのYESの設定

- REDO転送圧縮を使用する場合の決定

TCP送信/受信バッファ・サイズの適切な構成

特に待機時間が長い高帯域のネットワークで、高いネットワーク・スループットを達成する場合、TCP送受信ソケット・バッファ・サイズの最小推奨設定は、プライマリ・システムとスタンバイ・システム間のネットワーク・リンクの帯域幅遅延積(BDP)です。BDPより高い値を設定すると、多少改善されることがあります。たとえば、MAA Linuxテスト・ラボで、TCP送受信ソケット・バッファ設定をBDPの最大3倍にすると、待機時間が長く高帯域という条件でシミュレートされたネットワークで、スループットが多少向上します。

BDPは、ネットワーク帯域幅と待機時間の積です。ソケット・バッファ・サイズは、Oracle NetパラメータのRECV_BUF_SIZEとSEND_BUF_SIZEを使用して設定されるため、ソケット・バッファ・サイズの設定はOracle TCP接続にのみ有効です。ソケット・バッファ・サイズがオペレーティング・システムにより制限されている場合、Oracleでより大きい値を使用できるよう調整する必要があります。たとえば、Linuxでは、net.core.rmem_maxおよびnet.core.wmem_maxパラメータでソケット・バッファ・サイズを制限しているため、これらのパラメータにRECV_BUF_SIZEとSEND_BUF_SIZEより大きい値を設定する必要があります。

送信および受信バッファ・サイズは、計算した値か10MB(10,485,760バイト)のどちらか大きい方の値に設定します。たとえば、帯域幅が622Mビットで待機時間が30ミリ秒の場合、RECV_BUF_SIZEおよびSEND_BUF_SIZEパラメータの最小サイズは、622,000,000 / 8 x 0.030 = 2,332,500バイトのように計算します。次に、BDPを2,332,500 x 3のように乗算すると合計は6,997,500になります。

この例では、初期化パラメータを次のように設定します。

RECV_BUF_SIZE=10485760

SEND_BUF_SIZE=10485760

SDUサイズの増加

Oracle Net Servicesでは、セッション・データ・ユニット(SDU)に関するOracle Net設定を調整することでデータ転送を制御できます。オラクル社の内部テストによれば、SDUを最大値の65535に設定すると、SYNC転送のパフォーマンスが向上する可能性があります。SDUは、ローカル・ネーミング構成ファイル(TNSNAMES.ORA)およびリスナー構成ファイル(LISTENER.ORA)のSDUパラメータを使用して接続単位ごとに設定するか、SQLNET.ORAファイルのDEFAULT_SDU_SIZEプロファイル・パラメータですべてのOracle Net接続を対象に設定します。

ASYNC転送では新規ストリーミング・プロトコルが使用されるため、SDUサイズをデフォルトから増やしてもパフォーマンス上の利点はないので注意してください。

関連項目:
SDUおよびDEFAULT_SDU_SIZEパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

TCP.NODELAYのYESの設定

TCPプロトコル・スタックでのバッファ・フラッシングによる遅延を回避するため、プライマリ・システムとスタンバイ・システムの両方でSQLNET.ORAファイルのTCP.NODELAYをYESに設定してTCP Nagleアルゴリズムを無効化します。

関連項目:
TCP.NODELAYパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

REDO転送圧縮を使用する場合の決定

Oracle Database 11gリリース2 (11.2.0.2)のREDO転送圧縮は、REDOギャップを解消中の際にREDOデータのみを圧縮することに制限されなくなりました。転送先で圧縮が有効になっている場合は、その宛先に送信されるすべてのREDOデータが圧縮されます。

一般に、圧縮のメリットがきわだつのは、 低帯域ネットワーク経由で使用する場合です。ネットワーク帯域幅が増大すると、メリットは減少します。Data Guard環境でREDOを圧縮すると、次の場合にメリットがあります。

- 圧縮処理に十分なCPUリソースを利用できる場合

- データベースREDO速度が、低帯域ネットワークのために制限されている場合

圧縮を有効にする前に、利用できるCPUリソースを評価し、圧縮を有効にできるかどうか判断します。圧縮の有効化の詳細は、次のWebサイトのMy Oracle Support Note 729551.1の『Data Guard環境のREDO転送圧縮』を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=729551.1

9.3.8 Data Guard Redo Applyのベスト・プラクティスの使用

フィジカル・スタンバイ・データベース(およびメディア・リカバリ)のREDO Apply割合を改善するには、次のことを行います。

- スタンバイREDOログとアーカイブREDOログのI/Oレートの最大化

- リカバリ速度の評価

- DB_BLOCK_CHECKSUM=FULLおよびDB_BLOCK_CHECKING=MEDIUMまたはFULLの設定

- DB_CACHE_SIZEのプライマリ・データベースの同じパラメータより大きい値への設定

- データベース待機イベントの評価

- I/O操作のチューニング

- システム・リソースの評価

関連項目:

次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Active Data Guard 11gのベスト・プラクティス(Redo Applyのベスト・プラクティスを含む)』を参照してください。

http://www.oracle.com/goto/maa

9.3.8.1 スタンバイREDOログとアーカイブREDOログのI/Oレートの最大化

スタンバイREDOログ・ディレクトリとアーカイブREDOログ・ディレクトリのI/Oレートを測定します。転送されたREDOがスタンバイ・データベースに同時に書き込まれると、I/Oが飽和状態となってREDO読取り速度が低下する可能性があります。リカバリ速度全体はREDOを読み取ることのできる速度によって常に制限されるため、REDO読取り速度が必要とされるリカバリ速度を超えていることを確認します。

9.3.8.2 リカバリ速度の評価

リカバリ速度の履歴を取得するには、次の問合せを使用してリカバリ進行状況の履歴を表示します。

SELECT * FROM V$RECOVERY_PROGRESS;

ACTIVE APPLY RATEがプライマリ・データベースでの最大REDO生成速度を超えているか、プライマリ・データベースでの平均生成速度の2倍を超えている場合、チューニングは必要ありません。それ以外の場合は、次のチューニング・ヒントに従ってください。プライマリ・データベースのREDO生成速度は、Enterprise Managerで監視するか、REDO SIZE統計のAWRレポートから抽出することが可能です。CHECKPOINT TIME PER LOGが10秒を超えている場合は、I/Oとチェックポイントのチューニングを調査します。

9.3.8.3 DB_BLOCK_CHECKSUM=FULLおよびDB_BLOCK_CHECKING=MEDIUMまたはFULLの設定

Redo Applyのパフォーマンスは、ほとんどのアプリケーションのREDO生成速度に対応するために十分な速度である必要がありますが、DB_BLOCK_CHECKINGを一時的に無効化して、リカバリを高速化することができます。DB_BLOCK_CHECKINGを無効化する場合、My Oracle Supportのノート1302539.1の説明に従って、メモリー内ブロックのセマンティク・チェックを無効化します。

注意:
DB_BLOCK_CHECKINGパラメータで保護できなかったブロック破損をチェックするには、次の方法を使用します。

- RMAN BACKUPコマンド(VALIDATEオプション付き)

- DBVERIFYユーティリティ

- ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE SQL文

スタンバイ・データベースでDB_LOST_WRITE_PROTECTパラメータをFULLに設定し、I/Oサブシステムで失われた書込みをOracleで検出できるようにします。OLTPアプリケーションにおいてRedo Applyに対する影響はごくわずかであり、通常は5%未満です。

関連項目:
5.1.6.1項「データ破損の拡大の防止」

9.3.8.4 DB_CACHE_SIZEのプライマリ・データベースの同じパラメータより大きい値への設定

DB_CACHE_SIZEを、プライマリ・データベースの同じパラメータより大きい値に設定します。DB_KEEP_CACHE_SIZEとDB_RECYCLE_CACHE_SIZEを0に設定します。

データベース・キャッシュ・サイズを大きくすると、物理データ・ブロックの読取り量が減少するため、メディア・リカバリのパフォーマンスが向上する可能性があります。メディア・リカバリでは、DB_KEEP_CACHE_SIZEやDB_RECYCLE_CACHE_SIZEを必要としないか、または大きいサイズのSHARED_POOL_SIZEを必要としないため、DB_CACHE_SIZEにメモリーを再度割り当てることができます。

これらのパラメータは、スタンバイ・データベースをプライマリ・データベースに変換する前に、プライマリ・データベースの設定にリセットしてください。

9.3.8.5 データベース待機イベントの評価

Active Data Guardオプションとリアルタイム問合せによって、プライマリ・データベースのStatspackを使用して、読取り専用でオープンされてリカバリを実行するスタンバイ・データベースからデータを収集できます。すべてのチューニングまたはトラブルシューティング作業は、Standby Statspackレポートを収集することから開始します。Standby Statspackのインストールおよび使用方法の詳細は、次のWebサイトのMy Oracle Support Note 454848.1の『11gでのStandby Statspackのインストールおよび使用』を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=454848.1

Active Data Guardオプションのライセンスがない場合、スタンバイ・データベースのV$SYSTEM_EVENT、V$SESSION_WAITおよびV$EVENT_HISTOGRAMを問い合せて、最大のTIME_WAITED値を調べることで、上位のシステムおよびセッション待機イベントを特定できます。場合によっては、ある一定期間を正確に評価するため、問合せ結果の複数のスナップショットを取得して手動で差異を抽出する必要があります。

リカバリで多くのREDOデータを効率的に適用する場合、システムはI/Oバウンドとなるため、I/O待機が発生することはシステムにとって妥当な動作です。パラレル・リカバリ・コーディネータおよびスレーブに関連する待機イベントの大部分は、コーディネータに適用されます。スレーブは、変更を適用するか(CPUでのクロッキング)、コーディネータから変更が渡されるのを待機します。

通常、適切にチューニングされたシステムでは、上位の待機イベントは、db file parallel writeの後にcheckpoint completedが続きます。db file parallel writeが上位の待機イベントではない場合のチューニング・アドバイスは、後述の表を参照してください。表9-3と表9-4に、データベースの待機イベントを示します。

表9-3 パラレル・リカバリ・コーディネータの待機イベント

待機名

説明

チューニング

Log file sequential read

パラレル・リカバリ・コーディネータは、オンラインREDOログまたはアーカイブREDOログからのI/Oを待機しています。

アーカイブ・ログまたはオンラインREDOログが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。

Parallel recovery read buffer free

このイベントは、すべての読取りバッファがスレーブによって使用されていることを示し、通常はリカバリ・スレーブがコーディネータに遅れていることを示します。

データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。

Parallel recovery change buffer free

パラレル・リカバリ・コーディネータは、リカバリ・スレーブがバッファを解放するのを待機しています。このイベントも、リカバリ・スレーブがコーディネータに遅れていることを示します。

データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。

Datafile init write

パラレル・リカバリ・コーディネータは、ファイルの自動拡張などによるファイルのサイズ変更が終了するのを待機しています。

データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。

Parallel recovery control message reply

コーディネータは、同期制御メッセージをすべてのスレーブに送信済で、すべてのスレーブからの応答を待機しています。

これはチューニング不可能なイベントです。

リカバリ・スレーブ・イベントを処理する場合、起動しているスレーブの数を把握することが重要です。任意のリカバリ・スレーブ・イベントの待機時間をスレーブの数で割ります。表9-4に、パラレル・リカバリ・スレーブの待機イベントを示します。

表9-4 パラレル・リカバリ・スレーブの待機イベント

待機名

説明

チューニング

Parallel recovery slave next change

パラレル・リカバリ・スレーブは、コーディネータから変更が転送されるのを待機しています。このイベントは、実質的にはリカバリ・スレーブのアイドル・イベントです。リカバリ・スレーブが使用するCPU時間を特定するには、このイベントの経過時間を起動済スレーブの数で割り、その値を合計経過時間から引きます。この値には、多少の待機時間も含まれるため、近似値となります。

アーカイブ・ログまたはオンラインREDOログが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。

DB File Sequential Read

パラレル・リカバリ・スレーブ(またはシリアル・リカバリ・プロセス)は、同期データ・ブロックのバッチ読取りが完了するのを待機しています。

データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。

Checkpoint completed

リカバリは、チェックポイントの完了を待機しており、REDO Applyは現時点で変更を適用していません。

データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。

また、checkpoint completed待機イベントがdb file parallel write待機イベントより低くなるまで、db_writer_processesの数を増やします。プライマリおよびスタンバイでのオンライン・ログ・ファイル・サイズを増やして、ログ・スイッチの境界における完全なチェックポイントの数を減らすことも検討します。

Recovery read

パラレル・リカバリ・スレーブは、バッチ・データ・ブロックI/Oを待機しています。

データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。

9.3.8.6 I/O操作のチューニング

DBWRでは、変更されたブロックをバッファ・キャッシュからデータファイルに書き出す必要があります。DISK_ASYNCH_IOをTRUEに設定して(デフォルト)、ネイティブの非同期I/Oを常に使用します。めったにないことですが、非同期I/Oが使用できない場合は、DBWR_IO_SLAVESを使用すると同期I/Oで有効なデータ・ブロック書込み速度を向上できます。

基本的なI/Oテストの実行、プライマリ・データベースとのI/O統計の比較、またはいくつかのI/O履歴メトリックの調査により、十分なI/O帯域幅が確保されており、I/Oレスポンス時間が現在のシステムにとって適切であることを確認します。Storage Area Network(SAN)やNetwork Attached Storage(NAS)などの同じストレージ・インフラストラクチャを多くのアプリケーションで共有している場合、I/Oレスポンス時間は変化する可能性があることに注意してください。

9.3.8.7 システム・リソースの評価

UNIXのsarコマンドやvmstatコマンドなどのシステム・コマンド、またはシステム・モニタリング・ツールを使用してシステム・リソースを評価します。別の方法として、Oracle Enterprise Manager、AWRレポート、またはV$SYSTEM_EVENT、V$ASM_DISK、V$OSSTATなどのパフォーマンス・ビューを使用して監視できます。

1. I/Oボトルネックや過剰な待機I/O操作が存在する場合、I/O容量を増加させている操作またはアプリケーションの変更を調査します。長い待機時間の原因が不十分なI/O帯域幅にある場合、関連するOracle ASMディスク・グループに別のディスクを追加します。この原因がバスやコントローラのボトルネック、またはその他のI/Oボトルネックではないことを確認します。スタンバイREDOログからの読取りI/Oレートは、期待されるリカバリ速度を超えている必要があります。

2. 過剰なスワッピングまたはメモリー・ページングが発生していないかどうかをチェックします。

3. リカバリ中にリカバリ・コーディネータまたはMRPがCPUバウンド状態にならないことを確認します。

9.3.9 複数のスタンバイ・データベースの実装

次のいずれかの目的がある場合は、スタンバイ・データベースを複数デプロイすることをお薦めします。必要に応じて複数のスタンバイ・データベースをそのような目的に使用する場合も、プライマリ・フェイルオーバー・ターゲットの役割を果すスタンバイ・データベースを1つ以上確保しておきます。

- フェイルオーバー後に継続保護を提供する場合
複数スタンバイ構成で、ロール移行のターゲットでないスタンバイ・データベース(バイスタンダ・スタンバイ・データベース)は、新しいプライマリ・データベースから受信したREDOデータを自動適用します。

- 同期通信限界を超える広範囲の地理的災害に対する保護も提供しつつ、データ損失ゼロの保護を実現する場合
たとえば、同期的にREDOデータを受信するスタンバイ・データベースがプライマリから200マイル遠方、非同期でREDOデータを受信する2番目のスタンバイ・データベースが1,500マイル遠方に位置する場合です。

- ローリング・アップグレード・プロセスによって障害保護を維持しつつ、ローリング・データベース・アップグレードを実行する場合

- 障害時リカバリ保護を維持しつつ、テストなどの非定型作業を実行する場合

複数のスタンバイ・データベースのベスト・プラクティスの使用

『Oracle Database高可用性概要』には、複数のスタンバイ・データベースのアーキテクチャが、実質的にどの程度単一のスタンバイ・データベースのアーキテクチャと同じであるかが記載されています。したがって、この項で説明する複数のスタンバイ・データベースの実装における構成ガイドラインは、フィジカルおよびロジカル・スタンバイ・データベースの既存のベスト・プラクティスを補完するものです。

複数のスタンバイ・データベースをデプロイする場合、次のベスト・プラクティスを使用します。

- Oracle Data Guardブローカ(第12章「高可用性の監視」で説明)を使用して、構成を管理し、ロール移行を実行します。ただし、SQL*Plus文を使用する場合のベスト・プラクティスは、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『複数のスタンバイ・データベースのベスト・プラクティス』を参照してください。
http://www.oracle.com/goto/maa

- フェイルオーバー後にデータベースを復元することを唯一の目的としてフラッシュバック・データベースを使用する場合、DB_FLASHBACK_RETENTION_TARGETの最低限の推奨値は120分です。フェイルオーバー後、バックアップまたはプライマリ・データベース(ファスト・スタート・フェイルオーバーの使用時)からスタンバイ・データベース全体を再作成するかわりに、フラッシュバック・データベースを使用して旧プライマリをスタンバイとして迅速に復元する場合は、UNDO_RETENTIONおよびDB_FLASHBACK_RETENTION_TARGET初期化パラメータを必ず120以上に設定して、長時間の停止後も復元が可能であるようにします。スタンバイでは、フラッシュバック・バリアが30分ごとに発行されることは保証されません。これはプライマリ上にあるためです。したがって、フラッシュバック・データベースをスタンバイで有効化する際、DB_FLASHBACK_RETENTION_TARGETは120以上に設定する必要があります。プライマリとスタンバイは一致する必要があるため、プライマリにも同じことが適用されます。

- ロジカル・スタンバイ・データベースが含まれる構成でサプリメンタル・ロギングを有効化します。フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方を含んだ構成を作成する場合、次の状況ではALTER DATABASE ADD SUPPLEMENTAL LOG DATA文を発行してサプリメンタル・ロギングを有効化します。

- すべてのフィジカル・スタンバイ・データベースが含まれる既存の構成にロジカル・スタンバイ・データベースを追加する場合、構成内のすべての既存のフィジカル・スタンバイ・データベースでサプリメンタル・ロギングを有効化する必要があります。

- ロジカル・スタンバイ・データベースを含んだ既存の構成にフィジカル・スタンバイ・データベースを追加する場合、作成時にフィジカル・スタンバイ・データベースでサプリメンタル・ロギングを有効化する必要があります。

ロジカル・スタンバイ・データベースの作成時に、サプリメンタル・ロギングはプライマリで自動的に有効化されます。サプリメンタル・ロギングを有効化すると、制御ファイルが変更されるため、その変更は各フィジカル・スタンバイ・データベースに伝播されません。サプリメンタル・ロギングは、ディクショナリ・ビルド・プロセスの一環としてデータベースがフィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースに最初に変換されたときに、ロジカル・スタンバイ・データベースで自動的に有効化されます。サプリメンタル・ロギングを有効化するには、フィジカル・スタンバイ・データベースへの接続時に次のSQL*Plus文を発行します。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

- ロジカル・スタンバイ・データベースがリアルタイム問合せを実行するように構成されていない場合、SQL Applyを構成して、ロジカル・スタンバイ・データベースへのREDOデータの適用を遅延することを検討してください。REDOの適用を遅延することで、フィジカル・スタンバイ・データベースへのフェイルオーバー後にロジカル・スタンバイ・データベースを手動で復元する必要性を最小限に抑えることができます。
遅延時間を設定するには、LOG_ARCHIVE_DEST_n初期化パラメータのDELAY=minutes属性を使用します。

関連項目:

- 複数のスタンバイ・データベースを使用するメリットおよび実装例の詳細は、『Oracle Database高可用性概要』を参照してください。

- 複数のスタンバイ・データベース・アーキテクチャの概要は、『Oracle Database高可用性概要』を参照してください。

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『複数のスタンバイ・データベースのベスト・プラクティス』を参照してください。
http://www.oracle.com/goto/maa

9.4 Oracle Data Guardのロール移行のベスト・プラクティス

適切な計画と実行に基づいたData Guardのロール移行により、効果的に停止時間を最小化し、ビジネスへの影響を最小限に抑えながらデータベース環境をリストアすることが可能になります。フィジカル・スタンバイ・データベースを使用する場合、MAAのテスト結果では、Oracle Data Guard 11gによるスイッチオーバーとフェイルオーバーの時間は数秒間に短縮されました。この項では、スイッチオーバーとフェイルオーバーのベスト・プラクティスについて説明します。

9.4.1 Oracle Data Guardのスイッチオーバーのベスト・プラクティス

Oracle Data Guardにより実行されるデータベース・スイッチオーバーは、スタンバイ・データベースとプライマリ・データベースの間でロールを切り替えるための一連の手順を含む計画された移行操作です。スイッチオーバー操作に成功すると、スタンバイ・データベースがプライマリ・ロールを引き継ぎ、プライマリ・データベースがスタンバイ・データベースとなります。通常、スイッチオーバーはわずか数秒から数分で完了します。データベースのロール管理の分野では、スイッチバックという用語も使用されることがあります。スイッチバックは、スイッチオーバー操作の後にデータベースのロールを元の状態に戻す操作です。

Data Guardでは、次の方法により動的にロールを変更できます。

- Oracle Enterprise Managerの使用

- Oracle Data GuardブローカのDGMGRLコマンドライン・インタフェースの使用

- SQL文の発行(14.2.1.3項「Data Guardスイッチオーバーの実行方法」を参照)

関連項目:
Oracle Enterprise ManagerまたはOracle Data GuardブローカのDGMGRLコマンドライン・インタフェースを使用してデータベース・スイッチオーバーを実行する方法の詳細は、『Oracle Data Guard Broker』を参照してください。

スイッチオーバー処理を最適化するには、スイッチオーバーを実行する前に次の手順を実行します。

- ALTER SYSTEM KILL SESSION SQL*Plusコマンドを使用して、切断可能なすべてのセッションを切断します。

- AQ_TM_PROCESSESパラメータを0に設定してジョブ処理を停止します。

- NODELAYキーワードを使用してスタンバイ・データベースのログ適用サービスを停止および再起動し、指定されている適用遅延をすべて取り消します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE NODELAY;

V$ARCHIVE_DESTビューのDELAY_MINS列を問い合せることによって、プライマリ・データベース上の現在の遅延設定を表示することができます。

- Oracle RAC環境のフィジカル・スタンバイ・データベースについては、各プライマリ・データベースおよびスタンバイ・データベースに対して、必ず、アクティブなインスタンスが1つのみ存在するようにします。

- スイッチオーバー処理を最適化するには、リアルタイム適用を使用するようにスタンバイ・データベースを構成し、可能な場合は、スイッチオーバー操作の前にデータベースが確実に同期されるようにします。
スイッチオーバーを可能なかぎり高速化するには、受信と同時にREDOデータがスタンバイ・データベースに適用されるように、リアルタイム適用を使用します。この場合、スタンバイ・データベースが、スイッチオーバー操作の前にプライマリ・データベースと同期化されて、スイッチオーバー時間が最小限に抑えられます。リアルタイム適用を有効化するには次のSQL*Plus文を使用します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;

- フィジカル・スタンバイ・データベースの場合は、アーカイバ・プロセス(ARCn)の数を、リモート・アーカイブとローカル・アーカイブの両方に必要な最小の値に減らします。追加のアーカイバ・プロセスは、停止時間を増加させる可能性があり、その結果スイッチオーバーの実行にかかる合計時間も増加します。スイッチオーバーが完了したら、追加のアーカイバ・プロセスを再有効化できます。

- LOG_FILE_NAME_CONVERT初期化パラメータをその環境で有効な任意の値に設定するか、不要な場合はNULLに設定します。
スイッチオーバーの一環として、スタンバイ・データベースでは、プライマリ・データベースとしてオープンする前にスタンバイ・データベース上のオンラインREDOログ・ファイルを消去する必要があります。I/Oの完了に要する時間により、スイッチオーバーの合計時間が大幅に増加する可能性があります。LOG_FILE_NAME_CONVERTパラメータを設定すると、MRPプロセスの最初の起動時に、スタンバイ・データベースからオンラインREDOログを事前に作成することができます。スタンバイ・データベース上でSQL*PlusのALTER DATABASE CLEAR LOGFILE文を発行することで、空のオンラインREDOログを事前に作成することもできます。

関連項目:
Data Guard Physical Standby (11.2.0.2)のスイッチオーバー・ベスト・プラクティス用のサポート・ノートは次のとおりです。

- SQL*Plusを使用中の場合、次のWebサイトのMy Oracle Support Note 1304939.1の『SQL*Plusを使用した11.2 Data Guard Physical Standbyのスイッチオーバー・ベスト・プラクティス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1304939.1

- Oracle Data GuardブローカまたはOracle Enterprise Managerを使用中の場合、次のWebサイトのMy Oracle Support Note 1305019.1の『Brokerを使用した11.2 Data Guard Physical Standbyのスイッチオーバー・ベスト・プラクティス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1305019.1

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『スイッチオーバーおよびフェイルオーバーのベスト・プラクティス』を参照してください。
http://www.oracle.com/goto/maa

9.4.2 Oracle Data Guardのフェイルオーバーのベスト・プラクティス

フェイルオーバーは通常、プライマリ・データベースが利用できなくなって、妥当な期間内でサービスに復帰させる可能性がない場合にのみ使用されます。フェイルオーバーの際、1つのサイトのプライマリ・データベースがオフラインにされ、スタンバイ・データベースがプライマリ・データベースとしてオンラインにされます。

Data Guardのフェイルオーバー・プロセスは、ファスト・スタート・フェイルオーバーを使用して完全に自動化するか、ユーザーが手動で起動します。ファスト・スタート・フェイルオーバーを使用して、手動操作を必要とするプロセスに固有の不確実性を排除することをお薦めします。ファスト・スタート・フェイルオーバーでは、システム停止が検出されてから数秒以内にフェイルオーバーが自動的に実行されます。

Data Guardフェイルオーバー・ベスト・プラクティスの詳細は、次のトピックを参照してください。

- ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較

- フェイルオーバーのベスト・プラクティス(手動フェイルオーバーとファスト・スタート・フェイルオーバー)

- ファスト・スタート・フェイルオーバーのベスト・プラクティス

- 手動フェイルオーバーのベスト・プラクティス

関連項目:
Oracle Data Guardフェイルオーバー・ベスト・プラクティスの総合レビューは、次を参照してください。

- スイッチオーバーとフェイルオーバー操作の詳細は、『Oracle Data Guard Broker』を参照してください。

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Data Guardのファスト・スタート・フェイルオーバー』を参照してください。
http://www.oracle.com/goto/maa

- 次のWebサイトのMy Oracle Support Note 1304939.1の『SQL*Plusを使用した11.2 Data Guard Physical Standbyのスイッチオーバー・ベスト・プラクティス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1304939.1

- 次のWebサイトのMy Oracle Support Note 1305019.1の『Brokerを使用した11.2 Data Guard Physical Standbyのスイッチオーバー・ベスト・プラクティス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1305019.1

9.4.2.1 ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較

フェイルオーバーには、手動フェイルオーバーとファスト・スタート・フェイルオーバーという2つの異なるタイプがあります。プライマリ・データベースに障害が発生した場合、管理者は手動フェイルオーバーを開始します。一方、Data Guardでは、一定の期間にわたり(ファスト・スタート・フェイルオーバーしきい値)プライマリ・データベースが使用不可能になると、ユーザーの操作なしで自動的にファスト・スタート・フェイルオーバーが開始されます。

表9-5にファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較を示します。

表9-5 ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較

比較ポイント

ファスト・スタート・フェイルオーバー

手動フェイルオーバー

メリット

手動操作を極力使用せずに可用性を向上し、管理コストを削減できます。

フェイルオーバーの発生時期とターゲット・スタンバイ・データベースをユーザーが正確に制御できます。

フェイルオーバー・トリガー

ファスト・スタート・フェイルオーバーが自動的に起動されるのは、次の場合です。

- データベース・インスタンス障害(またはOracle RAC構成の最後のインスタンス障害)の場合

- 異常終了した場合(またはOracle RAC構成の最後のインスタンスが異常終了した場合)

- データベース・ヘルス・チェック・メカニズムによって特定の条件が検出された場合(たとえば、I/Oエラーのためにデータファイルがオフラインにされた、など)
それらの条件に対してファスト・スタート・フェイルオーバーを有効化することができ(ENABLE FAST_START FAILOVER CONDITION)、それらの条件が発生すると、OracleサーバーによりORAエラーが発生します。

条件すべてのリストは『Oracle Data Guard Broker』を参照してください。

- オブザーバとスタンバイ・データベースの両方がプライマリ・データベースに対するネットワーク接続を失った場合

- アプリケーションがDBMS_DG.INITIATE_FS_FAILOVER PL/SQLプロシージャを使用してファスト・スタート・フェイルオーバーを開始した場合

手動フェイルオーバーは、ユーザーによって開始され、スタンバイ・データベースをプライマリ・データベースに変換するための一連の手順を実行します。手動フェイルオーバーは、次のような計画外の停止が発生した場合に実行します。

- プライマリ・データベースが使用不可能となるサイト障害(Oracle RACプライマリ・データベースのすべてのインスタンス)

- 一定の時間内に修復できないユーザー・エラー

- 本番アプリケーションに影響を及ぼすデータ障害

管理

ファスト・スタート・フェイルオーバーの管理には、次のツールを使用します。

- Oracle Enterprise Manager

- Oracle Data Guardブローカ・コマンドライン・インタフェース(DGMGRL)

14.2.1.3項「Data Guardスイッチオーバーを実行する方法」を参照してください。

手動フェイルオーバーの実行には、次のツールを使用します。

- Oracle Enterprise Manager

- Oracle Data Guardブローカ・コマンドライン・インタフェース(DGMGRL)

- SQL文

13.2.2.3項「手動フェイルオーバー実行のベスト・プラクティス」を参照してください。

フェイルオーバー後の元のプライマリ・データベースのリストア

ファスト・スタート・フェイルオーバーの後、Oracle Data Guardブローカは、構成への再接続時に元のプライマリ・データベースをスタンバイ・データベースとして自動的に再構成できます(FastStartFailoverAutoReinstate)。または、再構成を遅延して、障害が発生したプライマリで診断を実行できます。自動再構成では、Data Guardで障害保護の構成を迅速かつ容易にリストアし、データベースを可能なかぎり早く保護状態に戻すことができます。

手動フェイルオーバーの後、フォルト・トレランスを回復するために元のプライマリ・データベースをスタンバイ・データベースとして復元する必要があります。

フェイルオーバー後のバイスタンダ・スタンバイ・データベースのリストア

Oracle Data Guardブローカにより、構成内のすべてのデータベースのロール移行が調整されます。

復元を必要としないバイスタンダは、新しいプライマリになれるスタンバイ・データベースとして利用できます。復元を必要とするバイスタンダは、オブザーバによって自動復元されます。

Oracle Data Guardブローカを使用する利点は、バイスタンダ・データベースのステータスが提供され、データベースを復元する必要があるかどうかが示されることです。SQL*Plus文を使用してフェイルオーバーを管理する場合、ステータス情報はすぐには利用できません。

13.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

アプリケーション・フェイルオーバー

Oracle Data Guardブローカは、フェイルオーバー後に、FAN/AQ (アドバンスト・キューイング)およびFAN/ONS (Oracle Notification Service)の通知を自動的に発行します。高速接続フェイルオーバーも構成されているクライアントは、それらの通知を使用して新しいプライマリ・データベースに接続することができます。DB_ROLE_CHANGEシステム・イベントを使用して、ユーザー・アプリケーションによるプライマリ・データベース上のサービスの検索も支援できます。(これらのイベントは、ブローカが実行する手動フェイルオーバーでも利用できます。『Oracle Data Guard Broker』を参照してください。

Oracle Data Guardブローカは、フェイルオーバー後に、FAN/AQ (アドバンスト・キューイング)およびFAN/ONS (Oracle Notification Service)の通知を自動的に発行します。高速接続フェイルオーバーも構成されているクライアントは、それらの通知を使用して新しいプライマリ・データベースに接続することができます。DB_ROLE_CHANGEシステム・イベントを使用して、ユーザー・アプリケーションによるプライマリ・データベース上のサービスの検索も支援できます。(これらのイベントは、ブローカが実行する手動フェイルオーバーでも利用できます。『Oracle Data Guard Broker』を参照してください。

9.4.2.2 フェイルオーバーのベスト・プラクティス(手動フェイルオーバーとファスト・スタート・フェイルオーバー)

フェイルオーバー処理を最適化するには、次のことを行います。

- フェイルオーバー操作の完了後に障害が発生したプライマリ・データベースを復元するため、フラッシュバック・データベースを有効化します。必要な場合、フラッシュバック・データベースはポイント・イン・タイム・リカバリを容易にします。

- ユーザー・エラーや論理破損が検出されたときに、受信と同時にREDOデータをスタンバイ・データベースに適用してデータベースを迅速に復元するため、フラッシュバック・データベースと組み合せてリアルタイム適用を使用します。

- フェイルオーバー後もデータ保護を維持するために、複数のスタンバイ・データベースを構成することを検討します。

- LOG_FILE_NAME_CONVERTパラメータを設定します。フェイルオーバーの一環として、スタンバイ・データベースでは、プライマリ・データベースとしてオープンする前にオンラインREDOログを消去する必要があります。このI/Oの完了に要する時間により、フェイルオーバーの合計時間が大幅に増加する可能性があります。LOG_FILE_NAME_CONVERTパラメータを設定すると、MRPプロセスの最初の起動時に、スタンバイによってオンラインREDOログが事前作成されます。スタンバイ・データベース上でSQL*PlusのALTER DATABASE CLEAR LOGFILE文を発行することで、空のオンラインREDOログを事前に作成することもできます。

- ファスト・スタート・フェイルオーバーを使用します。Oracle Database 11gの稼働する環境で行ったMAAテストでは、Oracle Data Guardブローカとファスト・スタート・フェイルオーバーを使用したフェイルオーバーの実行により、可用性が大幅に向上しました。詳細は、9.4.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」を参照してください。

- フィジカル・スタンバイ・データベースの場合、次の作業を実行します。

- 読取り専用モードからREDO Apply(リカバリ)モードに移行する場合、データベースを再起動します。

- (Oracle Database 11gリリース2より前のリリースで要求されたように)スタンバイ・データベースを再起動するのではなく、MOUNTED状態からOPEN状態に直接移行します。

- REDO Applyのメディア・リカバリの最適化については、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Oracle Data GuardのREDO Applyとメディア・リカバリ』を参照してください。
http://www.oracle.com/goto/maa

9.4.2.3 ファスト・スタート・フェイルオーバーのベスト・プラクティス

プライマリ・データベースで障害が発生した場合、ファスト・スタート・フェイルオーバーにより、指定されたスタンバイ・データベースに対して自動的に迅速で信頼性の高いフェイルオーバーが実行されるため、手動操作でフェイルオーバーを実行する必要はありません。ファスト・スタート・フェイルオーバーは、Oracle Data Guardブローカが管理するOracle Data Guard構成でのみ使用できます。

ファスト・スタート・フェイルオーバーを使用したOracle Data Guard構成は、最大可用性モードまたは最大パフォーマンス・モードで稼働します。ファスト・スタート・フェイルオーバーを有効化した場合、構成済のデータ損失保証を維持できる場合にのみファスト・スタート・フェイルオーバーを実行できるように、ブローカにより保証されます。最大可用性モードでは、データ損失の発生しないことが保証された自動フェイルオーバー環境が提供されます。最大パフォーマンス・モードでは、FastStartFailoverLagLimit構成プロパティで指定されたデータ量(秒単位)を超える損失は発生しないことが保証された自動フェイルオーバー環境が提供されます。

9.4.2.2項「フェイルオーバーのベスト・プラクティス(手動フェイルオーバーとファスト・スタート・フェイルオーバー)」に記載された汎用のベスト・プラクティスに加え、次のファスト・スタート・フェイルオーバーのベスト・プラクティスを使用してください。

- ファスト・スタート・フェイルオーバーのオブザーバ・プロセスは、プライマリ・データベースまたはスタンバイ・データベースとは別の場所にあるデータ・センターのホストで実行します。
オブザーバは、プライマリ・データベースおよびスタンバイ・データベースから等距離の場所にあるシステムで実行してください。オブザーバは、任意のエンド・ユーザー・クライアントと同じネットワークを使用してこれら2つのデータベースに接続する必要があります。指定したオブザーバに障害が発生した場合、Oracle Enterprise Managerがそれを検出し、自動的にオブザーバを再起動することができます。オブザーバを第3のサイトで実行できない場合は、アプリケーションと同じネットワークにインストールしてください。第3の独立した場所を使用できない場合、スタンバイ・データ・センター内の別個のホストにオブザーバを配置し、スタンバイ・データベースに影響を与える障害からできるかぎり離してください。

- Oracle Enterprise Managerを使用してオブザーバの可用性を高め、データベースへの接続が再確立されたら、元のプライマリ・データベースがスタンバイ・データベースとして自動的に復元されるように構成します。また、Oracle Enterprise Managerを使用すると、オブザーバを再起動する代替ホストを定義できます。
フェイルオーバーの完了後、FastStartFailoverAutoReinstate構成プロパティをTRUEに設定すると、接続が再確立されたときに、元のプライマリ・データベースがスタンバイ・データベースとして自動的に復元されます。

- 現在の構成上の特性に従って、FastStartFailoverThresholdプロパティの値を表9-6のとおりに設定します。

表9-6 FastStartFailoverThresholdの最小値の推奨設定

構成

最小値の推奨設定

単一インスタンスのプライマリ、短い待機時間、信頼性の高いネットワーク

15秒

単一インスタンスのプライマリ、WANを介した待機時間の長いネットワーク

30秒

Oracle RACのプライマリ

Oracle RACミスカウント + 再構成時間 + 30秒

表9-6に示す設定を使用する構成をテストして、ファスト・スタート・フェイルオーバーのしきい値が、間違ってフェイルオーバーが起動されるほど極端に小さくないか、またはフェイルオーバー要件を満たさないほど大きくないかどうかを確認してください。

9.4.2.4 手動フェイルオーバーのベスト・プラクティス

ユーザーが起動する手動フェイルオーバーは、緊急時にのみ使用し、次のような計画外の停止が発生した場合に開始する必要があります。

- プライマリ・データベースが使用不可能となるサイト障害

- 一定の時間内に修復できないユーザー・エラー

- 広範囲の破損を含む、本番アプリケーションに影響を及ぼすデータ障害

9.4.2.2項「フェイルオーバーのベスト・プラクティス(手動フェイルオーバーとファスト・スタート・フェイルオーバー)」に記載された汎用のベスト・プラクティスに加え、次の手動フェイルオーバーのベスト・プラクティスを使用してください。

- 元のプライマリ・データベースをスタンバイ・データベースとして復元し、現在の環境にフォルト・トレランスを回復する必要があります。スタンバイ・データベースは、フラッシュバック・データベースを使用して迅速に復元できます。13.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

関連項目:
フィジカル・スタンバイ・データベースについては、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Oracle Data GuardのREDO Applyとメディア・リカバリ』を参照してください。
http://www.oracle.com/goto/maa

9.5 Oracle Active Data Guardのベスト・プラクティスの使用

Oracle Active Data Guardオプションのライセンスがある場合、スタンバイ・データベース上のREDO Applyがプライマリ・データベースから受信したREDOデータを継続して適用している状態で、フィジカル・スタンバイ・データベースを読取り専用アクセスで開くことができます。フィジカル・スタンバイ・データベースから読み取る問合せはすべてリアルタイムで実行され、現在の結果を戻すため、データ保護が不完全になったり、フェイルオーバーが必要な場合にリカバリ時間が長くなったりすることなく、システム資源をより効率的に利用してスタンバイが正常な状態であることを再確認できます。このため、この機能はリアルタイム問合せと呼ばれます。

注意:
Oracle Active Data Guardオプションのライセンスを購入すると、REDO Applyをアクティブにしたままフィジカル・スタンバイ・データベースを読取り専用アクセスでオープンできます。リアルタイム問合せとも呼ばれるこの機能を使用すると、スタンバイ・データベース上でブロック変更トラッキングが可能になり、それによりスタンバイ上で増分バックアップを実行できます。

リアルタイム問合せをデプロイするには、次のことを行います。

- Active Data Guardが有効であることを確認します。
Oracle Active Data Guardのステータスを参照する簡単かつ最適な方法は、Oracle Enterprise ManagerからのData Guardの概要ページの参照です。

もしくは、スタンバイ・データベースでv$databaseビューの問合せを行い、READ ONLY WITH APPLYのステータスを確認することもできます。

SQL> SELECT open_mode FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLY WITH APPLY

- REDOデータの受信と同時に変更が適用されるように、スタンバイ・データベースにリアルタイム適用を使用します。
Oracle Data Guardブローカは、構成が作成されるとリアルタイム適用を自動的に有効化します。構成の作成にSQL*Plusコマンドラインを使用している場合は、リアルタイム適用を次のように有効化します。

次の文を発行します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE

- スタンバイ・データベースでフラッシュバック・データベースを有効化して、論理破損の停止時間を最小化します。

- Standby Statspackを使用してスタンバイ・データベースのパフォーマンスを監視します。Standby Statspackのインストールおよび使用方法の詳細は、次のWebサイトのMy Oracle Support Note 454848.1の『11gでのStandby Statspackのインストールおよび使用』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=454848.1

- リアルタイム問合せをデプロイして、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せをオフロードしている場合、適用ラグを監視して許容範囲内かどうかを確認します。リアルタイム問合せ環境での適用ラグの監視の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- Oracle Data Guardブローカ構成を作成することで、管理を簡素化し、Oracle RACスタンバイ・データベースでの自動適用インスタンス・フェイルオーバーを有効化します。

関連項目:
次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Active Data Guard 11gのベスト・プラクティス(Redo Applyのベスト・プラクティスを含む)』を参照してください。
http://www.oracle.com/goto/maa

9.6 スナップショット・スタンバイ・データベースのベスト・プラクティスの使用

Oracle Data Guardのリリース11g以上では、フィジカル・スタンバイ・データベースを、スナップショット・スタンバイ・データベースと呼ばれる完全に更新可能なスタンバイ・データベースに変換することができます。

フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するには、SQL*PlusのALTER DATABASE CONVERT TO SNAPSHOT STANDBY文を発行します。このコマンドを使用すると、Oracle Data Guardが次のアクションを実行します。

1. 利用できるすべてのREDOデータを回復します。

2. 保証付きリストア・ポイントを作成します。

3. スタンバイ・データベースを、プライマリ・データベースとしてアクティブ化します。

4. データベースを、スナップショット・スタンバイ・データベースとしてオープンします。

スナップショット・スタンバイを元のフィジカル・スタンバイに変換するには、ALTER DATABASE CONVERT TO PHYSICAL STANDBY文を発行します。このコマンドを使用すると、フィジカル・スタンバイ・データベースは、ALTER DATABASE CONVERT TO SNAPSHOT STANDBY文が発行される前に作成された保証付きリストア・ポイントにフラッシュバックされます。次に、次のアクションを実行する必要があります。

1. フィジカル・スタンバイ・データベースを再起動します。

2. フィジカル・スタンバイ・データベース上でREDO Applyを再起動します。

スナップショット・スタンバイ・データベースを作成および管理するには、次のことを行います。

- Oracle Data Guardブローカは、スナップショット・スタンバイ・データベースの管理を簡素化するため、これを使用してOracle Data Guard構成を管理します。ブローカではフェイルオーバー操作の一環として、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに変換されます。ブローカがない場合、この変換はフェイルオーバーの開始前に手動で実行する必要があります。

- リカバリ時間目標(RTO)が要求される業務の場合、複数のスタンバイ・データベースを作成します。

- スナップショット・スタンバイに変換するフィジカル・スタンバイ・データベースが、プライマリ・データベースに追随しているか、適用ラグが最小であることを確認します。メディア・リカバリのチューニングの詳細は、9.3.8項「Data Guard Redo Applyのベスト・プラクティスの使用」を参照してください。

- 高速リカバリ領域を構成し、十分なI/O帯域幅を利用できることを確認します。確認が必要なのは、スナップショット・スタンバイ・データベースが保証付きリストア・ポイントを使用するためです。

関連項目:
スナップショット・スタンバイ・データベースの作成方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。

9.7 Data Guardのパフォーマンスの評価

Data Guardスタンバイ・データベースの追加後におけるプライマリ・データベースのパフォーマンスを正確に評価するには、同じアプリケーション・プロファイルおよび負荷を伴うOracle Data Guardのデプロイ前後に、V$SYSMETRIC_SUMMARYビューまたは自動ワークロード・リポジトリ(AWR)のスナップショットから統計履歴を取得します。

アプリケーション・プロファイルを評価するには、次の統計を比較します。

- 1トランザクション当たりの物理読取り

- 1トランザクション当たりの物理書込み

- 1トランザクション当たりのCPU使用率

- 1トランザクション当たりのREDO生成

アプリケーション・パフォーマンスを評価するには、次の統計を比較します。

- 1秒当たりのREDO生成(またはREDO速度)

- 1秒当たりのユーザー・コミット(または1秒当たりのトランザクション)

- 1秒当たりのデータベース処理時間

- 1トランザクション当たりのレスポンス時間

- SQLサービス・レスポンス時間

アプリケーション・プロファイルが2つの使用例で変化していると、正確に比較できません。『Oracle Databaseパフォーマンス・チューニング・ガイド』に記載された一般的な原則に従って、データベースまたはシステムでテストとチューニングを繰り返してください。

アプリケーション・プロファイルがほぼ同じ状態で、プライマリ・データベースのアプリケーション・パフォーマンスにスループットの低下やレスポンス時間の増大といった変化が認められる場合、次の一般的な問題領域を確認します。

- CPU使用率
システム負荷が高い場合(90%を超える過剰なCPU使用率、ページングおよびスワッピング)、Data Guardでの操作を続ける前にシステムをチューニングする必要があります。V$OSSTATビューまたはV$SYSMETRIC_HISTORYビューを使用して、オペレーティング・システムからのシステム使用率統計を監視します。

- I/O待機イベントの増加
ログ・ライター・プロセスまたはデータベース・ライター・プロセスのI/O待機が増加すると、I/Oの低下によりスループットとレスポンス時間が影響を受けます。I/Oへの影響は、次の待機イベントの履歴データを参照することで確認できます。

- ログ・ファイル・パラレル書込み

- ログ・ファイル順次読取り

- ログ・ファイル・パラレル読取り

- データファイル・パラレル書込み

- データファイル順次読取り

SYNC転送では、より多くのコミット時間を必要とします。これは、フォアグラウンド・プロセスがログ・ライター(LGWR)・バックグラウンド・プロセスからコミット完了の確認応答を受信する前に、スタンバイ・データベースでREDOデータが使用可能であることを保証する必要があるためです。LGWRプロセスのコミットには、次の待機イベントが含まれます。

- ログ・ファイル・パラレル書込み(LGWRプロセスのローカル書込み)

- SENDREQでのLGWR待機
この待機イベントには、次の時間が含まれます。

- パケットをネットワークに送信する時間

- パケットをスタンバイ・データベースに送信する時間

- スタンバイREDOログにRFS書込みまたはスタンバイ書込みを行う時間(RFSのI/O待機イベントとチェックサムのための追加オーバーヘッドを含む)

- プライマリ・データベースにネットワーク確認応答を送信する時間(シングル・トリップの待機時間など)

LGWRプロセスによるコミット時間の増加は、特に小規模な時間依存型のトランザクションにおいて、レスポンス時間の増加とスループット低下の原因となる場合があります。ただし、ログ・ライターのローカル書込み(Log File Parallel Write待機イベント)や、LGWR wait on SENDREQ待機イベントを構成する各種の構成要素をチューニングすることで、これらの問題を十分に改善できる可能性があります。

ディスク書込みI/O(ログ・ファイル・パラレル書込みまたはRFS I/O)をチューニングするには、より多くのスピンドルを追加するか、I/O帯域幅を拡張します。

ネットワーク時間を短縮するには、次のようにします。

- Oracle Netの送信および受信バッファ・サイズをチューニングします。

- SDU=65535に設定します(詳細は9.3.7.2項「ネットワーク構成と最大ネットワークREDO速度の設定」を参照してください)。

- 飽和状態にある場合、ネットワーク帯域幅を拡張します。

- より近距離のサイトを探してネットワーク待機時間を短縮します。

ASYNC転送では、LGWRプロセスは、ネットワーク・サーバー・プロセスが戻るのを待機せずにCOMMITレコードを現在のログ・ファイルに書き込みます。ただし、ネットワーク・サーバー・プロセスが遅延し、転送予定のREDOがログ・バッファからフラッシュされている場合、ネットワーク・サーバー・プロセスはオンラインREDOログからデータを読み取ります。これにより、I/Oの競合が増加し、状況によってはログ・ライター・プロセスの書込み(ログ・ファイル・パラレル書込み)の待機時間が増加します。I/O帯域幅と十分なスピンドルが割り当てられていない場合、ログ・ファイル・パラレル書込みおよびログ・ファイル順次読取りによる待機が増加し、スループットやレスポンス時間に影響を与える可能性があります。通常は、十分なスピンドルを追加することでI/O待機時間を削減できます。

注意:
統計収集機能とアドバイザの大部分を有効化するには、STATISTICS_LEVEL初期化パラメータをTYPICAL(推奨)またはALLに設定します。

関連項目:

- 一般的なパフォーマンス・チューニングおよびトラブルシューティングのベスト・プラクティスは、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- 自動ワークロード・リポジトリ(AWR)と自動ワークロード・リポジトリ・レポートの生成の概要は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Data GuardのREDO転送およびネットワークのベスト・プラクティス』を参照してください。
http://www.oracle.com/goto/maa

10 Oracle GoldenGateの構成

Oracle GoldenGateは、影響の少ない、リアルタイム・データの取得、分散および配信を同機種システムおよび異機種システムの両方で実現します。Oracle GoldenGateでは、費用効果的かつ影響の少ないリアルタイムのデータ統合と可用性を継続させるソリューションが、幅広いユースケースに対して可能です。Oracle GoldenGateではOracleテクノロジおよびアプリケーションとの緊密な統合、追加的な異機種システムのサポート、およびパフォーマンスの向上が提供されます。

この章には、次の項目が含まれます。

- Oracle GoldenGateの概要

- Oracle GoldenGateの構成ベスト・プラクティス

- Oracle GoldenGateの運用ベスト・プラクティス

10.1 Oracle GoldenGateの概要

Oracle GoldenGateはソース・データベースのオンラインREDOログ・ファイルからREDOレコードを読み取り、このレコードをプラットフォーム非準拠の追跡ファイル形式に変換して、追跡ファイルをターゲット・データベースに転送することで、プライマリ・データベースの変更を捕捉します。Oracle GoldenGateは追跡ファイルをSQLに変換し、SQLをターゲット・データベースに適用することで、論理レプリカを保持します。ターゲット・データベースは同期の発生中、読取り/書込みに対してオープンです。その他のOracle GoldenGate情報は、次のサイトを参照してください。

http://www.oracle.com/us/products/middleware/data-integration/goldengate/index.html

Oracle GoldenGateの使用が適しているのは、その他のMAA機能では対応できない高度な要件にその柔軟性を生かせるような場合です。Oracle GoldenGateはMAAアーキテクチャにおける重要な要素で、次のような目的に有効です。

- データ可用性とパフォーマンス平準化に使用されるアクティブ/アクティブなマルチマスター構成。前述の構成に対する重要な考慮事項である、競合の回避、または競合を検出および解決するプロセスの実装のどちらかによって、更新の競合を管理する機能。

- レポーティング・インスタンスへの読取り/書込みアクセスが必要な場合の、操作レポーティングのオフロード。

- 次のような計画済メンテナンス・タスクのための、ゼロに近い停止時間(一方向レプリケーション)または停止時間ゼロ(双方向レプリケーション)。

- データベースのアップグレード

- バックエンド・データベース・オブジェクトを変更するアプリケーションのアップグレード(旧バージョンと新バージョンをマップするための変換をユーザーが実装する必要があります)。

- データベースの統合

- データベースおよびプラットフォームの移行

10.1.1 Oracle GoldenGateおよびOracle Streams

Oracle GoldenGateは、Oracle MAAアーキテクチャにおいてOracle Streamsを直接的に置き換えます。Oracle GoldenGateはOracle Streamsの代替となります。Oracle GoldenGateはすべてがOracleという環境での同様の高度なレプリケーション機能だけでなく、異機種のデータベース管理システムにおける拡張的なレプリケーション・サポートも組み合せて提供します。Oracle GoldenGateによってユーザーは、すべてのプラットフォームを1つの水平的なレプリケーション・テクノロジに平準化することで、環境をシンプルにする機会を得られます。新規のレプリケーション・プロジェクトを実装する際はOracle GoldenGateを検討し、オラクルが現在も開発中のこのテクノロジを利用することをお薦めします。

オラクルは今後もStreams製品をサポートして同製品への投資を保護していくため、Oracle Streamsのユーザーは既存のStreamsの実装を引き続き拡張できます。Oracle Streamsの詳細は、次のWebサイトでOracle Streamsエリアを参照してください。

http://www.oracle.com/technetwork/database/focus-areas/data-integration/index.html

10.1.2 Oracle GoldenGateおよびOracle RAC

Oracle GoldenGateのアクティブ/アクティブ・レプリケーションは、Oracle Databaseの複数の同期化されたレプリカに対してワークロードを均衡化することで、高可用性とパフォーマンス平準化の両方に使用できます。Oracle GoldenGateをこの目的で使用する際の要件は次のとおりです。

- Oracleデータベースの冗長コピー

- サプリメンタル・データベース・ロギング

- 各データベースでの取得および適用プロセスからのレプリケーション・オーバーヘッド

- 競合の検出および解決

- データベースが停止した場合のクライアントの通知/リダイレクト

- ロジカル・レプリケーションのためのすべての前提条件の準拠

対照的に、Oracle RACでは、Oracleデータベースの単一コピーへの共有アクセスを保有する複数のサーバーに対してワークロードを均衡化することで、高可用性と拡張性の高いパフォーマンスが提供されます。Oracle RACにはクライアントの通知およびリダイレクトの統合的なメソッドが組み込まれており、追加的な処理または前提条件がロジカル・レプリケーションで求められることはありません。このような理由から、Oracle RACは、Oracleデータベースに高可用性と拡張性の高いパフォーマンスを実装する場合の推奨メソッドです。Oracle GoldenGateはほとんどの場合、Oracle RACとともにメンテナンスまたは移行に使用されます。もしくは、ソース・データベースのサブセットを地理的に離れた場所に分散するためのメソッドとして使用され、ローカルの読取り/書込みアクセスを提供するか、レポーティング・アプリケーションをオフロードするためのローカルの読取り/書込みレプリカを作成します(対象アプリケーションでデータベースへの読取り/書込みアクセスが必要な場合)。

10.1.3 Oracle GoldenGateとOracle Data Guard/Oracle Active Data Guard

Oracle GoldenGateはOracleの戦略的ロジカル・レプリケーション製品です。Oracle Data Guardは、データ保護およびデータ可用性に重点を置いたOracleの戦略的フィジカル・レプリケーション製品で、ロジカル・レプリケーションを上回るメリットを提供することから、対象となる目的における標準のMAA推奨製品です。Oracle Data Guardは、障害保護のためのストレージ・リモート・ミラー化またはホスト・ベース・ミラー化ソリューションのかわりとしてもよく使用されています。Oracle Data Guardではデータベースのローリング・アップグレード、移行の選択(たとえば、WindowsからLinux)、データ・センターの移動、およびその他のタイプの計画済メンテナンスをサポートしているため、計画済停止時間を最小限に抑えることもできます。Oracle Active Data GuardはOracle Data Guardの拡張機能で、読取り専用ワークロードおよびバックアップをオフロードするために、ソース・データベースの同期化されたフィジカル・レプリカを読取り専用にオープンするのを維持しておく、最もシンプルかつ高速で効率的なメソッドです。データ保護のためのData Guardの利点の詳細は、次のWebサイトでGoldenGateリンクから製品の技術資料『Oracle Active Data GuardとOracle GoldenGate』を参照してください。

http://www.oracle.com/technetwork/database/features/availability/index.html

Oracle GoldenGateはData Guard構成で相補的に使用されることがほとんどです。Data Guardフィジカル・スタンバイでは、データの保護と可用性が提供されます。同時に、Oracle GoldenGate取得プロセスがプライマリ・データベースまたは(ALOモードを使用して)スタンバイ・データベースのどちらかで構成され、1つ以上のターゲット・データベース(OracleまたはOracle以外のどちらでも)にデータを分散することで、高度なレプリケーション要件に対応します。Oracle GoldenGateは、データ保護、高可用性および障害回復のためのOracle Data Guard固有の機能よりもメリットがあり、ロジカル・レプリケーションのためのすべての前提条件が一致している場合に、Oracle Data Guardのかわりとして使用することもできます。例として次のようなユースケースがあります。

- マルチマスター・レプリケーションを実装するか、またはターゲット・データベースへの読取り/書込みアクセスを求めるパッケージ化レポーティング・アプリケーションをオフロードするために、ターゲット・データベースへの読取り/書込みアクセスが必要な場合

- Oracle Data Guardでサポートされていない異機種環境での計画済メンテナンスまたは移行を行う場合

- 計画済メンテナンス中にOracle Databaseまたはアプリケーションの新規のバージョンから以前のバージョンへ下方レプリケートする際に、予定外の問題の発生時における迅速なスイッチバックのためにフレキシビリティがさらに必要な場合

- バックエンド・データベース・オブジェクトに変更を加えるようなアプリケーション・アップグレード全体の可用性を維持する場合

10.1.4 Oracle GoldenGateとエディションベース再定義

エディションベース再定義はOracle Database内で完全に実装されている機能で、アプリケーションのバックエンドを実装するデータベース・オブジェクトについて、アプリケーションの可用性を妨げることなくパッチ適用またはアップグレードを行うことができます。エディションベース再定義を使用すると、データベースの停止時間はゼロのまま、アプリケーション・アップグレードをオンラインで実装できます。エディションベース再定義にはOracle Database 11gリリース2が必要で、アプリケーションの変更も必要です。アプリケーションは、オンラインでアップグレードできるようにエディション可能にする必要があります。

Oracle GoldenGateはオンライン・アプリケーション・アップグレードにも使用できます。アップグレードを実装するためにアプリケーション自体を変更する必要はありませんが、Oracle GoldenGateを使用してバージョン間のマッピングを実装するために、アプリケーションの新旧のバージョン間の差異に関する十分な知識が管理者には必要です。アプリケーションに対するユーザー制御や、これらのテクノロジの2番目に大きな区分に対するユーザー優先度によって、停止時間ゼロのアプリケーション・アップグレードの実行に適したアプローチが決まります。

これらのテクノロジの2番目に大きな差異は、エディションベース再定義が、通常はアプリケーションをサポートする単一データベースのみを使用することです。Oracle GoldenGateは2番目に同期化されたデータベースを使用してアップグレードを実行します。

- エディションベース再定義を使用することで、アプリケーションの旧バージョンは旧エディション内に、アプリケーションの新バージョンは新エディション内に存在し、どちらとも同じデータベース内にあります。エディションは分離メカニズムです。アプリケーションの新旧のバージョンで同じように表されるデータは、両方のバージョンで使用される表の列で一度だけ示されます。アプリケーションの2つのバージョンで異なるように表されるデータのみが2回存在する必要があります。したがって同期が必要なのは、2つのバージョン間で異なる、総データ中の通常はわずかな割合のみです。クロス・エディションはトランザクション内でトリガーされ、新旧データの潜在的な競合はコミットされる前に防止されるため、競合解決の必要性はありません。

- Oracle GoldenGateを使用することで、アプリケーションの旧バージョンは元のデータベースで稼働し、アプリケーションの新バージョンは2番目のデータベースで稼働します。2番目のデータベースは分離メカニズムです。すべてのデータ、つまり、アプリケーションの新旧のバージョンで同じように表されるデータと、アプリケーションの2つのバージョンで異なるように表されるデータの両方が2回存在する必要があります。したがって、同期はすべてのデータに対して必要です。同期は、REDOログのマイニングによって構築されるSQLのリプレイ・メカニズムに介入するコードを使用して、実装されます。したがって、これはトランザクション不可であり、新旧のデータ間の競合を防ぐことはできません。正確に言えば、競合解決を明示的な処理後の手順として実装することが必要です。

10.2 Oracle GoldenGateの構成ベスト・プラクティス

GoldenGateプロセスの停止時間によって起こった待機時間の増加を減らすために、GoldenGate Extract、Data pumpおよびReplicatの最適なパフォーマンスおよび高可用性を構成する次のようないくつかのベスト・プラクティスがあります。

- クラスタ化ファイル・システムの使用

- ASMログ・ファイルの読取りAPIの向上

- Replicatコミット動作

- Oracle Clusterware構成

- その他のOracle GoldenGateベスト・プラクティス

10.2.1 クラスタ化ファイル・システムの使用

クラスタ化ファイル・システムの使用は、ノード障害時にOracle GoldenGateのチェックポイント・ファイルおよび追跡ファイルの可用性を継続させるために不可欠です。障害発生後、Extractプロセスが最後に認識されたアーカイブREDOログ・ファイルの位置からマイニングを継続し、Replicatプロセスが障害発生前の同じ追跡ファイルの位置からの適用を開始できるようにするため、チェックポイント・ファイルの可用性の確保は不可欠です。Oracle Database Filesystem (DBFS)またはOracle Automatic Storage Management Cluster File System (Oracle ACFS)の使用によって、動作可能なデータベースまたはASMインスタンスを、Extractプロセスのソース、またはReplicatプロセスの宛先として使用できます。

Oracle GoldenGateとともに使用するため、DBFSまたはOracle ACFSを構成するためのベスト・プラクティスは、次の各参考資料に記載されています。

注意:
次のドキュメントに記載されているベスト・プラクティスは、Oracle Exadata Database Machineなどのすべてのサポート対象Oracle GoldenGateプラットフォームに適用されます。

関連項目:

- 次のWebサイトのMy Oracle Support Note 1319042.1の『Oracle GoldenGateを併用する場合のDBFS構成ベスト・プラクティス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1319042.1

- 次のWebサイトでGoldenGateリンクから製品の技術資料『Sun Oracleデータベース・マシン上のOracle GoldenGate』を参照してください。
http://www.oracle.com/technetwork/database/features/availability/index.html

10.2.2 ASMログ・ファイルの読取りAPIの向上

Oracle GoldenGate 11gには、Oracle ASMに格納されたログ・ファイルを読み取るための新たな最適化メソッドが導入されました。この新規メソッドは、Oracle ASMインスタンスに直接接続するのではなく、データベース・サーバーを使用してREDOログ・ファイルおよびアーカイブREDOログ・ファイルにアクセスします。データベースにはAPIモジュールを使用したライブラリが含まれている必要があります。ライブラリは現在、Oracle Databaseリリース10.2.0.5および11.2.0.2に含まれています。その他のリリースのAPIモジュールへのアクセスの詳細は、次のWebサイトのMy Oracle Support Note 1333171.1の『10.2.0.5および11.2.0.2以外のOracle Databaseリリースにおける、ASMのREDOログ・ファイルへのOracle GoldenGateに最適化されたアクセス』を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1333171.1

関連項目:
ExtractのTRANLOGOPTIONS DBLOGREADERパラメータの詳細は、『Oracle GoldenGate Windows and UNIXリファレンス・ガイド』(v11.1.1.1)を参照してください。

10.2.3 Replicatコミット動作

Oracle GoldenGateリリース11.1.1以下を使用している場合は、Replicatコミット動作をCOMMIT NOWAITに設定することをお薦めします。Replicatプロセスはトランザクションの適用時に各コミットで待機しないため、全体的なパフォーマンスが向上します。このことは、チェックポイント中のリカバリ・データの保護のためにチェックポイント表を使用する場合のみ、考慮してください。

Oracle Database 11gリリース1 (11.1)以下のリリースを使用中の場合は、Replicatパラメータ・ファイルを次のようにCOMMIT NOWAITに設定してください。

Replicatパラメータ・ファイルを次のようにCOMMIT NOWAITに設定してください。

SQLEXEC "ALTER SESSION SET COMMIT_WRITE='NOWAIT'";

Oracle Database 11gリリース2 (11.2)以上のOracle Databaseリリースの場合は、Replicatパラメータ・ファイルを次のようにCOMMIT NOWAITに設定してください。

SQLEXEC "ALTER SESSION SET COMMIT_WAIT='NOWAIT'";

GoldenGate v11.1.1.1 COMMIT NOWAITでの開始が、チェックポイント表の使用時におけるデフォルト動作です。

10.2.4 Oracle Clusterwareの構成

Oracle RAC環境内でOracle GoldenGateを実行すると、サーバー障害による停止時間を短縮する機能が提供されます。Oracle Clusterwareは、ノード障害時にOracle GoldenGateプロセスが動作可能ノードで自動的に起動するように構成できます。このような方法で、ExtractがREDOログのマイニングを続行し、Replicatが最後に記録されたチェックポイントからの適用を続行できます。

注意:
Oracle GoldenGateのDataポンプ・プロセス(リリースv11.1.1以下)を使用して、DBFSを使用しているデータベース・マシン上のソース・ホストから追跡ファイルを転送している場合(これはExadata Database Machineと非Exadataの構成に適用されます)は、次のWebサイトのMy Oracle Support Note 1313703.1の『Oracle GoldenGateベスト・プラクティス: Oracle Clusterwareを使用したOracle GoldenGateの高可用性』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1313703.1

関連項目:
GoldenGateによるOracle Clusterwareの構成手順の詳細は、次のWebサイトでGoldenGateリンクから製品の技術資料『Oracle Clusterwareを使用したOracle GoldenGateの高可用性』を参照してください。
http://www.oracle.com/technetwork/database/features/availability/index.html

10.2.5 その他のOracle GoldenGateベスト・プラクティス

Oracle GoldenGateの構成ベスト・プラクティスはOracle統合の強化に伴って増え続けています。すべてのコンポーネントに対するベスト・プラクティスの最新情報は、次のMAA Webサイトを参照してください。

http://www.oracle.com/goto/maa

現在のベスト・プラクティスには次のようなものがあります。

- 次のWebサイトのMy Oracle Support Note 1296168.1の『Oracle Databaseに対するOracle GoldenGateデータベースのスキーマ・プロファイル・チェック・スクリプト』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1296168.1

- 次のWebサイトのMy Oracle Support Note 1298562.1の『Oracle GoldenGateデータベースの完全データベース・プロファイル・チェック・スクリプト(全スキーマ)』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1298562.1

- 製品の技術資料は次のとおりです。

- 『Oracle GoldenGateを使用した停止時間ゼロのデータベース・アップグレード』

- 『Oracle GoldenGateを使用したアクティブ/アクティブ・データベース構成での競合の検出および解決のベスト・プラクティス』

これらは次のWebサイトのGoldenGateリンクから使用できます。

http://www.oracle.com/technetwork/database/features/availability/index.html

10.3 Oracle GoldenGateの運用ベスト・プラクティス

Oracle GoldenGateの管理および運用のベスト・プラクティスの詳細は、次のドキュメントを参照してください。

- 『Oracle GoldenGate Windows and UNIX管理者ガイド』

- 『Oracle GoldenGate Windows and UNIXトラブルシューティングおよびチューニング・ガイド』

- 次のWebサイトのMy Oracle Support Note 1299679.1の『Oracle GoldenGate - GoldenGate内のラグおよびパフォーマンスを監視するハートビート・プロセス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1299679.1

- 次のWebサイトのMy Oracle Support Note 1312092.1の『Oracle GoldenGateベスト・プラクティス: Oracle GoldenGate Veridata』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1312092.1

11 高速接続フェイルオーバーの構成

この章で説明する手順では、クライアント・バージョンおよびデータベース・バージョンが11.2.0.1以上であることを前提としています。リリース11.2.0.1には、11.1.0.7以下のリリースと比較して次のような機能が用意されています。

- ロールベースのサービス

- FAN ONSイベントをJDBCクライアントに送信するData Guardブローカ

- SCANアドレスのサポート

以前のバージョンには前述の機能がありませんが、手動構成で同様の結果を導くことが可能です。たとえば、次のようになります。

- データベース・ロールに基づくサービスの停止および起動を管理するトリガーを作成します。

- フェイルオーバーが発生した後で、外部ONSパブリッシャを利用してFANイベントを送信します。

- プライマリになる可能性のあるすべてのホストが含まれる、Oracle Net別名の作成。

11.2.0.1より前のリリースを構成する手順は、次のWebサイトのMAAホワイト・ペーパー『可用性の高いOracle Databaseのためのクライアント・フェイルオーバーのベスト・プラクティス: Oracle Database 10gリリース2』を参照してください。

http://www.oracle.com/goto/maa

障害のタイプ

Oracle Databaseインスタンスの計画外の障害は一般的なカテゴリに分類されます。

- Oracle RACデータベース内の個々のOracleインスタンスのクラッシュを引き起こす、サーバー障害またはその他の障害。可用性を維持するため、障害が発生したインスタンスに接続中のアプリケーション・クライアントには障害について迅速に通知し、Oracle RACデータベースの動作可能なインスタンスへの新規接続をすぐに確立する必要があります。

- アプリケーション層およびデータベース層の両方を使用不可状態にする、完全サイト障害。可用性を維持するため、本番データベースの冗長アプリケーション層と同期コピーをホスティングするセカンダリ・サイトに、ユーザーをリダイレクトする必要があります。

- プライマリ・データベース、単一インスタンス・データベース、またはOracle RACデータベース内の全ノードが使用不可になりますが、プライマリ・サイトのアプリケーション層は元のまま残される、部分サイト障害。

Oracle RACおよびOracle Data Guardでインスタンスとデータベースの高速フェイルオーバーおよびスイッチオーバーの効果を最大化するには、ベスト・プラクティスとして高速接続フェイルオーバーを構成します。高速接続フェイルオーバーを使用すると、データベース・サービスが使用不可能になった場合に、クライアント(中間層アプリケーションまたはデータベースに直接接続する任意のプログラム)を迅速かつシームレスに使用可能なデータベース・サービスにフェイルオーバーできます。

この章には、次の項目が含まれます。

- JDBCとOCIクライアントへのフェイルオーバーの構成

- Oracle RACデータベースのフェイルオーバーの構成

- Oracle Data Guard環境の構成

- スイッチオーバー操作中のクライアント移行

- ログイン・ストームの阻止

- アプリケーション・サポート

関連項目:

- 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『可用性の高いOracle Databaseのためのクライアント・フェイルオーバーのベスト・プラクティス: Oracle Database 11gリリース2』を参照してください。
http://www.oracle.com/goto/maa

- 『Oracle Database管理者ガイド』で、サービスおよびFANを使用したアプリケーションの高可用性に関する項を参照してください。

11.1 JDBCとOCIクライアントへのフェイルオーバーの構成

高速接続フェイルオーバーを有効にする構成のベスト・プラクティスは、クライアントのタイプ(JDBCまたはOCI)によって異なります。

JDBCクライアントでの高速接続フェイルオーバー

JDBCクライアントでは、次のベスト・プラクティスに従います。

1. JDBCクライアントで高速接続フェイルオーバーを有効化するため、DataSourceプロパティのFastConnectionFailoverEnabledをTRUEに設定します。

2. JDBCクライアントを構成して、各サイトのSCANアドレスが順番に記載された、既存のサービスに接続するためのアドレス・リストを含む接続記述子を使用します。

3. JDBCクライアントはoracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STRプロパティを設定する必要があります。このプロパティによって、障害発生時にJDBCクライアントが迅速にADDRESS_LISTを横断できます。

4. Oracle Notification Service(ONS)デーモンがクライアントで必要とされることのないように、JDBCクライアントでリモートONSサブスクリプションを構成します。

5. デフォルトでJDBCアプリケーションはsetONSConfigurationプロパティから3つのホストをランダムに選択し、その3つのONSデーモンへの接続を作成します。このデフォルトを変更して、接続がすべてのONSデーモンに対して行われるようにします。これを実行するには、JDBCアプリケーションの起動時に、次のプロパティを構成内のONSデーモンの合計数に設定します。
java - oracle.ons.maxconnections=4

関連項目:

- JDBCクライアントでの高速接続フェイルオーバーの有効化の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 『Oracle Database管理者ガイド』で、サービスおよびFANを使用したアプリケーションの高可用性に関する項を参照してください。

OCIクライアントでの高速接続フェイルオーバー

OCIクライアントでは、次のベスト・プラクティスに従います。

1. OCIクライアントで高速アプリケーション通知(FAN)を有効化するため、OCI_EVENTSパラメータで環境を初期化します。

2. OCIクライアント・アプリケーションをスレッド・ライブラリにリンクします。

3. AQ_HA_NOTIFICATIONSパラメータをTRUEに設定し、サービスで透過的アプリケーション・フェイルオーバー(TAF)属性を構成します。

4. OCIアプリケーションでデータベースへの接続に使用されるOracle Net別名を構成します。Oracle Net別名ではプライマリおよびスタンバイの両方のSCANホスト名を指定する必要があります。新規接続の作成で最高のパフォーマンスを得るには、Oracle Net別名でDESCRIPTION_LISTに対してLOAD_BALANCE=OFFを保持し、DESCRIPTIONsが整列されたリストで上から下に試行されるようにします。この構成では、2番目のDESCRIPTIONは、1番目のDESCRIPTIONに対するすべての接続が失敗した場合にのみ、試行されます。

関連項目:

- Oracle Call Interfaceクライアントでの高速接続フェイルオーバーの有効化の詳細は、『Oracle Database管理者ガイド』を参照してください。

- OCIでの透過的アプリケーション・フェイルオーバーの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

11.2 Oracle RACデータベースのフェイルオーバーの構成

Oracle Database 11gは、Oracle Real Application Clusters (Oracle RAC)およびOracle Data Guardにおけるアプリケーション・データの高度な可用性を可能にするインフラストラクチャを備えています。データベース層で高速アプリケーション・フェイルオーバーを構成する必要があります。

11.2.1 データベース・サービスの構成

上位レベルにおけるOracle RAC構成でのクライアント・フェイルオーバーの自動化には、新規インスタンスまたは動作可能インスタンスへのデータベース・サービスの再配置、TCPタイムアウトからクライアントを解放するための障害発生のクライアントへの通知、動作可能インスタンスへのクライアントのリダイレクトが含まれます(Oracle ClusterwareはFANメッセージをアプリケーションに送信します。アプリケーションはFANイベントに応答してすぐに処理を行います)。FANの詳細は、6.1.1項「クライアントの構成および移行の概要」を参照してください。

Oracle RACデータベース上のサービスについては、Oracle Enterprise ManagerまたはSRVCTLユーティリティが推奨されるサービス管理ツールです。単一のサービスをOracleデータベースの1つ以上のインスタンスに適用し、単一のインスタンスで複数のサービスをサポートできます。サービスを提供するインスタンスの数は、アプリケーションとは関係なくDBAによって管理されます。

関連項目:

- 6.1.1項「クライアントの構成および移行の概要」

- 6.2.5項「サービスおよび単一クライアント・アクセス名(SCAN)を使用したデータベースへの接続」

11.2.2 FANのサーバー側コールアウトのオプション構成

サーバー側コールアウトは、Oracle Clusterwareを構成する高可用性フレームワークとの単純かつ強力な統合メカニズムを提供します。サーバー側コールアウトの使用によって、トラブル・チケットを記録するか、管理者にページングして障害を警告することができます。UPイベントでは、サービスおよびインスタンスが起動された場合に新しい接続を作成して、新しく使用可能になったリソースをアプリケーションでただちに使用できます。

関連項目:

- 自動ワークロード管理の概要は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- クライアント・フェイルオーバーのベスト・プラクティスとFANサーバー側コールアウトのデプロイの詳細は、Oracle Technology Networkの次の場所にあるテクニカル記事『Oracle Real Application Clusters 11gリリース2での自動ワークロード管理』を参照してください。
http://www.oracle.com/technetwork/database/clustering/overview/index.html

11.3 Oracle Data Guard環境の構成

Oracle Data Guard環境を構成するには、次の作業を実行します。

- データベース・サービスの構成

- Data Guardブローカの使用

関連項目:
次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Data Guard 11gリリース2のクライアント・フェイルオーバーのベスト・プラクティス』を参照してください。
http://www.oracle.com/goto/maa

11.3.1 データベース・サービスの構成

Oracle Data Guard構成では、プライマリ・データベースではプライマリ・アプリケーション・サービスを、スタンバイ・データベースではスタンバイ・アプリケーション・サービスのみを実行します。Data Guard 11gリリース2以降では、データベース・ロールを各サービスに割り当てることで、プライマリ・データベースおよびスタンバイ・データベース上のデータベース・サービスの起動を自動的に制御できます(ロールにはPRIMARY、PHYSICAL_STANDBY、LOGICAL_STANDBYおよびSNAPSHOT_STANDBYが含まれます)。

サービスの管理ポリシーがAUTOMATICであり、そのサービスに割り当てられているロールがデータベースの現行のロールに一致する場合、データベースを起動するとデータベース・サービスが自動的に起動されます。

関連項目:

- SRVCTLによるデータベース・サービスの作成および削除の詳細は、『Oracle Database管理者ガイド』を参照してください。

- データベース・サービスの自動的な起動の詳細は、『Oracle Database管理者ガイド』を参照してください。

11.3.2 Data Guardブローカの使用

Oracle Data Guardブローカを使用して構成を管理するように、Oracle Data Guardを構成することがベスト・プラクティスです。Oracle Data Guardブローカではクライアント・アプリケーションにFANイベントを送信することで、停止したデータベースへの接続がクリーン・アップされ、新規の本番データベースに再接続されます。FANの詳細は、6.1.1項「クライアントの構成および移行の概要」を参照してください。

単一インスタンス(Oracle Restartを使用)とOracle RACデータベースの両方に対して、Oracle Clusterwareがインストールされ、プライマリ・サイトおよびスタンバイ・サイトでアクティブになっている必要があります。Oracle Data GuardブローカはOracle Clusterwareと連動して、Data Guardフェイルオーバーの発生後、ロールベースのサービスを新規プライマリ・データベースへ適切にフェイルオーバーします。詳細は、次を参照してください。

関連項目:
9.3.1項「Oracle Data GuardによるOracle Data Guardブローカの使用」

11.4 スイッチオーバー操作中のクライアント移行

Oracle Data Guardでは、スイッチオーバーという用語は、プライマリ・データベースとスタンバイ・データベースでロールがスイッチされる計画済イベントを表し、通常は計画済メンテナンスの実行中の停止時間を最小限に抑えることが目的です。計画外のフェイルオーバーに対応するための構成ベスト・プラクティスは、計画済スイッチオーバーのほとんどの要件にも対応しますが、ロジカル・スタンバイ・データベースに適用されるいくつかの追加的な手動手順は例外です(SQL Apply)。

注意:
Oracle Active Data Guardを使用するスイッチオーバーに関するその他の考慮事項はありません。

次の手順は、Oracle Data Guard 11gリリース2における追加的な手動のスイッチオーバー手順です。

1. プライマリ・データベースがスタンバイ・データベースに変換されます。これによってすべてのセッションが切断され、データベースがマウント状態にされます。Oracle Data Guardブローカがあらゆる読取り/書込みサービスを停止します。

2. クライアント・セッションがORA-3113を受け取り、再試行ロジック(OCIの場合はTAF、JDBCの場合はアプリケーション・コード・ロジック)が開始されます。

3. スタンバイ・データベースがプライマリ・データベースに変換され、存在するすべてのセッションが切断されます。Oracle Data Guardブローカが読取り専用サービスを停止します。

4. 読取り専用接続がORA-3113を受け取り、再試行ロジック(OCIの場合はTAF、JDBCの場合はアプリケーション・コード・ロジック)が開始されます。

5. 新規プライマリおよび新規スタンバイがオープンされるに従って、個々のサービスが各ロールに対して開始され、再試行を実行するクライアントではサービスが使用可能であることが確認され、接続されます。

ロジカル・スタンバイ・スイッチオーバーの場合:

1. 適切な再接続ロジックが構成されていることを確認します(詳細は、11.1項「JDBCとOCIクライアントへのフェイルオーバーの構成」と11.2項「Oracle RACデータベースのフェイルオーバーの構成」を参照してください)。たとえば、OCIアプリケーションの場合はTAFおよびRETRY_COUNTを構成し、JDBCアプリケーションの場合はコード再試行ロジックを構成します。

2. プライマリ・アプリケーションで使用されるサービスと、スタンバイ・データベースで有効になっている読取り専用アプリケーションを停止します。

3. プライマリ・アプリケーションおよび読取り専用アプリケーションのセッションを切断するか、停止します。

4. スイッチオーバーが完了したら、プライマリ・アプリケーションおよび読取り専用アプリケーションで使用されるサービスを再起動します。

5. 終了されたセッションは、サービスが使用可能になると再試行メカニズムの一環として再接続します。

6. アプリケーションが停止している場合は、アプリケーションを再起動します。

アプリケーションが再試行を実行する場合、スイッチオーバー操作中の移行クライアントにFANは必要ありません。FANが必要なのはTCPタイムアウトからクライアントを解放する場合のみで、この状態は計画外の停止中のみ発生します。

関連項目:
14.2.1.3項「Data Guardスイッチオーバーの実行方法」

11.5 ログイン・ストームの阻止

多数の接続があるアプリケーションのフェイルオーバー・プロセスにより、ログイン・ストームが発生することがあります。ログイン・ストームとは、データベース・インスタンスへの接続数が急激に増加し、CPUリソースを消費しつくしてしまうことです。CPUリソースが枯渇すると、アプリケーション・タイムアウトとアプリケーション・レスポンス時間が増加する可能性が高くなります。

ログイン・ストームを制御する手順:

- 接続速度リミッタを実装します。
ログイン・ストームを制御する主要な方法は、Oracleリスナーの接続速度リミッタ機能を実装することです。この機能は、1秒に処理できる接続の数を制限します。接続速度を低下させることで、CPUリソースが利用可能な状態に維持され、システムが無反応になりません。

- Oracle Databaseに共有サーバー運用を構成します。
接続速度リミッタを実装する他、一部のアプリケーションでは、Oracle Databaseに共有サーバー運用を構成することによって、ログイン・ストームを制御することができます。共有サーバーを使用すると、フェイルオーバー時間に作成する必要があるプロセスの数が大幅に減少します。

- 中間層接続プールの最大接続数を調整します。
ご使用のアプリケーションの中間層でそうした機能を利用できる場合、中間層接続プールの最大接続数を調整することによって接続数を制限してみます。

関連項目:

- 共有サーバー運用の構成と制御の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 接続速度リミッタの詳細は、ホワイト・ペーパー『Oracle Net Listener Connection Rate Limiter』を参照してください。
http://www.oracle.com/technetwork/database/enterprise-edition/oraclenetservices-connectionratelim-133050.pdf

- リスナー接続率のスロットリングの詳細および例は、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、ホワイト・ペーパー『Oracle ClusterwareとOracle Real Application Clustersを使用して計画外停止時の可用性を最適化するためのベスト・プラクティス』を参照してください。
http://www.oracle.com/goto/maa

11.6 アプリケーション・サポート

現在、PeopleSoft EnterpriseとOracle WebLogic ServerがFANイベントをサポートしています。

PeopleSoft PeopleToolsリリース8.50.09以上がFANをサポートしています。これによって、PeopleSoftアプリケーションではデータベース接続が切断された場合、データベース接続をOracle RACクラスタ内の動作可能インスタンス、またはOracle Data Guard構成内の新規プライマリ・データベースに自動的にフェイルオーバーできます。Oracle RACインスタンス障害、プライマリ・データベース障害、またはOracle Databaseの停止や再起動の場合、PeopleSoftサーバーおよびクライアントは引き続き稼働し、ユーザーが再度ログインする必要はありません。

Oracle WebLogic Server 10.3.4では、Oracle RACクラスタのサポートのために単一のデータ・ソース実装が導入されています。これはFANイベントに応答して、高速接続フェイルオーバー(FCF)、ランタイム接続ロード・バランシング(RCLB)、およびOracle RACインスタンスのすみやかな停止を提供します。XAアフィニティがグローバル・トランザクションIDレベルでサポートされています。この新機能はWebLogic Active GridLink for Oracle RACと呼ばれ、Oracle WebLogic Server内のGridLinkデータ・ソースとして実装されます。

FANイベントをサポートしないアプリケーションについては、Oracleの多数のアプリケーション(たとえば、SiebelやOracle E-Business Suite)が該当し、この項で説明されているすべての手順は最速のクライアント・フェイルオーバーのために完了する必要があります。このようなケースでFANイベントを使用できない場合でも、タイムアウトやアプリケーション再試行を使用することで、効率的なフェイルオーバーのためにアプリケーションを構成できます。

詳細は、次のWebサイトのMAAホワイト・ペーパー『可用性の高いOracle Databaseのためのクライアント・フェイルオーバーのベスト・プラクティス: Oracle Database 11gリリース2』を参照してください。

http://www.oracle.com/goto/maa

12 高可用性の監視

この章では、Enterprise Managerを使用したシステムの監視、およびアプリケーション・スタックのすべての階層での高可用性環境の監視と維持に関するベスト・プラクティスを示します。

この章には、次の項目が含まれます。

- 高可用性の監視と検出の概要

- Enterprise Managerを使用したシステム監視

- Enterprise Managerを使用した高可用性環境の管理

- クラスタ状態モニターの使用方法

12.1 高可用性の監視と検出の概要

システム、ネットワーク、データベース操作、アプリケーション、およびその他のシステム・コンポーネントを継続的に監視することで、問題を早期に検出できます。早期の検出により、問題を迅速に回避または解決できるため、ユーザーのシステム使用感が向上します。また、監視では、システムのパフォーマンス、拡大および再発する問題の傾向を示すシステム・メトリックを取得できます。この情報を使用して、予防対策の促進、セキュリティ・ポリシーの適用、およびジョブ処理の管理を行うことができます。データベース・サーバーでは、堅牢な監視システムで可用性を測定し、データベース・サーバーを使用不可能にする危険性のあるイベントを検出すると同時に、重大な障害については担当各所に即座に通知する必要があります。

監視システムは、それ自体が高可用性を保持し、監視対象のリソースと同じ運用ベスト・プラクティスと可用性プラクティスに準拠している必要があります。監視システムに障害が発生すると、すべての監視対象システムで診断データを取得することや管理者に問題を通知することができなくなります。

Enterprise Managerには、様々な通知オプションを備えた管理および監視機能が付属しています。環境の可用性およびパフォーマンスを監視する方法と、環境内の変化に対応してツールを使用する方法の推奨事項が含まれます。

12.2 Enterprise Managerを使用したシステム監視

Enterprise Managerの主なメリットは、ホスト・オペレーティング・システムからユーザー・アプリケーション(またはパッケージ・アプリケーション)までのアプリケーション・スタック全体で複数のコンポーネントを管理できることです。Enterprise Managerは、アプリケーションの各レイヤーをターゲットとして扱います。ターゲット(データベース、アプリケーション・サーバー、ハードウェアなど)は、同じタイプの他のターゲットとともに表示するか、アプリケーション・タイプごとにグループ化することができます。また、すべてのターゲットを、高可用性コンソールから単一のビューで確認することも可能です(詳細は12.3.3項「高可用性コンソールを使用したデータベース可用性の管理」を参照)。各ターゲット・タイプには、特定のターゲットに関連する詳細情報のサマリーを含む、デフォルトで生成されるホームページがあります。異なるタイプのターゲットは、機能ごとに(つまり、同じアプリケーションをサポートするリソースとして)グループ化できます。

すべてのターゲットは、Oracle Management Agentによって監視されます。すべての管理エージェントは、任意のシステム上で稼働し、ターゲットのセットを監視対象とします。ターゲットは、管理エージェントが稼働するシステムとは別のシステム上にあってもかまいません。たとえば、管理エージェントでは、エージェントをネイティブにホストしないストレージ・アレイを監視できます。管理エージェントをホストにインストールすると、そのホストはマシン上の他のターゲットとともに自動的に検出されます。

さらにEnterprise Managerには、最大可用性アーキテクチャ(MAA)のベスト・プラクティス実装を支援するMAAアドバイザ(詳細は12.3.4項「MAAアドバイザを使用した高可用性ソリューションの構成」を参照)が用意されています。MAAアドバイザのページでは、大部分の停止タイプにOracleソリューションを推奨し、各ソリューションの利点を説明しています。

Oracle HA環境でのEnterprise Managerを使用したインフラストラクチャの監視に加えて、Oracle Auto Service Request (ASR)を使用して、特定のハードウェア障害の発生時にOracleのSunサーバーおよびストレージ・システムの自動ケース生成を使用することにより、問題をより迅速に解決できます。詳細は、次の場所にあるMy Oracle Supportのノート1185493.1の『Oracle Auto Service Request』を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1185493.1

関連項目:
Enterprise Manager ArchitectureおよびOracle Management Agentの詳細は、『Oracle Enterprise Manager概要』を参照してください。

12.2.1 Oracle Enterprise Managerの「ホーム」ページ

図12-1に示すとおり、Enterprise Managerの「ホーム」ページには、検出されたすべてのターゲットの可用性が表示されます。

図12-1 Enterprise Managerの「ホーム」ページ

Enterprise Managerの「ホーム」ページには、次の情報が表示されます。

- すべてのターゲットを対象とする現在の可用性のスナップショット。「すべてのターゲットのステータス」円グラフにより、管理者は、使用可能なターゲット(「稼働中」)、使用不可能なターゲット(「停止中」)、またはコンソールとの通信が途絶えているターゲット(「不明」)を即座に判別できます。

- 監視対象システム全体で認識されているアラート数とジョブの問題数の概要。詳細情報を表示するには、対応するリンクをクリックするか、任意のEnterprise Managerページから「アラート」タブに移動します。

- 重大度と、すべての管理対象ターゲットでのポリシー違反の総数のビュー。ドリルダウンすると、違反のソースとタイプが判明します。

- 「すべてのターゲット・ジョブ」には、すべてのEnterprise Managerジョブについて、スケジュール済の実行、実行中の実行、一時停止中の実行、問題のある実行(停止中/失敗)の数が一覧表示されます。ステータス・グループの隣にある数をクリックすると、それぞれのジョブのリストが表示されます。

- システム内で実際に何が検出されたかを示す概要情報。このリストは、ハードウェア・レベルとOracleレベルで表示できます。

アラートは、複数の要因の組合せにより生成されるもので、特定のメトリックに対して定義されます。メトリックは、管理エージェントにより調査されてOracle Management Repositoryに送信されるデータ・ポイントです。アラートは、単純なハートビート・テストに基づくコンポーネントの可用性である場合や、特定のパフォーマンス測定(ディスク・ビジーまたは特定の待機イベントを待機するプロセスの割合など)の評価である場合があります。

どのメトリックでも、エラー、警告、クリティカルおよびクリアという4つの状態をチェックできます。管理者は、次のようなポリシーを決定する必要があります。

- どのオブジェクトを監視するか(データベース、ノード、リスナー、またはその他のサービス)。

- 何を計測対象として調査するか(可用性、CPUビジー割合など)。

- どの程度の頻度でメトリックを調査するか。

- 事前定義されたしきい値をメトリックが超えたときに何を実行するか。

これらすべての項目は、システムのビジネス要件に基づいて決定します。たとえば、すべてのコンポーネントで可用性を監視する場合でも、一部のシステムは業務時間中にのみ監視することが可能です。特定のパフォーマンス問題のあるシステムでは、問題をデバッグするために、追加のパフォーマンス・トレース機能を有効化できます。

関連項目:
Enterprise Managerでのメトリックの監視および使用の詳細は、『Oracle Enterprise Manager Cloud Control概要』を参照してください。

12.2.2 各システムのメトリックと通知ルールの構成

通知ルールは、Enterprise Managerに検出されたターゲットに自動的に適用される、メトリックに対する定義済のアラートのセットです。たとえば、管理者は、データベース・ターゲットの可用性を監視して、データベースに障害が発生した場合は電子メール・メッセージを生成するルールを作成できます。作成したルールは、既存のすべてのデータベースと、将来作成される任意のデータベースに適用できます。これらのルールにアクセスするには、「プリファレンス」に移動し、「ルール」を選択します。

ルールでは、サービス可用性に影響する可能性のある問題など、即座に対処する必要のある問題や、Oracleエラーまたはアプリケーション・エラーを監視します。サービス可用性は、アプリケーション・スタックの任意のレイヤー(ノード、データベース、リスナー、重大なアプリケーション・データなど)の停止によって影響を受けます。データベースに接続できない、またはアプリケーション機能に不可欠なデータにアクセスできないなどのサービス可用性の障害については、迅速に特定してレポートを確認し、問題に対処する必要があります。アーカイブ・ログ・ディレクトリが一杯であるなど、サービス停止につながる可能性のある問題も、システム停止を避けるために適切に対処する必要があります。

Enterprise Managerには、可用性を監視するための強力なフレームワークを提供する一連のデフォルト・ルールが用意されています。デフォルト・ルールは、Enterprise Managerに付属のインストール済ターゲット・タイプごとに提供されます。これらのルールを変更して個々のサイトのポリシーに準拠し、サイト固有のターゲットまたはアプリケーション用にルールを作成できます。特定の期間にユーザーに通知するようにルールを設定して、自動化されたカバレッジ・ポリシーを作成することもできます。

次のベスト・プラクティスを使用します。

- ターゲット・アーキテクチャの重要なコンポーネントの各ルールは、ルール変更ウィザードを使用して可用性要件を満たすように変更します。データベース・ルールの場合、ターゲットごとに表12-1、表12-2および表12-3のメトリックを設定します。監視頻度は、各コンポーネントの品質保証契約(SLA)に基づいて決定します。

- ビーコン機能を使用して、個々のアプリケーションのパフォーマンスを追跡します。ビーコンを設定すると、通常のアプリケーション作業のかわりとなるユーザー・トランザクションを実行できます。Enterprise Managerでは、このトランザクションのレスポンス時間を分析用のコンポーネントに分割します。また、このトランザクションの実行時間が事前定義済の制限値を超えた場合、アラートを起動できます。

- 通知メソッドを追加して各通知ルールで使用します。デフォルトでは、潜在的な問題を管理者に通知する最も簡単な方法は、電子メールの送信です。この通知メソッドを拡張するため、電子メール以外の方法でアラートを送信するSNMPトラップまたはオペレーティング・システム・スクリプトへのコールアウトを追加できます。これにより、電子メール・システムのコンポーネントが停止した場合に問題が発生することを回避できます。追加の通知メソッドを設定するには、任意のEnterprise Managerページの上部にある「設定」リンクを使用します。

- ターゲットの可用性の計算でエラーが発生した場合に管理者に通知するよう通知ルールを変更します。これにより、コンポーネントの可用性の誤った読取りが発生することもありますが、システム管理者にとって最高度の通知レベルが保証されます。

関連項目:

- ビーコンの概念的な情報は、『Oracle Enterprise Manager Cloud Control概要』を参照してください。

- サービス・テストとビーコンの構成方法の詳細は、『Oracle Enterprise Managerアドバンスト構成』を参照してください。

図12-2は、可用性状態を選択するための「通知ルールの編集: 」プロパティ・ページを示しています。「停止中」オプションが選択されています。

図12-2 可用性の通知ルールの設定

また、表12-1、表12-2および表12-3にリストされているメトリックがデータベース通知ルールに追加されることを確認します。データベース・ホームページの「関連リンク」セクションからアクセスできる「メトリックとポリシー設定」ページを使用して、これらのメトリックを構成します。

サービス停止の原因となる可能性のある領域管理の条件は、表12-1のメトリックを使用して監視します。

表12-1 領域を監視するための推奨事項

メトリック

推奨事項

表領域使用率(%)

このデータベース・レベルのメトリックを設定すると、各表領域の使用可能な領域の使用率(%)をチェックできます。クラスタ・データベースでは、このメトリックは、メンバー・インスタンス単位ではなく、クラスタ・データベース・ターゲット・レベルで監視されます。このメトリックを使用する場合、管理者は、Enterprise Managerがテスト対象とするしきい値の割合と、メッセージを管理者に生成および送信する前に検出を必要とするエラーの発生数を選択できます。使用済領域の割合がしきい値の引数で指定された値を超えると、警告アラートまたはクリティカル・アラートが生成されます。

デフォルト設定は、85%を警告、97%を領域使用率のクリティカルしきい値とすることをお薦めしますが、これらの値はシステムの使用状況に応じて適切に調整してください。また、このメトリックは、特定の表領域を監視するようカスタマイズできます。

注意: 「ジョブ・ライブラリ」には次の名前のEnterprise Managerジョブがあります。

DISABLE TABLESPACE USED (%) ALERTS FOR UNDO AND TEMP TABLESPACES

このジョブは、すべてのUNDOおよびTEMP表領域のアラートを無効にする場合に使用します。このジョブは、TEMPおよびUNDO表領域のアラートが多すぎる場合に役立ちます。

ダンプ領域使用率(%)

このメトリックを設定すると、ダンプ出力先ディレクトリを監視できます。最初にエラーが発生したときに最大量の診断情報を保存するためには、ダンプ領域が使用可能である必要があります。デフォルト設定は、70%で警告、90%でエラーとすることをお薦めしますが、これらの値はシステムの使用状況に応じて調整してください。

このメトリックは、「ダンプ領域」メトリック・グループで設定します。

リカバリ領域空き領域(%)

これは、15分ごと、またはファイル作成時のいずれか早い方の時点で、サーバーにより評価されるデータベース・レベルのメトリックです。このメトリックは、アラート・ログにも出力されます。クラスタ・データベースでは、このメトリックは、メンバー・インスタンス単位ではなく、クラスタ・データベース・ターゲット・レベルで監視されます。

クリティカルのしきい値は3%未満、警告のしきい値は15%未満に設定されます。これらのしきい値はカスタマイズできません。アラートの最初の発生時にアラートが返され、使用可能な領域が15%を超えるまでアラートは消去されません。

使用可能なファイル・システム(%)

デフォルトで、このメトリックにより各ホストのルート・ファイル・システムを監視します。デフォルトの警告レベルは20%で、クリティカル警告は5%です。

アーカイブ領域使用率(%)

アーカイブ領域保存先で使用されている領域の割合を返すには、このメトリックを設定します。使用済領域がしきい値引数で指定したしきい値を超えると、警告アラートまたはクリティカル・アラートが生成されます。

データベースがARCHIVELOGモードで稼働していない場合、このメトリックは登録されません。デフォルトの警告しきい値は80%ですが、警告を送信するには70%フルを使用し、クリティカルしきい値には90%を使用することを検討してください。

Enterprise Manager 11gでは、データベース・アラート・ログを監視するメカニズムは、サポート・ワークベンチと緊密に統合されており、レポートされる各問題またはインシデントに対してパッケージを生成し、それらをサポートに迅速にアップロードできるという利点があります。

サポート・ワークベンチとの統合の一環として、エラーは様々なクラスとグループに分類され、それぞれ異なるメトリックによって処理されます。最上位レベルの分類には、インシデントおよび操作エラーという2種類のエラー・クラスがあります。

- インシデントは、データベース・アラート・ログ・ファイルに記録されるエラーであり、監視されているデータベースでクリティカル・エラー条件が検出されたことを示します。たとえば、クリティカル・エラー条件には、一般的な内部エラーやアクセス違反があります。

- 操作エラーは、データベース・アラート・ログ・ファイルに記録されるエラーであり、監視されているデータベースでデータベースの操作に影響する可能性のあるエラーが検出されたことを示します。たとえば、操作エラーには、アーカイバのハングやメディア障害があります。

表12-2に示すように、アラート・ログでレポートされるエラーのアラートを生成するメトリックを構成します。

注意:
表12-2のアラート・ログ・メトリックおよびEnterprise Managerでの11gデータベース・ターゲットのアラート・ログの監視の詳細は、次の場所にあるMy Oracle Supportのノート949858.1の『Monitoring 11g Database Alert Log Errors in Enterprise Manager』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=949858.1

表12-2 アラート・ログを監視するための推奨事項

メトリック

推奨事項

一般的な内部エラー・ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-0600エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

アクセス違反ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-7445またはORA-3113エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

セッション終了のステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-603エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

メモリー不足ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-4030またはORA-4031エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

REDOログの破損ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-353、ORA-355またはORA-356エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

DBの不整合状態ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-1410またはORA-8103エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

デッドロック・ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-4020エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

注意: このメトリックは、アプリケーション・レベルのデッドロック(ORA-0060エラー)がアラート・ログにレポートされたときに、アラートを生成しません。

内部SQLエラー・ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-0604エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

クラスタ・エラー・ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-29740エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

データ・ブロック破損ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-1578、ORA-1157またはORA-27048エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

メディア障害ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-1242またはORA-1243エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

一般的なインシデント・ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上のORA-700、ORA-255、ORA-239、ORA-601、ORA-602、ORA-255、ORA-240、ORA-494、ORA-3137、ORA-202、ORA-214、ORA-227、ORA-1103、ORA-312、ORA-313、ORA-1110、ORA-1542、ORA-32701、ORA-32703またはORA-12751エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

一般的な操作エラー・ステータス

「クリティカル」しきい値を0に設定して、メトリックが前回収集された後で1つ以上の一般操作エラーがアラート・ログにレポートされるたびにアラートが生成されるようにします。

処理容量を超えることがないようシステムを監視します。これらのメトリックの警告とクリティカルのしきい値は、表12-3の推奨事項に従って、システムの使用パターンに基づいて変更する必要があります。

表12-3 処理容量を監視するための推奨事項

メトリック

推奨事項

プロセス制限

このメトリックのしきい値を設定すると、現在のプロセス数がPROCESSES初期化パラメータの値に接近したときに警告を生成できます。

セッション制限

このメトリックのしきい値を設定すると、インスタンスがデータベースに許可されている同時接続の最大数に接近したときに警告を生成できます。

図12-3は、メトリックを設定および編集するための「メトリックとポリシー設定」ページを示しています。オンライン・ヘルプには、すべてのメトリックに関する完全なリファレンス情報があります。個別のメトリックのリファレンス情報にアクセスするには、オンライン・ヘルプの検索機能を使用します。

図12-3 メトリックの通知ルールの設定

関連項目:

- 通知ルールおよびメトリックしきい値の設定方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- Enterprise Managerサポート・ワークベンチを使用した問題の表示の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- 使用可能なメトリックの詳細は、『Oracle Enterprise Manager Oracle Databaseおよびデータベース関連メトリック・リファレンス・マニュアル』を参照してください。

12.2.3 データベース・ターゲット・ビューを使用したシステム状態、可用性およびパフォーマンスの監視

図12-4のデータベース・ターゲットの「ホーム」ページには、システムのパフォーマンス、領域使用率、および高速リカバリ領域で使用されている領域のパーセンテージや「フラッシュバック・データベース・ロギング」ステータス(Enterprise Manager 11gでは高速リカバリ領域に「フラッシュ・リカバリ領域(%)」というラベルが付いています)などの重要な可用性コンポーネントの構成が表示されています。

ターゲットの最新のアラートは、図12-4に示すように「アラート」表で参照できます。「メッセージ」列のリンクをクリックして、アラートに関する詳細情報にアクセスできます。

図12-4 データベースの「ホーム」ページ

パフォーマンス分析とパフォーマンス・ベースライン

Enterprise Managerのデータベース・ターゲットのメトリックの多くは、パフォーマンスに関連します。パフォーマンス品質保証契約に到達しないシステムは、高可用性システムの要件を満たしません。パフォーマンスの問題が大規模なシステム停止の原因となることはまれですが、それでも顧客の一部に対するサービスを停止させる可能性があります。このタイプの停止は、一般的にアプリケーション・サービス低下と呼ばれます。サービス低下の主な原因は、1つ以上のインフラストラクチャ・コンポーネントの断続的または部分的障害です。ITマネージャは、インフラストラクチャ・コンポーネントの稼働状況(レスポンス時間、待機時間および可用性)と、エンド・ユーザーに提供されるアプリケーション・サービスの品質に対するこれらのコンポーネントの影響を把握しておく必要があります。

品質保証契約を満たす通常の動作から導出されたパフォーマンス・ベースラインは、パフォーマンス・メトリック・アラートの構成要素を決定します。ベースライン・データは、アプリケーションを本番稼働する初日から収集し、次の項目を含む必要があります。

- アプリケーション統計(トランザクション量、レスポンス時間、Webサービス時間)

- データベース統計(トランザクション率、REDO速度、ヒット率、上位5位の待機イベント、上位5位のSQLトランザクション)

- オペレーティング・システム統計(CPU、メモリー、I/O、ネットワーク)

Enterprise Managerを使用して、データベース・パフォーマンスのベースライン・スナップショットをキャプチャし、自動ワークロード・リポジトリ(AWR)ベースラインを作成できます。Enterprise Managerは、これらの値をシステム・パフォーマンスと比較し、結果を「データベース・ターゲット」ページに表示します。基準のベースラインから値が大きく逸脱した場合に、アラートを送信することも可能です。自動ワークロード・リポジトリの詳細は、「自動パフォーマンス・チューニング機能の使用」を参照してください。

すべてのデータベース・ターゲットに対して、表12-4のメトリックを取得するようデータベース通知ルールを設定します。

表12-4 パフォーマンス関連メトリックに関する推奨事項

メトリック

レベル

推奨事項

I/Oリクエスト(1秒当たり)

インスタンス

このメトリックは、データベースのI/O読取りおよび書込みリクエストの合計率を示します。このメトリックは、操作の数がユーザー定義のしきい値を超えたときにアラートを送信します。このメトリックは、Enterprise Managerでも使用できるオペレーティング・システム・レベルのメトリックと組み合せて使用します。

このメトリックは、システムで使用可能な合計I/Oスループット、使用可能なI/Oチャネルの数、ネットワーク帯域幅(SAN環境の場合)、ディスク・キャッシュの効果(ストレージ・アレイ・デバイスを使用している場合)、最大I/Oレート、およびデータベースで使用可能なスピンドルの数に基づいて設定します。

データベースCPU時間(%)

インスタンス

このメトリックは、CPUで費やされるデータベース・コール時間の割合を示します。データベースCPU時間が50%から25%に急激に低下した場合など、システムの稼働状況に変化があったことを検出するために使用できます。

通知前の連続した状態変化の数という列は、アラートの生成前にしきい値との比較によるTRUEを許容する連続回数を示します。この使用率は、ピーク期間では一般的ですが、リソース集中型のプロセスや潜在的なリソース不足を表すインジケータにもなります。

待機時間(%)

インスタンス

過剰なアイドル時間は、1つ以上のリソースにボトルネックが発生していることを示します。このインスタンス・レベルのメトリックは、アプリケーションが問題なく動作しているときのシステム待機時間に基づいて設定します。

1秒当たりのネットワーク・バイト

インスタンス

このメトリックは、Oracleによって生成されるネットワーク・トラフィックをレポートします。このメトリックは、潜在的なネットワーク・ボトルネックを示します。このメトリックは、ピーク期間中の実際の使用状況に基づいて設定します。

ページインされたページ/秒

ホスト

UNIXベースのシステムでは、1秒当たりにページインされたページ数(フォルト・メモリー参照を解決するためのディスクからの読取り)を表します。このメトリックは、cpu_stat0、*(システム上のすべてのCPU)などのホストCPUパラメータで指定されたCPUについて、ページインされたページ数を調べます。

Microsoft Windowsの場合、このメトリックはハード・ページ・フォルトを解決するためにページがディスクから読み込まれた1秒当たりの回数です。ハード・ページ・フォルトは、プロセスが作業セットまたは物理メモリー内の他の場所にない仮想メモリー内のページを参照し、ディスクから取得する必要がある場合に発生します。ページがない場合、読込み操作を最大限に活用するため、システムは隣接した複数のページをメモリーに読み込もうとします。

実行キューの長さ

ホスト

UNIXベースのシステムでは、「実行キューの長さ」メトリックは最後の間隔におけるメモリーおよび実行対象サブジェクト内の平均プロセス数を表します(1分平均、5分平均、15分平均)。

「実行キューの長さ」がCPU数のときにアラートを生成することをお薦めします。(これを行う別の方法として、「平均のロード」メトリックを監視し、「最大CPU」と比較することもできます。)

このメトリックは、Microsoft Windowsでは使用できません。

関連項目:

- パフォーマンス監視の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- Enterprise Managerを使用した監視方法とチューニング方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

12.2.4 メトリックを使用したData Guardシステムの可用性の監視

Enterprise Managerのメトリックを設定すると、Data Guard構成の可用性を監視できます。表12-5に、Data Guardデータベースの監視に利用できるメトリックを示します。

表12-5 Data Guardメトリックを設定するための推奨事項

メトリック

推奨事項

Data Guardステータス

Data Guard構成におけるシステムの問題について通知します。

適用ラグ

プライマリ・データベースに対するスタンバイの遅れを表示します(単位は秒)。遅れが、ユーザーが指定したしきい値(指定した場合)を超過すると、このメトリックによりスタンバイ・データベース上でアラートが生成されます。

フェイルオーバー推定時間

このスタンバイ・データベースにフェイルオーバーするのに必要な時間のおよその秒数を表示します。

REDO Apply速度

このスタンバイ・データベース上でのREDO Apply速度を表示します(単位はKB/秒)。

トランスポート・ラグ

このスタンバイ・データベースでまだ利用できないREDOのおよその秒数を表示します。ラグがあるのは、REDOデータが未転送だったり、ギャップがある可能性があったりするためです。遅れが、ユーザーが指定したしきい値(指定した場合)を超過すると、このメトリックによりスタンバイ・データベース上でアラートが生成されます。

12.3 Enterprise Managerを使用した高可用性環境の管理

次の推奨事項に従って、Enterprise Managerをシステム管理のプロアクティブな部分として、また問題の通知と分析に使用します。

- Enterprise Managerポリシー違反のチェック

- Enterprise Managerを使用したOracleパッチの管理とシステム・ベースラインの維持

- 高可用性コンソールを使用したデータベース可用性の管理

- MAAアドバイザを使用した高可用性ソリューションの構成

12.3.1 Enterprise Managerポリシー違反のチェック

Enterprise Managerには、すべてのデータベースのベスト・プラクティスとして、ポリシーと推奨事項の事前インストール済のセットが付属しています。これらのポリシーはデフォルトでチェックされ、違反の数は図12-5のように「ターゲット」ページの「ポリシー違反」領域に表示されます。

図12-5 ポリシー違反を表示しているターゲットのデータベースの「ホーム」ページ

違反の詳細を参照するには、「ポリシー違反」領域のリンクを選択します。図12-6に、「ポリシーの傾向の概要」ページを示します。

図12-6 データベース・ターゲットの「ポリシーの傾向の概要」ページ

ポリシー違反を参照するには、図12-7に示すように、「コンプライアンス」タブから「違反」を選択します。

図12-7 ポリシー違反が表示された「コンプライアンス」タブの表示

関連項目:
既存のポリシー定義の詳細は、『Oracle Enterprise Managerポリシー・リファレンス・マニュアル』を参照してください。

12.3.2 Enterprise Managerを使用したOracleパッチの管理とシステム・ベースラインの維持

アプリケーション環境の任意の監視対象システムについて、Enterprise Managerを使用して、次の場所にあるMy Oracle Supportからパッチをダウンロードおよび管理できます。

https://support.oracle.com/

ジョブを設定して、ユーザー環境に関連するパッチを定期的にチェックできます。これらのパッチは、ダウンロードして管理リポジトリに直接保存できます。パッチは、管理リポジトリから複数のシステムにステージングして、メンテナンス・ウィンドウ中に適用できます。

あるシステムのパッチ・レベルを調査して、それらを1対1または1対多の関係において複数のシステム間で比較できます。この場合、1台のシステムをベースラインとして区別し、他の複数のシステムにおけるメンテナンス要件の実証に使用できます。この機能は、データベース・パッチと同様に、オペレーティング・システム・パッチにも使用可能です。

関連項目:

- My Oracle Supportを使用したパッチ適用の詳細は、ソフトウェアとサーバーのプロビジョニングおよびパッチ適用のためのEnterprise Manager管理者ガイドを参照してください。

- Oracleデータベースのパッチ適用の詳細は、ソフトウェアとサーバーのプロビジョニングおよびパッチ適用のためのEnterprise Manager管理者ガイドを参照してください。

- 14.2項「計画済の停止による停止時間の回避または短縮」

12.3.3 高可用性コンソールを使用したデータベース可用性の管理

高可用性(HA)コンソールは、各データベースの可用性を一箇所で監視できる、ダッシュボード・スタイルのページです。あらゆるデータベース上で使用でき、データベースがData Guard構成の一部の場合、HAコンソールで、プライマリ・データベースから任意のスタンバイ・データベースにビューを変更することができます。

HAコンソールを使用して、次の操作を行います。

- 関連ターゲット(スタンバイ・データベースなど)からのイベントなどの、高可用性イベントの表示

- データベースのステータスなど、高可用性サマリーの表示

- 最後のバックアップ・ステータスの表示

- 高速リカバリ領域が構成されている場合、その使用量の表示

- Oracle Data Guardが構成されている場合: Data Guardサマリーの表示、任意のデータベース・ターゲットに対するData Guardスタンバイ・データベースのセットアップ、管理リポジトリを含むデータベース以外のデータベース・ターゲットのスイッチオーバーとフェイルオーバーの管理、およびData Guard構成の状態の集中監視

- Oracle RACが構成されている場合: 上位サービスなどのOracle RACサービスのサマリーの表示

注意:
Oracle Enterprise Manager Database Controlでは、フラッシュ・リカバリ領域の名前が変更されて高速リカバリ領域という名前を使用しています。HAコンソールとEnterprise Managerでは、フラッシュ・リカバリ領域という名前を使用します。高速リカバリ領域の詳細は、5.1.3項「高速リカバリ領域の使用」を参照してください。

図12-8はHAコンソールを示します。この図は、プライマリ・データベースの要約情報、詳細および履歴統計を示し、プライマリ・ターゲットのスタンバイ・データベース、様々なData Guardスタンバイ・パフォーマンス・メトリックと設定、およびデータ保護モードを示しています。

図12-8 高可用性コンソールでのプライマリ・データベースの監視

図12-8では、「可用性のサマリー」に、プライマリ・データベースが稼働中で、その可用性が現在100%であることが示されています。「可用性のサマリー」には、Oracle ASMインスタンスのステータスも示されています。「可用性イベント」表には、特定の高可用性イベント(アラート)が示されます。メッセージをクリックすると、詳細情報を表示することができます(あるいは、そのイベントが簡略表示に戻ります)。このデータベースの特定のソリューション領域を設定、管理および構成するには、「可用性のサマリー」の「MAAアドバイザ」の横で「詳細」をクリックして、「最大可用性アーキテクチャ(MAA)アドバイザ」ページ(第12.3.4項「MAAアドバイザを使用した高可用性ソリューションの構成」で詳細に説明されています)に移動します。

「バックアップ/リカバリ・サマリー」領域には、「最終バックアップ」および「次のバックアップ」情報が表示されます。「高速リカバリ領域の使用量」グラフは、高速リカバリ領域のおよそ83%が現在使用されていることを示しています。「使用済(再利用不可能)高速リカバリ領域(%)」グラフには、過去2時間の使用量が表示されます。グラフをクリックすると、メトリック詳細のページが表示されます。

「Data Guardサマリー」領域には、プライマリ・データベースが「最大可用性」モードで実行され、「ファスト・スタート・フェイルオーバー」が有効になっていることが示されています。「保護モード」の隣のリンクをクリックすると、データ保護モードを変更できます。「スタンバイ・データベース」表を見ると、フィジカル・スタンバイ・データベース(north)はプライマリ・データベースのメトリック(「適用ラグ」/「トランスポート・ラグ」)に追随して0秒を示し、「高速リカバリ領域の使用」(FRA)は16.02%です。「プライマリ・データベースREDO率」グラフには、過去2時間のREDO傾向が示されます。Data Guardが構成されていない場合、コンソールの隅の「切替え」ボックスは表示されません。

図12-9は、図12-8と同様の情報を示していますが、この情報はリアルタイム問合せを実行しているフィジカル・スタンバイ・データベースであるスタンバイ・データベース(north)に関するものです。「スタンバイ・データベース」表を見ると、「適用ラグ」/「「トランスポート・ラグ」メトリックは、フィジカル・スタンバイ・データベースがプライマリ・データベースに追随していることを示し、「高速リカバリ領域の使用」(FRA)は16%です。Data Guardが構成されていない場合、コンソールの隅の「切替え」ボックスは表示されません。

図12-9 高可用性コンソールでのスタンバイ・データベースの監視

図12-10は、「サービス・サマリー」および「サービスの詳細」領域のサンプル値を示しています。これらの領域は、「上位サービス」や「問題のサービス」など、Oracle RAC Servicesに関するサマリー情報と詳細情報を示します。

図12-10 サービスを表示している高可用性コンソールでのクラスタの監視

関連項目:
データベース管理の詳細は、『Oracle Enterprise Manager Cloud Control概要』を参照してください。

12.3.4 MAAアドバイザを使用した高可用性ソリューションの構成

MAA Advisorは、最適な高可用性アーキテクチャを実現するためのOracleベスト・プラクティスの実装を支援するために設計されています。

高可用性コンソールの「可用性のサマリー」セクションでは、MAAアドバイザへのリンクで次のことが可能です。

- 各停止タイプ(サイト障害、コンピュータ障害、ストレージ障害、ヒューマン・エラーおよびデータ破損)の推奨Oracleソリューションの表示

- 構成ステータスの表示、「Oracleソリューション」列のリンクを使用した「Enterprise Manager」ページへの移動、およびそこでのソリューションの構成

- 各ソリューションの利点の把握

- ホワイト・ペーパー、ドキュメントなどの情報があるMAA Webサイトへのリンク

「MAAアドバイザ」ページの表には、停止タイプ、それぞれの停止に対するOracleソリューション、構成ステータス、および利点が表示されます。MAAアドバイザを使用すると、次のようにして高可用性ソリューションを表示できます。

- プライマリ・データベースの推奨事項のみ: プライマリ・データベースの推奨ソリューション(デフォルト・ビュー)のみを簡略表示します。

- すべてのソリューション: この拡張ビューには、この構成のすべてのプライマリ・データベースとスタンバイ・データベースのすべての推奨構成およびステータスが表示されます。これには、データベース名を提供し、データベースのロール(「プライマリ」、「フィジカル・スタンバイ」または「ロジカル・スタンバイ」)を示す追加の「ターゲット名: ロール」列が含まれます。

図12-11は、「表示」で「すべてのソリューション」ビューが選択された「MAAアドバイザ」ページの例を示しています。

図12-11 Enterprise Managerの「最大可用性アーキテクチャ(MAA)アドバイザ」ページ

「Oracleソリューション」列でリンクをクリックすると、移動先のページで特定のソリューション領域をセットアップ、管理および構成することができます。ソリューションの構成が終わったら、「リフレッシュ」をクリックして構成ステータスを更新します。ページがリフレッシュされたら、「コンソール」ページで「アドバイザの詳細」をクリックして、更新された値を参照します。

12.4 クラスタ状態モニターの使用方法

クラスタ状態モニター(CHM)はリアルタイムにオペレーティング・システムのメトリックを収集し、後で分析するためにリポジトリに格納して、Oracleサポートの支援を受けながら、Oracle ClusterwareおよびOracle RACの多くの問題の原因を判断します。また、ノードでのメモリーのオーバーコミットメントを検出するためのメトリックを提供することによって、Oracle Databaseにおけるサービスのクオリティ管理(Oracle Database QoS Management)とあわせて使用することもできます。この情報により、Oracle Database QoS Managementは、負荷を軽減し、既存のワークロードを保持するためのアクションを実行できます。

関連項目:
Oracle Clusterware環境の管理の概要およびクラスタ状態モニター(CHM)の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

13 計画外の停止からのリカバリ

この章では、計画外の各停止タイプを許容するか管理することで停止時間を最小化できるOracle運用ベスト・プラクティスについて説明します。

この章には、次の項目が含まれます。

- 計画外の停止の概要

- 計画外の停止からのリカバリ

- フォルト・トレランスのリストア

関連項目:
計画済の停止の詳細は、第14章「計画メンテナンスの停止時間の短縮」を参照してください。

13.1 計画外の停止の概要

この項では、プライマリまたはセカンダリ・サイト・コンポーネントに影響する計画外の停止について説明し、推奨される修復方法または各停止に関連する停止時間を最小化するために推奨される方法について説明します。

計画外の停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャのいずれかの部分に予期しない障害が発生することを示します。これには、次のコンポーネントが含まれます。

- ハードウェア

- ソフトウェア

- ネットワーク・インフラストラクチャ

- ネーミング・サービス・インフラストラクチャ

- データベース

監視および高可用性インフラストラクチャでは、迅速な検出作業を行って停止時間からの回復を図る必要があります。第12章「高可用性の監視」では問題の検出について説明しましたが、この章では停止時間の短縮に重点を置きます。

13.1.1 プライマリ・サイトでの計画外の停止の管理のベスト・プラクティス

計画外の停止を解決することが、システムの最大可用性にとって不可欠です。表13-1に、最も一般的なOracle高可用性アーキテクチャの比較と、プライマリ・サイトでの計画外の停止に対応するためのリカバリ手順の概要を示します。複数のリカバリ手順を必要とする停止については、この表に、13.2項「計画外の停止からのリカバリ」の詳細な説明へのリンクが含まれます。

表13-1 プライマリ・サイトでの計画外の停止のリカバリ時間および手順

停止範囲

Oracle Database 11g

Oracle RACおよびOracle Clusterwareを使用したOracle Database 11g

Data Guardを使用したOracle Database 11g脚注1

Oracle Database 11g MAA

サイト障害

数時間から数日

1. サイトをリストアします。

2. テープ・バックアップからリストアします。

3. データベースをリカバリします。

数時間から数日

1. サイトをリストアします。

2. テープ・バックアップからリストアします。

3. データベースをリカバリします。

数秒から5分脚注2

1. 13.2.2項「スタンバイ・データベースでのデータベース・フェイルオーバー」

2. 13.2.1項「サイト・フェイルオーバーの完了(セカンダリ・サイトへのフェイルオーバー)」

3. 13.2.4項「アプリケーション・フェイルオーバー」

数秒から5分脚注2

1. 13.2.2項「スタンバイ・データベースでのデータベース・フェイルオーバー」

2. 13.2.1項「サイト・フェイルオーバーの完了(セカンダリ・サイトへのフェイルオーバー)」

3. 13.2.4項「アプリケーション・フェイルオーバー」

クラスタ全体障害

適用なし

数時間から数日

1. クラスタをリストアするか、最低1つのノードをリストアします。

2. テープ・バックアップからリストアします(データの損失または破損が発生した場合のオプション)。

3. データベースをリカバリします。

適用なし

数秒から5分

1. 13.2.2項「スタンバイ・データベースでのデータベース・フェイルオーバー」

2. 13.2.4項「アプリケーション・フェイルオーバー」

コンピュータ障害(ノード)

数分から数時間脚注3

1. Oracle Restartでノードとデータベースを再起動します。『Oracle Database管理者ガイド』を参照してください。

2. ユーザーを再接続します。

停止時間なし脚注4

13.2.3項「計画外の停止からのOracle RACリカバリ(ノードまたはインスタンス障害の場合)」による自動管理

数秒から5分脚注3

1. 13.2.2項「スタンバイ・データベースでのデータベース・フェイルオーバー」

2. 13.2.4項「アプリケーション・フェイルオーバー」

停止時間なし脚注4

13.2.3項「計画外の停止からのOracle RACリカバリ(ノードまたはインスタンス障害の場合)」による自動管理

コンピュータ障害(インスタンス)

数分脚注3

1. インスタンスを再起動します。

2. ユーザーを再接続します。

停止時間なし脚注4

13.2.3項「計画外の停止からのOracle RACリカバリ(ノードまたはインスタンス障害の場合)」による自動管理

数分脚注3

1. インスタンスを再起動します。

2. ユーザーを再接続します。

または

数秒から5分脚注2

1. 13.2.2項「スタンバイ・データベースでのデータベース・フェイルオーバー」

2. 13.2.4項「アプリケーション・フェイルオーバー」

停止時間なし脚注4

13.2.3項「計画外の停止からのOracle RACリカバリ(ノードまたはインスタンス障害の場合)」による自動管理

ストレージ障害

停止時間ゼロ脚注5

13.2.5項「ディスクおよびストレージ障害後のOracle ASMリカバリ」

停止時間ゼロ脚注5

13.2.5項「ディスクおよびストレージ障害後のOracle ASMリカバリ」

停止時間ゼロ脚注5

13.2.5項「ディスクおよびストレージ障害後のOracle ASMリカバリ」

停止時間ゼロ脚注5

13.2.5項「ディスクおよびストレージ障害後のOracle ASMリカバリ」

データ破損

数分から数時間

13.2.6項「データ破損からのリカバリ」

数分から数時間

13.2.6項「データ破損からのリカバリ」

Active Data Guardでは停止時間ゼロが可能: 13.2.6.2項「Active Data Guardの使用」

数秒から5分

1. 13.2.2項「スタンバイ・データベースでのデータベース・フェイルオーバー」

2. 13.2.4項「アプリケーション・フェイルオーバー」

Active Data Guardでは停止時間ゼロが可能: 13.2.6.2項「Active Data Guardの使用」

数秒から5分

1. 13.2.2項「スタンバイ・データベースでのデータベース・フェイルオーバー」

2. 13.2.4項「アプリケーション・フェイルオーバー」

ヒューマン・エラー

30分未満脚注6

13.2.7項「人為的エラーからのリカバリ(フラッシュバックによるリカバリ)」

30分未満脚注6

13.2.7項「人為的エラーからのリカバリ(フラッシュバックによるリカバリ)」

30分未満脚注6

13.2.7項「人為的エラーからのリカバリ(フラッシュバックによるリカバリ)」

30分未満脚注6

13.2.7項「人為的エラーからのリカバリ(フラッシュバックによるリカバリ)」

停止または減速

カスタマイズ済で構成可能脚注7

13.2.4項「アプリケーション・フェイルオーバー」

カスタマイズ済で構成可能脚注7

13.2.4項「アプリケーション・フェイルオーバー」

カスタマイズ済で構成可能脚注8

13.2.4項「アプリケーション・フェイルオーバー」

カスタマイズ済で構成可能脚注8

13.2.4項「アプリケーション・フェイルオーバー」

脚注1 Data Guardの物理レプリケーションはOracleデータベースで最も一般的に使用されるデータ保護および可用性ソリューションですが、アプリケーションの制御によって実装が可能になる場合には特に、アクティブ/アクティブ論理レプリケーションが望ましい場合があります。これらの要件に対して、Oracle GoldenGateをData Guardのかわりに使用できます。物理レプリケーションと論理レプリケーションのトレードオフの詳細は、http://www.oracle.com/technetwork/database/features/availability/dataguardgoldengate-096557.htmlで「Oracle Active Data Guard and Oracle GoldenGate」のトピックを参照してください。

脚注2 このリカバリ時間は、データベースおよび既存の接続フェイルオーバーに適用されます。ネットワーク接続の変更やサイト固有の他のフェイルオーバー・アクティビティによっては、リカバリ時間全体が増加する可能性があります。

脚注3 リカバリ時間の多くは、障害の発生したシステムの再起動に要する時間です。

脚注4 データベースは継続して使用できますが、障害の発生したシステムに接続するアプリケーションの一部は一時的に影響を受けます。

脚注5ストレージ障害は、ミラー化および自動リバランス機能のあるOracle ASMを使用して防止されます。

脚注6 人為的エラーからのリカバリ時間は、主に検出時間に依存します。不適切なDMLまたはDLLトランザクションの検出に数秒を要する場合、一般的に適切なトランザクションをフラッシュバックするのに必要な時間は、数秒間のみです(適切にリハーサルされている場合)。参照整合性制約を考慮する必要があります。

脚注7 アプリケーションまたはレスポンス時間の減速を検出し、これらのSLA違反に対応するようにOracle Enterprise Managerまたはカスタマイズしたアプリケーションのハートビートを構成できます。たとえば、Enterprise Managerのビーコンを構成して、アプリケーションのレスポンス時間を監視および検出できます。さらに、特定のしきい値を超過した後で、Enterprise Managerはアラートを生成し、場合によってはデータベースを再起動できます。

脚注8 アプリケーションまたはレスポンス時間の減速を検出し、これらのSLA違反に対応するようにOracle Enterprise Managerまたはカスタマイズしたアプリケーションのハートビートを構成できます。たとえば、Enterprise Managerのビーコンを構成して、アプリケーションのレスポンス時間を監視および検出できます。一定のしきい値に到達すると、Enterprise ManagerによってOracle Data Guardの DBMS_DG.INITIATE_FS_FAILOVER PL/SQLプロシージャがコールされ、フェイルオーバーが開始されます。

関連項目:

- 「アプリケーションによるファスト・スタート・フェイルオーバーの開始」の詳細は、『Oracle Data Guard Broker』を参照してください。

- 物理レプリケーションと論理レプリケーションのトレードオフの詳細は、次の場所にある「Oracle Active Data Guard and Oracle GoldenGate」のトピックを参照してください。
http://www.oracle.com/technetwork/database/features/availability/dataguardgoldengate-096557.html

13.1.2 スタンバイ・サイトでの計画外の停止の管理のベスト・プラクティス

Data Guardの「最大可用性」(net_timeoutでの同期通信)または「最大パフォーマンス」(非同期通信)を使用している場合、スタンバイ・サイトの停止はプライマリ・データベースの可用性に影響しません。

注意:
スタンバイ・データベースでActive Data Guardオプションを使用するシステムの停止は、読取りアクティビティにスタンバイ・データベースを使用しているアプリケーションに影響することがありますが、このような停止はプライマリ・データベースの可用性には影響しません(可用性は指定したモードに基づきます)。

ただし、プライマリ・データベースがSYNCトランスポート・モードで稼働しているスタンバイ・データベースから確認応答を受信しない場合、Data Guardの「最大保護」は可用性に影響します(net_timeoutは「最大保護」に適用されません)。このため、「最大保護」を使用している場合は、各サイトに2つのSYNCスタンバイ・データベースをデプロイするというMAAベスト・プラクティスに従う必要があります。2つのスタンバイ・データベースがある場合、単一のスタンバイの停止はプライマリの可用性またはデータ損失ゼロの保護に影響しません。

システム・リソースが制限されているため2つのスタンバイ・データベースをデプロイすることが実際的でない場合は、単純にデータ保護モードを「最大可用性」にダウングレードし、プライマリ・データベースを再起動することで、プライマリ・データベースの可用性をリストアできます。

表13-2に、セカンダリ・サイトでのスタンバイ・データベースの計画外の停止に対応するためのリカバリ手順をまとめます。複数のリカバリ手順を必要とする停止については、この表に、13.2項「計画外の停止からのリカバリ」の詳細な説明へのリンクが含まれます。

表13-2 セカンダリ・サイトでの計画外の停止のリカバリ手順

停止タイプ

単一インスタンスのスタンバイ・データベースまたはOracle RACスタンバイ・データベースのリカバリ手順

コンピュータ障害(インスタンス)

1. 使用可能になったら、ノードとスタンバイ・インスタンスを再起動します。

2. リカバリを再開します。

ブローカにより、ログ適用サービスが自動的に再起動されます。

注意1: スタンバイ・データベースが1つのみあり、「最大保護」が構成されている場合は、プライマリ・データベースを停止して、スタンバイ・データベースとのデータの相違(保護されていないデータ)がないようにします。

注意2: Oracle RACスタンバイ・データベースの場合、使用可能なスタンバイ・インスタンスへの接続時フェイルオーバーを実行するようプライマリ・データベースのOracle Net記述子が構成されている場合、プライマリ・データベースの可用性に対する影響はありません。ブローカを使用している場合、自動的に接続時フェイルオーバーが構成されます。

データ破損

13.3.5項「スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア」

RESETLOGSによるプライマリ・データベースのオープン(フラッシュバック・データベース操作またはポイント・イン・タイム・メディア・リカバリのため)

13.3.6項「RESETLOGSによるプライマリ・データベースのオープン後のフォルト・トレランスのリストア」

関連項目:

- 9.1項「Oracle Data Guard構成のベスト・プラクティス」

- 「Data Guardの保護モード」の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- Oracle Active Data Guardオプションの詳細と、フィジカル・スタンバイ・データベースが開いているときにREDO適用をいつアクティブにできるかについては、『Oracle Data Guard概要および管理』を参照してください。

- 「保護モードによるブローカ操作への影響」の詳細は、『Oracle Data Guard Broker』を参照してください。

13.2 計画外の停止からのリカバリ

この項では、様々なタイプの計画外の停止からリカバリするためのベスト・プラクティスについて説明します。

- サイト・フェイルオーバーの完了(セカンダリ・サイトへのフェイルオーバー)

- スタンバイ・データベースでのデータベース・フェイルオーバー

- 計画外の停止からのOracle RACリカバリ(ノードまたはインスタンス障害の場合)

- アプリケーション・フェイルオーバー

- ディスクおよびストレージ障害後のOracle ASMリカバリ

- データの破損からのリカバリ

- 人為的エラーからのリカバリ(フラッシュバックによるリカバリ)

- 分散環境でのデータベースのリカバリ

13.2.1 サイト・フェイルオーバーの完了(セカンダリ・サイトへのフェイルオーバー)

完全サイト・フェイルオーバーでは、本番環境の負荷に対応するよう準備されたセカンダリ・サイトにデータベース、中間層アプリケーション・サーバーおよびすべてのユーザー接続をフェイルオーバーします。

13.2.1.1 完全サイト・フェイルオーバーを使用する時期

スタンバイ・サイトが前提条件を満たしている場合、次の状況では完全サイト・フェイルオーバーをお薦めします。

- プライマリ・サイトの障害(自然災害や悪意のある攻撃など)

- プライマリ・ネットワークの接続障害

- プライマリ・サイトの電源障害

13.2.1.2 完全サイト・フェイルオーバーのベスト・プラクティス

サイト・フェイルオーバーを数分以内に迅速に完了するには、次のことを行います。

- 9.3項「一般的なData Guard構成のベスト・プラクティス」で説明した、Data Guard構成ベスト・プラクティスを使用します。

- リカバリ時間目標(RTO)が30秒未満の環境では、Data Guardファスト・スタート・フェイルオーバーを使用してスタンバイ・データベースに自動的にフェイルオーバーします(9.4.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」参照)。

- セカンダリ・サイトで稼働している中間層アプリケーション・サーバーを維持して起動時間を不要にするか、高速接続フェイルオーバーのベスト・プラクティスを使用して既存のアプリケーションを新しいプライマリ・データベースにリダイレクトします。その説明は次を参照してください。

- 第11章「高速接続フェイルオーバーの構成」

- 次の場所にあるOracleデータベースのMAAベスト・プラクティスの領域のMAAホワイト・ペーパー『Client Failover Best Practices for Data Guard 11g Release 2』
http://www.oracle.com/goto/maa

- 自動ドメイン・ネーム・サーバー(DNS)フェイルオーバー手順を構成します。プライマリ・サイトがアクセス不能になった後で自動DNSフェイルオーバーが行われ、セカンダリ・サイトのワイドエリア・トラフィック・マネージャがセカンダリ・サイトのロード・バランサの仮想IPアドレスを返し、後続の再接続でクライアントが自動的に方向付けされます。

データ損失の可能性は、使用しているData Guard保護モード(「最大保護」、「最大可用性」または「最大パフォーマンス」)によって決まります。

13.2.1.3 修復ソリューション

プライマリ・サイトとセカンダリ・サイトのWANトラフィック・マネージャにより、サイト・フェイルオーバー機能が提供されます。WANトラフィック・マネージャは、プライマリ・サイト(またはプライマリ・サイトの特定のアプリケーション)がアクセス不可能になった場合に、自動的にトラフィックをリダイレクトします。スイッチオーバーの際には、この操作を手動で起動してセカンダリ・サイトに切り替えることも可能です。トラフィックは、停止またはスイッチオーバーによりプライマリ・サイトでサービスを提供できなくなった場合にのみ、セカンダリ・サイトに転送されます。プライマリ・サイトが停止すると、ユーザー・トラフィックはセカンダリ・サイトに自動的に転送されます。

図13-1は、サイト・フェイルオーバー前の可能なネットワーク・ルートを示しています。

1. クライアント・リクエストは、プライマリ・サイトのクライアント層に入り、WANトラフィック・マネージャによって転送されます。

2. クライアント・リクエストは、ファイアウォールを介して非武装地帯(DMZ)からアプリケーション・サーバー層に送信されます。

3. リクエストは、アクティブなロード・バランサを介してアプリケーション・サーバーに転送されます。

4. リクエストは、別のファイアウォールを介してデータベース・サーバー層に送信されます。

5. アプリケーション・リクエストは、必要に応じてOracle RACインスタンスにルーティングされます。

6. レスポンスは、同様の経路でアプリケーションとクライアントに戻されます。

図13-1 サイト・フェイルオーバー前のネットワーク・ルート

図13-2は、サイト・フェイルオーバー後のネットワーク・ルートを示しています。クライアントまたはアプリケーション・リクエストは、セカンダリ・サイトのクライアント層に入り、プライマリ・サイトと同じ経路をたどります。

図13-2 サイト・フェイルオーバー後のネットワーク・ルート

次の手順では、フェイルオーバーまたはスイッチオーバーのネットワーク・トラフィックに対する影響について説明します。

1. 管理者は、プライマリ・データベースをセカンダリ・サイトにフェイルオーバーまたはスイッチオーバーします。この操作は、Data Guardファスト・スタート・フェイルオーバーを使用している場合は自動的に処理されます。

2. 管理者は、セカンダリ・サイトの中間層アプリケーション・サーバーを起動します(実行されていない場合)。

3. セカンダリ・サイトのワイドエリア・トラフィック・マネージャの選択は、サイト全体の障害に対して自動的に行うことができます。セカンダリ・サイトのワイドエリア・トラフィック・マネージャがセカンダリ・サイトのロード・バランサの仮想IPアドレスを返し、後続の再接続でクライアントが自動的に方向付けされます。このシナリオでは、サイト・フェイルオーバーは自動ドメイン・ネーム・システム(DNS)フェイルオーバーによって実行されます。
別の方法として、DNS管理者は、WANトラフィック・マネージャの選択をサイト全体または特定のアプリケーションに対応するセカンダリ・サイトに手動で変更できます。次に、手動DNSフェイルオーバーの例を示します。

1. セカンダリ・サイトのロード・バランサを参照するようDNSを変更します。
マスター(プライマリ)DNSサーバーは、新規ゾーン情報で更新され、この変更はDNS NOTIFYアナウンスで広く通知されます。

スレーブDNSサーバーは、DNS NOTIFY通知によりゾーンの更新を認識し、ゾーン情報を取得します。

注意:
マスター・サーバーとスレーブ・サーバーは、権威ネーム・サーバーです。したがって、これらのサーバーには信頼できるDNS情報が含まれます。

2. キャッシュDNSサーバーから関連するレコードを消去します。
キャッシュDNSサーバーは、主にパフォーマンスとレスポンス速度を向上するために使用します。キャッシュ・サーバーは、ホスト問合せに応答して権威DNSサーバーから情報を取得し、そのデータをローカルに保存(キャッシュ)します。同じデータに対する2回目のリクエストや後続のリクエストがあると、キャッシュDNSサーバーは、レスポンスのTTL値が期限切れになるまでローカルに保存したデータ(キャッシュ)を使用して応答します。期限切れになると、ゾーン・マスターからのデータはリフレッシュされます。DNSレコードがプライマリDNSサーバーで変更される場合、キャッシュDNSサーバーは、TTLが期限切れになるまでキャッシュされたレコードの変更を取得しません。キャッシュをフラッシュすることでキャッシュDNSサーバーを強制的に権威DNSサーバーに再接続し、更新されたDNS情報を取得します。

キャッシュのフラッシュは、使用中のDNSサーバーがフラッシュ機能をサポートしている場合に実行します。一般的なDNS BINDバージョンのフラッシュ機能は、次のとおりです。

BIND 9.3.0: コマンドrndc flushname nameにより、キャッシュから個々のエントリをフラッシュします。

BIND 9.2.0および9.2.1: コマンドrndc flushにより、キャッシュ全体をフラッシュできます。

BIND 8およびBIND 9(9.1.3以下): ネーム・サーバーを再起動してキャッシュを消去します。

3. ローカルDNSサービス・キャッシュをリフレッシュします。
一部のオペレーティング・システムでは、DNS情報がローカル・ネーム・サービス・キャッシュにローカルにキャッシュされることがあります。その場合、DNSの更新が迅速に認識されるように、このキャッシュも消去する必要があります。

Solaris: nscd

Linux: /etc/init.d/nscd restart

Microsoft Windows: ipconfig /flushdns

Apple Mac OS X: lookupd -flushcache

4. セカンダリ・サイトのロード・バランサで、セカンダリ・サイトの中間層アプリケーション・サーバーにトラフィックを転送します。

5. セカンダリ・サイトでクライアント・リクエストを処理する準備が整いました。

フェイルオーバーは、クライアントのWebブラウザにも依存します。ほとんどのブラウザ・アプリケーションでは、一定期間DNSエントリがキャッシュされます。したがって、停止の発生時に進行中だったセッションは、キャッシュ・タイムアウトの期限切れまでフェイルオーバーされない可能性があります。このようなクライアントでサービスを再開するには、ブラウザを一度終了して再起動します。

13.2.2 スタンバイ・データベースでのデータベース・フェイルオーバー

フェイルオーバーは、1つのスタンバイ・データベースをプライマリ・データベースのロールに移行する操作です。フェイルオーバー操作は、プライマリ・データベースに計画外の障害が発生し、一定の時間内にそのデータベースをリカバリできない場合に起動します。

Oracle Data Guardでは、ブローカと、ファスト・スタート・フェイルオーバーを使用して、フェイルオーバー・プロセスを自動化することができます。手動でフェイルオーバーを実行することもできます。

- ファスト・スタート・フェイルオーバーでは、手動操作を必要とするプロセスの不確実性がなく、システム停止が検出されてから数秒以内に、データ損失がゼロまたは最小限のフェイルオーバーが自動実行されます(FastStartFailoverLagLimitプロパティを使用して構成)。構成ベスト・プラクティスは、9.4.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」を参照してください。

- 手動フェイルオーバーでは、次のいずれかの方法を使用して、ユーザーの決定に基づくフェイルオーバー・プロセスが可能になります。

- Oracle Enterprise Manager

- ブローカ・コマンドライン・インタフェース(DGMGRL)

- SQL*Plus文
13.2.2.3項「手動フェイルオーバー実行のベスト・プラクティス」を参照してください。

データベース・フェイルオーバーは、アプリケーション・フェイルオーバーにより実行されますが、先にサイト・フェイルオーバーが実行される場合もあります。Data Guardフェイルオーバー後は、セカンダリ・サイトがプライマリ・データベースをホストします。元のプライマリ・データベースを新しいスタンバイ・データベースとして回復し、構成のフォルト・トレランスを復元する必要があります。13.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

通常、フェイルオーバー操作は、データをほとんど失わないか、まったく失うことなく1分未満で完了します。

関連項目:

- フェイルオーバー・プロセスの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 次の場所にあるOracleデータベースのMAAベスト・プラクティスの領域から入手できるMAAベスト・プラクティス・ホワイト・ペーパー『Data Guard Fast-Start Failover』および『Data Guard Switchover and Failover』
http://www.oracle.com/goto/maa

13.2.2.1 Data Guardフェイルオーバーを実行する時期

プライマリ・データベースの障害を、ローカル・バックアップやフラッシュバック・テクノロジを使用してリカバリ時間目標(RTO)内に修復できない場合、Oracle Data Guardを使用してフェイルオーバーを実行する必要があります。

手動フェイルオーバーは、次のような計画外の停止が発生した場合に実行します。

- プライマリ・データベースが使用不可能となるサイト障害

- 一定の時間内に修復できないユーザー・エラーによる障害

- 本番アプリケーションに影響を及ぼすデータ障害

フェイルオーバーでは、以前のプライマリ・データベースをスタンバイ・データベースとして復元し、現在の環境にフォルト・トレランスを回復する必要があります。元のプライマリ・データベースが損傷していない場合、フラッシュバック・データベースを使用して、スタンバイ・データベースを短時間で回復することができます。13.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

13.2.2.2 ファスト・スタート・フェイルオーバーを実装するためのベスト・プラクティス

ファスト・スタート・フェイルオーバーは、完全自動のため、ユーザーの操作を必要としません。

ファスト・スタート・フェイルオーバーの実行時に考慮する必要のある操作上のベスト・プラクティスはありません。ただし、9.4.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」に記載されているすべての構成上のベスト・プラクティスを検討することは重要です。

関連項目:
次の場所にあるOracleデータベースのMAAベスト・プラクティスの領域のMAAホワイト・ペーパー『Data Guard Switchover and Failover Best Practices』
http://www.oracle.com/goto/maa

13.2.2.3 手動フェイルオーバー実行のベスト・プラクティス

手動フェイルオーバーを実行する場合は、次のようにします。

- 9.4.2.4項「手動フェイルオーバーのベスト・プラクティス」で説明されている構成ベスト・プラクティスに従います。

- 次の方法から選択します。

- Oracle Enterprise Manager
Oracle Enterprise Managerを使用して手動フェイルオーバーを実行する方法の詳細は、『Oracle Data Guard Broker』を参照してください。手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方で同じです。

- Oracle Data Guardブローカ・コマンドライン・インタフェース(DGMGRL)
Oracle Enterprise Managerを使用して手動フェイルオーバーを実行する方法の詳細は、『Oracle Data Guard Broker』を参照してください。手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方で同じです。

- SQL*Plus文

- フィジカル・スタンバイ・データベースへのフェイルオーバーを実行するためのフィジカル・スタンバイ・データベースでの手順の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- ロジカル・スタンバイ・データベースへのフェイルオーバーを実行するためのロジカル・スタンバイ・データベースでの手順の詳細は、『Oracle Data Guard概要および管理』を参照してください。

13.2.3 計画外の停止からのOracle RACリカバリ(ノードまたはインスタンス障害の場合)

ノードまたはインスタンスの障害が発生すると、Oracle RACリカバリが自動的に実行されます。通常の複数インスタンスOracle RAC環境では、正常なインスタンスが障害インスタンスを自動的にリカバリし、自動クライアント・フェイルオーバーで支援する可能性があります。リカバリ時間は、データベースとOracle RAC構成のベスト・プラクティスを採用することで制限でき、通常は、データ損失なしで、非常に大規模なビジー・システムのインスタンス・リカバリ時間を数秒から数分にすることができます。Oracle RAC One Node構成では、リカバリ時間はOracle RAC全体よりも長くなると予想されます。Oracle RAC One Nodeでは、インスタンス・リカバリを実行する前に置換インスタンスを起動する必要があります。

Oracle RACおよびOracle RAC One Nodeでのインスタンスまたはノードの障害の場合は、次のリカバリ方法を使用します。

- 障害インスタンスの自動インスタンス・リカバリ

- 自動サービス再配置

- Oracle Cluster Registryのリカバリ

13.2.3.1 障害インスタンスの自動インスタンス・リカバリ

ソフトウェアまたはハードウェアの問題によりインスタンスが停止または中止されると、インスタンス障害が発生します。インスタンス障害の発生後、Oracleでは、オンラインREDOログ・ファイルを使用して自動的にデータベース・リカバリを実行します。

Oracle RAC環境のインスタンス・リカバリでは、障害インスタンスの再起動や、障害インスタンスで稼働していたアプリケーションのリカバリは行われません。アプリケーションはサービス再配置と高速アプリケーション通知を使用して継続して実行できます(13.2.3.2項「自動サービス再配置」を参照してください)。

いずれかのインスタンスが別のインスタンスに対してリカバリを実行する場合、リカバリする側のインスタンスは次の操作を実行します。

- 障害インスタンスによって生成されたREDOログ・エントリを読み取り、その情報を使用してコミット済トランザクションがデータベースに記録されていることを確認します。したがって、コミット済トランザクションのデータは失われません。

- 障害発生時にアクティブであったコミットされていないトランザクションをロールバックし、それらのトランザクションに使用されていたリソースを解放します。

複数のインスタンスに障害が発生した場合、障害を受けなかったインスタンスが1つでもあれば、Oracle RACは、障害が発生したすべてのインスタンスに対してインスタンス・リカバリを実行します。Oracle RACデータベースのすべてのインスタンスに障害が発生した場合、いずれかのインスタンスを再起動した時点でクラッシュ・リカバリが開始され、コミット済トランザクションはすべてリカバリされます。Data Guardは、クラスタのすべてのインスタンスに障害が発生した場合に停止を防ぐための推奨ソリューションです。

13.2.3.2 自動サービス再配置

サービスの信頼性を確保するには、正常なインスタンスを構成してその中でフェイルオーバーを実行します。必要なサービスを複数のデータベース・インスタンスで提供することにより、サービスが使用可能になります。ハードウェア障害が発生し、障害Oracle RACデータベース・インスタンスに悪影響を及ぼす場合、構成に応じて、Oracle Clusterwareは次のいずれかを行います。

- Oracle Clusterwareは、DBCAまたはEnterprise Managerでの構成どおりに、障害のあるデータベース・インスタンス上のサービスを別の使用可能なインスタンスに自動的に移動します。Oracle Clusterwareは、障害がサービスに影響を与えるタイミングを認識して、サービスをサポートする稼働中のインスタンス全体にサービスを自動的にフェイルオーバーします。

注意:
Oracle RAC One Nodeでは、別のノードの別のインスタンスが起動し、適切なサービスに対して使用可能になると、再配置が行われます。このため、Oracle RAC One Nodeはインスタンスの障害時に新しいインスタンスを起動しますが、新しいインスタンスは「稼働を続けているインスタンス」ではありません。

- デフォルトでは、サービスを複数のインスタンスで使用可能にできます。この場合、複数のインスタンスのいずれかが失われると、クライアントは稼働を続けているインスタンス全体で使用可能なサービスの使用を継続しますが、作業に使用できるリソースは減ります。

同時に、Oracle Clusterwareは障害インスタンスを再起動して依存リソースをシステムに再統合するように試み、Cluster Ready Services (CRS)はデータベース・インスタンスの再起動を3回試みます。クライアントは、ノード障害イベントを"サブスクライブ"して、インスタンスの問題の通知を迅速に受け、新しい接続を設定できます(Oracle Clusterwareは新しい接続を設定せず、クライアントが新しい接続を設定します)。高速アプリケーション通知(FAN)イベントを使用した障害の通知は、Oracleサーバー・アーキテクチャ内の様々なレベルで起動できます。レスポンスには、Oracle Notification Service(ONS)、アドバンスト・キューイングまたはFANコールアウトを通じた外部パーティへの通知に加え、追跡用の障害記録、イベント・ロギング、およびアプリケーションへの割込みを含めることが可能です。障害ノードのサービスが停止すると、稼働を続けるノードから通知が発生します。サービスを提供するノードの場所と数は、アプリケーションに対して透過的です。ノードの停止またはクラスタの再起動後の再起動とリカバリは、自動的に行われます。

13.2.3.3 Oracle Cluster Registryのリカバリ

Oracle Cluster Registry(OCR)ファイルが失われると、Oracle RACおよびOracleクラスタウェアの可用性が影響を受けます。OCRファイルは、自動で作成されるバックアップからリストアするか、ocrconfigツールを使用して手動で作成されるエクスポート・ファイルからリストアすることが可能です(ocrconfigはバックアップのリストアにも使用します)。また、OracleはオプションでOCRをミラーリングして、単一のOCRデバイスの障害に対応します。OCRミラーは、必ず物理的に別々のデバイス、できれば別々のコントローラ上に置きます。詳細は、6.2.7項「Oracle Cluster Registry (OCR)のミラーリングとOracle ASMでの複数の投票ディスクの構成」を参照してください。

すべての投票ディスクが破損している場合は、それらをリストアする必要があります。これを行うには、crsctlコマンドを使用します。使用する手順は、投票ファイルを格納する場所によって決まります。投票ディスクがOracle ASMに格納されている場合は、crsctl replace votediskコマンドを実行して、指定するOracle ASMディスク・グループに投票ディスクを移行します。投票ディスクをOracle ASMに格納しなかった場合は、crsctl delete css votediskコマンドを実行して投票ディスクを削除し、crsctl add css votediskコマンドを実行して追加します。

関連項目:

- 6.3.2項「テープまたはオフサイトへのOCRの定期的なバックアップ」

- Real Application Clustersの記憶域の管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- Oracle Cluster Registryのリストアの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- 投票ディスクのリストアの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

13.2.4 アプリケーション・フェイルオーバー

最小限の構成で、アプリケーションは、サービスを提供しているインスタンスが使用不可能になったときに通知を迅速かつ効率的に受信できます。通知が発生すると、稼働を続けるOracle RACデータベースのインスタンス、またはフェイルオーバー後にプライマリ・ロールを引き受けるはずのスタンバイ・データベースへのアプリケーションの再接続が透過的に発生します。

Oracle RAC構成では、迅速で透過的なアプリケーション・フェイルオーバーを実現するためにサービスは不可欠です。クライアントは、高速アプリケーション通知(FAN)を介してサービス再配置を通知されます。

Oracle Data Guard構成では、複数サイトにわたるクライアント・フェイルオーバーを行うようにサービスを構成することができます。Data Guard構成では、サイト障害の発生後、新規プライマリ・データベースで自動的に本番サービスが公開され、障害の発生したプライマリ・データベースでサービスが中断したことがFANイベントを通じて関連するクライアントに通知されます。

ハングしたか、またはレスポンス時間が許容できないほどかかる状況では、アプリケーションまたはレスポンス時間の速度低下を検出し、その状況に対応するように、Oracle Enterprise Managerまたはカスタム・アプリケーション・ハートビートを構成することができます。たとえば、Enterprise Managerビーコンを構成して、アプリケーションのレスポンス時間を監視、検出することができます。特定の時間しきい値が期限切れになると、Enterprise ManagerがOracle Data Guard DBMS_DG.INITIATE_FS_FAILOVER PL/SQLプロシージャをコールしてデータベース・フェイルオーバーを即座に開始し、続いて、FAN通知とサービス再配置を使用してアプリケーション・フェイルオーバーを行うことができます。

FAN通知とサービス再配置を使用すると、Oracle RACまたはOracle Data Guardのフェイルオーバーを引き起こすあらゆる障害または計画済のメンテナンスが発生した場合に、自動の高速リダイレクションが可能になります。

関連項目:

- 第11章「高速接続フェイルオーバーの構成」

- 次の場所にあるOracleデータベースのMAAベスト・プラクティスの領域のMAAホワイト・ペーパー『Client Failover for Highly Available Oracle Databases』
http://www.oracle.com/goto/maa

- アプリケーションによるファスト・スタート・フェイルオーバーの開始とDBMS_DG.INITIATE_FS_FAILOVER PL/SQLプロシージャの詳細は、『Oracle Data Guard Broker』を参照してください。

13.2.5 ディスクおよびストレージ障害後のOracle ASMリカバリ

表13-3に、様々なOracle ASM障害タイプの影響と推奨される修復方法をまとめます。

表13-3 Oracle ASM障害タイプと推奨される修復方法

障害

説明

影響

推奨される修復方法

Oracle ASMインスタンス障害

Oracle ASMインスタンスの障害

同じノードからOracle ASM記憶域にアクセスするすべてのデータベース・インスタンスが停止します。

自動(13.2.3項「計画外の停止からのOracle RACリカバリ(ノードまたはインスタンス障害の場合)」)

Oracle RACを使用していない場合、Data Guardフェイルオーバーを使用します(13.2.2.2項「ファスト・スタート・フェイルオーバーを実装するためのベスト・プラクティス」を参照)。

Oracle RACとData Guardを使用していない場合、基礎となる問題を修正してからOracle ASMとデータベース・インスタンスを再起動します。

Oracle ASMディスク障害

1つ以上のOracle ASMディスクに障害が発生しますが、すべてのディスク・グループはオンラインのままです。

引き続きすべてのデータにアクセスできます。この状況は、標準冗長性または高冗長性のディスク・グループでのみ発生します。

Oracle ASMは、残りのディスク・ドライブに自動的にリバランスし、冗長性を再確立します。冗長性をリストアするには残りのディスク・ドライブに十分な空きディスク領域が必要です。そうでないと、リバランスがORA-15041で失敗することがあります。詳細は、4.6.2項「計画済のメンテナンスに関するOracleストレージ・グリッドのベスト・プラクティス」を参照してください。注意: 外部冗長性ディスク・グループは、ストレージ・アレイでミラーリングを使用して、ディスク障害から保護する必要があります。ディスク障害はOracle ASMから隔離する必要があります。

データ領域ディスク・グループ障害

1つ以上のOracle ASMディスクに障害が発生し、データ領域ディスク・グループがオフラインになります。

データ領域ディスク・グループにアクセスするデータベースが停止します。

Data Guardフェイルオーバーまたはローカル・リカバリを実行します(13.2.5.3項「データ領域ディスク・グループ障害」を参照)。

高速リカバリ領域ディスク・グループ障害

1つ以上のOracle ASMディスクに障害が発生し、高速リカバリ領域ディスク・グループがオフラインになります。

高速リカバリ領域ディスク・グループにアクセスするデータベースが停止します。

ローカル・リカバリまたはData Guardフェイルオーバーを実行します(13.2.5.4項「高速リカバリ領域ディスク・グループ障害」を参照)。

13.2.5.1 Oracle ASMインスタンス障害

Oracle ASMインスタンスに障害が発生した場合、同じノードからOracle ASM記憶域にアクセスするデータベース・インスタンスが停止します。フェイルオーバー処理の説明を次のリストに示します。

- プライマリ・データベースがOracle RACデータベースの場合、アプリケーション・フェイルオーバーは自動的に発生し、データベース・インスタンスに接続しているクライアントは残っているインスタンスに再接続します。このため、サービスはクラスタ内の他のインスタンスによって提供され、処理は継続します。通常、リカバリ時間は数秒以内です。

- プライマリ・データベースがOracle RACデータベースでない場合、Oracle ASMインスタンス障害が発生するとデータベース全体が停止します。

- 構成でOracle Data Guardを使用しており、ファスト・スタート・フェイルオーバーを有効にしている場合、データベース・フェイルオーバーが自動的に起動され、クライアントはフェイルオーバーの完了後に新規プライマリ・データベースに自動的に再接続されます。リカバリ時間は、自動Data Guardファスト・スタート・フェイルオーバー操作が完了するまでの時間と同じです。ファスト・スタート・フェイルオーバーを構成していない場合、手動でOracle ASMインスタンスとデータベース・インスタンスを再起動するか、手動Data Guardフェイルオーバーを実行することによって、この停止状態からリカバリする必要があります。

- 構成にOracle RACもData Guardも含まれない場合、Oracle ASMインスタンスとデータベース・インスタンスを手動で再起動する必要があります。リカバリ時間は、これらの作業の所要時間により異なります。

13.2.5.2 Oracle ASMディスク障害

Oracle ASMディスクに障害が発生した場合、フェイルオーバー処理は次のようになります。

- 外部冗長性
Oracle ASMディスク・グループが外部冗長性タイプとして構成されている場合、単一のディスク障害は、ストレージ・アレイにより処理されるためOracle ASMインスタンスからは認識されないのが普通です。ディスク・グループを使用するOracle ASMとデータベースのすべての操作は、通常どおり機能し続けます。

ただし、外部冗長性ディスク・グループの障害がOracle ASMインスタンスによって検出された場合、Oracle ASMインスタンスはディスク・グループを即時にオフラインにするため、ディスク・グループにアクセスしているOracleインスタンスはクラッシュします。ディスク障害が一時的な場合は、Oracle ASMとデータベース・インスタンスを再起動でき、ディスク・グループがオンラインに戻った後でクラッシュ・リカバリが行われます。

- 標準冗長性または高冗長性
Oracle ASMディスク・グループが標準または高冗長性タイプとして構成されている場合、ディスク障害はOracle ASMにより透過的に処理され、ディスク・グループにアクセスしているデータベースは影響を受けません。

Oracle ASMインスタンスは、自動的にOracle ASMリバランス操作を開始し、1つ以上の障害ディスクのデータをOracle ASMディスク・グループの他の正常なディスクに分散します。リバランス操作の進行中に、まだ再ミラー化されていないデータを含むディスクに別のディスク障害が発生すると、ディスク・グループの可用性に影響を与える可能性があります。リバランス操作が正常に完了すると、後続の障害が発生してもOracle ASMディスク・グループは影響を受けません。複数のディスク障害も、それらの障害が正常な冗長性のOracle ASMディスク・グループのただ1つの障害グループに影響を与えるかぎり、同じように処理されます。

複数の障害グループの複数のディスクで、プライマリ・エクステントとそのすべてのミラーが失われる障害が発生した場合、ディスク・グループはオフラインになります。

Oracle ASMディスクに障害が発生した場合は、次のリカバリ方法を使用します。

- Enterprise Managerを使用したOracle ASMディスク障害の修復

- SQLを使用したディスク・グループへの置換ディスクの追加

13.2.5.2.1 Enterprise Managerを使用したOracle ASMディスク障害の修復

図13-3は、ディスク障害をレポートするEnterprise Managerを示しています。14個のアラートのうち5つを示しています。示されている5つのアラートは、Disk RECO2のオフライン・メッセージです。

図13-3 Enterprise Managerによるディスク障害のレポート

図13-4は、データ領域ディスク・グループDATA、Data Guardディスク・グループDBFS_DGおよびリカバリ領域ディスク・グループRECOのステータスをレポートするEnterprise Managerを示しています。

図13-4 Enterprise ManagerによるOracle ASMディスク・グループ・ステータスのレポート

図13-5は、DATAディスク・グループに対する保留中のREBAL操作をレポートするEnterprise Managerを示しています。この操作は、「%完了」に示されているとおりほぼ完了しており、「残り時間」は0分と推定されています。

図13-5 Enterprise Managerによる保留中のREBAL操作のレポート

13.2.5.2.2 SQLを使用したディスク・グループへの置換ディスクの追加

1つの特定の障害グループの1つ以上の障害ディスクが削除された後、新しいディスクで置換する必要がある場合に、これらの手順を実行します。

1. 次のSQLコマンドを使用して、障害ディスク・グループに1つ以上の置換ディスクを追加します。

ALTER DISKGROUP disk_group
ADD FAILGROUP failure_group
DISK 'disk1','disk2',...;

2. 次のコマンドで操作の進行状況をチェックします。

SELECT * FROM V$ASM_OPERATION;

13.2.5.3 データ領域ディスク・グループ障害

データ領域ディスク・グループ障害は、複数の障害が存在する場合にのみ発生するのが普通です。たとえば、データ領域ディスク・グループが外部冗長性として定義されている場合、単一のディスク障害はOracle ASMから隔離されている必要があります。ただし、ストレージ・アレイの複数のディスク障害は、Oracle ASMで認識される可能性があり、その場合ディスク・グループはオフラインになります。同様に、標準または高冗長性ディスク・グループの異なる障害グループに複数のディスク障害が発生した場合も、ディスク・グループはオフラインになる可能性があります。

標準または高冗長性ディスク・グループで1つ以上のディスク障害が発生し、Oracle ASMディスク・グループにアクセス可能な場合、データは失われず、即座にアクセスできなくなることもありません。Oracle ASMインスタンスは、自動的にOracle ASMリバランス操作を開始し、1つ以上の障害ディスクのデータをOracle ASMディスク・グループの他の正常なディスクに分散します。リバランス操作が正常に完了すると、2番目の障害が発生してもOracle ASMディスク・グループは影響を受けません。リバランス操作を正常に完了するには、ディスク・グループ内の残りのディスクに十分な空きディスク領域が存在する必要があります。

表13-4に、データ領域のディスク・グループ障害からリカバリするために可能な解決方法をまとめます。

表13-4 データ領域ディスク・グループ障害のリカバリ・オプション

リカバリ・オプション

リカバリ時間目標(RTO)

リカバリ・ポイント目標(RPO)

Data Guardフェイルオーバー(13.2.5.4項「高速リカバリ領域ディスク・グループ障害」を参照)。

5分以下

選択されているデータ保護レベルに応じて変動

ローカル・リカバリ(「ローカル・リカバリの手順」を参照)

データベースのリストア時間とリカバリ時間

0(ゼロ)

Data Guardを使用しており、ファスト・スタート・フェイルオーバーを構成している場合、データ領域ディスク・グループがオフラインとなってデータベースが停止した時点で自動フェイルオーバーが起動されます。ファスト・スタート・フェイルオーバーを構成していない場合は、手動フェイルオーバーを実行します。

Data Guardフェイルオーバーを実行する場合、リカバリ時間目標(RTO)は、Data Guardオブザーバ・プロセスとファスト・スタート・フェイルオーバーの稼働状況に応じて数分から数秒となります。ただし、手動フェイルオーバーを実行する場合は、スタンバイ・サイトにすべてのデータが用意されていないとデータ損失が発生する可能性があります。

Data Guardフェイルオーバーが完了し、アプリケーションが使用可能になったら、データ領域ディスク・グループ障害を解決する必要があります。引き続き、後続の「ローカル・リカバリの手順」を参照してOracle ASMディスク・グループ障害を解決します。

ローカル・リカバリのみのRTOは、次の操作時間に基づきます。

1. 障害ストレージ・コンポーネントを修復および置換する時間

2. データベースをリストアおよびリカバリする時間

損失の影響はデータ領域ディスク・グループに限定されるため、データ損失は発生しません。すべてのトランザクションは高速リカバリ領域に存在するOracle REDOログ・メンバーに記録されるため、完全なメディア・リカバリが可能です。

Data Guardを使用していない場合、次のローカル・リカバリの手順を実行します。ローカル・リカバリの実行に要する時間は、データベースをリストアおよびリカバリする時間に応じて変化します。ローカル・リカバリの実行によるデータ損失はありません。

ローカル・リカバリの手順

1つ以上の障害ディスクを置換し、ストレージへのアクセスが回復したら、次の手順を実行します。

注意:
新規プライマリ・データベースに対してOracle Data Guardフェイルオーバーを実行した場合、次の手順を使用してリストアし、Data Guard設定と同期できます。13.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」も参照してください。

1. Oracle ASMインスタンスで次のSQL*Plus文を発行することで、新しい記憶域の場所を使用してOracle ASMディスク・グループを再構築します。

SQL> CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK 'path1','path2',...force;

2. 次のRMANコマンドを発行して、データベース・インスタンスNOMOUNTを起動します。

RMAN> STARTUP FORCE NOMOUNT;

3. リカバリ領域に残っているコピーから制御ファイルをリストアします。

RMAN> RESTORE CONTROLFILE FROM 'recovery_area_controlfile';

4. データベース・インスタンスMOUNTを起動します。

RMAN> STARTUP FORCE MOUNT;

5. データベースをリストアします。

RMAN> RESTORE DATABASE

6. データベースをリカバリします。

RMAN> RECOVER DATABASE;

7. ブロック変更トラッキングを使用している場合、次のSQL*Plus文を使用して、ブロック変更トラッキング・ファイルを一度無効化してから再有効化します。

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

8. データベースをオープンします。

SQL> ALTER DATABASE OPEN;

9. 障害Oracle ASMディスク・グループにログ・ファイル・メンバーを再作成します。

SQL> ALTER DATABASE DROP LOGFILE MEMBER 'filename';
SQL> ALTER DATABASE ADD LOGFILE MEMBER 'disk_group' TO GROUP group_no;

10. 次のRMANコマンドを使用して、増分レベル0のバックアップを実行します。

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

13.2.5.4 高速リカバリ領域ディスク・グループ障害

通常、制御ファイル・メンバーは高速リカバリ領域に存在し、Oracleではすべての制御ファイル・メンバーにアクセスできる必要があるため、高速リカバリ領域ディスク・グループに障害が発生すると、データベースはクラッシュします。高速リカバリ領域には、フラッシュバック・ログ、REDOログ・メンバーおよびすべてのバックアップ・ファイルが含まれることがあります。

この障害は高速リカバリ領域ディスク・グループのみに影響を与えるため、データの損失はありません。データファイルとオンラインREDOログ・ファイルは引き続き存在し、データ領域で使用できるため、データベースのメディア・リカバリは必要ありません。

高速リカバリ領域ディスク・グループ障害は、複数の障害が存在する場合にのみ発生するのが普通です。たとえば、高速リカバリ領域ディスク・グループが外部冗長性として定義されている場合、単一のディスク障害はOracle ASMから隔離されている必要があります。ただし、ストレージ・アレイの複数のディスク障害は、Oracle ASMに影響し、ディスク・グループがオフラインになる原因となることがあります。同様に、標準または高冗長性ディスク・グループの異なる障害グループに複数のディスク障害が発生した場合も、ディスク・グループはオフラインになる可能性があります。

表13-5に、高速リカバリ領域ディスク・グループ障害が発生した場合に使用可能な解決方法をまとめます。

表13-5 高速リカバリ領域ディスク・グループ障害のリカバリ・オプション

リカバリ・オプション

リカバリ時間目標(RTO)

リカバリ・ポイント目標(RPO)

ローカル・リカバリ(13.2.5.4.1項「高速リカバリ領域ディスク・グループ障害のローカル・リカバリ」を参照)。

5分以下

0(ゼロ)

Data Guardフェイルオーバーまたはスイッチオーバー(13.2.5.4.2項「高速リカバリ領域ディスク・グループ障害のData Guardロールの移行」を参照)。

5分以下

0(ゼロ)

13.2.5.4.1 高速リカバリ領域ディスク・グループ障害のローカル・リカバリ

ローカル・リカバリを実行することを決定した場合は、高速リカバリ領域に存在する制御ファイル・メンバーをinit.oraから削除した後で高速ローカル再起動を実行してプライマリ・データベースを起動し、アーカイブ用に高速リカバリ領域として別のディスク・グループを割り当てる必要があります。

高速ローカル再起動を行うには、プライマリ・データベースで次の手順を実行します。

1. データ領域のメンバーのみを指定するようCONTROL_FILES初期化パラメータを変更します。

ALTER SYSTEM SET CONTROL_FILES='+DATA/sales/control1.dbf' SCOPE=spfile;

2. ローカル・アーカイブの宛先と高速リカバリ領域を、冗長性を備えたスケーラブルなローカルの宛先に変更します。

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+DATA' SCOPE=spfile;

3. 新規設定でデータベースを起動します。

STARTUP MOUNT:

4. 失われたディスク・グループにあったREDOログ・メンバーを削除します。たとえば、次のコマンドを発行します。

ALTER DATABASE DROP LOGFILE MEMBER '+RECO/dbm/onlinelog/group_2.258.750768395';

5. フラッシュバック・ログの破損や損失が発生した場合、状況によってはフラッシュバック・データベースを一度無効化してから再有効化する必要があります。

ALTER DATABASE FLASHBACK OFF;
ALTER DATABASE FLASHBACK ON;
ALTER DATABASE OPEN;

ただし、この方法は、高速リカバリ領域を作成して障害ストレージ・コンポーネントを置換するまでの一時的な修復手段です。ローカル・リカバリの手順を使用することをお薦めします。詳細は、「高速リカバリ領域ディスク・グループ障害のData Guardロールの移行のローカル・リカバリ手順」を参照してください。

13.2.5.4.2 高速リカバリ領域ディスク・グループ障害のData Guardロールの移行

Data Guardロールの移行を実行する場合、リカバリ時間目標(RTO)は、Data Guardオブザーバ・プロセスとファスト・スタート・フェイルオーバーの稼働状況に応じて数秒から数分となります。

保護レベルが最大パフォーマンスの場合、またはスタンバイ・データベースがプライマリ・データベースと同期されていない場合は、次の手順を実行します。

1. 制御ファイル・メンバーを削除し、SPFILEの一時高速リカバリ領域(ファイル・システム)を参照することによって、一時的にプライマリ・データベースを起動します。

2. Data Guardスイッチオーバーを実行してデータ損失を防ぎます。

3. スイッチオーバーが完了し、アプリケーションが使用可能になったら、高速リカバリ領域ディスク・グループ障害を解決します。

4. 関連するデータベースを停止し、ローカル・リカバリの手順を使用してOracle ASMディスク・グループ障害を解決します。詳細は、「高速リカバリ領域ディスク・グループ障害のData Guardロールの移行のローカル・リカバリ手順」を参照してください。

13.2.5.4.3 高速リカバリ領域ディスク・グループ障害のData Guardロールの移行のローカル・リカバリ手順

ローカル・リカバリの手順

注意:
新規プライマリ・データベースに対してOracle Data Guardフェイルオーバーを実行した場合、この手順を使用して元のプライマリ・データベースをスタンバイ・データベースとして再導入することはできません。その理由は、データベースの再導入作業に必要なフラッシュバック・データベースのログ・ファイルが失われているためです。スタンバイ・データベースについては、完全な復元を実行する必要があります。

1. 高速リカバリ領域として使用するストレージを置換するか、ストレージへのアクセスを確立します。

2. 次のSQL*Plus文を発行することによって、記憶域の場所を使用してOracle ASMディスク・グループを再構築します。

SQL> CREATE DISKGROUP RECO NORMAL REDUNDANCY DISK 'path1','path2',...force;

3. 次のRMANコマンドを使用して、データベース・インスタンスNOMOUNTを起動します。

RMAN> STARTUP FORCE NOMOUNT;

4. データ領域に残っているコピーから制御ファイルをリストアします。

RMAN> RESTORE CONTROLFILE FROM 'data_area_controlfile';

5. データベース・インスタンスMOUNTを起動します。

RMAN> STARTUP FORCE MOUNT;

6. フラッシュバック・データベースを使用している場合、次のSQL*Plus文を使用して、その機能を無効化します。

SQL> ALTER DATABASE FLASHBACK OFF;

7. データベースをオープンし、インスタンス・リカバリを完了します。

SQL> ALTER DATABASE OPEN;

8. フラッシュバック・データベースが必要な場合にのみ、次の文を発行します。

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE FLASHBACK ON;
SQL> ALTER DATABASE OPEN;

9. 障害Oracle ASMディスク・グループにログ・ファイル・メンバーを再作成します。

SQL> ALTER DATABASE DROP LOGFILE MEMBER 'filename';
SQL> ALTER DATABASE ADD LOGFILE MEMBER 'disk_group' TO GROUP group_no;

10. 次のRMANコマンドを使用して、制御ファイルおよび高速リカバリ領域を同期します。

RMAN> CATALOG RECOVERY AREA;
RMAN> CROSSCHECK ARCHIVELOG ALL;
RMAN> CROSSCHECK BACKUPSET;
RMAN> CROSSCHECK DATAFILECOPY ALL;
RMAN> LIST EXPIRED type;
RMAN> DELETE EXPIRED type;

例では、type変数はLIST EXPIRED BACKUPとLIST EXPIRED COPYコマンド、およびDELETE EXPIRED BACKUPとDELETE EXPIRED COPYコマンドのプレースホルダです。これらのコマンドをすぐにすべて実行します。

11. データが失われたと仮定し、バックアップを実行します。

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

13.2.6 データの破損からのリカバリ

データ・ブロックは、認識されているOracleデータベース形式ではないか、または内容に内部的な一貫性がないと破損します。データ・ブロック破損は、内部のOracle制御情報やアプリケーションおよびユーザー・データにダメージを与えて、これがクリティカル・データおよびサービスの重大な損失につながる場合があります。Oracleデータベースの破損の防止、検出および修復機能は、保護対象のデータおよびトランザクションの内部知識と、包括的な高可用性ソリューションのインテリジェント統合を基に構築されています。詳細は、5.1.6項「データの破損からの保護」を参照してください。

リカバリ・プロセスは、ブロックの破損が疑われるか検出された場合に開始します(例: ORA-1578、ORA-752およびORA-600 [3020])。破損したブロックが見つかると、ほとんどのブロック破損からリカバリするための様々な手法が提供されます。

データ・ブロックのリカバリには次のような様々な手法があります。

- データ・リカバリ・アドバイザは、ほとんどの問題を診断および修復するための最も簡単な方法です。詳細は、13.2.6.1項「データ・リカバリ・アドバイザの使用」を参照してください。

- Active Data Guardは、プライマリまたはスタンバイ・データベースの破損データ・ブロックを自動的に修復できます。詳細は、13.2.6.2項「Active Data Guardの使用」を参照してください。

- RMANブロック・メディア・リカバリは、正常なバックアップからブロックを取得することで個々の破損ブロックを修復できます。詳細は、13.2.6.3項「RMANとブロック・メディア・リカバリの使用」を参照してください。

- スタンバイ・データベースへのData Guardスイッチオーバーまたはフェイルオーバー。詳細は、13.2.6.2.2項「フィジカル・スタンバイ・データベースからのデータの抽出」を参照してください。

- RMANでのデータファイル・メディア・リカバリ。詳細は、13.2.6.3項「RMANとブロック・メディア・リカバリの使用」を参照してください。

- ORA-752またはORA-600 [3020]を引き起こす書込みの欠落を検出した場合は、次の場所にあるMy Oracle Supportのノート1265884.1の『Resolving ORA-752 or ORA-600 [3020] During Standby Recovery』のガイドラインに従います。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265884.1

破損ブロックのリカバリに使用するメソッドにかかわらず、最初に破損のタイプと程度を分析してリカバリを実行する必要があります。データの破損を防止および準備するのに最適な手法を実装すると、その後発生する可能性のあるデータ損失と停止時間に対処するときの時間、労力およびストレスを軽減できます。

MAAベスト・プラクティスは、次のようなほとんどの破損や、逸脱または欠落した書込みを解決するための手順を追ったプロセスを提供します。

1. データ・リカバリ・アドバイザの使用

2. Active Data Guardの使用

3. RMANとブロック・メディア・リカバリの使用

4. Data Guardロール移行の実行

5. RMANおよびデータファイル・メディア・リカバリの使用

関連項目:

- 詳細は、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『ブロック破損の防止、検出および修復: Database 11g』を参照してください。
http://www.oracle.com/goto/maa

- 次の場所にあるMy Oracle Supportのノート1302539.1の『Best Practices for Corruption Detection, Prevention, and Automatic Repair - in a Data Guard Configuration』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1302539.1

13.2.6.1 データ・リカバリ・アドバイザの使用

データ・リカバリ・アドバイザでは、次のようなリストア操作やリカバリ手順を実行したり、フラッシュバック・データベースを使用したりできます。

- 破損ブロックを含むデータファイルのブロック・メディア・リカバリの実行

- データベースまたは選択した表領域のPoint-in-Timeリカバリの実行

- フラッシュバック・データベースを使用したデータベース全体の巻戻し

- バックアップからのデータベースの完全なリストアおよびリカバリ

データ・リカバリ・アドバイザには、コマンドラインおよびGUIの両方のインタフェースがあります。GUIインタフェースは、Oracle Enterprise Manager Database Control(サポート・ワークベンチ)で「リカバリの実行」をクリックすると使用できます。これにより、データ・リカバリ・アドバイザを使用できます。

RMANコマンドライン・インタフェースを使用したデータ・リカバリ・アドバイザのコマンドには、LIST FAILURE、ADVISE FAILURE、REPAIR FAILURE、CHANGE FAILUREなどがあります。

データ・リカバリ・アドバイザで問題が修正された場合、それ以上リカバリ方法を続行する必要はありません。ただし、アラート・ログでプライマリ・データベースとスタンバイ・データベースのORA-エラーと破損警告を定期的にチェックしてください。データベースの動作中に破損が検出されると、破損エラーがORA-600またはORA-01578としてアラート・ログに記録されます。

注意:
現在のリリースのデータ・リカバリ・アドバイザでは、単一インスタンス・データベースのみがサポートされています。Oracle RACデータベースはサポートされていません。データ・リカバリ・アドバイザでサポートされているデータベース構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

関連項目:

- 5.2.2項「データ・リカバリ・アドバイザを使用したデータ障害の検出、分析および修復」

- データ・リカバリ・アドバイザのGUIインタフェースの使用方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- データ・リカバリ・アドバイザを使用した障害の診断と修復の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

13.2.6.2 Active Data Guardの使用

スタンバイ・データベースを使用してプライマリ・データベースのブロック破損を修復するには、2つのオプションがあります。

- Oracle Active Data Guardと自動ブロック修復

- フィジカル・スタンバイ・データベースからのデータの抽出

または、破損が広範囲の場合は、プライマリ・データベースを修復する一方でスタンバイ・データベースへのフェイルオーバーまたはスイッチオーバーを選択できます。詳細は、13.2.6.4項「Data Guardロール移行の実行」を参照してください。

13.2.6.2.1 Oracle Active Data Guardと自動ブロック修復

Oracle Database 11gリリース2(11.2)から、破損ブロックの修復は、フィジカル・スタンバイ・データベースから同じブロックの状態のよいバージョンを取得することで、プライマリ・データベースによりリアルタイムで自動的に行われます。この機能を自動ブロック修復と呼びます。自動ブロック修復では、破損したデータ・ブロックを破損検出と同時に自動修復できます。自動ブロック修復では、ディスクやテープのバックアップまたはフラッシュバック・ログからブロックを取得するのとは対照的に、最新の良好なブロックをリアルタイムで使用するため、ブロック破損によりデータにアクセスできない時間とブロックのリカバリの時間が短縮されます。

このため、自動ブロック修復では、Oracle Active Data Guardスタンバイ・データベースを使用して、プライマリ・データベースにより検出されたデータ破損の自動修復が行われます。また、Active Data Guardのフィジカル・スタンバイ・データベースで破損が検出された場合、破損はプライマリの良好なブロックで自動的に修復されます。どちらの操作もアプリケーションに対して透過的です。

注意:
自動ブロック修復では、Oracle Active Data Guardオプションを使用する必要があります。

関連項目:
Oracle Active Data Guardオプションおよび自動ブロック修復機能の詳細は、『Oracle Data Guard概要および管理』を参照してください。

13.2.6.2.2 フィジカル・スタンバイ・データベースからのデータの抽出

Data Guardフィジカル・スタンバイ・データベースを使用して、破損データファイルをスタンバイ・データベースの良好なコピーで置換することにより、プライマリ・データベース上のデータファイル全体のブロック破損を修復できます。ファイルがプライマリ・データベースにリストアされた後、データファイルまたは表領域リカバリによって、データファイルとデータベースの残りの部分との整合性がとられます。

関連項目:
スタンバイ・データベースのファイルを使用した、プライマリ・データベース上のデータファイルの損失からのリカバリの詳細は、『Oracle Data Guard概要および管理』を参照してください。

13.2.6.3 RMANとブロック・メディア・リカバリの使用

ブロック・メディア・リカバリでは、RMAN RECOVER BLOCKコマンドを使用して、データファイルでメディア破損としてマークされた1つのブロックまたはデータ・ブロックのセットをリカバリします。メディア破損としてマークされた、メディア・リカバリを必要とするデータ・ブロックの数が少ない場合、データファイル全体ではなく、破損したブロックを選択的にリストアおよびリカバリできます。ブロック・メディア・リカバリにより、REDO適用時間が最小化され、リカバリ時のI/Oオーバーヘッドが回避されます。ブロック・メディア・リカバリでは、破損ブロックのリカバリ中も、関連するデータファイルをオンラインのまま使用できます。ただし、破損ブロックは、完全にリカバリされるまで使用できない状態が続きます。

ブロック・メディア・リカバリを使用するのは、次の場合です。

- メディア・リカバリを必要とするブロックの数が少なく、リカバリの必要なブロックが判明している場合。

- ブロックが破損としてマークされている場合(RMAN VALIDATE CHECK LOGICALコマンドで検証可能)。

- 破損したデータファイルのバックアップ・ファイルがローカルで使用可能であるか、そのバックアップ・ファイルをリモートの場所から取得できる場合。

注意:
データ・ブロックに問題のない論理的な破損の原因となるユーザー・エラーまたはソフトウェア・バグからのリカバリには、ブロック・メディア・リカバリを使用しないでください。

データファイルの重要な部分が破損しているか、破損量が不明の場合は、RMANを使用してバックアップからのファイルのリストアまたはディスク・イメージ・コピーへの切替えを行うか、Data Guardスタンバイ・データベースにスイッチオーバーしてください。

破損が検出された場合は、Oracle Enterprise Managerのリストアまたはリカバリウィザードを使用してブロックをリカバリするか、RMANで直接リカバリします。たとえば、RMANブロック・メディア・リカバリを使用して特定の破損ブロックをリカバリするには、次のようにします。

RMAN> RECOVER BLOCK DATAFILE 7 BLOCK 3;

破損ブロックを修復すると、この破損ブロックを示す行がV$DATABASE_BLOCK_CORRUPTIONビューから削除されます。

関連項目:
RMANのブロック・メディア・リカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

13.2.6.4 Data Guardロール移行の実行

不良なコントローラまたはその他のハードウェアやソフトウェアの問題によりプライマリ・データベースの破損が広範囲の場合は、プライマリ・データベース・サーバーを修復する一方でスタンバイ・データベースにフェイルオーバーまたはスイッチオーバーできます。次の場合には、データの破損またはデータ障害にData Guardスイッチオーバーまたはフェイルオーバーを使用します。

- データベースが停止しているか、データベースが稼働していてもデータの破損や障害によりアプリケーションが使用不能であり、ローカルでのリストアとリカバリにかかる時間が長いか不明な場合。

- ローカルでのリカバリ時間が、ビジネス品質保証契約またはRTOより長くなる場合。

関連項目:
Data Guardのフェイルオーバーとスイッチオーバーの詳細は、『Oracle Data Guard概要および管理』を参照してください。

13.2.6.5 RMANおよびデータファイル・メディア・リカバリの使用

破損、および逸脱または欠落した書込みの解決に次のいずれの方法も使用できない場合は、RMANの従来のメディア・リカバリを使用します。

- データ・リカバリ・アドバイザの使用

- Active Data Guardの使用

- RMANとブロック・メディア・リカバリの使用

- Data Guardロール移行の実行

注意:
Data Guardフィジカル・スタンバイがない場合は、従来のメディア・リカバリを使用する必要があります。従来のメディア・リカバリを使用すると、1つ以上のファイルのバックアップ・コピーがリストアされ、データファイル、表領域またはデータベースのリカバリによってデータベースが整合性のとれた状態に戻ります。

データファイル・メディア・リカバリでは、RMAN RECOVERコマンドを使用して、データベースのデータファイル全体またはデータファイルのセットをリカバリします。メディア破損としてマークされた、メディア・リカバリを必要とするデータ・ブロックの数が多いか不明の場合、またはファイル全体が失われた場合、関連するデータファイルをリストアおよびリカバリする必要があります。

関連項目:
高度なユーザー管理リカバリ・シナリオの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

13.2.7 人為的エラーからのリカバリ(フラッシュバックによるリカバリ)

Oracleフラッシュバック・テクノロジは、データ・リカバリの概念を大きく変えるものです。フラッシュバック・テクノロジ以前は、データベースを破損するのは数秒でも、リカバリには数時間から数日を要していました。フラッシュバック・テクノロジを使用すると、エラーを修正する時間が、エラーを起こしたときの時間と同じ程度にまで短縮されます。人為的エラーが発生し、データベース、表、トランザクションまたは行レベルの変更を過去の任意の時点に戻す必要がある場合でも、データベースやオブジェクトをリストアすることなくそれらのエラーを簡単に修復できます。フラッシュバック・テクノロジでは、間違った行削除などの局所的な障害を詳細に分析して修復できます。また、フラッシュバック・テクノロジでは、不適切なアプリケーション・バッチ・ジョブを誤って実行した場合など、広範囲に影響が及ぶ障害を修復することも可能です。さらに、フラッシュバック・テクノロジは、データベース・リストアと比較して非常に高速です。

フラッシュバック・テクノロジは、次のような人為的エラーを修復する場合にのみ使用できます。

- 間違いによる(または悪意のある)更新、削除または挿入トランザクション

- 間違いによる(または悪意のある)DROP TABLE文

- 間違いによる(または悪意のある)バッチ・ジョブまたは広範囲に影響が及ぶアプリケーション・エラー

フラッシュバック・テクノロジは、ブロック破損、ディスク障害、ファイル削除などのメディア破損やデータ破損には使用できません。これらの停止を修復するには、13.2.2項「セカンダリ・データベースでのデータベース・フェイルオーバー」を参照してください。

注意:
フラッシュバック・データベース構成のベスト・プラクティスの詳細は、5.1.4項「フラッシュバック・データベースの有効化」を参照してください。

表13-6に、行の破壊(不適切な更新を使用した場合など)からデータベース全体の破壊(オペレーティング・システム・レベルで基礎となるファイルをすべて削除した場合など)まで、停止範囲に応じた各種のフラッシュバック・ソリューションをまとめます。

表13-6 様々な障害のフラッシュバック・ソリューション

停止範囲

人為的エラーの例

フラッシュバック・ソリューション

関連項目

行またはトランザクション

意図しない行の削除

間違ったトランザクション

フラッシュバック問合せ

フラッシュバック・バージョン問合せ

フラッシュバック・トランザクション問合せ

フラッシュバック・トランザクション

関連項目: 13.2.7.2項「行およびトランザクションの非一貫性の解決」

表

表の削除

1つの表または表のセットに影響を与える間違ったトランザクション

フラッシュバック・ドロップ

フラッシュバック表

関連項目: 13.2.7.1項「表の非一貫性の解決」

表領域またはデータベース

多くの表または不明な表のセットに影響を与える間違ったバッチ・ジョブ

データベース全体を対象とする悪意のある一連のトランザクション

フラッシュバック・データベースの有効化またはFLASHBACK TABLEコマンドの複数回使用

関連項目: 13.2.7.3項「データベース全体の非一貫性の解決」

単一の表領域、または複数の表領域のサブセット

少数の表領域に影響を与える間違ったトランザクション

RMAN表領域のPoint-in-Timeリカバリ(TSPITR)

関連項目: 13.2.7.4項「1つまたは複数の表領域の非一貫性の解決」

表13-7に、各フラッシュバック機能をまとめます。

表13-7 フラッシュバック機能のまとめ

フラッシュバック機能

説明

変更の伝播先

フラッシュバック問合せ

フラッシュバック問合せでは、以前のある時点でのデータを参照できます。この機能は、間違って削除または変更された損失データを参照および再構築する際に使用します。開発者は、この機能を使用して、アプリケーションにセルフサービスのエラー修正機能を組み込み、エンド・ユーザーにエラーを元に戻して修正する機能を提供できます。

フィジカルおよびロジカル・スタンバイ・データベース

フラッシュバック・バージョン問合せ

フラッシュバック・バージョン問合せでは、データベースに格納されたUNDOデータを使用して、1つ以上の行に対する変更と、その変更のすべてのメタデータを参照できます。

フィジカルおよびロジカル・スタンバイ・データベース

フラッシュバック・トランザクション問合せ

フラッシュバック・トランザクション問合せでは、トランザクション・レベルでデータベースに対する変更を調査できます。その結果、問題の診断、分析の実行、およびトランザクションの監査を行うことができます。

フィジカルおよびロジカル・スタンバイ・データベース

フラッシュバック・トランザクション

フラッシュバック・トランザクションを使用すると、データベースをオンラインにしたままで、1つまたは複数のトランザクションとその依存トランザクションをロールバックできます。

フィジカルおよびロジカル・スタンバイ・データベース

フラッシュバック・ドロップ

フラッシュバック・ドロップでは、間違って削除した表をリストアできます。

フィジカル・スタンバイ・データベース

フラッシュバック表

フラッシュバック表では、バックアップをリストアせずに以前のある時点まで表を迅速にリカバリできます。

フィジカルおよびロジカル・スタンバイ・データベース

フラッシュバック・データベース

フラッシュバック・データベースでは、過去のある時点以降に発生したすべての変更を取り消すことで、データベースをその時点まで迅速に戻すことができます。バックアップをリストアする必要がないため、この操作は高速です。

フィジカルおよびロジカル・スタンバイ・データベース

フラッシュバック・データベースでは、Oracleデータベースのフラッシュバック・ログを使用し、他のすべてのフラッシュバック・テクノロジ機能では、Oracleデータベース独自のUNDO機能とマルチバージョン読取り一貫性機能を使用します。詳細は、5.1項「データベース構成の高可用性および高速リカバリのベスト・プラクティス」に記載されているデータベース構成上のベスト・プラクティスを参照して、障害時にこれらのソリューションでリソースを使用できるようフラッシュバック・テクノロジを構成してください。

関連項目:

- Oracleフラッシュバック表を使用した表のリカバリの詳細は、『Oracle Database管理者ガイド』を参照してください。

- フラッシュバック・データベースとリストア・ポイントの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- Oracle Flashback Technologyの詳細は、『Oracle Database概要』を参照してください。

一般的に、フラッシュバック・テクノロジを使用した場合のリカバリ時間は、人為的エラーの発生に要した時間と人為的エラーの検出に要した時間の合計に等しくなります。

フラッシュバック・テクノロジでは、人為的エラーが発生した時点までリカバリすることが可能です。

次のリカバリ方法を使用できます。

- 表の非一貫性の解決

- 行およびトランザクションの非一貫性の解決

- データベース全体の非一貫性の解決

- 1つまたは複数の表領域の非一貫性の解決

13.2.7.1 表の非一貫性の解決

誤ってデータベース・オブジェクトを削除することは、よくあります。ユーザーはすぐこの間違いに気付きますが、その時点ではすでに遅く、削除した表とその索引、制約、トリガーを簡単に元に戻す方法はなくなっています。以前は、一度削除したオブジェクトは永久的に失われていました。非常に重要な表やその他のオブジェクト(索引、パーティションまたはクラスタ)が失われた場合、DBAはポイント・イン・タイム・リカバリを実行する必要がありましたが、これは時間のかかる操作であり、最新のトランザクションは失われる可能性がありました。

Oracleでは、表の非一貫性の解決を支援するために、次の文が用意されています。

- FLASHBACK TABLE文: データベースで、以前のある時点の表を復元します。

- FLASHBACK DROP文: うっかりDROP TABLE文を実行した場合にリカバリします。

- FLASHBACK TRANSACTION文: データベースをオンラインにしたままで、1つまたは複数のトランザクションとその依存トランザクションをロールバックします。

フラッシュバック表

FLASHBACK TABLEを使用すると、1つの表または表のセットを特定の時点に迅速にリカバリできます。多くの場合、フラッシュバック表を使用することで、ポイント・イン・タイム・リカバリ操作の複雑さが軽減されます。たとえば、次のようになります。

FLASHBACK TABLE orders, order_items
TO TIMESTAMP
TO_DATE('28-Jun-11 14.00.00','dd-Mon-yy hh24:mi:ss');

この文により、タイムスタンプで指定した過去の時点から現在までの間に発生したORDERS表とORDER_ITEMS表に対するすべての更新が元に戻されます。フラッシュバック表では、この操作がオンラインでインプレース実行されると同時に、表間の参照整合性制約も維持されます。

フラッシュバック・ドロップ

フラッシュバック・ドロップは、オブジェクトを削除するときの安全策を提供します。ユーザーが表を削除すると、その表はごみ箱に配置されます。ごみ箱のオブジェクトは、ユーザーがそれらを永久的に削除することを決定するまで、またはその表を含む表領域の領域制限に到達するまでそのまま格納されます。ごみ箱は、すべての削除済オブジェクトが存在する仮想的なコンテナです。ユーザーは、ごみ箱を参照して、削除済の表とその依存オブジェクトを元に戻すことができます。たとえば、employees表とそのすべての依存オブジェクトを元に戻すには、次の文を使用します。

FLASHBACK TABLE employees TO BEFORE DROP;

フラッシュバック・トランザクション

Oracleフラッシュバック・トランザクションでは、データベースをオンラインにしたままで、特定のトランザクションまたはトランザクションのセットを簡単かつ迅速に取り消すことができ、ロジカル・リカバリ時の可用性が向上します。

トランザクションとその依存トランザクションをロールバックするには、DBMS_FLASHBACK.TRANSACTION_BACKOUT() PL/SQLプロシージャを使用します。このプロシージャは、UNDOデータを使用して、影響を受けたデータをトランザクション前の状態に戻す補正トランザクションを作成、実行します。

関連項目:

- フラッシュバック・トランザクションの使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』の「DBMS_FLASHBACK.TRANSACTION_BACKOUT()」

13.2.7.2 行およびトランザクションの非一貫性の解決

行およびトランザクションの非一貫性を解決するには、フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せ、および問題を修正するためのUNDO文で構成された補正SQL文を組み合せて使用する必要があります。この項では、人事管理の例を使用して、間違いによる(または悪意のある)ユーザー・エラーによって引き起こされた行およびトランザクションの非一貫性を解決するための一般的な方法について説明します。

フラッシュバック問合せ

フラッシュバック問合せでは、管理者やユーザーが以前のある時点でのデータを問合せできます。この機能は、間違って削除または変更されたデータを参照および再構築する際に使用します。

開発者は、フラッシュバック問合せを使用して、アプリケーションにセルフサービスのエラー修正機能を組み込み、エンド・ユーザーにエラーをすぐに元に戻して修正する機能を提供し、それらの作業からデータベース管理者を解放します。過去に設定された時間に合せてデータを再構築するのに必要な情報は、データベースで自動的に維持されるため、フラッシュバック問合せの管理は簡単です。

次の部分的な文により、2011年6月28日午後2時以降のEMPLOYEES表から行が選択されて表示されます。

SELECT * FROM EMPLOYEES
AS OF TIMESTAMP
TO_DATE('28-Jun-11 14:00','DD-Mon-YY HH24:MI')
WHERE ...

フラッシュバック・バージョン問合せ

フラッシュバック・バージョン問合せでは、データベースの変更を行レベルで参照できます。フラッシュバック・バージョン問合せは、SQLの拡張機能であり、指定した時間間隔で異なるバージョンの行をすべて取得できます。たとえば、次のようになります。

SELECT * FROM EMPLOYEES
VERSIONS BETWEEN TIMESTAMP
TO_DATE('28-Jun-11 14:00','dd-Mon-YY hh24:mi') AND
TO_DATE('28-Jun-11 15:00','dd-Mon-YY hh24:mi')
WHERE ...

この文により、2011年6月28日の午後2時から3時の間における各バージョンの行(異なるトランザクションによって変更された各エントリ)が表示されます。データベース管理者は、この機能を使用して、データがいつどのように変更されたかを特定し、関連するユーザー、アプリケーションまたはトランザクションを追跡することが可能です。フラッシュバック・バージョン問合せにより、データベース管理者は、データベースの論理破損の原因を追跡して修正できます。また、アプリケーション開発者は、自分のコードをデバッグできます。

フラッシュバック・トランザクション問合せ

フラッシュバック・トランザクション問合せでは、データベースの変更をトランザクション・レベルで参照できます。フラッシュバック・トランザクション問合せは、SQLの拡張機能であり、トランザクションによって行われたすべての変更を参照できます。たとえば、次のようになります。

SELECT UNDO_SQL
FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = '000200030000002D';

この文により、このトランザクションに基づくすべての変更が表示されます。また、補正SQL文が戻されるため、その文を使用してこのトランザクションで変更されたすべての行を元に戻すことができます。フラッシュバック・トランザクション問合せのような精度の高いツールを使用することで、データベース管理者とアプリケーション開発者は、データベースやアプリケーションの論理問題を正確に診断および修正できます。

ここでは、SCOTTスキーマに関連する人事管理(HR)の例について検討します。HRマネージャから、Wardの給与に食い違いがあるようだという報告がデータベース管理者に入ります。Wardの給与は、午前9時前のどこかの時点で$1875に上昇しました。HRマネージャは、この変更がどうして起こったのかわからないため、いつこの従業員の給与が上がったのかを把握するつもりです。また、HRマネージャは、スタッフに指示してWardの給与を以前のレベルの$1250に再設定しました。この作業は、午前9時15分ごろには完了しました。

この問題に対処するには、次の手順を実行します。

1. 問題を評価します。
変更の発生した時刻に関する情報は、HRマネージャから提供されています。フラッシュバック問合せを使用して、午前9時の時点での情報を問い合せます。

SELECT EMPNO, ENAME, SAL
FROM EMP
AS OF TIMESTAMP TO_DATE('28-JUN-11 09:00','dd-Mon-yy hh24:mi')
WHERE ENAME = 'WARD';

EMPNO ENAME             SAL
---------- ---------- ----------
7521 WARD             1875

Wardの給与が午前9時の時点で$1875であったという事実から、正しい従業員を選択したことを確認できます。後続の調査では、Wardの名前ではなく従業員番号を使用できます。

2. トランザクション情報を取得するため、データの以前の行またはバージョンを問い合せます。
行バージョン情報を特定の日付またはSCNの範囲に制限することも可能ですが、フラッシュバック・バージョン問合せを使用すると、従業員WARDについて使用可能なすべての行情報を問い合せることができます。

SELECT EMPNO, ENAME, SAL, VERSIONS_STARTTIME, VERSIONS_ENDTIME, VERSIONS_XID
FROM EMP
VERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUE
WHERE EMPNO = 7521
ORDER BY NVL(VERSIONS_STARTSCN,1);

EMPNO ENAME  SAL  VERSIONS_STARTTIME     VERSIONS_ENDTIME      VERSIONS_XID
----- ------ ---  ---------------------- -------------------- ---------------
7521 WARD  1250  28-JUN-11 08.48.43 AM  28-JUN-11 08.54.49 AM 0006000800000086
7521 WARD  1875  28-JUN-11 08.54.49 AM  28-JUN-11 09.10.09 AM 0009000500000089
7521 WARD  1250  28-JUN-11 09.10.09 AM                        000800050000008B

WARDの給与は、今朝の08:54:49に$1250から$1875に上がり、その後09:10:09ごろに$1250に戻されたことがわかります。

また、WARDの給与を$1875に上げた不適切なトランザクションのIDが、0009000500000089であることもわかります。

3. 不適切なトランザクションとその影響範囲を問い合せます。
フラッシュバック・トランザクション問合せにトランザクション情報(VERSIONS_XID擬似列)を指定してデータベースに問い合せ、トランザクションの範囲を確認します。

SELECT UNDO_SQL
FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = HEXTORAW('0009000500000089');

UNDO_SQL
----------------------------------------------------------------------------
update "SCOTT"."EMP" set "SAL" = '950' where ROWID = 'AAACV4AAFAAAAKtAAL';
update "SCOTT"."EMP" set "SAL" = '1500' where ROWID = 'AAACV4AAFAAAAKtAAJ';
update "SCOTT"."EMP" set "SAL" = '2850' where ROWID = 'AAACV4AAFAAAAKtAAF';
update "SCOTT"."EMP" set "SAL" = '1250' where ROWID = 'AAACV4AAFAAAAKtAAE';
update "SCOTT"."EMP" set "SAL" = '1600' where ROWID = 'AAACV4AAFAAAAKtAAB';

6 rows selected.

このトランザクションでは、WARDの給与以外にも変更が発生していたことがわかります。従業員WARDと同時に変更されていた他の4人の従業員情報を、確認のためHRマネージャに送信できます。

4. 修正用の文を実行するかどうかを確認します。
UNDO_SQL列に示された修正用の変更文がHRマネージャによって正しいと判断されたら、データベース管理者はその文を個別に実行できます。

5. FLASHBACK_TRANSACTION_QUERYビューを問い合せて追加のトランザクション情報を取得します。たとえば、間違った更新を実行したユーザーを確認するには、次の問合せを発行します。

SELECT LOGON_USER FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = HEXTORAW('0009000500000089');

LOGON_USER
----------------------------
MSMITH

この例の場合、ユーザーMSMITHが間違ったトランザクションを実行していたことがわかります。

13.2.7.3 データベース全体の非一貫性の解決

Oracleデータベースを過去の時点に戻すための従来のメソッドは、Point-in-Timeリカバリです。ただし、Point-in-Timeリカバリは、データベース全体をバックアップからリストアし、データベースでエラーが発生する前の時点にリカバリする必要があるため、数時間または数日かかる場合があります。データベースのサイズは絶えず拡大しているため、データベース全体をリストアするだけでも数時間から数日かかります。

フラッシュバック・データベースは、ポイント・イン・タイム・リカバリを実行するための手段です。フラッシュバック・データベースを使用すると、論理的データ破損またはユーザー・エラーを原因とする問題を修正するために、Oracleデータベースを過去の時点に迅速に戻すことができます。フラッシュバック・ログは、以前のバージョンの変更済ブロックを取得するのに使用されます。リカバリを実行する必要がある場合、データベースをエラー前の時点にリストアするためにフラッシュバック・ログが迅速に適用され、変更済ブロックがリストアされます。フラッシュバック・データベースは非常に高速であり、リカバリ時間を数時間から数分に短縮できます。また、この機能は簡単に使用できます。1つの文を発行することで、データベースを午後2時5分の時点にリカバリできます。データベースをリカバリするには、データベースのすべてのインスタンスを停止して、その後、インスタンスの1つをマウントする必要があります。次に、FLASHBACK DATABASE文の例を示します。

FLASHBACK DATABASE TO TIMESTAMP SYSDATE-1;

フラッシュバック・データベースを使用する場合、テープからのリストア、長い停止時間、および複雑なリカバリ手順は必要とされません。フラッシュバック・データベースを使用して、データベースを読取り専用モードでオープンし、その内容を調査することも可能です。フラッシュバックした時点が希望の位置と比べて前後した場合は、FLASHBACK DATABASE文を再発行するか、データベースが破損する前の適切な時点を見つけるために、より新しい時点にまでリカバリを続けることができます。フラッシュバック・データベースは、プライマリ・データベース、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースで動作します。

フラッシュバック・データベースを使用する際に推奨される手順は、次のとおりです。

1. データベースをフラッシュバックする日時またはSCNを決定します。

2. 十分なフラッシュバック・ログ情報が存在することを確認します。

SELECT OLDEST_FLASHBACK_SCN,
TO_CHAR(OLDEST_FLASHBACK_TIME, 'mon-dd-yyyy HH:MI:SS')
FROM V$FLASHBACK_DATABASE_LOG;

3. データベースを特定の日時またはSCNにフラッシュバックします。(フラッシュバック・データベースを実行するにはデータベースをマウントする必要があります。)

FLASHBACK DATABASE TO SCN scn;

または

FLASHBACK DATABASE TO TIMESTAMP TO_DATE date;

4. データベースを読取り専用モードでオープンして、正しい状態になっていることを確認します。

ALTER DATABASE OPEN READ ONLY;

追加のフラッシュバック・データが必要な場合は、もう一度FLASHBACK DATABASE文を発行します。(フラッシュバック・データベースを実行するにはデータベースをマウントする必要があります。)

時間的に前に進めるには、次のような文を発行します。

RECOVER DATABASE UNTIL [TIME date | CHANGE scn];

5. データベースをオープンします。

ALTER DATABASE OPEN RESETLOGS;

フラッシュバック・データベースを使用する際のその他の考慮事項は、次のとおりです。

- 目的の時点にフラッシュバックするのに十分なフラッシュバック・ログが存在しない場合は、代替方法を使用します。

- Data Guardを使用して、目的の時点にリカバリするか(スタンバイ・データベースがプライマリ・データベースより遅れている場合)、目的の時点にフラッシュバックします(スタンバイ・データベースに十分なフラッシュバック・ログが存在する場合)。

- バックアップからリストアします。

- データベースのフラッシュバック後は、スタンバイ・データベースなどの依存データベースもすべてフラッシュバックする必要があります。13.3項「フォルト・トレランスのリストア」を参照してください。

フラッシュバック・データベースでは、削除した表領域は自動的に修復されませんが、フラッシュバック・データベースを使用して停止時間を大幅に短縮できます。表領域が削除される前の時点にプライマリ・データベースをフラッシュバックして、SET NEWNAMEを使用して関連する表領域から対応するデータファイルのバックアップをリストアし、表領域が削除される前の時点にリカバリできます。

13.2.7.4 1つまたは複数の表領域の非一貫性の解決

Recovery Manager(RMAN)の自動化された表領域のPoint-in-Timeリカバリ(TSPITR)を使用すると、データベースの1つまたは複数の表領域を、以前の時点まで迅速にリカバリでき、表領域の他の部分とデータベースのオブジェクトには影響を与えません。TSPITRは、データベースの他の部分からデータが完全に分離された表領域でのみ使用できます。つまり、通常、TSPITRの使用にあたっては、あらかじめ計画する必要があります。

RMAN TSPITRが最も有効なのは、次の状況です。

- 複数のロジカル・データベースが1つのフィジカル・データベースの別々の表領域に存在するときに、ロジカル・データベースをフィジカル・データベースの他の部分と異なる時点にリカバリする場合。たとえば、ロジカル・データベースのOrders表領域とPersonnel表領域を管理しているとします。不適切なバッチ・ジョブまたはDML文は、1つの表領域のデータのみを破損します。

- 表の構造を変更するDDL操作の後で失われたデータを回復する場合。FLASHBACK TABLEを使用しても、表の切捨て操作などの構造変更の時点以前に表を巻き戻すことはできません。

- PURGEオプションで表を削除した後でその表をリカバリする場合。

- 表の論理破損からリカバリする場合。

RMAN RECOVER TABLESPACEコマンドを使用することにより、TSPITRを実行します。

関連項目:
RMAN TSPITRの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

13.2.8 分散環境でのデータベースのリカバリ

一部のアプリケーションは、複数のデータベースを更新でき、分散トランザクションに関与できます。関与するデータベース間のグローバルな一貫性は、アプリケーションに不可欠です。

分散データベース環境の1つのデータベースを過去の時点にリカバリする必要がある場合は、アプリケーションでグローバルなデータ一貫性が必要なときに、構成内の他のすべてのデータベースを同じ時点にリカバリすることが必要な場合があります。

時間ベースの協調分散データベース・リカバリを実現するには、次の手順を実行します。

1. 時間ベースのリカバリを使用して、リカバリ操作を必要とするデータベースをリカバリします。
たとえば、メディア障害のためにデータベースをリカバリする必要がある場合、時間ベースのリカバリを使用して最初にこのデータベースをリカバリします。この時点では他のデータベースをリカバリしないでください。

2. データベースをリカバリし、RESETLOGSオプションを使用してデータベースをオープンしたら、データベースのalert_SID.logでRESETLOGSメッセージを検索します。次の手順は、次の表に示したとおり、ログ・ファイル内で見つかったメッセージに応じて変化します。

戻されたメッセージ

その後の手順

RESETLOGS after complete recovery through change nnn

リカバリは完全です。データベースのすべての変更を適用し、完全リカバリを実行しました。データベースの変更が不必要に削除されるため、分散システムの他のデータベースはいずれもリカバリしないでください。

RESETLOGS after incomplete recovery UNTIL CHANGE nnn

不完全リカバリの実行に成功しました。メッセージの変更番号を記録し、次の手順に進んでください。

3. 変更ベースのリカバリを使用して分散データベース・システムの他のすべてのデータベースをリカバリまたはフラッシュバックします。このとき、手順2で記録した変更番号(SCN)を指定します。

注意:
分散トランザクションに参加するデータベースに障害が発生した場合、そのデータベースにインダウト分散トランザクションが存在する可能性があります。障害データベースが完全にリカバリされ、データベース間の通信が再開すると、インダウト・トランザクションはOracleリカバラ・プロセス(RECOプロセス)により自動的に解決されます。障害データベースが使用可能になるまで待機できない場合は、インダウト・トランザクションを手動でコミットまたはロールバックすることもできます。

関連項目:

- 時間ベースのリカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- インダウト・トランザクションの処理方法と分散トランザクション障害からのリカバリの詳細は、『Oracle Database管理者ガイド』を参照してください。

- 複数のOracleデータベースをローカルおよび分散データベース・トランザクションと一貫性のある状態にリカバリするための他の方法は、My Oracle Supportのノート1096993.1を参照してください。関与するデータベースは、分散またはリモート・トランザクションに関係している場合や、完全に独立しているがアプリケーションの一貫性を保つために「同期」が必要な場合があります。複数のデータベースを含むSiebel、Peoplesoft、SAPおよびその他のカスタム・アプリケーションは、複数のデータベース間にグローバルな一貫性を必要とする実際の例です。詳細は、次の場所にあるMy Oracle Supportのノート1096993.1の『Recovery for Global Consistency in an Oracle Distributed Database Environment』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1096993.1

13.3 フォルト・トレランスのリストア

高可用性アーキテクチャのコンポーネントに障害が発生するたびに、アーキテクチャの完全保護またはフォルト・トレランスが損われ、コンポーネントが修復されるまで単一点障害が存在する可能性があります。高可用性アーキテクチャを完全なフォルト・トレランスにリストアして完全なOracle RAC、Data GuardまたはMAA保護を再確立するには、障害のあるコンポーネントの修復が必要です。計画停止時間中は完全なフォルト・トレランスが犠牲になることがありますが、計画済であるため修復の方法はよく理解されており、リスクは管理され、継続的なアプリケーション可用性に最適な時点で実行されます。一方、計画外の停止時間については、単一点障害のリスクを明確に理解する必要があります。

この項には、データベースのフォルト・トレランスを回復するのに必要な手順を記載した次の項目が含まれます。

- Oracle RACまたはOracle RAC One Nodeを使用したOracle Database 11gの場合

- Oracle RACおよびOracle RAC One Nodeの障害ノードまたは障害インスタンスのリストア

- Data Guardを使用したOracle Database 11gと、Oracle RACおよびData Guardを使用したOracle Database 11g(MAA)の場合

- フェイルオーバー後のスタンバイ・データベースのリストア

- 障害後のOracle ASMディスク・グループのリストア

- セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア

- スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア

- RESETLOGSによるプライマリ・データベースのオープン後のフォルト・トレランスのリストア

- 二重障害後のフォルト・トレランスのリストア

13.3.1 Oracle RACおよびOracle RAC One Nodeの障害ノードまたは障害インスタンスのリストア

アプリケーション・サービスをOracle RACクラスタ内(またはプライマリ・サイトとセカンダリ・サイト間)で自動的にすばやくフェイルオーバーすることは、計画済の停止と計画外の停止の両方に備えるうえで重要です。同様に、Oracle RAC One Nodeを使用して、Oracle RAC One Nodeインスタンスに障害が発生した場合に起動する新しいインスタンスにアプリケーションがフェイルオーバーすることを確認する必要があります。また、エラーまたは問題の修正後に、環境で完全なフォルト・トレランスを回復するためには、Oracle RACクラスタ内または各サイトのデータベースで障害インスタンスや障害ノードをリストアするための手順およびプロセスを理解しておくことも重要です。

特定のコンポーネントに最初に障害を発生させる原因となった主要な問題を修正したら、クラスタに障害ノードを戻すことや、Oracle RACまたはOracle RAC One Nodeの障害インスタンスを再起動することは簡単です。ただし、次のことを検討する必要があります。

- 現在稼働中の環境に影響をまったく与えないか、最小限の影響で抑えるためにこれらのタスクを実行するのに最適な時期

- 既存の接続のフェイルバックまたは再調整

ノードまたはインスタンスの最初の障害を引き起こした問題を修正したら、ノードまたはインスタンスを再起動していつでもOracle RAC環境に戻すことができます。Oracle RAC One Nodeでは、障害インスタンスを再起動し、元のノードでインスタンスを実行することもできます。ノードの再構成を完了するための処理では、追加のシステム・リソースを必要とする場合があります。

表13-8に、ノードの追加時に必要とされる可能性のある追加処理をまとめます。

表13-8 ノードまたはインスタンスの再起動または再結合時の追加処理

アクション

追加リソース

ノードの再起動またはクラスタへのノードの再結合

Oracleクラスタウェアのみを使用している場合、ノードをクラスタに結合することによる影響はありません。

ベンダーのクラスタウェアを使用している場合、ノードをクラスタに戻すための再構成中にパフォーマンスが低下する可能性があります。現在のアプリケーションに対する影響は、フル・ワークロードのテストで評価しておく必要があります。

Oracle RACインスタンスの再起動または再結合

Oracle RACインスタンスを再起動する場合、ロックの再構成中はパフォーマンスに多少影響する可能性があります。現在のアプリケーションに対する影響は、通常はほとんどありませんが、フル・ワークロードのテストで評価しておく必要があります。

次のリカバリ方法を使用できます。

- Oracle RACのサービス可用性のリカバリ

- Oracle RAC One Nodeのサービス可用性のリカバリ

- Oracle RACインスタンスのリストア後のクライアント接続に関する考慮事項

関連項目:

- Oracle RACインスタンスの再起動の詳細は、『Oracle Database Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- ノードを起動してクラスタに結合する方法の詳細な手順は、ベンダーが指定するクラスタ管理ドキュメントを参照してください。

13.3.1.1 Oracle RACのサービス可用性のリカバリ

注意:
サービス可用性のリカバリに関するこれらの説明はOracle RACに関するものであり、Oracle RAC One Nodeシステムには適用されません。

障害ノードがクラスタに戻され、そのインスタンスが起動されると、Cluster Ready Services(CRS)によってノードで使用される仮想IPアドレスと、インスタンスでサポートされるサービスが自動的に管理されます。リストアされたインスタンスでは、特定のサービスが起動される場合と起動されない場合があります。CRSがリストアされたインスタンスでサービスを起動するかどうかは、サービスがどのように構成されているかと、その時点で適切な数のインスタンスがサービスへのアクセスを提供しているかどうかによって決定されます。最初の障害が発生したときにCRSによって移動された稼働中のインスタンスで、サービスが現在も適切に提供されている場合、そのサービスは優先インスタンスに再配置されません。

CRSがリストアされたインスタンスでサービスを再起動するのは、クラスタ全体でサービスへのアクセスを提供しているインスタンスの数が、そのサービスに定義されている優先インスタンスの数より少ない場合です。CRSは、リストアされたインスタンスでサービスを再起動すると、登録アプリケーションにサービスの変更を通知します。

たとえば、HRサービスがインスタンスAおよびBでは優先として定義され、インスタンスCおよびDでは障害発生時に使用可能として定義されているとします。インスタンスBに障害が発生すると、CRSはCでHRサービスを自動的に開始し、インスタンスBが再起動された後もHRサービスはインスタンスCに残ります。CRSは、サービスを優先インスタンスに自動的には再配置しません。

HRサービスがインスタンスA、B、C、Dで優先として定義され、使用可能として定義されているインスタンスはなく、サービスがクラスタ内のすべてのノードに分散している別のシナリオについて考えます。インスタンスBに障害が発生した場合、HRサービスは他の3つのノードで使用可能なままになります。HRサービスは構成されているインスタンス数よりも少ないインスタンスで実行されているため、CRSは、インスタンスBがクラスタに再結合されたときにインスタンスBでHRサービスを自動的に開始します。CRSは、HRサービスがインスタンスBで再び使用可能になったことをアプリケーションに通知します。

関連項目:
『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

13.3.1.2 Oracle RAC One Nodeのサービス可用性のリカバリ

Oracle RAC One Nodeデータベースの管理は、Oracle RACデータベースまたはシングル・インスタンス・データベースとは若干異なります。管理者管理Oracle RAC One Nodeデータベースの場合は、候補ノード・リストを監視し、可能であればサーバーがいつでもフェイルオーバーに使用できるようにしておく必要があります。候補サーバーは汎用サーバー・プールに存在し、データベースとそのサービスは、いずれかの候補サーバーにフェイルオーバーします。

ポリシー管理Oracle RAC One Nodeデータベースの場合は、その現在のノードが使用できなくなった場合に備えて、サーバーがデータベースのフェイルオーバーに使用できるようにサーバー・プールが確実に構成されている必要があります。また、ポリシー管理Oracle RAC One Nodeデータベースでは、オンライン・データベース再配置用の宛先ノードを、データベースのサーバー・プールに配置する必要があります。

関連項目:
Oracle RAC One Nodeの管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

13.3.1.3 Oracle RACインスタンスのリストア後のクライアント接続に関する考慮事項

Oracle RACインスタンスのリストア後、システムの現在のリソース使用状況とパフォーマンス、アプリケーション構成、および実装されているネットワーク・ロード・バランシング機能によっては、追加の手順を実行する必要があります。

稼働を続けているOracleインスタンス上でフェイルオーバーまたは新規セッションとして開始された可能性のある既存の接続は、再起動されたインスタンスに自動的には再配布またはフェイルバックされません。現在のリソース使用率と、稼働を続けているインスタンスがワークロードを十分に処理でき、許容されるレスポンス時間を提供するかどうかに応じて、ユーザーのフェイルバックまたは再配布が必要な場合と不要な場合とがあります。稼働を続けているOracle RACインスタンスに、ワークロード全体を実行するのに十分なリソースがないか、許容されるレスポンス時間を提供しない場合は、一部の既存のユーザー接続を再起動されたインスタンスに移動(切断して再接続)することが必要な場合があります。

注意:
Oracle RAC One Nodeでは、データベースに対してインスタンスが1つのみあります(移行していない場合)。したがってOracle RAC One Node構成では、接続が1つしかないため、接続の"リバランス"の戦略を再考する必要はありません。Oracle RAC One Nodeを使用しているクライアントは、サービスのステータスに関する通知を受けるために、FANやその他のクライアントおよびサービス機能を操作できる必要があります。

接続ロード・バランシングが構成されている場合は、使用頻度の最も低いノードで必要に応じて接続が開始されます。したがって、接続は、時間の経過とともに自動的に分散されます。

アプリケーション・サービスでは、次の構成を使用できます。

- Oracle RACインスタンスのサブセットで稼働するサービスで管理される構成。

- パーティション化しない構成: すべてのサービスがすべてのノードで均等に稼働します。

これは、データセットの結合を維持したままアプリケーションおよびデータベースの形式と機能をモジュール化する際に役立ちます。アプリケーションをパーティション化する場合、またはパーティション化と非パーティション化の組合せを使用する場合、各サービスのレスポンス時間と可用性を考慮する必要があります。

特定のサービスの接続を再分散またはフェイルバックする必要がある場合、Oracle Universal Connection Pool (UCP)を使用してワークロードを自動的にリバランスできます。UCPを使用している場合、接続は新しいノードに自動的に再分散されます。

注意:
Oracle Universal Connection Pool(UCP)は、高速接続フェイルオーバーとFANイベントを使用して、接続障害を高速かつ自動的に検出し、Javaアプリケーションの終了した接続を削除します。

複数のOracle RACインスタンス間のロード・バランシング・アプリケーション・サービスには、Oracle Net接続時フェイルオーバーと接続ロード・バランシングをお薦めします。この機能には、フェイルオーバーまたはリストアの変更や修正は不要です。ハードウェア・ベースのロード・バランサも使用できます。ただし、個々のアプリケーション・サービスの区別(Oracle Net Servicesでは認識されます)とインスタンスまたはノードのリストアには制限がある場合があります。たとえば、ノードまたはインスタンスがリストアされ、接続の受信を開始できるようになった場合、リストアされたノードまたはインスタンスをハードウェア・ベースのロード・バランサ・ロジックに含めるには手動の手順が必要な場合がありますが、Oracle Net Servicesでは手動再構成は不要です。

表13-9に、インスタンス・リストア後の新規および既存の接続に関する考慮事項をまとめます。これらの考慮事項は、パーティション化、非パーティション化、またはその両方の組合せというアプリケーション・サービスの構成に応じて変化します。既存の接続の再分散が実際に必要であるかどうかは、リソース使用状況とレスポンス時間に応じて決定されます。

表13-9 リストアおよび接続フェイルバック

アプリケーション・サービス

既存の接続のフェイルバックまたはリストア

新規接続のフェイルバックまたはリストア

パーティション化

既存のセッションは、リストアされたインスタンスに自動的に再配置されません。SRVCTLユーティリティを使用して、サービスを手動で開始、停止および再配置します。詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のサービスの管理に関する項を参照してください。

Oracle Net Services構成の使用により、リストアされたインスタンスに自動的にルーティングされます。

非パーティション化

インスタンスがリストアされた時点でそのインスタンスの負荷は低いため、負荷を再調整する必要がなければ特に何もする必要はありません。負荷を再調整する必要がある場合は、アプリケーション・サービスをパーティション化している場合と同様の問題が発生します。

Oracle Net Services構成の使用により、リストアされたインスタンスに自動的にルーティングされます(そのインスタンスの負荷が最も低いため)。

図13-6は、2つのノードでパーティション化されたOracle RACデータベースを示しています。各インスタンスでは、異なるアプリケーション機能(HRおよびSales)が提供されます。クライアント・プロセスは、必要とするサービスに基づいて適切なインスタンスに接続します。

図13-6 パーティション化された2ノードのOracle RACデータベース

図13-7は、1つのOracle RACインスタンスに障害が発生した場合を示しています。

図13-7 パーティション化されたデータベースでのOracle RACインスタンスのフェイルオーバー

1つのOracle RACインスタンスに障害が発生すると、サービスと既存のクライアント接続は、別のOracle RACインスタンスに自動的にフェイルオーバーされます。この例の場合、HRサービスとSalesサービスは、両方とも稼働を続けるOracle RACインスタンスによってサポートされます。また、Salesサービスに対する新規クライアント接続は、Salesサービスのサポートを開始したインスタンスにルーティングされます。

障害インスタンスが修復およびリストアされて図13-6の状態に戻り、Salesサービスがリストアされたインスタンスに再配置されると、フェイルオーバーされたクライアントと、フェイルオーバー先のインスタンスのSalesサービスに接続されていた新規クライアントは、それぞれ識別されてフェイルバックされる可能性があります。インスタンスのリストア後に開始したクライアント接続は、自動的に元のインスタンスに接続されます。したがって、時間の経過とともに古い接続は切断され、新規セッションはSalesサービスに接続されるため、クライアント負荷はリストアされたインスタンスに戻ります。リストアの直後に負荷の再調整が発生するかどうかは、リソース使用状況とアプリケーションのレスポンス時間に応じて決定されます。

図13-8は、パーティション化されていないアプリケーションを示しています。サービスは、アクティブな2つのインスタンス間で均等に分散されます。各インスタンスには、HRとSalesに対するクライアント接続が混在しています。

図13-8 パーティション化されていないOracle RACインスタンス

1つのOracle RACインストールに障害が発生した場合、Oracle Clusterwareは障害インスタンスで実行されていたサービスを移動します。1つのOracle RACインスタンスに障害が発生した場合、新しいクライアント接続はそのサービスを提供する残りのインスタンスでのみ受け入れられます。

障害インスタンスが修復およびリストアされて図13-8の状態に戻ると、一部のクライアントはリストアされたインスタンスに戻される可能性があります。パーティション化されていないアプリケーションでは、すべての使用可能なインスタンス間でクライアント負荷を再調整するために適切なサービスを識別する必要はありません。この処理は、単一インスタンス・データベースでリクエストを十分に処理できない場合にのみ必要です。

インスタンスのリストア後に開始したクライアント接続は、自動的にリストアされたインスタンスに接続されます(そのインスタンスの負荷が他と比べて低いためです)。したがって、時間の経過とともに古い接続は切断され、新規セッションはリストアされたインスタンスに接続されるため、クライアント負荷は再び使用可能なすべてのOracle RACインスタンス間で均等に分散されます。リストアの直後に負荷の再調整が発生するかどうかは、リソース使用状況とアプリケーションのレスポンス時間に応じて決定されます。

13.3.2 フェイルオーバー後のスタンバイ・データベースのリストア

フェイルオーバーを必要とするプライマリ・データベースの計画外の停止後、スタンバイ・データベースが再確立されるまで完全なフォルト・トレランスは損われます。データベースの完全保護は、可能なかぎり迅速に回復する必要があります。フォルト・トレランスを回復する手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースで多少異なります。

Data Guardファスト・スタート・フェイルオーバーを使用している場合、データベースは自動的に復元されます。ファスト・スタート・フェイルオーバーの完了後、オブザーバは元のプライマリ・データベースをスタンバイ・データベースとして自動的に回復しようとします。復元により、ブローカ構成に高可用性が回復され、新規プライマリ・データベースに障害が発生した場合に再度ファスト・スタート・フェイルオーバーを起動できます。復元されたデータベースは、新規プライマリ・データベース用としてファスト・スタート・フェイルオーバーのターゲットとなるため、再度のファスト・スタート・フェイルオーバーが可能になります。スタンバイ・データベースは、新規プライマリ・データベースから受信されたREDOデータの適用を開始することで、フェイルオーバーの実行可能なターゲットとなります。フェイルオーバーの完了後に診断作業や修復作業を実行するなど、自動復元を行わない場合、FastStartFailoverAutoReinstate構成プロパティをFALSEに設定します。

FastStartFailoverAutoReinstate構成プロパティは、プライマリ・データベースがFastStartFailoverThresholdプロパティで指定された秒数を超えて孤立したことによりファスト・スタート・フェイルオーバーが開始したためにファスト・スタート・フェイルオーバーが発生した後で、オブザーバが元のプライマリ・データベースを自動的に回復する必要があるかどうかを制御します。場合によっては、診断またはリカバリ作業が終了するまで自動復元は不要です。

元のプライマリ・データベースを復元する場合、データベースを起動してマウントする必要がありますが、オープンすることはできません。ブローカは、元のスタンバイ・データベースと同じタイプ(フィジカルまたはロジカル)のスタンバイ・データベースとしてデータベースを復元します。

元のプライマリ・データベースが自動的に復元されない場合、DGMGRL REINSTATEコマンドまたはEnterprise Managerを使用して手動で復元できます。手動復元の詳細な手順は、『Oracle Data Guard Broker』を参照してください。

Oracleのフラッシュバック・データベース機能を使用する場合、スタンバイ・データベースを再作成する必要はありません。フラッシュバック・データベースには、次のメリットがあります。

- 数時間に及ぶデータベースのリストア時間を節約できます。

- フォルト・トレランスを回復する際の全体的な複雑さを軽減できます。

- スタンバイ・データベースが迅速に再作成されるため、システムが脆弱である時間が短縮されます。

関連項目:

- フィジカル・スタンバイ・データベースへの障害の発生したプライマリ・データベースのフラッシュバックの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- ロジカル・スタンバイ・データベースへの障害の発生したプライマリ・データベースのフラッシュバックの詳細は、『Oracle Data Guard概要および管理』を参照してください。

この項には、次の項目が含まれます。

- ファスト・スタート・フェイルオーバー後の元のプライマリ・データベースの復元

- Enterprise Managerを使用したフェイルオーバー後のスタンバイ・データベースの復元

13.3.2.1 ファスト・スタート・フェイルオーバー後の元のプライマリ・データベースの復元

ファスト・スタート・フェイルオーバーの後、オブザーバは、定期的に以前のプライマリ・データベースに再接続するよう試みます。以前のプライマリ・データベースへのネットワーク・アクセスを再確立すると、オブザーバは、ブローカに対するリクエストを起動して、そのデータベースを新規プライマリ・データベース用のスタンバイ・データベースとして自動的に復元します。これにより、構成における障害保護と高可用性が迅速に回復されます。

ファスト・スタート・フェイルオーバーは、ブローカ構成内のデータベースに接続しながら、Enterprise Managerでオブザーバ・サイトを含む任意のサイトから有効化できます。ブローカでは、図13-9に示されているOracle Enterprise Managerのページでボタンを1回クリックするだけで簡単にスイッチオーバーやフェイルオーバーを起動できます。

図13-9 有効化に成功したファスト・スタート・フェイルオーバーとオブザーバ

13.3.2.2 Enterprise Managerを使用したフェイルオーバー後のスタンバイ・データベースの復元

Enterprise Managerを使用して、元のプライマリ・データベースを新規スタンバイ・データベースとして復元することも可能です。図13-10は、復元が必要な場合にEnterprise Managerに表示される警告メッセージの例を示しています。

図13-10 ファスト・スタート・フェイルオーバー後の元のプライマリ・データベースの復元

13.3.3 障害後のOracle ASMディスク・グループのリストア

13.2.5.3項「データ領域ディスク・グループ障害」または13.2.5.4項「高速リカバリ領域ディスク・グループ障害」の手順に従ってください。

13.3.4 セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア

セカンダリ・サイトで計画メンテナンスを実行した後、スタンバイ・データベースとログ適用サービスを再起動する必要があり、Data Guard REDOトランスポート・サービスはプライマリ・データベースでスタンバイ・データベースを自動的にキャッチ・アップします。Enterprise Managerとブローカを使用してData Guardの状態を監視できます。

セカンダリ・サイトでの計画済の停止後、またはクラスタ全体の停止後に、次の手順を実行して完全なフォルト・トレランスを回復する必要があります。

注意:
次の手順は、(後述の説明のとおり)手動で実行するか、Enterprise Managerを使用して自動で実行することができます。

1. スタンバイ・データベースを起動します。
スタンバイ・データベースは、ローカル・バックアップ、ローカル・テープ・バックアップまたはプライマリ・サイト・バックアップ(セカンダリ・サイトのデータが破損している場合)からリストアする必要があります。『Oracle Data Guard概要および管理』のスタンバイ・データベースを作成する手順に従って、新規プライマリ・データベースからスタンバイ・データベースを再作成します。

スタンバイ・データベースを再確立したら、スタンバイ・データベースを起動します。

表13-10 スタンバイ・データベースを起動するためのSQL文

スタンバイ・データベースのタイプ

SQL文

フィジカル

STARTUP MOUNT;

ロジカル

STARTUP;

Active Data Guard

STARTUP;

2. REDO Apply(フィジカル・スタンバイ)またはSQL Apply(ロジカル・スタンバイ)を開始します。

表13-11 REDO ApplyおよびSQL Applyを開始するためのSQL文

スタンバイ・データベースのタイプ

SQL文

フィジカル(またはActive Data Guard)

RECOVER MANAGED STANDBY DATABASE DISCONNECT;

ロジカル

ALTER DATABASE START LOGICAL STANDBY APPLY;

3. プライマリ・データベースでREDO転送サービスを検証します。

状況により、プライマリ・データベースのリモート・アーカイブの宛先を再有効化する必要があります。最初にV$ARCHIVE_DEST_STATUSビューを問い合せて、アーカイブの宛先の現在の状態を確認します。

SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR, SRL
FROM V$ARCHIVE_DEST_STATUS;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
ALTER SYSTEM ARCHIVE LOG CURRENT;

エラーをチェックしてプライマリ・データベースとスタンバイ・データベース間のREDO転送サービスを検証します。V$ARCHIVE_DESTビューとV$ARCHIVE_DEST_STATUSビューを問い合せます。

SELECT STATUS, TARGET, LOG_SEQUENCE, TYPE, PROCESS, REGISTER, ERROR
FROM V$ARCHIVE_DEST;
SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS!='INACTIVE';

4. リカバリがスタンバイ・データベースで進行中であることを確認します。

- フィジカル・スタンバイ・データベースの場合、管理リカバリ・プロセスからのエラーがないことと、アーカイブREDOログ・ファイルからREDOが適用されていることを次のように確認します。

SELECT MAX(SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD;
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS
FROM V$MANAGED_STANDBY;

- ロジカル・スタンバイ・データベースの場合、ロジカル・スタンバイ・プロセスからのエラーがないことと、アーカイブREDOログからREDOが適用されていることを次のように確認します。

SELECT THREAD#, SEQUENCE# SEQ#
FROM DBA_LOGSTDBY_LOG LOG, DBA_LOGSTDBY_PROGRESS PROG
WHERE PROG.APPLIED_SCN BETWEEN LOG.FIRST_CHANGE# AND LOG.NEXT_CHANGE#
ORDER BY NEXT_CHANGE#;

5. プライマリ・データベースの保護モードを回復します。
スタンバイ・データベースの停止のために、プライマリ・データベースの保護モードを最大保護モードから最大可用性モードまたは最大パフォーマンス・モードに変更する必要があった場合、ビジネス要件に応じて最大保護モードに戻します。

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE [PROTECTION | AVAILABILITY];

関連項目:
『Oracle Data Guard概要および管理』

13.3.5 スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア

データ障害やメディア障害など、データファイルの完全リストアまたは部分リストアを必要とするスタンバイ・データベースでの計画外の停止後、スタンバイ・データベースが稼働を再開するまで完全なフォルト・トレランスは損われます。データベースの完全保護は、可能なかぎり迅速に回復する必要があります。

ロジカル・スタンバイ・データベース上のデータの破損とデータ障害を修復するには、プライマリ・データベースからのバックアップではなくロジカル・スタンバイ・ファイルのバックアップが必要です。または、破損の影響を受ける関連オブジェクトを回復または再作成する必要があります。スタンバイ・データベースのデータ破損またはデータ障害を修復するには、次の修復ソリューションを使用できます。

- RMANとブロック・メディア・リカバリの使用(13.2.6.3項「RMANとブロック・メディア・リカバリの使用」で説明しました)。

- RMANとデータファイル・メディア・リカバリの使用 (13.2.6.5項「RMANとデータファイル・メディア・リカバリの使用」で説明しました)。

- ロジカル・スタンバイ・データベースのみのオブジェクトの手動再作成(14.2.6.7項「手動によるオブジェクトの再作成」で説明します)。

スタンバイ・データベースの停止のために、プライマリ・データベースの保護モードを最大保護モードから最大可用性モードまたは最大パフォーマンス・モードに変更する必要があった場合、ビジネス要件に応じて最大保護モードに戻します。

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE [PROTECTION | AVAILABILITY];

13.3.6 RESETLOGSによるプライマリ・データベースのオープン後のフォルト・トレランスのリストア

プライマリ・データベースが、論理エラーの修正のためにフラッシュバックされたか、任意の時点にリストアおよびリカバリされてアクティブ化された場合、状況によっては対応するスタンバイ・データベースで追加メンテナンスを実行する必要があります。プライマリ・データベースのリカバリがリセットログ操作なしで完了した場合、追加の作業は必要ありません。

RESETLOGSオプション付きでプライマリ・データベースをオープンした後に、表13-12の問合せを実行します。

表13-12 RESETLOGS SCNと現在のSCN OPEN RESETLOGSを確認するための問合せ

データベース

問合せ

プライマリ

SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;

フィジカル・スタンバイ

SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;

ロジカル・スタンバイ

SELECT APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;

表13-13に、スタンバイ・データベースがプライマリ・データベースのリセットログSCNより遅れている場合に、フォルト・トレランスを回復するために実行できるアクションを示します。

表13-13 スタンバイ・データベースのSCNがプライマリ・データベースのRESETLOGS SCNより遅れている場合のアクション

データベース

アクション

フィジカル・スタンバイ

1. スタンバイ・データベースがプライマリ・データベースからアーカイブREDOログ・ファイルを受信していることを確認します。
関連項目: プライマリ・データベースでREDO転送サービスを検証する手順

2. REDO Applyを再開します。

ロジカル・スタンバイ

スタンバイ・データベースがプライマリ・データベースからアーカイブREDOログ・ファイルを受信していることを確認します。

関連項目: プライマリ・データベースでREDO転送サービスを検証する手順

表13-14に、スタンバイ・データベースがプライマリ・データベースのリセットログSCNより進んでいる場合に、フォルト・トレランスを回復するために実行できるアクションを示します。

表13-14 スタンバイ・データベースのSCNがプライマリ・データベースのリセットログSCNより進んでいる場合のアクション

データベース

アクション

フィジカル・スタンバイ

1. スタンバイ・データベースがプライマリ・データベースからアーカイブREDOログ・ファイルを受信していることを確認します。
関連項目: プライマリ・データベースでREDO転送サービスを検証する手順

2. 必要に応じてSHUTDOWN IMMEDIATE文を発行します。

3. STARTUP MOUNT文を発行します。

4. FLASHBACK DATABASE TO SCN flashback_scn文を発行します(flashback_scnは、表13-12のプライマリ・データベース問合せから返されたSCNです)。プライマリ・データベース問合せから返されるSCNはRESETLOGS_CHANGE#-2です。
FLASHBACK DATABASE TO SCN resetlogs_change#_minus_2文を発行します。

5. リアルタイム適用を指定するか、または指定せずにREDO Applyを再開します。
リアルタイム適用を指定する場合:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

リアルタイム適用を指定しない場合:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

ロジカル・スタンバイ

1. プライマリ・データベースのSCNを特定します。
プライマリ・データベースで、次の問合せを使用して、プライマリ・データベースでRESETLOGS操作が発生した時点より2つ前のシステム変更番号(SCN)に相当するSCNの値を取得します。

SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) AS FLASHBACK_SCN FROM V$DATABASE;

2. ロジカル・スタンバイ・データベースでフラッシュバック操作のターゲットSCNを特定します。

SQL> SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN => FLASHBACK_SCN)2> AS TARGET_SCN FROM DUAL;

3. ロジカル・スタンバイ・データベースを、戻されたTARGET_SCNまでフラッシュバックします。
次のSQL文を発行して、ロジカル・スタンバイ・データベースを指定のSCNまでフラッシュバックし、RESETLOGSオプション付きでロジカル・スタンバイ・データベースをオープンします。

SQL> SHUTDOWN;
SQL> STARTUP MOUNT EXCLUSIVE;
SQL> FLASHBACK DATABASE TO SCN TARGET_SCN;
SQL> ALTER DATABASE OPEN RESETLOGS;

4. SQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

13.3.7 二重障害後のフォルト・トレランスのリストア

スタンバイ・データベースとプライマリ・データベースの両方に影響する二重障害が発生した場合、先にプライマリ・データベースを再作成する必要があります。各サイトは同一であるため、最新のバックアップが存在する場所であればどこでもプライマリ・データベースを作成できます。

表13-15に、使用可能なバックアップのタイプに応じたリカバリ計画をまとめます。

表13-15 プライマリ・データベースとスタンバイ・データベースの再作成

使用可能なバックアップ

プライマリ・データベースの再作成

プライマリ・データベースとスタンバイ・データベースのローカル・バックアップ

プライマリ・データベースのバックアップをリストアします。データベースをリカバリして新規プライマリ・データベースとしてアクティブ化します。

スタンバイ・データベースにのみ存在するローカル・バックアップ。スタンバイ・データベースのテープ・バックアップ。

スタンバイ・データベースのローカル・バックアップをスタンバイ・データベースにリストアします。データベースをリカバリして新規プライマリ・データベースとしてアクティブ化します。

テープ・バックアップのみ

テープ・バックアップをローカルでリストアします。データベースをリカバリして新規プライマリ・データベースとしてアクティブ化します。

関連項目:
プライマリ・データベースを再作成した後のスタンバイ・データベースの作成手順は、『Oracle Data Guard概要および管理』を参照してください。

14 計画メンテナンスの停止時間の短縮

この章では、計画済の停止について説明します。また、各停止タイプを許容するか管理することで停止時間を最小化できるOracle運用ベスト・プラクティスについて説明します。

この章には、次の項目が含まれます。

- 計画済の停止の概要

- 計画済の停止による停止時間の回避または短縮

関連項目:
計画外の停止の詳細は、第13章「計画外の停止からのリカバリ」を参照してください。

14.1 計画済の停止の概要

計画済の停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャの定期メンテナンスのために必要です。これには、次のタスクが含まれます。

- ハードウェアのメンテナンス、修復およびアップグレード

- ソフトウェアのアップグレードとパッチ適用

- アプリケーションの(プログラム的な)変更、パッチおよびアップグレード

- システムのパフォーマンスと管理性を向上するための変更

これらの作業の多くは、アプリケーションの可用性を連続的に維持したまま、実装することができます。

次の各項では、プライマリ・サイトとセカンダリ・サイトでの計画済の停止を削減するための推奨ベスト・プラクティスについて説明します。

- プライマリ・サイトでの計画済の停止の管理

- セカンダリ・サイトでの計画済の停止の管理

14.1.1 プライマリ・サイトでの計画済の停止の管理

表14-1に、プライマリ・サイトで計画済の停止を実行するための適切なソリューションを示します。この表には、14.2項「計画済の停止による停止時間の回避または短縮」の詳細な説明へのリンクが含まれます。

表14-1 プライマリ・サイトでの計画済の停止のソリューション

計画済のメンテナンス

説明および例

優先されるOracleソリューション

停止時間見積り

サイト・メンテナンス

プライマリ・データベースが現在使用不能になっているサイト全体で実行されるメンテナンスです。通常は、事前に広く通知されます。

- 計画済の停電

- サイト・メンテナンス

- テスト・インフラストラクチャへの定期的な計画済のスイッチオーバー

14.2.1項 「データベース・スイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス」

5分未満

データベース・クラスタ全体に影響するハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンス

データベース・サーバー・クラスタでのハードウェア・メンテナンスです。

- クラスタ・インターコネクトのアップグレード

- データベース層の停止を必要とするストレージ層のアップグレード

14.2.1項 「データベース・スイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス」

5分未満

データベース・クラスタのサブセットに影響するハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンス

データベース・サーバーでのハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンスです。停止時間の範囲は、データベース・クラスタの1つのノードに制限されます。

- RAIDカード・バッテリの予防的な交換

- データベース層の既存のノードへのメモリーまたはCPUの追加

- オペレーティング・システムなどのソフトウェア・コンポーネントのアップグレード

- オペレーティング・システムの構成パラメータの変更

Oracle RACサービスの再配置(14.2.11項「システム・メンテナンスのための自動ワークロード管理」)

停止時間なし

Oracle Grid Infrastructureアップグレードへのパッチ・セット、メンテナンスまたはメジャー・アップグレードの実行(Oracle ClusterwareとOracle ASMを含む)

Grid Infrastructureのソフトウェア・メンテナンスです。

- 11gリリース2 (11.2.0.1)から11gリリース2 (11.2.0.2)パッチ・セット1へのGridのパッチ・セット・アップグレード

- 11gリリース1から11gリリース2へのメンテナンス・リリース・アップグレード

- 10gから11gへのメジャー・リリース・アップグレード

- 14.2.5項「Grid Infrastructureのメンテナンス」
または

- 14.2.1項 「データベース・スイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス」
または

- 14.2.3項「Data Guard Standby-First Patchの適用」

詳細は、『Oracle Database 2日でReal Application Clustersガイド』、およびプラットフォーム固有の『Oracle Grid Infrastructureインストレーション・ガイド』のOracle Grid Infrastructureのアップグレード方法に関する付録を参照してください。

停止時間なし

5分未満

停止時間なし(ロール移行がないか、ロール移行が行われる場合は5分未満の場合)

Oracle Databaseへのパッチ・セット、メンテナンスまたはメジャー・アップグレードの実行

Oracle Databaseのソフトウェア・メンテナンスです。

- 11gリリース2 (11.2.0.1)から11gリリース2 (11.2.0.2)パッチ・セット1へのGridのパッチ・セット・アップグレード

- 11gリリース1から11gリリース2へのメンテナンス・リリース・アップグレード

- 10gから11gへのメジャー・リリース・アップグレード

- Data Guard SQL Applyを使用したOracle Databaseローリング・アップグレード(14.2.6.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード」を参照)
または

- Oracle GoldenGate(14.2.6.3項「Oracle GoldenGateを使用したアップグレード」を参照)

5分未満

パッチ・セット更新(PSU)、クリティカル・パッチ・アップデート(CPU)またはパッチ・バンドルの適用

Grid InfrastructureまたはOracle Databaseのソフトウェア・メンテナンスです。

- パッチ・セット更新11.2.0.2.3のインストール

- 11.2.0.2 Grid Infrastructureバンドル1のインストール

- クリティカル・パッチ・アップデート2011年7月のインストール

- Exadata Databaseバンドル・パッチ8のインストール

- OPatchを使用したOracle RACローリング・パッチ・アップグレード(14.2.4項「Oracle RACパッチ」を参照)
または

- 14.2.3項「Data Guard Standby-First Patchの適用」

停止時間なし

停止時間なし(ロール移行がないか、ロール移行が行われる場合は5分未満の場合)

Oracle個別パッチまたは診断パッチの適用

特定の顧客問題を修正するためのOracleソフトウェアへのパッチ適用。

- パッチ10205230のインストール

- OPatchを使用したOracle RACローリング・パッチ・アップグレード(14.2.4項「Oracle RACパッチ」を参照)
または

- 14.2.3項「Data Guard Standby-First Patchの適用」
または

- 14.2.2項「オンライン・パッチ」

停止時間なし

停止時間なし(ロール移行がないか、ロール移行が行われる場合は5分未満の場合)

停止時間なし

データベース・オブジェクトの再編成または再定義

主にパフォーマンスや管理性を向上する目的で、Oracleデータベース・オブジェクトの論理構造または物理編成を変更します。

データまたはスキーマの変更です。

Oracleデータベースのオンライン再定義機能を使用すると、再編成または再定義中にオブジェクトを使用できます。

- 異なる表領域へのオブジェクトの移動

- パーティション表への表の変換

- 表またはクラスタの1つ以上の列の追加、変更、または削除

DBMS_REDEFINITIONを使用したオンライン・オブジェクト再編成(14.2.10項「データの再編成と再定義」を参照)

停止時間なし

データベース・ストレージ・メンテナンス

データベース・ファイルが存在するストレージのメンテナンスです。

- Oracle ASMへの変換

- ストレージの追加または削除

- ストレージ・ファームウェアまたはソフトウェアのパッチ適用またはアップグレード

Oracle ASMを使用したオンライン・ストレージ・メンテナンス(14.2.5.2項「ストレージ・メンテナンス」を参照)

停止時間なし

データベースのプラットフォームまたはロケーションの移行

プライマリ・データベースとスタンバイ・データベースのオペレーティング・システム・プラットフォームを変更します。

プライマリ・データベースの物理的な場所を変更します。

- Linuxオペレーティング・システムへの移行

- あるデータ・センターから別のデータ・センターへのプライマリ・データベースの移行

14.2.7項「データベースのプラットフォームまたはロケーションの移行」

5分未満から数時間

(選択した方法に依存)

アプリケーションの変更

データ変更、スキーマおよびその他のプログラム的な変更が含まれます。

- アプリケーション・アップグレード

- 14.2.8項「オンライン・アプリケーション・メンテナンスおよびアップグレードのエディションベースの再定義」
または

- 14.2.6.3項「Oracle GoldenGateを使用したアップグレード」

5分未満

14.1.2 セカンダリ・サイトでの計画済の停止の管理

セカンダリ・サイトの計画済の停止は、Active Data Guardを使用して読取り中心の作業をプライマリ・データベースからオフロードするアプリケーションの可用性に影響することがあります。セカンダリ・サイトで停止が発生したときにプライマリ・サイトで同時障害が発生すると、RTOおよびRPOに影響する可能性があります。セカンダリ・サイトの停止は、プライマリ・データベースの可用性に影響を与えずに管理できます。

- 最大保護データベース・モードで構成しており、プライマリ・データベースを保護するスタンバイ・データベースが1つのみの場合、プライマリ・データベースで停止時間が発生しないように、スタンバイ・インスタンスまたはデータベースで計画済の停止を実行する前に保護モードをダウングレードする必要があります。

- 最大保護データベース・モードで構成されていて、複数のスタンバイ・データベースが存在する場合、LGWR SYNC AFFIRM属性で構成された1つ以上のスタンバイ・データベースが利用でき、それプライマリ・データベースがREDOデータを転送できるかぎり、保護モードをダウングレードする必要はありません。

セカンダリ・サイトのメンテナンスをスケジュールする場合、サイト全体またはクラスタ全体の停止期間が増加するほどスタンバイ・データベースとプライマリ・データベースの差異が拡大し、それによりフォルト・トレランスを回復するための時間も増加することに注意してください。Data Guard保護モードの概要は、9.2項「保護モードとData Guardトランスポートの決定」を参照してください。

表14-2に、セカンダリ・サイトで計画済の停止を実行するための手順をまとめます。

表14-2 セカンダリ・サイトでの計画済の停止の管理

計画済のメンテナンス

Data Guardを使用したOracle Database 11g

Oracle Database 11g(MAA)

サイト停止

停止前:

14.1.2項「セカンダリ・サイトでの計画済の停止の管理」

停止後:

13.3.4項「セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア」

停止前:

14.1.2項「セカンダリ・サイトでの計画済の停止の管理」

停止後:

13.3.4項「セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア」

管理リカバリ・プロセス(MRP)を実行しているノードでのハードウェアまたはOracle以外のデータベース・ソフトウェアのメンテナンス

停止前:

14.1.2項「セカンダリ・サイトでの計画済の停止の管理」

停止前:

14.1.2項「セカンダリ・サイトでの計画済の停止の管理」

MRPを実行していないノードでのハードウェアまたはOracle以外のデータベース・ソフトウェアのメンテナンス

適用なし

プライマリ・スタンバイ・ノードまたはインスタンスは、管理リカバリ・プロセスで適用されるREDOログを受信するため、影響はありません。

停止後: 使用可能になったら、ノードとインスタンスを再起動します。

ハードウェアまたはOracle以外のデータベース・ソフトウェアのメンテナンス(クラスタ全体に影響)

適用なし

停止前:

14.1.2項「セカンダリ・サイトでの計画済の停止の管理」

停止後:

13.3.4項「セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア」

Oracleパッチとソフトウェアのアップグレード

アップグレードのために停止時間が必要ですが、構成が最大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。

アップグレードのために停止時間が必要ですが、構成が最大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。

14.2 計画済の停止による停止時間の回避または短縮

計画済の停止の停止時間を回避または短縮するためのベスト・プラクティスには、次の項があります。

- データベース・スイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス

- オンライン・パッチ

- Data Guard Standby-First Patchの適用

- Oracle RACパッチ

- ストレージ・メンテナンス

- データベース・アップグレード

- データベースのプラットフォームまたはロケーションの移行

- オンライン・アプリケーション・メンテナンスおよびアップグレードのエディションベースの再定義

- オンライン・アプリケーション・アップグレードでのOracle GoldenGate

- データの再編成と再定義

- システム・メンテナンスのための自動ワークロード管理

システムへの更新を実行する前に、入念なテストを実行することをお薦めします。

14.2.1 データベース・スイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス

スイッチオーバーは、プライマリ・データベースとスタンバイ・データベース間のデータベース・ロールを切り替える一連の手順を含む計画済の移行です。スイッチオーバー操作に成功すると、スタンバイ・データベースがプライマリ・ロールを引き継ぎ、プライマリ・データベースがスタンバイ・データベースとなります。データベース・スイッチオーバーは、Oracle Enterprise ManagerまたはOracle Data Guardブローカによって、あるいはSQL*Plus文を発行することで実行できます。データベース・ロール管理のスコープでは、スイッチバックという用語も使用されることがあります。スイッチバックは、スイッチオーバー操作の後にスタンバイ・データベースを元のロールに戻す操作です。

スイッチオーバーは、サイト・メンテナンス、およびハードウェアやソフトウェアのメンテナンス(データベース・アップグレードなど)を実行するとき、多くの状況で便利です。

14.2.1.1 Data Guardスイッチオーバーを実行する時期

プライマリ・データベースが起動しており、ターゲット・スタンバイ・データベースが使用可能で、すべてのアーカイブREDOログが使用できる場合、いつでもスイッチオーバーを実行できます。

スイッチオーバーは、次のような状況で役立ちます。

- 計画されたメンテナンス(プライマリ・ホストでのハードウェア・メンテナンスやファームウェア・パッチ適用など)

- プライマリ・データベースをオープンしたままでのデータ障害の解決

- セカンダリ・リソースのテストと検証(障害時リカバリの準備状況をテストする手段として)

- SQL Applyを使用したローリング・アップグレードの実行(14.2.6.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード」を参照)

スイッチオーバーは、次の場合には使用できないか、または効果がありません。

- 適用に必要なアーカイブREDOログ・ファイルがない場合

- ポイント・イン・タイム・リカバリが必要な場合

- プライマリ・データベースがオープンしておらず、オープンできない場合

14.2.1.2 Data Guardスイッチオーバーを構成するためのベスト・プラクティス

スイッチオーバーを実行する前に、Data Guard構成のベスト・プラクティスを採用します。詳細は、9.4.1項「Oracle Data Guardスイッチオーバーのベスト・プラクティス」を参照してください。

14.2.1.3 Data Guardスイッチオーバーの実行方法

Oracle Enterprise Managerを使用して、動的にスイッチオーバーを実行することをお薦めします。Oracle Enterprise Managerを使用していない場合、DGMGRLコマンドライン・インタフェースまたはSQL*Plus文を使用して、手動でスイッチオーバーを実行することができます。

- Oracle Enterprise Managerの使用(『Oracle Data Guard Broker』を参照)

- DGMGRLコマンドライン・インタフェースの使用(『Oracle Data Guard Broker』を参照)

- SQL*Plusの使用

- フィジカル・スタンバイ・データベースが関与するロールの推移:
フィジカル・スタンバイ・データベースが関与するロール移行の詳細な手順は、『Oracle Data Guard概要および管理』を参照してください。

- ロジカル・スタンバイ・データベースが関与するロールの推移:
ロジカル・スタンバイ・データベースが関与するロール移行の詳細な手順は、『Oracle Data Guard概要および管理』を参照してください。

Data Guardスイッチオーバーの実行後に、次の操作を行います。

- データベースがセカンダリ・サイトに移動され、アプリケーション層もセカンダリ・サイトに移動される場合は、完全サイト・フェイルオーバーを実行します。詳細は、13.2.1項「サイト・フェイルオーバーの完了(セカンダリ・サイトへのフェイルオーバー)」を参照してください。

- データベースのみがセカンダリ・サイトに移動される場合は、アプリケーション・フェイルオーバーを実行します。詳細は、13.2.4項「アプリケーション・フェイルオーバー」を参照してください。

14.2.2 オンライン・パッチ

Oracle Database 11gからは、一部の認定個別パッチおよび診断パッチにオンライン・パッチがサポートされます。オンライン・パッチは、インスタンスを停止しないでOracleインスタンスのプロセスにパッチを当てる機能です。インスタンスに関連付けられる各プロセスは、安全実行点でパッチを適用したコードをチェックし、続いてそのコードをプロセス空き領域にコピーします。このように、パッチを適用したプロセスは、正確に同じ時間に新しいコードを取り上げるわけではありません。

従来のパッチとオンライン・パッチの主要な違いは、従来のパッチがソフトウェア・レベルで実装され、オンライン・パッチがソフトウェアまたはOracle Databaseインスタンス・レベルで実装されるということです。つまり、従来のパッチを受信するORACLE_HOMEを使用するインスタンスは常にパッチが適用されたコードを受信するのに対して、オンライン・パッチを受信するORACLE_HOMEを受信するインスタンスがパッチを適用されたコードを受信するのは、パッチが適用されるときにそのインスタンスが指定されていた場合のみです。

注意:
オンライン・パッチでは、次の点に注意してください。

- パッチでオンライン・インストールがサポートされるかどうかの詳細は、パッチのREADMEを参照してください。

オンライン・パッチのベスト・プラクティス:

- 次の計画メンテナンス中に、インスタンスを停止できる場合は、すべてのオンライン・パッチをロールバックし、オフライン方式でパッチを適用します。

- パッチを緊急に適用する必要があり、パッチを適用する停止時間を確保できない場合は、オンラインでインストール可能なパッチをオンライン方式でインストールする必要があります。インスタンスの停止時間を許容できる場合は、(パッチのREADMEの説明に従って)オフライン方式でパッチを適用します。

- パッチは一度に1つのインスタンスに適用します。

- オンライン・パッチをロールバックする場合は、パッチが適用されたすべてのインスタンスが含まれていることを確認して、同じ$ORACLE_HOMEを使用する複数インスタンスにわたって異なるソフトウェアがあるような、危険で混乱した状況を回避します。

- 本番環境にデプロイする前に、テスト・システムへのメモリーの影響を評価します(例: pmapコマンドの使用)。

- $ORACLE_HOME/hpatchディレクトリは決して削除しないでください。

関連項目:

- OPatchを使用したOracleソフトウェアのパッチ適用の詳細は、Oracle Universal InstallerおよびOpatchのユーザーズ・ガイドを参照してください。

- オンライン・パッチ、インストールおよびロールバックの最新情報は、次の場所にあるMy Oracle Supportのノート761111.1の『RDBMS Online Patching - Hot Patching』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=761111.1

14.2.3 Data Guard Standby-First Patchの適用

Oracle Data Guard Standby-First Patchの適用は、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるソフトウェア・リリースをサポートして、本番データベースへのリスクが低いローリング方法でOracleパッチを適用および検証します。Oracle Data Guard Standby-First Patchの適用は、Oracle Database Enterprise Editionリリース2 (11.2)リリース11.2.0.1以降の認定ソフトウェア・パッチでサポートされます。ターゲット・パッチがStandby-First Patchとして認定されているかどうかを判断するには、パッチのREADMEを参照してください。

Oracle Database COMPATIBLE初期化パラメータ値は、プライマリ・システムとフィジカル・スタンバイ・システム間で同じままである必要があります。

既存のデータベースまたはOracle Grid Infrastructureソフトウェア・リリースに依存しないすべてのOracle Exadata Storage Serverソフトウェアの変更が適用されます。

プライマリ・システムとフィジカル・スタンバイ・システム間の相互運用性を中断する可能性のあるソフトウェア変更、またはすべてのSQLコード変更は適用できません。

Oracle Data Guard Standby-First Patchの適用は、プライマリ・データベースを前のソフトウェア・リリースにしたまま、最初にフィジカル・スタンバイ・データベースにパッチを適用する方法をサポートします。

スタンバイ・データベースがプライマリ・データベースから完全に切り離されている(つまり、ストレージ、ネットワークまたはクラスタ・コンポーネントを共有しない)場合は、次の操作を実行します。

- データベース・ホームに適用される認定Oracleパッチをまずスタンバイ・データベースに適用し、テストできます。このカテゴリのOracleデータベース・ソフトウェアの例を次に示します。

- Exadata Databaseバンドル・パッチ

- パッチ・セット更新(PSU)

- クリティカル・パッチ・アップデート(CPU)

- 個別パッチ

- その他のOracleまたはシステム・ソフトウェアは、まずスタンバイ・データベースに適用し、テストできます。このカテゴリのソフトウェアの例を次に示します。

- グリッド・ホームに適用されるOracleパッチ

- オペレーティング・システム・パッチおよびファームウェア

- ストレージ・パッチ

- ネットワーク・パッチ

スタンバイ・データベースがプライマリ・データベースとインフラストラクチャまたはサーバー・コンポーネントを共有する場合は、プライマリ・データベースへのリスクを軽減する方法で共有コンポーネントへのパッチを評価することはできません。たとえば、プライマリ・データベースとは別のクラスタで実行されているスタンバイ・データベースがあり、それがプライマリ・データベースと同じストレージ・グリッドを共有する場合は、プライマリ・データベースに影響を与えずにスタンバイ・ストレージに最初にパッチを適用することはできません。

次に、Oracle Data Guard Standby-First Patchの適用の利点を示します。

- ロール移行の前、またはプライマリ本番データベースへの適用前に、リカバリ、バックアップまたは問合せ検証のためにフィジカル・スタンバイ・データベースにソフトウェア変更を適用する機能。これにより、本番データベースでのリスクと潜在的な停止時間が軽減されます。

- リストを軽減し、停止時間を最小限に抑えて検証を完了した後で、ターゲット・データベースにスイッチオーバーする機能。

- 安定性やパフォーマンスが大きく低下している場合に、スイッチバック(フォールバックとも呼ぶ)を行う機能。

Oracleパッチ・セットとメジャー・リリース・アップグレードは適用されません。パッチ・セットとメジャー・リリースにはData Guardの一時ロジカル・スタンバイ手法を使用します。詳細は、14.2.6.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード」を参照してください。

関連項目:

- ダウングレードと互換性の考慮事項、およびOracle DatabaseのCOMPATIBLEパラメータの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

- ディスク・グループの互換性属性の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- 次のWebサイトのMy Oracle Support Note 1265700.1の『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1

14.2.4 Oracle RACパッチ

Oracle RACでは、特定のデータベース・パッチをノードまたはインスタンスごとに適用できるため、アプリケーションとデータベースを継続的に使用できます。データベース・ソフトウェア用の個別パッチ、パッチ・セット更新(PSU)およびクリティカル・パッチ・アップデート(CPU)を適用するのは、通常、インストール環境で発生したソフトウェア問題の既知の修正策を実装する場合か、問題に関する情報を収集するための診断パッチを適用する場合です。このようなパッチ適用は、一般的に、計画された停止期間中のメンテナンスで実行されます。

Oracleでは、データベースをまったく停止しないか、最小限の停止時間でOracle RACのローリング・パッチ・アップグレードを実行できます。この操作を行うためのツールは、opatchコマンドライン・ユーティリティです。

Oracle RACローリング・アップグレードのメリットは、パッチ・アップグレードに必要とされる計画済の停止期間中でも、Oracle RACインストール環境の一部のインスタンスを使用できることです。停止する必要があるのは、現在パッチを適用中のOracle RACインスタンスのみです。その他のインスタンスは、引き続き使用できます。これにより、このような計画済の停止に必要とされるアプリケーションの停止時間に対する影響を最小限に抑えることができます。Oracleのopatchユーティリティでは、Oracle RACインストール環境の異なるインスタンスに対して連続的にパッチを適用できます。

ローリング・アップグレード機能は、オラクル社がローリング・アップグレードに適切であると認定したパッチでのみ使用できます。パッチのREADMEファイルは、パッチをOracle RACローリング方式で適用できるかどうかを示します。一般に、ローリング方式でインストール可能なパッチは次のとおりです。

- Exadata Databaseバンドル・パッチ

- パッチ・セット更新(PSU)

- クリティカル・パッチ・アップデート(CPU)

- 個別パッチ

- 診断パッチ

パッチのローリング・アップグレードは、現在個別パッチでのみ使用可能です。ローリング・アップグレードは、パッチ・セットには使用できません。

ローリング・パッチ・アップグレードは、Oracleデータベース・ソフトウェアが異なるノード間で共有されるデプロイメントでは使用できません。これに該当するのは、クラスタ・ファイル・システム(CFS)上、またはファイル・サーバーやNFSマウント・ドライブにより提供される共有ボリューム上にOracleホームが存在する場合です。この機能を使用できるのは、各ノードがOracleデータベース・ソフトウェアの独自のコピーを所有している場合のみです。

14.2.4.1 すべてのデータベース・パッチ・アップグレードで停止時間を最小にするためのベスト・プラクティス

すべてのデータベース・パッチ・アップグレードで、次の推奨プラクティスを使用します。

- Oracleサポート・サービスに連絡して、パッチが現在の問題とデプロイメント環境に有効であることを必ず確認します。

- パッチを適用する計画とともに、パッチをバック・アウトする計画を作成します。

- パッチは先にテスト環境に適用し、問題が修正されることを確認します。

- パッチを適用する際の所要時間を見積もる場合、必要に応じてテクノロジ・スタックの他の層を起動および停止する時間も含めます。

- パッチがOracle RACローリング・アップグレードに適しておらず、パッチの適用時に停止時間が発生する可能性がある場合、14.2.6項「データベース・アップグレード」を参照して他の解決方法を実行できないかどうかを検討します。

14.2.4.2 データベースのローリング・アップグレードで停止時間を最小にするためのベスト・プラクティス

次に、Oracle RACローリング・アップグレードの追加の推奨プラクティスを示します。

- 複数のインスタンスでOracleホームを共有している場合、それらすべてのインスタンスがパッチの適用により影響を受けます。管理者は、これにより意図しない別の問題が発生しないことを確認する必要があります。また、パッチの適用中は、ノード上のこのようなインスタンスをすべて停止する必要があります。計画済の停止を計画する場合、そのことを考慮する必要があります。ベスト・プラクティスとしては、類似するアプリケーションのみでノード上のOracleホームを共有します。これにより、パッチ適用の柔軟性が向上します。

- 各ノードのOracleインベントリは、インストールされているすべてのOracleソフトウェアの中央インベントリを保持するリポジトリです。インベントリは、各ノードに固有です。インベントリは、ノードにインストールされているすべてのOracleソフトウェアにより共有されます。このインベントリがノード間で類似するのは、デプロイされているOracleデータベース・ソフトウェア、デプロイメント構成およびパッチ・レベルに関してすべてのノードが同じである場合のみです。Oracleインベントリは、パッチ適用およびパッチ管理プロセスに非常に役立つため、その整合性を維持することをお薦めします。Oracleインベントリは、特定のノードのOracleソフトウェアにパッチをインストールするたびにバックアップする必要があります。この原則は、クラスタの各ノードのOracleインベントリに適用されます。

- Oracle Universal Installerを使用してすべてのOracleデータベース・ソフトウェアをインストールします。これにより、関連するリポジトリ・エントリがクラスタの各ノードのOracleインベントリに作成されます。また、既存のOracle RACクラスタにノードを追加する場合もOracle Universal Installerを使用します。
ただし、この操作を実行していない場合や、なんらかの理由で実行できない場合、opatchユーティリティのattachオプションを使用して、既存のOracleデータベース・ソフトウェア・インストールに関する情報をOracleインベントリに追加できます。ノード情報もこのオプションで追加できます。

- Oracleローリング・パッチ・アップグレードでは、その性質上、パッチをOracle RACクラスタの一部のノードにのみ適用できます。そのため、パッチの適用されているインスタンスと、パッチの適用されていないインスタンスが同時に稼働することになります。この状態は、ローリング・パッチ・アップグレード以外の方法では発生しません。Oracle RACデプロイをアクティブ化する前であれば、ローリング・パッチ・アップグレード以外の方法ですべてのインスタンスにパッチを適用します。パッチをすべてのインスタンスにデプロイする前にテストする必要がある場合、混在環境は役立ちます。これを実現するのに推奨される方法は、-localオプション付きでパッチを適用することです。
Oracle RACクラスタのすべてのインスタンスを同じパッチ・レベルで維持するため、検証の完了したパッチは、Oracle RACインストール環境のすべてのノードに適用することを強くお薦めします。Oracle RACクラスタの各インスタンスが同じパッチ・ソフトウェアを維持している場合、パッチの修正対象である問題を発生させることなくインスタンス間でサービスを移行できます。

- すべてのパッチ(ローリング・アップグレードにより適用されるパッチを含む)は、オンラインで管理し、適用後も削除しないようにします。パッチを保存しておくと、パッチをロールバックまたは再適用する場合に役立ちます。
パッチは、クラスタのすべてのノードからアクセスできる場所に保存します。これにより、クラスタのすべてのノードで、同じようにパッチを適用またはロールバックできます。

- ローリング・パッチ・アップグレードは、他の任意のパッチ・アップグレードと同様に、ノードで別のパッチ・アップグレードまたはOracleインストールが行われていない場合に実行します。複数のパッチの適用は、順次処理するため、計画済の停止はあらかじめそれに応じて計画します。

- 複数のパッチを同時に適用する必要があるが、ローリング・アップグレードできるパッチがその一部のみである場合は、すべてのパッチをローリング・アップグレードでない方式で適用します。これにより、パッチ適用プロセスの完了に必要とされる合計時間を短縮できます。

- ローリング・アップグレードに適さないパッチの場合、Oracle RACデプロイ用として次に適切なオプションは、APPLYコマンドのMINIMIZE_DOWNTIMEオプションです。

- ローリング・アップグレードを実行するのは、システム使用率が低く、エンド・ユーザーへのサービス中断の影響を最小にできるのが確実であるときです。

関連項目:
opatchユーティリティの詳細は、『Oracle Universal InstallerおよびOpatchユーザーズ・ガイド for Microsoft Windows and UNIX Systems』を参照してください。

14.2.4.3 ホーム外ソフトウェアのインストールとパッチ適用

次のソフトウェアのインストールは、デフォルトでOracle Universal Installer (OUI)によりホーム外で実行されます。OUIによって実行されるソフトウェア・インストールは、完全ソフトウェア・インストールです。

- メジャー・リリース

- メンテナンス・リリース

- パッチ・セット(11gリリース2以降)

次のソフトウェアのインストールは、OPatchユーティリティによりインプレースで実行されます。OPatchは、インストールされるパッチの更新ソフトウェアで既存のソフトウェアを上書きすることにより、ソフトウェア更新を既存のORACLE_HOMEにインストールします。

- 個別パッチのインストール

- バンドル・パッチのインストール

- パッチ・セット更新(PSU)のインストール

- クリティカル・パッチ・アップデート(CPU)のインストール

- 診断パッチのインストール

ホーム外パッチ適用の利点

- 新規ORACLE_HOMEでのソフトウェアのアップグレード中も、引き続きアプリケーションを使用できます。

- クローニング手順にはソフトウェアの物理的なコピー操作が含まれるため、ORACLE_HOME内の構成は保持されます(たとえば、LISTENER.ORA、TNSNAMES.ORA、INITSID.ORAなどのファイル)。

- 元のORACLE_HOMEとパッチを適用したORACLE_HOME間でロールバックまたはテストする方が簡単です。

- 統合する場合、複数のバージョンのORACLE_HOMEを持つことができるため、このオプションでは統合のサポートが向上します。

ホーム外パッチ適用の使用上の考慮事項

- クローニングによるホーム外パッチ・インストールを実行する場合、アプリケーション・コードおよびOracle固有のスクリプトにハードコードされているORACLE_HOME環境変数をすべて変更する必要があります。

- ホーム外パッチ適用には、インプレース・パッチ適用よりも多くのディスク領域が必要です。

OPatchを使用したホーム外パッチ適用

従来、OPatchでインストールされるパッチはインプレースで行われるため、新しいコードは古いコードに直接適用されます。

インプレース・パッチの短所は次のとおりです。

- 新しいコードのインストール中は、アプリケーションはデータベースに接続できません。

- パッチ・ロールバックが必要な場合、古いコードの再インストール中はアプリケーションがデータベースに接続できません。

注意:
インプレース・データベース・パッチ・セット・アップグレードのこの短所は、Standby-First Patch Applyを使用する場合には適用されません。
詳細は、14.2.3項「Data Guard Standby-First Patchの適用」を参照してください。

OPatchによって実行されるOracle Databaseソフトウェア・ホームまたはGrid Infrastructureソフトウェア・ホームへのソフトウェアのインストールは、OPatchを使用して新しいORACLE_HOMEにパッチを適用する前にORACLE_HOMEクローニング手法を使用して新しいホーム・ディレクトリにソフトウェアをコピーすることにより、ホーム外で実行できます。ホーム外パッチ適用を実行する高レベルのアプローチは次のとおりです。

1. アクティブなORACLE_HOMEを新しいORACLE_HOMEにクローニングします。

2. 新しいORACLE_HOMEにパッチを適用します。

3. 新しいORACLE_HOMEをアクティブなソフトウェア・ホームに切り替えます。この操作は、一度に1ノードずつローリング方式で実行できます。

関連項目:
ホーム外パッチ適用の詳細は、次の場所にあるMy Oracle Supportのノート1136544.1の『Minimal downtime patching via cloning 11gR2 ORACLE_HOME directories on Oracle Database Machine』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1136544.1

14.2.4.4 OPlanを使用したパッチ適用

OPlanは、インプレース・パッチ・インストールとホーム外パッチ・インストールの両方について、環境に固有のパッチ適用の手順を示すことで、パッチのインストール・プロセスを容易にするユーティリティです。現在、OPlanはExadata Databaseバンドル・パッチでサポートされます。最新情報は、次の場所にあるMy Oracle Supportのノート1306814.1の『Oracle Software Patching with OPLAN』を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1306814.1

14.2.5 Grid Infrastructureのメンテナンス

Oracle Database 11gリリース2 (11.2)以降では、Oracle ASMはOracle Grid Infrastructureコンポーネントをインストールするときにインストールされ、Oracle RACなどとともにクラスタにインストールされたときにOracle ClusterwareとOracleホームを共有します。Grid Infrastructureでパッチ適用やアップグレードなどのメンテナンスを実行する場合、Oracle ASMとOracle Clusterwareの両方に影響します。

14.2.5.1 Grid Infrastructureのローリング・アップグレード

Grid Infrastructureのアップグレードは、Oracle ClusterwareとOracle ASMを新しいメジャー・バージョン、メンテナンス・バージョンまたはパッチ・セットにすることを意味します。Grid Infrastructureのアップグレードは、ローリング方式で実行されます。

関連項目:
『Oracle Database 2日でReal Application Clustersガイド』
詳細は、プラットフォームに固有の『Oracle Grid Infrastructureインストレーション・ガイド』でOracle Grid Infrastructureのアップグレード方法に関する付録を参照してください。

14.2.5.2 ストレージ・メンテナンス

システム上にストレージを追加したり、アップグレードしたりするときは、次の手順を使用します。次の各項の手順では、ストレージをOracle ASMディスク・グループに追加すると仮定します。

- Oracle ASM記憶域への移行

- ストレージの追加と削除

- Oracle ASMノードのアップグレード

14.2.5.2.1 Oracle ASM記憶域への移行

ファイル・システムまたはRAWデバイスにデータベース・ファイルを格納する既存のOracleデータベースがある場合、それらのデータベース・ファイルの一部または全部をOracle ASMに移行できます。停止時間を最小にするには、フィジカル・スタンバイ・データベースを使用して、データをOracle ASM記憶域に移行します。Oracle Recovery Manager (RMAN)またはASMCMDユーティリティを使用すると、停止時間をほとんど発生させずにOracle ASMに移行できます。Oracle Recovery Manager (RMAN)とASMCMDユーティリティでは、個々のファイルをOracle ASMにコピーできます。

完全移行の場合は、Oracle Data GuardまたはOracle GoldenGateが、より少ない停止時間でOracle ASMに移行するためのより優れた代替方法です(移行は、スイッチオーバーの実行に要する時間と同じ程度で行われます)。

関連項目:

- RMANを使用してOracle ASMにデータを移行する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- MAAホワイト・ペーパー『Minimal Downtime Migration to ASM』

http://www.oracle.com/goto/maa

14.2.5.2.2 ストレージの追加と削除

Oracle ASMへのディスクの追加および削除は停止時間なしで実行できます。ディスクが追加または削除されると、Oracle ASMではリバランス操作が自動的に開始され、ディスク・グループのコンテンツがディスク・グループのすべてのドライブに均等に分割されます。ストレージの追加または削除のベスト・プラクティスは次のとおりです。

- Oracle ASMを使用してストレージの追加や削除を行う前に、ホスト・オペレーティング・システムとストレージ・ハードウェアが、停止時間なしでのストレージの追加や削除をサポートしていることを確認します。

- 複数のディスク・ドライブを追加または削除するときに単一のALTER DISKGROUPコマンドを使用します(この方法ではリバランス操作は1つのみですが、個々の削除と追加では2つ以上のリバランス操作があります。詳細は、4.5.4項「単一のコマンドを使用したストレージの追加または削除」を参照してください)。
たとえば、ストレージ・メンテナンスでドライブを追加し、既存のドライブを削除する場合は、既存のドライブを削除するためのDROP DISK句と、ドライブを追加するためのADD DISK句を指定した単一のALTER DISKGROUPコマンドを使用します。

ALTER DISKGROUP data
DROP DISK diska5
ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9;

- ディスク・グループからディスクを削除する場合、削除対象のドライブの内容が他のドライブに移行されるまでALTER DISKGROUP文が戻されないように、REBALANCE句にWAITオプションを指定します。文が完了したら、システムから安全にドライブを削除できます。たとえば、次のようになります。

ALTER DISKGROUP data
DROP DISK diska5
ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9
REBALANCE WAIT;

- 標準または高冗長性ディスク・グループのディスクを削除する場合、完全な冗長性を再構築するのに十分な空き領域がディスク・グループに存在することを確認します。

- Enterprise Managerを使用するか、V$ASM_OPERATIONを問い合せることでリバランス操作の進行状況を監視します。

- データベース・アクティビティの頻度が低い期間に長く実行されるリバランス操作では、リバランスの最大能力が向上するため、リバランス時間を短縮できます。

関連項目:
『Oracle Automatic Storage Management管理者ガイド』

14.2.5.2.3 Oracle ASMノードのアップグレード

Oracle ASMローリング・アップグレードを実行すると、クラスタ化Oracle ASMノードのアップグレードまたはパッチ適用を独立して行うことで、データベース可用性に影響を与えずに稼働時間を最大化できます。Oracle ASMローリング・アップグレードを使用できるのは、Oracle Database 11g以上のリリースを実行している環境でクラスタ化Oracle ASMインスタンスをアップグレードする場合のみです。

関連項目:
Oracle ASMローリング・アップグレードの使用方法の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

14.2.6 データベースのアップグレード

データベース・アップグレードは、データベースを新しいメジャー・リリース、メンテナンス・リリースまたはパッチ・セットにすることを意味します。データベース・アップグレードを実行する場合、次のOracle機能を使用できます。

- Database Upgrade Assistant (DBUA)を使用したアップグレード

- Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード

- Oracle GoldenGateを使用したアップグレード

- トランスポータブル表領域を使用したアップグレード

データベース・アップグレードの実行方法は、次のことを考慮したうえで選択します。

- アップグレードを完了するのに必要な停止時間

- 停止時間の前に必要な設定時間および作業

- 一時的に必要となる追加リソース(ディスク領域やCPUなど)

- アップグレードを完了するのに許容される手順の複雑さ

表14-3に、データベース・アップグレードに使用できる方法と、特定のケースでその方法の使用が推奨される場合についてリストします。

表14-3 データベース・アップグレード・オプション

アップグレード方法

この方法を使用する場合

Database Upgrade Assistant (DBUA)を使用したアップグレード

メンテナンス・ウィンドウが十分であるか、データ型制約によりこの表の他の方法を使用できない場合の推奨の方法

Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード

DBUAがメンテナンス・ウィンドウ内に終了せず、データベースがOracle RACローリング・パッチ・アップグレードに適していない場合

フィジカル・スタンバイ・データベースが1つのみの構成の場合は、一時ロジカル・スタンバイを使用

Oracle GoldenGateを使用したアップグレード

Oracle GoldenGateは、完全データベース・レプリケーションの場合、データベース・バージョンがOracle 10g (Oracle Data Guardデータベース・ローリング・アップグレードの最小バージョン)より前の場合、前のバージョンへのレプリケートのために柔軟性が必要な場合(高速フォールバック・オプション)、またはマルチマスター・レプリケーションを使用した停止時間ゼロのアップグレードが必要な場合にすでに使用されています。

トランスポータブル表領域を使用したアップグレード

Data Guard SQL ApplyまたはOracle GoldenGateでサポートされないデータ型をデータベースで使用しており、ユーザー・スキーマが単純な場合

使用するアップグレード方法にかかわらず、『Oracle Databaseアップグレード・ガイド』のガイドラインおよび推奨事項と、その関連ドキュメントである次の場所にあるMy Oracle Supportのノート785351.1の『Oracle 11gR2 Upgrade Companion』に従う必要があります。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=785351.1

関連項目:

- 次の場所にあるMy Oracle Supportのノート250.1の『Oracle Support Lifecycle Advisors』
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=250.1

- 次の場所にあるOracle Technology Network Oracle Database Upgrade Webページ
http://www.oracle.com/technetwork/database/upgrade/index.html

14.2.6.1 Database Upgrade Assistant (DBUA)を使用したアップグレード

Database Upgrade Assistant(DBUA)は、データベースを以前のソフトウェア・リリースからインプレースでアップグレードする際に使用します。

最小限の停止時間でデータベース・アップグレードを実行する際に、DBUAを適切なツールとして使用するかどうかを決定する場合、次の点を考慮してください。

- DBUAは、データベース・ディクショナリとすべてのコンポーネントをアップグレードします。例: 通常のユーザー・アクティビティにデータベースを使用できないときにインストールされたJavaやXDBなど。

- DBUAを使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。

- すべてのデータベース・ディクショナリ・オブジェクトを新規バージョンにアップグレードする時間

- データベースの再起動

- アップグレードしたデータベースにクライアントを再接続する時間

- DBUAの使用時にデータベース・アップグレードに必要とされる停止時間を短縮するには、次のようにします。

- 使用されていないデータベース・オプションをすべて削除します。
DBUAでは、アプリケーションで必要とされるかどうかにかかわらず、インストール済のすべてのデータベース・オプションがアップグレードされます。アップグレードの必要なオプションの数を減らすことで、アップグレード時間全体を短縮できます。

- データ・ディクショナリ統計は、アップグレードの直前に更新します。

DBUAによるアップグレードの実行時間がメンテナンス・ウィンドウ内に収まる場合は、データベース・アップグレードにDBUAを使用してください。

関連項目:

- DBUAおよびOracleデータベース・ソフトウェアのアップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

- 次の場所にあるMy Oracle Supportのノート785351.1の『Oracle 11gR2 Upgrade Companion』
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=785351.1

- Oracle9iからOracle Database 11gにアップグレードするには、次の場所にあるMy Oracle Supportのノート601807.1の『Oracle 11gR1 Upgrade Companion』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=601807.1

14.2.6.2 Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード

Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用して、ローリング・アップグレードというプロセスを使用して最小限の停止時間でデータベースをアップグレードします。現在のところ、Data Guardでは、プライマリ・データベースとスタンバイ・データベースが同じプラットフォームで稼働する同機種環境をサポートしています。

関連項目:
異種環境に固有の例外、およびSQL Applyでのローリング・アップグレードに関するその他の最新情報は、次の場所にあるMy Oracle Supportのノート413484.1の『Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=413484.1

14.2.6.2.1 SQL Applyローリング・アップグレード

従来の方法によるアップグレードがメンテナンス・ウィンドウ内に完了せず、アプリケーションでユーザー定義型を使用していない場合は、Data Guard SQL Applyのローリング・データベース・アップグレードを使用してください。パッチ・セットおよびデータベースのアップグレードを最小の停止時間で実行するには、SQL Applyを使用するOracle Data Guardのソリューションをお薦めします。

データベース・アップグレード時の停止時間を最小化するためにData Guard SQL Applyが適切な方法であるかどうかを決定する場合、次の点を考慮してください。

- SQL Applyには、データ型の制限がいくつかあります(制限のリストは、『Oracle Data Guard概要および管理』を参照)。データ型の制限がある場合は、拡張データ型サポート(EDS)の実装を検討してください。ソース・データベースがSQL Applyでもともとサポートされていないデータ型を使用している場合、拡張データ型サポート(EDS)を使用することで、対応する拡張データ型をさらにいくつか増やすことができます。

- SQL Applyローリング・アップグレードは、ソース・リリースがOracle Database 10gリリース1(10.1.0.3)以上であれば、メジャー・リリース・アップグレードを含むすべてのアップグレードに対して実行できます。作業を開始する前に、『Oracle Data Guard概要および管理』でSQL Applyローリング・アップグレードの詳細な手順と、サポートされるデータ型を確認してください。

- ソース・データベースが、SQL Applyのローリング・アップグレードでサポートされていないソフトウェア・バージョンを使用している場合(Oracle Databaseリリース10.1.0.3より前のリリース)、またはEDSを使用してもSQL Applyのデータ型の競合を十分に解決できない場合は、Database Upgrade Assistant (DBUA)、トランスポータブル表領域またはOracle GoldenGateの使用を検討します。

- Data Guard SQL Applyを使用したデータベース・アップグレード(ローリング・アップグレード)に必要な停止時間は、次の操作に要する時間によって決定されます。

- Data Guardスイッチオーバーを実行する時間

- 新規データベースにクライアントを再接続する時間

関連項目:

- SQL Applyを使用したOracle Databaseのアップグレードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- http://www.oracle.com/goto/maaにあるMAAホワイト・ペーパー『Database Rolling Upgrade Using Data Guard SQL Apply Oracle Database 11g and 10gR2』

- SQL Applyについては、EDSサポートはOracle Databaseリリース10.2.0.4から開始します。EDS実装は10.2.0.4と11.1、およびOracle Databaseリリース11.2とで異なります。
10.2.0.4から11.1では、次の場所にあるMy Oracle Supportのノート559353.1の『Extended Datatype Support (EDS) for SQL Apply』で詳細に示されている例に従って、EDSを構築する必要があります。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=559353.1

Oracle Databaseリリース11.2では、EDS関連プロシージャはDBMS_LOGSTDBYパッケージの一部です。詳細は、次の場所にあるMy Oracle Supportのノート949516.1の『SQL Apply Extended Datatype Support - 11.2』を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=949516.1

14.2.6.2.2 一時ロジカル・スタンバイ・データベースのローリング・アップグレード

一時ロジカル・スタンバイ・データベースを使用して、現在のフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイ・データベースに変換することにより、そのフィジカル・スタンバイ・データベースを使用してデータベースのローリング・アップグレードを実行できます。フィジカル・スタンバイ・データベースが1つのみの構成の場合は、一時ロジカル・スタンバイを使用します。一時ロジカル・スタンバイを使用したローリング・アップグレードの実行は、標準SQL Applyローリング・アップグレードと似ていますが、次の点が異なります。

- 保証付きリストア・ポイントがプライマリ・データベース上に作成され、スイッチオーバーの後、データベースをフィジカル・スタンバイ・データベースにフラッシュバックします。

- フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースへの変換では、KEEP IDENTITY句を使用して、プライマリ・データベースと同じDB_NAMEおよびDBIDを保持します。

- ALTER DATABASE CONVERT TO PHYSICAL STANDBY文が、元のプライマリ・データベースを、ロジカル・スタンバイからフィジカル・スタンバイ・データベースに変換します。

- 元のプライマリ・データベースは、一時ロジカル・スタンバイ・データベース・ロールからフィジカル・スタンバイ・データベースに変換された後で、REDO Applyを使用して実際にアップグレードされます。

図14-1に、一時ロジカル・スタンバイ・データベースを使用してローリング・アップグレードを実行するときに発生する処理のフローを示します。

注意:
図14-1に示す操作を簡略化するために、データベースのローリング・アップグレード手順を自動化するBourneシェル・スクリプトを使用できます(Oracle Database 11gリリース1以降)。データベースのローリング・アップグレードは、既存のData Guardフィジカル・スタンバイ・データベースおよび一時的なロジカル・スタンバイ・ローリング・アップグレード・プロセスを使用して実行されます。次の場所にあるMy Oracle Supportのノート949322.1の『Oracle 11g Data Guard: Database Rolling Upgrade Shell Script』で詳細に説明されている、physruという名前のBourneシェル・スクリプトをダウンロードできます。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=949322.1

図14-1 一時ロジカル・スタンバイ・データベースを使用したデータベース・ローリング・アップグレード

関連項目:

- 既存のフィジカル・スタンバイ・データベースでのローリング・アップグレードの実行の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 次の場所にあるOracle DatabaseのMAAベスト・プラクティス領域から入手できる、データベース・ローリング・アップグレードに関連する多くのタスクの自動化のプロセスについて説明しているMAAホワイト・ペーパー『Database Rolling Upgrades Made Easy by Using a Data Guard Physical Standby Database』
http://www.oracle.com/goto/maa

14.2.6.3 Oracle GoldenGateを使用したアップグレード

Oracle Data Guardでは対処するように設計されていない要件に対して、最小限の停止時間でデータベース・ソフトウェアをあるバージョンから別のバージョンにアップグレードするために、Data Guardデータベース・ローリング・アップグレードの代替方法としてOracle GoldenGateを使用することを検討してください。この目的では、Oracle GoldenGateはOracle Data Guardに比べて次の利点があります。

- Oracle GoldenGateは、Oracle Database 10gより前のOracle DatabaseリリースからOracle Databaseをローリング方式でアップグレードできます(Data Guardデータベース・ローリング・アップグレードは、Oracle Database 10g以降でサポートされます)。

- Oracle GoldenGateは、新しいOracle Databaseリリースから以前のOracle Databaseリリースへの一方向レプリケーション用に構成して、高速フォールバック・オプションを有効にできます(Oracle Data Guardでは、以前のデータベース・リリースから新しいリリースへのレプリケートのみ可能です)。これは、一定期間新しいリリースで操作する場合に役立ち、本番運用の開始数日後に予期しない問題が発生した場合に以前のリリースに迅速に戻すことができます。新しいリリースから以前のリリースへの一方向レプリケーションを構成することにより、問題を解決する一方で、データを失ったりダウングレードに時間をかけたりすることなく本番環境を以前のリリースに迅速に切り替えることができます。

- Oracle GoldenGateは、異なるOracle Databaseリリース間のマルチマスター・レプリケーション用に構成して、停止時間ゼロのアップグレードを促進できます(Oracle Data Guardは一方向レプリケーション・ソリューションです)。新しいOracleリリースがデプロイされ、ユーザー接続の準備ができると、古いリリースの既存のユーザー接続でトランザクションの処理を継続したまま、新しいユーザー接続を新しいリリースに向けることができます。既存のユーザー接続が終了すると、ユーザーが停止時間を認識することなく、以前のリリースで動作しているOracle Databaseの使用率が自然に縮小されます。マルチマスター・レプリケーションは、この移行フェーズ中に両方のデータベースの同期を保ちます。すべてのユーザーが新しいリリースに移行した後、単純な一方向レプリケーションは以前のデータベース・リリースの同期を維持して、前の箇条書き項目で説明したように高速フォールバック・オプションを提供できます。マルチマスター・レプリケーションは、すべてのアプリケーションに適しているわけではありません。競合の検出と解決が必要です。

- データベースのアップグレードに14.2.6.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード」で説明した手順を使用できず、データベースまたはアプリケーションのアップグレードの際の停止時間を0 (ゼロ)にするか最小限に抑える必要がある場合は、Oracle GoldenGateを構成してデータベース・アップグレードを実行することで、停止時間を0 (ゼロ)または最小限に抑えることができます。詳細は、次の場所にあるホワイト・ペーパー『Zero-Downtime Database Upgrades Using Oracle GoldenGate』を参照してください。
http://www.oracle.com/technetwork/middleware/goldengate/overview/ggzerodowntimedatabaseupgrades-174928.pdf

関連項目:
Oracle GoldenGateを使用したデータベース・アップグレードの詳細は、『Oracle GoldenGate Windows and UNIX管理者ガイド』を参照してください。

14.2.6.4 トランスポータブル表領域を使用したアップグレード

トランスポータブル表領域を使用すると、すべてのユーザー・データファイルを事前に作成および準備されたターゲット・データベースにトランスポートすることで、データベース・アップグレードを実行できます。

データベース・アップグレードの実行にトランスポータブル表領域が適切な方法であるかどうかを決定する場合、次の点を考慮してください。

- SYSTEM表領域は、トランスポータブル表領域で移動できません。ユーザー定義やアプリケーションに必要なオブジェクトを含むターゲット・データベースのSYSTEM表領域の内容は、手動で構築する必要があります。SYSTEM表領域の内容を移動する場合、データ・ポンプを使用します。

- トランスポータブル表領域を使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。

- ソース・データベースの表領域を読取り専用モードにする時間。

- トランスポータブル・メタデータのネットワーク・インポートを実行する時間。

- ターゲット・データベースがリモート・システムに存在する場合、ソース・システムからターゲット・システムにすべてのデータファイルを転送する時間。ただし、トランスポータブル表領域を使用してデータベース・アップグレードを実行すると有益なのは、データファイルをその現在の場所で使用できる場合のみです。トランスポータブル表領域手法は、この手法を使用するとターゲットの場所にデータファイルをコピーする必要がある場合にはお薦めしません。
データファイルの転送時間を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを使用可能にするストレージ・インフラストラクチャを使用するか、フィジカル・スタンバイ・データベースを使用します。

トランスポータブル表領域を使用したデータベース・アップグレードの実行は、次の場合に推奨されます。

- トランスポート・プロセスの一環としてデータファイルをコピーせずに、現在の場所でデータファイルを使用できる場合。ターゲット・データベースが異なるマシン上に存在する場合、ソース・システムとターゲット・システムの両方からそのストレージにアクセスできる必要があります。

- DBUAがメンテナンス・ウィンドウ内に完了しない場合。

- データ型の制限によりOracle GoldenGateまたはData Guard SQL Applyを使用できない場合。

- Oracleデータベースに単純なスキーマが含まれる場合。

関連項目:

- トランスポータブル表領域の概要は、『Oracle Database管理者ガイド』を参照してください。

- 次の場所にあるMAAホワイト・ペーパー『Database Upgrade Using Transportable Tablespaces』
http://www.oracle.com/goto/maa

14.2.7 データベースのプラットフォームまたはロケーションの移行

データベースの移行を実行する場合、主要な目標は、既存のソース・システムからOracle 11gデータベースにデータを移行することです。データの移行は、データ・ポンプ、トランスポータブル表領域、Oracle Data Guard、Oracle GoldenGateなどのツールで実行できます。ただし、移行中は、移行計画の目標となる2つの同等の重要度の項目に対処する必要があります。

- 簡略化: 移行中に、実装を簡略化します。様々なバージョンと様々なDBAによって進化してきたほとんどのデータベース環境には、古い情報が含まれます(また、現在のDBAはシステムで何かが使用されている理由について疑問を持つ場合があります)。簡略化の目的は、管理者が作業を高い信頼性で簡単に行えるようにすることです。この簡略化により、システムの可用性が高まります。

- 最適化: 移行中に、実装を最適化できます。多くの場合、移行には更新されたデータベース・バージョンが含まれるため、新しい機能が使用可能です。移行の実行中に、新しい機能とプラクティスの採用を検討する必要があります。

移行計画に次の手順を追加して、簡略化と最適化を行います。

- オプションと移行方針の検討

- 移行の計画

- プラットフォームの移行とアップグレードに関するOracleの機能

14.2.7.1 オプションと移行方針の検討

移行方針を策定する場合の最初の手順は、新しいターゲット環境について理解し、ソース・システムからターゲット・システムにデータを物理的に移動する方法を決定することです。ターゲット環境の中心はOracle Databaseです。他のOracleデータベース・アップグレードや移行と同様に、『Oracle Databaseアップグレード・ガイド』とその関連ドキュメントである次の場所にあるMy Oracle Supportのノート785351.1の『Oracle 11gR2 Upgrade Companion』に記載されているガイドラインおよび推奨事項に従う必要があります。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=785351.1

- 移行中にinit.oraを更新します。
既存のinit.oraファイルで、重要でなくなったと思われるパラメータを削除します。パラメータをデフォルト設定から変更する場合は、変更の妥当性を確認します。たとえば、以前のリリースで見つかった問題を回避するため(たとえば、以前のリリースで解決したオプティマイザの問題を処理するため)に設定されたアンダースコア・パラメータは削除できます。

- 移行中にSQLを更新します。
オプティマイザで目的の計画を強制的に生成するために挿入された、以前のOracle Databaseバージョンに追加されたSQLヒントを削除します。オプティマイザは一般に、適切な統計が提供されていれば、ヒントの必要なしに適切な実行計画を作成します。

- 移行中にスキーマ・オブジェクトを簡略化または変更します。
移行中に行えるスキーマ・レイアウトの変更があるかどうかを検討する必要があります。たとえば、次の場合を考えます。

- 大きな表のパーティション化スキームの変更

- Oracle Exadataデータベース・マシンに移行する場合に、ハイブリッド列圧縮(HCC)などの新規に使用可能な圧縮機能の採用(詳細は、『Oracle Database概要』を参照)

- 暗号ハードウェア・アクセラレーションを提供するシステムに移行する場合には特に、透過的データ暗号化(TDE)の採用

また、索引の過剰な使用など、移行するべきでないオブジェクトがあるかどうかを判断します。データベースのスキーマ・オブジェクトを変更または削減する場合は、現在の形式でデータベースを移行し、移行後に変更を実行する方がよいか、または移行中に選択的に行う方がよいかを検討する必要があります。

- 使用していない表領域とデータファイルを移行中に削除します。
使用していないまたは不要な表領域とデータファイルを移行中に削除できるかどうかを検討する必要があります。表領域とデータファイルが少ない方が、管理性とパフォーマンスが向上します。

14.2.7.2 移行の計画

移行を計画するときには、次の点を検討します。

- ソース・データベースをOracle Database 11gリリース2にアップグレードすることを検討します。これにより、(場合によっては大幅に)移行が向上します。たとえば、Oracle Database 11gリリース2のデータ・ポンプのパラレル機能はOracle Databaseリリース10.2よりも大幅に向上しているため、ソース・データベースをOracle Database 11gリリース2にアップグレードした場合は、ソース・システムからのデータベース・エクスポートが向上し、より高速に完了します。

- 移行の前に、ソース・データベース内の不要なスキーマ・オブジェクトの削除を検討します。これにより、移行する必要のあるデータ量が削減されます。

- ビジネス・ニーズと停止時間の要件を判断および検討します。必要な停止時間の長さに影響する要因について、14.2.7.3項「プラットフォームの移行とアップグレードに関するOracleの機能」でプラットフォームの移行に関するOracle機能を参照してください。

- 移行を段階的に実行するための要件または可能性があるかどうかを検討します。たとえば、ソース・データベースに大量の読取り専用データがある場合は、ライブ・データ移行の前に移行して停止時間を短縮できます。

- プラットフォームの移行作業には、大量のテストが含まれます。

14.2.7.3 プラットフォームの移行とアップグレードに関するOracleの機能

プラットフォーム移行とアップグレードを実行する場合、次のOracle機能を使用できます。

- プラットフォーム移行のためのフィジカル・スタンバイ・データベース

- プラットフォーム移行のためのトランスポータブル・データベース

- プラットフォーム移行のためのOracle GoldenGate

- プラットフォーム移行のためのOracle Data Pump

- プラットフォーム移行のためのトランスポータブル表領域

- ロケーション移行のためのData Guard REDO Apply(フィジカル・スタンバイ・データベース)

これらのデータベース・メンテナンス・タスクの実行方法は、次のことを考慮したうえで選択します。

- メンテナンス操作を完了するのに必要な停止時間

- 停止時間の前に必要な設定時間および作業

- 一時的に必要となる追加リソースの量(ディスク領域やCPUなど)

- メンテナンス操作を完了するのに許容される手順の複雑さ

表14-5に、プラットフォーム移行およびデータベース・アップグレードに使用できる方法と、操作ごとにその方法の使用が推奨される場合についてまとめます。

表14-5 プラットフォームおよびロケーション移行のオプション

操作

推奨される方法

代替の方法

同じエンディアン・プラットフォームへのプラットフォーム移行

プラットフォーム移行のためのフィジカル・スタンバイ・データベース

1. 移行対象のプラットフォームの組合せで、クロスプラットフォームのフィジカル・スタンバイ・データベースを利用できない場合は、プラットフォーム移行のためのトランスポータブル・データベースを使用します。

2. トランスポータブル・データベースがメンテナンス・ウィンドウ内に完了しない場合は、プラットフォーム移行のためのOracle GoldenGateを使用します。

異なるエンディアン・プラットフォームへのプラットフォーム移行

プラットフォーム移行のためのOracle Data Pump

1. データ・ポンプがメンテナンス・ウィンドウ内に完了しない場合は、プラットフォーム移行のためのOracle GoldenGateを使用します。

2. データベースが、Oracle GoldenGateによってサポートされていないデータ型を使用している場合は、プラットフォーム移行のためのトランスポータブル表領域を使用します。

ロケーション移行のみ

ロケーション移行のためのData Guard REDO Apply(フィジカル・スタンバイ・データベース)

なし

注意:
すべてのプラットフォームのエンディアン形式を確認するには、V$TRANSPORTABLE_PLATFORMビューを問い合せます。現在のシステムのプラットフォームIDとプラットフォーム名を確認するには、V$DATABASEビューを問い合せます。

14.2.7.4 プラットフォーム移行のためのフィジカル・スタンバイ・データベース

プラットフォーム移行の推奨アプローチは、フィジカル・スタンバイを作成し、スイッチオーバーを実行することです。フィジカル・スタンバイ・データベースは、特定の異種プラットフォームの組合せをサポートします。プラットフォームの組合せの最新リストは、次の場所にあるMy Oracle Supportのノート413484.1の『Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration』を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=413484.1

Oracle Data Guardとフィジカル・スタンバイ・データベースは、Oracle RACローリング・アップグレードを使用してアップグレードできないシステムとクラスタのアップグレードを実行する場合に推奨されるソリューションです。たとえば、Data Guardは次の場合にも推奨されます。

- システム制約のためにOracle RACローリング・アップグレードを使用してアップグレードできないシステム・アップグレード。

- Oracle ASMへの移行、クラスタ化されていない環境からのOracle RACへの移行、64ビット・システムへの移行、同じエンディアン形式の異なるプラットフォームへの移行、同じプロセッサ・アーキテクチャの異なるプラットフォームへの移行、またはWindowsからLinuxへ、LinuxからWindowsへの移行。

- 32ビットOracleバイナリを持つプライマリ・データベースがLinux 32ビット上にあり、64ビットOracleバイナリを持つフィジカル・スタンバイ・データベースがLinux 64ビット上にある場合。このような構成は、Data Guardのロール移行(スイッチオーバーおよびフェイルオーバー)時に、サポート・ノート414043.1に記載されている追加の手順に従う必要があります。

関連項目:

- 次の場所にあるMy Oracle Supportのノート413484.1の『Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=413484.1

- 次の場所にあるMy Oracle Supportのノート414043.1の『Role Transitions for Data Guard Configurations Using Mixed Oracle Binaries』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=414043.1

14.2.7.5 プラットフォーム移行のためのトランスポータブル・データベース

トランスポータブル・データベースは、データベース全体を、同じエンディアン形式を持つ別のプラットフォームに移行する場合、ただし移行元と移行先のプラットフォームの組合せで、クロスプラットフォームのフィジカル・スタンバイ・データベースが使用できない場合のみに推奨される方法です。

データベースを別のプラットフォームに移行する際にトランスポータブル・データベースが適切な方法であるかどうかを決定する場合、次の点を考慮してください。

- トランスポータブル・データベースでは、同じエンディアン形式のプラットフォーム間でのデータベースの移行がサポートされます。

- トランスポータブル・データベースを使用したプラットフォーム移行に必要な停止時間は、次の操作に要する時間によって決定されます。

- ソース・データベースを読取り専用モードにする時間。

- データファイルを変換します。UNDOセグメントを含むファイル、またはHP Tru64との間で変換する場合は自動セグメント領域管理(ASSM)セグメント・ヘッダーを含むファイルのみ、変換が必要です。

- すべてのデータファイルをソース・システムからターゲット・システムに転送する時間。
停止時間の総量を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを利用可能にするストレージ・インフラストラクチャを使用します。

関連項目:

- プラットフォーム間でトランスポータブル・データベースを使用する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 次の場所にあるMAAホワイト・ペーパー『Platform Migration Using Transportable Database』を参照してください。
http://www.oracle.com/goto/maa

14.2.7.6 プラットフォーム移行のためのOracle GoldenGate

Oracle GoldenGateを使用すると、最小限の停止時間でデータベースをあるプラットフォームから別のプラットフォームに移行できます。トランスポータブル・データベースで移行を迅速に実行できない状況において、アプリケーションでユーザー定義型を使用しておらず、移行を実行するために追加の管理作業が発生してもかまわない場合は、Oracle GoldenGateの使用を検討してください。

プラットフォーム移行の実行にOracle GoldenGateが適切な方法であるかどうかを決定する場合、次の点を考慮してください。

- Oracle GoldenGateでは、ユーザー定義型がサポートされません(オブジェクト型、REF値、VARRAY、ネストした表など)。

- Oracle GoldenGate環境をセットアップして、維持するには、追加の管理上の労力が必要とされることがあります。

- Oracle GoldenGateを使用したプラットフォーム移行に必要な停止時間は、キュー内の残りのトランザクションを適用する時間と、新規データベースにクライアントを再接続する時間によって決定されます。

関連項目:
『Oracle GoldenGate Windows and UNIX管理者ガイド』

14.2.7.7 プラットフォーム移行のためのOracle Data Pump

Oracle Data Pumpテクノロジを使用すると、異なるプラットフォーム間や異なるデータベース・リリース間でデータおよびメタデータをあるデータベースから別のデータベースに高速に移動できます。

プラットフォーム移行にデータ・ポンプが適切な方法であるかどうかを決定する場合、次の点を考慮してください。

- データ・ポンプを使用している場合にプラットフォーム移行に必要な停止時間は、完全データベース・エクスポートの実行、ターゲット・システムへのエクスポート・ダンプ・ファイルの転送、さらに完全データベース・インポートの実行に必要な時間によって決まります。

- 停止時間は、ソース・システムとターゲット・システム間で共有されているストレージへのエクスポートを実行することで短縮されるため、エクスポート・ダンプ・ファイルの転送の必要がなくなります。

- データ・ポンプは、ネットワーク・インポートと呼ばれる、データベース・リンク上でのソース・データベースからのターゲット・データベースの直接ロード機能をサポートします。場合によっては、ネットワーク・インポートはエクスポート・データベースのマルチステップ・アプローチ、ダンプ・ファイルの転送およびデータベースのインポートより高速です。

異なるエンディアン形式のプラットフォームにデータベースを移行する場合、ネットワーク・インポート時間が許容範囲内であれば、データ・ポンプを使用してください。

関連項目:

- Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。

- Oracleデータベース・ソフトウェアのアップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

14.2.7.8 プラットフォーム移行のためのトランスポータブル表領域

トランスポータブル表領域は、すべてのユーザー・データファイルを事前に作成および準備されたターゲット・データベースにトランスポートすることで、プラットフォーム移行を実行します。トランスポータブル表領域は、Oracle GoldenGateでサポートされないデータ型をデータベースで使用しており、ユーザー・スキーマが単純な場合に使用します。

プラットフォーム移行の実行にトランスポータブル表領域が適切な方法であるかどうかを決定する場合、次の点を考慮してください。

- SYSTEM表領域は、トランスポータブル表領域で移動できません。ユーザー定義やクライアントに必要なオブジェクトを含むターゲット・データベースのSYSTEM表領域の内容は、手動で構築する必要があります。SYSTEM表領域の必要な内容を移動する場合、データ・ポンプを使用します。

- トランスポータブル表領域を使用したプラットフォーム移行またはデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。

- ソース・データベースの表領域を読取り専用モードにする時間。

- トランスポータブル・メタデータのネットワーク・インポートを実行する時間。

- すべてのデータファイルをソース・システムからターゲット・システムに転送する時間。
この時間を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを利用可能にするストレージ・インフラストラクチャを使用します。

- RMANを使用してすべてのデータファイルを新規プラットフォームの形式に変換する時間

Oracle Data Pumpがメンテナンス・ウィンドウ内に完了せず、データ型の制限からOracle GoldenGateまたはData Guard SQL Applyを使用できない場合は、プラットフォームへの移行にトランスポータブル表領域を使用してください。

関連項目:
トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

14.2.7.9 ロケーション移行のためのData Guard REDO Apply(フィジカル・スタンバイ・データベース)

Data Guard REDO Applyを使用すると、一時スタンバイ・データベースをリモートの場所に設定してスイッチオーバー操作を実行することで、最小限の停止時間でデータベースの場所をリモート・サイトに変更できます。

Data Guard REDO Applyを使用したロケーション移行に必要な停止時間は、スイッチオーバー操作を実行する時間によって決定されます。

関連項目:
REDO Applyとフィジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

14.2.8 オンライン・アプリケーション・メンテナンスおよびアップグレードのエディションベースの再定義

エディションベースの再定義を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。これは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することにより実行します。

アプリケーションを使用中にアップグレードするには、アプリケーションを構成するデータベース・オブジェクトをコピーし、コピーしたオブジェクトを個別に再定義します。アプリケーションのユーザーは、この変更による影響を受けず、変更されていないアプリケーションを引き続き実行します。変更内容が正しいことを確認したら、アップグレードしたアプリケーションをすべてのユーザーが使用できるようにします。

順調な場合は、ロールオーバーが可能です。アップグレード前とアップグレード後のエディションは同時に使用できるため、アップグレード後のエディションの公開前に開始されたセッションは、自然に終了するまで、引き続きアップグレード前のエディションを使用することができ、新しいセッションではアップグレード後のエディションが使用されます。順調でない場合は、アップグレード前のセッションをすべて終了させないと、新しいセッションでアップグレード後のエディションを使用できません。そのような場合、アプリケーションは少しの間停止することになります。

関連項目:

- エディションベースの再定義の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- エディションの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

14.2.9 オンライン・アプリケーション・アップグレードでのOracle GoldenGate

アプリケーションのアップグレードには、データベースのアップグレードに加えて、必要なアプリケーション・コードとスキーマの変更が含まれることがあります。データベースまたはアプリケーション・アップグレードの実行時に停止時間をゼロまたは最小限にする必要がある場合は、Oracle GoldenGateを使用して、わずかな停止時間または停止時間なしでデータベース・アップグレードを実行できます。Oracle GoldenGateは、継続的なシステム可用性を提供し、計画済の停止を排除して、中断のないビジネス操作を可能にします。

関連項目:
『Oracle GoldenGate Windows and UNIX管理者ガイド』

14.2.10 データの再編成と再定義

データ・サーバーに関連する多くの計画済の停止には、データベース・オブジェクトの再編成が伴います。Oracle Databaseのオンライン再編成および再定義機能を使用すると、基礎となるデータが変更されている間でも、データ再編成を実行することができます。この機能により、ユーザーがデータベースに完全にアクセスできる状態でデータ再編成操作が可能になるため、可用性と管理性が拡張されます。

高可用性システムでは、問合せやDMLのパフォーマンスを向上するために、頻繁にアクセスされる大規模な表を定期的に再定義する必要があります。オンライン再編成および再定義機能を使用すると、管理者は、ユーザーによるデータベースへの完全なアクセスを維持しながら、表の物理属性を変更し、データと表構造の両方を変換できる柔軟性を手にできます。この機能により、ミッション・クリティカルな環境で重要となるデータ可用性、問合せパフォーマンス、レスポンス時間およびディスク領域使用率が向上します。また、オンライン再編成および再定義機能により、アプリケーション・アップグレード・プロセスは、より簡単、安全、迅速になります。

推奨されるベスト・プラクティスは、DBMS_REDEFINITION PL/SQLパッケージを使用して表を再編成することです。これにより、表をオフラインにする必要のある従来の表の再定義メソッドに比べて可用性が大幅に向上します。DBMS_REDEFINITIONをコマンドラインで手動で呼び出すか、Oracle Enterprise Managerのオブジェクトの再編成ウィザードを使用するかにかかわらず、再編成プロセス全体は、ユーザーが表への完全なアクセス権を持つときに行われるため、システムの可用性が確保されます。

図14-2に、SQL*PlusコマンドラインでDBMS_REDEFINITIONパッケージを呼び出すかわりに使用できるOracle Enterprise Managerのオブジェクトの再編成ウィザードのページを示します。ウィザードでいくつかの質問に答えると、スクリプトが生成され、再編成が実行されます。

図14-2 Oracle Enterprise Managerを使用したデータベース・オブジェクトの再編成

データの再編成を実行する場合は、次のことを考慮してください。

- オンライン操作中の表における同時アクティビティを最小化します。
オンライン操作中は、実表でのユーザー・アクティビティを最小化することをお薦めします。オンライン操作中のデータベース・アクティビティによる影響は、表の10%未満とする必要があります。データベース管理者は、データベース・リソース・マネージャを使用してユーザーに十分なリソースを割り当てることで、データ再編成の影響を最小限に抑えることができます。

- ピーク期間中にオンライン操作を実行することや、データのオンライン再編成中に大容量のデータ変更を伴うバッチ・ジョブを実行することは避けてください。

- オンラインで索引を再構築する方法と、索引を削除してからオンラインで索引を再作成する方法の比較。
オンラインで索引を再構築する場合、操作中に新規索引用の追加ディスク領域が必要です。一方、索引を削除して再作成する場合、追加ディスク領域は必要ありません。

- オンライン索引結合とオンライン索引再構築の比較。
オンライン索引結合は、インプレースのデータ再編成操作であるため、索引を再構築する場合のような追加ディスク領域は必要ありません。索引の再構築では、索引とソート領域の合計サイズに等しい一時ディスク領域が操作中に必要です。オンライン索引結合では、Bツリーの高さは減少しません。この場合、リーフ・ブロック数の削減が試行されるのみです。結合操作では、ユーザー用の領域は解放されませんが、索引スキャンのパフォーマンスは向上します。

索引を新規表領域に移動する必要がある場合は、オンライン索引再構築を使用してください。

- ローカル索引およびグローバル索引のオンライン・メンテナンスの実行。
Oracle Database 11gでは、オンライン操作でローカル・パーティション索引とグローバル・パーティション索引の両方がサポートされます。表および索引がパーティション化されている場合、管理者は、一度に1つのパーティションを対象にこれらのオブジェクトのメンテナンスを実行することで、他のパーティションをオンラインのまま維持できます。

関連項目:

- 表のオンライン再定義の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 次の場所にあるOracle Database High Availabilityページの「Online Reorganization」のリンク
http://www.oracle.com/technetwork/database/features/availability/index.html

14.2.11 システム・メンテナンスのための自動ワークロード管理

インスタンス、ノード、またはその他のコンポーネントを分離する必要のある計画済の停止では、サービスを再配置、無効化および有効化するOracle RACの機能を使用できます。再配置機能では、サービスを別のインスタンスに移行できます。サービスとインスタンスは、ハードウェアまたはシステム・ソフトウェアでの修復、変更、アップグレードの実行中に選択的に無効化し、メンテナンスの完了後に再有効化することが可能です。これにより、メンテナンスによる停止中はサービスまたはインスタンスが起動しないことが保証されます。サービスとインスタンスは、計画済の停止の開始時に無効化します。その後、メンテナンスによる停止の後に有効化します。

Oracle RACを使用している場合、ノードの開始時にOracleクラスタウェア・デーモンが自動的に起動します。1つ以上のシステムの再起動や、オペレーティング・システム以外のすべてのプロセスの停止が必要なメンテナンスの実行時には、crsctlコマンドを使用してOracle Clusterwareデーモンの起動を停止および無効化します。メンテナンスが完了したら、crsctlコマンドでOracleクラスタウェア・デーモンを有効化して起動します。

関連項目:

- 自動ワークロード管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- crsctlコマンドの使用方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- MAAホワイト・ペーパー『Optimizing Availability During Planned Maintenance Using Oracle Clusterware and Oracle RAC』
http://www.oracle.com/goto/maa

用語集

Oracle Active Data Guardオプション

Oracle Active Data Guardオプションのライセンスを購入すると、REDO Applyをアクティブにしたままフィジカル・スタンバイ・データベースを読取り専用アクセスでオープンできます。リアルタイム問合せとも呼ばれるこの機能を使用すると、スタンバイ・データベース上でブロック変更トラッキングが可能になり、それによりスタンバイ上で増分バックアップを実行できます。

クラスタ全体障害

Oracle RACデータベースをホストするクラスタ全体が使用不可能になるか、機能停止します。これには、クラスタ内の複数のノードの障害と、クラスタを停止してサイトのOracleデータベースおよびインスタンスを使用不可能にする他のすべてのコンポーネントの障害が含まれます。

コンピュータ障害

データベースを実行しているシステムが、クラッシュするか、アクセスできなくなったことにより使用不可能になったときに発生する停止状態。

データ破損

破損ブロックとは、変更されてOracleデータベースが予期する検出内容とは異なってしまったブロックです。ブロック破損は、物理ブロック破損と論理ブロック破損という2つのカテゴリに分類されます。

停止または減速

ハングまたは遅延が発生するのは、リソースやロックの競合が原因でデータベースまたはアプリケーションがトランザクションを処理できなくなったときです。認識されるハングは、システム・リソースの不足が原因である可能性があります。

ヒューマン・エラー

データベースのデータを論理的に破損させるか、使用不可能な状態にする意図的ではないアクションまたは悪意のあるアクションが実行されたときに発生する停止状態。人為的エラーによる停止のサービス・レベルへの影響は、影響を受けるデータの量や重要度に応じて大きく変化します。

論理ユニット番号(LUN)

同じSCSI IDで最大8つのデバイス(論理ユニット)を区別するためにSCSIバスで使用される3ビットの識別子。

書込みの欠落

書込みの欠落は、I/Oサブシステムでブロック書込みの完了を確認したが、実際には永続記憶域で書込みが発生していない場合に発生する、別形態のデータ破損。I/OサブシステムからOracleへはエラーがレポートされません。

MAA環境

最大可用性アーキテクチャは、Oracle RACを使用したOracle Database 11gとData Guardを使用したOracle Database 11gの両方の機能とメリットが継承されるため、計画外の停止に対して最も包括的なソリューションのセットを提供します。

MAAには、テクノロジ・スタック全体にわたるすべてのOracle製品(Oracle Database、Oracle WebLogic Server、Oracle Applications、Oracle Collaboration SuiteおよびOracle Enterprise Manager)の高可用性ベスト・プラクティスが含まれます。

ネットワーク・サーバー・プロセス

Data Guardネットワーク・サーバー・プロセスは、LNSnプロセスとも呼ばれ、プライマリ・データベースでスタンバイ・データベースのRFSプロセスに対するネットワーク送信を実行します。宛先ごとに1つのネットワーク・サーバー・プロセスが存在します。

リアルタイム問合せ

Oracle Active Data Guardオプションのライセンスを購入すると、プライマリ・データベースから受信したREDOデータがREDO Applyにより継続して適用されている間も、フィジカル・スタンバイ・データベースをオープンできます。

リカバリ・ポイント目標(RPO)

組織に問題を発生させずにITベースのビジネス・プロセスで失うことのできる最大データ量。RPOは、一般的に、ビジネス・プロセスまたは組織の許容データ損失量に相当します。このデータ損失は、通常、時間を基準として測定されます(5時間または2日分のデータ損失など)。

リカバリ時間目標(RTO)

組織に重大な物理的損失を発生させずにITベースのビジネス・プロセスを停止できる最大時間。RTOは、一般的に、ビジネス・プロセスまたは組織の許容停止時間に相当します。

サイト障害

イベントによりアプリケーションの全体または重要な部分が処理を停止するか、利用不可能なサービス・レベルにまで処理が遅延したときに発生する停止状態。サイト障害は、データ・センターのすべての処理に影響するか、データ・センターにサポートされているアプリケーションのサブセットに影響する可能性があります。

スナップショット・スタンバイ・データベース

フィジカル・スタンバイ・データベースから作成される更新可能なスタンバイ・データベース。スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信してアーカイブしますが、スタンバイ・データベースが読取り/書込みI/O用に開いているときにはプライマリ・データベースのREDOデータを適用しません。そのため、スナップショット・スタンバイは、時間が経過するにつれてプライマリ・データベースと異なるものになります。さらに、スナップショット・スタンバイ・データベースのローカルな更新によって相違は増えます。ただし、スナップショット・スタンバイはフィジカル・スタンバイ・データベースに逆変換されるので、プライマリ・データベースを保護します。

ストレージ障害

データベースの内容の一部または全部を格納するストレージが、停止またはアクセス中断を理由として使用不可能になったときに発生する停止状態。

一時ロジカル・スタンバイ・データベース

一時ロジカル・スタンバイ・データベースは、ローリング・データベース・アップグレードを実行するために、一時的にロジカル・スタンバイ・データベースに変換されたフィジカル・スタンバイ・データベース。

索引
A  B  C  D  E  F  G  H  I  K  L  M  N  O  P  Q  R  S  T  U  V  W  Z

A

ACFSスナップショット, 8.6.1

Active Data Guardオプション

データベース待機の評価, 9.3.8.5

アクティブ・セッション履歴レポート(ASH), 5.2.3 アドバンスト・キューイング(AQ), 9.3.1 アラート

Enterprise Manager, 12.2.1

ALTER DATABASE文

CONVERT TO SNAPSHOT STANDBY, 9.6

デフォルト一時表領域の指定, 5.2.8

ALTER DISKGROUP ALL MOUNT文, 4.5.3 ALTER SESSION ENABLE RESUMABLE文, 5.2.9 ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE, 9.3.8.3 アプリケーション・フェイルオーバー

DBMS_DG.INITIATE_FS_FAILOVER, 13.2.4

Oracle Data Guard構成, 13.2.4

Oracle RAC構成, 13.2.4

アプリケーション・ワークロード

データベースのパフォーマンス要件, 4.1

アプリケーション

サービスとして定義, 6.2.5

フェイルオーバー, 13.2.4

高速アプリケーション通知(FAN), 6.1.1.2, 13.2.4

高速フェイルオーバー, 11.5

ログイン・ストーム, 11.5

レスポンス時間の監視, 13.2.4

サービス低下, 12.2.3

ビーコンでのパフォーマンスの追跡, 12.2.2

アップグレード, 14.2.9

適用ラグ

Enterprise Managerのメトリック, 12.2.4

AQ_HA_NOTIFICATIONSパラメータ, 11.1 AQ_TM_PROCESSESパラメータ, 9.4.1 アーキテクチャ

高可用性, 1.1

アーカイブ・バックアップ

保持, 8.2.1

ARCHIVELOGモード, 5.1.1 アーカイバ(ARCn)プロセス

削減, 9.4.1

アーカイブ計画, 9.3.5 ASM

「Oracle Automatic Storage Management (Oracle ASM)」を参照, 4.2

ASM_DISKGROUPS初期化パラメータ, 4.5.3 ASM_DISKSTRINGパラメータ, 4.4.1 ASM_POWER_LIMIT

初期化パラメータ, 4.5.2

ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータ

拡張クラスタ, 7.3.4

ASMCAユーティリティ

ストレージ管理, 4.5.8

ASMCMDコマンドライン・ユーティリティ

ストレージ管理, 4.5.7

ASMLib, 4.4.6

ディスク・ラベル, 4.4.4

ASR

「Oracle Auto Service Request (ASR)」を参照

非同期ディスクI/O, 5.1.7 非同期I/O

有効化, 7.1.3

V$IOSTAT_FILEビュー, 5.1.7

AUTOBACKUP文

RMAN, 8.2.5

自動データベース診断モニター(ADDM), 5.2.3 自動パフォーマンス・チューニング, 5.2.3 自動セグメント領域管理, 5.2.7

使用, 5.2.7

自動共有メモリー管理, 5.1.9 Automatic Storage Management(Oracle ASM)

冗長性, 4.3.2.2

RMAN表領域のPoint-in-Timeリカバリ(TSPITR), 13.2.7.4 自動UNDO管理

説明, 5.2.5

自動ワークロード・リポジトリ(AWR), 5.1.4, 5.2.3, 9.7

ベスト・プラクティス, 5.2.3

パフォーマンス要件の評価, 4.1

AWR

「自動ワークロード・リポジトリ(AWR)」を参照

B

バックアップとリカバリ

ベスト・プラクティス, 8.2

チェックサムの計算, 5.1.6.1

ARCHIVELOGモードでの有効化, 5.1.1

バックアップ・ファイル

高速リカバリ領域ディスク・グループ障害, 13.2.5.4

UNDOのバックアップの最適化, 8.1.3 バックアップ

自動, 8.2.5

オプションの比較, 8.3

構成, 8.2

作成と同期, 8.2.3

保存ポリシーの決定, 8.2.1

アーカイブ(長期)の保持, 8.2.1

OCR, 6.3.2

定期実行, 8.5.4

RMANリカバリ・カタログ, 8.2.2

ビーコン, 12.2.2

構成, 12.2.2

メリット

Data Guardブローカ, 9.3.1

高可用性ベスト・プラクティス, 1.2

ベスト・プラクティス

AWR, 5.2.3

バックアップとリカバリ, 8.2

Data Guard構成, 9

データベース・リソース・マネージャ, 5.2.10

フェイルオーバー

手動, 9.4.2.4

フェイルオーバー(ファスト・スタート), 9.4.2.3, 13.2.2.2 フェイルオーバー(手動), 13.2.2.3, 13.2.2.3 高速接続フェイルオーバーの構成, 11 高可用性, 1.1 Oracle ASM構成, 4.4 Oracle ASMの運用ベスト・プラクティス, 4.5 Oracle ASMの戦略的な, 4.3 Oracle Clusterwareの構成, 6.2 Oracle Clusterwareの運用と管理, 6.3 Oracle Databaseの構成, 5.1 Oracle Databaseの運用と管理, 5.2 Oracle GoldenGateの構成, 10.2 Oracle RACの構成, 7.1, 7.1 Oracle RACローリング・アップグレード, 14.2.4.2 ストレージ・サブシステム, 4 スイッチオーバー, 14.2.1.2 アップグレード, 14.2.4.1 BLOCK CHANGE TRACKING句, 8.2.4 低下, 12.2.3

C

キャパシティ・プランニング, 6.3.1

変更トラッキング

増分バックアップ, 8.2.4

チェックポイント

平均リカバリ時間(MTTR)の確定, 7.1.1

クライアント接続

ノード間の移行, 6.1.1

クライアント

アプリケーション・フェイルオーバー, 13.2.4

フェイルオーバーの構成, 11.1

ロード・バランシング, 6.2.6

クラスタ・ファイル・システム

ソフトウェア・パッチ時に共用, 6.2.2

クラスタ状態モニター(CHM), 12.4 Cluster Ready Services(CRS)

説明, 13.3.1.1

サービスの移動, 13.2.3.2

サービス可用性のリカバリ, 13.3.1.1

OCRとの関係, 13.2.3.3

クラスタ時刻同期化サービス(CTSS), 6.2.8 クラスタASM

ストレージ・グリッドの有効化, 4.2.1

クラスタ

拡張, 7.3

クラスタ全体の停止

スタンバイ・データベースのリストア, 13.3.4

COMMIT NOWAIT

Oracle GoldenGate, 10.2.3

COMPATIBLE初期化パラメータ, 14.2.3 完全サイト・フェイルオーバー

リカバリ時間目標(RTO), 13.2.1.2

圧縮

REDO転送, 9.3.7.2

データベースの高可用性構成

MAAアドバイザを使用, 12.3.4

Oracle Databaseの共有サーバー構成, 11.5 接続プール

数の調整, 11.5

接続速度リミッタ

リスナー, 11.5

接続時フェイルオーバー, 13.3.1.3 制御ファイル

高速リカバリ領域ディスク・グループ障害, 13.2.5.4

CONTROL_FILES初期化パラメータ, 13.2.5.4.1 時間ベースの協調分散データベース・リカバリ, 13.2.8 破損

データベース・ファイルのチェック, 8.5.2

データ・リカバリ・アドバイザで阻止, 5.2.2

CREATE DISKGROUP文

例, 4.3.1, 4.3.2.1

CRS

「クラスタ・レディ・サービス・コントロール(CRS)」を参照

システム・メンテナンスのためのcrsctlコマンド, 14.2.11 CRSDプロセス

OCRのバックアップ, 6.3.2

CTSS

時間管理, 6.2.8

累積増分バックアップ, 8.3

D

ダーク・ファイバ

高密度波長分割多重方式(DWDM), 7.1.4

データ

重大性とRPO, 8.2.1

バックアップとRTOのリカバリ, 8.2.1

データ領域

内容, 4.3.1

ディスクのパーティション化, 4.3.1

データ領域ディスク・グループ障害

リカバリ・オプション, 13.2.5.3

データ破損

検出, 5.1.6.2

Oracle ASMの冗長性ディスク・グループによる保護, 5.1.6.1

ソリューション, 5.1.6.1

データ障害

スタンバイ・データベースのフォルト・トレランスのリストア, 13.3.5

Data Guard

アーカイブ計画, 9.3.5

ブローカ, 9.3.1

FAN/AQの使用, 9.3.1

データベース・アップグレード, 14.2.6.2 フェイルオーバー

ベスト・プラクティス(ファスト・スタート), 9.4.2.3

ベスト・プラクティス(手動), 9.4.2.4

データ領域ディスク・グループ障害のリカバリ, 13.2.5.3

実行する場合, 13.2.2.1

ログ適用サービス, 9.3.8 ターゲットの管理, 12.3.3 監視, 12.2.4 複数スタンバイ・データベース, 9.3.9 パフォーマンス, 9.7 プラットフォーム移行, 14.2.7.4 データ破損の防止, 5.1.6.1 REDO転送サービス, 9.2.1 スタンバイ・データベースのリストア, 13.3.2 ロール移行, 9.4.2.4 スナップショット・スタンバイ・データベース, 9.6 SQL Apply, 14.2.6.2 Standby-First Patchの適用, 14.2.3 Enterprise Managerのステータス・イベント, 12.2.4 スイッチオーバー, 14.2.1.3 データ・ポンプ

プラットフォーム移行用, 14.2.7.7

SYSTEM表領域の内容の移動, 14.2.7.8

データ・リカバリ・アドバイザ

データ破損の検出と防止, 5.2.2

データ維持バックアップ, 8.2.1 データ型の制限

拡張データ型サポート(EDS)による解決, 14.2.6.2.1

データ領域ディスク・グループ障害

「Data Guardフェイルオーバー」、「ファスト・スタート・フェイルオーバー」、「ローカル・リカバリ」も参照

データベース・ファイル

管理の最適化, 4.2

Oracle ASM統合, 4.2

リカバリ関連, 4.3.1

データベース・パッチ・アップグレード

推奨事項, 14.2.4.1

データベース・リソース・マネージャ, 5.2.10

ベスト・プラクティス, 5.2.10

Database Upgrade Assistant(DBUA), 14.2.6.1 データベースのアップグレード

エディションベースの再定義, 14.2.8

一時的なロジカル・スタンバイ・データベース, 14.2.6.2.2

データベース

ファイルの破損チェック, 8.5.2

構成の推奨事項, 5

MAAアドバイザを使用した構成, 12.3.4

パフォーマンス要件の評価, 4.1

移行, 14.2.7.5

オブジェクトの再編成, 14.2.10

分散環境でのリカバリ, 13.2.8

非一貫性の解決, 13.2.7.3

プライマリ・ロールとスタンバイ・ロールの切替え, 14.2.1.1

アップグレード, 14.2.6

DB_BLOCK_CHECKING初期化パラメータ, 5.1.6.1, 9.3.8.3 DB_BLOCK_CHECKSUM初期化パラメータ, 4.6.1, 5.1.6.1, 9.3.8.3 DB_CACHE_SIZE初期化パラメータ, 9.3.8.4 DB_CREATE_FILE_DEST初期化パラメータ

Oracle Managed Filesの有効化, 4.3.1

DB_CREATE_ONLINE_LOG_DEST_n初期化パラメータ

Oracle Managed Filesの場所, 4.3.1

DB_FLASHBACK_RETENTION_TARGETパラメータ, 5.1.4 DB_KEEP_CACHE_SIZE初期化パラメータ, 9.3.8.4 DB_LOST_WRITE_PROTECT初期化パラメータ 5.1.6.1, 9.3.8.3 DB_RECOVERY_FILE_DEST初期化パラメータ

高速リカバリ領域, 5.1.3

DB_RECOVERY_FILE_DEST_SIZE初期化パラメータ

高速リカバリ領域の制限, 5.1.3

DB_RECYCLE_CACHE_SIZE初期化パラメータ, 9.3.8.4 DBCA

クライアント接続の分散, 6.2.6

DBMS_DG.INITIATE_FS_FAILOVER PL/SQLプロシージャ

アプリケーション・フェイルオーバー, 13.2.4

DBMS_FLASHBACK.TRANSACTION_BACKOUT PL/SQLプロシージャ, 13.2.7.1 DBMS_REDEFINITION PL/SQLパッケージ, 14.2.10 DBVERIFYユーティリティ, 9.3.8.3 意思決定支援システム(DSS)

アプリケーション・ワークロード, 4.1

デフォルト一時表領域

指定, 5.2.8

DEFAULT TEMPORARY TABLESPACE句

CREATE DATABASE文, 5.2.8

SQLNET.ORAファイルのDEFAULT_SDU_SIZEパラメータ, 9.3.7.2 高密度波長分割多重方式(DWDMまたはダーク・ファイバ), 7.1.4 デバイス・マッパー

ディスクのマルチパス, 4.4.1

差分増分バックアップ・セット, 8.3 DISABLE BLOCK CHANGE TRACKING, 8.2.4 パラレル・リカバリの無効化, 5.1.10, 5.1.10 ディスク・バックアップ方法, 8.3 ディスク・デバイス

ASMLIBディスク名のデフォルト, 4.4.4

構成, 4.3.1, 4.3.2.1, 4.3.4

ディスク・ラベル, 4.4.4

マルチパス, 4.4.1

名前

ASM_DISKSTRINGパラメータ, 4.4.1

ASMLib, 4.4.6

Oracle ASMのパーティション化, 4.3.1 障害からの保護, 4.3.2 ディスク・エラー

ベンダー・ログのマイニング, 4.5.6

ディスク障害

保護, 4.3.2

冗長性の回復, 4.3.2.2

ディスク・グループ

V$ASM_DISK_IOSTATビューを使用したチェック, 4.5.5

構成, 4.3.1

サイズの決定, 4.3.2.2, 4.3.4

高速リカバリ領域の制限, 13.2.5.4

不均衡, 4.5.5

マウント, 4.5.3

障害後のオフライン化, 13.2.5.4

Oracle ASMインスタンスへのSYSASMでのアクセス, 4.5.1

ディスクのマルチパス, 4.4.1 DISK_ASYNCH_IO初期化パラメータ, 5.1.7, 9.3.8.6 DISK_REPAIR_TIMEパラメータ, 4.4.5 ディスク

Oracle ASMの障害, 13.2.5.2, 13.2.5.2

分散データベース

リカバリ, 13.2.8

DNSフェイルオーバー, 13.2.1.3 削除された表領域

フラッシュバック・データベースを使用した修正, 13.2.7.3

データベース・オブジェクトの削除, 13.2.7.1 二重障害

リストア, 13.3.7

DWDM

高密度波長分割多重方式, 7.1.4

E

エディションベースの再定義, 10.1.4, 14.2.8

ENABLE BLOCK CHANGE TRACKING, 8.2.4

エンディアン形式

決定, 14.2.7.3

Enterprise Manager

アラート, 12.2.1

ビーコン

アプリケーション・フェイルオーバー, 13.2.4

データベース・ターゲットのページ, 12.2.3 高可用性コンソール(HAコンソール), 12.3.3 ホームページ, 12.2.1 MAAアドバイザ, 12.3.4 Data Guardターゲットの管理, 12.3.3 パッチの管理, 12.3.2 メトリック, 12.2.1 通知ルール, 12.2.2, 12.2.3 パフォーマンス, 12.2.3 ポリシー違反, 12.3.1 ポリシー違反, 12.3.1 サポート・ワークベンチ, 12.2.2 Enterprise Managerの監視, 12.2 等式

スタンバイREDOログ・ファイル, 9.3.6

フェイルオーバー推定時間

Enterprise Managerのイベント, 12.2.4

Exadata Database Machine

MAAのベスト・プラクティス, 2.11

HARD, 4.6.1

拡張クラスタ

概要, 7.3

ASM_PREFERRED_READ_FAILURE_GROUPSパラメータの設定, 7.3.4

エクステント

ミラー化されたOracle ASM, 5.1.6.1, 5.1.6.1

外部冗長性

Oracle ASMのディスク障害, 13.2.5.2

Oracle ASMのサーバー・ベースのミラー化, 7.3.4

EXTERNAL REDUNDANCY句

CREATE DISKGROUP文, 4.3.2.1

抽出、変形およびロード(ETL)

アプリケーション・ワークロード, 4.1

F

フェイルオーバー

アプリケーション, 13.2.4

手動フェイルオーバーとファスト・スタート・フェイルオーバーの比較, 9.4.2.1

完全サイト, 13.2.1

定義, 13.2.2

説明, 13.2.2.2

ネットワーク・ルートへの影響, 13.2.1.3

高速アプリケーション通知(FAN), 9.3.1

高速接続フェイルオーバー, 11.5

手動

ベスト・プラクティス, 9.4.2.4

実行する場合, 9.4.2.1, 13.2.2.1

無停止, 4.4.1 スタンバイ・データベースのリストア, 13.3.2 障害検出

CRSレスポンス, 13.2.3.2

障害グループ

ASM冗長性, 4.3.5

定義, 4.3.2.2

複数ディスク障害, 13.2.5.4

拡張クラスタでの指定, 7.3.4

障害

Oracle ASMディスクのリバランス, 13.2.5.2

領域割当て, 5.2.9

高速アプリケーション通知(FAN), 6.1.1.2, 13.2.4

フェイルオーバー後, 9.3.1

高速接続フェイルオーバー, 11.5 高速ローカル再起動

高速リカバリ領域ディスク・グループ障害後, 13.2.5.4.1

高速リカバリ領域

バックアップ, 8.4.3

内容, 4.3.1

ディスク・グループ障害, 13.2.5.4

ディスクのパーティション化, 4.3.1

ローカル・リカバリの手順, 13.2.5.4.3

使用, 5.1.3

FAST_START_MTTR_TARGET初期化パラメータ, 5.1.10, 7.1.1

インスタンス・リカバリ時間の制御, 5.1.5

単一インスタンス環境での設定, 7.1.1

FAST_START_PARALLEL_ROLLBACK初期化パラメータ

トランザクション・リカバリで使用されるプロセスの数の決定, 7.1.2

ファスト・スタート・フェイルオーバー

手動フェイルオーバーとの比較, 9.4.2.1

ファスト・スタート・リカバリ

インスタンス・リカバリ, 5.1.5

FastStartFailoverAutoReinstate構成プロパティ, 13.3.2 フォルト・トレランス

ストレージ・サブシステムの構成, 4

リストア, 13.3

OPEN RESETLOGS後のリストア, 13.3.6

フラッシュ・リカバリ領域

「高速リカバリ領域」を参照, 12.3.3

フラッシュバック・データベース, 13.2.7, 13.2.7.3

有効化, 5.1.4, 5.1.4

Data Guard構成, 9.3.3

最大メモリーの設定, 5.1.8

フラッシュバック・ドロップ, 13.2.7, 13.2.7.1 フラッシュバック・テクノロジ

高速リカバリ領域ディスク・グループ障害, 13.2.5.4

フラッシュバック問合せ, 13.2.7, 13.2.7.2 フラッシュバック表, 13.2.7, 13.2.7.1 フラッシュバック・テクノロジ

例, 13.2.7.2

ユーザー・エラーからのリカバリ, 13.2.7

データベース全体の非一貫性の解決, 13.2.7.3

表領域の非一貫性の解決, 13.2.7.4

ソリューション, 13.2.7

フラッシュバック・トランザクション, 13.2.7

DBMS_FLASHBACK.TRANSACTION_BACKOUT PL/SQLプロシージャ, 13.2.7.1

フラッシュバック・トランザクション問合せ, 13.2.7, 13.2.7.2 フラッシュバック・バージョン問合せ, 13.2.7, 13.2.7.2 FORCE LOGGINGモード, 5.1.1, 9.3.4 全体データファイル・コピー, 8.3 全体バックアップ・セットまたはレベル0バックアップ・セット, 8.3

G

ギャップ解消

圧縮, 9.3.7.2

GoldenGate (Oracle GoldenGate), 10 Grid Control (Oracle Grid Control)

監視, 12.2

保証付きリストア・ポイント, 8.1.4 GV$SYSSTATビュー

ワークロード統計の収集, 4.1

H

HA (Oracle高可用性テクノロジ), 1.3

Hardware Assisted Resilient Data(HARD), 4.6.1

Hardware Assisted Resilient Data(HARD)

Oracle ASMを使用する場合, 4.3.5

ハードウェアRAIDストレージ・サブシステム

ミラー化の遅延, 7.3.4

高可用性

(HA)コンソール

データベースの監視, 12.3.3

説明, 1.1 ファスト・スタート・フェイルオーバー後のリストア, 13.3.2 高冗長性

Automatic Storage Management(Oracle ASM)

ディスク・グループ, 4.3.2.2

Oracle ASMのディスク障害, 13.2.5.2 Oracle ASMディスク・グループ, 4.3.1 ホスト・バス・アダプタ(HBA)

ロード・バランシング, 4.4.1

HRサービス

使用例, 13.3.1.1

人為的エラー

リカバリ, 13.2.7

I

不均衡なディスク・グループ

チェック, 4.5.5

増分バックアップ

BLOCK CHANGE TRACKING, 8.2.4

増分を更新したバックアップ, 8.3 初期化パラメータ

プライマリとフィジカル・スタンバイの例, 9.3.5

インスタンス障害

リカバリ, 5.1.5

単一, 13.2.3.1

インスタンス・リカバリ

ファスト・スタート・リカバリを使用した制御, 5.1.5

インターコネクト・サブネット

確認, 6.2.9

個別パッチ, 14.2.2 I/O操作

ロード・バランシング, 4.4.1

チューニング, 9.3.8.6

K

KEEP IDENTITY句, 14.2.6.2.2

KEEPオプション

RMAN BACKUPコマンド, 8.2.1

L

ライブラリ

Oracle ASMのASMLibのサポート, 4.4.6

リスナー接続速度制限, 11.5 リスナー

クライアントの分散, 6.2.6

接続速度リミッタ, 11.5

ロード・バランシング

アプリケーション・サービス, 13.3.1.3

クライアント接続, 6.2.6

I/O操作, 4.4.1

ディスクのマルチパスの使用, 4.4.1

LOAD_BALANCEパラメータ, 6.2.6, 11.1

クライアント接続の分散, 6.2.6

ローカル・ホーム

ローリング・パッチ時の使用, 6.2.2

ローカル・リカバリ

高速リカバリ領域ディスク・グループ障害後, 13.2.5.4.1

データ領域ディスク・グループ障害, 13.2.5.3

高速リカバリ領域ディスク・グループ障害, 13.2.5.4.3

ローカル管理表領域, 5.2.6

説明, 5.2.6

ログ適用サービス

ベスト・プラクティス, 9.3.8

LOG_ARCHIVE_DEST_n初期化パラメータ, 9.3.9 LOG_ARCHIVE_FORMAT初期化パラメータ, 9.3.5 LOG_ARCHIVE_MAX_PROCESSES初期化パラメータ, 9.3.7.1

複数スタンバイ環境での設定, 9.3.7.1

Oracle RACでの設定, 9.3.7.1

LOG_BUFFER初期化パラメータ, 5.1.4, 5.1.8 LOG_FILE_NAME_CONVERT初期化パラメータ, 9.4.1, 9.4.2.2 ロジカル・スタンバイ・データベース

フェイルオーバー, 13.2.2.3

スイッチオーバー, 14.2.1.3

アップグレード, 14.2.6.2

論理ユニット番号(LUN), 4.3.2.1

定義, Glossary

ログイン・ストーム

共有サーバーでの制御, 11.5

防止, 11.5

低帯域ネットワーク

圧縮, 9.3.7.2

低コストのストレージ・サブシステム, 4.1 LUN

「論理ユニット番号(LUN)」も参照

「論理ユニット番号(LUN)」も参照, 4.3.2.1

M

MAA

「Oracle Maximum Availability Architecture(MAA)」を参照

管理性

向上, 5.2

計画済の停止の管理, 14.1.1, 14.1.2 手動フェイルオーバー

ベスト・プラクティス, 9.4.2.4, 13.2.2.3

ファスト・スタート・フェイルオーバーとの比較, 9.4.2.1

実行する場合, 9.4.2.1, 13.2.2.1

「最大可用性アーキテクチャ(MAA)アドバイザ」ページ, 12.3.4 最大可用性モード

REDO転送の要件, 9.2.2

最大接続数

中間層接続プールでの調整, 11.5

最大パフォーマンス・モード

REDO転送の要件, 9.2.2

最大保護モード

初期化パラメータの例, 9.3.5

平均リカバリ時間(MTTR)

チェックポイント, 7.1.1

データ・リカバリ・アドバイザで減少, 5.2.2

メモリー使用量

MEMORY_TARGETパラメータによる管理, 4.4.2

メモリー管理, 5.1.9 MEMORY_TARGET初期化パラメータ, 4.4.2 メトリック

Enterprise Manager, 12.2.1

Enterprise ManagerのData Guard, 12.2.4

中間層接続プール

最大接続数の調整, 11.5

移行

計画, 14.2.7

トランスポータブル・データベース, 14.2.7.5

移行計画, 14.2.7.2 移行計画

計画済の停止, 14.2.7.1

領域使用量の最小化, 8.3 システム・リソース使用量の最小化, 8.3 ディスク・エラーに備えたベンダー・ログのマイニング, 4.5.6 ミラー・エクステント

データ破損からの保護, 5.1.6.1, 5.1.6.1

ミラー化

ストレージ・アレイ, 4.3.2.2

RAIDストレージ・サブシステムへの依存, 7.3.4

監視

アプリケーション・レスポンス時間, 13.2.4

Enterprise Manager, 12.2

Oracle Grid Control, 12.2

リバランス操作, 14.2.5.2.2

ディスク・グループのマウント, 4.5.3 マルチパス(ディスク)

パスの抽象化, 4.4.1

複数ディスク障害, 13.2.5.4

N

ネット・サービスのパラメータ

DEFAULT_SDU_SIZE, 9.3.7.2

RECV_BUF_SIZE, 9.3.7.2

SEND_BUF_SIZE, 9.3.7.2

TCP.NODELAY, 9.3.7.2

Network Attached Storage(NAS), 9.3.8.6 ネットワーク検出およびフェイルオーバー

OracleクラスタウェアとOracle RAC, 6.2.9

ネットワーク・ルート

サイト・フェイルオーバー後, 13.2.1.3

サイト・フェイルオーバー前, 13.2.1.3

ネットワーク・サーバー・プロセス(LNSn), Glossary ネットワーク・タイム・プロトコル(NTP), 6.2.8 NOCATALOGモード

バックアップの作成, 8.2.3

ノード障害

複数, 13.2.3.1

ノード

クライアント接続の移行, 6.1.1

無停止のフェイルオーバー, 4.4.1 標準冗長性

Oracle ASMのディスク障害, 13.2.5.2

NORMAL REDUNDANCY句

CREATE DISKGROUP文, 4.3.2.2

通知ルール

推奨事項, 12.2.3

監視に対する品質保証契約の影響, 12.2.2

通知

アプリケーション・フェイルオーバー, 13.2.4

NTP, 6.2.8

O

OCI_EVENTSパラメータ, 11.1

OCR

バックアップ, 6.3.2

障害, 13.2.3.3

リカバリ, 13.2.3.3

ocrconfig -showbackupコマンド, 6.3.2 OMF

Oracle Managed Filesを参照

オンライン・パッチ, 14.2.2 オンラインREDOログ・ファイル

多重化, 5.1.2

オンライン再編成および再定義, 14.2.10 オンライン・トランザクション処理(OLTP)

アプリケーション・ワークロード, 4.1

opatchコマンドライン・ユーティリティ, 14.2.4 最適化

リカバリ時間, 8.3

Oracle ACFSスナップショット, 8.6.1 Oracle ASM

「Oracle Automatic Storage Management (Oracle ASM)」を参照, 4.2

Oracle Auto Service Request (ASR), 2.10.2 Oracle Automatic Storage Management(Oracle ASM)

ASM_DISKSTRINGパラメータ, 4.4.1

ASMLib, 4.4.6

クラスタリングによるストレージ・グリッドの有効化, 4.2.1

ASMCAを使用した構成, 4.5.8

データベース・ファイルの管理, 4.2

ディスク・デバイス割当て, 4.3.1

ディスク障害, 13.2.5.2, 13.2.5.2

ディスク・グループのサイズ, 4.3.2.2, 4.3.4

障害グループ, 7.3.4

障害グループと冗長性, 4.3.5

ディスク・エラーの処理, 4.5.6

HARD準拠ストレージ, 4.3.5

不均衡なディスク・グループ, 4.5.5

MEMORY_TARGETパラメータによるメモリーの管理, 4.4.2

ASMCMDによる管理, 4.5.7

データベースの移行, 14.2.5.2.1

複数ディスク障害, 13.2.5.4

Oracle Restart, 4.2.2

高速リバランスの最大能力, 4.6.2

リバランスの能力, 4.5.2

リバランス, 4.5.4

障害後のディスクのリバランス, 13.2.5.2

リカバリ, 13.2.5

冗長性, 4.3.2.2, 5.1.6.1, 5.1.6.1

ローリング・アップグレード, 14.2.5.2.3

サーバー・ベースのミラー化, 7.3.4

SYSASMロール, 4.5.1, 4.5.1

ディスク・ラベルの使用, 4.4.4

標準冗長性または高冗長性の使用, 4.3.2.2, 7.3.4

ボリューム・マネージャ, 7.3.4

ディスクのマルチパス・ソフトウェア, 4.4.1

Oracle Cluster Registry(OCR)

障害, 13.2.3.3

Oracleクラスタウェア

キャパシティ・プランニング, 6.3.1

CTSS時間管理, 6.2.8

システム・メンテナンス, 14.2.11

インターコネクト・サブネットの確認, 6.2.9

Oracle Data Guard

「Data Guard」を参照, 9

Oracle Data Pump

プラットフォーム移行用, 14.2.7.7

プラットフォーム移行, 14.2.7.7

Oracle Database 11g

構成の推奨事項, 5

Data Guard, 9

拡張クラスタの構成, 7.3 Oracle RAC構成の推奨事項, 7.1 Oracle Enterprise Manager

高可用性(HA)コンソール, 12.3.3

MAAアドバイザのページ, 12.3.4

Oracleフラッシュバック・データベース

フォルト・トレランスの構成へのリストア, 13.3.2

Oracle GoldenGate

Oracle RAC, 10.1.2

ベスト・プラクティス, 10

構成, 10

データベース移行, 14.2.7.6

データベース・アップグレード, 14.2.6.3

概要, 10

replicatコミット, 10.2.3

replicatのCOMMIT NOWAIT, 10.2.3

アップグレード, 14.2.6.3

Oracle Data Guard, 10.1.3

Oracle Grid Control

ホームページ, 12.2.1

監視, 12.2

Oracle高可用性テクノロジ, 1.3 Oracle Managed Files(OMF)

データベース・ファイルの管理, 4.3.1

ディスクおよびディスク・グループの構成, 4.3.1

高速リカバリ領域, 5.1.3

Oracle Management Agent, 12.2

ターゲットの監視, 12.2

Oracle Maximum Availability Architecture(MAA)

定義, Glossary

説明, 1.3

Webサイト, 1.3

Oracle Notification Service(ONS)

フェイルオーバー後, 9.3.1

Oracle RACローリング・パッチ・アップグレード, 14.2.4 Oracle Real Application Clusters(Oracle RAC)

ノードへのディスクの追加, 4.4.6

アプリケーション・フェイルオーバー, 13.2.4

構成, 7.1

拡張クラスタ, 7.3

ネットワーク検出およびフェイルオーバー, 6.2.9

スイッチオーバーの準備, 9.4.1

計画外の停止からのリカバリ, 13.2.3

障害ノードまたはインスタンスのリストア, 13.3.1

ローリング・アップグレード, 14.2.4

ローリング・アップグレード, 14.2.4

LOG_ARCHIVE_MAX_PROCESSES初期化パラメータの設定, 9.3.7.1

システム・メンテナンス, 14.2.11

冗長専用接続の使用, 7.1.4

インターコネクト・サブネットの確認, 6.2.9

投票ディスク, 6.2.7, 7.3.2, 13.2.3.3

Oracle Restart, 4.2.2, 5.2.1 Oracle Secure Backup, 8.1.3

OCRのバックアップ, 6.3.2

Oracleストレージ・グリッド, 4.6 Oracle Streams

Oracle GoldenGate, 10.1.1

オラクルのSun ZFS Storage Appliance, 8.6.2 Oracle Universal Installer, 14.2.4.2 停止

計画外, 13.1

P

パラレル・リカバリ

無効化, 5.1.10

PARALLEL_EXECUTION_MESSAGE_SIZEパラメータ, 5.1.4 パーティション

Oracle ASMで使用するためのディスクの割当て, 2.1.5

パッチ・セット

ローリング・アップグレード, 14.2.4

パッチ

Enterprise Managerでの管理, 12.3.2

ローリング, 6.2.2

共有クラスタ・ファイル・システムの使用, 6.2.2

パス障害

保護, 4.4.1

パフォーマンス

アプリケーション, ビーコンでの追跡, 12.2.2

非同期ディスクI/O, 5.1.7

自動チューニング, 5.2.3

Data Guard, 9.7

データベース、収集要件, 4.1

フィジカル・スタンバイ・データベース

スナップショット・スタンバイ・データベース, 9.6

フェイルオーバー, 13.2.2.3

ロケーション移行, 14.2.7.9

リアルタイム問合せ, 9.5

スイッチオーバー, 14.2.1.3

プラットフォーム移行, 14.2.6

エンディアン形式, 14.2.7.3

フィジカル・スタンバイ・データベース, 14.2.7.4

ポイント・イン・タイム・リカバリ

TSPITR, 13.2.7.4

プール

サイズ変更, 5.1.9

最大能力

リバランスの設定, 4.6.2

優先読取り障害グループ

Oracle ASMの指定, 7.3.4

ログイン・ストームの阻止, 11.5 プライマリ・データベース

ファスト・スタート・フェイルオーバー後の復元, 13.3.2

フォルト・トレランスのリストア, 13.3.6

PROCESSES初期化パラメータ, 4.4.3

Q

クォーラム・ディスク

投票ディスク, 7.3.2

R

RAID保護, 4.3.2.1

リアルタイム適用

スイッチオーバー用構成, 9.4.1

リアルタイム問合せ

Active Data Guardオプション, 9.5

リバランス操作, 4.5.2

監視, 14.2.5.2.2

Oracle ASMディスク・パーティション, 4.3.1, 4.3.1

リバランスの能力

制限, 4.5.2

リバランス, 4.5.4

Oracle ASMディスク・グループ, 4.5.2, 4.5.5

障害後のOracle ASMのディスク, 13.2.5.2

Oracle ASM最大能力の設定, 4.6.2

推奨事項

データベース構成, 5

リカバリ

時間ベースの協調分散データベース・リカバリ, 13.2.8

高速リカバリ領域のオプション, 13.2.5.4

計画外の停止の手順, 13.1.1

テスト手順, 8.5.3

時間の最適化, 8.3

リカバリ・カタログ

定期バックアップに含む, 8.5.4

RMANリポジトリ, 8.2.2

リカバリ・ファイル

リカバリ領域の場所に作成されるファイル, 5.1.3

Recovery Manager

「RMAN」も参照

リカバリ・ポイント目標(RPO)

データの重大性, 8.2.1

定義, Glossary

データ領域ディスク・グループ障害, 13.2.5.3

ディスク・グループ障害の解消, 13.2.5.4

リカバリ時間目標(RTO)

定義, Glossary

説明, 13.2.1.2

データ領域ディスク・グループ障害, 13.2.5.3

リカバリ時間, 8.2.1

ディスク・グループ障害の解消, 13.2.5.4

RECOVERY_ESTIMATED_IOS初期化パラメータ

パラレル・リカバリ, 5.1.10

RECOVERY_PARALLELISM初期化パラメータ, 5.1.10, 5.1.10 SQLNET.ORAのRECV_BUF_SIZEパラメータ, 9.3.7.2 ごみ箱, 13.2.7.1 REDO Apply

リアルタイム問合せ, 9.5

REDO Apply速度

Enterprise Managerのイベント, 12.2.4

REDOデータ

圧縮, 9.3.7.2

REDOログ・メンバー

高速リカバリ領域ディスク・グループ障害, 13.2.5.4

REDO転送サービス

ベスト・プラクティス, 9.2.1

冗長性

自動ストレージ管理(Oracle ASM), 4.3.2.2

CREATE DISKGROUP DATA文, 4.3.2.1

専用接続, 7.1.4

ディスク・デバイス, 4.3.2

ディスク障害後の回復, 4.3.2.2

復元, 13.3.2

FastStartFailoverAutoReinstateプロパティ, 13.3.2

リモート・アーカイブ, 9.3.5 REMOTE_LISTENERパラメータ, 6.2.5, 6.2.6 プライマリ・データベースでのリセットログ操作

スタンバイ・データベースのリストア, 13.3.6

リソース使用量

最小化, 8.3

リソース管理

データベース・リソース・マネージャの使用, 5.2.10

レスポンス時間

速度低下の検出, 13.2.4

リストア・ポイント, 8.1.4 リストア

クライアント接続, 13.3.1.3

障害インスタンス, 13.3.1

障害ノード, 13.3.1

サービス, 13.3.1.1

再開可能領域割当て, 5.2.9, 5.2.9 RESUMABLE_TIMEOUT初期化パラメータ, 5.2.9 RESYNC CATALOGコマンド

バックアップ情報の再同期, 8.2.3

RETENTION GUARANTEE句, 5.2.5, 5.2.5, 8.2.7 バックアップの保存ポリシー, 8.2.1 RMAN

UNDOのバックアップの最適化, 8.1.3

BACKUP VALIDATEコマンド, 9.3.8.3

チェックサムの計算, 5.1.6.1

スタンバイ・データベースの作成, 9.3.2

データベース・バックアップ, 8.1.2

DUPLICATEコマンド, 8.5.3

DUPLICATE TARGET DATABASE FOR STANDBYコマンド, 9.3.2

FROM ACTIVE DATABASEコマンド, 9.3.2

リカバリ・カタログ, 8.2.2

TSPITR, 13.2.7.4

未使用ブロックの圧縮, 8.1.3

VALIDATEコマンド, 8.5.2

RMAN BACKUPコマンド

KEEPオプション, 8.2.1

ロール移行

ベスト・プラクティス, 9.4.2.4

ロール・ベースの宛先, 9.3.5 ローリング・パッチ, 6.2.2 ローリング・アップグレード

Oracle RAC, 14.2.4

ローリング・アップグレード

パッチ・セット, 14.2.4

行およびトランザクションの非一貫性, 13.2.7.2 RPO

「リカバリ・ポイント目標(RPO)」を参照

RTO

「リカバリ時間目標(RTO)」を参照

S

SALESの使用例

初期化パラメータの設定, 9.3.5

SAME

「全ディスクのストライプ化とミラー化(SAME)」を参照

使用例

ファスト・スタート・フェイルオーバー, 13.3.2.1

HRサービス, 13.3.1.1

オブジェクトの再編成, 14.2.10

Oracle ASMディスク障害と修復, 13.2.5.2.1

人為的エラーからのリカバリ, 13.2.7.2

SALES, 9.3.5

計画済の停止

Data Guard Standby-First Patchの適用, 14.2.3

説明, 14.1

エディションベースの再定義, 14.2.8

移行, 14.2.7

移行計画, 14.2.7.2

移行計画, 14.2.7.1

オンライン・パッチ, 14.2.2

Oracle ASM

ローリング・アップグレード, 14.2.5.2.3

Oracle Real Application Clusters (Oracle RAC)ローリング・パッチ・アップグレード, 14.2.4 プラットフォーム移行, 14.2.7.4 プライマリ・サイト, 14.1.1 推奨ソリューション, 14.1.1, 14.1.2 停止時間の短縮, 14.2 セカンダリ・サイト, 14.1.2 スイッチバック, 14.2.1 スイッチオーバー, 14.2.1 トランスポータブル表領域のアップグレード, 14.2.6.4 Oracle GoldenGateを使用したアップグレード, 14.2.6.3 「計画外の停止」も参照 セカンダリ・サイトの停止

スタンバイ・データベースのリストア, 13.3.4

SQLNET.ORAのSEND_BUF_SIZEパラメータ, 9.3.7.2 サーバー・パラメータ・ファイル(SPFILE), 5.2.4, 9.3.5

RMANを使用したバックアップ, 8.2.5

サーバー・ベースのミラー化

Oracle ASM, 7.3.4

サービス可用性

リカバリ, 13.3.1.1

品質保証契約(SLA), 1.3

監視と通知に対する影響, 12.2.2

サービス・テストとビーコン

構成, 12.2.2

SERVICE_TIME

サービス・レベルの目標値, 6.2.6

サービス

FAN, 6.1.1.1

自動再配置, 13.2.3.2

定義, 6.1.1.1

高可用性の保証, 6.2.3

Oracle RACアプリケーション・フェイルオーバー, 13.2.4

Oracle RACアプリケーション・ワークロード, 6.2.5

アプリケーション・フェイルオーバー後の再配置, 13.2.4

管理用ツール, 6.2.5

SGA_TARGET初期化パラメータ, 5.1.9 共有サーバー

Oracle Databaseの構成, 11.5

サイト・フェイルオーバー

ネットワーク・ルート, 13.2.1.3

SMONプロセス

稼働を続ける最後のインスタンス, 7.1.1

ソート操作

向上, 5.2.8

領域管理, 5.2.7 領域使用量

最小化, 8.3

SQLアクセス・アドバイザ, 5.2.3 SQL Apply, 14.2.6.2 SQLチューニング・アドバイザ, 5.2.3 SRVCTL

Oracle Restart, 4.2.2

スタンバイ・データベース

複数の構成, 9.3.9

作成, 9.3.2

リストア, 13.3.2

スタンバイREDOログ・ファイル

数の決定, 9.3.6

Standby-First Patchの適用(Data Guard), 14.2.3 STATISTICS_LEVEL初期化パラメータ, 9.7 Statspack

データベース待機の評価, 9.3.8.5

ストレージ

RAIDへのミラー化, 7.3.4

Storage Appliance, 8.6.2 Storage Area Network(SAN), 9.3.8.6 ストレージ・アレイ

ミラー化, 4.3.2.2

複数ディスク障害, 13.2.5.4

ストレージ・グリッド

クラスタOracle ASMの使用, 4.2.1

ストレージ・サブシステム, 4

Oracle ASMの構成, 4.2

冗長性の構成, 4.3.2

パフォーマンス要件, 4.1

全ディスクのストライプ化とミラー化(SAME), 4.2 サポート・ワークベンチ, 12.2.2 スイッチオーバー

リアルタイム適用の構成, 9.4.1

説明, 14.2.1.1

Oracle RAC, 9.4.1

アーカイバ(ARCn)プロセスの削減, 9.4.1

「Data Guard」も参照

LOG_FILE_NAME_CONVERT初期化パラメータの設定, 9.4.1

ロジカル・スタンバイ・データベース, 14.2.1.3

フィジカル・スタンバイ・データベース, 14.2.1.3

SYSASMロール

Oracle ASM認証, 4.5.1

システム障害

リカバリ, 5.1.5

システム・メンテナンス, 14.2.11 システム・リソース

評価, 9.3.8.7

SYSTEM表領域

内容の移動, 14.2.7.8

T

表の非一貫性, 13.2.7.1

表領域のPoint-in-Timeリカバリ(TSPITR), 13.2.7.4

表領域

ローカル管理, 5.2.6

非一貫性の解決, 13.2.7.4

一時的, 5.2.8, 5.2.8

ターゲット

Enterprise Manager, 12.2

監視, 12.2

TCP Nagleアルゴリズム

無効化, 9.3.7.2

SQLNET.ORAのTCP.NODELAYパラメータ, 9.3.7.2 一時表領域, 5.2.8, 5.2.8 THROUGHPUT

サービス・レベルの目標値, 6.2.6

トランザクション・リカバリ

使用されるプロセスの数の決定, 7.1.2

一時ロジカル・スタンバイ・データベース

ローリング・アップグレード, 14.2.6.2.2

トランスポート・ラグ

Enterprise Managerのイベント, 12.2.4

トランスポータブル・データベース, 14.2.7.5 トランスポータブル表領域

データベース・アップグレード, 14.2.6.4

プラットフォーム移行, 14.2.7.8

U

UNDO保存期間

チューニング, 5.2.5

UNDO領域

管理, 5.2.5

UNDO_MANAGEMENT初期化パラメータ, 8.2.7

自動UNDO管理, 5.2.5

UNDO_RETENTION初期化パラメータ, 8.2.7

自動UNDO管理, 5.2.5

UNDO_TABLESPACE初期化パラメータ

自動UNDO管理, 5.2.5

計画外の停止

Data Guardスイッチオーバー, 14.2.1.3

説明, 13.1

Oracle RACリカバリ, 13.2.3

リカバリ, 13.1.1, 13.2

種類, 13.1

「計画済の停止」も参照

未使用ブロックの圧縮, 8.1.3 アップグレード

アプリケーション, 14.2.9

個別パッチの適用, 14.2.2

ベスト・プラクティス, 14.2.4.1

Database Upgrade Assistant(DBUA), 14.2.6.1

メソッド, 14.2.6

オンライン・パッチ, 14.2.2

Oracle RACローリング

ベスト・プラクティス, 14.2.4.2

USABLE_FILE_MB列

V$ASM_DISKGROUPビュー, 4.3.2.2

ユーザー・エラー

フラッシュバック・テクノロジ, 13.2.7

V

V$ASM_DISKビュー, 9.3.8.7

V$ASM_DISK_IOSTATビュー

ディスク・グループの不均衡のチェック, 4.5.5

V$ASM_DISKGROUPビュー

REQUIRED_MIRROR_FREE_MB列, 4.3.2.2

USABLE_FILE_MB列, 4.3.2.2

V$ASM_OPERATIONビュー

リバランス操作の監視, 14.2.5.2.2

V$EVENT_HISTOGRAMビュー, 9.3.8.5 V$INSTANCE_RECOVERYビュー

リカバリ・プロセスのチューニング, 5.1.10

V$IOSTAT_FILEビュー

非同期I/O, 5.1.7

V$OSSTATビュー, 9.3.8.7, 9.7 V$SESSION_WAITビュー, 9.3.8.5 V$SYSMETRIC_HISTORYビュー, 9.7 V$SYSMETRIC_SUMMARYビュー, 9.7 V$SYSTEM_EVENTビュー, 9.3.8.5, 9.3.8.7 VALID_FOR属性, 9.3.5 VALIDATEオプション

RMAN BACKUPコマンド, 9.3.8.3

検証

RMANバックアップ時のチェックサム, 5.1.6.1

インターコネクト・サブネットの確認, 6.2.9 VIPアドレス

アプリケーションへの接続, 6.2.5

説明, 6.2.5

リカバリ時, 13.3.1.1

仮想インターネット・プロトコル(VIP)・アドレス

「VIPアドレス」を参照

ボリューム・マネージャ

Oracle ASM, 7.3.4

投票ディスク(Oracle RAC)

ベスト・プラクティス, 6.2.7

破損, 13.2.3.3

クォーラム・ディスク, 7.3.2

W

待機イベント

Active Data GuardおよびStatspackによる評価, 9.3.8.5

Webサイト

ASMLib, 4.4.6

MAA, 1.3

ワークロード

例, 4.1

統計の収集, 4.1

Z

ZFS Storage Appliance, 8.6.2

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。