DataGuard入門 その1





http://info.insight-tec.com/hubfs/db_tech_library/TechBlog_DataGuard.png





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

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

<DataGuard入門 その1>
ペンネーム:りん

おら!オラ!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アーカイブを適用することにより、リカバリまでのダウンタイム
を軽減することができるはずです…

今回はここまでです。

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