Oracle Database 12c Release 1 でData Guardを学ぶ - フィジカル・スタンバイ・データベースの作成(1)

【目的】

Oracle Database 12c Release 1 でData Guardを実装する。

【環境】

ホストOS：MacBook Air OS X EI Capitan / 1.6GHz Intel Core i5 / 4GB /
ゲストOS：Oracle Linux Release 6 Update 4 for x86_64 (64 bit)

# 今回の勉強用途でMacBook Air買ったのだかすでに容量パンパン。。

【参考資料】

Data Guardに関する社内ハンズオンの資料とかWeb上の資料とか。

【現状】

このエントリに書いたとおり、VirtualBox上にOracle DB 12cR2を構築した経験はある。
逆にそれ以外の経験はなし。

【今日やること】

フィジカル・スタンバイ・データベースの作成。

－－－以下作業－－－

そもそもフィジカル・スタンバイ・データベースとは？

フィジカル・スタンバイ・データベースはプライマリ・データベースを正確に、ブロックごとにコピーしたものです。フィジカル・スタンバイはREDO Applyと呼ばれるプロセスによって正確なコピーとして維持されます。このプロセスではデータベース・リカバリ・メカニズムを使用して、プライマリ・データベースから受信したREDOデータを継続的にフィジカル・スタンバイ・データベースに適用します。

フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンし、問合せをプライマリ・データベースからオフロードするために使用できます。 Oracle Active Data Guardオプションのライセンスを購入している場合は、フィジカル・スタンバイ・データベースを開いている間はRedo Applyをアクティブにすることができます。それにより、問合せによって、プライマリ・データベースからのものと同じ結果が得られます。この機能は、リアルタイム問合せ機能と呼ばれます。

出典：[https://docs.oracle.com/cd/E16338_01/server.112/b56302/standby.htm:title=Oracle® Data Guard概要および管理]

日常でのセールストークはこんな具合と想像。
・本番DBのREDOデータを継続的にDRサイトのDBに適用することで高可用性を確保できます。
・ストレージバックアップとは違いデータの破損およびユーザーエラーからも保護されます。
　# 本番DBでのストレージレベルの物理的な破損がDRサイトのDBに伝播することはありません（これ大事）

…

ということでフィジカル・スタンバイ・データベースの作成を始める。
まずはプライマリ・データベース設定の確認から。

[oracle@node1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on 水 11月 29 17:35:27 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.



Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
に接続されました。

SQL> show parameters db_name

NAME				     TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
db_name 			     string
orcl

SQL> show parameter db_unique_name

NAME				     TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
db_unique_name			     string
orcl

SQL> show parameters db_block size

NAME				     TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
db_block_buffers		     integer
0
db_block_checking		     string
FALSE
db_block_checksum		     string
TYPICAL
db_block_size			     integer
8192

SQL> show parameters audit_file_dest         

NAME				     TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
audit_file_dest 		     string
/u01/app/oracle/admin/orcl/adu
mp

SQL> show parameters remote_login_passwordfile        

NAME				     TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
remote_login_passwordfile	     string
EXCLUSIVE

SQL> show parameters listener

NAME				     TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
listener_networks		     string

local_listener			     string
LISTENER_ORCL
remote_listener 		     string

SQL> show parameters DB_RECOVERY_FILE_DEST

NAME				     TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
db_recovery_file_dest		     string
+FRA
db_recovery_file_dest_size	     big integer
4800M

ここまでが設定の確認。
赤字で記載した部分が特にチェックすべき項目。

次にData Guard用初期化パラメータの設定を行う。

# DG_CONFIGにはData Guard構成に含まれるすべてのデータベースのDB_UNIQUE_NAMEを設定
SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,orcls)'scope=spfile;

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

# ローカル・ノードへのアーカイブREDOログ格納
SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
  2  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=orcl'Scope=spfile;

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

# リモート・ノードへのREDOログ転送
SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=node2 ASYNC
  2  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=orcls'scope=spfile;

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

上記でアーカイブログの保存先の指定とREDOログの有効化を行った。
ASYNC属性を指定することでプライマリでのREDOの生成とスタンバイへの転送が非同期に行われる。
その他の細かい説明は省略してData Guard用初期化パラメータの設定を続ける。

SQL> alter system set LOG_ARCHIVE_DEST_STATE_1='ENABLE' scope=spfile;

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


SQL> alter system set LOG_ARCHIVE_DEST_STATE_2='ENABLE' scope=spfile;

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

上記手順ではLOG_ARCHIVE_DEST_1及びLOG_ARCHIVE_DEST_2を
アーカイブ操作の宛先として使用するか否かを設定した。
今回は両方使用するため「ENABLE」に設定。

次。

SQL> alter system set FAL_SERVER='node2' scope=spfile;

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

SQL> alter system set STANDBY_FILE_MANAGEMENT='AUTO' scope=spfile;

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

FAL_SERVER='node2' について手元の資料は以下のように記載がある。

「FAL_SERVERには、スタンバイ・データベースのFAL(Fetch Archive Log)サーバーを指定する」

FALとは何か？については後で復習するとしてとりあえず作業を進める。

また、STANDBY_FILE_MANAGEMENT='AUTO' ではデータファイルがプライマリ・データベースに
追加または削除された場合に、 それに対応してスタンバイ・データベースも自動的に変更されるよう、
 AUTOに設定をした。
※このパラメータは、フィジカル・スタンバイ・データベースに対してのみ適用される

ここまででData Guard用初期化パラメータの設定は完了。
だいぶ長くなったので本エントリはここまで。

ysk_son’s diary

勉強の記録