もう一度Oracleスタンバイについて

DBMSとしてOracleを使用するプロジェクトが予期せず（または期待を抱いて）ビジネスにとって非常に重要になった状況を想像してください（したがって、システムの信頼性を確保するために資金を割り当てる意思がありました）。
その瞬間まで、私たちは毎日または毎週のバックアップ（「ホット」または「コールド」コピー、または単にデータのエクスポート）で完全に管理し、その日のオーダーのシステム回復時間に満足していました（数テラバイトのデータがあると仮定します）。
そして、システムを復元する時間は1時間以内であり、データを失うことはありませんでした。
したがって、すべてが、スタンバイサーバーを上げる必要があることを示しています。
原則として、この記事で説明する内容のほとんどは、Oracle Data Guard ConceptsおよびAdministartion 、 および Web上の多数の場所で説明されていますが、ほとんどの場合、これらは多くのことなく一連のコマンドを含む指示ですその意味の説明、そして最も重要なこととして、何かがうまくいかない場合の対処方法に関する推奨事項はありません。
フィジカルスタンバイデータベースを展開するプロセスを、これまでに遭遇したレーキの表示とともに可能な限り詳細に説明しようとします。
誤って見つけられなかった問題の説明、および説明と追加は、あらゆる点で歓迎されます。

将来、コマンドおよびクエリの例が本文で提供される場合、次の表記法を使用します。
$ -コマンドは、ユーザーoracleの下のオペレーティングシステムのコマンドラインに入力されます。
SQL> -コマンドはsqlplusに入力されます。 明示的に定義されていないこの記事では、sqlplusが管理モード（ sqlplus / as sysdba ）で起動され、データベースインスタンスが$ ORACLE_SID変数を介して設定されていると想定しています。
RMAN> -コマンドはrmanに入力されます。 ここでも、他に明示的に定義されていない限り、rmanはrman target /コマンドで起動され、データベースインスタンスは$ ORACLE_SID変数を介して設定されると想定されます。

始める前に、Oracle DBMSのバックアップおよびデータリカバリのメカニズムを理解する必要があるOracleデータベース組織の原則について少し説明する価値があります。

Oracleデータベースインスタンスには、次の種類のファイルが含まれています。
制御ファイル（制御ファイル）-データベース自体に関するサービス情報が含まれています。 これらがないと、データファイルを開くことができないため、データベース情報へのアクセスを開くことができません。
データファイル-データベース情報が含まれています。
操作ログ（Redoログ）-データベースで発生したすべての変更に関する情報が含まれます。 この情報は、障害が発生した場合にデータベースの状態を復元するために使用できます。

正式にはデータベースに含まれていない他のファイルがありますが、データベースを正常に操作するには重要です。
パラメータファイル-インスタンスの開始設定を記述するために使用されます。
パスワードファイル-ユーザーが管理タスクのためにデータベースにリモートで接続できるようにします。
アーカイブログ-インスタンス（オフラインコピー）によって作成されたオンラインジャーナルファイルの履歴が含まれます。 これらのファイルを使用すると、データベースを復元できます。 それらとデータベースリザーブを使用して、失われたデータファイルを回復できます。

スタンバイインスタンスを作成するときの主なアイデアは、メインデータベースの操作ログまたはアーカイブログに格納されているトランザクションを使用してバックアップデータベースを最新の状態に保つことです（OracleのメカニズムはData Guardと呼ばれます）。
ここからメインデータベースの最初の要件に従います-archivelogモードで起動する必要があります 。
2番目の要件はパスワードファイルです。 これにより、管理モードでデータベースにリモート接続できます。
3番目の要件は、 強制ログモードです。 このモードは、NOLOGGINGオプションを使用して実行された操作でも、強制的にトランザクションをREDOログに書き込むために必要です。 このモードがないと、一部のデータファイルがスタンバイデータベースで破損するという事実につながる可能性があります。 アーカイブログを「ローリング」すると、NOLOGGINGオプションで作成されたトランザクションに関するデータをそれらから取得することはできなくなります。
また、Oracleを11g以下で使用する場合、メインデータベースとスタンバイ用のサーバーは同じプラットフォームでなければならないことに注意してください。 つまり、メインデータベースがLinuxサーバーで実行されている場合、スタンバイサーバーでWindowsを実行することはできません。

