11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
この章では、フィジカル・スタンバイ・データベースを作成する手順について説明します。この章は、次の主な項目で構成されています。
この章で説明する手順では、スタンバイ・データベースが最大パフォーマンス・モードで構成されます。このモードは、デフォルトのデータ保護モードです。別のデータ保護モードの構成については、第5章を参照してください。
|
関連項目
|
スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを確認する必要があります。
表3-1は、フィジカル・スタンバイ・データベースを作成するための準備としてプライマリ・データベースで実行するタスクのチェックリストです。各タスクを詳細に説明している参照先の項も記載されています。
| 参照先 | タスク |
|---|---|
データベースの作成後、次のSQL文を使用して、プライマリ・データベースをFORCE LOGGINGモードにします。
SQL> ALTER DATABASE FORCE LOGGING;
この文は、完了までに非常に時間がかかる場合があります。これは、ログに記録されないダイレクト書込みI/Oがすべて完了するまで待機するためです。
Data Guardでは、Oracle Netセッションを使用してData Guard構成のメンバー間でREDOデータを転送し、メッセージを制御します。これらのREDO転送セッションは、Secure Sockets Layer（SSL）プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。
SSLは、次の場合に2つのデータベース間のREDO転送セッションの認証に使用されます。
LOG_ARCHIVE_DEST_n、FAL_SERVERおよびFAL_CLIENTの各データベース初期化パラメータで、SSL用に構成されたOracle Net接続記述子を使用する場合
SSL認証の要件が満たされない場合は、リモート・ログイン・パスワード・ファイルを使用するようにData Guard構成の各メンバーを構成する必要があります。また、構成内のすべてのフィジカル・スタンバイ・データベースには、プライマリ・データベースのパスワード・ファイルの最新コピーが必要です。
SYSDBA権限またはSYSOPER権限を付与または取り消すか、これらの権限を持つユーザーのログイン・パスワードを変更するたびに、構成内の各フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースで、パスワード・ファイルをプライマリ・データベースのパスワード・ファイルの最新コピーで置き換える必要があります。
このタスクはオプションですが、Data Guard構成の作成時に、REDOデータを受信するようにプライマリ・データベースを構成することをお薦めします。このベスト・プラクティスに従うことで、プライマリ・データベースは、スタンバイ・ロールに速やかに推移してREDOデータの受信を開始できるようになります。
REDOデータを受信するようにデータベースを構成する方法の詳細は、6.2.3項を参照してください。
プライマリ・データベースでは、データベースがプライマリ・ロールで動作している間のREDO転送サービスを制御する初期化パラメータを定義します。また、プライマリ・データベースがスタンバイ・ロールに推移したときにREDOデータの受信と適用サービスを制御するパラメータを追加する必要があります。
例3-1に、プライマリ・データベースでメンテナンスする、プライマリ・ロールの初期化パラメータを示します。この例は、シカゴにプライマリ・データベースがあり、ボストンにフィジカル・スタンバイ・データベースが1つあるData Guard構成を示しています。例3-1に示すパラメータは、シカゴのデータベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで稼働している場合に有効です。この構成例では、次の表に示す名前を使用しています。
| データベース | DB_UNIQUE_NAME | Oracle Netサービス名 |
|---|---|---|
|
プライマリ |
chicago |
chicago |
|
フィジカル・スタンバイ |
boston |
boston |
DB_NAME=chicago DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_2= 'SERVICE=boston ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE LOG_ARCHIVE_FORMAT=%t_%s_%r.arc LOG_ARCHIVE_MAX_PROCESSES=30
これらのパラメータは、REDO転送サービスがREDOデータをスタンバイ・システムに転送する方法と、ローカル・ファイル・システムでのREDOデータのアーカイブ処理を制御します。例では、LOG_ARCHIVE_DEST_2初期化パラメータにREDOデータを転送する非同期（ASYNC）ネットワーク転送を指定します。これらは推奨設定であり、スタンバイREDOログ・ファイルが必要です（3.1.3項「REDOデータを受信するためのプライマリ・データベースの構成」を参照）。
例3-2に、プライマリ・データベースで定義するスタンバイ・ロールの追加の初期化パラメータを示します。これらのパラメータは、プライマリ・データベースがスタンバイ・ロールに推移すると有効になります。
FAL_SERVER=boston FAL_CLIENT=chicago DB_FILE_NAME_CONVERT='boston','chicago' LOG_FILE_NAME_CONVERT= '/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/' STANDBY_FILE_MANAGEMENT=AUTO
例3-2に示す初期化パラメータを指定すると、プライマリ・データベースはギャップを解決して新しいプライマリ・データベースからの新規データファイルとログ・ファイルのパス名を変換するように設定され、このデータベースがスタンバイ・ロールで動作しているときの着信REDOデータがアーカイブされます。説明に従ってプライマリおよびスタンバイ・ロールについて初期化パラメータを設定した場合、ロールの推移後に変更が必要なパラメータはありません。
次の表に、例3-1および例3-2に示した各パラメータ設定に関する簡単な説明を示します。
| パラメータ | 推奨する設定 |
|---|---|
|
|
8文字の名前を指定します。すべてのスタンバイ・データベースに同じ名前を使用してください。 |
|
|
各データベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。 |
|
|
このパラメータの |
|
|
プライマリ・データベースの制御ファイルのパス名を指定します。例3-1は、2つの制御ファイルのパス名を指定する方法を示しています。不良制御ファイルの位置に正常な制御ファイルをコピーした後でインスタンスを簡単に再起動できるように、制御ファイルの第2コピーを使用可能にしておくことをお薦めします。 |
|
|
REDOデータがアーカイブされるプライマリ・システムおよびスタンバイ・システムの位置を指定します。例3-1では、次のようになっています。
注意: フラッシュ・リカバリ領域を（ |
|
|
REDO転送サービスがREDOデータを指定した宛先に転送するのを許可するには、 |
|
|
リモート・ログイン・パスワード・ファイルを使用して管理ユーザーまたはREDO転送セッションを認証する場合は、このパラメータを |
|
|
スレッド（%t）、順序番号（%s）およびリセットログID（%r）を使用して、アーカイブREDOログ・ファイルのフォーマットを指定します。 |
|
|
Oracleソフトウェアが最初に起動するアーカイバ（ |
|
|
FALサーバー（通常はプライマリ・ロールで実行中のデータベース）のOracle Netサービス名を指定します。シカゴのデータベースがスタンバイ・ロールで実行されている場合、ボストンのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、ボストンのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ（要求）されます。 |
|
|
シカゴのデータベースのOracle Netサービス名を指定します。FALサーバー（ボストン）は、欠落しているアーカイブREDOログ・ファイルをシカゴのスタンバイ・データベースにコピーします。 |
|
|
プライマリ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはデータファイルが格納されているスタンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は、このパラメータが必要です。このパラメータは、フィジカル・スタンバイ・データベースのパス名の変換にのみ使用されることに注意してください。このパラメータにより、複数のペアのパスを指定できます。 |
|
|
プライマリ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはログ・ファイルが格納されているスタンバイ・システムのディレクトリ構造がプライマリ・システムと異なる場合は、このパラメータが必要です。このパラメータにより、複数のペアのパスを指定できます。 |
|
|
データファイルがプライマリ・データベースに追加または削除された場合に、それに対応してスタンバイ・データベースも自動的に変更されるように、 |
アーカイブが有効になっていない場合は、次の文を発行して、プライマリ・データベースをARCHIVELOGモードにし、自動アーカイブを有効にします。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE OPEN;
アーカイブの詳細は、『Oracle Database管理者ガイド』を参照してください。
この項では、フィジカル・スタンバイ・データベースの作成で実行するタスクについて説明します。
表3-2は、フィジカル・スタンバイ・データベースの作成で実行するタスク、および各タスクを実行するデータベースのチェックリストです。各タスクを詳細に説明している参照先の項も記載されています。
| 参照先 | タスク | データベース |
|---|---|---|
|
プライマリ |
||
|
プライマリ |
||
|
プライマリ |
||
|
プライマリ |
||
|
スタンバイ |
||
|
スタンバイ |
||
|
スタンバイ |
データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルがあるかぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタンバイ・データベースを作成できます。Recovery Manager（RMAN）ユーティリティを使用することをお薦めします。
バックアップの推奨事項は『Oracle高可用性アーキテクチャおよびベスト・プラクティス』を、データベースのバックアップ操作の実行方法は『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
バックアップ処理のために、プライマリ・データベースを停止する必要がある場合は、次のSQL*Plus文を発行して、プライマリ・データベースを起動します。
SQL> STARTUP MOUNT;
スタンバイ・データベース用の制御ファイルを作成してから、ユーザー・アクセス用にプライマリ・データベースをオープンします。次に例を示します。
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl'; SQL> ALTER DATABASE OPEN;
次の手順を実行して、スタンバイの初期化パラメータ・ファイルを作成します。
プライマリ・データベースで使用されているサーバー・パラメータ・ファイル（SPFILE）から、テキストの初期化パラメータ・ファイル（PFILE）を作成します。テキストの初期化パラメータ・ファイルは、スタンバイの位置にコピーして変更できます。次に例を示します。
SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;
このファイルを変更して、フィジカル・スタンバイ・データベースでの使用に適したパラメータ値を含めます。このファイルは、後述の3.2.5項で、サーバー・パラメータ・ファイルに変換しなおします。
プライマリ・システムからコピーしたテキストの初期化パラメータ・ファイルの初期化パラメータ設定の多くは、フィジカル・スタンバイ・データベースにも適していますが、一部を変更する必要があります。
例3-3は、スタンバイの初期化パラメータ・ファイルの一部です。この中の値は、フィジカル・スタンバイ・データベース用に変更されています。例3-1および例3-2と異なるパラメータ値は、太字で示されています。例3-3に示すパラメータは、ボストンのデータベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで稼働している場合に有効です。
. . . DB_NAME=chicago DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl' DB_FILE_NAME_CONVERT='chicago','boston' LOG_FILE_NAME_CONVERT= '/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE STANDBY_FILE_MANAGEMENT=AUTO FAL_SERVER=chicago FAL_CLIENT=boston . . .
プライマリ・データベースとスタンバイ・データベースでは、COMPATIBLE初期化パラメータを同じ値に設定する必要があります。値が異なる場合は、REDO転送サービスがREDOデータをプライマリ・データベースからスタンバイ・データベースに転送できない可能性があります。Data Guard構成では、COMPATIBLEを少なくとも9.2.0.1.0に設定する必要があります。ただし、Oracle Database 11gの新機能を利用する場合は、COMPATIBLEパラメータを11.0.0に設定します。
SHOW PARAMETERSコマンドを使用して、他に変更を必要とするパラメータがないかどうかを確認することをお薦めします。
次の表に、例3-3に示したパラメータ設定のうち、プライマリ・データベースとは異なる設定に関する簡単な説明を示します。
| パラメータ | 推奨する設定 |
|---|---|
|
|
このデータベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。 |
|
|
スタンバイ・データベースの制御ファイルのパス名を指定します。例3-3は、2つの制御ファイルのパス名を指定する方法を示しています。不良制御ファイルの位置に正常な制御ファイルをコピーした後でインスタンスを簡単に再起動できるように、制御ファイルの第2コピーを使用可能にしておくことをお薦めします。 |
|
|
プライマリ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはデータファイルが格納されているスタンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は、このパラメータが必要です。 |
|
|
プライマリ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはログ・ファイルが格納されているスタンバイ・システムのディレクトリ構造がプライマリ・システムと異なる場合は、このパラメータが必要です。 |
|
|
REDOデータのアーカイブ先を指定します。例3-3では、次のようになっています。
注意: フラッシュ・リカバリ領域を（ |
|
|
FALサーバー（通常はプライマリ・ロールで実行中のデータベース）のOracle Netサービス名を指定します。ボストンのデータベースがスタンバイ・ロールで実行されている場合、シカゴのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、シカゴのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ（要求）されます。 |
|
|
ボストンのデータベースのOracle Netサービス名を指定します。FALサーバー（シカゴ）は、欠落しているアーカイブREDOログ・ファイルをボストンのスタンバイ・データベースにコピーします。 |
オペレーティング・システムのコピー・ユーティリティを使用して、次のバイナリ・ファイルをプライマリ・システムからスタンバイ・システムにコピーします。
次の手順を実行して、Windowsベース・サービスの作成、パスワード・ファイルの作成、Oracle Net環境の設定およびSPFILEの作成を行います。
スタンバイ・データベースのホストがWindowsシステムである場合、ORADIMユーティリティを使用してWindowsサービスを作成します。次に例を示します。
WINNT> oradim -NEW -SID boston -STARTMODE manual
ORADIMユーティリティの使用方法の詳細は、『Oracle Databaseプラットフォーム・ガイド for Microsoft Windows』を参照してください。
プライマリ・データベースにリモート・ログイン・パスワード・ファイルがある場合は、そのファイルをフィジカル・スタンバイ・データベース・システムの適切なディレクトリにコピーします。パスワード・ファイルは、SYSDBA権限またはSYSOPER権限が付与または取り消されるか、これらの権限を持つユーザーのログイン・パスワードが変更されるたびに再コピーする必要があります。
この手順は、オペレーティング・システムの認証を管理ユーザーに使用する場合およびSSLをREDO転送の認証に使用する場合はオプションです。
プライマリ・サイトとスタンバイ・サイトの両方で、Oracle Net Managerを使用して、各データベースに対するリスナーを構成します。
リスナーを再起動して新しい定義を読み込むには、プライマリ・システムとスタンバイ・システムの両方で次のLSNRCTLユーティリティ・コマンドを入力します。
% lsnrctl stop % lsnrctl start
『Oracle Database Net Services管理者ガイド』を参照してください。
プライマリ・システムとスタンバイ・システムの両方で、Oracle Net Managerを使用して、プライマリ・データベースとスタンバイ・データベースのネットワーク・サービス名を作成します。ネットワーク・サービス名はREDO転送サービスで使用されます。
Oracle Netネット・サービス名は、プライマリ・データベースとスタンバイ・データベースに対するリスナーの構成時に指定したものと同じプロトコル、ホスト・アドレス、ポートおよびサービスを使用する接続記述子に解析される必要があります。この接続記述子は、専用サーバーが使用されるように指定する必要もあります。
『Oracle Database Net Services管理者ガイド』および『Oracle Database管理者ガイド』を参照してください。
アイドル状態のスタンバイ・データベースで、SQL CREATE文を使用して、手順2で編集したテキストの初期化パラメータ・ファイルから、スタンバイ・データベース用のサーバー・パラメータ・ファイルを作成します。次に例を示します。
SQL> CREATE SPFILE FROM PFILE='initboston.ora';
プライマリ・データベースにデータベース暗号化ウォレットがある場合は、スタンバイ・データベース・システムにコピーし、そのウォレットを使用するようにスタンバイ・データベースを構成します。
フィジカル・スタンバイ・データベースおよびREDO Applyを起動するには、次の手順を実行します。
スタンバイ・データベースで、次のSQL文を発行してデータベースを起動およびマウントします。
SQL> STARTUP MOUNT;
REDOデータをプライマリ・データベースから受信してアーカイブするように、6.2.3項で説明する手順を実行して、スタンバイ・データベースを準備します。
この手順はオプションですが、スタンバイ・データベースの作成時に、オンラインREDOログを作成することをお薦めします。このベスト・プラクティスに従うことで、スタンバイ・データベースは、プライマリ・データベース・ロールに速やかに推移できるようになります。
スタンバイ・データベースのオンラインREDOログにおけるREDOログ・グループのサイズおよび数は、スタンバイ・データベースがプライマリ・ロールに推移した場合に十分に機能するように選択する必要があります。
スタンバイ・データベースで、次のコマンドを発行してREDO Applyを開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
この文にはDISCONNECT FROM SESSIONオプションが指定されているため、REDO Applyはバックグラウンド・セッションで実行されます。詳細は、7.3項「REDOデータのフィジカル・スタンバイ・データベースへの適用」を参照してください。
また、この文にはUSING CURRENT LOGFILE句が指定されているため、REDOを受信後すぐに適用できます。詳細は、7.3.1項「REDO Applyの開始」を参照してください。
フィジカル・スタンバイ・データベースを作成してREDO転送サービスを設定した後、データベースの変更がプライマリ・データベースからスタンバイ・データベースに正常に転送されているかどうかの確認が必要な場合があります。
スタンバイ・データベースでREDOデータが受信されていることを確認するには、最初に、スタンバイ・データベースの既存のアーカイブREDOログ・ファイルを識別し、ログ・スイッチを強制実行して、プライマリ・データベースのオンラインREDOログ・ファイルをいくつかアーカイブし、スタンバイ・データベースを再度チェックする必要があります。このタスクの実行手順を次に示します。
スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、アーカイブREDOログの既存のファイルを識別します。次に例を示します。
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME 2 FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# FIRST_TIME NEXT_TIME ---------- ------------------ ------------------ 8 11-JUL-07 17:50:45 11-JUL-07 17:50:53 9 11-JUL-07 17:50:53 11-JUL-07 17:50:58 10 11-JUL-07 17:50:58 11-JUL-07 17:51:03 3 rows selected.
プライマリ・データベースで、ALTER SYSTEM SWITCH LOGFILE文を発行して、ログ・スイッチを強制実行し、現行のオンラインREDOログ・ファイル・グループをアーカイブします。
SQL> ALTER SYSTEM SWITCH LOGFILE;
スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、スタンバイ・データベースでREDOデータが受信およびアーカイブされたことを確認します。
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME 2> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# FIRST_TIME NEXT_TIME ---------- ------------------ ------------------ 8 11-JUL-07 17:50:45 11-JUL-07 17:50:53 9 11-JUL-07 17:50:53 11-JUL-07 17:50:58 10 11-JUL-07 17:50:58 11-JUL-07 17:51:03 11 11-JUL-07 17:51:03 11-JUL-07 18:34:11 4 rows selected.
アーカイブREDOログ・ファイルは、フィジカル・スタンバイ・データベースに適用できます。
スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、受信したREDOが適用されたことを確認します。
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG 2 ORDER BY SEQUENCE#; SEQUENCE# APP --------- --- 8 YES 9 YES 10 YES 11 IN-MEMORY
4 rows selected.
この時点で、フィジカル・スタンバイ・データベースが実行中であり、最大パフォーマンス・レベルのデータ保護を提供できます。次のリストに、フィジカル・スタンバイ・データベースに対して実行できるその他の準備について説明します。
Data Guard構成は、最初は最大パフォーマンス・モード（デフォルト）で設定されます。
フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたりREDOデータを広範囲に適用する必要がないため、従来のPoint-in-Timeリカバリよりもはるかに高速でデータベースを過去の最新時点の状態に戻すことができます。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。Data Guard環境でのフラッシュバック・データベースの使用例は、13.2項および13.3項を参照してください。また、フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|