| Oracle Database高可用性ベスト・プラクティス 11gリリース1（11.1） B54839-01 |
|
 戻る |
 次へ |
この項では、管理性とパフォーマンスを維持しながらデータを保護するフォルト・トレラントなストレージ・サブシステムを構成するためのベスト・プラクティスについて説明します。これらのプラクティスは、『Oracle Database高可用性概要』に記載されているOracleデータベースのすべての高可用性アーキテクチャに適用されます。
様々なアプリケーション・ワークロードを使用して、現在のデータベースのパフォーマンス要件を分類します。ターゲット・ワークロードの処理中に統計を抽出するため、開始時と終了時の統計スナップショットを収集します。ターゲット・ワークロードの例は、次のとおりです。
平均負荷
ピーク負荷
バッチ処理
バッチ処理などのアプリケーション・ワークロード、オンライン・トランザクション処理（OLTP）、意思決定支援システム（DSS）およびレポート作成、ETL（Extraction, Transformation and Loading）
データベース・パフォーマンス要件の評価
必要な統計は、自動ワークロード・リポジトリ（AWR）・レポートを使用するか、GV$SYSSTATビューを問い合せることで収集できます。データベースのパフォーマンス要件を理解すると同時に、ストレージ・アレイのパフォーマンス性能を評価する必要があります。DBMS_RESOURCE_MANAGER.CALIBRATE_IO PL/SQLプロシージャを使用すると、ストレージ・アレイの最大容量を確認できます。
ストレージの選択
パフォーマンス要件と容量要件を把握したら、要件に適合するストレージ・プラットフォームを選択します。たとえば、Oracle Exadata Storage Serverは、パフォーマンスおよび可用性に優れた特性を示すソリューションの一例です。各Exadataセルを、I/Oパフォーマンスと容量の1つの単位とみなすことができます。このため、決定する必要があるのは、必要セル数のみです。
Oracleストレージ・グリッドは、Oracle自動ストレージ管理（ASM）とOracle Exadata Storage Serverソフトウェアの組合せか、ASMとサード・パーティのストレージの組合せにより実装されます。Exadataを使用するOracleストレージ・グリッドは、MAA関連テクノロジをシームレスにサポートし、パフォーマンスを改善し、無制限のI/Oスケーラビリティを提供し、使用も管理も容易で、ミッション・クリティカルな可用性と信頼性を実現します。次の各項に、Exadataを使用するOracleストレージ・グリッドの推奨ベスト・プラクティスを示します。
計画外の停止からストレージを保護する方法を、次のリストに示します。
DB_BLOCK_CHECKSUM初期化パラメータを、TYPICAL（デフォルト）またはFULLに設定します。
必ず、チェックサムがデータベース・ブロックに格納されるようにしてください。Exadataセルがチェックサムを受け取ることで、そのブロックに対するHardware Assisted Resilient Data（HARD）のチェックが実行可能になります。
必要な保護レベルと能力要件に基づいて、ASM冗長性のタイプを選択します（NORMALまたはHIGH）。
NORMAL設定では2つのASMエクステントが保存されますが、HIGH設定では3つのASMエクステントが保存されます。標準冗長性を使用すると使用できる容量が増え、高冗長性にすると保護がより高度になります。
ASMのデフォルトのディスク修復タイマーが正しく設定されていることを確認します。
ディスク修復タイマー属性をディスク・グループに対して設定することで、オフライン状態がどれくらい続いた場合にディスクを削除するかを指定することができます。デフォルトのディスク修復時間は3.6時間です。環境に適した設定は、典型的な種類の一時的障害がどれくらいの間、持続すると予想されるかによって異なります。
ASMディスク・グループのバランスを監視して、割当て障害を防止します。
ディスク・グループのバランスを監視して、割当て障害を防止することをお薦めします。ディスク・グループのバランスが崩れると、割当て障害が発生する可能性があります。一般にASMは、確実にディスク・グループのバランスを維持しますが、一部のまれな場合には（リバランス操作の失敗など）、ディスク・グループが不均衡になることがあります。ディスク・グループが不均衡になると、パフォーマンスまたは使用容量の問題を引き起こすことがあるので、定期的にバランスをチェックすることが運用ベスト・プラクティスになります。
停止後にI/Oパフォーマンスが維持されることを確認します。
障害が発生しても、品質保証契約（SLA）のI/O要件を維持できるだけのExadataセルがあることを確認します。たとえば、n個のセルを持つストレージ・グリッドの場合に、n-1個のセルでもアプリケーション・サービス・レベルを確実に維持できるようにしておくという手法がよく採用されています。
計画済のメンテナンスのベスト・プラクティスを、次のリストに示します。
I/Oのサイズは、先にパフォーマンスに合せて設定し、その後で容量に合せて設定します。
Oracleストレージ・グリッドを構築する場合、品質保証要件に適合する、1秒当たりのI/OとMB数をサポートできるだけのExadataセルがあることを確認します。その後で、十分な容量があることを確認します。容量に見合った量のExadataセルを購入した後で、そのシステムではパフォーマンス要件に適合しないことが判明すると困るので、この順序は重要です。
Oracleストレージ・グリッドをスケーリングする場合は、Exadataセルを追加します。
Exadataシステムをスケール・アウトするか、パフォーマンスを向上させる場合は、Exadataセルを追加します。Exadataは、直線的にスケーリングされます。Exadataセルで利用できるI/Oリソース量がわかれば、どれくらいの量のExadataセルが必要かわかります。
Exadata自動構成を使用します。
次のOracle Exadata Storage Serverのツールと機能を活用すると、構成作業を自動化、簡素化することができます。
CELLCLIコマンド
CREATE CELLDISK ALL—このCELLCLIコマンドは、利用できるすべての論理的ユニット番号（LUN）にセル・ディスクを自動作成します。
CREATE GRIDDISK ALL PREFIX=prefix—このCELLCLIコマンドは、使用可能なすべてのExadataセル・ディスクにグリッド・ディスクを自動作成します。
prefixに指定する名前は、ディスク・グループ名と同じである必要があります。たとえば、ASMディスク・グループDATAにグリッドを作成するには、CREATE GRIDDISK ALL PREFIX='DATA'コマンドを使用します。この例ではサイズが指定されていないため、このグリッド・ディスクは全部のセル・ディスクを消費します。
ASM障害グループ自動検出
Oracle Exadata Storage ServerにASM障害グループを作成すると、そのOracle Exadata Storage Serverセル内のグリッド・ディスクがそのASM障害グループに自動配置されます。ディスク・グループ作成時に障害グループを指定する必要がないため、CREATE DISKGROUPの構文が大幅に簡素化されます。
DCLIユーティリティ
Oracle Exadata Storage Serverでは、各セルにDCLIユーティリティが含まれています。DCLIユーティリティを使用すると、定義したセル・セットに、スクリプトやコマンドをパラレルに実行できます。これにより、サブセットやすべてのセルで実行する必要のあるあらゆる操作が大幅に簡素化されます。すべてのセルでSSHユーザー等価関係を構成しておくことが、DCLIコマンドの使用を最適化するために必要な前提条件です。DCLIには、SSHの秘密鍵をAUTHORIZED_KEYSファイルに自動配信する-kオプションがあります。
db.iscsi.shスクリプト
データベース・サーバーで利用できる/opt/oracle.cellos/db.iscsi.shスクリプトを使用すると、iSCSIの構成、iSCSIデバイスの作成およびudevの構成といった、エラーの発生しやすい処理を自動化できます。このスクリプトは、初期構成時にあらゆるOracle Databaseマシン上で実行できます。完了すると、/dev/ocr*ディレクトリでiSCSIデバイスが利用できる状態になります（これらのデバイスがOracle ClusterwareのOCRおよび投票デバイスで使用される点に注意してください）。
Exadataセルの計画済メンテナンスでASMディスクの再同期を使用するには、次の手順を実行します。
Exadataセルに対応する障害グループをオフラインに設定します。
デフォルトのDISK_REPAIR_TIMEが不適切な場合は、ここで、OFFLINE句にオフライン時間を指定します。たとえば、次のようになります。
ALTER DISKGROUP diskgroup_name OFFLINE DISKS IN FAILGROUP failure group name DROP AFTER integer in hours or minutes
プラットフォームの計画済メンテナンスを実行します。
Exadataセルに対応する障害グループをオンラインに設定します。たとえば、次のようになります。
ALTER DISKGROUP diskgroup_name ONLINE DISKS IN FAILGROUP failure group name
ASMは障害グループがオフラインの間に変更されたすべてのエクステントを追跡し、障害グループがオンラインに戻るときに、それらのエクステントを再同期します。計画済メンテナンスの時間がディスク修復時間を超過しないようにしてください。超過すると、ディスクが削除され、再追加されます。
計画済メンテナンス（たとえばストレージの追加や削除）を実行したら、続いてリバランスを実行し、データをすべてのディスクに再分散する必要があります。リバランスには能力の限界があります。最大能力を2〜11の間で設定して、リバランスを実行するプロセス数を指定することができます。アプリケーションがリバランスによる影響を受けないようにするには、最大能力を低く設定します。リバランスを最小限の時間で完了するには、最大能力を高く設定します。リバランスのデフォルトの最大能力を知るには、ASMインスタンスのASM_POWER_LIMIT初期化パラメータの値をチェックします。
I/O Resource Management（IORM）を設定して、品質保証要件を管理し、それに適合させます。IORMのセットアップと構成の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
|
関連項目:
|
ASMは、特にOracleデータベース・ファイル用に構築されたファイル・システムとボリューム・マネージャの両方を垂直統合したものです。ASMにより、パフォーマンスの最適化のためにすべてのディスクをストライプ化してミラー化する（SAME）という概念が拡張される一方で、手動によるI/Oチューニングを行う必要がなくなります（データファイルのレイアウトはホット・スポットを避けるように分散されます）。ASMでは、ストレージ割当てを調整するためにデータベースを停止することなくデータベース・サイズを拡張することで、動的にデータベース環境を管理できます。また、ASMによるミラー化とストライプ化のサポートにより、低コストのモジュール型ストレージで優れたパフォーマンスと高度な可用性を実現できます。
さらに、ASMは、Exadataセル内のストレージを管理します。Exadataセルの場合、ASMはドライブやセルの障害に対処するデータ保護を提供します。パフォーマンスはきわめて優秀で、構成や再構成のオプションは非常に柔軟性に富んでいます。ASMは複数のExadata Storageサーバーにわたってデータを分散し、Exadata Storageサーバーがストレージ・グリッドに追加または削除された場合、透過的かつ動的にデータを再分散します。
ASMを使用してすべてのデータベース・ファイルを管理することをお薦めします。最初はフラッシュ・リカバリ領域のみをサポートして現在の環境にASMを段階的に導入します。
|
関連項目:
|
管理性を向上するため、プラットフォーム上で使用可能な場合にはASMLibを使用してください。ASMLibは、ASMのサポート・ライブラリです。ASMLibはASMの実行に必要ありませんが、ASMLibを使用すると次のメリットがあります。
すべてのOracleプロセスでASMディスクごとにファイル記述子をオープンする必要がなくなるため、システム・リソースの使用率が向上します。
ディスク・デバイス名の管理が容易になり、検出プロセスが簡単になると同時に、あるノードに追加されたディスクがクラスタ内の他のノードに認識されないといった問題を回避できます。
システムの再起動時にディスク・デバイス名のマッピングが変化する場合にその影響を回避できます。
データベース記憶域にASMを使用する場合、2つ以上のディスク・グループ（データベース領域用のディスク・グループとフラッシュ・リカバリ領域用のディスク・グループ）を作成する必要があります。
データベース領域には、データファイル、制御ファイル、オンラインREDOログ・ファイル、スタンバイREDOログ・ファイル、ブローカ・メタデータ・ファイルRMANの増分バックアップに使用される変更トラッキング・ファイルなどのアクティブなデータベース・ファイルが含まれます。たとえば、次のようになります。
CREATE DISKGROUP DATA DISK '/devices/lun01','/devices/lun02','/devices/lun03','/devices/lun04';
フラッシュ・リカバリ領域には、現在の制御ファイルのコピー、各オンラインREDOログ・ファイル・グループのメンバー、アーカイブREDOログ・ファイル、RMANのバックアップ・セット、フラッシュバック・ログ・ファイルなどのリカバリ関連ファイルが含まれます。たとえば、次のようになります。
CREATE DISKGROUP RECO DISK '/devices/lun05','/devices/lun06','/devices/lun07','/devices/lun08', '/devices/lun09','/devices/lun10','/devices/lun11','/devices/lun12';
Linux環境でASMLibを使用する場合、次のようにORACLEASM CREATEDISKコマンドを使用してディスクを作成します。
/etc/init.d/oracleasm createdisk lun1 /devices/lun01
次に、ディスク・グループを作成します。たとえば、次のようになります。
CREATE DISKGROUP DATA DISK 'ORCL:lun01','ORCL:lun02','ORCL:lun03','ORCL:lun04';
ファイル管理を簡略化するには、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
ASMで使用するためにディスクをパーティション化する場合、次の2つのオプションがあります。
複数のディスク全体をデータベース領域のディスク・グループとフラッシュ・リカバリ領域のディスク・グループに割り当てます。
各ディスクを2つのパーティションに分割し、1つをデータベース領域に、もう1つをフラッシュ・リカバリ領域に割り当てます。
図2-1は、ディスク全体を割り当てる方法を示しています。このオプションのメリットは、次のとおりです。
各ディスクを1つの大きなパーティションとして分割しているため、オペレーティング・システム・レベルでディスク・パーティションを管理することが容易です。
ディスク障害後のASMによるリバランス操作が、1つのディスク・グループのみをリバランスすればよいため、迅速に完了します。
このオプションのデメリットは、次のとおりです。
各ディスク・グループが使用可能なディスクのサブセットに単純に分散されるため、I/O帯域幅が小さくなります。
図2-2は、2番目のパーティション化オプションを示しています。この場合、各ディスクを2つのパーティションに分割する必要があります。各ドライブの高速な外側部分にある小さいパーティションをデータベース領域用とし、各ドライブの低速な内側部分にある大きいパーティションをフラッシュ・リカバリ領域用とします。内側のパーティション・サイズと外側のパーティション・サイズの割合は、データベース領域とフラッシュ・リカバリ領域の推定サイズに応じて変化します。
このオプションのメリットは、次のとおりです。
使用可能なすべてのスピンドルに両方のディスク・グループが分散されるため、使用できるI/O帯域幅が大きくなります。このメリットは、I/O集中型のアプリケーションで使用されるデータベース領域用のディスク・グループでは重要です。
I/O容量が十分である場合、オンラインREDOログまたはスタンバイREDOログに、分離された専用のストレージを持つ別個のディスク・グループを作成する必要がありません。
このオプションのデメリットは、次のとおりです。
二重ディスク障害が発生すると、両方のディスク・グループが失われる可能性があります。この場合、リカバリのためにスタンバイ・データベースまたはテープ・バックアップを使用する必要があります。
各ディスクを適切にパーティション化するために、より多くの初期管理作業を必要とします。
|
関連項目:
|
ディスクのマルチパス・ソフトウェアでは、複数の独立したI/Oパスを単一の論理パスに集約します。パスの抽象化により、ホスト・バス・アダプタ（HBA）全体にわたるI/Oのロード・バランシングが実現し、I/Oパスの障害時には無停止のままフェイルオーバーが実行されます。ディスクのマルチパス・ソフトウェアは、ASMとともに使用してください。
ASMでのディスク・グループ作成時にディスク名を指定するときに、単一の論理パスを表す論理デバイスを使用します。たとえば、Linux 2.6でデバイス・マッパーを使用する場合、/dev/dm-0の論理デバイス・パスで物理ディスク/dev/sdcおよび/dev/sdhを集約できます。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';
冗長性を設定してハードウェア障害から保護する場合、検討する必要のあるオプションは次の2つです。
RAIDに基づくストレージ・アレイ
ASMによる冗長性
堅牢な組込みRAIDソリューションを提供するハイエンドなストレージ・アレイを使用する場合、RAID1（ミラー化）やRAID5（ストライプ化とパリティ）などのRAID保護を有効化してストレージ・アレイで冗長性を構成することをお薦めします。たとえば、ストレージ・アレイにより冗長性が提供されるASMディスク・グループを作成するには、まずストレージ・アレイにRAIDで保護された論理ユニット番号（LUN）を作成してから、EXTERNAL REDUNDANCY句を使用して次のようにASMディスク・グループを作成します。
CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK
'/devices/lun1','/devices/lun2','/devices/lun3','/devices/lun4';
ストレージ・アレイで希望するレベルの冗長性を使用できない場合、または複数のストレージ・アレイ全体で冗長性を構成する必要がある場合、ASMによる冗長性を使用します。ASMでは、障害グループを使用した冗長性が提供されます（障害グループはディスク・グループ作成時に定義します）。ASMによる冗長性では、エクステントを二重にミラー化する標準冗長性か、またはエクステントを三重にミラー化する高冗長性を指定できます。ディスク・グループが作成された後で冗長性レベルを変更することはできません。
障害グループの定義は、各ストレージ設定に固有ですが、次のガイドラインに従う必要があります。
ディスクのマルチパス・ソフトウェアを使用している場合のように、すべてのI/Oパスを通じてすべてのディスクを使用できる場合、各ディスクはそれぞれ独自の障害グループに残します。これは、障害グループを明示的に定義せずにディスク・グループを作成する場合の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';
ASMによる冗長性で保護されるディスク・グループの適切なサイズを決定する場合、ディスク・グループには十分な空き領域が存在する必要があります。これは、ディスク障害が発生した場合に、データベースをオンラインに維持したまま、障害ドライブの内容をディスク・グループ内の別のドライブに自動的に再構築できるようにするためです。ディスク障害後にASMで冗長性を回復するのに必要な領域の容量は、V$ASM_DISKGROUPビューのREQUIRED_MIRROR_FREE_MB列で確認できます。ミラー化を考慮しながらディスク・グループで安全に使用できるとともに、ディスク障害後に冗長性を回復できる空き領域の容量は、V$ASM_DISKGROUPビューのUSABLE_FILE_MB列で確認できます。USABLE_FILE_MB列の値は、常に0（ゼロ）を超えている必要があります。USABLE_FILE_MBが0（ゼロ）未満の場合、ディスク・グループに別のディスクを追加します。
クラスタASMは、Oracleの単一インスタンス・データベースとOracle Real Application Clusters（Oracle RAC）の両方で使用できます。Oracle RAC環境では、ノードごとに1つのASMインスタンスが存在し、各ASMインスタンスはpeer-to-peerベースで相互に通信します。ノード上のデータベース・インスタンスの数にかかわらず、ノードごとに必要で、またサポートされているASMインスタンスは、1つのみです。ASMインスタンスをクラスタ化することで、ストレージ・プールにフォルト・トレランス、柔軟性およびスケーラビリティが提供されます。
|
関連項目: クラスタASMの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
独自のホーム・ディレクトリにASMをインストールすると、ASMホームをデータベースのホーム・ディレクトリとは別に管理できます。個別のホーム・ディレクトリを使用することで、ASMとOracleデータベース・ソフトウェアを別々にアップグレードしてパッチを適用でき、ASMインスタンスに影響を与えることなくOracleデータベース・ソフトウェアを削除できるため、可用性が向上します。
|
関連項目: Oracleデータベースに使用されているホーム・ディレクトリとは別のホーム・ディレクトリにASMをインストールする方法の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。 |
ASMインスタンスのMEMORY_TARGET初期化パラメータを使用して、ASMプロセスのメモリー使用量の管理を自動化および簡略化できます。完全なASMメモリー管理のために設定する必要があるのは、このパラメータのみです。ASMには自動メモリー管理を使用することをお薦めします。
自動メモリー管理は、MEMORY_TARGETパラメータが明示的に設定されていない場合でも、ASMインスタンスでデフォルトで有効化されます。MEMORY_TARGETのデフォルト値は、ほとんどの環境で使用できます。
MEMORY_TARGETの値を設定していないが、他のメモリー関連パラメータの値を設定している場合、それらのメモリー・パラメータの値に基づいてOracle内部でMEMORY_TARGETの最適値が計算されます。データベース・インスタンスの場合と同じように、MEMORY_MAX_TARGETパラメータの値までMEMORY_TARGETを動的に増加することも可能です。
|
関連項目: ASMにおけるメモリー関連の初期化パラメータの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
同一ディスク・グループ内のすべてのディスクに同じサイズとパフォーマンス特性を割り当てる必要はありませんが、そうすることで全体的なパフォーマンスおよび領域使用率が予測しやすくなります。可能であれば、ASMに対して、ディスクとASM間に抽象化レイヤーを作成する論理ユニット番号（LUN）ではなく、物理ディスク（スピンドル）を割り当てます。
ディスクが同じサイズであると、ASMはディスク・グループのすべてのディスクに均等にファイルを分散できます。この割当てパターンでは、すべてのディスクが同じ容量レベルに維持されるため、ディスク・グループのすべてのディスクに同じI/O負荷が割り当てられます。ASMは、ディスク・グループのすべてのディスク間でワークロードを負荷分散するため、異なるASMディスクで同じ物理ドライブを共有することはできません。
|
関連項目: ASMディスク・グループの管理方法の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
ASMインスタンスは、ASMディスク・グループに対する完全なアクセス権を付与するSYSASMという権限ロールにより管理されます。SYSASMを使用すると、ストレージ管理者とデータベース管理者の認証を分離できます。ASM認証用の個別のオペレーティング・システム・グループを構成することで、ASMインスタンスに対するSYSASMアクセス権を保持し、データベース・インスタンスに対するSYSDBAアクセス権を保持しないユーザーを確保できます。
|
関連項目: ASMインスタンスにアクセスするための認証の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
同じコマンドで複数のディスク・グループをマウントすると、ディスク検出の実行が1回のみで済むため、パフォーマンスが向上します。ASM_DISKGROUPS初期化パラメータに指定されたディスク・グループは、ASMインスタンスの起動時に自動的にマウントされます。手動でディスク・グループをマウントするには、次のようにALTER DISKGROUP...MOUNT文でALLキーワードを指定します。
ALTER DISKGROUP ALL MOUNT;
|
関連項目: ディスク・グループのマウントおよびディスマウント方法の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
ASMでは、データベースの稼働中にディスク・ストレージ・システムを対象にディスクを追加または削除できます。ディスク・グループにディスクを追加すると、ディスク・グループ内で新しいディスクを含むすべてのディスクに均等にデータが配置されるように、ASMによって自動的にデータが再分散されます。新しく追加されたディスクも含めるようにデータを再分散するプロセスは、リバランスと呼ばれます。同じコマンドでストレージ・メンテナンス・コマンドを実行すると、必要なリバランス操作は1回のみで済むため、データベース・パフォーマンスに与える影響を最小限に抑えることができます。
|
関連項目: 詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
障害グループを使用して共通障害コンポーネントを定義することで、そのコンポーネントに障害が発生してもデータに継続的にアクセスできます。保護を最大化する場合、標準冗長性では最低3つの障害グループを使用し、高冗長性では最低5つの障害グループを使用します。これにより、ASMでは、障害グループの複数の障害に対応でき、完全な冗長性なしでASMが稼働する混乱状態を回避できます。
Oracle Database 10gが稼働する10TBを超える大規模データベースでは、ASM割当て単位を16MBに、ストライプ・サイズを1MBに増やします。これにより、ASMファイルのオープンが高速化し、10TB〜1PBのサイズの大規模データベースを効率的にデプロイできます。この手順の詳細は、サポート・ノート368055.1を参照してください（http://metalink.oracle.com/）。
COMPATIBLE初期化パラメータを「Oracle Database 11g Release 1 (11.1)」に設定している場合、Oracle Database 11gでは可変サイズのエクステントが提供されるため、ASM割当て単位を増やす必要はありません。可変サイズのエクステントを使用することで、より大きなASMデータファイルのサポート、大規模データベースに必要なSGAメモリーの削減、ファイルのCREATEおよびOPEN操作でのパフォーマンスの向上が可能になります。
定期的にディスク・グループの不均衡をチェックする必要があります。リバランス操作に失敗するなど、特定の操作に失敗すると、ディスク・グループは不均衡な状態になることがあります。定期的にディスク・グループのバランスをチェックし、必要に応じて手動でリバランス操作を行うことで、ASMの領域使用率とパフォーマンスを最適化してください。
次の方法で、ディスク・グループの不均衡をチェックします。
マウントされているすべてのディスク・グループの不均衡をチェックするには、サポート・ノート367445.1にあるスクリプトを実行します（http://metalink.oracle.com/）。
I/O面の不均衡をチェックするには、大規模なSQL*Plus文を使用する前に、V$ASM_DISK_IOSTATビューで統計を問い合せます。たとえば、読取りI/Oのみを実行する大規模な問合せを実行する場合は、READS列およびREAD_BYTES列は、ディスク・グループ内のすべてのディスクで、ほぼ同じである必要があります。
ASMのリバランス能力の限界を上げると、リバランス操作をより高速に実行できますが、同時にアプリケーション・サービス・レベルに影響する可能性があります。能力値を低く抑えると、リバランス操作の時間はかかりますが、データベースなどの他のアプリケーションにより共有される処理リソースとI/Oリソースの消費は少なくて済みます。
能力の限界は、アプリケーション・サービス・レベルに影響しない最大限の値に設定してください。POWER句がALTER DISKGROUP文に指定されていない場合、またはディスクの追加や削除を行うとリバランスが暗黙的に実行される場合、リバランス能力はデフォルトでASM_POWER_LIMIT初期化パラメータの値に設定されます。このパラメータの値は動的に調整できます。
|
関連項目: ASMディスク・グループのリバランス方法の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
ASMCMDユーティリティを使用して、日常のストレージ制御作業の管理性を簡略化します。ASMCMDは、ASMディスク・グループ内のファイルやディレクトリの表示および操作に使用できるコマンドライン・ユーティリティです。ASMCMDでは、ディスク・グループの内容のリスト、検索の実行、ディレクトリやエイリアスの作成と削除、領域使用率の表示などを行うことができます。ASMCMDは、ディスク・グループの作成または削除、あるいはディスク・グループ内のディスクの追加または削除には使用できません。これらの操作を実行するには、SQL*Plusコマンドを使用する必要があります。
Oracle Recovery Manager（RMAN）を使用すると、停止時間をほとんど発生させずにASMに移行できます。また、Oracle Data Guardを使用すると、より少ない停止時間（スイッチオーバーの実行に要する時間と同じ程度）でASMに移行できます。
|
関連項目: ASMデータ移行の実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
DISK_REPAIR_TIMEディスク・グループ属性では、ASMでディスクを削除するまでにそのディスクをオフラインのままにしておく期間を指定します。DISK_REPAIR_TIMEパラメータの期限前にディスクを使用可能にする場合、ストレージ管理者は、ONLINE DISKコマンドを発行できます。ASMでは、ミラー側から失効データが再同期されます。Oracle Database 11gでは、ディスクが稼働中のインスタンスに障害が発生しても、オンライン・ディスク操作は再起動されないことに注意してください。ディスクをオンラインにするには、手動でコマンドを再発行する必要があります。
DISK_REPAIR_TIMEディスク・グループ属性には、ディスクが稼働していないと確実にみなせるまでの最大期間を設定してください。
|
関連項目: 一時的なディスク・パス障害後にASMディスク・グループの冗長性をリストアする方法の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
ディスク・エラーに備えてベンダー・ログを予防的にマイニングし、ASMでデータを不良ディスク・スポットから移動する必要があります。ディスク・ベンダーは、通常、メディア検出エラーなど、ディスクの一部に問題が発生した場合にユーザーに通知するディスク・スクラブ・ユーティリティを提供しています。問題が検出された場合、ASMCMD REMAPコマンドを使用して、ASMエクステントを不良スポットから正常スポットに移動します。
この処理は、データベース・インスタンスまたはASMインスタンスにアクセスされないデータにのみ適用されることに注意してください。アクセスされるデータの場合、メディア検出エラーが発生したエクステントは、ASMによって自動的に同じディスク上の別の場所に移動されるためです。つまり、ASMCMD REMAPコマンドを使用してデータを予防的に不良ディスク・スポットから正常ディスク・スポットに移動する操作は、そのデータがアプリケーションによりアクセスされる前に行います。
|
関連項目: ASMCMDコマンドライン・ユーティリティの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
