web-dev-qa-db-ja.com

11.2.0.4を使用して、フェイルオーバー後にOracleデータベースを複製中にエラーが発生しました

最近、Oracleをバージョン11.2.0.1から11.2.0.4に更新しましたが、冗長システムがフェイルオーバーから回復できなくなりました。

プライマリノードとスタンバイノードの両方でスクリプトを使用して、冗長システムとして再度インストールできる状態に戻しています。

フェイルオーバーの実行後を除いて、すべての状態でリセットスクリプトを繰り返し実行することができます。唯一の変更点は、11.2.0.4.へのアップグレードです。これは11.2.0.1の魅力のように機能しました。

Data GuardBrokerを使用して冗長性を維持しています。

セットアップ手順は複雑で、ここで説明するのは難しいので、誰かが同じエラーに直面したかどうかを尋ねているだけで、そのような状況から回復する方法があるかもしれません。

少なくとも、これは失敗した場合の出力です:(バックアップ手順は重複アクションの前に実行されます)

2014-11-14 17:08:55 : Recovery Manager: Release 11.2.0.4.0 - Production on Fri Nov 14 17:08:48 2014
2014-11-14 17:08:55 : Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
2014-11-14 17:08:55 : connected to target database: REF15 (DBID=276671931)
2014-11-14 17:08:55 : RMAN> CONNECT AUXILIARY *
2014-11-14 17:08:55 : 2> RUN {
2014-11-14 17:08:55 : 3> SET UNTIL sequence = 159 thread = 1;
2014-11-14 17:08:55 : 4> ALLOCATE AUXILIARY CHANNEL CH1 TYPE DISK;
2014-11-14 17:08:55 : 5> DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK DORECOVER;
2014-11-14 17:08:56 : 6> RELEASE CHANNEL CH1;
2014-11-14 17:08:56 : 7> }
2014-11-14 17:08:56 : 8> exit;
2014-11-14 17:08:56 : connected to auxiliary database: REF15 (not mounted)
2014-11-14 17:08:56 : executing command: SET until clause
2014-11-14 17:08:56 : using target database control file instead of recovery catalog
2014-11-14 17:08:56 : allocated channel: CH1
2014-11-14 17:08:56 : channel CH1: SID=25 device type=DISK
2014-11-14 17:08:56 : Starting Duplicate Db at 14-NOV-14
2014-11-14 17:08:56 : released channel: CH1
2014-11-14 17:08:56 : RMAN-00571: ===========================================================
2014-11-14 17:08:56 : RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
2014-11-14 17:08:56 : RMAN-00571: ===========================================================
2014-11-14 17:08:56 : RMAN-03002: failure of Duplicate Db command at 11/14/2014 17:08:51
2014-11-14 17:08:56 : RMAN-05501: aborting duplication of target database
2014-11-14 17:08:56 : RMAN-20206: log sequence not found in the repository
2014-11-14 17:08:56 : Recovery Manager complete.

更新:ログシーケンス番号(この場合:159)は、次のクエリから取得されます。

    v $ archived_logからmax(sequence#)を選択します。

ありがとう(元々はstd Stack Exchangeに投稿されました)

1
Magnus

このメッセージは、現在のインカネーションにこのシーケンスのアーカイブログが存在しないことを示しています。

フェイルオーバーは新しいインカネーションを開始し、ログシーケンスは再び1から始まります。データベースがシーケンス10にあり、フェイルオーバー前のログシーケンスが159だったとします。この時点でのV $ ARCHIVED_LOGには、以前のインカネーションに関するエントリがまだ含まれているため、上記のクエリは、新しいインカネーション(resetlogs)の開始を考慮しないため、159を返します。

これらの種類のクエリについては、常にresetlogs_change#またはresetlogs_timeを確認してください。例:

select max(sequence#) from v$archived_log join v$database using (resetlogs_change#);

これを修正して、複製を再試行してください。または、UNTIL句をスキップして、ログ配布でアーカイブログを処理します。

1
Balazs Papp