この記事のすべての例では、UNIXシステムに焦点を当てますが、Windowsシステムの場合との違いは、主にファイルへのパスの書き込み方法のみです。
メインサーバーとスタンバイサーバー間のデータ交換はSQL-Netを介して行われることを忘れないでください。したがって、対応するポート（通常は1521 tcp）への接続を両方向で開く必要があります。

データベースがtestと呼ばれると仮定します。 メインデータベースとスタンバイデータベースの構成を調整して、いつでもロールを切り替えられるようにします（スイッチオーバー）。 システムでは、MAXIMUM PERFORMANCEと呼ばれるData Guard保護モードを使用する予定です。

行きましょう。
まず、データベースが必要な要件を満たしていることを確認します。

1.メインDBが機能するモードを確認します。

SQL> select name, open_mode, log_mode from v$database;

NAME OPEN_MODE LOG_MODE
--------- ---------- ------------
TEST READ WRITE ARCHIVELOG

LOG_MODEフィールドにARCHIVELOG値が表示されない場合は、次のコマンドを実行します。

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

2.パスワードファイルを確認します。

SQL> select * from v $ pwfile_users;

USERNAME SYSDB SYSOP
------------------------------ ----- -----
SYS TRUE TRUE

この結果が表示されない場合は、必要なファイルを作成します。

$ orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=xxxxxxxx force=y

「xxxxxxxx」の代わりに、SYSユーザーの現在のパスワードを挿入する必要があります。

3. 強制ログモードをオンにします。

SQL> alter database force logging;

システムの構成に進みます。 まず、メインベースで必要な設定を行います。 すべてのデータを/ data / backupディレクトリに保存します。

スタンバイREDOログを作成します。 これらは、メインデータベースのREDOログに保存されたデータを記録するためのスタンバイデータベースでのみ必要です。 メインベースでは、スタンバイモードに切り替えてリアルタイム適用REDOを使用するときにそれらが必要になります。 スタンバイREDOログファイルは、オンラインREDOログと同じサイズである必要があります。 次のコマンドを使用して、オンラインREDOログのサイズを表示できます。

SQL> select bytes from v$log;

BYTES
----------
52428800
52428800
52428800

データベースにあるREDOログのグループを確認します。

SQL> select group# from v$logfile;

GROUP#
----------
1
2
3

スタンバイREDOログを作成します。

SQL> alter database add standby logfile group 4 '/oradata/test/stnbylog01.log' size 50m;
Database altered.

SQL> alter database add standby logfile group 5 '/oradata/test/stnbylog02.log' size 50m;
Database altered.

SQL> alter database add standby logfile group 6 '/oradata/test/stnbylog03.log' size 50m;
Database altered.

インスタンスのパラメーターを含むファイル（pfile）を作成します。 メインベースをスタンバイモードに切り替えることができることを考慮します。これには、スタンバイモードでのみ使用されるパラメーターの設定が必要です。

SQL> create pfile='/data/backup/pfilePROD.ora' from spfile;

結果のファイルにいくつかのパラメーターを追加する必要があります（それらが存在しない場合）。

db_name = 'test'は、データベースの名前です（メインインスタンスとスタンバイインスタンスでも同じです）。
db_unique_name = 'testprod'-これは各インスタンスの一意の名前であり、ロールをスタンバイから実稼働に変更しても変更されません。
l og_archive_config = 'dg_config =（testprod、teststan）' -ログが交換されるインスタンスの名前を定義します。
log_archive_dest_1 = 'SERVICE = teststan LGWR ASYNC VALID_FOR =（ONLINE_LOGFILES、PRIMARY_ROLE）db_unique_name =' teststan ' -インスタンスがメインベース（PRIMARY_ROLE）の場合、LGWRプロセスを使用してアーカイブログをスタンバイサーバーに転送します。 ASYNCパラメーターは、トランザクションによって生成されたデータを、トランザクションが完了する前にスタンバイで受信する必要がないことを示します。これにより、スタンバイとの接続がない場合にメインデータベースが停止することはありません。
log_archive_dest_2 = 'LOCATION = / oradata / test / archive VALID_FOR =（ALL_LOGFILES、ALL_ROLES）db_unique_name = testprod'-ここでは、アーカイブされたログがローカルに保存されるディレクトリ（メインデータベース用）またはメインデータベースからのログの場所（スタンバイベース）。
l og_archive_dest_state_1 = ENABLE -log_archive_dest_1でアーカイブログの記録を有効にします。 スタンバイデータベースを作成するまで、alert_logでスタンバイデータベースの使用不可に関する不要なメッセージを表示したくない場合は、このパラメーターをDEFERに設定できます。
log_archive_dest_state_2 = ENABLE - log_archive_dest_2でアーカイブログの記録を有効にします。
fal_client = 'testprod'-このパラメーターは、インスタンスがスタンバイモードに入るときに、アーカイブログを受信する（アーカイブログを取得する）クライアントになることを決定します。
fal_server = 'teststan'-アーカイブログの転送元となるFAL（アーカイブログの取得）サーバーを定義します。 fal_clientおよびfal_serverパラメーターは、データベースがスタンバイモードで起動された場合にのみ機能します。
standby_file_management = 'AUTO'-自動ファイル管理モードをスタンバイモードに設定します。 このパラメーターの値を使用すると、メインデータベースによって作成または削除されたすべてのファイルがスタンバイデータベースに自動的に作成または削除されます。

