| Oracle® Database高可用性ベスト・プラクティス 12cリリース1 (12.1) E57730-02 |
|
 前 |
 次 |
この章では、管理性とパフォーマンスを維持しながらデータを保護するフォルト・トレラントなストレージ・サブシステムを構成するためのベスト・プラクティスについて説明します。これらのプラクティスは、『Oracle Database高可用性概要』に記載されているOracleデータベースのすべての高可用性アーキテクチャに適用されます。
この章には、次の項目が含まれます。
様々なアプリケーション・ワークロードを使用して、現在のデータベースのパフォーマンス要件を分類します。ターゲット・ワークロードの処理中に統計を抽出するため、開始時と終了時の統計スナップショットを収集します。ターゲット・ワークロードの例は、次のとおりです。
平均負荷
ピーク負荷
バッチ処理などのアプリケーション・ワークロード、オンライン・トランザクション処理(OLTP)、意思決定支援システム(DSS)およびレポート作成、ETL(Extraction, Transformation and Loading)
データベース・パフォーマンス要件の評価
必要な統計は、自動ワークロード・リポジトリ(AWR)・レポートを使用するか、GV$SYSSTATビューを問い合せることで収集できます。データベースのパフォーマンス要件を理解すると同時に、ストレージ・アレイのパフォーマンス性能を評価する必要があります。
ストレージの選択
パフォーマンス要件と容量要件を把握したら、要件に適合するストレージ・プラットフォームを選択します。
|
関連項目: 自動ワークロード・リポジトリ(AWR)と自動ワークロード・リポジトリ・レポートの生成の概要は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
Oracle ASMは、特にOracleデータベース・ファイル用に構築されたファイル・システムとボリューム・マネージャの両方を垂直統合したものです。Oracle ASMにより、パフォーマンスの最適化のためにすべてのディスクをストライプ化してミラー化する(SAME)という概念が拡張される一方で、手動によるI/Oチューニングを行う必要がなくなります(データファイルのレイアウトはホット・スポットを避けるように分散されます)。Oracle ASMでは、ストレージ割当てを調整するためにデータベースを停止することなくデータベース・サイズを拡張することで、動的にデータベース環境を管理できます。また、Oracle ASMによるミラー化とストライプ化のサポートにより、低コストのモジュール型ストレージで優れたパフォーマンスと高度な可用性を実現できます。
Oracle ASMはドライブやSANの障害に対処するデータ保護を提供します。パフォーマンスはきわめて優秀で、構成や再構成のオプションは非常に柔軟性に富んでいます。Oracle ASMはすべての使用可能なドライバに対してデータを自動的に分散し、ストレージがデータベースから追加または削除された場合、透過的かつ動的にデータを再分散します。
Oracle ASMはすべてのデータベース・ファイルを管理します。最初は高速リカバリ領域のみをサポートして現在の環境にOracle ASMを段階的に導入します。
|
注意: 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管理者ガイド』を参照してください。 |
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 ASMの戦略的ベスト・プラクティスを使用します。
ミッション・クリティカルなアプリケーションには、Oracleの高冗長性ディスク・グループ(3通りのミラー化)か、または同等のミラー化復元性を備える外部冗長性ディスク・グループを使用することをお薦めします。この高レベルのミラー化によって、保護レベルが向上し、各種のストレージ障害の許容度も上がります。これは特に、ストレージのサブセットがパッチ適用またはアップグレードのためにオフラインになっている際の計画メンテナンス・ウィンドウにおいて実現されます。冗長性の詳細は、第3章「冗長性を使用したディスク障害からの保護」を参照してください。
データベース記憶域にOracle ASMを使用する場合、少なくとも2つのディスク・グループ(データ領域用のディスク・グループと高速リカバリ領域用のディスク・グループ)を作成します。また、OCRファイルと投票ファイルをそれぞれのディスク・グループに含めることをお薦めします。
データ領域: 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の詳細は、3.4.5項「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つのオプションがあります。
複数のディスク全体をデータ領域のディスク・グループと高速リカバリ領域のディスク・グループに割り当てます。図3-1は、ディスク全体を割り当てる方法を示しています。
各ディスクを2つのパーティションに分割し、1つをデータ領域に、もう1つを高速リカバリ領域に割り当てます。図3-2は、各ディスクの2つのパーティションへのパーティション化を示しています。
図3-1に示されるオプションのメリットは次のとおりです。
各ディスクを1つの大きなパーティションとして分割しているため、オペレーティング・システム・レベルでディスク・パーティションを管理することが容易です。
ディスク障害後のOracle ASMによるリバランス操作が、1つのディスク・グループのみをリバランスすればよいため、迅速に完了します。
障害の分離。これによって、ストレージ障害では影響を受けるディスク・グループのみがオフラインになります。
パッチ適用の分離。これによって、すべてのディスクに適用しなくても、各ディスクや、個々のディスクのファームウェアにパッチを適用できます。
図3-1に示されるオプションのデメリットは次のとおりです。
各ディスク・グループが使用可能なディスクのサブセットに単純に分散されるため、I/O帯域幅が小さくなります。
図3-2は、各ディスクに2つのパーティションが存在するパーティション化オプションを示しています。このオプションでは各ディスクを2つのパーティションに分割する必要があります。各ドライブの高速な外側部分にある小さいパーティションをデータ領域用とし、各ドライブの低速な内側部分にある大きいパーティションを高速リカバリ領域用とします。内側のパーティション・サイズと外側のパーティション・サイズの割合は、データ領域と高速リカバリ領域の推定サイズに応じて変化します。
図3-2に示されるパーティション化のオプションのメリットは次のとおりです。
パフォーマンスおよびスケーラビリティの点で、柔軟性と管理性が向上します。
使用可能なすべてのスピンドルに両方のディスク・グループが分散されるため、使用できるI/O帯域幅が大きくなります。このメリットは、I/O集中型のアプリケーションで使用されるデータ領域用のディスク・グループでは重要です。
I/O容量が十分である場合、オンラインREDOログまたはスタンバイREDOログに、分離された専用のストレージを持つ別個のディスク・グループを作成する必要がありません。
ディスクの低速な部分を高速リカバリ領域に、またディスクの高速な部分をデータ領域用に使用できます。
図3-2に示されるパーティション化のオプションのデメリットは次のとおりです。
二重パートナ・ディスク障害が発生すると、両方のディスク・グループが失われる可能性があります。この場合、リカバリのためにスタンバイ・データベースまたはテープ・バックアップを使用する必要があります。この問題は、高冗長性のASMディスク・グループの使用時には発生しません。
ディスク障害後のOracle ASMによるリバランス操作は、両方のディスク・グループが対象となるため、時間がかかります。
|
関連項目:
|
冗長性を設定してハードウェア障害から保護する場合、検討する必要のあるオプションは次の2つです。
|
関連項目:
|
堅牢な組込み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';
ストレージ・アレイによって真の冗長性が物理ディスク間に提供されるようにする必要があります。仮想ディスクを使用している場合、別々の物理ディスク上にあるミラー・コピーを使用して冗長性が確立されるようにする必要があります。
Exadataシステムには外部冗長性がサポートされていません。標準冗長性または高冗長性のディスク・グループを選択する必要があります。
|
関連項目:
|
Oracle ASM では、障害グループを使用した冗長性が提供されます(障害グループはディスク・グループ作成時に定義します)。ディスク・グループのタイプによって、Oracle ASMのファイルのミラー化の方法が決定されます。ディスク・グループを作成するとき、そのディスク・グループが 通常の冗長性 ディスク・グループ(デフォルトによる2通りのミラー化)か、 高冗長性 ディスク・グループ(3通りのミラー化)か、または 外部冗長性 ディスク・グループ(Oracle ASMによるミラー化なし)かを指示します。ストレージ・システムがハードウェア・レベルでミラー化されているか、または冗長データを必要としない場合は、外部冗長性ディスク・グループを使用します。デフォルトのディスク・グループ・タイプは、通常の冗長性です。ディスク・グループが作成された後で冗長性レベルを変更することはできません。
ASMレベルの冗長性を使用する主なメリットは次のとおりです。
全ディスクにまたがるストライプ化に起因するホット・スポットの削除
ディスクの追加または削除時の、データおよびI/Oのリバランスと再分散の簡略化
ASMによって別のミラー・コピーで適切なエクステントが利用される場合の、データ破損の自動修復
破損データ・ブロックが検出され、ASMレベルの冗長性が使用されている場合、Oracleではそのミラーが自動的にチェックされます。ミラーが破損していない場合、アプリケーションでエラーが発生することはなく、初期ミラーの破損ブロックはOracle ASMによって自動的に修正されます。Oracle ExadataおよびOracle SuperClusterでは、前述のメリットのため、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日でデータベース管理者』を参照してください。 |
Oracle Automatic Storage Management (Oracle ASM)およびOracle Clusterwareは、Gridホームと呼ばれる単一のホーム・ディレクトリにインストールされます。クラスタ・ソフトウェア用のOracle Grid Infrastructureは、組み合された製品のインストールを参照します。Gridホームは、同じサーバー上にインストールされている他のOracleソフトウェア製品のホーム・ディレクトリとは異なります。
|
関連項目: Oracle ASMおよびGridホームの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。 |
Oracle Database 12cでは同一サイズのLUNと同一容量の障害グループが強制され、同一ディスク・グループ内のすべてのディスクに同じサイズとパフォーマンス特性を割り当てる必要はありませんが、そうすることで全体的なパフォーマンスおよび領域使用率が予測しやすくなります。可能であれば、Oracle ASMに対して、ディスクとOracle ASM間に抽象化レイヤーを作成する論理ユニット番号(LUN)ではなく、物理ディスク(スピンドル)を割り当てます。
ディスクが同じサイズであると、Oracle ASMはディスク・グループのすべてのディスクに均等にファイルを分散できます。この割当てパターンでは、すべてのディスクが同じ容量レベルに維持されるため、ディスク・グループのすべてのディスクに同じI/O負荷が割り当てられます。Oracle ASMは、ディスク・グループのすべてのディスク間でワークロードを負荷分散するため、異なるOracle ASMディスクで同じ物理ドライブを共有することはできません。
|
関連項目: Oracle ASMディスク・グループの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
障害グループを使用して共通障害コンポーネントを定義することで、そのコンポーネントに障害が発生してもデータに継続的にアクセスできます。保護を最大化する場合、標準冗長性では最低3つの障害グループを使用し、高冗長性では最低5つの障害グループを使用します。これにより、Oracle ASMでは、障害グループの複数の障害に対応でき、完全な冗長性なしでOracle ASMが稼働する混乱状態を回避できます。
インテリジェント・データ配置により、最高のパフォーマンスを実現するためにOracle ASMディスク上のディスク・リージョンを指定できます。ディスク・リージョン設定を使用すると、アクセス頻度の高いデータを、より高速でバンド幅も大きい一番外側の(ホット)トラックに確実に配置できます。また、アクセス・パターンが似ているファイルは物理的に近くに配置され、待機時間が短縮されます。異なるホット・リージョンまたはコールド・リージョンに、プライマリ・エクステントおよびミラー・エクステントを配置することもできます。
|
関連項目: インテリジェント・データ配置の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
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管理者ガイド』を参照してください。 |
次のようなOracle ASMの構成ベスト・プラクティスを使用します。
ディスクのマルチパス・ソフトウェアでは、複数の独立した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の構成』を参照してください。
|
|
関連項目:
|
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インスタンスに接続しているデータベース・インスタンスの数です。
|
関連項目:
|
ディスク・ラベルにより、再起動を行ってもディスクへの一貫性のあるアクセスが可能になります。ASMLibは、ディスク・ラベル作成のための推奨ツールです。ASMLibの詳細は、3.4.5項「ASMLibのサポート対象プラットフォームでの使用」を参照してください。
Oracle Database 12cでは、ディスク・グループ属性FAILGROUP_REPAIR_TIMEにより、障害グループのディスクを削除する前に障害グループ全体がオフラインになる時間が決まります。これは、より複雑なコンポーネントを修復するのに十分な時間を与えるために、デフォルトで24時間に設定されます。このようなコンポーネントの修復時間が24時間を超えても、影響を受けるディスク・グループを完全にリバランスするのにかかる時間を下回る場合は、この時間を変更します。
DISK_REPAIR_TIMEディスク・グループ属性では、Oracle ASMでディスクを削除するまでにそのディスクをオフラインのままにしておく期間を指定します。DISK_REPAIR_TIMEパラメータの期限前にディスクを使用可能にする場合、ストレージ管理者は、ONLINE DISKコマンドを発行できます。Oracle ASMでは、ミラー側から失効データが再同期されます。ディスクが稼働中のインスタンスに障害が発生しても、オンライン・ディスク操作は再起動されません。ディスクをオンラインにするには、手動でコマンドを再発行する必要があります。
ディスク修復時間属性をディスク・グループに対して設定することで、オフライン状態がどれくらい続いた場合にディスクを削除するかを指定することができます。環境に適した設定は、典型的な種類の一時的障害がどれくらいの間、持続すると予想されるかによって異なります。
DISK_REPAIR_TIMEディスク・グループ属性には、ディスクが稼働していないと確実にみなせるまでの最大期間を設定してください。
|
関連項目: 一時的なディスク・パス障害後にOracle ASMディスク・グループの冗長性をリストアする方法の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
管理性を向上するため、プラットフォーム上で使用可能な場合にはASMLibを使用してください。ASMLibはOracle ASMのサポート・ライブラリです。
ASMLibはOracle ASMの実行に必要ありませんが、ASMLibを使用すると次のメリットがあります。
すべてのOracleプロセスでOracle ASMディスクごとにファイル記述子をオープンする必要がなくなるため、システム・リソースの使用率が向上します。
ディスク・デバイス名の管理が容易になり、検出プロセスが簡単になると同時に、あるノードに追加されたディスクがクラスタ内の他のノードに認識されないといった問題を回避できます。
システムの再起動時にディスク・デバイス名のマッピングが変化する場合にその影響を回避できます。
|
注意: ASMLibはすべてのプラットフォームでサポートされているわけではありません。 |
|
関連項目:
|
ディスク・グループごとのLUN (Oracle ASMディスク)の数は、アクティブなI/Oパスの数の少なくとも4倍である必要があります。たとえば、ディスク・グループにアクティブなI/Oパスが2つある場合、少なくとも8つのLUNを使用する必要があります。LUNのサイズおよびパフォーマンスは、各ディスク・グループで同じである必要があります。
I/Oパスは、LUNを提供するストレージとサーバー間の個別のチャネルまたは接続です。アクティブなI/Oパスは、LUNのI/O負荷がマルチパス・ソフトウェアによって多重化されるI/Oパスです。
ディスク・グループ内のすべてのOracle ASMディスクは、ほぼ同じストレージ・パフォーマンスと可用性の特性を備えている必要があります。フラッシュ・メモリー・ドライブやハードディスク・ドライブ(HDD)など、様々な速度のドライブを使用したストレージ構成では、最も遅い速度のドライブによってI/Oパフォーマンスが制約されます。
Oracle ASMのデータ分散ポリシーは容量に基づいています。ディスク・グループ内のOracle ASMディスクは、均衡を保つために同じ容量となるようにします。
Oracle ASMディスク・グループにディスクを割り当てることで、Oracle ASMディスクと他のアプリケーション間のI/O競合を最小限に抑えます。
2の累乗であり、かつOracle ASM割当て単位のサイズ以下であるハードウェアRAIDストライプ・サイズを選択します。
パートナ・ステータス表(PST)の必要な数のコピーを維持し、ストレージ・ハードウェアの障害に関する堅牢性を確保するには、標準冗長性ディスク・グループでは3つ以上の障害グループ、高冗長性ディスク・グループでは5つ以上の障害グループをを構成します。
高性能のストレージ・アレイを使用する場合は、外部冗長性のディスク・グループを作成します。一般に、高性能のストレージ・アレイにはハードウェアRAID保護が備わっています。ストレージ・アレイを適切に構成し、真のディスク冗長性が提供されるようにします。
ハードウェアRAIDを使用していない場合や、ホストベースのボリューム管理機能(ストレージ・システムにまたがるミラー化など)が必要な場合は、Oracle ASMのミラー化冗長性を使用してください。地理的に離れているサイト(拡張クラスタ)間でミラー化を行う場合は、Oracle ASMのミラー化を構成で使用できます。
2つのディスク・グループ(1つはデータ用、もう1つは高速リカバリ領域用)を構成します。
次のようなOracle ASMの運用ベスト・プラクティスを使用します。
Oracle ASMインスタンスは、SYSASMと呼ばれる権限ロールで管理され、これによりOracle ASMディスク・グループへの完全なアクセスが付与されます。SYSASMを使用すると、ストレージ管理者とデータベース管理者の認証を分離できます。Oracle ASM認証用の個別のオペレーティング・システム・グループを構成することで、Oracle ASMインスタンスに対するSYSASMアクセス権を保持し、データベース・インスタンスに対するSYSDBAアクセス権を保持しないユーザーを確保できます。
|
関連項目: Oracle ASMインスタンスにアクセスするための認証の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ASMのリバランス能力の限界を上げると、リバランス操作をより高速に実行できますが、同時にアプリケーション・サービス・レベルに影響する可能性があります。能力値を低く抑えると、リバランス操作の時間はかかりますが、データベースなどの他のアプリケーションにより共有される処理リソースとI/Oリソースの消費は少なくて済みます。
計画メンテナンス(たとえばストレージの追加や削除)を実行したら、続いてリバランスを実行し、データをすべてのディスクに再分散する必要があります。リバランスには能力の限界があります。最大能力を設定して、リバランスを実行するプロセス数を指定することができます。アプリケーションがリバランスによる影響を受けないようにするには、最大能力を低く設定します。リバランスを最小限の時間で完了するには、最大能力を高く設定します。リバランスのデフォルトの最大能力を知るには、Oracle ASMインスタンスのASM_POWER_LIMIT初期化パラメータの値をチェックします。
POWER句がALTER DISKGROUP文に指定されていない場合、またはディスクの追加や削除を行うとリバランスが暗黙的に実行される場合、リバランス能力はデフォルトでASM_POWER_LIMIT初期化パラメータの値に設定されます。このパラメータの値は動的に調整できます。
|
関連項目: Oracle ASMディスク・グループのリバランスの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
同じコマンドで複数のディスク・グループをマウントすると、ディスク検出の実行が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管理者ガイド』を参照してください。 |
Oracle ASMでは、データベースの稼働中にディスク・ストレージ・システムを対象にディスクを追加または削除できます。ディスク・グループにディスクを追加すると、Oracle ASMによりデータが自動的に再分散され、ディスク・グループ内で新規ディスクも含むすべてのディスクに均等に分散されます。新たに追加したディスクにもデータが分散されるようにデータの再分散を行うプロセスはリバランスと呼ばれます。同じコマンドでストレージ・メンテナンス・コマンドを実行すると、必要なリバランス操作は1回のみで済むため、データベース・パフォーマンスに与える影響を最小限に抑えることができます。
|
関連項目: ディスク・グループの変更の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
定期的にディスク・グループの不均衡をチェックする必要があります。リバランス操作に失敗するなど、特定の操作に失敗すると、ディスク・グループは不均衡な状態になることがあります。定期的にディスク・グループのバランスをチェックし、必要に応じて手動でリバランス操作を行うことで、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列は、ディスク・グループ内のすべてのディスクで、ほぼ同じである必要があります。
ディスク・エラーに備えてベンダー・ログを予防的にマイニングし、Oracle ASMでデータを不良ディスク・スポットから移動する必要があります。ディスク・ベンダーは、通常、メディア検出エラーなど、ディスクの一部に問題が発生した場合にユーザーに通知するディスク・スクラブ・ユーティリティを提供しています。問題が検出された場合、ASMCMDユーティリティのREMAPコマンドを使用して、Oracle ASMエクステントを不良スポットから正常スポットに移動します。
この処理は、データベース・インスタンスまたはOracle ASMインスタンスにアクセスされないデータにのみ適用されることに注意してください。アクセスされるデータの場合、メディア検出エラーが発生したエクステントは、Oracle ASMによって自動的に同じディスク上の別の場所に移動されるためです。つまり、ASMCMDユーティリティのREMAPコマンドを使用してデータを予防的に不良ディスク・スポットから正常ディスク・スポットに移動する操作は、そのデータがアプリケーションによりアクセスされる前に行います。
|
関連項目: ASMCMDユーティリティの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
ASMCMDユーティリティを使用して、日常のストレージ制御作業の管理性を簡略化します。ASMCMDユーティリティを使用すると、Oracle ASMディスク・グループ内のファイルやディレクトリの表示および操作、ディスク・グループの内容のリスト、検索の実行、ディレクトリやエイリアスの作成と削除、領域使用率の表示などを行うことができます。また、ディスク・グループのメタデータのバックアップおよびリストアにもASMCMDユーティリティを使用できます(md_backupコマンドおよびmd_restoreコマンドをそれぞれ使用します)。
|
注意: Oracle ASMディスク・グループを作成および削除するためのベスト・プラクティスでは、SQL*Plus、ASMCAまたはOracle Enterprise Managerを使用します。 |
|
関連項目: ASMCMDディスク・グループ管理コマンドの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracleストレージ・グリッドは次のいずれかで構成されます。
Oracle ASMと、外部冗長性を使用するサード・パーティのストレージ。
Oracle ASMと、Oracle ASM冗長性を使用するOracle Exadataまたはサード・パーティのストレージ。Exadataを使用するOracleストレージ・グリッドは、MAA関連テクノロジをシームレスにサポートし、パフォーマンスを改善し、無制限のI/Oスケーラビリティを提供し、使用も管理も容易で、ミッション・クリティカルな可用性と信頼性を実現します。
|
関連項目: 『Oracle Automatic Storage Management管理者ガイド』 |
計画外の停止からストレージを保護するには、次のことを行います。
各データベースでDB_BLOCK_CHECKSUM初期化パラメータをTYPICAL (デフォルト)またはFULLに設定します。詳細は、8.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によるストレージの最適化とデータの保護』を参照してください。
|
必要な保護レベルと能力要件に基づいて、Oracle ASM冗長性のタイプを選択します(NORMALまたはHIGH)。
NORMAL設定では2つのOracle ASMエクステントが保存されますが、HIGH設定では3つのOracle ASMエクステントが保存されます。標準冗長性を使用すると使用できる容量が増え、高冗長性にすると保護がより高度になります。
1つ以上のデータベースの実行中にストレージ・コンポーネントをオフラインにする場合、ストレージ・コンポーネントのオフラインによるOracle ASMディスク・グループおよびデータベース可用性への影響がないことを確認してください。障害グループの削除、またはストレージ・コンポーネントのオフライン化を行う前に、適切なチェックを実行します。
停止後にI/Oパフォーマンスが維持されることを確認します。
障害が発生しても、品質保証契約(SLA)を維持できるだけのI/O帯域幅があることを確認します。たとえば、n個のストレージ・コンポーネントを持つストレージ・グリッドの場合に、n-1個のストレージ・コンポーネントでも、(たとえば、ストレージ・コンポーネント障害を処理するために)アプリケーション・サービス・レベルを確実に維持できるようにしておくという手法がよく採用されています。
ExadataまたはSuperClusterでディスク・グループ属性が適切に設定されていることを確認します。
この設定により、単一のディスク・グループに対する2つのディスクの喪失による影響を抑制できます。content.type属性は、データファイルが含まれるディスク・グループの場合、"data"に設定します。高速リカバリ領域が含まれるディスク・グループの場合、"recovery"に設定します。DBFS_DGディスク・グループに対しては、"system"に設定します。
計画メンテナンスのベスト・プラクティスを、次のリストに示します。
I/Oのサイズは、先にパフォーマンスに合せて設定し、その後で容量に合せて設定します。
Oracleストレージ・グリッドを構築する場合、品質保証要件に適合する、1秒当たりのI/OとMB数をサポートできるだけのドライブがあることを確認します。その後で、十分な容量があることを確認します。容量に見合った量のドライブを購入した後で、そのシステムではパフォーマンス要件に適合しないことが判明すると困るので、この順序は重要です。
サイズ指定をする際は、計画メンテナンスのためにストレージのサブセットをオフラインにした場合のパフォーマンスへの影響を考慮する必要があります。たとえば、ストレージ全体のサブセットがオフラインになった場合でも、SLAの準拠にとって重要ならば必要な数のIOPSを得られるようにしておく必要があります。また、ストレージのオフライン化によってシステムへのデータベースの追加ができなくなる場合は、そのことを前もって検討しておく必要があります。
Oracle ASMの最大能力を高速なリバランス用に設定します。 詳細は、3.5.2項「サービス・レベルに影響しない上限値へのリバランスの最大能力の設定」を参照してください。
|
関連項目:
|
