DataGuard入門　その１

Oracle DataGuardについて、その基本構成、セットアップ方法、スイッチオーバー、Flashback、管理方法などを紹介する全4回の連載を1冊にまとめました。
Oracle DataGuardとは・・・1つ以上の Standby Database から構成されていてプライマリデータベース(稼動している方)から Standby Database へ REDO ログを転送し、同期をとることで、可用性を高めるものです。DataGuard には、Physical Standby Database と Logical Standby Database の 2つの構成を利用することができます。

*eBook版のダウンロードをご希望の方は、画像をクリック

＜DataGuard入門　その１＞
ペンネーム：りん

おら！オラ！Oracleをご愛読の皆様
はじめまして。新米雑用係りんです。

今回からDataGuard入門をお送りしたいと思います。
至らぬ点が（かなり）多いと思いますが、お付き合いください。

○DataGuardって？
Oracle DataGuardは、1つ以上のStandby Databaseから構成されていてプラ
イマリデータベース（稼動しているほう）からStandby DatabaseへREDOログ
を転送し、同期をとることで、可用性を高めるものです。

○Standby Databaseの種類
DataGuardには、Physical Standby DatabaseとLogical Standby Database
の2つの構成を利用することができます。
Physical StandbyとLogical Standby Databaseの違いを一言で書くなら、
・物理構成を等しくするものがPhysical Standby
・論理構成を等しくするものがLogical Standby
という違いがあります。

Physical Standby構成は、プライマリデータベースからアーカイブログを
Standbyへ転送し、リカバリする形で同期をとります。
つまり、アーカイブログファイルを、Standby Databaseにバックアップリカ
バリの仕組みを使って適用する形になります。

Logical Standby構成は、転送されたアーカイブログファイルをSQL文に変換
し変換されたSQL文を実行することによってプライマリデータベースと同期
をとります。

○Oracle10gで拡張された機能
Oracle8iのStandby Database（Physical Standby）を拡張しOracle9i では、
Logical Standby Database構成が構築できREDOログをStandby側へ適用でき
るようになりました。

Oracle10gからリアルタイム適用という機能が使えます。
この機能は、プライマリデータベースのLGWRプロセスが送信したREDOデータ
を、Standby Database側で受信し、アーカイブログにすることなく適用でき
るものです。
即時にStandby Databaseへ適用することができるものです。
とりあえずPhysical Standbyで試してみようと思います。

SQL> startup mount
ORACLE instance started.

Total System Global Area  188743680 bytes
Fixed Size                   778036 bytes
Variable Size             162537676 bytes
Database Buffers           25165824 bytes
Redo Buffers                 262144 bytes
Database mounted.

SQL> recover managed standby database using current logfile disconnect;
Media recovery complete.

リアルタイム適用が実行されるかどうかを確認してみます。

SQL> select dest_name,recovery_mode from v$archive_dest_status;

DEST_NAME                      RECOVERY_MODE
------------------------------ -----------------------
LOG_ARCHIVE_DEST_1             MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_2             MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_3             MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_4             MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_5             MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_6             MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_7             MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_8             MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_9             MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_10            MANAGED REAL TIME APPLY
STANDBY_ARCHIVE_DEST           MANAGED REAL TIME APPLY

11 rows selected.

ちゃんと、MANAGED REAL TIME APPLYとなっています。
試しに、プライマリ側で、ログのスイッチをしてみます…

Primary↓

SQL> alter system switch logfile;

システムが変更されました。

Standby側のalertログを確認します。

---------------------------------------------------------------------------
Mon Jun 21 22:13:48 2004
Media Recovery Log /home/oracle/archive/standby/standby1_32_529269042.arc
Mon Jun 21 22:13:48 2004
Primary database is in MAXIMUM PERFORMANCE mode
Mon Jun 21 22:13:51 2004
Media Recovery Waiting for thread 1 sequence 33 (in transit)
---------------------------------------------------------------------------

転送されたREDOアーカイブが適用されているかどうかを確認します。

SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
 SEQUENCE# APP
---------- ---
         9 YES
      ～中略～

SEQUENCE# APP
---------- ---
        26 YES
        27 YES
        28 YES
        29 YES
        30 YES
        31 YES
        32 YES

ばっちり適用されています。
即時にREDOアーカイブを適用することにより、リカバリまでのダウンタイム
を軽減することができるはずです…

今回はここまでです。

毎日がお勉強。茅ヶ崎にて

DataGuard入門 その１