メインデータベースがあるディレクトリ以外のディレクトリにスタンバイデータベースを配置する場合は、追加のパラメータが必要です。

db_file_name_convert = '/ oradata_new / test'、 '/ oradata / test'-このパラメーターは、スタンバイデータベースに作成されるデータファイルの名前で（つまり、メインインスタンスがスタンバイモードで動作を開始するとき）、変更する必要があることを示します「/ oradata_new / test」から「/ oradata / test」へのパス。
log_file_name_convert = '/ oradata_new / test / archive'、 '/ oradata / test / archive'-このパラメーターは、スタンバイデータベースに作成されるログファイルの名前で、パスを '/ oradata_new / test / archive'から「/ oradata / test / archive」。

その結果、メインデータベースのパラメーターファイルには、特に次のエントリが必要です。

# PRIMARY STANDBY
db_name='test'
db_unique_name='testprod'
log_archive_config='dg_config=(testprod,teststan)'
log_archive_dest_1='SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name='teststan' log_archive_dest_2='LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=testprod'
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# STANDBY
fal_client='testprod'
fal_server='teststan'
standby_file_management='AUTO'

そのような機会があれば、新しいパラメータでメインデータベースを再起動し、 処理したpfileに基づいて新しいspfileを作成します 。

SQL> shutdown immediate;
SQL> startup nomount pfile='/data/backup/pfilePROD.ora';
SQL> create spfile from pfile='/data/backup/pfilePROD.ora';
SQL> shutdown immediate;
SQL> startup;

操作中にメインベースを停止する機会がない場合は、ALTER SYSTEMを使用して現在の構成を変更する必要があります。
作業ベースでdb_unique_nameを変更することはできないことに注意してください。 したがって、現在構成にある名前を使用する必要があります。 次のコマンドを使用して表示できます。

SQL> show parameter db_unique_name
NAME TYPE VALUE
------------------------------------ ----------- --------------------------
db_unique_name string test

必要なパラメーターを設定します。

SQL> alter system set log_archive_config='dg_config=(test,teststan)';
System altered.

アーカイブされたジャーナルを記録する場所を設定します。 作業ベースでは、 log_archive_dest_1パラメーターが設定されている場合、調整することはできません。 したがって、スタンバイデータベースにコピー方向を追加するだけです。

SQL> alter system set log_archive_dest_2='SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=teststan';
System altered.

SQL> alter system set log_archive_dest_state_2=ENABLE;
System altered.

SQL> alter system set FAL_SERVER=teststan;
System altered.

SQL> alter system set FAL_CLIENT=test;
System altered.

SQL> alter system set standby_file_management='AUTO';
System altered.

スタンバイデータベースに関するレコードをtnsnames.oraに追加します。

TESTSTAN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)

（バックアップがない場合）バックアップを作成します。 このために、rmanユーティリティを使用します。
スタンバイベースを展開するバックアップの場所は、このバックアップを保存した場所とまったく同じである必要があります。 つまり バックアップを「/ data / backup」ディレクトリに配置すると、スタンバイサーバーでデータベースを復元するときに、rmanは同じディレクトリでバックアップデータを検索します。 この問題を解決するには、2つの明白な方法があります。バックアップデータをメインサーバーからスタンバイに作成されたまったく同じディレクトリにコピーするか、両方のサーバーに均等にマウントされるネットワークリソースをバックアップに使用します。

