oracle database 10g automatic storage management の技術的なベスト...

Oracle Database 10g Automatic Storage Managementの技術的なベスト・プラクティス

Nitin Vengurlekar Oracle Corporation 2004年 9月


概要 ...................................................................................................................................................................... 3 ASMインスタンス.............................................................................................................................................. 5 ASM SGAとパラメータのサイズ指定............................................................................................................. 8 ASMLIB ............................................................................................................................................................... 9 ディスク ............................................................................................................................................................ 10 ディスク・グループ ........................................................................................................................................ 13 ASMの冗長性と障害グループ........................................................................................................................ 16 Cluster Synchronization Service（CSS: クラスタ同期サービス）............................................................... 17 データベース・インスタンス ........................................................................................................................ 18 ストレージ管理と割当て ................................................................................................................................ 23 再調整と再配分 ................................................................................................................................................ 24 ファイルとエイリアス .................................................................................................................................... 26 テンプレート .................................................................................................................................................... 29 結論 .................................................................................................................................................................... 30 付録A – パーティション、ビュー、および検索文字列............................................................................. 31 付録B − ASMへの移行 ..................................................................................................................................... 32 付録C − Datapumpファイル・セットとASM ................................................................................................ 36 付録D − ASMでの追加の制御ファイルの作成 ............................................................................................. 37 付録E − ASM SQLスクリプト ......................................................................................................................... 38


2

Oracle Corporation発行「Oracle Database 10g Automatic Storage Management Technical Best Practices」の翻訳版です。

概要

Oracle10gでは、データベースのストレージ管理と準備が Automatic Storage Management（ASM）という新機能によ

って、さらに簡素化されました。ASMは、Oracleデータベース・カーネルに組み込まれたファイル・システムと

ボリューム・マネージャ機能を提供します。この ASMの機能により、データベースの作成や配置、ディスク領域

管理などのストレージ管理作業が簡素化されます。ASMでは使い慣れた SQL文の CREATE、ALTERや DROPを

使用してディスクが管理できるため、DBAは新しいスキルセットの習得、または準備段階における重要な決定が

必要ありません。さらに、10gの Enterprise Managerによって ASMのすべての操作が可能になります。

ASMは、DBAでのジョブの簡素化を目的として作成された管理ツールです。これは、すべてのサーバーおよびス

トレージ・プラットフォーム全体に簡単なストレージ管理インタフェースを提供します。ASMは、さらに効率が

よく動的なデータベース環境を管理できる柔軟性を DBAに提供します。この機能は、グリッド・コンピューティ

ングの鍵となる要素です。

ASMの主要な利点を次に示します。

° I/Oがすべての使用可能なディスク・ドライブに均質に分散されるため、使用が一点に集中せず、パフォ

ーマンスが最大化する。

° 特有な大きいファイルのサポート。

° ストレージ容量を増分追加または削除した後のオンライン再配布の自動実行。

° フォルト・トレランスを提供する冗長コピーの保持、またはベンダー製の信頼できるストレージ・メカニ

ズム上での構築。

° 単一のSMPマシンに対するデータベース・ストレージ管理の提供、またはクラスタの複数ノード全体に対

するOracle Real Application Clusters（RAC）サポートの提供。

° インテリジェントなストレージ・アレイの冗長性の利用が可能。

° サード・パーティのマルチIOパステクノロジの利用が可能。

° ASMへの移行を簡単にする10gでのASMファイルとASM以外のファイルが共存可能。すべてのファイルを

ASMファイルとして新規に作成だけでなく、既存のファイルもASMに移行可能。

° 非ASM管理ファイルをASMディスク・グループに再配置する新しいRMANコマンドが使用可能。

° ASMディスクおよびファイル管理活動を、Enterprise Manager 10gによって管理が可能。


3


このドキュメントでは、ASMの要点、ディスクの追加手順、ディスク・グループの作成、最終的には ASM内で

のデータベースの作成について説明し、同時にベスト・プラクティスについても説明します。また、Veritas Volume

Manager（VxVM）とも比較して理解しやすくします。

次の ASMの基本的なコンポーネントについて説明します。

° インスタンス – ASMインスタンスとデータベース・インスタンス

° ディスク・グループ

° 障害グループ

° ASMディスク

° 再調整機能

° ASMファイル、テンプレートおよびエイリアス

ここでは Cluster Synchronization Services（CSS）を明示的にリストしていませんが、CSSはインスタンス間におけ

る同期化のために必要であり、そのため ASMの実行には必要です。したがって、このドキュメントでは全体の説

明のために取り上げます。


4


ASMインスタンス

10gには、データベース・インスタンスとASMインスタンスの 2種類があります。データベース・インスタンスに

ついては、後の項で説明します。ASMインスタンスは通常+ASMと命名され、INSTANCE_TYPE=ASMというinit.ora

パラメータで開始されます。このパラメータがセットされると、Oracle初期化ルーチンに信号を送り標準のデータ

ベース・インスタンスではなくASMインスタンスを開始します。標準データベース・インスタンスとは異なり、

ASMインスタンスには、ログ・ファイル、制御ファイル、データ・ファイルなど物理的なファイルは含まれず、

startupには、いくつかのinit.oraパラメータのみが必要となります1。

起動時、ASMインスタンスはすべての基本的なバックグラウンド・プロセスの起動だけでなく、ASMの実行に固

有ないくつかのプロセスを新しく起動します。ASMインスタンス用のSTARTUP句は、データベース・インスタン

ス用のSTARTUP句と類似しています。たとえば、RESTRICTは、データベース・インスタンスがこのASMインス

タンスへの接続を防止します。NOMOUNTは、ディスク・グループをマウントせずASMインスタンスを起動しま

す。MOUNTオプションは、すべての定義済みディスク・グループをマウントするだけです2。

図 1に、初期化された ASMインスタンスを示します。データベース・インスタンスのプロセスは oraで始まりま

すが、ASMインスタンスでは、すべてのプロセスが asmで始まっています。

ASMは、Veritasボリューム・マネージャのように、ASMを使用しているすべてのデータベースのファイルおよ

びストレージを所定のノードで管理します。したがって、ノード上のデータベース・インスタンス数には関係な

く、ノードごとに 1つの ASMインスタンスが必要となります。さらに ASMは RACアーキテクチャとシームレス

に連携して、クラスタ化ストレージ環境をサポートします。RAC環境では、クラスタ化されたノードごとに 1つ

の ASMインスタンスが必要で、この ASMインスタンスは peer-to-peerベースで互いに通信します。

1 ASMインスタンスが必要とするメモリ・フットポイントは、約 100Mbです。 2 OPEN起動オプションは、MOUNTオプションと同じ機能です。すなわち、すべてのasm_diskgroupをマウントします。


5


図 1.

インスタンス・タイプ

SQL> select instance_name from v$instance

INSTANCE_NAME

----------------

+ASM

ASM init.oraパラメータ *.background_dump_dest='/u06_10i/app/admin/+ASM/bdump'

*.core_dump_dest='/u06_10i/app/admin/+ASM/cdump'

*.instance_type=asm

*.asm_diskgroups=+DGR14_A

*.large_pool_size=12M

*.asm_diskstring='/dev/rdsk/c3t19d*s4'

*.remote_login_passwordfile='SHARED'

*.user_dump_dest='/u06_10i/app/admin/+ASM/udump'

ASMバックグラウンド・プロセス Oracle 2423 1 0 Apr30 ? 00:00:00 asm_pmon_+ASM1

Oracle 2425 1 0 Apr30 ? 00:00:00 asm_diag_+ASM1

Oracle 2427 1 0 Apr30 ? 00:00:01 asm_lmon_+ASM1

Oracle 2430 1 0 Apr30 ? 00:00:36 asm_lmd0_+ASM1

Oracle 2432 1 0 Apr30 ? 00:00:01 asm_lms0_+ASM1

Oracle 2434 1 0 Apr30 ? 00:00:00 asm_mman_+ASM1

Oracle 2436 1 0 Apr30 ? 00:00:00 asm_dbw0_+ASM1

Oracle 2438 1 0 Apr30 ? 00:00:00 asm_lgwr_+ASM1

Oracle 2440 1 0 Apr30 ? 00:00:00 asm_ckpt_+ASM1

Oracle 2442 1 0 Apr30 ? 00:00:00 asm_smon_+ASM1

Oracle 2444 1 0 Apr30 ? 00:16:03 asm_rbal_+ASM1

Oracle 2447 1 0 Apr30 ? 00:00:17 asm_lck0_+ASM1

Oracle 2457 1 0 Apr30 ? 00:00:00 oracle+ASM1

