Oracle Databaseファイル・システムについて
DBFSは、ローカル・ファイル・システムのような共有ネットワーク・ファイル・システムを提供し、サーバー・コンポーネントとクライアント・コンポーネントの両方を持つ点でNFSに似ています。DBFSファイル・システムは、中間層ホストからマウントし、通常の共有ファイル・システムとしてアクセスできます。
DBFSは、DBFSマウントに必要な構成およびメンテナンスのために、若干の複雑さをもたらします。DBクライアントをマウントするホストにインストールし、データベース(表領域、ユーザーなど)およびクライアント(ウォレット、tnsnames.oraなど)で一部のアーティファクトの初期設定を実行する必要があります。DBFSマウントにコピーされたコンテンツはデータベースに格納されるため、データベースに追加の容量が必要です。
ドメイン構成またはバイナリを直接DBFSマウントに格納しないでください。これにより、Oracle Fusion Middlewareファイルとデータベースの間に非常に強い依存関係が作成されます。ただし、DBFS機能には役立つ可能性のある一部のアーティファクトおよび操作があります。
runtimeフォルダへのDBFSの使用について
このアプローチを実装するには、すべての中間層ホスト(プライマリおよびセカンダリ)にDBクライアントをインストールします。データベース(DBFS表領域、ユーザーなど)およびクライアント(ウォレット、tnsnames.oraなど)の一部のアーティファクトの初期設定を実行する必要があります。
中間層ホストでDBFSマウントを構成するスクリプトの例として、スクリプトdbfs_dr_setup_root.shを参照してください。このスクリプトは、データベース・クライアントをインストールし、データベースにDBFSスキーマを作成し、クライアント・アーティファクトを構成し、中間層ホストにDBFSファイル・システムをマウントします。
スクリプトをダウンロードするには、リンクの「コードのダウンロード」に移動します。
このスクリプトを使用する際は、次の点にご注意ください。
- スクリプトを実行する前に、ホストで「yum」ユーティリティが正しく構成されている必要があります。スクリプトはyumを使用して、DBクライアントのインストールに必要なパッケージをダウンロードします。
- スクリプトの「CUSTOMIZABLE VARIABLES」セクションに環境値(ユーザー名、パスなど)を指定する必要があります。
- 変数DBFS_CONFIG_DIRは、DBFS構成アーティファクトの場所(ウォレット、
tnsnames.oraおよびDBFSをマウントするスクリプト)をカスタマイズするために使用されます。サイト間でレプリケートされない場所を使用するため、各サイトには独自の構成があります。ドメインがレプリケートされるときにセカンダリにレプリケートされるため、ドメイン・フォルダの下に配置しないでください。 - スクリプトは、プライマリ中間層ホスト(プライマリ・データベースを指し示す)およびセカンダリ中間層ホスト(セカンダリ・データベースを指す)で実行する必要があります。一部のもの(dbユーザー、表領域など)がすでに作成されているため、警告が表示されますが、これらのメッセージは無視できます。
- セカンダリ中間層ホストで構成を実行するには、スタンバイ・データベースをスナップショット・スタンバイ・モードでオープンする必要があります。これは、DBFSは、データベースがオープンされている場合にのみマウントできるためです。Oracle Data GuardがActive Data Guardではない場合、スタンバイ・データベースはマウント状態です。このような場合にスタンバイ・サイトのDBFSマウントにアクセスするには、データベースをスナップショット・スタンバイに変換する必要があります。
DBFSマウントがすべての中間層ホストで構成されたら、ランタイム・データの共有フォルダとして使用できます(ファイル・アダプタまたはカスタム・アプリケーションによって読取り/書込みされるファイルなど)。このコンテンツをセカンダリ・サイトに手動でレプリケートする必要はありません。Oracle Data Guardで自動的にレプリケートされます。スイッチオーバーまたはフェイルオーバーが発生した場合、ランタイム・コンテンツは、データベースに格納されている残りの情報とともに新しいプライマリで使用できます。
ランタイム・データにDBFSマウントを使用する利点:
- サイト間のレプリケーションは暗黙的です。プライマリ・サイトのDBFSマウントに格納されているコンテンツは、Oracle Data Guardを介してセカンダリ・サイトにレプリケートされます。
短所:
- DBFSのパフォーマンスは、NFSソリューション(Oracle Cloud Infrastructure File Storage、Oracle ZFS)よりも劣ります。
- Oracleでは、スイッチオーバー後に
DBFSを新しいプライマリに再マウントして、DBFSマウントが正常であることを確認することをお薦めします。DBFSマウントが古くなり、指定するデータベースがしばらくの間(データベースがスタンバイ・モードの間など)オープンされていなかった場合、再マウントが必要になることがあります。
DBFSを使用したOracle WebLogic Server構成のレプリケートについて
この方法では、Oracle Data Guardレプリカの堅牢性を活用できます。Oracleドライバの再試行ロジックにより可用性が高く、回復可能な動作を提供します。これは、データ・センター間のレイテンシが中または高であるシナリオで使用できます。ただし、構成レプリケーションにDBFSを使用すると、設定、データベース・ストレージおよびライフサイクルの観点から、さらなる影響があります:
- DBFSマウントに必要な構成およびメンテナンスのために、若干の複雑さが生じます。DBクライアントは、マウントするホストにインストールする必要があり、データベース(表領域、ユーザーなど)およびクライアント(ウォレット、
tnsnames.oraなど)にいくつかのアーティファクトの初期設定が必要です。スクリプトdbfs_dr_setup_root.shを参照してください。このスクリプトは、データベースクライアントのインストール、データベースへのDBFSスキーマの作成、クライアントアーティファクトの構成、中間層ホストへのDBFSファイルシステムのマウントを行うスクリプトの例です。 - DBFSマウントにコピーされたコンテンツはデータベースに格納されるため、データベースに追加の容量が必要です。
- ドメイン構成またはバイナリを直接DBFSマウントに格納しないでください。これにより、Oracle Fusion Middlewareファイルとデータベースの間に非常に強い依存関係が作成されます。かわりに、DBFSをアシスタント・ファイル・システムとして使用することをお薦めします: これは、スタンバイ・サイトにレプリケートされる情報を配置するための中間ステージング・ファイル・システムです。スタンバイへのレプリケーションには2つのステップがあります: プライマリのオリジン・フォルダから中間のDBFSマウントへ、そしてスタンバイ・サイトではDBFSマウントからスタンバイの宛先フォルダへ、となります。
- DBFSは、データベースがオープンされている場合にのみマウントできます。Oracle Data GuardがActive Data Guardではない場合、スタンバイ・データベースはマウント状態です。したがって、このような場合にスタンバイ・サイトでDBFSマウントにアクセスするには、データベースをスナップショット・スタンバイに変換する必要があります。Active Data Guardを使用する場合、読取り用にファイル・システムをマウントできるため、スナップショットに遷移する必要はありません。
このような理由から、DBFSは、すべてのファイル・システム・アーティファクトをスタンバイにレプリケートする汎用的なソリューションとしてはお薦めしません。たとえば、バイナリをDBFSでレプリケートすることは過剰です。
ただし、この方法は、ストレージ・レプリケーションやrsyncなどの他の方法が実行できない場合に、ドメイン共有構成(ASERVER_HOME)など、ライフサイクル中にいくつかの動的アーティファクトをレプリケートする際には適しています。ドメイン構成をレプリケートするためにDBFSをアシスタンス・ファイル・システムとして使用する方法の例は、『Oracle WebLogic Server for Oracle Cloud Infrastructureの障害時リカバリ』のペーパーを参照してください。
スクリプトをダウンロードするには、リンクの「コードのダウンロード」に移動します。