Oracle Database 管理者ガイド 11gリリース1(11.1) E05760-03 |
|
この章の内容は次のとおりです。
データファイルは、データベース内に存在するすべての論理構造のデータを格納する、オペレーティング・システムの物理ファイルです。データファイルは、表領域ごとに明示的に作成する必要があります。
注意: 一時ファイルはデータファイルの特殊なクラスで、一時表領域にのみ関連付けられます。この章で説明する内容は、相違点が示されている場合を除き、データファイルと一時ファイルの両方に適用されます。一時ファイルの詳細は、「ローカル管理の一時表領域の作成」を参照してください。 |
Oracle Databaseは、絶対ファイル番号および相対ファイル番号という2つの関連するファイル番号を各データファイルに割り当てます。これらは、データファイルを一意に識別するために使用されます。これらの番号について、次の表で説明します。
ここでは、データファイルの管理について説明します。この項の内容は、次のとおりです。
データベースのSYSTEM
表領域およびSYSAUX
表領域には、少なくとも1つのデータファイルが必要です。データベースにはこれ以外に、複数の表領域とそれに関連するデータファイルまたは一時ファイルが含まれている必要があります。データベースで作成するデータファイルの数に応じて、初期化パラメータの設定値およびCREATE
DATABASE
文の句の指定が決定します。
オペレーティング・システムによっては、Oracle Databaseに格納できるデータファイルの数が制限される場合があります。また、データファイル数およびその割当ての方法と場所によって、データベースのパフォーマンスが影響を受ける可能性があることを考慮してください。
注意: データベース内のデータファイルの数を制御してその管理を簡素化する方法の1つが、大型ファイル表領域の使用です。大型ファイル表領域は1つの大型データファイルのみで構成され、大規模データベースを使用する場合、および論理ボリューム・マネージャを使用してオペレーティング・システム・ファイルを管理する場合に特に役立ちます。大型ファイル表領域については、「大型ファイル表領域」を参照してください。 |
データベースのデータファイルの数を決める際は、次のガイドラインを考慮してください。
DB_FILES
初期化パラメータは、Oracle Databaseインスタンスを起動するときに、データファイル情報用に予約するシステム・グローバル領域(SGA)の容量を指定します。これによって、インスタンスで作成可能なデータファイルの最大数が決定します。この制限が適用されるのは、インスタンスが存続する期間内です。DB_FILES
の値は(初期化パラメータ設定を変更することで)変更できますが、新しい値はインスタンスをいったん停止して再起動するまでは有効になりません。
DB_FILES
の値を決めるときは、次の点を考慮してください。
DB_FILES
の値が小さすぎる場合は、最初にデータベースを停止しないと、DB_FILES
制限を超えてデータファイルを追加できません。
DB_FILES
の値が大きすぎると、メモリーが不必要に消費されます。
データファイルを従来の小型ファイル表領域に追加するときには、次の制限事項があります。
DB_FILES
初期化パラメータで指定したデータファイルの数を超えることはできません。
CREATE DATABASE
文またはCREATE CONTROLFILE
文を発行するときに、MAXDATAFILES
パラメータによって制御ファイルのデータファイル部分の初期サイズを指定します。ただし、新しく追加するファイルの番号がMAXDATAFILES
より大きくDB_FILES
以下であれば、データファイルのセクションにより多数のファイルを格納できるように、制御ファイルが自動的に拡張されます。
表領域、そして最終的にはデータベースに格納されるデータファイルの数は、パフォーマンスに影響を与える可能性があります。
Oracle Databaseでは、オペレーティング・システムで定義されている制限よりも多くの数のデータファイルをデータベース内に作成できます。データベースのDBWnプロセスは、すべてのオンライン・データファイルをオープンできます。Oracle Databaseには、オープン・ファイル記述子をキャッシュとして処理し、オープン・ファイル記述子の数がオペレーティング・システムで定義されている制限に達したときに自動的にファイルをクローズする機能があります。この機能は、パフォーマンスに悪影響を与えるおそれがあります。できれば、オープン・ファイル記述子に関するオペレーティング・システムの制限を調整して、それがデータベース内のオンライン・データファイルの数より大きくなるようにしてください。
表領域を作成するときは、データベース・オブジェクトの将来的なサイズを見積り、十分な数のデータファイルを作成する必要があります。必要に応じて、後で表領域に割り当てられたディスク領域のすべての容量(その結果としてデータベースの容量)を大きくするために、データファイルを作成して表領域に追加できます。可能であれば、データがすべてのデバイスに均等に配分されるように、データファイルを複数のデバイスに作成してください。
表領域の位置は、その表領域を構成するデータファイルの物理的な位置によって決まります。コンピュータのハードウェア資源を適切に使用してください。
たとえば、データベースを格納するためのディスク・ドライブが複数使用可能な場合は、競合の可能性のあるデータファイルを別のディスクに配置することを検討してください。このようにすると、ユーザーが情報を問い合せるときに両方のディスク・ドライブが同時に動作し、同時にデータを取得できます。
データファイルは、データベースのREDOログ・ファイルが格納されているディスク・ドライブに格納しないでください。データファイルとREDOログ・ファイルが同じディスク・ドライブに格納されていて、このディスク・ドライブで障害が発生すると、これらのファイルをデータベースのリカバリ手順で使用できなくなります。
REDOログ・ファイルを多重化すると、全REDOログ・ファイルが失われる可能性が低くなるので、データファイルを一部のREDOログ・ファイルと同じドライブに格納できます。
データファイルを作成して表領域を対応付けるには、次の表にリストされている文のいずれかを使用します。どの文でも、作成するデータファイルのファイル仕様を指定するか、またはOracle Managed Files機能を使用してデータベース・サーバーが作成し管理するファイルを作成できます。表には、データファイルの作成に使用する文の簡単な説明と、このマニュアル内に記載されている文の詳細説明への参照が示されています。
表領域に新しいデータファイルを追加するときにファイル名を完全に指定しないと、データファイルは、オペレーティング・システムに応じてデフォルトのデータベース・ディレクトリまたはカレント・ディレクトリに作成されます。データファイルには、常に完全修飾名を使用することをお薦めします。既存のファイルを再利用する場合以外は、新しいファイル名が他のファイルと競合しないことを確認してください。すでに削除済の旧ファイルは上書きされます。
データファイルを作成する文が失敗した場合は、作成されたオペレーティング・システム・ファイルがすべて削除されます。ただし、ファイル・システムやストレージ・サブシステムで発生する多数の潜在的なエラーが原因で、オペレーティング・システムのコマンドを使用した手動でのファイル削除が必要になる場合があります。
ここでは、データファイルのサイズを変更する様々な方法について説明します。この項の内容は、次のとおりです。
データベースに追加の領域が必要になった場合に、自動的にサイズを拡張するデータファイルを作成できます。また、既存のデータファイルを自動拡張するように変更することも可能です。ファイルのサイズは、指定されている最大値に達するまで、指定の増分値ずつ大きくなります。
データファイルを自動的に拡張するように設定しておくと、次のような利点があります。
データファイルが自動的に拡張できるかどうか確認するには、DBA_DATA_FILES
ビューを問い合せ、AUTOEXTENSIBLE
列を調べます。
自動ファイル拡張を指定するには、次のSQL文を使用してデータファイルを作成するときにAUTOEXTEND ON
句を指定します。
既存のデータファイルの自動ファイル拡張機能を使用可能または使用禁止にしたり、データファイルのサイズを手動で変更するには、ALTER
DATABASE
文を使用します。大型ファイル表領域では、ALTER
TABLESPACE
文を使用してこれらの操作を実行できます。
次の例は、users
表領域に追加するデータファイルの自動拡張機能を使用可能にします。
ALTER TABLESPACE users ADD DATAFILE '/u02/oracle/rbdb1/users03.dbf' SIZE 10M AUTOEXTEND ON NEXT 512K MAXSIZE 250M;
NEXT
の値は、データファイルの拡張時にこのファイルに追加される増分値の最小サイズです。MAXSIZE
の値は、自動拡張可能なファイルの最大サイズです。
次の例は、データファイルの自動拡張機能を使用禁止にします。
ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/users03.dbf' AUTOEXTEND OFF;
手動でデータファイルのサイズを増減させるには、ALTER DATABASE
文を使用します。データファイルのサイズを変更できるため、データファイルを追加しなくてもデータベースに領域を追加できます。この機能は、データベースで許容されているデータファイルの最大数に達することが懸念される場合に有効です。
大型ファイル表領域では、ALTER
TABLESPACE
文を使用して、データファイルのサイズを変更できます。大型ファイル表領域にはデータファイルを追加できません。
また、データファイルのサイズを手動で縮小することで、データベース内の未使用領域を再生できます。これは、領域要件の見積りの誤りを訂正する際に有効です。
次の例では、データファイル/u02/oracle/rbdb1/stuff01.dbf
が250MBまで拡張されていることを想定しています。ただし、その表領域には現在小さなオブジェクトが格納されているので、データファイルのサイズを縮小できます。
次の文は、データファイル/u02/oracle/rbdb1/stuff01.dbf
のサイズを縮小します。
ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' RESIZE 100M;
個々のデータファイルまたは一時ファイルは、オフライン化またはオンライン化することでその可用性を変更できます。オフラインのデータファイルはデータベースに使用できず、オンライン化されるまでアクセスできません。
データファイルの可用性の変更には、次のような理由があります。
読取り専用表領域のデータファイルはオフライン化またはオンライン化ができますが、ファイルをオンライン化しても表領域の読取り専用状態に影響を与えることはありません。表領域が読取り/書込み可能な状態に戻るまで、このデータファイルには書き込めません。
注意: 表領域自体をオフライン化することによって、表領域のすべてのデータファイルを一時的に使用禁止にできます。表領域をオンラインに戻すためには、表領域内のデータファイルはすべてそのままにしておく必要があります。ただし、「データファイルの名前変更と再配置」で説明する手順に従ってデータファイルを再配置または名前を変更することは可能です。 詳細は、「表領域のオフライン化」を参照してください。 |
データファイルをオンライン化またはオフライン化するには、ALTER DATABASE
システム権限が必要です。ALTER TABLESPACE
文を使用してすべてのデータファイルまたは一時ファイルをオフライン化するには、ALTER TABLESPACE
またはMANAGE TABLESPACE
システム権限が必要です。Oracle Real Application Clusters環境では、データベースを排他モードでオープンする必要があります。
ここでは、データファイルの可用性を変更する様々な方法について説明します。この項の内容は、次のとおりです。
個々のデータファイルをオンライン化するには、DATAFILE
句を指定してALTER DATABASE
文を発行します。次の文では、指定したデータファイルがオンライン化されます。
ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' ONLINE;
これと同じファイルをオフライン化するには、次の文を発行します。
ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' OFFLINE;
データベースがNOARCHIVELOG
モードのときにデータファイルをオフライン化するには、DATAFILE
句およびOFFLINE
FOR
DROP
句を指定してALTER
DATABASE
文を使用します。
OFFLINE
キーワードを指定すると、破損しているかどうかに関係なくデータファイルにOFFLINE
のマークが付くため、データベースをオープンできます。
FOR
DROP
キーワードによって、データファイルが後で削除されるようにマークが付けられます。このようなデータファイルは、オンラインに戻すことはできません。
次の文は、指定したデータファイルをオフライン化し、削除対象としてマークを付けます。
ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/users03.dbf' OFFLINE FOR DROP;
ALTER TABLESPACE
文で句を指定することにより、表領域内にあるすべてのデータファイルまたは一時ファイルのオンラインまたはオフラインの状態を変更できます。具体的には、オンライン/オフラインの状態に影響を与える文として次のものがあります。
入力が必要なのは表領域名のみであり、個々のデータファイルや一時ファイルを入力する必要はありません。すべてのデータファイルまたは一時ファイルが影響を受けますが、表領域そのもののオンライン/オフラインの状態は変わりません。
ほとんどの場合、データベースがマウントされていれば、オープンしていなくても、前述のALTER TABLESPACE
文を発行できます。ただし、表領域がSYSTEM
表領域、UNDO表領域またはデフォルト一時表領域である場合は、データベースをオープンしないでください。ALTER DATABASE DATAFILE
文およびALTER DATABASE TEMPFILE
文にも ONLINE/OFFLINE
句がありますが、これらの文では表領域のファイル名をすべて入力する必要があります。
この操作は表領域の可用性を変更するALTER TABLESPACE...ONLINE|OFFLINE
文とは操作が異なるため、構文も異なります。ALTER TABLESPACE
文は表領域だけでなくデータファイルもオフラインにしますが、一時表領域または一時ファイルの状態を変更するためには使用できません。
データファイルの名前を変更して、それらの名前や位置を変更できます。次の項では、その手順について説明します。
これらの手順を使用してデータファイルを名前変更または再配置すると、データベースの制御ファイルに記録されている、データファイルへのポインタのみが変わります。これらの手順では、オペレーティング・システム・ファイルを物理的に名前変更したり、ファイルをオペレーティング・システム・レベルでコピーすることはありません。データファイルの名前変更と再配置には、複数の手順が必要です。手順と例題をよく理解してから実行してください。
ここでは、単一の表領域のデータファイルを名前変更および再配置するための手順をいくつか示します。この手順を実行するには、ALTER TABLESPACE
システム権限が必要です。
単一の表領域のデータファイルの名前を変更する手順は、次のとおりです。
次に例を示します。
ALTER TABLESPACE users OFFLINE NORMAL;
ALTER TABLESPACE
文にRENAME DATAFILE
句を指定して、データベース内のファイル名を変更します。 たとえば、次の文はデータファイル/u02/oracle/rbdb1/user1.dbf
および/u02/oracle/rbdb1/user2.dbf
をそれぞれ/u02/oracle/rbdb1/users01.dbf
および/u02/oracle/rbdb1/users02.dbf
に名前変更します。
ALTER TABLESPACE users RENAME DATAFILE '/u02/oracle/rbdb1/user1.dbf', '/u02/oracle/rbdb1/user2.dbf' TO '/u02/oracle/rbdb1/users01.dbf', '/u02/oracle/rbdb1/users02.dbf';
古いデータファイルと新しいデータファイルを正しく識別するために、必ず完全なファイル名(パスを含む)を指定してください。特に、古いデータファイル名は、データ・ディクショナリのDBA_DATA_FILES
ビューに表示されるとおり、正確に指定してください。
ここでは、データファイルを再配置する手順の例を示します。
想定する条件は、次のとおりです。
users
という表領域が存在し、すべて同じディスク上に配置されたデータファイルによって構成されています。
users
表領域のデータファイルを、別の分離されたディスク・ドライブに再配置します。
次の手順を実行します。
DBA_DATA_FILES
を問い合せて情報を取得できます。
SQL> SELECT FILE_NAME, BYTES FROM DBA_DATA_FILES 2> WHERE TABLESPACE_NAME = 'USERS'; FILE_NAME BYTES ------------------------------------------ ---------------- /u02/oracle/rbdb1/users01.dbf 102400000 /u02/oracle/rbdb1/users02.dbf 102400000
ALTER TABLESPACE users OFFLINE NORMAL;
DBMS_FILE_TRANSFER
パッケージを使用して、ファイルをコピーできます。users
表領域を構成するファイルのデータファイル・ポインタは、対応付けられているデータベースの制御ファイルに記録されていますが、これらのポインタをこの時点で旧ファイル名から新ファイル名に変更する必要があります。
ALTER TABLESPACE...RENAME DATAFILE
文を使用します。
ALTER TABLESPACE users RENAME DATAFILE '/u02/oracle/rbdb1/users01.dbf', '/u02/oracle/rbdb1/users02.dbf' TO '/u03/oracle/rbdb1/users01.dbf', '/u04/oracle/rbdb1/users02.dbf';
1つ以上の表領域のデータファイルは、ALTER DATABASE RENAME FILE
文を使用して、名前変更および再配置できます。1回の操作で複数の表領域のデータファイルを名前変更または再配置する方法は、これ以外にありません。この手順を実行するには、ALTER DATABASE
システム権限が必要です。
複数の表領域のデータファイルの名前を変更する手順は、次のとおりです。
DBMS_FILE_TRANSFER
パッケージを使用して、ファイルをコピーできます。
ALTER DATABASE
を使用して、データベースの制御ファイル内のファイル・ポインタの名前を変更します。 たとえば、次の文はデータファイル/u02/oracle/rbdb1/sort01.dbf
および/u02/oracle/rbdb1/user3.dbf
をそれぞれ/u02/oracle/rbdb1/temp01.dbf
および/u02/oracle/rbdb1/users03.dbf
に名前変更します。
ALTER DATABASE RENAME FILE '/u02/oracle/rbdb1/sort01.dbf', '/u02/oracle/rbdb1/user3.dbf' TO '/u02/oracle/rbdb1/temp01.dbf', '/u02/oracle/rbdb1/users03.dbf;
古いデータファイルと新しいデータファイルを正しく識別するために、必ず完全なファイル名(パスを含む)を指定してください。特に、古いデータファイル名は、DBA_DATA_FILES
ビューに表示されるとおり、正確に指定してください。
単一のデータファイルまたは一時ファイルを削除するには、ALTER
TABLESPACE
コマンドのDROP
DATAFILE
およびDROP
TEMPFILE
句を使用します。データファイルは空である必要があります(データファイルから割り当てられたエクステントが残っていない場合、データファイルは空とみなされます)。データファイルまたは一時ファイルを削除すると、データファイルまたは一時ファイルへの参照はデータ・ディクショナリおよび制御ファイルから削除され、物理ファイルがファイル・システムまたは自動ストレージ管理(ASM)ディスク・グループから削除されます。
次の例では、ASMディスク・グループDGROUP1
の別名example_df3.f
で識別されたデータファイルを削除します。データファイルは表領域example
に属します。
ALTER TABLESPACE example DROP DATAFILE '+DGROUP1/example_df3.f';
次の例では、表領域lmtemp
に属する一時ファイルlmtemp02.dbf
を削除します。
ALTER TABLESPACE lmtemp DROP TEMPFILE '/u02/oracle/data/lmtemp02.dbf';
これは、次の文と同じです。
ALTER DATABASE TEMPFILE '/u02/oracle/data/lmtemp02.dbf' DROP INCLUDING DATAFILES;
ALTER
TABLESPACE
構文の詳細は、『Oracle Database SQLリファレンス』を参照してください。
データファイルおよび一時ファイルの削除に関する制限事項は、次のとおりです。
空でなく、スキーマ・オブジェクトを削除しても空にできないデータファイルを削除する場合は、そのデータファイルを含む表領域を削除する必要があります。
これは、大型ファイル表領域にはDROP
DATAFILE
を使用できないことを意味します。
SYSTEM
表領域のデータファイルは削除できません。
チェックサムを使用してデータ・ブロックを検証するようにデータベースを構成する場合は、初期化パラメータDB_BLOCK_CHECKSUM
をTYPICAL
(デフォルト)に設定します。これによって、DBWnプロセスおよびダイレクト・ローダーが各ブロックのチェックサムを計算し、ブロックをディスクに書き込むときにこのチェックサムをブロック・ヘッダーに格納します。
ブロックが読み込まれるときにチェックサムが検証されるのは、DB_BLOCK_CHECKSUM
がTRUE
に設定され、前回ブロックが書き込まれたときにチェックサムが格納されている場合のみです。破損が検出されると、メッセージORA-01578
が返され、破損に関する情報がアラート・ログに書き込まれます。
DB_BLOCK_CHECKSUM
パラメータの値は、ALTER SYSTEM
文で動的に変更できます。このパラメータの設定に関係なく、SYSTEM
表領域のデータ・ブロックは常にチェックサムを使用して検証されます。
データベース内のファイルをコピーする場合、またはデータベース間でファイルを転送する場合(トランスポータブル表領域機能を使用して転送する場合など)は、必ずしもオペレーティング・システムを使用する必要はありません。これらの処理は、DBMS_FILE_TRANSFER
パッケージ、またはStreamsの伝播を使用して行うこともできます。このマニュアルではStreamsの使用方法については説明していませんが、DBMS_FILE_TRANSFER
パッケージの使用例は「ファイルのローカル・ファイル・システムへのコピー」に示しています。
DBMS_FILE_TRANSFER
パッケージでは、ローカル・ファイル・システムまたは自動ストレージ管理(ASM)ディスク・グループをファイル転送の移動元または移動先として使用できます。ASMへの転送またはASMからの転送に含めることができるのは、Oracleデータベース・ファイル(データファイル、一時ファイル、制御ファイルなど)のみです。
UNIXシステムでは、DBMS_FILE_TRANSFER
パッケージを使用して作成したファイルの所有者は、インスタンスを実行するシャドウ・プロセスの所有者です。通常、この所有者はORACLE
です。DBMS_FILE_TRANSFER
を使用して作成されたファイルは、常に、データベース内のすべてのプロセスで書込みと読取りが可能です。ただし、権限を持たないユーザーがこのようなファイルを直接読取りまたは書込みする必要がある場合は、システム管理者によるアクセスが必要になる場合があります。
この項の内容は、次のとおりです。
関連項目:
DBMS_FILE_TRANSFER
パッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
この項では、DBMS_FILE_TRANSFER
パッケージのCOPY_FILE
プロシージャを使用してファイルをローカル・ファイル・システムにコピーする例を示します。次の例では、/usr/admin/source
ディレクトリ内のdb1.dat
という名前のバイナリ・ファイルを、ローカル・ファイル・システムの/usr/admin/destination
ディレクトリにdb1_copy.dat
という名前でコピーします。
CREATE DIRECTORY
を使用して、コピー元ファイルが格納されるディレクトリのディレクトリ・オブジェクトを作成します。ディレクトリ・オブジェクトは、ディレクトリの別名に類似しています。たとえば、SOURCE_DIR
というディレクトリ・オブジェクトを、使用しているコンピュータ・システムの/usr/admin/source
ディレクトリに対して作成するには、次の文を実行します。
CREATE DIRECTORY SOURCE_DIR AS '/usr/admin/source';
CREATE
DIRECTORY
を使用して、バイナリ・ファイルがコピーされるディレクトリのディレクトリ・オブジェクトを作成します。たとえば、DEST_DIR
というディレクトリ・オブジェクトを、使用しているコンピュータ・システムの/usr/admin/destination
ディレクトリに対して作成するには、次の文を実行します。
CREATE DIRECTORY DEST_DIR AS '/usr/admin/destination';
COPY_FILE
プロシージャを実行するユーザーに対して、必要な権限を付与します。この例では、strmadmin
ユーザーがプロシージャを実行します。
GRANT EXECUTE ON DBMS_FILE_TRANSFER TO strmadmin; GRANT READ ON DIRECTORY source_dir TO strmadmin; GRANT WRITE ON DIRECTORY dest_dir TO strmadmin;
strmadmin
ユーザーとして接続し、プロンプトが表示されたらユーザー・パスワードを入力します。
CONNECT strmadmin
COPY_FILE
プロシージャを実行して、ファイルをコピーします。
BEGIN DBMS_FILE_TRANSFER.COPY_FILE( source_directory_object => 'SOURCE_DIR', source_file_name => 'db1.dat', destination_directory_object => 'DEST_DIR', destination_file_name => 'db1_copy.dat'); END; /
DBMS_FILE_TRANSFER
パッケージのプロシージャは、通常、ローカル・プロシージャ・コールとして起動しますが、リモート・プロシージャ・コールとして起動することもできます。リモート・プロシージャ・コールとして起動すると、別のデータベースに接続している場合でも、データベース内のファイルをコピーできます。たとえば、次のリモート・プロシージャ・コールを実行すると、別のデータベースに接続していても、データベースDB
でファイルをコピーできます。
DBMS_FILE_TRANSFER.COPY_FILE@DB(...)
また、リモート・プロシージャ・コールを使用すると、いずれのデータベースにも接続していなくても、2つのデータベース間でファイルをコピーできます。たとえば、データベースA
に接続し、ファイルをデータベースB
からデータベースC
に転送できます。この場合、データベースA
は、転送するファイルの転送元でも転送先でもないため、サード・パーティになります。
サード・パーティ・ファイル転送では、ファイルのプッシュとプルの両方が可能です。前述の例では、A
からB
またはC
へのデータベース・リンクがあり、そのデータベースから別のデータベースへのデータベース・リンクがある場合は、サード・パーティ・ファイル転送を実行できます。データベースA
からB
およびC
両方へのデータベース・リンクは必要ありません。
たとえば、A
からB
へのデータベース・リンクがあり、B
からC
への別のデータベース・リンクがある場合は、データベースA
で次のプロシージャを実行してファイルをB
からC
に転送できます。
DBMS_FILE_TRANSFER.PUT_FILE@B(...)
この構成では、ファイルをプッシュします。
または、A
からC
へのデータベース・リンクがあり、C
からB
への別のデータベース・リンクがある場合は、データベースA
で次のプロシージャを実行してファイルをB
からC
に転送できます。
DBMS_FILE_TRANSFER.GET_FILE@C(...)
この構成では、ファイルをプルします。
DBMS_SCHEDULER
パッケージを使用して、単一のデータベース内およびデータベース間でファイルを自動的に転送できます。DBMS_SCHEDULER
パッケージではサード・パーティ・ファイル転送もサポートされています。スケジューラによって実行されるファイル転送が長時間実行される場合は、ファイルの読取りまたは書込みを行うデータベースでV$SESSION_LONGOPS
動的パフォーマンス・ビューを使用してファイル転送を監視できます。スケジューラ・ジョブで使用するデータベース・リンクは、必ず固定ユーザー・データベース・リンクです。
再開可能なスケジューラ・ジョブを使用すると、特に断続的に障害が発生する場合に、ファイル転送の信頼性を自動的に改善できます。転送先ファイルがクローズする前にファイル転送が失敗した場合は、部分的に書き込まれた転送先ファイルがデータベースによって削除された後、ファイル転送を最初から再開できます。したがって、ジョブの残りの部分が再開可能な場合は、再開可能なスケジューラ・ジョブを使用してファイルを転送することを検討してください。スケジューラ・ジョブの詳細は、第27章「Oracle Schedulerを使用したジョブのスケジューリング」を参照してください。
DBMS_FILE_TRANSFER
パッケージとDBMS_SCHEDULER
パッケージの両方を使用すると、複雑なファイル転送メカニズムを作成できます。たとえば、転送するファイルのコピーが複数のデータベースに存在する場合は、ソースの可用性、ソースのロード、宛先データベースへの通信帯域幅などの要因を検討して、最初にアクセスするソース・データベース、および障害発生時にアクセスを試みるソース・データベースを決定します。この場合、それらの要因に関する情報を入手する必要があるため、要因を検討するメカニズムを構築する必要があります。
別の例として、ロードよりも完了時間が短いことが重要である場合は、複数のスケジューラ・ジョブを発行してファイル転送をパラレルで実行できます。また、ソース・データベースと転送先データベースのファイル・レイアウトに関する知識があれば、使用するI/Oデバイスが異なる場合のみ同時転送を実行またはスケジュールすることで、ディスクの競合を最小限にできます。
データファイルが単なるファイル・システム・ファイルである環境や、RAWデバイス上で直接作成される環境では、表領域と基礎となるデバイスとの関連付けを調べるのは比較的容易です。Oracle Databaseには、ファイルとデバイスとのマッピングを提供するDBA_TABLESPACES
、DBA_DATA_FILES
およびV$DATAFILE
などのビューが用意されています。これらのマッピングをデバイス統計と併用して、I/Oパフォーマンスを評価できます。
ただし、ホスト・ベースの論理ボリューム・マネージャ(LVM)と、Redundant Array of Inexpensive Disks(RAID)機能を提供する洗練されたストレージ・サブシステムの導入によって、ファイルからデバイスへのマッピングを判別するのが難しくなっています。最新ファイルがブラック・ボックスに隠れていると、そのファイルを判断するのが難くなるため、問題が発生します。この項では、この問題を解決するためのOracle Databaseのアプローチについて説明します。
この項の内容は、次のとおりです。
I/Oパフォーマンスを把握するには、ファイルが格納されている記憶域の階層の詳細を知る必要があります。Oracle Databaseには、ファイル、論理ビューの中間レイヤーおよび実際の物理デバイスのマッピング全体を表示するメカニズムが用意されています。この表示には、動的パフォーマンス・ビュー(V$
ビュー)のセットが使用されます。これらのビューを使用すると、ファイル・ブロックがあるディスクを正確に特定できます。
これらのビューを作成するために、ストレージ・ベンダーは特定のI/Oスタック要素のマッピングを受け持つマッピング・ライブラリを提供する必要があります。データベースは、バックグラウンド・プロセスFMONによって起動される外部の非Oracle Databaseプロセスを介して、これらのライブラリと通信します。FMONは、マッピング情報の管理を受け持ちます。OracleにはPL/SQLパッケージDBMS_STORAGE_MAP
が用意されており、このパッケージを使用して、マッピング・ビューを移入するマッピング操作を起動します。
この項では、Oracle Databaseのファイル・マッピング・インタフェースの構成要素と、インタフェースの動作について説明します。この章の内容は、次のとおりです。
次の図は、ファイル・マッピング・メカニズムの構成要素を示しています。
ここでは、これらの構成要素と、各構成要素が連動してマッピング・ビューを移入する動作について説明します。
FMONは、FILE_MAPPING
初期化パラメータがTRUE
に設定されている場合に、データベースにより起動されるバックグラウンド・プロセスです。FMONの役割は、次のとおりです。
これらの構造については、「マッピング構造」を参照してください。
DBMS_STORAGE_MAP
パッケージで起動されるプロシージャを使用すると、このマッピングを制御しやすくなります。
FMONは外部の非Oracle DatabaseプロセスFMPUTL
を起動し、このプロセスはベンダーが提供するマッピング・ライブラリと直接通信します。このプロセスは、I/Oスタックのすべてのレベルにマッピング・ライブラリが存在していれば、すべてのレベルを通じてマッピング情報を取得します。一部のプラットフォームでは、I/Oマッピング・スタックの全レベルを通じてマッピングするにはルート権限が必要であるため、外部プロセスのSETUID
ビットをON
に設定する必要があります。
この外部プロセスの役割は、マッピング・ライブラリを検出してアドレス空間に動的にロードすることです。
Oracle Databaseはマッピング・ライブラリを使用して、特定のマッピング・ライブラリが所有する要素のマッピング情報を検出します。これらのマッピング・ライブラリを通じて、個々のI/Oスタック要素に関する情報が伝達されます。この情報を使用して、ユーザーが問合せできる動的パフォーマンス・ビューが移入されます。
マッピングを完成するには、すべてのスタック・レベルにマッピング・ライブラリが存在する必要があり、各ライブラリがI/Oマッピング・スタックの独自部分を所有できます。たとえば、VERITAS VxVMライブラリはVERITASボリューム・マネージャに関連するスタック要素を所有し、EMCライブラリはI/Oマッピング・スタックのうちすべてのEMCストレージ固有レイヤーを所有します。
マッピング・ライブラリはベンダーから提供されます。ただし、現在、OracleにはEMCストレージ用のマッピング・ライブラリが用意されています。データベース・サーバーに使用可能なマッピング・ライブラリは、特殊ファイルfilemap.ora内で識別されます。
この項では、マッピング構造とそのOracle Database表現について説明します。マッピング・ビューに表示される情報を解析するには、この情報を理解する必要があります。
マッピング情報を構成する基本構造は、次のとおりです。
すべてのマッピング構造は、ファイル・サイズ、ファイルを構成するファイル・システムのエクステント数およびファイル・タイプなど、ファイルの属性セットを提供します。
ファイル・システムのエクステントのマッピング構造では、1つの要素にあるブロックの連続するチャンクが記述されます。これには、デバイス・オフセット、エクステント・サイズ、ファイル・オフセット、タイプ(データまたはパリティ)およびエクステントがある要素の名前が含まれます。
要素のマッピング構造は、I/Oスタック内の記憶域コンポーネントを記述する抽象マッピング構造です。要素には、ミラー、ストライプ、パーティション、RAID5、連結要素およびディスクがあります。これらの構造は、マッピングのビルディング・ブロックです。
副要素のマッピング構造では、I/Oマッピング・スタック内のある要素と次の要素のリンクが記述されます。この構造には、副要素番号、サイズ、副要素が存在する要素の名前および要素のオフセットが含まれます。
次の例は、これらのマッピング構造すべてを示しています。
2つのデータファイルXおよびYで構成されるOracle Databaseを考えてみます。ファイルXとYはどちらもボリュームAにマウントされたファイル・システム上に存在し、ファイルXは2つのエクステントで構成され、ファイルYは1つのエクステントのみで構成されているとします。
ファイルXの2つのエクステントとファイルYの1つのエクステントは、いずれも要素Aにマップされます。要素Aは、要素BおよびCにストライプ化されています。要素Aは、副要素B0とC1を介してそれぞれ要素BとCにマップされます。
要素Bは、要素D(物理ディスク)のパーティションで、副要素D0を介して要素Dにマップされます。
要素Cは、副要素E0とF1を介してそれぞれ要素EとF(両方とも物理ディスク)にまたがってミラー化されています。
図13-2は、すべてのマッピング構造を示しています。
この図が示すマッピング構造は、Oracle Databaseインスタンスのマッピング情報全体を記述するには十分であり、ファイル内の各論理ブロックをI/Oスタック内の各レベルで1つ(またはミラー化の場合は1つ以上)の(要素名、要素オフセットの)タプルにマップしていることに注意してください。
構成IDでは、要素またはファイルに関連付けられたバージョン情報を取得します。ベンダーのライブラリには構成IDが用意されており、変更があるたびに更新されます。構成IDがなければ、データベースではマッピングに変更があったかどうかを指示できません。
構成IDには、次の2種類があります。
この種の構成IDは、インスタンスが停止されても持続します。
この種の構成IDは、インスタンスが停止すると持続しません。データベースでは、インスタンスが稼働している間にのみマッピング情報をリフレッシュできます。
この項では、Oracle Databaseのファイル・マッピング・インタフェースの使用方法について説明します。この章の内容は、次のとおりです。
ファイル・マッピング機能を使用可能にする手順は、次のとおりです。
filemap.oraファイルは、使用可能なすべてのマッピング・ライブラリが記述されている構成ファイルです。FMONを使用するには、filemap.oraファイルが存在し、マッピング・ライブラリへの有効なパスを指している必要があります。それ以外の場合は、正常に起動しません。
ライブラリごとに、次の行をfilemap.oraに含める必要があります。
lib
=vendor_name:mapping_library_path
各項目の意味は次のとおりです。
このファイル内のライブラリの順序がきわめて重要であることに注意してください。各ライブラリは、構成ファイル内での順序に基づいて問合せされます。
ファイル・マッピング・サービスは、使用可能なマッピング・ライブラリがなくても起動できます。filemap.oraファイルは、空であっても存在する必要があります。この場合、マッピング・サービスは、新しいマッピング情報を検出できないという制約を伴います。この種の構成で許可されるのは、リストア操作と削除操作のみです。
FILE_MAPPING
初期化パラメータをTRUE
に設定します。 このパラメータを設定するためにインスタンスを停止する必要はありません。次のALTER SYSTEM
文を使用して設定できます。
ALTER SYSTEM SET FILE_MAPPING=TRUE;
DBMS_STORAGE_MAP
マッピング・プロシージャを起動します。次の2つの方法があります。
DBMS_STORAGE_MAP.MAP_ALL
プロシージャを実行して、データベースに関連するI/Oサブシステム全体のマッピング情報を作成します。
DBMS_STORAGE_MAP.MAP_SAVE
プロシージャを起動してマッピング情報をデータ・ディクショナリに保存するかどうかをオプションで選択できます。(このプロシージャは、デフォルトでDBMS_STORAGE_MAP.MAP_ALL()
内で起動します。)これにより、SGA内のすべてのマッピング情報がディスクに強制的にフラッシュされます。 データベースの再起動後に、DBMS_STORAGE_MAP.RESTORE()
を使用してマッピング情報をSGAにリストアします。必要な場合は、DBMS_STORAGE_MAP.MAP_ALL()
をコールしてマッピング情報をリフレッシュできます。
DBMS_STORAGE_MAP
パッケージを使用すると、マッピング操作を制御できます。次の表に、使用可能な各種プロシージャを示します。
関連項目:
|
DBMS_STORAGE_MAP
パッケージにより生成されたマッピング情報は、動的パフォーマンス・ビューで取得されます。次の表に、これらのビューの概要を示します。
ただし、DBMS_STORAGE_MAP.MAP_OBJECT
プロシージャにより生成された情報は、グローバルな一時表MAP_OBJECT
に取得されます。この表には、オブジェクトの記憶域コンテナの階層配置が表示されます。表の各行は1つの階層レベルを表します。MAP_OBJECT
表の内容は、次のとおりです。
次の例では、Oracle Databaseのファイル・マッピング機能の強力な機能について説明します。次のような機能があります。
次の2つのデータファイルで構成されるOracle Databaseインスタンスを考えてみます。
この2つのファイルは、VERITAS VxVMホスト・ベースのストライプ化ボリューム/dev/vx/dsk/ipfdg/ipf-vol1
にマウントされたSolaris UFSファイル・システム上で作成されており、このボリュームはEMC Symmetrix配列から外部化された次のホスト・デバイスで構成されているとします。
次の例では、MAP_ALL()
操作を実行する必要があることに注意してください。
次の問合せでは、/dev/vx/rdmp/c2t1d1s2
ホスト・デバイスに関連付けられたすべてのOracle Databaseファイルが戻されます。
SELECT UNIQUE me.ELEM_NAME, mf.FILE_NAME FROM V$MAP_FILE_IO_STACK fs, V$MAP_FILE mf, V$MAP_ELEMENT me WHERE mf.FILE_MAP_IDX = fs.FILE_MAP_IDX AND me.ELEM_IDX = fs.ELEM_IDX AND me.ELEM_NAME = '/dev/vx/rdmp/c2t1d1s2';
問合せ結果は次のとおりです。
ELEM_NAME FILE_NAME ------------------------ -------------------------------- /dev/vx/rdmp/c2t1d1s2 /oracle/dbs/t_db1.f /dev/vx/rdmp/c2t1d1s2 /oracle/dbs/t_db2.f
次の問合せでは、/oracle/dbs/t_db1.f
データファイルのトポロジ・グラフが表示されます。
WITH fv AS (SELECT FILE_MAP_IDX, FILE_NAME FROM V$MAP_FILE WHERE FILE_NAME = '/oracle/dbs/t_db1.f') SELECT fv.FILE_NAME, LPAD(' ', 4 * (LEVEL - 1)) || el.ELEM_NAME ELEM_NAME FROM V$MAP_SUBELEMENT sb, V$MAP_ELEMENT el, fv, (SELECT UNIQUE ELEM_IDX FROM V$MAP_FILE_IO_STACK io, fv WHERE io.FILE_MAP_IDX = fv.FILE_MAP_IDX) fs WHERE el.ELEM_IDX = sb.CHILD_IDX AND fs.ELEM_IDX = el.ELEM_IDX START WITH sb.PARENT_IDX IN (SELECT DISTINCT ELEM_IDX FROM V$MAP_FILE_EXTENT fe, fv WHERE fv.FILE_MAP_IDX = fe.FILE_MAP_IDX) CONNECT BY PRIOR sb.CHILD_IDX = sb.PARENT_IDX;
表示されるトポロジ・グラフは次のとおりです。
FILE_NAME ELEM_NAME ----------------------- ------------------------------------------------- /oracle/dbs/t_db1.f _sym_plex_/dev/vx/rdsk/ipfdg/ipf-vol1_-1_-1 /oracle/dbs/t_db1.f _sym_subdisk_/dev/vx/rdsk/ipfdg/ipf-vol1_0_0_0 /oracle/dbs/t_db1.f /dev/vx/rdmp/c2t1d0s2 /oracle/dbs/t_db1.f _sym_symdev_000183600407_00C /oracle/dbs/t_db1.f _sym_hyper_000183600407_00C_0 /oracle/dbs/t_db1.f _sym_hyper_000183600407_00C_1 /oracle/dbs/t_db1.f _sym_subdisk_/dev/vx/rdsk/ipfdg/ipf-vol1_0_1_0 /oracle/dbs/t_db1.f /dev/vx/rdmp/c2t1d1s2 /oracle/dbs/t_db1.f _sym_symdev_000183600407_00D /oracle/dbs/t_db1.f _sym_hyper_000183600407_00D_0 /oracle/dbs/t_db1.f _sym_hyper_000183600407_00D_1
この例では、scott.bonus
表についてI/Oスタックの全レベルにおけるブロックの分散を表示します。
次のように、最初にMAP_OBJECT()
操作を実行する必要があります。
EXECUTE DBMS_STORAGE_MAP.MAP_OBJECT('BONUS','SCOTT','TABLE');
問合せは次のとおりです。
SELECT io.OBJECT_NAME o_name, io.OBJECT_OWNER o_owner, io.OBJECT_TYPE o_type, mf.FILE_NAME, me.ELEM_NAME, io.DEPTH, (SUM(io.CU_SIZE * (io.NUM_CU - DECODE(io.PARITY_PERIOD, 0, 0, TRUNC(io.NUM_CU / io.PARITY_PERIOD)))) / 2) o_size FROM MAP_OBJECT io, V$MAP_ELEMENT me, V$MAP_FILE mf WHERE io.OBJECT_NAME = 'BONUS' AND io.OBJECT_OWNER = 'SCOTT' AND io.OBJECT_TYPE = 'TABLE' AND me.ELEM_IDX = io.ELEM_IDX AND mf.FILE_MAP_IDX = io.FILE_MAP_IDX GROUP BY io.ELEM_IDX, io.FILE_MAP_IDX, me.ELEM_NAME, mf.FILE_NAME, io.DEPTH, io.OBJECT_NAME, io.OBJECT_OWNER, io.OBJECT_TYPE ORDER BY io.DEPTH;
問合せの結果は次のとおりです。o_size
列がKB単位で表されていることに注意してください。
O_NAME O_OWNER O_TYPE FILE_NAME ELEM_NAME DEPTH O_SIZE
------ ------- ------ ------------------- ----------------------------- ------ ------
BONUS SCOTT TABLE /oracle/dbs/t_db1.f /dev/vx/dsk/ipfdg/ipf-vol1 0 20
BONUS SCOTT TABLE /oracle/dbs/t_db1.f _sym_plex_/dev/vx/rdsk/ipf 1 20
pdg/if-vol1_-1_-1
BONUS SCOTT TABLE /oracle/dbs/t_db1.f _sym_subdisk_/dev/vx/rdsk/ 2 12
ipfdg/ipf-vol1_0_1_0
BONUS SCOTT TABLE /oracle/dbs/t_db1.f _sym_subdisk_/dev/vx/rdsk/ipf 2 8
dg/ipf-vol1_0_2_0
BONUS SCOTT TABLE /oracle/dbs/t_db1.f /dev/vx/rdmp/c2t1d1s2 3 12
BONUS SCOTT TABLE /oracle/dbs/t_db1.f /dev/vx/rdmp/c2t1d2s2 3 8
BONUS SCOTT TABLE /oracle/dbs/t_db1.f _sym_symdev_000183600407_00D 4 12
BONUS SCOTT TABLE /oracle/dbs/t_db1.f _sym_symdev_000183600407_00E 4 8
BONUS SCOTT TABLE /oracle/dbs/t_db1.f _sym_hyper_000183600407_00D_0 5 12
BONUS SCOTT TABLE /oracle/dbs/t_db1.f _sym_hyper_000183600407_00D_1 5 12
BONUS SCOTT TABLE /oracle/dbs/t_db1.f _sym_hyper_000183600407_00E_0 6 8
BONUS SCOTT TABLE /oracle/dbs/t_db1.f _sym_hyper_000183600407_00E_1 6 8
次のデータ・ディクショナリ・ビューは、データベースのデータファイルに関して役立つ情報を提供します。
ここでは、これらのビューの1つであるV$DATAFILE
の使用例を示します。
SELECT NAME, FILE#, STATUS, CHECKPOINT_CHANGE# "CHECKPOINT" FROM V$DATAFILE; NAME FILE# STATUS CHECKPOINT -------------------------------- ----- ------- ---------- /u01/oracle/rbdb1/system01.dbf 1 SYSTEM 3839 /u02/oracle/rbdb1/temp01.dbf 2 ONLINE 3782 /u02/oracle/rbdb1/users03.dbf 3 OFFLINE 3782
FILE#
は各データファイルのファイル番号を示します。データベースとともに作成されるSYSTEM
表領域内の最初のデータファイルは、常にファイル1になります。STATUS
は、データファイルに関する他の情報を示します。データファイルがSYSTEM
表領域の一部である場合、このファイルのSTATUS
はSYSTEM
になります(ただし、ファイルがリカバリを必要とする場合を除きます)。SYSTEM
表領域以外の表領域内のデータファイルがオンラインの場合、このファイルのSTATUS
はONLINE
になります。SYSTEM
表領域以外の表領域内のデータファイルがオフラインの場合、このファイルのSTATUS
はOFFLINE
またはRECOVER
になります。CHECKPOINT
は、データファイルの最新のチェックポイントに対して書き込まれた最後のSCN(システム変更番号)を示します。