(DESCRIPTION=(LOCAL=

同様に、Veritas VxVMはディスク構成とメタデータの保持に次のプロセスを必要とします。

oracle@dal-ors4[/dev/rdsk]ps -ec |grep vx

19 TS 59 0:10 vxconfig

860 TS 20 0:00 vxrelocd

894 TS 53 0:00 vxnotify

892 TS 0 0:00 vxrelocd


6


可用性と管理性を高めるため、ASMインスタンスでは、OracleデータベースのORACLE_HOMEとは別の

ORACLE_HOME（ASM_HOME）へのインストールをお薦めします3。単一のASMインスタンスによる、ただ 1つ

のデータベース・インスタンスの管理には、ASMとデータベースの両方にORACLE_HOMEの 1つを維持するだけ

で十分なこともあります。しかし、ASMインスタンスがいくつかのデータベース・インスタンスの記憶域を管理

している場合、それらのデータベースの可用性要件によっては、ASMとORACLE_HOMEデータベースを分離して

おくことをお薦めします。

非RACインストールにおけるASMはデータベースから分離されているため、ASMはORACLE_HOMEをCSSと共有

できます。RAC環境でのASMは、Oracle Clusterware（CRS）およびORACLE_HOMEデータベースとは別の

ORACLE_HOME環境にインストールできます4。このようなORACLE_HOMEの分離により、データベースとASM

との個々のアップグレードが可能になります。さらに、ASMインスタンスに影響なくデータベース・ソフトウェ

アが削除できます。

ASMを専用の ASM_HOMEにインストールする場合、ASM_HOMEは ORACLE_HOMEデータベース以上のバー

ジョンをお薦めします。ASMよりデータベースのバージョンが下位でも、ASMはデータベースと ASMのバージ

ョンの相違に対応できます。つまり、ASMのバージョンがデータベースに伝達されて互換性が確認されます。

ORACLE_HOMEデータベースとは異なるユーザーIDで個々の ASM_HOMEを作成する場合、ASM_HOMEの所

有者は dbaグループのメンバーであることが必要です。ASMディスクに対する読込み/書込み権限が、ASM_HOME

のグループ IDと同じ IDに正しく設定されている必要もあります。

3 10gR1でのインストーラやDBCAなどのツールは、別個にインストールされたASMをサポートしません。ただし、手動での対応は可能です。

4 10gR1では、同一のASMインスタンスによって対応するRACと非RACが混在したインスタンスはサポートされていません。すなわち、非RACデータベース・インスタンスはRAC ASMインスタンスを使用できません。


7


ASM SGAとパラメータのサイズ指定

ASMインスタンスを有効にするには、わずかな init.oraパラメータの構成だけであり簡単です。図 1で指定されて

いる init.oraパラメータは、ASMの起動に不可欠なパラメータです。

° db_cache_size - この値によってキャッシュのサイズが決まります。このバッファ・キャッシュ領域は、

メタデータ・ブロックのキャッシュに使用します。ほぼすべての実装にデフォルト値

が適します。

° shared_pool - インスタンス管理の標準のメモリー使用（制御構造など）に使用します。またエクス

テント・マップの格納にも使用します。ほぼすべての実装にデフォルト値が適します。

° large_pool - 大容量の割当てに使用します。ほぼすべての実装にデフォルト値が適します。

ASM用のプロセス init.oraパラメータは、変更が必要な場合があります。この推奨事項が該当するのは、バージョ

ン 10.1.0.3以上の Oracleソフトウェアです。RACシステム、非 RACシステムの両方が有効です。次の式によりこ

のパラメータの最適の値を決定できます。

25 + 15n − ここで、nは、記憶域に ASMを使用するデータベースの数です。

ASMインスタンスへのアクセスは、SYSDBAやSYSOPERなどの標準インスタンスへのアクセスと同程度です。た

だし、データ・ディクショナリがないため、オペレーティング・システム・レベル、またはOracleパスワード・フ

ァイルによって認証されます。通常、オペレーティング・システム・グループを通じてSYSDBA権限が付与され

ます。Unixでは、これは通常はdbaグループです。デフォルトでのdbaグループのメンバーは、ASMインスタンス

も含めた当該ノード上のすべてのインスタンスにSYSDBA権限を与えられています5。SYSDBA権限でASMインス

タンスに接続するユーザーは、システム内のすべてのディスク・グループに完全な管理アクセスが可能です。ASM

インスタンスではSYSOPER権限がサポートされており、許容SQLコマンドのセットを構成済みのシステムの基本

的な操作に必要となる最小限のセットに制限しています。SYSOPERユーザーは次のコマンドを使用できます。

• STARTUP/SHUTDOWN

• ALTER DISKGROUP MOUNT/DISMOUNT

• ALTER DISKGROUP ONLINE/OFFLINE DISK

• ALTER DISKGROUP REBALANCE

• ALTER DISKGROUP CHECK

• すべてのV$ASM_*ビューへのアクセス

CREATE DISKGROUP、ADD/DROP/RESIZE DISKなど、その他のコマンドの使用には SYSDBA権限が必要です。

それらのコマンドは、SYSOPER権限では使用できません。

5 NTシステムでは、sqlnet.oraにNTSの指定が必要です。


8


ASMLIB

ASMLIBは記憶域管理インタフェースで、ASMの拡張機能として使用できます。ASMはデータベースと同じ記憶

域アクセス方法（与えられたデバイスに対するオープン、読込み、書込み）を使用しますが、ASMLIBは、I/Oを

効率化する特殊なアクセス方法なため、パフォーマンスの最適化を可能にします。ASMLIBは、ストレージ・パ

ートナに対して、記憶域レイヤーとデータベース間でより多くの情報を受け渡せる、という独特な機能を提供し

ます。

このインタフェースは、オペレーティング･システムのデータベース・インタフェースに対する簡素化、およびベ

ンダーのストレージ・アレイの機能と利点の活用を目的としています。オラクル社は、ASMLIB APIという記憶域

管理インタフェースを開発しました。ASMLIBはASMの実行にとって不可欠ではなくASMディスクの管理と検出

を簡素化するアドオン・モジュールに過ぎません。ASMLIBは、ASM対応カーネルにとって、ブロック・デバイ

スを識別してアクセスする代替インタフェースとなります。このAPIは、標準のオペレーティング･システム・イ

ンタフェースに代わる機能をします。ASMLIB APIは、スレージ・ベンダーおよびオペレーティング･システム・

ベンダーに対して、ストレージ関連の拡張機能を提供します。

オラクル社が開発した ASMLIB APIは、標準のインタフェースにはない 2つの重要な拡張機能を提供します。

• ディスクの検出 – データベースおよび DBAに対する記憶域属性についてより多くの情報を提供

• I/O処理 – I/O処理の効率化

オラクル社は Linuxプラットフォーム向けに、Oracle ASMLIB（現行バージョンは 1.0.0）という ASMLIBを提供

しています。ASMLIBのこの実装は、クラスタ化記憶域プールに対する記憶域のプロビジョニングを容易にしま

す。サーバーを再起動すると、ASMLIBによってプロビジョニングされた記憶域のナビゲートできる変更が発生

し、また他のメソッドには恒久的な RAWデバイスと ASMディスクとのバインディングに対する変更が必要な場

合もありますが、ディスクに対するカーネル・レベルのドライバ・アクセスの提供により、権限とデバイスのマ

ッピングが安定化します。

また、管理を簡素化し、あるノードに付加されたディスクを同じクラスタ内の他のノードに認知させる課題を排

除します。この Linux用 ASMLIBは、OTNで利用およびダウンロードできます。


9


ディスク

ASMインフラストラクチャを構築する最初の作業は、ASMの管理下にあるディスクを検出して関連付ける（追加

する）ことです。この手順は、ストレージ管理者とシステム管理者が共同で行うと効果的な結果を得られます。

ストレージ管理者は、ホストに提示されるストレージ・アレイから、ディスクのセットを識別します。ここでは、

ディスクという言葉を広義の意味で使用します。ディスクという用語は、物理的スピンドルのパーティション、

またはスピンドル全体を指すことがあります。これは、ストレージ・アレイが、どのように論理単位番号（LUN）

をオペレーティング･システム（OS）に提示しているかに依存します。このドキュメントでは、LUNまたは OS

に提示されるディスクを総称して、単にディスクと呼びます。

Solarisシステムにおけるディスクでは次の SCSI名形式 CwTxDySzが使用されています。ここで、Cはコントロー

ラ番号、Tはターゲット、Dは LUN/ディスク番号、Sはパーティションです。OS毎の独自なディスク名の表現に

注意してください。

Solarisシステムでは、ベスト・プラクティスとして、ディスクの s4パーティションまたは s6パーティションを選

択するか、またはディスクの最初の 1Mbをスキップするパーティションを選択します。これにより、OSラベル

/VTOCがスキップされます。Sun Solarisのパーティション表の例については、付録 Aを参照してください。オペ

レーティング・システムによって、OSラベルの要件は異なります。たとえば、使用前に OSラベルを必要とする

ものと、しないものがあります。

SAN環境では、ディスクの識別と構成が前提でした。したがってディスクは SAN環境内での適切なゾーン化と

LUNマスキングがされ、OSによる認識が可能になっています。識別されたディスクは、ASMでの検出が必要と

なります。これには、ディスク・デバイス（Unixファイル名）の所有権を rootから oracleへの変更が必要です。

候補となるこれらのディスクには（必要に応じて）有効なラベルが付けられ、現在は、Veritasなど他の論理ボリ

ューム・マネージャ（LVM）によって管理（カプセル化）されていないことが必要です。

このドキュメントの全編を通じ、DG_R14ディスク・グループで構成される実行例により、ディスク・グループお

よびその他の ASMオブジェクトの作成手順を説明します。

この例でのディスク c3t19d5s4、c3t19d16s4、c3t19d17s4および c3t19d18s4は識別されており、所有権が oracleとい

う正しい所有権 IDに変更されています。ここで、これらのディスクを init.oraパラメータの asm_diskstringで定義

できます。この例では、次のワイルドカード設定を使用します。

*.asm_diskstring='/dev/rdsk/c3t19d*s4'.

ディスクのスキャンに、ASMはこの文字列を使用してオープンする権限を持つデバイスを検索します。検出が正

常終了すると、検出されたディスクが V$ASM_DISKに表示されます。その際、名前のフィールドは空で、

group_numberは 0に設定されています。検出されてもディスク・グループに関連付けられていないディスクの名

前の値は NULLで、そのグループ番号は 0です。図 2を参照してください。


10


図 2.

SQL> select name, path, group_number from v$asm_disk

NAME PATH GROUP_NUMBER

------------------------------ --------------- ------------

/dev/rdsk/c3t19d5s4 0




Veritasと同様、ASMは各ディスクの識別として順序番号によるディスク名を生成して割り当てます6。ASMディス

ク名は、SCSIアドレスとは異なります。これにより、RACノードで一貫性のあるネーミングだけでなく、アレイ

の再構成などによるSCSIアドレス名の変更から保護します。ディスク管理活動の実行にはDisk Nameが使用されま

す。Veritasとの比較については次の図 3aおよび 3bを参照してください。

図 3a.

同様に、Veritasの vxdiskコマンドは、ディスクに関する次の情報を提供します。

# vxdisk list | more

DEVICE TYPE DISK GROUP STATUS

c1t4d0s2 sliced disk04 rootdg online

c1t5d0s2 sliced disk03 rootdg online

c3t19d6s2 sliced odm_vg04 odm_vg online

c3t19d7s2 sliced 11i_ora01 11i_oracle_home_vg online

c3t19d8s2 sliced arch_re01 arch_redo online

c3t19d11s2 sliced 11i_ora02 11i_oracle_home_vg online

c3t19d12s2 sliced 11i_db_01 11i_db_vg online

図 3b.

ディスクの構成には、vxdiskaddコマンドライン・ユーティリティ(およびメニュー)を使用します。

vxdiskaddコマンドは、ユーザーにディスクのディスク・グループ名とディスク名の入力を求めます。ディス

ク・グループ名を指定しない場合、そのディスクは未割当の状態です。たとえば、次のグループ名は、指定さ

れた文字列のすべてのディスクを VxVMの制御下に置きます。

vxdiskadd c3t19d*s4

ディスクには、ディスク・グループにメンバーシップ状態を反映する様々なヘッダー・ステータスがあります。

ディスクのヘッダー・ステータスを次に示します。

6 共通のディスク名は、CREATE DISKGROUP文で指定されていない場合にのみ生成されます。


11


° Former（旧メンバー） − この状態は、当該ディスクが以前のディスク・グループの一部であったこと

を示します。

° Candidate（候補） − ディスクがこの状態にある場合、ディスク・グループに付加できることを示

します。

° Member（メンバー） − この状態は、ディスクがすでにディスク・グループの一部であることを示し

ます。

° Provisioned（プロビジョニング済み）− この状態は「候補」と同じく、ディスク・グループが利用でき

ることを示しますが、さらに、ASMLIBを使用して構成または利用可能なデ

ィスクであることも示します。


12


ディスク・グループ

ディスクが検出されて準備が整うと、これらのドライバの 1つ以上をカプセル化するディスク・グループが作成

できます。ASM内で最上位レベルのデータ構造であるディスク・グループは、LVMのボリューム・グループまた

はストレージ・グループと同様です。ただし、一般的な LVMのボリューム・グループと、ASMのディスク・グ

ループには、いくつかの違いがあります。

° ASMのファイル・システム・レイヤーは、ユーザーから参照できません（透過的にディスク・グループ

の最上部に存在します）。ASMの論理ボリューム/ファイル・システムは、ASMおよびインタフェース化

されたデータベース・インスタンスからのみ参照可能なRAWインタフェースです（これについては後述

します）。

° 固有の自動的なファイル・レベルのストライプ化とミラー化機能があります。ASMディスク・グループ

内で作成されたデータベース・ファイルについては、そのファイル・エクステントが均等にディスク・グ

ループ内のすべてのオンライン・ディスクに分散され、均等なIOロードを実現します（データベース・エ

クステントと混同しないでください）。

ディスク・グループの作成時には、追加するディスクが検証されます。他のディスク・グループによって使用さ

れているディスクや、既存のASMヘッダーやOracleファイル・ヘッダーを持つディスクは追加できません。こうし

て、ASMによる既存のデータ・デバイスの破棄が回避されます。候補、旧メンバー、プロビジョニング済みなど

の有効なヘッダー・ステータスを持つディスクのみが、ディスク・グループのメンバーとなることができます7。

このディスク・グループは、SQLコマンドを使用して作成されます。次の図 4a、図 4b、図 5を参照してください。

図 4a.

SQL> create diskgroup DGR14_A external redundancy disk

'/dev/rdsk/c3t19d5s4' , '/dev/rdsk/c3t19d16s4', '/dev/rdsk/c3t19d17s4' , '/dev/rdsk/c3t19d18s4' ;

次はv$asm_diskgroupからの出力ですが、新たに作成されたディスク・グループを示しています8

。

図 4b.

SQL> select name, state, type, total_mb, free_mb from v$asm_diskgroup;

NAME STATE TYPE TOTAL_MB FREE_MB

------------------------------ ----------- ------ ---------- ----------

DGR14_A MOUNTED EXTERN 34512 33479

前述の例では、4つのディスクを使用するディスク・グループとして DGR14_Aが作成されています。これは、ス

トレージ・アレイに常駐し、ミラー化セット経由で外部的に冗長性が処理されます。ディスク・グループが作成

されると、作成日、ディスク・グループ名および冗長性タイプを含むメタデータ情報は、DGR14_Aディスク・グ

ループ内の SGAと各ディスク（ディスク・ヘッダー内）に保存されます。ディスク・グループがマウントされる

と、ASMによってディスク・グループ名、インスタンス名および対応する Oracle Homeのパス名が Cluster

Synchronization Services（CSS）に登録されます。この登録データは、データベース・インスタンスが TNS接続文

7 Member（メンバー）ステータスのディスクをディスク・グループに付加するときは、強制実行オプションが必要です。強制実行オプションは慎重に使用してください。

8 この例で、total_mbとfree_mbの差（使用した領域）が大きいのは、DGR14_Aディスク・グループにシード・データベースが組み込まれているためです。


13


字列の作成に使用されます。この文字列は、これに続いてデータベース・インスタンスが ASMインスタンスに接

続したボリューム管理活動に使用されます。これについては、データベース・インスタンスの項で説明します。

ディスク・グループを正しく作成すると、各ディスクに有効な ASMディスク・ヘッダーが作成され、V$ASM_DISK

ビューによって、オンラインではモード・ステータス、通常のインジケータでは状態が表示されます。これらの

ディスクが ASMの管理下に入ると、そのディスク・グループの後続するマウントについては、すべて ASMによ

って再読込みが行われ、ASMディスク・ヘッダーが検証されます。

図 5.

SQL> select name, path, mode_status, state, disk_number from v$asm_disk;

NAME PATH MODE_ST STATE DISK_NUMBER

------------ ---------------------- ------- -------- -----------

DGR14_A_0000 /dev/rdsk/c3t19d5s4 ONLINE NORMAL 0




ASM起動時または後続するマウントでのディスク・グループのマウントには、すべての必要なディスク・グルー

プを一度にマウントすることをお薦めします。これにより、複数の ASM検出スキャンによるオーバーヘッドが最

小限に抑えられます。

ディスク・グループには、多くの Oracle Database 10gからのファイルを格納できます。またそれらのデータベース

が 1つのサーバーからか、または異なるサーバーでも可能です。だだし、ディスクとデータベースは、単一なデ

ィスク・グループの一部であることが必要です。また、単一な Oracleデータベースは、同一の ASMインスタンス

が管理する複数のディスク・グループにそのファイルを保存できます。複数のデータベースが 1つのディスク・

グループを共有することでディスク使用率が高まり、全体的なスループットが向上します。

管理性のためのベスト・プラクティスとして、ソフトウェア、アクティブなデータベース・ファイル、およびリ

カバリ関連ファイルを、3つの独立したストレージ領域への保存をお薦めします。

° ソフトウェア領域: ソフトウェアがインストールされ、ログとトレース・ファイルの作成場所です。これ

は、ASMディスク・グループの外部に作成されたファイル・システムに入れる必要があります。

° データベース領域: データ・ファイル、制御ファイル、オンラインREDOログ、および増分バックアップ

に使用される変更追跡ファイルなどのアクティブなデータベース・ファイルの保存場所です。

° フラッシュ・リカバリ領域: 現在の制御ファイルとオンラインREDOログの多重化コピー、アーカイブ化

されたREDOログ、バックアップ・セット、およびフラッシュバック・ログ・ファイルなど、リカバリ関

連ファイルの作成場所です。

データベースの高可用性のために、データベース作成時に Flash Recovery Areaが選択された場合、制御ファイル

のアクティブ・コピーと REDOログ・グループの 1メンバーが Flash Recovery Areaに格納されます。制御ファイ

ルの追加のコピーまたは追加のログ・ファイルを作成して任意のディスク・グループに配置できます。

ASMとそのディスク・グループ管理の簡素化に、維持管理するディスク・グループは RACクラスタまたは ASM

インスタンスにつき 2つまでとすることをお薦めします。

Flash Recovery Areaの用途とベスト・プラクティスについての詳細な検討は、次のドキュメントを参照してくださ

い。http://www.oracle.com/technology/deploy/availability/pdf/40104_Bednar_doc.pdf


14


http://www.oracle.com/technology/deploy/availability/pdf/40104_Bednar_doc.pdf

ディスク・グループのメタデータ

ASMはデータベース・データを保持しませんが、ディスク・グループの操作として非常に重要なメタデータは保

持します。このメタデータは、ASMディスクに保管され、ASMインスタンス SGAにキャッシュされます。この

メタデータは、ディスク・グループ自体に保存されるため、ディスク・グループは自己記述的になります。

2つの重要なメタデータ構造は、Continuing Operation Directory（COD）と Active Change Directory（ACD）です。

CODはディスク・グループのアクティブな構造的変更について、ACDはメタデータの更新について、ログのよう

な構造体をそれぞれ格納しています。COD構造体は、ディスクまたはデータ・ファイルのドロップ/追加など、ア

クティブな ASM処理または変更の状態を保持します。たとえば、ディスク・グループに新しいディスクが追加さ

れると、この構成変更を反映する CODレコードが作成されます。CODログ・レコードは、処理の正常終了に基

づいてコミットまたはロールバックされます。処理が正常終了すると、そのディスクはディスク・グループに追

加されます。違反した処理はロールバックし、エラーメッセージが返されて、ディスク対応付けの参照先がなく

なることを防ぎます。

ACDは、メタデータへの変更が記録される点において、REDOログに似ています。ACDログ・レコードは、ASM

処理に障害が発生した場合、またはインスタンスに障害が発生した場合、リカバリのポイントを判別するために

使用されます。たとえば、再調整処理中に障害が ASMに発生した場合、これに続く ASMの再起動時メタデータ

には流入する処理が反映され、次に ACDと CODにより未完了の処理が再開されます。

ASMには物理的ファイルがないため、ASMのバックアップが必要ありません。ASMメタデータは、永続的にデ

ィスク・グループに保持されて 3つにミラー化されるなど、設計段階から高可用性が考慮されています。


15


ASMの冗長性と障害グループ

外部冗長性を使用しないシステムに対して、ASMは障害グループを通じて自身の内部冗長性メカニズムと高可用

性を提供します。障害グループはディスク・グループのサブセットで、コントローラやアレイ全体など、関連付

けられたコンポーネントの 1つに障害が発生すると使用できなくなるディスクの集合と定義されています。した

がって、（与えられたディスク・グループのための）2つの障害グループに含まれるディスクは、共通の障害コン

ポーネントで分離/隔離が必要となります。

ASMは独自のミラー化アルゴリズムを使用します。ASMはディスクのミラー化ではなく、エクステントのミラー

化をします。したがって、ホット・スペア・ディスクのプロビジョニングは必要なく、ディスク・グループの予

備の容量のみが必要となります。ASMがファイルのプライマリ・エクステントをディスク・グループ内の 1つの

ディスクに割り当てると、そのエクステントのミラー・コピーがディスク・グループ内の別のディスクに割り当

てられます。指定ディスクのプライマリ・エクステントは、ディスク・グループ内のいずれかのパートナに対応

するミラー・エクステントを持つことができます。ディスク・グループの各ディスクにおいて、プライマリ・エ

クステントおよびミラー・エクステントの割合は同じです。ASMでは、プライマリ・エクステントおよびそのミ

ラー・コピーは決して同じ障害グループには存在しません。ディスク・グループ内で障害グループを定義すると、

ASMは、1つの障害グループ内で複数ディスク上に同時に発生する障害に耐えられます。

ディスク・グループの冗長性には、ファイルが 2箇所にミラー化される（2つ以上の障害グループが必要）通常冗

長性（デフォルト）と、ファイルが 3箇所にミラー化され（3つ以上の障害グループが必要）、高度な保護が提供

される高冗長性のいずれかを指定できます。

次の図 6に、障害グループによるディスク・グループの作成例を示します。障害グループはディスク・グループ

の作成時に定義します。ディスク・グループ作成後は、その冗長性レベルが変更できません。あるディスク・グ

ループにおけるデータ・ファイルの冗長性の変更には、適切な冗長性が定義された別のディスク・グループを作

成して、そのデータ・ファイルを新しく作成したディスク・グループに移動します（RMANリストアまたは

DBMS_FILE_TRANSFERを使用）。

図 6.

SQL> create diskgroup DBR15_B normal redundancy

Failure group flgrp1 disk ‘/dev/rdsk/c3t19d3s4’, ‘/dev/rdsk/c3t19d4s4’,

‘/dev/rdsk/c3t19d5s4’, ‘/dev/rdsk/c3t19ds4’

Failure group flgrp2 disk ‘/dev/rdsk/c4t19d3s4’, ‘/dev/rdsk/c4t19d4s4’,

‘/dev/rdsk/c4t19d5s4’, ‘/dev/rdsk/c4t19ds4’ ;

障害グループ flgrp1で再調整をもたらすディスク障害が発生すると、図 6の例の場合、障害が発生したディスク

の内容（データ・エクステント）は、障害グループ flgrp2に常駐するパートナ・ディスクのエクステントの冗長

コピーを使用して再構築されます。再調整処理中に、データベース・インスタンスが障害発生ディスク上にプラ

イマリ・エクステントを持つエクステントにアクセスが必要な場合、データベースは適切なディスクからミラー・

コピーを読み込みます。再調整が完了して、ディスクの内容が完全に再構築されると、データベース・インスタ

ンスはプライマリ・コピーのみの読込みに復帰します。


16


ディスク・ドライブは機械的なデバイスであるため、障害が発生することがあります。ドライブに障害が発生し

始めるか、または散発的なI/Oエラーによってデータベースの障害が発生する可能性も高くなります。ASMは、I/O

エラーの予防対策をします。この処置は、障害グループの使用にも実行されます。デバイス・ドライバで数回の

リトライ後でのみ、永続的I/Oエラーのシグナルがコール元（Oracle IOプロセス）に発信されます。Oracleの書込

み処理中に永続的I/Oエラーが発生すると、影響を受けたディスクはASMによってディスク・グループから削除さ

れるため、それ以上のアプリケーション障害は防止されます9。ディスクの損害によってデータ損害が発生すると、

ASMは自動的にディスク・グループをディスマウントし、ディスク・グループ・データの整合性を保護します。

Cluster Synchronization Service（CSS: クラスタ同期サービス）

ASMは、単一インスタンスでも RACクラスタでも動作する設計がされています。単一インスタンスの場合も、

Cluster Synchronization Services（CSS）がインストールされ使用可能であることが ASMでは必要です。CSSは、単

一インスタンス内で ASMとデータベース・インスタンス間の同期を維持します。Oracleの Cluster Ready Services

（CRS）のコンポーネントである CSSは、Oracle Database 10gが実行されているすべてのノードに自動的にインス

トールされます。ただし、RAC環境では、各 RACノードに完全な Oracleクラスタウェア（CRS）がインストー

ルされます。

CSSはクラスタ管理とノード監視管理を提供するため、本質的に ASMとこの共有ストレージ・コンポーネント（デ

ィスクとディスク・グループ）を監視します。ASMの起動時に、ASMとマウントされているすべてのディスク・

グループが CSSに登録されます。これにより、CSSがすべての RACノードで稼働し、ディスク・グループのメタ

データの同期を保持できます。新しく作成されたディスク・グループも動的に登録され、クラスタ内の他のノー

ドにブロードキャストされます。

ASMインスタンスのアクティビティは、データベースの場合と同様にノード間通信で同期化されます。CSSは、

ASMインスタンスのハートビート監視による健全性チェックに使用されます。ASMのノード間メッセージは、デ

ィスクの追加など、同期化が必要な構造的変化によって開始されます。したがって、ASMは、データベースが効

率の良い同期化に使用する、統合されたロック管理インフラストラクチャを使用します。

データベース・インスタンスは、CSSと接続し、TNS接続文字列をルックアップします（ディスク・グループ名

を索引として使用）。この接続文字列は、次に ASMインスタンス内における永続的な接続の作成に使用されます。

9 ディスクがディスク・グループから削除されるのは、書込み処理のI/Oエラーのみの場合で、読込み処理には削除されません。読込みエラーの場合、そのブロックはセカンダリ・エクステントから（冗長性が通常、または高度のみの場合）、または外

部冗長性から読み込まれます。


17


データベース・インスタンス

データベース・インスタンスは、標準の Oracleインスタンスで、ASMのクライアントになります。データベース

から ASMへの通信は常にコード内通信です。データベースがリモート（RACの場合）ASMインスタンスに接触

してデータベース要求に応えることはありません。

ASMディスク・グループが作成されると、データベースの作成にDBCAを使用できます10。DBCAは、データベー

ス・ファイル構造に関する 3つのオプションとして、ファイル・システム、RAW、またはASMが使用可能になり

ました。ASMを選択すると、そのASMインスタンスのすべての使用可能なディスク・グループがリストされます。

ASMとディスク・グループを選択すると、DBCAによってASM内にデータベースが作成されます。ディスク・グ

ループが存在しない場合、DBCAは新しいディスク・グループの作成を提供します。ASMディスク・グループに

は、制御ファイル、データ・ファイル、spfileファイル、RMANバックアップ・ファイルなど、すべてのOracle物理

ファイルを格納できます。ただし、Oracle実行可能ファイル、CRSファイル（OCRと投票ディスク）および非デー

タベース・ファイルは、ASMディスク・グループへ格納できません。このドキュメントでは、Oracleのすべての物

理ファイルをデータベース・ファイルと呼んでいます。

ASMストレージを使用するアクティブなデータベース・インスタンスは、一般のデータベース・インスタンスと

同様に操作できます。つまり、すべてのファイル・アクセスは大規模な ASMの介入なく直接実行されます。ファ

イルが作成またはオープンされると、データベース・インスタンスは ASMインスタンスと相互対話します。この

間、ASMインスタンスおよび後続するすべての I/Oからのファイル・レイアウトの読込みは、データベース・イ

ンスタンスに保存されているレイアウトで実行されます。ASMおよび DBのインスタンスはストレージ構成の変

更時、つまり、ディスクまたはデータベース・ファイルの追加、削除、またはディスク障害の発生時などに相互

対話します。

ASMレイヤーは、データベース・クライアントおよびサーバー上のユーザーに対して透過的です。したがって、

データ・ファイルへのアクセスは、データベース・インスタンスとそのユーティリティ経由に限られます。たと

えば、ASMベースのファイルのデータベース・バックアップは、RMANまたは RMANを利用するバックアップ・

ソリューションでのみ実行されます。Unixの ddコマンドのようなユーティリティは、ASMディスク・グループ

のバックアップやリストアにはお薦めできませんので注意してください。

ASMファイルのデータベース・ファイル・レベルのアクセス（読込み/書込み）は、10gより前と同様ですが、「+」

で始まるデータベース・ファイル名は、自動的に ASMコード・パス内で処理および管理されます。ただし、ASM

ファイルに関しては、データベース・ファイル・アクセスに RAWデバイスの特性が付与されます。つまり、カー

ネル化された非同期 IO（KAIO; kernelized asynchronous IO）によるバッファされていない IO（ダイレクト IO）で

す。

10 ASMインスタンスおよびディスク・グループの作成にもDBCAを使用できます。


18


データベース・インスタンスが作成され、インスタンスがアクティブとなったら、データベース・インスタンス

はASMのクライアントになります。このことは、V$ASM_CLIENTビューに反映されます11。V$ASM_CLIENTは、

ASMディスク・グループを使用するインスタンスごとに1つの行を含んでいます。次の図7では、GV$ASM_CLIENT

が、クラスタ化されたASMインスタンスを使用して 2つのRACインスタンスを表示しています。

図 7.

SQL> select * from gv$asm_client;

INST_ID GROUP_NUMBER INSTANCE DB_NAME STATUS

---------- ------------ -------- -------- ------------

2 1 +ASM2 soxs CONNECTED

1 1 +ASM1 soxs CONNECTED

新規データベース・プロセスによる ASMのサポート

データベース・インスタンスには、ASMディスク・グループとインフラストラクチャをサポートする新しい 3つ

のプロセス・セットが追加されました。

° RBAL – このプロセスは、ディスク・グループ内のすべてのディスクをグローバルにオープンします。

° ASMB – このプロセスは、ディスク・グループ名を使用してCSSに接続し、関連付けられているASM接続

文字列を取得します。この接続文字列は、この後ASMインスタンスとの接続に使用されます12。この永続

的な接続を使用して、統計を更新し、ハートビート・メカニズムを提供する定期的なメッセージが交換さ

れます。たとえば、データベース・フォアグラウンドによるファイル作成など、ASMの介入が必要な間、

データベース・フォアグラウンドは直接ASMインスタンスと接続して処理します。ファイルの作成が正

常に完了すると、ASMによってデータベース・ファイルのエクステント・マップがASMBに送信されます。

さらに、ASMBはデータベースのIO統計をASMインスタンスに送信します。

° A00x − スレーブ・プロセスのグループが、ASMインスタンスへの接続を確立します。ここで「x」は、1

から10までの数字です。この接続プールを通じてデータベース・プロセスはASMにメッセージの送信が

できます。たとえば、ファイルのオープン時には、スレーブ経由でオープン要求がASMインスタンスに

送信されます。ただしファイルの作成など、長時間の処理では、スレーブが使用されません。スレーブ（プ

ール）接続では、ASMインスタンスの短い要求でのログインによるオーバーヘッドを回避できます。こ

れらのスレーブは使用中以外シャットダウンされます。

11 このビューは、+ASMインスタンスの行のみを含んでいます。データベース・インスタンスについては、V$ASM_CLIENTにエントリはありません。さらに、RAC環境では、各RACインスタンスに対してエントリが 1つあります。

12 この接続は、常にASMインスタンスへのBEQ接続です。


19


データベースの Init.oraパラメータによる ASMのサポート

データベース・インスタンスの SGAパラメータでは、ASMエクステント・マップおよび他の ASM情報をサポー

トする修正が少々必要です。10g Automatic Memory Management機能がデータベース・インスタンスで使用されて

いる場合、このサイズ指定データは、SGAの最適値を割り出す参考情報のみ、または補完データのみに扱われる

ことに注意してください。オラクルは、Automatic Memory Management機能の使用を強くお薦めします。

次にデータベース・インスタンスにおける SGAのサイズ指定のガイドラインを示します。

Large_pool = 600k追加します。

Shared_pool = エクステント・マップの格納にメモリー追加が必要です。次のクエリーの値を集計して、ASMに既

存するか、または今後 ASMに格納されるカレントのデータベース・ストレージのサイズを求めてください。次に、

使用されている（または今後使用する）冗長性タイプを決定した集計値を入力として shared_poolを計算します。

select sum(bytes)/(1024*1024*1024) from v$datafile; select sum(bytes)/(1024*1024*1024) from v$logfile a, v$log b where a.group#=b.group#; select sum(bytes)/(1024*1024*1024) from v$tempfile where status='ONLINE'; 外部冗長性を使用したディスク・グループ: (100Gb毎に 1Mbの追加 shared pool) + 2M 通常冗長性を使用したディスク・グループ: (50Gb毎に 1Mbの追加 shared pool) + 4M. 高冗長性を使用したディスク・グループ: (33Gb毎に 1Mbの追加 shared pool) + 6M.

Processes = 16を追加します。


20


ASMとデータベースのシャットダウン依存性

ASMは、データベース・ファイルとそのメタデータを含むディスク・グループの管理に、ASMインスタンスがシ

ャットダウンされると、すべてのクライアント・データベース・インスタンスもシャットダウンされます13。通常

のシャットダウンでは、一般的なデータベース・インスタンスと同様に、ASMインスタンスがシャットダウンを

開始し、すべてのセッションの切断を待ちます。ただし、ASMは永続的なデータベース・インスタンス接続を保

持しており、ASMがシャットダウンを完了するため、最初にデータベース・インスタンスのシャットダウンが必

要なことに注意してください。

ASMの SHUTDOWN IMMEDIATEまたは ABORTの場合、ASMは即座に開いているすべての接続を終了させ（デー

タベース・インスタンス接続も含む）、依存しているすべてのデータベースを直ちに強制終了します。正常終了

にはなりません。

単一 ASMインスタンス構成では、更新にディスク・グループが開いているときの ASMインスタンスの障害発生

時、ASMの再起動にディスク・グループのログを読み込んで ASMインスタンスをリカバリします。RAC環境で

は、複数の ASMインスタンスがディスク・グループを共有しており、1つの ASMインスタンスに障害が発生す

ると、別のノードの ASMインスタンスは、障害が発生したインスタンスによる一時的な ASMメタデータの変更

を自動的にリカバリします。つまり、インスタンス・リカバリが実行されます。

13 ASMインスタンスに障害が発生すると、そのASMインスタンスに依存するすべてのOracleインスタンスにも障害が発生します。これは、OSでのボリューム・マネージャの障害と同じです。


21


ASMとデータベースの配置にかかわるベスト・プラクティス

ASMは、冗長性と最適なパフォーマンスを即座に実現します。しかしながら、パフォーマンスと可用性をさらに

高めるには、次の事項の考慮が必要です。

1. 複数の HBA（訳注: Host Bus Adapter）またイニシエータによるストレージ・アレイへの複数のアクセス・

パスの実装

2. 上記の複数の HBAでのマルチパス・ソフトウェアの配置による、IOロード・バランシングとフェイルオ

ーバー機能の提供。ASMに対するディスクストリングとして擬似デバイスをできるかぎり使用してくだ

さい。

3. 同様なサイズのディスクを数多く含むディスク・グループの使用およびこれらのディスクがいくつかのバ

ックエンド・ディスク・アダプタにまたがることの保証。数多くのディスクを含むディスク・グループは、

データ・エクステントを広範囲に配布することで、I/Oの並行性を高め、ホット・スポットの発生を抑え

ます。大きなディスク・グループは、様々な I/O特性とワークロードを容易にサポートできるため、単一

（データベース領域）なディスク・グループによるデータベース・ファイル、ログ・ファイルおよび制御

ファイルが格納できます。

4. 前述のとおり、2つ以下とするディスク・グループをお薦めします。たとえば、一般的な配置では、デー

タベースのディスク・グループ 1つにすべてのバックエンド・アダプタまたはディレクトリにまたがるデ

ィスクを 8つ、Flash Recovery Areaのディスク・グループに対しては 8~10ディスクとします。Flash領域

のサイズは、データベースのフル・バックアップ、増分バックアップ、フラッシュバック・データベース

のログおよびアーカイブ・ログなど、格納される内容によって変わります。

（注）制御ファイルのアクティブなコピーおよび各 REDOログ・グループのメンバー1つが Flash Recovery

Areaに格納されます。

5. データベース領域とフラッシュバック領域の物理的隔離によって、2つの領域が同じ物理スピンドルを共

有しないことの保証。

以上のトピックの詳細は、マニュアル『Oracle 高可用性アーキテクチャおよびベスト・プラクティス』を参照し

てください。


22


ストレージ管理と割当て

ASM構成下に作成されたデータベースは、SAME方法論で指定されるように、ストライプ化され、ミラー化され

ます。つまり、I/Oロードは、ディスク・グループ内のディスク間で均一に分散および調整されます。この例では、

データベースは 4つのディスク間でストライプ化され、EMCストレージ・アレイによって冗長性が処理されます。

ここでは、1MBのストライプ・サイズを使用して、1ファイル順にストライプ化されます。これは他のLVMとは

逆で、こちらはディスク・ボリューム・レベルでストライプ化やミラー化を実行します。ASMは 1MBのストライ

プの深さで割当てますが、この深さは割当て単位（AU; allocation unit）とも呼ばれ、ASMが割り当てる最小な連

続するディスク領域です14。

ファイル・エクステント分散には、coarseと fineという 2つのタイプがあります。ASMはディスク・グループ内

のすべてのディスクに、1つのファイル割当単位のチャンク（ファイル・エクステントを 1つ格納）にファイルを

常に分散します。fine分散では、8AUのグループに 128Kを挿入します。これらの AUはすべてのディスクに分散

されます。fine分散では、大きなサイズの I/O処理を、並列して実行可能な 128Kの I/O処理に分割します。

ディスク・グループ内の各ディスクは、ディスク・ヘッダー内に割当て表構造が作成されます。この表構造には、

ディスク AUの 1エントリごとに、AU記述子が含まれます。この AU記述子には、ファイル番号とファイル・エ

クステント番号が含まれます。データベース・ファイルは、ファイル・エクステントに分割されます。各ファイ

ル・エクステントは、単一の割当て単位です。各データベース・ファイルには、ファイル・エクステント・マッ

プが割り当てられており、各マップ・エントリは、ディスク上のファイル・エクステントの場所を一意に示す、

ディスク番号と AU番号を参照します。

14 現在、ユーザーはAUサイズの設定ができません。


23


再調整と再配分

従来のボリューム・マネージャでは、一般にストライプ化されたファイル・システムの拡張/増加、または縮小は

困難でした。ASMを使用すると、これらのディスク/ボリュームの変更は、ストライプ化されたデータのシームレ

スな再配分（再調整）となり、オンラインで実行できます。

ストレージの構成が変更されると、再調整がトリガーされます。再調整処理の主な目的は、ファイル・エクステ

ントと、ディスク・グループ内のすべてのディスクのスペース使用率を常に均一に分散することです。再調整は、

すべてのデータベース・ファイルに対するファイルごとに実行されます15。このリバランスは、ASMインスタン

スからOracleの新しいバックグラウンド・プロセスであるRBALによって実行されます。

再調整プロセスでは、各ファイル・エクステントのマップを調査し、新しい記憶域構成には新しいエクステント

が再プロットされます。たとえば、40エクステントのデータ・ファイルを持つ、8つのディスクによるディスク・

グループがあるとします（各ディスクが 5つのエクステントを格納）。2つの新しい同サイズのドライブが追加さ

れると、このデータ・ファイルは 10のドライブ間で再調整され、各ドライブには 4つのエクステントが格納され

ます。8エクステントのみの移動でリバランスを完了でき、エクステントの完全な再配分が必要ありません。最小

限な数のエクステントのみの移動により、均等な配分が達成されます。

ASM再調整の一般的なプロセスを次に示します。

1. ASMインスタンス上で、DBAによってディスクがディスク・グループに追加（削除）されます。

2. これにより RBALプロセスが呼び出され、再調整プランが作成されて、再配分を調整します。

3. RBALは、必要な時間と作業を推測し、実際に要求を処理する ARB0や ARB1などにメッセージを送信し

ます。呼び出された ARBxプロセスの数は、asm_power_limitによって直接決定されます。

4. 連続作業ディレクトリ（Continuing Operations Directory; メタデータ）は、再調整活動を反映して更新され

ます。

5. 再配置される各エクステントが、ARBxプロセスに割り当てられます。

6. ARBxは、これらのエクステントを再調整します。各エクステントは、ロック、再配置およびロック解除

されます。これは、オペレーション REBALとして表示されます。

再調整では、ファイル・エクステントが物理的に移動されます。一度に「1エクステント/AU」で再調整されるた

め、任意の時間に実行中の I/Oは 1つのみとなり、通常これによる影響はほとんどありません。これはオンライン・

データベース活動に否定的な影響を与えません。ただし、再調整処理は、ピーク以外の時間での予定をお薦めし

ます。

再調整処理のスループットと速度の変更に、新しいinit.oraパラメータのasm_power_limitが導入されました16。

asm_power_limitの値の範囲は 1～11です。値 11が最高速で、値 1は低速です。ただし、この能力値は、alter diskgroup

コマンドにより、特定な再調整活動にも設定できます。この値は、特定の再調整作業にのみ有効です。

asm_power_limit設定と、alter diskgroupコマンドによる能力値の変更との主な違いは、能力値では値 0を指定でき

ますが、asm_power_limitでは指定できないことです。図 8を参照してください。能力値 0とは、この再調整処理

では再調整されないことです。この設定は、ストレージ（冗長性を持つ）を追加または削除した際に、再調整を

後（スケジュールした時間）に遅延させる場合に特に重要です。

15 ディスク・サイズによって影響され、再調整に影響を与える重み付け要素です。ドライブが大きくなるほど、多くのエクステントを消費します。これは、全体的なサイズに基づく配分でも実行されます。

16 asm_power_limitは、各ASMインスタンスに固有です。


24


図 8.

“Session1 SQL”> alter diskgroup DGR14_A add disk '/dev/rdsk/c3t19d39s4'

rebalance power 11

別のセッションから

“Session2 SQL”> select * from v$asm_operation;

OPERA STAT POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES

----- ---- ---------- ---------- ---------- ---------- ---------- -----------

1 REBAL WAIT 11 0 0 0 0 0

1 DSCV WAIT 11 0 0 0 0 0

(しばらくして)

OPERA STAT POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES

------------ ----- ---- ---------- ---------- ---------- ---------- ----------

1 REBAL REAP 11 2 25 219 485 0

複数のディスクを削除または追加する場合、ベスト・プラクティスとして、ドライブを一度に追加または削除し

て、ストレージ変更に必要な再調整処理を減らすことが有効です。さらに、asm_power_limitまたは power valueの

セットによるドライブ数の 2倍の再調整を（上限は 11）お薦めします。

外部冗長性の場合、ディスク・グループ内のディスクの削除および追加が非常にシームレスなため、再調整のス

ケジューリングは、より役立ちます。ただし、障害グループの場合、ディスクの削除および追加方法のプランを

立てるなど事前の考慮が必要となります。この操作のベスト・プラクティスについては、フォローアップ記事で

説明します。


25


ファイルとエイリアス

ファイルとは、データベース・インスタンスがアクセスするオブジェクトです。ファイルには、データ・ファイ

ル、制御ファイル、spfileおよびREDOログ・ファイルなどの形式があります17。付録Cでは、ASMのディスク・グ

ループ内へのDataPumpダンプセット・ファイルの作成方法を説明しています。

操作上、ASMに格納されているデータベース・ファイルは非ASMファイルと異なりません。ただし、ASMファイ

ルはdf、ls、dd、mvなどの通常のコマンドによるOSからの参照はできません。ファイル・システムのデータベース・

ファイルをASMのディスク・グループ間で移動する、またはデータベース・ファイルをASMのディスク・グルー

プ間で移動するファイル管理活動には、RMANパッケージまたはDBMS_FILE_TRANSFERパッケージの使用が必

要となります18。たとえば、誤って配置されたデータ・ファイルをあるディスク・グループから別のディスク・グ

ループに移動する場合、RMANを使用できます。そのプロシージャは付録Bを参照してください。

データベース・ファイルの追加または削除など、その他のファイル操作では、Enterprise Manager（Database Control

または Grid Control）、SQLPLUSコマンドラインまたはRMANが必要となります。前述したとおり、データベー

ス・バックアップはRMANによる管理を推奨します。

ASMファイルとしては、bigfileまたは通常のファイルを使用できます。いずれのファイル・タイプの場合も、フ

ァイル・サイズの制限は、ディスク・グループの冗長性モードおよび Oracleソフトウェアのブロック・サイズに

よって決まります。bigfile表領域またはファイル・サイズの制限の詳細については Oracleマニュアルを参照して

ください。

ASMファイル名の構文は、通常の命名の標準とは異なりますが、9iの OMF（Oracle Managed File）機能のファイ

ルシステム・アプローチに似ています。ASMファイル名は、正しく作成したデータ・ファイルから取得して生成

されます。ASMファイル名の形式は、「+ディスク・グループ名/データベース名/データベース・ファイル・タイ

プ/タグ名.ファイル番号.インカネーション」です。

たとえば、サンプルの SYSTEM表領域名は、「+DGR14_A/b2r6/datafile/system.258.3」です。

データ・ファイル名のタグ名が、表領域名に対応していることに注意してください。REDOログ・ファイルにつ

いては、タグ名は「+DGR14_A/b2r6/onlinelog/group_3.264.3」のようなグループ番号です。

ASMインスタンスのファイル番号により、データベース・インスタンスのファイル名の対応の特定および名前の

判別ができます。

次の図は、データベース・インスタンスのファイル識別と、ASMのファイル識別間の関係を示しています。ファ

イル名には、V$ASM_FILEのファイル番号が埋め込まれていることに注意してください。

17 合計で 12のファイル・タイプがあります。 18 現在、10gR1におけるDBMS_FILE_TRANSFERは、ファイル・システム間またはASMディスク・グループ間でのデータ・ファイルの転送にのみ使用できます。ASMの外部への（または外部からの）ファイル転送は現在サポートされていません。


26


図 9.

+ASM (ASMインスタンス)

SQL> select file_number , sum(bytes)/(1024*1024) from v$asm_file

2* group by file_number

FILE_NUMBER SUM(BYTES)/(1024*1024)

----------- ----------------------

256 360.007813

257 35.0078125

258 450.007813

261 .002441406

262 150.007813

263 23.0078125

264 10.0004883

265 5.0078125

266 10.0004883

267 10.0004883

268 2.2109375

B2R14 (データベース・インスタンス)

SQL> select name from v$datafile

NAME

----------------------------------------

+DGR14_A/b2r6/datafile/sysaux.256.3

+DGR14_A/b2r6/datafile/system.258.3

+DGR14_A/b2r6/datafile/undotbs1.257.3

+DGR14_A/b2r6/datafile/users.265.3

/u01/oradata/b2r6/ishan01.dbf

SQL> select member from v$logfile;

MEMBER

-------------------------------------------------------------------------------

+DGR14_A/b2r6/onlinelog/group_3.264.3



このデータベースには、ASMファイルと、ASM以外のファイルの ishan01.dbfが含まれています。

図 9の ASMリストには、ASM管理下にないため、ishanデータ・ファイルのエントリはありません。重要な注意

点ですが、10gデータベースは、ファイル・システムに常駐するファイル、RAWファイルおよび ASMファイル

を同時に保持できます。

ここで説明しているファイル名の表記規則のことを、完全修飾（FQFN; Fully Qualified FileName）表記規則と呼び

ます。FQFNは、一般に長くて使いづらく、ファイルのネーミング規則を簡単に覚えるために、ASMのエイリア

ス名形式が導入されました。ASMエイリアスは、ファイル・システム階層と同様に、基本的には次のような階層

型ディレクトリ形式になっています。 /u01/oradata/dbname/datafile_name


27


エイリアス名はディスク・グループ名を指定しますが、ファイルとインカネーション番号の変わりに、親しみや

すい文字列の名前が使用されます。エイリアスの ASMファイル名は、ドットつきの数値のペアでは終らないため、

完全修飾された名前や数値による名前の区別が必要です。

次にASMエイリアスの例を示します19。

図 10.

SQL> alter diskgroup DGR14_A add directory '+DGR14_A/oradata/B2R6';

SQL> alter diskgroup DGR14_A add alias '+DGR14_A/oradata/B2R6/ishan01.dbf'

for'+DGR14_A/b2r6/datafile/ishan.314.1'

ベスト・プラクティスとして、各データベースにOracle Managed File（OMF）機能を実装してください。OMFを使

用すると、ファイルの命名が簡素化され、ファイル操作も容易になります。たとえば、表領域が削除された場合、

ASMは、OMFデータ・ファイルに限り自動的に削除します。OMFが使用されていない場合、DBAがASMに接続し

て手動でそのファイルの削除が必要となります。OMFファイルは、DB_CREATE_FILE_DESTディレクトリに置か

れています20。使用方法と実装については、OMFのドキュメントを参照してください。

create/alter tablespaceコマンドまたはadd datafileコマンドでファイル名が指定されている場合、OMFは使用されませ

ん。

次の図 11では、DBCAによって作成された、デフォルト・データベースの OMF関連の init.oraパラメータである

B2R6を示しています。

図 11.

spfile = +DGR14_A/b2r6/spfileb2r6.ora

control_files = +DGR14_A/b2r6/controlfile/current.268.3

db_create_file_dest = +DGR14_A

db_recovery_file_dest = +FLASH

エイリアスは、制御ファイルおよび spfileを扱うときに特に有効です。たとえば、エイリアスの ASMファイル名

は、通常 CONTROL_FILES初期化パラメータで使用されます。前述の例では、SPFILEは OMFファイルを使用し

ています。

ディスク・グループに保存されているファイル階層の表示には、接続後に次の SQL文でフル・パスを生成します。

この問合せの実行には、ASMインスタンス内に十分な大きさの shared_pool_sizeが必要なことに注意してください。

より効率的な階層の参照には EMを使用します。

SELECT concat('+'||gname, sys_connect_by_path(aname, '/')) full_alias_path FROM (SELECT g.name gname, a.parent_index pindex, a.name aname, a.reference_index rindex FROM v$asm_alias a, v$asm_diskgroup g WHERE a.group_number = g.group_number) START WITH (mod(pindex, power(2, 24))) = 0 CONNECT BY PRIOR rindex = pindex;

19 エイリアスは、ファイル作成時に割り当てるか、またはALTER DISKGROUP <diskgroup> ADD ALIAS <alias name> for <

file name>コマンドで既存のファイルにエイリアスを作成します。 20 他のファイル・タイプに使用できるものとして、*_DEST変数があります。


28


テンプレート

ASMファイル・テンプレートは、ファイル作成時にファイルに適用された、属性の名前付きコレクションです。

テンプレートは、複雑なファイル属性の仕様を格納することで、ファイル作成を簡素化します。ASMテンプレー

トがファイルに適用されると、そのファイルはテンプレートのすべての属性を持つようになります。ディスク・

グループを作成すると、そのディスク・グループに関連付けられた初期システム・デフォルト・テンプレートの

セットが ASMによって作成されます。これらのテンプレートには、各種の Oracleデータベース・ファイル・タイ

プのデフォルト属性が含まれています。管理者は、デフォルト・テンプレートの属性を変更できます。また管理

者は、必要に応じた独自のテンプレートが追加できます。このテンプレート指定によって、ファイル作成属性の

簡素化と正確な指定が可能になります。システムのデフォルト・テンプレートは削除できません。ファイルの作

成後に ASMファイル属性の変更が必要な場合、そのファイルをコピーし、新しい属性を持つ新しいファイルとし

て保存します。これが、ファイル属性を変更する唯一の方法です。

SQL> alter diskgroup DGR14_A add template all_new_files attributes (unprotected

fine)

テンプレート作成後は、新しい表領域に適応可能です。

SQL> create tablespace ISHAN datafile ‘+DGR14_A/ishan(all_new_files)’ size 100M;


29


結論

ASMは、統一インタフェースによるデータベース・ストレージ管理に焦点を当てた、重点的なソリューションを

提供します。この完全なソリューションは、グリッド・コンピューティングを可能にし、全体的な管理コストを

削減し、サービス性を維持します。次に、ASMの重要なポイントについて確認します。

複雑な管理の削減

• 日常のデータベース管理作業を簡素化または削減します。

• すべてのタイプのワークロードを自動で I/Oチューニングします。

• 管理するオブジェクト数を減らします。つまり、Oracleカーネルにファイル・システムとボリューム・

マネージャを垂直統合することで、複数のファイル・システムを 1つのディスク・グループに置き換

えられるため、複雑さが低減されます。また、OMFを使用すると、ファイルの管理に煩わされるこ

となく、表領域のみを管理できます。

• データベース・ストレージ構成の変更の簡素化－追加および削除されたディスクのデータを自動でコ

ピーします。新しいストレージ・ハードウェアにオンラインで移行できます。

• 停止時間の低減－ASMにはファイル・システムのインタフェースがないため、誤ってファイルを削

除することがなく、ASMがファイル管理します。

ストレージ管理コストの削減と使用率の増加

• ストレージ管理のコストを削減します。

• クラスタ化されたボリューム・マネージャと、ファイル・システム機能を、データベースに統合され

た形で提供します。

• ブロック・デバイスを、ファイル・サーバーのように簡素化して管理します。

• NASデバイスから、SANディスク・アレイまで、任意のモジュラー・ストレージの任意のタイプの

ディスクを扱うことができます。

パフォーマンス、スケーラビリティ、信頼性の向上

• すべてのファイルの RAWディスク I/Oパフォーマンス

• 複数のストレージ・アレイ全体に渡ったファイルのストライプ化

• ストレージ・リソースのより効果的な活用

• ASM-Lib APIによる、CPU使用率の向上を通じた I/Oパフォーマンスの改善および優先付けられキャ

ッシングされたヒントの提供

• ファイル・システム・サイズの制限の克服

• ストレージ・アレイを障害発生から守るミラー化の実装


30


付録 A – パーティション、ビュー、および検索文字列

次に Sun Solarisのパーティション表を示します。s4パーティションの使用に注目してください。

partition> p partition table (original): Total disk cylinders available: 18412 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 unassigned wm 0 0 (0/0/0) 0 1 unassigned wm 0 0 (0/0/0) 0 2 backup wu 0 – 18411 8.43GB (18412/0/0) 17675520 3 - wu 0 - 2 1.41MB (3/0/0) 2880 4 - wu 4 – 18411 8.43GB (18408/0/0) 17671680 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wm 0 0 (0/0/0) 0

次の表は、各種ビューとインスタンス・タイプとの関係を示しています。

ASM関連のV$ビュー ASMインスタンスデータベース・インスタンス

V$ASM_DISKGROUP 検出された行/ディスク・グループローカルのデータベース・インスタンスが

使用可能な行/ディスク・グループ

V$ASM_CLIENT 接続された行/クライアント DBにオープンな ASMファイルを含む場合のローカル ASMインスタンスの行

V$ASM_DISK ディスク・グループ全体からとディスク・

グループに属さないディスクから検出さ

れた行/ディスク

行/ディスク、ローカルのデータベース・インスタンスが使用したすべてのディス

ク・グループ

V$ASM_FILE 割り当てられた行/ファイル（すべてのクライアント・インスタンス − ディスク・グループ全体）

なし

V$ASM_TEMPLATE 行/テンプレート行/テンプレート（関連付け/接続されたディスク・グループを含む）

V$ASM_ALIAS 行/ファイルのエイリアスなし

V$ASM_OPERATION 行/アクティブな ASM処理（複数の処理が起動されている場合もある）

なし

次の表は、現在サポートしているプラットフォーム上で使用される、各種のデフォルトの ASMディスク文字列で

す。次で指定されているデフォルトの検索文字列は、初期デフォルト・パラメータ値の NULLから変更されたと

きに使用します。

オペレーティング・システムデフォルト検索文字列

Solaris (32/64 bit) /dev/rdsk/*

Windows NT/XP ¥¥.¥orcldisk*

Linux (32/64 bit) /dev/raw/*

HP-UX /dev/rdsk/*

HP Tru64 UNIX /dev/rdisk/*

AIX /dev/rhdisk/*


31


付録 B − ASMへの移行

既存の 10gデータベースから ASMへの移行は複雑ではなく、RMANを使用して簡単に実行できます。ソースのデ

ータベースの場所としては、テープまたはディスクを使用します。ASMへは、データベース全体または断片的に、

表領域またはデータ・ファイル単位で移行できます。両方のオプションのプロシージャは同じです。ASMへの移

行の詳細は、次のドキュメントを参照してください。

http://www.oracle.com/technology/deploy/availability/pdf/Technical_WP_ASM_Migration.pdf

この項では、既存のデータベースを ASMボリューム管理に移行するプロシージャを説明します。

1. ブロック変更追跡の有効性を確認します。ブロック・チェンジ・トラッキングが有効の場合は、変更追跡

を無効にします。

SQL> select * from V$BLOCK_CHANGE_TRACKING; SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

2. データベースを確実にシャットダウンします。

SQL> SHUTDOWN IMMEDIATE;

3. ターゲット・データベースの初期化パラメータ・ファイルを次のように変更します。

DB_CREATE_FILE_DESTおよび DB_CREATE_ONLINE_LOG_DEST_[1234]に、使用する ASMディスク・

グループを設定します。データベースがサーバー・パラメータ・ファイルを使用している場合、制御ファ

イルの位置を指定している CONTROL_FILESパラメータを削除します。制御ファイルは、DB_CREATE_*

に移動され、サーバー・パラメータ・ファイルが自動的に更新されます。クライアント側のサーバー・パ

ラメータ・ファイルを使用している場合、ディスク・グループおよび物理ファイル名を使用して、

CONTROL_FILESパラメータを制御ファイル名の ASMエイリアスに設定します。たとえば、次のような

元の CONTROL_FILESの設定とします。

'/u07/oradata/mig10i/MIG10I/controlfile/o1_mf_zsbzfq9j_.ctl'

この場合、次の CONTROL_FILESが新しい ASM設定になります。

‘+DG14_A/ o1_mf_zsbzfq9j_.ctl' *.control_files=(+DGR14_A/o1_mf_zsbzfq9j_.ctl) *.db_create_file_dest=+DGR14_A *.db_create_online_log_dest_1 = +DG14_A *.db_name='mig10i' *.dispatchers='(PROTOCOL=TCP) (SERVICE=mig10iXDB)' *.log_archive_dest_1='LOCATION=+DGR14_A'

4. RMANを起動し、ターゲット・データベースに接続します。データベースをノーマウント・モードで起

動します。

RMAN> CONNECT TARGET; RMAN> STARTUP NOMOUNT;


32


5. 古い spfile/pfileで指定された場所から、制御ファイルを新しい場所に復元します。これで現在の制御ファ

イルは、DGR14_A ASMディスク・グループに移行されました。

RMAN> RESTORE CONTROLFILE FROM '/u07/oradata/mig10i/MIG10I/controlfile/o1_mf_zsbzfq9j_.ctl' ';

6. データベースをマウントします。

RMAN> ALTER DATABASE MOUNT;

7. 次のコマンドを使用して、データベースを ASMディスク・グループにコピーします。ここでは、元のフ

ァイルが保持されていることに注意してください。

RMAN> BACKUP AS COPY DATABASE FORMAT '+disk_group';

オプションとして、RMANの並列性を増加させることで、コピーにかかる時間を短縮できます。

RMAN> configure device type disk parallelism 4;

8. すべてのデータ・ファイルを ASMディスク・グループ内に切り替えます。

RMAN> SWITCH DATABASE TO COPY;

各データ・ファイルの切替えメッセージが表示されます。

datafile 1 switched to datafile copy "+DGR14_A/mig10i/datafile/system.271.1" datafile 2 switched to datafile copy "+DGR14_A/mig10i/datafile/undotbs1.259.3" datafile 3 switched to datafile copy "+DGR14_A/mig10i/datafile/sysaux.272.1" datafile 4 switched to datafile copy "+DGR14_A/mig10i/datafile/users.270.1" datafile 5 switched to datafile copy "+DGR14_A/mig10i/datafile/example.273.1"

この処理の後で、すべてのデータ・ファイルが ASMに入ります。元のデータ・ファイル（古いストレージ上

のもの）は、データ・ファイル・コピーとしてカタログ化されるため、これをバックアップとして使用できま

す。また、古いストレージに移行し直す場合、これにも切替えできます。

9. データベースのリカバリ（必要な場合）

10. データベースをオープンします。open resetlogsの実行は必要ありません。

RMAN> ALTER DATABASE OPEN;

11. 手動で一時表領域を作成します（tempfile）。制御ファイルに、一時表領域のレコードがないため、RMAN

は tempfileのコピー作成や移行は行いません。したがって、手動で ASM内に一時表領域を再作成します。

SQL> create TEMPORARY tablespace temp_tempfile_local size 100M 3 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;


33


12. 次は、オンライン・ログを ASMに移動します。REDOログの移行には、次の PL/SQLプロシージャを使

用します。

declare cursor orlc is select lf.member, l.bytes from v$log l, v$logfile lf where l.group# = lf.group# and lf.type = 'ONLINE' order by l.thread#, l.sequence#; type numTab_t is table of number index by binary_integer; type charTab_t is table of varchar2(1024) index by binary_integer; byteslist numTab_t; namelist charTab_t; procedure migrateorlfile(name IN varchar2, bytes IN number) is retry number; stmt varchar2(1024); als varchar2(1024) := 'alter system switch logfile'; begin select count(*) into retry from v$logfile; stmt := 'alter database add logfile size ' || bytes; execute immediate stmt; stmt := 'alter database drop logfile ''' || name || ''''; for i in 1..retry loop begin execute immediate stmt; exit; exception when others then if i > retry then raise; end if; execute immediate als; end; end loop; end; begin open orlc; fetch orlc bulk collect into namelist, byteslist; close orlc; for i in 1..namelist.count loop migrateorlfile(namelist(i), byteslist(i)); end loop; end; /

13. ここで、オプションとして古いデータベース・ファイルの削除ができます。RMANには、古いデータ・

ファイルの情報はありますが、制御ファイルやオンライン REDOログは持っていません。このため、手

動で制御ファイルとオンライン REDOログの削除が必要です。

RMAN> run { # delete datafiles DELETE COPY OF DATABASE; HOST 'rm <old_online_redo_logs>'; HOST 'rm <old_control_file_copies>'; }


34


14. 移行の完了後、変更追跡を有効にします（無効にした場合）。

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

ASM以外の個々のデータ・ファイルの ASMへの移行

この項では、データベースがオンラインの状態で、個々の表領域の ASMへの移行方法を説明します。この図は、

マウントされたファイル・システム上に ISHANという名前の表領域を示しています。さらに、この同じプロシー

ジャを使用してデータ・ファイルをディスク・グループ間で移動もできます。

1. RMANに接続します。

RMAN> connect target

2. ターゲットの表領域をオフラインまたは読取り専用にします。

RMAN> sql "alter tablespace ISHAN offline";

3. ISHAN表領域を DGR14_Aディスク・グループにコピーします。

RMAN> backup as copy tablespace ishan format '+DGR14_A';

4. 表領域のコピーの完了後、ISHAN表領域にあるすべてのデータ・ファイルを ASMに切り替えます。切替

えが必要なファイルの数を決定します（v$datafileを使用）。

RMAN> switch datafile 6 to copy;

次のメッセージが表示されたら、表領域が正しく移行できたと判断できます。

datafile 6 switched to datafile copy "+DGR14_A/b2r6/datafile/ishan.314.1"

元のファイル・システムのコピーは存在していますが、削除もできます。


35


付録 C − DataPumpファイル・セットと ASM

この項では、ASMのディスク・グループ内における DataPumpエクスポート・ダンプセットの作成方法を説明し

ています。

1. ASMからディレクトリを作成します。このステップは、ダンプセットを特定なディレクトリへの格納に

のみ必要です。

alter diskgroup flash add directory '+flash/dumpsets';

2. データベースにディレクトリを作成します。

create directory dumpsets as '+flash/dumpsets';

3. ログ・ファイルは ASMには格納できないので、ログ・ファイル・ディレクトリを作成します。

create directory logfile_dest as '/u01/admin/dumpsets';

4. expdp parfile=expdp_parfile

expdp_parfileの内容を次に示します。

userid=system/manager1 directory='DUMPSETS' dumpfile=expdp_5_5.dat job_name=full_export logfile=logfile_dest:exp5_5.log

5. ASMにファイルが作成されたことを確認します。

SQL> select file_number, bytes, creation_date from v$asm_file where type ='DUMPSET';

FILE_NUMBER BYTES CREATION_

----------- ---------- ---------

581 2785280 07-MAY-04


36


付録 D − ASMに追加の制御ファイルの作成

次のプロシージャを使用して、ASMディスク・グループに追加の制御ファイルを作成できます。

1. 次のコマンドにより、ディスク・グループに新しいディレクトリを作成します（オプション）。

alter diskgroup <DG_name> add directory '+<DG_name>/<DB_name>'; alter diskgroup <DG_name> add directory '+<DG_name>/<DB_name>/controlfile';

2. 次に、新しい制御ファイルを指すために、SPFILE/init.ora の中の制御ファイル・エントリーを編集してく

ださい。ここで、新しい制御ファイルは、+DATA2/ora10g/controlfile/control03.ctl' です。

*.control_files='+DATA/0ra10g/controlfile/current.260.3’,’+FLASH/Ora10G/controlfile/o1_mf_0fh3t83f_.ctl’,’DATA2/ora10g/controlfile/control03.ctl'

3. データベースを確実にシャットダウンします（RACを使用している場合はすべてのインスタンスを停止

します）。

shutdown immediate;

4. データベースをノーマウント・モードで起動します。

startup nomount;

5. RMANを使用して、制御ファイルを既存の位置の 1つから新しい位置にリストアします。

restore controlfile to 'DATA2/Ora10g/controlfile/control03.ctl' from '+FLASH/Ora10g/controlfile/current.260.3';

6. データベースをマウントして、必要に応じてリカバリします。

SQL> alter database mount; SQL> recover database;

7. データベースをオープンします。

SQL> alter database open;


37


付録 E − ASM SQLスクリプト

次に、ASMファイルのリスティングや削除などの管理に役立つスクリプトの概要を示します。これらの機能の実

行には、10g EM Grid Controlまたは Database Controlの使用をお薦めします。

1. 次の SQL文は、与えられたデータベースの ASMファイルを一覧表示するスクリプトを生成します。ディ

レクトリ構造から始まり、その後にファイルが一覧表示されます。このスクリプトは、ASMファイル命

名規則によるファイルの作成を前提とします。具体的には、与えられたデータベースの名前がエイリアス

（full_path列）としていることを前提としています。クエリーは、データベース名を要求します。

クエリー中の full_path変数は、エイリアスを指します。dir列は、ディレクトリかどうかを示します。sys

列は、エイリアスがシステムによる作成かどうかを示します。

COL full_path FORMAT a120

COL dir FORMAT a3

COL sys FORMAT a3

SET ECHO OFF

SET VERIFY OFF

SET FEEDBACK OFF

SET PAGESIZE 39

SET LINESIZE 130

--get database name

ACCEPT database PROMPT 'Enter the database name: '

--spool file

spool lis_&database..lst

--generates list

SELECT full_path, dir, sys FROM

(SELECT CONCAT('+'||gname, SYS_CONNECT_BY_PATH(aname,'/')) full_path, dir,

sys FROM

(SELECT g.name gname, a.parent_index pindex, a.name aname,

a.reference_index rindex, a.ALIAS_DIRECTORY dir, a.SYSTEM_CREATED sys

FROM v$asm_alias a, v$asm_diskgroup g

WHERE a.group_number = g.group_number)

START WITH (MOD(pindex, POWER(2, 24))) = 0

CONNECT BY PRIOR rindex = pindex

ORDER BY dir desc, full_path asc)

WHERE full_path LIKE UPPER('%/&database%');

--end spool

spool off

-- resetting format

COL full_path CLEAR

COL dir CLEAR

COL sys CLEAR

SET VERIFY ON

SET HEADING ON

SET FEEDBACK ON


38


2. 次の SQL文は、与えられたデータベースの ASMにあるファイルを削除するスクリプトを生成します。こ

のスクリプトは、ファイルの ASM命名規則による作成を前提としています。具体的には、与えられたデ

ータベース名がエイリアス（full_path列）として、 "/データベース名/"という形式で存在することを前提

としています。このスクリプトは、データベース名を要求します。

COL gsql FORMAT a300

SET ECHO OFF

SET VERIFY OFF

SET HEADING OFF

SET FEEDBACK OFF

SET PAGESIZE 0

SET LINESIZE 600

SET TRIMSPOOL ON

--get database name

ACCEPT database PROMPT 'Enter the database name: '

--spool file

spool del_&database..sql

--generates file list

SELECT 'ALTER DISKGROUP '||gname||' DROP FILE '''||full_path||''';' gsql

FROM

(SELECT CONCAT('+'||gname, SYS_CONNECT_BY_PATH(aname,'/')) full_path, gname

FROM


a.reference_index rindex, a.ALIAS_DIRECTORY adir



WHERE adir='N'


CONNECT BY PRIOR rindex = pindex)

WHERE full_path LIKE UPPER('%/&database/%');


39


3. 次の SQL文は、ASMディレクトリを削除するスクリプトを生成します。

SELECT 'ALTER DISKGROUP '||gname||' DROP DIRECTORY '''||full_path||''';'

gsql FROM

(SELECT CONCAT('+'||gname, SYS_CONNECT_BY_PATH(aname,'/')) full_path, gname

FROM


a.reference_index rindex, a.ALIAS_DIRECTORY adir



WHERE adir='Y'


CONNECT BY PRIOR rindex = pindex

ORDER BY full_path desc)

WHERE full_path LIKE UPPER('%/&&database%');

--end spool

spool off

-- resetting format

COL gsql CLEAR

SET VERIFY ON

SET HEADING ON

SET FEEDBACK ON

SET PAGESIZE 30

SET LINESIZE 600

SET TRIMSPOOL OFF


40


oracle database 10g automatic storage management の技術的なベスト...

Documents