0

テーブル構造の変更を含むさまざまなスクリプトの実行中に、ユーザーが Oracle 12c データベースに新しいデータを追加できないようにするために、アプリケーション サーバーの最大 4 時間のダウンタイムを必要とするリリースがあります。

次のようなシナリオでデータ ガードを使用できますか。

  1. ステージング領域で現在の本番スキーマを複製します
  2. ユーザーは本番環境で作業を続けます
  3. テーブル構造の変更を含め、ステージング DB でさまざまなスクリプトを実行します。
  4. ある時点で、データ ガードを使用して、本番環境で変更されたすべてのデータをステージング環境に「プッシュ」します。
  5. この時点で、ステージング環境は本番環境になります

これは、スケジュールされたリリースにのみ使用されます

4

1 に答える 1

0

これには、Data Guard Logical Standby を使用できる場合があります。

警告する

ロジカル Data Guard スタンバイのセットアップは、通常のフィジカル スタンバイよりもはるかに複雑です。特に、プライマリとスタンバイを分離して行う変更の種類について話す場合はなおさらです。このため、ロジカル・スタンバイの管理に取りかかる前に、少なくともフィジカル・スタンバイの管理に慣れることができます。

1) Data Guard フィジカル スタンバイを作成します。

2) フィジカル スタンバイをロジカル スタンバイに変換します。

--STANDBY 
alter database recover managed standby database cancel;

--PRIMARY
execute dbms_logstdby.build;

--STANDBY
alter database recover to logical standby keep identity;
alter database open;
alter database start logical standby apply immediate;

3) スキーマ全体で DDL のみをスキップします。

--STANDBY
EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'SCHEMA DDL', -
     schema_name => 'HR', -
     table_name => '%', -
     proc_name => null);

特定のオブジェクトの DDL または DML をスキップすることもできますが、あなたの場合はスキーマ レベルの方が適切であると思います。DBMS_LOGSTDBY は非常に堅牢で、 docsから読むことができます。

4) プライマリに影響を与えずにスタンバイのみに変更をプッシュする必要がある場合は、そのセッションのガード モードを無効にすることができます。

--STANDBY
alter session disable guard;
--Make your changes
alter session enable guard;

5) ライブに移行する準備ができたら、Data Guard スイッチオーバーを実行します。これについては、ドキュメントから参照できます。このドキュメントは、Data Guard 環境を管理する際に強く推奨される Data Guard ブローカーの使用に固有のものです。

于 2017-01-18T14:41:16.287 に答える