メインサーバーでrmanを実行します。
$ rman target /

OracleがLinuxにインストールされている場合の興味深い点。 PolyglotManパッケージ（RosettaMan）をインストールした場合、実行しようとすると
$ rman target /
エラーが発生する可能性があります。
rman: can't open target
この状況は、環境変数$ PATH内のこのパッケージのrman実行可能ファイルへのパス（たとえば、/ usr / X11R6 / bin / rman）がOracle rmanへのパスより前にある場合に発生します。 つまり PolyglotManパッケージからrmanを実行し、ターゲットファイルをパラメーターとして渡すことを試みていますが、これは当然開くことはできません。

スタンバイデータベースの制御ファイルを作成します。

RMAN> backup current controlfile for standby format '/data/backup/standbycontrol.ctl';

メインデータベースとアーカイブマガジンのバックアップを作成します。

RMAN> run
2> {
3> allocate channel c1 device type disk format '/data/backup/%u';
4> backup database plus archivelog;
5> }

ここで、何らかの理由でアーカイブされたジャーナルの完全なセットがない場合（たとえば、削除された場合）、トラブルが発生する可能性があります。 次に、rmanはエラーをスローします。

RMAN-20242: Specification does not match any archivelog in the recovery catalog

状況を改善するには、rmanリポジトリのアーカイブログのステータスを確認および変更する必要があります。 これを行うには、次のコマンドを実行します。

RMAN> change archivelog all crosscheck;

バックアップが成功した場合、 / data / backup /ディレクトリの内容をスタンバイサーバーにコピーし（バックアップにネットワーク共有を使用しなかった場合）、スタンバイサーバーにインスタンスを作成します。

まず、データベースのインスタンスを作成せずにスタンバイサーバーにOracleをインストールする必要があります。 さらに寿命を延ばすために、スタンバイサーバー上の$ ORACLE_HOMEへのパスは、メインサーバーと同じである必要があります。 Oracleバージョンに完全に準拠するために、メインサーバーにインストールされたすべてのパッチもインストールします。
リスナー構成とネットサービス名を作成します。
スタンバイサーバーにメインデータベースのコピーをデプロイするには、戦闘サーバーで実行されているrmanを使用しますが、データベースのスタンバイインスタンスはnomountモードになり、listener.oraにサービスを明示的に登録する必要があります。補助についての将来のスタンバイへのrmanはブロックされます。
その結果、 listener.oraは次のようになります。

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /oracle)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = teststan)
(ORACLE_HOME = /oracle)
(SID_NAME = test)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
)

この場合のパラメーターSID_NAMEは、大文字と小文字が区別されることに注意してください。 リスナーはorapw $ SID_NAMEという名前のパスワードファイルを探します。

ところで、今がパスワードファイル（$ ORACLE_HOME / dbs / orapw $ ORACLE_SID）をメインサーバーからスタンバイにコピーするときです。

また、メインおよびスタンバイのベースをtnsnames.oraに登録する必要があります。

TEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)

TESTPROD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = productionsrv)(PORT = 1521))
)
(CONNECT_DATA =
(SID = test)
)
)

なぜなら アプリケーションはtestという名前でデータベースを「認識」しており、スタンバイデータベースにはSIDテストを設定していることがわかります。

リスナーを再起動することを忘れないでください：

$ORACLE_HOME/bin/lsnrctl stop
$ORACLE_HOME/bin/lsnrctl start

次に、データベースのディレクトリ構造を作成します。 通常、$ ORACLE_HOME / admin / $ ORACLE_SIDにあるadump 、 bdump 、 cdump 、 dpdump 、 udumpディレクトリと同様に、データファイルとログファイルを格納するためのすべてのディレクトリを作成する必要があることを忘れないでください。
スタンバイでメインデータベースのディレクトリ構造を保存したくない場合は、 db_file_name_convertおよびlog_file_name_convertパラメータの値に従ってディレクトリを作成する必要があります。

また、メインデータベースのパラメーターに基づいて、スタンバイ用のパラメーターファイルを作成する必要があります。 これを行うには、スタンバイサーバー上のpfilePROD.oraファイルを書き換えてpfileSTAN.oraに名前を変更し、前に編集した部分に必要な修正を加えます。

# PRIMARY STANDBY
db_name='test'
db_unique_name='teststan'
log_archive_config='dg_config=(testprod,teststan)'
log_archive_dest_1='SERVICE=testprod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name='testprod' log_archive_dest_2='LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=teststan'
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# STANDBY
fal_client='teststan'
fal_server='testprod'
standby_file_management='AUTO'

スタンバイデータベースを他のディレクトリに配置する場合、必要なパラメーターも追加します。

db_file_name_convert='/oradata/test','/oradata_new/test'
log_file_name_convert='/oradata/test/archive','/oradata_new/test/archive'

スタンバイベースインスタンスを開始します。

SQL> startup nomount pfile='/data/backup/pfileSTAN.ora';
SQL> create spfile from pfile='/data/backup/pfileSTAN.ora';
SQL> shutdown immediate;
SQL> startup nomount;

バックアップからスタンバイデータベースを展開します。 これを行うには、メインサーバーに移動してrmanを実行します。

将来のスタンバイデータベースに接続し、複製を実行します（データバックアップおよび制御ファイルは、メインサーバーおよびスタンバイから/ data / backupとして表示されるディレクトリにあることを覚えています）。

RMAN> connect auxiliary sys@teststan
RMAN> duplicate target database for standby nofilenamecheck dorecover;

nofilenamecheckパラメーターが必要です。これは、 rmanが重複したファイル名を誓わないようにするためです（メインサーバーとスタンバイサーバーで同じディレクトリ構造を使用する場合）。

すべてがうまくいった場合、システムをスタンバイベースのトランザクションの自動アプリケーションに移行します。

ログファイルを切り替えて、メインデータベースのアーカイブログの最後の番号を確認します。

SQL> alter system switch logfile;
System altered.

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
205

次に、スタンバイサーバーに移動します。

データベースのステータスを確認します。

SQL> select name,open_mode,log_mode from v$database;

NAME OPEN_MODE LOG_MODE
--------- ---------- ------------
TEST MOUNTED ARCHIVELOG
SQL> select recovery_mode from v$archive_dest_status;

RECOVERY_MODE
-----------------------
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE

11 rows selected.

SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
202

スタンバイで最後に使用されたログがメインベースよりも遅れており、ARCHプロセスが機能していないことがわかります。

スタンバイREDOログを確認します。

SQL> select * from v$standby_log;

そうでない場合は、作成します。

SQL> alter database add standby logfile group 4 '/oradata/test/stnbylog01.log' size 50m;
Database altered.

SQL> alter database add standby logfile group 5 '/oradata/test/stnbylog02.log' size 50m;
Database altered.

SQL> alter database add standby logfile group 6 '/oradata/test/stnbylog03.log' size 50m;
Database altered.


スタンバイベースをリアルタイムアプライREDOモードに移行します。

SQL> alter database recover managed standby database using current logfile disconnect;

何が起こったのか見てみましょう：

SQL> select recovery_mode from v$archive_dest_status;

RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY

11 rows selected.

SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
205

ご覧のとおり、すべてが機能します。

リアルタイムアプライREDOモードを使用したくないが、メインサーバーでの次のアーカイブログの形成が完了し、保存されたトランザクションを使用するためにスタンバイに転送されるまで待機する場合、コマンドでスタンバイベースをREDOアプライモードにする必要があります：

SQL> alter database recover managed standby database disconnect;

問題が発生した場合、まず問題を解決するには、まずログの「ローリング」を停止する必要があります。

SQL> alter database recover managed standby database cancel;

複製中にすべてのアーカイブログがスタンバイサーバーに転送されなかった可能性があります。 次に、手動で「ロール」するために、スタンバイサーバー（この場合、/ oradata / test / archiveディレクトリ）に手動でコピーする必要があります。

SQL> recover standby database;

その後、Real-time apply redoを再度実行します。

SQL> alter database recover managed standby database using current logfile disconnect;

インスタンス間でロールを切り替えるプロセス（スイッチオーバー）とメインデータベースに障害が発生した場合にスタンバイデータベースをプライマリモードにするプロセス（フェールオーバー）には、多くの落とし穴があるため、これは別の記事のトピックです。