Comments
Description
Transcript
Oracle Data Guard 11g フィジカル・スタンバイ設定ガイド
Oracle Data Guard 11g フィジカル・スタンバイ設定ガイド Date: 2008 年 3 月 Version: 1.0 -1Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 謝辞 2006 年 11 月、日本オラクル株式会社は株式会社日立製作所やグリッド戦略パートナー各社と 協業体制を確立し、企業のシステム基盤の最適化を実現する次世代のビジネス・ソリューション を構築するため、先鋭の技術を集結した「Oracle GRID Center(オラクル・グリッド・センター)」 (http://www.oracle.co.jp/solutions/grid_center/index.html) を 開 設 し ま し た 。 本 稿 は 、 Oracle GRID Center の趣旨にご賛同頂いたインテル株式会社、シスコシステムズ株式会社のハードウェ ア・ソフトウェアのご提供および技術者によるご支援などの多大なるご協力を得て作成しており ます。ここに協賛企業各社およびご協力頂いた技術者に感謝の意を表します。 ※本ドキュメントの無断転載を禁じます 免責事項 このドキュメントは単に情報として提供され、内容は予告なしに変更される場合があります。 このドキュメントに誤りが無いことの保証や、商品性又は特定目的への適合性の黙示的な保証や 条件を含め明示的又は黙示的な保証や条件は一切無いものとします。日本オラクル株式会社およ び株式会社日立製作所は、このドキュメントについていかなる責任も負いません。また、このド キュメントによって直接又は間接にいかなる契約上の義務も負うものではありません。このドキ ュメントを形式、手段(電子的又は機械的)、目的に関係なく、日本オラクル株式会社および株式 会社日立製作所の書面による事前の承諾なく、複製又は転載することはできません。 商標類 Oracle は，米国 Oracle Corporation 及びその子会社，関連会社の登録商標です。 Linux は、Linus Torvalds の米国およびその他の国における登録商標あるいは商標です。 その他の名称は、各社の商標または登録商標です。 -2Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved １ 目次 １ 目次 ......................................................................................................................................... 3 ２ はじめに.................................................................................................................................. 4 ３ 構築環境.................................................................................................................................. 4 ４ ハードウェアおよびオペレーティングシステム要件 .............................................................. 5 ５ ソフトウェア要件.................................................................................................................... 5 ６ スタンバイ・データベース構築手順 ....................................................................................... 6 6.1 6.2 6.3 6.4 6.5 6.6 プライマリ・データベースでの事前設定 ............................................................................. 6 スタンバイ・データベースの作成........................................................................................ 7 管理リカバリモードの開始 ............................................................................................... 15 プライマリ・データベースの構成変更............................................................................... 16 REDO転送・適用確認 ...................................................................................................... 17 フラッシュバック・データベースの構成 ........................................................................... 18 ７ リアルタイム・クエリー設定手順......................................................................................... 20 7.1 リアルタイム・クエリー設定手順...................................................................................... 20 7.2 リアルタイム・クエリー停止手順...................................................................................... 24 ８ スナップショット・スタンバイ変更手順 .............................................................................. 25 8.1 フィジカル・スタンバイからスナップショット・スタンバイへの 8.2 スナップショット・スタンバイからフィジカル・スタンバイへの 変更手順 ................. 25 変更手順 ................. 27 ９ スイッチオーバー/スイッチバック 手順............................................................................... 30 9.1 スイッチオーバー手順 ........................................................................................................ 30 9.2 スイッチバック手順............................................................................................................ 36 １０ フェイルオーバー/フェイルバック 手順 ........................................................................... 37 10.1 フェイルオーバー手順 ...................................................................................................... 37 10.2 フェイルバック手順.......................................................................................................... 40 １１ Data Guard Brokerの構成................................................................................................ 43 11.1 Data Guard Broker の構成手順 .................................................................................... 43 11.2 ファスト・スタート・フェイルオーバーの設定手順 ..................................................... 48 11.3 ファスト・スタート・フェイルオーバーの詳細設定 ..................................................... 51 -3Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ２ はじめに 本書は Oracle Data Guard 11g フィジカル・スタンバイ・データベースの構築ガイドです。本 書では LinuxOS 上に構築された既存の Oracle Real Application Clusters (以降、RAC)構成を使 用して、LinuxOS 上に Oracle RAC 構成のフィジカル・スタンバイ・データベースを追加し、 Oracle Data Guard 構成を作成する手順を紹介します。また Oracle Database 11g Release 1 の 新機能であるリアルタイム・クエリー、スナップショット・スタンバイの設定手順、スイッチオ ーバー、フェイルオーバーの基本的な手順を紹介します。 （注意：本書は Oracle Data Guard の実際に使用した設定や手順を紹介するものであり、全ての 環境において本書と同じ設定や手順を推奨するものではありません。また、全ての環境で同じ実 行結果やログ出力になることを保証するものではありません） ３ 構築環境 本書で使用しているコマンドの実行例や設定例は以下の環境を仮定したものとなります。 ・プライマリ・データベース(2 ノード RAC 構成) ノード 1 ノード 2 TOKYO1 TOKYO2 ホスト名 10.196.7.40 10.196.7.41 PublicLAN 用 IP アドレス 192.168.7.40 192.168.7.41 PrivateLAN 用 IP アドレス VIP TOKYO1-vip TOKYO2-vip ORACLE_HOME /oracle/db/product/11.1.0/db_1 DB_UNIQUE_NAME TOKYO TOKYO1 TOKYO2 インスタンス名 +ASM1 +ASM2 ASM インスタンス名 ・スタンバイ・データベース(2 ノード RAC 構成) － フィジカル・スタンバイ・データベース ノード 1 ノード 2 OSAKA1 OSAKA2 ホスト名 10.196.8.42 10.196.8.43 PublicLAN 用 IP アドレス 192.168.8.42 192.168.8.43 PrivateLAN 用 IP アドレス VIP OSAKA1-vip OSAKA2-vip ORACLE_HOME /oracle/db/product/11.1.0/db_1 DB_UNIQUE_NAME OSAKA OSAKA1 OSAKA2 インスタンス名 +ASM1 +ASM2 ASM インスタンス名 また本書で紹介している手順は以下の条件を満たしている環境を前提とした手順となります。 ・プライマリ・データベースが作成済みである ・プライマリ・データベースは Automatic Storage Management (以降、ASM)を使用している ・スタンバイ・データベース・サーバーには Oracle Database のソフトウェアの インストールが完了している ・スタンバイ・データベース・サーバーには Oracle Clusterware の インストールが完了している ・スタンバイ・データベース用の ASM インスタンスが作成済みである ・スタンバイ・データベース用の ASM インスタンス上でディスクグループが作成済みである ・プライマリ・スタンバイ両データベースともフラッシュリカバリ領域を使用している -4Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ４ ハードウェアおよびオペレーティングシステム要件 4.1 Oracle Data Guard 構成 Oracle Data Guard 環境は以下の構成で作成することが可能です 1) プライマリ・データベース：RAC / スタンバイ・データベース：RAC ＊プライマリ、スタンバイ間で RAC 構成のノード数が異なっていても可 2) プライマリ・データベース：RAC / スタンバイ・データベース：シングル 3) プライマリ・データベース：シングル / スタンバイ・データベース：RAC 4) プライマリ・データベース：シングル / スタンバイ・データベース：シングル 本書では 1) の構成について示します。 4.2 オペレーティングシステム要件 Oracle Database 11g Release 1 では Oracle Data Guard 構成の柔軟性が増し、プライマリ・ データベース、スタンバイ・データベース間で CPU アーキテクチャやワードサイズが異なる構 成も可能です。 また一部のオペレーティングシステム(2007 年 12 月時点では Linux と Windows)では、プライマ リ・データベースとスタンバイ・データベース間でオペレーティングシステムが異なる構成を実 現することも可能です。 Oracle Data Guard 構成の前提となる Oracle Database 11g Release 1 ソフトウェアのインスト ールのためのオペレーティングシステム要件等の情報は、インストレーションガイド及びリリー スノートをご参照ください。 ５ ソフトウェア要件 Oracle Database Enterprise Edition を使用している必要があります。Oracle Data Guard 11g 新 機 能 で あ る リ ア ル タ イ ム ・ ク エ リ ー を 使 用 す る た め に は 、 追 加 ラ イ セ ン ス と し て Enterprise Edition の他に Oracle Active Data Guard オプションが必要となります。 -5Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ６ スタンバイ・データベース構築手順 6.1 プライマリ・データベースでの事前設定 フィジカル・スタンバイ・データベースを作成する前にプライマリ・データベースで以下の 4 点 の確認を行う必要があります。 6.1.1 6.1.2 6.1.3 6.1.4 強制ロギングの有効化 アーカイブログモードへの変更 パスワード・ファイルの作成 初期化パラメータファイルの作成 6.1.1 強制ロギングの有効化 プライマリ・データベースで強制ロギングを有効にするために以下の SQL 文を発行します。 SQL> alter database force logging; 現在のデータベースで強制ロギングが有効となっているかは以下の SQL 文で確認可能です。 SQL> select force_logging from v$database; 実行例： SQL> select force_logging from v$database; FOR ------YES 6.1.2 アーカイブ・ログ・モードへの変更 プライマリ・データベースはアーカイブ・ログ・モードで稼動している必要があります。プラ イマリ・データベースがアーカイブ・ログ・モードで稼動しているか確認します。現在データベ ースがアーカイブ・ログ・モードで稼動しているかどうかは以下のコマンドを実行することで確 認することができます。 SQL> archive log list; 実行例： SQL> archive log list; Database log mode Automatic archival Archive destination Oldest online log sequence Current log sequence No Archive Mode Disabled +ARCH_FLASHBACK 26 28 データベースがノーアーカイブ・ログ・モードで稼動している場合はアーカイブ・ログ・モー -6Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ドへ変更します。アーカイブ・ログ・モードへは以下の SQL 文を実行することで変更可能です。 アーカイブ・ログ・モードへの変更を行う際は、インスタンスは mount 状態で実施する必要があ ります。 $ srvctl stop database –d tokyo $ srvctl start database –d tokyo –o mount SQL> alter database archivelog; アーカイブ・ログ・モードへの変更を実施後、再度以下コマンドを実行し、アーカイブ・ログ・ モードに変更されていることを確認します。 SQL> archive log list; 実行例： SQL> archive log list; Database log mode Automatic archival Archive destination Oldest online log sequence Next log sequence to archive Current log sequence Archive Mode Enabled +ARCH_FLASHBACK 26 28 28 6.1.3 パスワード・ファイルの作成 Oracle Data Guard 環境では REDO 転送セッションの認証に SSL プロトコルもしくはパスワ ード・ファイル認証を使用することが可能です。本書では REDO ログ転送セッションの認証にパ スワード・ファイルを使用する手順を紹介します。(SSL プロトコルでの認証についての詳細は、 マニュアル｢Oracle Data Guard 概要および管理 11g リリース 1（11.1)｣をご覧ください。) プライマリ・データベースにパスワード・ファイルが存在しない場合にはパスワード・ファイ ルを作成します。 $ cd $ORACLE_HOME/dbs $ orapwd file=’orapw$ORACLE_SID’ password=<password> ＊<password> の部分は sys ユーザーのパスワードを指定します 6.1.4 初期化パラメータファイルの作成 プライマリ・データベースで使用している spfile から pfile を作成します。 SQL> create pfile=’<ファイル名>’ from spfile; 作成した pfile については後述します。 6.2 スタンバイ・データベースの作成 Oracle Database 11g Release 1 では Recovery Manager (以下 RMAN)の duplicate コマンド -7Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved の機能拡張により起動中のプライマリ・データベースからバックアップファイルを作成せずに直 接スタンバイ・データベースを作成することが可能となりました。本書ではこの新機能を使用し た手順でのスタンバイ・データベースの作成手順を紹介します。スタンバイ・データベースの作 成は以下の流れで実施します。 6.2.1 スタンバイ・データベース・サーバーでの listener.ora の設定 6.2.2 OracleNet の設定 6.2.3 スタンバイ・データベース用パスワード・ファイルの作成 6.2.4 スタンバイ・データベース用初期化パラメータ・ファイルの作成 6.2.5 初期化パラメータ・ファイルの配置 6.2.6 ディレクトリの作成 6.2.7 スタンバイ・インスタンスの起動 6.2.8 RMAN の起動と接続 6.2.9 duplicate コマンドの実行 6.2.10 スタンバイ REDO ログの作成 6.2.11 OCR へのリソース登録(RAC 固有) (従来通り RMAN にて取得したバックアップファイルを使用してスタンバイ・データベースを作 成する手順や OS コマンドを使用して取得したバックアップからスタンバイ・データベースを作 成する手順でも構築は可能です。従来の手順の詳細についてはマニュアル｢Oracle Data Guard 概要および管理｣をご覧ください。) 6.2.1 スタンバイ・データベース・サーバーでの listener.ora の設定 RMAN の duplicate コマンドを使用するためにはプライマリ・データベースおよび RMAN を 起動するクライアントマシンからスタンバイ・データベース・サーバーへ OracleNet 経由で接続 する必要があります。RMAN からの OracleNet 接続を可能とするために、スタンバイ・データ ベース・サーバー上のリスナーにスタンバイ・データベースの情報を静的構成にて登録します。 duplicate コマンドはスタンバイ・データベース・サーバーのうちの１ノードに接続可能であれ ば実行可能なため、この設定はスタンバイ・データベース・サーバーの 1 ノードのみの実施で構 いません。 Listener.ora の記述例： LISTENER_OSAKA1 = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST =OSAKA1-vip)(PORT = 1521)(IP = FIRST)) (ADDRESS = (PROTOCOL = TCP)(HOST = 10.196.8.42)(PORT = 1521)(IP = FIRST)) ) ) SID_LIST_LISTENER_OSAKA1 = (SID_LIST = (SID_DESC = (SID_NAME = OSAKA1) (GLOBAL_DBNAME=OSAKA1) (ORACLE_HOME = /oracle/db/product/11.1.0/db_1) ) ) （この時点ではスタンバイ・データベースには制御ファイルもデータファイルもなく mount を -8Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 実施することができないため PMON による動的構成ではサービスが登録されません。 ） サービスが登録されていない状態では OracleNet 経由での接続もできないため RMAN からの 接続もできません。RMAN を使用してアクティブ・データベースからのスタンバイ・データベ ース作成を実行する際は、接続のために静的構成が必須作業となります) 6.2.2 Tnsnames.ora の設定 REDO 転送のためにプライマリ、スタンバイ両データベース間で OracleNet 接続を可能にしま す。また duplicate コマンドを使用してスタンバイ・データベースを作成するためには、RMAN を起動するマシンからプライマリ、スタンバイ両データベースに OracleNet 経由で接続可能であ る必要があります。 プライマリ、 スタンバイ両データベース及び RMAN を起動するマシン(RMAN クライアント)上で OracleNet の設定を実施します。RMAN クライアントからスタンバイ・デー タベースへの接続情報は、項番 6.2.1 で登録したサービスを利用してください。 (今回の実行例ではスタンバイ・データベース・サーバー上で RMAN を起動し duplicate コマン ドを実行するため、スタンバイ・データベースで RMAN クライアントの設定も包括しています。) プライマリ・データベースの tnsnames.ora 設定例： OSAKA = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = OSAKA1-vip)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = OSAKA2-vip)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = OSAKA) ) ) OSAKA1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = OSAKA1-vip)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = OSAKA1) ) ) スタンバイ・データベースの tnsnames.ora 設定例： TOKYO = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = TOKYO1-vip)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = TOKYO2-vip)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = TOKYO) ) ) OSAKA1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = OSAKA1-vip)(PORT = 1521)) -9Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ) (CONNECT_DATA = (SERVER = DEDICATED) (SID = OSAKA1) ) 6.2.3 スタンバイ・データベース用パスワード・ファイルの作成 Oracle Data Guard 構成ではプライマリ・データベースのパスワード・ファイルのコピーをス タンバイ・データベース用にリネームし、スタンバイ・データベースに配置する必要があります。 duplicate コマンドを使用してスタンバイ・データベースを作成する場合、duplicate コマンド実 行時にプライマリ・データベースからパスワードファイルがコピー、上書きされます。しかしな がら、RMAN で duplicate コマンドを実行するためにスタンバイ・インスタンスに接続する際も パスワード・ファイルが必要となるため、duplicate コマンド実行時に使用するパスワード・ファ イルをスタンバイ・サーバーで作成する必要があります。 プライマリ・データベースからパスワード・ファイルをコピーし、｢orapw$ORACLE_SID｣と ファイル名に変更して $ORACLE_HOME/dbs 配下に配置します。 実行例： $ cp orapwtokyo1 $ORACLE_HOME/dbs/orapwosaka1 ここで作成するパスワード・ファイルは、前述した通り duplicate コマンド実行時にプライマ リ・データベースからコピー、上書きされる一時的なものであるため、プライマリ・データベー スからファイルをコピーしなくともスタンバイ・データベース・サーバー上で以下の手順を実行 することで作成可能です。 $ cd $ORACLE_HOME/dbs $ orapwd file=orapw$ORACLE_SID password=<password> ＊<password> の部分はプライマリ・データベースと同一の sys ユーザーのパスワードを 指定します 6.2.4 スタンバイ・データベース用初期化パラメータ・ファイルの作成 スタンバイ・データベースで使用する初期化パラメータ・ファイルを作成します。項番 6.1.4 で作成した pfile をスタンバイ・データベース・サーバー上へコピー後、スタンバイ・データベ ース用に初期化パラメータ・ファイルを編集します。以下はスタンバイ・データベース用に編集 したパラメータの設定例です。各パラメータの設定値の詳細はマニュアル｢Oracle Database リフ ァレンス 11g リリース 1（11.1）｣をご参照ください。 ##RAC 関連パラメータ *.cluster_database=true *.cluster_database_instances=2 *.db_unique_name='osaka' osaka1.instance_number=1 osaka2.instance_number=2 osaka1.thread=1 osaka2.thread=2 osaka1.undo_tablespace='UNDOTBS1' osaka2.undo_tablespace='UNDOTBS2' *.remote_listener='LISTENERS_OSAKA' - 10 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ##Oracle Data Guard 関連パラメータ *.log_archive_config='dg_config=(tokyo,osaka)' *.log_archive_dest_1='location=+ARCH_FLASHBACK VALID_FOR=(all_logfiles,all_role) DB_UNIQUE_NAME=osaka' *.log_archive_dest_2='SERVICE=tokyo ASYNC VALID_FOR=(online_logfiles,primary_role) DB_UNIQUE_NAME=tokyo' *.db_file_name_convert='+DATA/TOKYO/DATAFILE/','+DATA/OSAKA/DATAFILE/', '+DATA/TOKYO/TEMPFILE/','+DATA/OSAKA/TEMPFILE/' *.log_file_name_convert='+REDO1/TOKYO/','+REDO1/OSAKA/', '+REDO2/TOKYO/','+REDO2/OSAKA/' *.standby_file_management='AUTO' *.fal_server='tokyo' *.fal_client='osaka' *.log_archive_trace=16383 ##その他のパラメータ *.compatible='11.1.0.0.0' *.diagnostic_dest='/oracle/db' *.audit_file_dest='/oracle/db/admin/osaka/adump' osaka1.background_dump_dest=’ /oracle/db/diag/rdbms/osaka/osaka1/trace’ osaka2.background_dump_dest=’ /oracle/db/diag/rdbms/osaka/osaka2/trace’ osaka1.core_dump_dest=’ /oracle/db/diag/rdbms/osaka/osaka1/cdump’ osaka2.core_dump_dest=’ /oracle/db/diag/rdbms/osaka/osaka2/cdump’ osaka1.user_dump_dest=’ /oracle/db/diag/rdbms/osaka/osaka1/trace’ osaka2.user_dump_dest=’ /oracle/db/diag/rdbms/osaka/osaka2/trace’ *.control_files='+DATA/OSAKA/control01.ctl','+DATA/OSAKA/control02.ctl', '+DATA/OSAKA/control03.ctl' *.db_recovery_file_dest='+ARCH_FLASHBACK' *.dispatchers='(PROTOCOL=TCP) (SERVICE=osakaXDB)' *.remote_login_passwordfile='EXCLUSIVE' 6.2.5 初期化パラメータ・ファイルの配置 項番 6.2.4 で作成したパラメータ・ファイルからスタンバイ・データベース用の spfile を作成 し配置します。スタンバイ・データベース・サーバー上で SQL*Plus から ASM インスタンスに 接続し spfile を配置するディレクトリを作成します。 (1) 配置ディレクトリの作成 下記の実行例では｢DATA｣という名称のディスクグループに DB_UNIQUE_NAME である ｢OSAKA｣ディレクトリを作成しています。 実行例： $ export ORACLE_SID=+ASM1 SQL> alter diskgroup DATA add directory ‘+DATA/OSAKA’; または ASMCMD ユーティリティを使用して ASM インスタンスに接続し mkdir コマンドを使用 してディレクトリを作成することも可能です。 実行例： - 11 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved $ export ORACLE_SID=+ASM1 $ asmcmd ASMCMD> mkdir ‘+DATA/OSAKA’ (2) spfile の作成 項番 6.2.4 で作成した初期化パラメータ・ファイルから spfile を作成し、(1)で作成したディレ クトリに配置します。SQL*Plus にてアイドル状態のスタンバイ・インスタンスに接続し、 spfile<DB_UNIQUE_NAME>.ora の名称で spfile を作成、配置します。 SQL> create spfile=’<spfile ファイル名> from pfile=’<項番 6.2.4 で編集したファイル名’; 実行例： SQL> create spfile=’+DATA/OSAKA/spfileosaka.ora’ from pfile=’/work/initstandby.ora’; (3) init.ora の作成 (2)で作成した spfile を使用してスタンバイ・データベースが起動できるように全てのスタンバ イ・データベース・サーバーで以下の内容で pfile を作成します。 $ cd $ORACLE_HOME/dbs $ echo “SPFILE=’<spfile フルパス>’ ” > init<SID 名>.ora 実行例： $ cd $ORACLE_HOME/dbs $ echo “SPFILE=’+DATA/OSAKA/spfileosaksa.ora’ “ > initosaka1.ora 6.2.6 ディレクトリの作成 全てのスタンバイ・データベース・サーバー上で初期化パラメータ AUDIT_FILE_DEST、 BACKGROUND_DUMP_DEST、CORE_DUMP_DEST、USER_DUMP_DEST で指定された ディレクトリの存在が存在することを確認します。存在しない場合は OS コマンドを使用してデ ィレクトリを作成します。 実行例： $ mkdir –p /oracle/db/admin/osaka/adump $ mkdir –p /oracle/db/diag/rdbms/osaka/osaka1/trace $ mkdir –p /oracle/db/diag/rdbms/osaka/osaka1/cdump 6.2.7 スタンバイ・インスタンスの起動 RMAN からスタンバイ・データベースに接続を行うためにはスタンバイ・インスタンスが nomount の状態で起動している必要があります。項番 6.2.5 で作成した spfile を使用してスタン バイ・インスタンスを nomount モードで起動します。 SQL> startup nomount 6.2.8 RMAN の起動と接続 - 12 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved RMAN を起動しプライマリ、スタンバイ両データベースへ接続を行います。 $ rman target ‘sys/<password>@<プライマリ接続情報>’ auxiliary ‘sys/<password>@<スタンバイ接続情報>’ 実行例： $ rman target ‘sys/oracle@tokyo’ auxiliary ‘sys/oracle@osaka1’ 6.2.9 duplicate コマンドの実行 duplicate コマンドを実行し稼動中のプライマリ・データベースからデータファイルのコピー を実施します。 RMAN> duplicate target database for standby from active database; ・for standby： スタンバイ・データベースとして使用する目的で duplicate コマンドを実行する際に付与するオプション ・from active database： 起動中のデータベースからデータベースの複製を行う際に使用するオプション Oracle Database 11g Release 1 新機能 上記の duplicate コマンドでは、パスワード・ファイルのコピー、スタンバイ・データベース 用制御ファイルのコピー、データファイルのコピーが実行されます。正常にコマンドが完了する とスタンバイ・データベースが mount された状態で作成されています。 6.2.10 スタンバイ REDO ログの作成 作成したスタンバイ・データベースへ接続しスタンバイ REDO ログ・ファイルを作成します。 スタンバイ REDO ログ・ファイルはプライマリ・データベースの REDO ログ・ファイルと同じ サイズである必要があります。またスタンバイ REDO ログ・ファイルはプライマリ・データベー スの REDO ログ・ファイルのグループ数より１つ以上多く作成する必要があります。 ・スタンバイ REDO ログ・ファイル数の算出方法 スタンバイ REDO ログ・ファイル数 ≧ (プライマリ・データベースの REDO ファイルグループ数 + 1) × REDO スレッド数 例えばプライマリ・データベースが 2 ノード RAC 構成で各スレッド毎に３つの REDO ロググル ープが存在する場合は以下の通り 8 グループ以上のスタンバイ REDO ログ・ファイルを作成する 必要があります。 (3+1) × 2 = 8 今回の環境ではプライマリ・データベースが 2 ノード RAC 構成で各スレッドごとに３つの REDO ロググループが存在し REDO ログ・ファイル１つのサイズが 4G であるため以下のような SQL 文を実行することになります。 実行例： SQL> alter database add standby logfile thread 1 group 7 - 13 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 2 ‘+REDO1/primary/st_redo07.log’ size 4G; SQL> alter database add standby logfile thread 1 group 8 2 ‘+REDO1/primary/st_redo08.log’ size 4G; SQL> alter database add standby logfile thread 1 group 9 2 ‘+REDO1/primary/st_redo09.log’ size 4G; SQL> alter database add standby logfile thread 1 group 10 2 ‘+REDO1/primary/st_redo10.log’ size 4G; SQL> alter database add standby logfile thread 2 group 11 2 ‘+REDO2/primary/st_redo11.log’ size 4G; SQL> alter database add standby logfile thread 2 group 12 2 ‘+REDO2/primary/st_redo12.log’ size 4G; SQL> alter database add standby logfile thread 2 group 13 2 ‘+REDO2/primary/st_redo13.log’ size 4G; SQL> alter database add standby logfile thread 2 group 14 2 ‘+REDO2/primary/st_redo14.log’ size 4G; スタンバイ REDO ログ・ファイルの追加は以下の SQL 文のように、ファイル名を指定せずに行 う こ と も 可 能 で す 。 こ の 場 合 は 、 初 期 化 パ ラ メ ー タ db_create_file_dest お よ び db_recovery_file_dest で指定されたディレクトリ以下に自動的に作成されます。 SQL> alter database add standby logfile thread <スレッド番号> group <グループ番号> 2 size <サイズ>; 6.2.11 OCR へのリソース登録(RAC 環境固有手順) duplicate コマンドにて作成したスタンバイ・データベースはこの時点では OCR に登録されて いません。srvctl コマンドを使用して OCR へデータベースリソース、インスタンスリソースの 登録を行います。 実行例： $ srvctl add database -d osaka -o /oracle/db/product/11.1.0/db_1 -n tokyo -r physical_standby -p "+DATA/OSAKA/spfileosaka.ora" ‐d：DB_UNIQUE_NAME (必須) ‐o：ORACLE_HOME のパス (必須) ‐n：DB_NAME ‐r：データベースロール 今回はフィジカルスタンバイ・データベースのため physical_standby を指定 ‐p：srvctl コマンドで起動した際に使用する spfile のフルパス (任意) 実行例： $ srvctl add instance -d osaka -i osaka1 -n osaka1 $ srvctl add instance -d osaka -i osaka2 -n osaka2 ‐d：DB_UNIQUE_NAME (必須) ‐i：インスタンス名 (必須) ‐n：ノード名 (必須) - 14 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 登録したインスタンスリソースと ASM リソースの間の依存関係を OCR に登録します。 実行例： $ srvctl modify instance -d osaka -i osaka1 -a +ASM1 $ srvctl modify instance -d osaka -i osaka2 -a +ASM2 ‐d：DB_UNIQUE_NAME (必須) ‐i：インスタンス名 (必須) ‐a：ASM インスタンス名 (必須) ASM リソースを有効化し起動させます。 実行例： $srvctl enable asm -n osaka1 -i +ASM1 $srvctl enable asm -n osaka1 -i +ASM1 $srvctl start asm -n osaka1 $srvctl start asm -n osaka2 6.3 管理リカバリモードの開始 フィジカル・スタンバイ・データベースでは MRP プロセス(管理リカバリプロセス)により REDO ログ・ファイルの適用が行われます。スタンバイ・データベースで MRP プロセスを起動 し REDO 適用を開始します SQL> alter database recover managed standby database using current logfile 2 disconnect from session; ・using current logfile： このオプションを付与するとスタンバイ・データベースに転送された REDO レコードはアーカ イブの出力を待つことなく、スタンバイ REDO ログ・ファイルから直接スタンバイ・データベ ースに適用されます。(Oracle Database 10g Release 1 からの新機能：リアルタイム適用) ・disconnect from session： オプションを付与することでバックグラウンドでプロセスが起動されます。 省略した場合はフォアグラウンドで実行されるため実行したプロンプトに制御が返りません。 スタンバイ・データベースで以下の SQL 文を実行することで MRP プロセスが起動している かを確認することが可能です。(MRP プロセスが起動している場合はレコードが返されます。) SQL> select process,pid,status,thread#,sequence# from v$managed_standby 2 where process='MRP0'; 実行例： SQL> select process,pid,status,thread#,sequence# from v$managed_standby 2 where process='MRP0'; - 15 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved PROCESS PID STATUS THREAD# SEQUENCE# -------------- ---------- ------------------------- ---------------- -------------------MRP0 2716.2 APPLYING_LOG 1 40 また、OS コマンドで ora_mrp0_<sid 名> プロセスが起動しているか確認することで MRP プ ロセスの起動を確認することも可能です。スタンバイ・データベースが RAC 環境の場合、MRP プロセスは１ノードでのみ起動します。 管理リカバリモードを停止させる場合は以下の SQL 文を実行します。 SQL> alter database recover managed standby database cancel; 6.4 プライマリ・データベースの構成変更 6.4.1 初期化パラメータの変更 プライマリ・データベースの初期化パラメータのうち Oracle Data Guard 構成に必要なパラ メータの変更を行います。以下はプライマリ・データベースでのパラメータ変更例です。各パラ メータの設定値の詳細はマニュアル｢Oracle Database リファレンス 11g リリース 1（11.1）｣を ご参照ください。 *.log_archive_config='dg_config=(osaka,tokyo)' *.log_archive_dest_1='location=+ARCH_FLASHBACK VALID_FOR=(all_logfiles,all_roles) DB_UNIQUE_NAME='tokyo' *.log_archive_dest_2='service='osaka' ASYNC VALID_FOR=(online_logfile,primary_role) db_unique_name='osaka' *.db_file_name_convert='+DATA/osaka/datafile/','+DATA/tokyo/datafile', '+DATA/osaka/tempfile/','+DATA/tokyo/tempfile/' *.log_file_name_convert='+REDO1/OSAKA/','+REDO1/TOKYO/', '+REDO2/OSAKA/','+REDO2/TOKYO/' *.fal_server='osaka' *.fal_client='tokyo' *.standby_file_management='AUTO' *.remote_login_passwordfile='EXCLUSIVE' 6.4.2 スタンバイ REDO ログ・ファイルの作成 スタンバイ REDO ログ・ファイルを作成します。今回の環境ではプライマリ・データベースが 2 ノード RAC 構成で各スレッドごとに３つの REDO ロググループが存在し REDO ログ・ファイ ル１つのサイズが 4G であるため以下のような SQL 文を実行することになります。 実行例： SQL> alter database add standby logfile thread 1 group 7 2 ‘+REDO1/standby/st_redo07.log’ size 4G; SQL> alter database add standby logfile thread 1 group 8 2 ‘+REDO1/standby/st_redo08.log’ size 4G; SQL> alter database add standby logfile thread 1 group 9 2 ‘+REDO1/standby/st_redo09.log’ size 4G; SQL> alter database add standby logfile thread 1 group 10 2 ‘+REDO1/standby/st_redo10.log’ size 4G; - 16 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved SQL> alter database add standby logfile thread 2 group 11 2 ‘+REDO2/standby/st_redo11.log’ size 4G; SQL> alter database add standby logfile thread 2 group 12 2 ‘+REDO2/standby/st_redo12.log’ size 4G; SQL> alter database add standby logfile thread 2 group 13 2 ‘+REDO2/standby/st_redo13.log’ size 4G; SQL> alter database add standby logfile thread 2 group 14 2 ‘+REDO2/standby/st_redo14.log’ size 4G; スタンバイ REDO ログ・ファイルの作成は以下の SQL 文のように、ファイル名を指定せずに行 う こ と も 可 能 で す 。 こ の 場 合 は 、 初 期 化 パ ラ メ ー タ db_create_file_dest お よ び db_recovery_file_dest で指定されたディレクトリ以下に自動的に作成されます。 SQL> alter database add standby logfile thread <スレッド番号> group <グループ番号> 2 size <サイズ>; 6.5 REDO 転送・適用確認 プライマリ・データベースでログ・スイッチを実施し、スタンバイ・データベースに正常に転 送されているか確認を行います。 6.5.1 既存のアーカイブ REDO ログ・ファイルの識別 スタンバイ・データベースで v$archived_log を問い合わせ、既存のアーカイブ REDO ログ・ ファイルを識別します。 SQL> select thread#, sequence#,first_time,next_time from v$archived_log; 実行例： SQL> select thread#, sequence#,first_time,next_time from v$archived_log; THREAD# SEQUENCE# FIRST_TIME NEXT_TIME ---------- ---------- ----------------- ----------------1 14 08/03/12 15:39:14 08/03/12 15:39:57 2 14 08/03/12 15:39:40 08/03/12 15:39:58 6.5.2 ログ・スイッチを実行しアーカイブ REDO ログ・ファイルを出力 プライマリ・データベースでログ・スイッチを実施し、現行の REDO ログ・ファイルのアーカ イブ REDO ログ・ファイルを出力させます。 SQL> alter system archive log current; 6.5.3 スタンバイ・データベースでアーカイブ REDO ログ・ファイルの出力確認 スタンバイ・データベースで v$archived_log を問い合わせ、アーカイブ REDO ログ・ファイ - 17 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ルが転送されたことを確認します。 SQL> select thread#, sequence#,first_time,next_time from v$archived_log; 実行例： SQL> select thread#, sequence#,first_time,next_time from v$archived_log; THREAD# SEQUENCE# FIRST_TIME NEXT_TIME ---------- ---------- ----------------- ----------------1 14 08/03/12 15:39:14 08/03/12 15:39:57 2 14 08/03/12 15:39:40 08/03/12 15:39:58 2 15 08/03/12 15:39:58 08/03/12 15:41:16 1 15 08/03/12 15:39:57 08/03/12 15:41:18 転送されたアーカイブ REDO ログ・ファイルは順に適用されていきます。 6.6 フラッシュバック・データベースの構成 プライマリ・スタンバイ両データベースでフラッシュバック・データベースの設定を有効にし ます。フラッシュバック・データベースの設定は必須ではありませんが、フラッシュバック・デ ータベースの設定を有効にしておくことにより、フェイルオーバー発生後の旧プライマリ・デー タベースを新スタンバイ・データベースとして容易に再構成することが可能です。フラッシュバ ック・データベースの設定を有効にしておくことを推奨します。 (本書では以降で紹介する手順でもフラッシュバック・データベースの機能が有効になっているこ とを前提に説明を行っています。) 現在フラッシュバック・データベースが有効となっているかどうかは以下の SQL 文を実行するこ とで確認することができます。 SQL> select flashback_on from v$database; 実行例： SQL> select flashback_on from v$database; FLASHBACK_ON ------------------------YES 6.6.1 初期化パラメータの設定 以下の２つの初期化パラメータを設定します。 ・db_recovery_file_dest：フラッシュリカバリ領域として使用する領域のフルパス ・db_recovery_file_dest_size：フラッシュリカバリ領域のサイズ （db_recovery_file_dest を設定する前に db_recovery_file_dest_size を設定する必要がありま す。db_recovery_file_dest_size が設定されていない状態で db_recovery_file_dest の設定を行 うとエラーとなり設定ができません。 ) - 18 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 6.6.2 フラッシュバック・データベースの有効化 フラッシュバック・データベースの設定を有効にします。以下の SQL 文を実行することでフラ ッシュバック・データベースを有効化することが可能です。フラッシュバック・データベースを 有効化する際、データベースは mount 状態である必要があります。 SQL> alter database flashback on; (RAC 環境固有手順) RAC 環境の場合はデータベースを mount 状態にするだけではなく、SQL 文を実行するイン スタンス以外のインスタンスを停止させておく必要があります。複数インスタンスが mount され ている状態でフラッシュバック・データベースを有効化しようとすると以下のようにエラーとな ります。 SQL> alter database flashback on; alter database flashback on * ERROR at line 1: ORA-38777: database must not be started in any other instance. またスタンバイ・データベースで実行する場合、管理リカバリモード中はフラッシュバック・ データベースを有効にできないため、管理リカバリモードを停止させる必要があります。管理リ カバリモードが開始している状態でフラッシュバック・データベースを有効化しようとすると以 下のようにエラーとなります。 SQL> alter database flashback on; alter database flashback on * ERROR at line 1: ORA-01153: an incompatible media recovery is active - 19 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ７ リアルタイム・クエリー設定手順 Oracle Database 11g Release 1 よりフィジカル・スタンバイ・データベースを読み取り専用で open させた状態で REDO ログの適用を行うことが可能となりました。この機能をリアルタイム・ クエリーと呼びます。本項では、スタンバイ・データベースが mount されている状況からリアル タイム・クエリーの設定を行う手順を紹介します。 7.1 リアルタイム・クエリー設定手順 7.1.1 管理リカバリモードの停止 スタンバイ・データベースで管理リカバリモードが開始している場合は停止します。 SQL> alter database recover managed standby database cancel; 7.1.2 スタンバイ・データベースを読み取り専用で open スタンバイ・データベースを読み取り専用で open します。RAC 環境で両ノードとも読み取り 専用で起動させたい場合は両インスタンスで実行する必要があります。 SQL> alter database open; 管理リカバリモードが開始している状態では読み取り専用で open した際にエラーとなり、イ ンスタンスを open させることができません。 SQL> alter database open; alter database open * ERROR at line 1: ORA-01154: database busy. Open, close, mount, and dismount not allowed now 7.1.3 管理リカバリモードの開始 読み取り専用で open した状態で管理リカバリモードを開始します。 SQL> alter database recover managed standby database using current logfile 2 disconnect from session; 以下は読み取り専用で open 中に管理リカバリモードを開始した際のスタンバイ・データベー ス側のアラートログの出力例です。 (本書に記載されているアラートログの出力例は初期化パラメータ log_archive_trace=16383 を 指定した状態でのアラートログ出力例となります) スタンバイ・データベースアラートログ出力例： ##SQL 文実行 Mon Jan 21 12:53:34 2008 alter database recover managed standby database using current logfile disconnect from - 20 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved session Attempt to start background Managed Standby Recovery process (osaka1) ##MRP プロセス起動 Mon Jan 21 12:53:34 2008 MRP0 started with pid=42, OS id=3847 MRP0: Background Managed Standby Recovery process started (osaka1) Fast Parallel Media Recovery enabled Mon Jan 21 12:53:39 2008 Managed Standby Recovery starting Real Time Apply Media Recovery Waiting for thread 2 sequence 65 (in transit) Recovery of Online Redo Log: Thread 2 Group 14 Seq 65 Reading mem 0 Mem# 0: +REDO2/osaka/st_redo14.log Media Recovery Waiting for thread 1 sequence 96 (in transit) Recovery of Online Redo Log: Thread 1 Group 10 Seq 96 Reading mem 0 Mem# 0: +REDO1/osaka/st_redo10.log Completed: alter database recover managed standby database using current logfile disconnect from session 7.1.4 設定確認 リアルタイム・クエリーが有効となっているか確認を行います。v$instance を問い合わせ、 status 列が”OPEN”となっていることを確認します。また項番 6.3 と同様の手順で MRP プロセ スが起動していることを確認します。 SQL> select status from v$instance; SQL> select process,pid,status,thread#,sequence# from v$managed_standby 2 where process='MRP0'; 実行例： SQL> select status from v$instance; STATUS -----------OPEN SQL> select process,pid,status,thread#,sequence# from v$managed_standby 2 where process='MRP0'; PROCESS PID STATUS THREAD# SEQUENCE# -------------- ---------- ------------------------- ---------------- -------------------MRP0 2716.2 APPLYING_LOG 1 40 7.1.5 REDO 適用確認 項番 6.5 と同様の手順で REDO 適用確認を実施します。以下はプライマリ・データベースでロ グ・スイッチを実行した際のアラートログの出力例です。 プライマリ・データベース(ノード１)アラートログ出力例： ##ログ・スイッチの実行 Mon Jan 21 13:04:15 2008 Beginning log switch checkpoint up to RBA [0x61.2.10], SCN: 378631178 - 21 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved Thread 1 advanced to log sequence 97 Current log# 2 seq# 97 mem# 0: +REDO1/tokyo/redo02.log ##LNS プロセスによりスタンバイ・データベースへ thread #1 sequence#96 の ##REDO ログ・ファイルの転送が完了する Mon Jan 21 13:04:15 2008 LNS: Completed archiving log 1 thread 1 sequence 96 (tokyo1) LNS: Closing remote archive destination LOG_ARCHIVE_DEST_2: 'standby' (tokyo1) ##アーカイバプロセスによりローカル出力先へ thread #1 sequence#96 のアーカイブログを出力 Mon Jan 21 13:04:15 2008 ARC3: Evaluating archive log 1 thread 1 sequence 96 ARC3: Beginning to archive thread 1 sequence 96 (378625000-378631178) (tokyo1) ARC3: Creating local archive destination LOG_ARCHIVE_DEST_1: '+ARCH_FLASHBACK' (thread 1 sequence 96) (tokyo1) ##LNS プロセスにより thread #1 sequence#97 の REDO ログ・ファイルの ##スタンバイ・データベースへのログ転送が開始される LNS: Creating remote archive destination LOG_ARCHIVE_DEST_2: 'osaka' (thread 1 sequence 97) (tokyo1) LNS: Transmitting activation ID 0x0 LNS: Standby redo logfile selected for thread 1 sequence 97 for destination LOG_ARCHIVE_DEST_2 LNS: Beginning to archive log 2 thread 1 sequence 97 (tokyo1) RAC 環境では各スレッドのアーカイブ REDO ログ情報はそれぞれのノードのアラートログ上に のみ出力されます。以下は同時刻のプライマリ・データベースのノード２(=スレッド２)のアラー トログ出力例です。 プライマリ・データベース(ノード２)アラートログ出力例： ##ログ・スイッチの実行 Mon Jan 21 13:04:17 2008 Beginning log switch checkpoint up to RBA [0x42.2.10], SCN: 378631181 Thread 2 advanced to log sequence 66 Current log# 5 seq# 66 mem# 0: +REDO2/tokyo/redo05.log ##LNS プロセスによりスタンバイ・データベースへ thread #2 sequence#65 の ##REDO ログ・ファイルの転送が完了する Mon Jan 21 13:04:17 2008 LNS: Completed archiving log 4 thread 2 sequence 65 (tokyo2) LNS: Closing remote archive destination LOG_ARCHIVE_DEST_2: 'osaka' (tokyo2) ##アーカイバプロセスによりローカル出力先へ thread #2sequence#65 のアーカイブログを出力 Mon Jan 21 13:04:17 2008 ARC3: Evaluating archive log 4 thread 2 sequence 65 ARC3: Beginning to archive thread 2 sequence 65 (378625003-378631181) (tokyo2) - 22 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ARC3: Creating local archive destination LOG_ARCHIVE_DEST_1: '+ARCH_FLASHBACK' (thread 2 sequence 65) (tokyo2) ##LNS プロセスにより thread #2 sequence#97 の REDO ログ・ファイルの ##スタンバイ・データベースへのログ転送が開始される LNS: Creating remote archive destination LOG_ARCHIVE_DEST_2: 'osaka' (thread 2 sequence 66) (tokyo2) LNS: Transmitting activation ID 0x0 LNS: Standby redo logfile selected for thread 2 sequence 66 for destination LOG_ARCHIVE_DEST_2 LNS: Beginning to archive log 5 thread 2 sequence 66 (tokyo2) 以下は同時刻のスタンバイ・データベース側で MRP プロセスが起動しているノードでのアラー トログ出力例です。 スタンバイ・データベースアラートログ出力： ## thread #1 sequence#96 の REDO ログ受信が完了 Mon Jan 21 13:04:15 2008 RFS[2]: Completed archive primary log 1 thread 1 sequence 96 (osaka1) ## thread#1 sequence#96 のアーカイブログがローカル出力先へ出力 Mon Jan 21 13:04:15 2008 ARC3: Evaluating archive log 10 thread 1 sequence 96 ARC3: Beginning to archive thread 1 sequence 96 (378625000-378631178) (osaka1) ARC3: Creating local archive destination LOG_ARCHIVE_DEST_1: '+ARCH_FLASHBACK' (thread 1 sequence 96) (osaka1) ## thread #1 sequence#97 の REDO ログ受信開始 RFS[2]: Begin archive primary thread 1 sequence 97 (osaka1) Primary database is in MAXIMUM PERFORMANCE mode RFS[2]: Successfully opened standby log 9: '+REDO1/osaka/st_redo09.log' ## thread #2 sequence#65 の REDO ログ受信が完了 Mon Jan 21 13:04:17 2008 RFS[6]: Completed archive primary log 4 thread 2 sequence 65 (osaka1) ## thread#2 sequence#65 のアーカイブログがローカル出力先へ出力 Mon Jan 21 13:04:17 2008 ARC0: Evaluating archive log 14 thread 2 sequence 65 ARC0: Beginning to archive thread 2 sequence 65 (378625003-378631181) (osaka1) ARC0: Creating local archive destination LOG_ARCHIVE_DEST_1: '+ARCH_FLASHBACK' (thread 2 sequence 65) (osaka1) ## thread #2 sequence#66 の REDO ログ受信開始 RFS[6]: Begin archive primary thread 2 sequence 66 (osaka1) Primary database is in MAXIMUM PERFORMANCE mode RFS[6]: Successfully opened standby log 13: '+REDO2/osaka/st_redo13.log' - 23 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ## thread #1 sequence#97 の REDO ログ ## thread #2 sequence#66 の REDO ログの適用開始 Media Recovery Waiting for thread 1 sequence 97 (in transit) Recovery of Online Redo Log: Thread 1 Group 9 Seq 97 Reading mem 0 Mem# 0: +REDO1/osaka/st_redo09.log Media Recovery Waiting for thread 2 sequence 66 (in transit) Recovery of Online Redo Log: Thread 2 Group 13 Seq 66 Reading mem 0 Mem# 0: +REDO2/osaka/st_redo13.log 7.2 リアルタイム・クエリー停止手順 リアルタイム・クエリーを停止し再度 mount 状態で REDO 適用を行いたい場合は、一旦スタ ンバイ・データベースを停止してから mount モードで再起動させる必要があります。 7.2.1 管理リカバリモードの停止 管理リカバリモードを停止します。 SQL> alter database recover managed standby database cancel; 7.2.2 データベースの停止 読み取り専用で open している状態から mount 状態へ変更するためには一旦スタンバイ・デー タベースを shutdown させる必要があります。 実行例： $ srvctl stop database –d osaka 7.2.3 データベースを mount で再起動 スタンバイ・データベースを mount モードで再起動させます。 実行例： $ srvctl start database –d osaka –o mount 7.2.4 管理リカバリモードの開始 管理リカバリモードを開始します。 SQL> alter database recover managed standby database using current logfile 2 disconnect from session; - 24 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ８ スナップショット・スタンバイ変更手順 本項ではフィジカル・スタンバイから Oracle Database 11g Release 1 の新機能であるスナッ プショット・スタンバイへの変更手順およびスナップショット・スタンバイからフィジカル・ス タンバイへの変更手順を紹介します。 スナップショット・スタンバイの機能を使用するためにはフラッシュバック・データベースの 機能が有効になっている必要があります。フラッシュバック・データベースの設定については｢6.6 フラッシュバック・データベースの構成｣を参照してください。 8.1 フィジカル・スタンバイからスナップショット・スタンバイへの 変更手順 8.1.1 管理リカバリモードの停止 フィジカル・スタンバイ・データベースで管理リカバリモードが開始している場合は管理リカ バリモードを停止します。 SQL> alter database recover managed standby database cancel; 8.1.2 スナップショット・スタンバイ・ロールへ変更 フィジカル・スタンバイ・ロールからスナップショット・スタンバイ・ロールへ変更します。 SQL> alter database convert to snapshot standby; (RAC 環境固有手順) RAC 環境の場合スナップショット・スタンバイ・ロールへの変更を実行するインスタンス以外 のインスタンスは停止している必要があります。事前に１インスタンスを除いてインスタンスを 停止してください。 複数インスタンスが起動している状態でスナップショット・スタンバイ・ロールへの変更を実行 するとエラーとなります。 SQL> alter database convert to snapshot standby; 行 1 でエラーが発生しました。: ORA-38777: 他のインスタンスでデータベースを起動しないでください。 以下はスナップショット・スタンバイ・ロールへ変更時のスタンバイ・データベースのアラート ログ出力例となります。 スタンバイ・データベースアラートログ出力例： ##ロール変更実行 Mon Jan 21 15:33:52 2008 alter database convert to snapshot standby ##リストアポイントの作成 Mon Jan 21 15:33:52 2008 - 25 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_01/21/2008 15:33:52 tkcrrxms: Killing 4 processes (all RFS) #フィジカル・スタンバイ・データベースのアクティブ化を開始 RESETLOGS after incomplete recovery UNTIL CHANGE 378638462 Resetting resetlogs activation ID 1481216091 (0x5849905b) Online log +REDO1/osaka/redo01.log: Thread 1 Group 1 was previously cleared Online log +REDO1/osaka/redo02.log: Thread 1 Group 2 was previously cleared Online log +REDO1/osaka/redo03.log: Thread 1 Group 3 was previously cleared Online log +REDO2/osaka/redo04.log: Thread 2 Group 4 was previously cleared Online log +REDO2/osaka/redo05.log: Thread 2 Group 5 was previously cleared Online log +REDO2/osaka/redo06.log: Thread 2 Group 6 was previously cleared #ロール変更完了 Standby became primary SCN: 378638460 Mon Jan 21 15:33:54 2008 Setting recovery target incarnation to 89 Converting standby mount to primary mount. ACTIVATE STANDBY: Complete - Database mounted as primary (osaka1) ALTER DATABASE CONVERT TO SNAPSHOT STANDBY: Complete (osaka1) Completed: alter database convert to snapshot standby 8.1.3 データベースの停止 ロール変更実行後は dismount 状態となり、そのままの状態から mount および open すること ができないため、一旦データベースを停止します。 実行例： $ srvctl stop database –d osaka 8.1.4 データベースの起動 データベースを read/write モードでオープンします。 実行例： $ srvctl start database –d osaka –o open 8.1.5 ステータス確認 正常にスナップショット・スタンバイへの変更が完了できているかステータスを確認します。 v$database を問い合わせ database_role 列が”SNAPSHOT STANDBY”となっており、且つ open_mode 列が”READ WRITE”となっていることを確認します。 SQL> select database_role,open_mode from v$database; 実行例： SQL> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE --------------------------------- --------------------- 26 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved SNAPSHOT STANDBY READ WRITE スナップショット・スタンバイ・データベース・ロールで起動したスタンバイ・データベースは、 read/write モードで起動されており、テスト用途等で使用することが可能です。 8.2 スナップショット・スタンバイからフィジカル・スタンバイへの 変更手順 スナップショット・スタンバイからフィジカル・スタンバイ・データベースへ戻す手順を紹介 します。 8.2.1 データベースの停止 スナップショット・スタンバイ・ロールのデータベースが open している場合は停止します。 実行例： $ srvctl stop database –d osaka フィジカル・スタンバイ・ロールへの変更は mount 状態で実行する必要があります。open 状 態で変更を実行しようとするとエラーとなります。 SQL> alter database convert to physical standby; 行 1 でエラーが発生しました。: ORA-01126: データベースはこのインスタンスでマウントし、 どのインスタンスでもオープンしないでください 8.2.2 データベースを mount モードで起動 データベースを mount モードで起動します。RAC 環境の場合は処理を実行する 1 インスタン ス以外は停止させておく必要があります。 実行例： $ srvctl start instance –d osaka –i osaka1 –o mount 8.2.3 フィジカル・スタンバイ・ロールへ変更 スナップショット・スタンバイ・ロールからフィジカル・スタンバイ・ロールへ変更します。 SQL> alter database convert to physical standby; 以下はフィジカル・スタンバイ・データベースへの変更を実施した際のスタンバイ・データベー スのアラートログ出力例となります。 スタンバイ・データベースアラートログ出力： ##ロール変更実行 Mon Jan 21 16:21:11 2008 alter database convert to physical standby - 27 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ALTER DATABASE CONVERT TO PHYSICAL STANDBY (osaka1) ##フラッシュバック・データベースの実行 Mon Jan 21 16:21:11 2008 Flashback Restore Start Flashback Restore Complete ##リストアポイントの削除 Guaranteed restore point dropped The primary database controlfile was created using the 'MAXLOGFILES 192' clause. There is space for up to 186 standby redo logfiles Use the following SQL commands on the standby database to create standby redo logfiles that match the primary database: ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 0; ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 0; ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 0; ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 0; ALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 0; ALTER DATABASE ADD STANDBY LOGFILE 'srl6.f' SIZE 0; ALTER DATABASE ADD STANDBY LOGFILE 'srl7.f' SIZE 0; Setting recovery target incarnation to 88 #ロール変更完了 Completed: alter database convert to physical standby 8.2.4 データベースの停止 ロール変更実行後は dismount 状態となり、そのままの状態から mount および open すること ができないため、一旦データベースを停止します。 実行例： $ srvctl stop database –d osaka 8.2.5 データベースの起動 フィジカル・スタンバイ・ロールでスタンバイ・データベースを起動します。 実行例： $ srvctl start database –d osaka –o mount もしくは $ srvctl start database –d osaka –o open 8.2.6 ステータス確認 項番 8.1.5 と同様に v$database を問い合わせ database_role 列が” PHYSICAL STANDBY”と なっていることを確認します。また項番 8.2.5 にてデータベースを起動している場合は、 open_mode 列が”READ ONLY”となっていることを確認します。 - 28 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved SQL> select database_role,open_mode from v$database; 実行例： SQL> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE -------------------------------- -------------------PHYSICAL STANDBY READ ONLY 8.2.7 管理リカバリモードの開始 管理リカバリモードを開始し、REDO ログの適用を実施することでスナップショット・スタン バイとなっていた間の変更を反映させます。 SQL> alter database recover managed standby database using current logfile 2 disconnect from session; - 29 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ９ スイッチオーバー/スイッチバック 手順 Oracle Data Guard 環境ではスイッチオーバーを実行することで、プライマリ・データベース とスタンバイ・データベースの同期を取り、ロールの変更を行うことが可能です。スイッチオー バーはメンテナンス等の計画停止時に使用します。 本項では一般的なスイッチオーバー、スイッチバックの実行手順を紹介します。 (本項ではプライマリ、スタンバイ両データベース・サーバーでコマンド、SQL 文を実施する必 要があります。またロールの変更も発生するため、実行コマンド、SQL 文に関しては例として使 用している環境の DB_UNIQUE_NAME(=TOKYO or OSAKA)を用いて、どちらのデータベー ス・サーバーで実行すべきコマンド、SQL 文であるかを明示します。スイッチオーバー実行前の 状態は、TOKYO=プライマリ・ロール、OSAKA=スタンバイ・ロールとします。) 9.1 スイッチオーバー手順 スイッチオーバーは以下の流れで実行します。 9.1.1 1 ノードを除いてインスタンスを停止 9.1.2 プライマリ・データベースをフィジカル・スタンバイ・ロールへ変更 9.1.3 旧プライマリ・インスタンスの停止 9.1.4 旧プライマリ・インスタンスの起動 9.1.5 スタンバイ・データベースにてステータス確認 9.1.6 スタンバイ・データベースをプライマリ・ロールへ変更 9.1.7 新プライマリ・データベースのステータス確認 9.1.8 新プライマリ・データベースの open 9.1.9 MRP プロセスの起動 9.1.10 Redo 転送確認 (手順 9.1.3 と 9.1.4 は、手順 9.1.8 の後に行うことも可能です。このようにするとプライマリ・ データベースのダウンタイムを最小化できます) 9.1.1 1 ノードを除いてインスタンスを停止(RAC 固有手順) RAC 環境ではスイッチオーバー実行前にプライマリ・データベース、スタンバイ・データベ ース共に 1 ノードを除いてインスタンスを停止する必要があります。 実行例(TOKYO 側で実行)： $ srvctl stop instance –d tokyo –i tokyo2 –o immediate 実行例(OSAKA 側で実行)： $ srvctl stop instance –d osaka –i osaka2 –o immediate 9.1.2 プライマリ・データベースをフィジカル・スタンバイ・ロールへ変更 プライマリ・データベースをフィジカル・スタンバイ・ロールへ変更します。 TOKYO 側で実行： SQL> alter database commit to switchover to physical standby with session shutdown; ・with session shutdown： - 30 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved スイッチオーバー実行時にプライマリ・データベースにアクティブなセッションが残っていた 場合、そのセッションを切断しロール変更処理を継続させます。with session shutdown の 指定なしで実行時にアクティブなセッションが残っていた場合、アクティブなセッションが なくなるまでロール変更処理が待機されます。 (RAC 環境下では CRS からの状態監視に使用されている racgimon のセッションが常に存在 しているため with session shutdown なしで実行するとロール変更が待機状態となりロール 変更処理が完了しません。racgimon は停止することができないため、RAC 環境下で スイッチオーバーを実行する際は with session shutdown オプションが必須となります) 以下はプライマリ・データベースでフィジカル・スタンバイ・ロールへの変更を実行した際のア ラートログの出力例です。 TOKYO(プライマリ)側のアラートログ出力例： ##SQL 文の実行 Mon Jan 21 18:23:24 2008 alter database commit to switchover to physical standby with session shutdown ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY (tokyo1) ・・省略・・ ##アクティブセッションの切断(with session shutdown オプションによる動作) Active process 21164 user 'oracle' program 'oracle@tokyo1 (TNS V1-V3)' Active process 18190 user 'oracle' program 'oracle@tokyo1 (TNS V1-V3)' Active process 8694 user 'oracle' program 'oracle@tokyo1 (TNS V1-V3)' Active process 8590 user 'oracle' program 'oracle@tokyo1 (TNS V1-V3)' CLOSE: all sessions shutdown successfully. ・・省略・・ ## sequence#114 のアーカイブ REDO ログ・ファイルに End-Of-Redo マーカーをつけて出力 ## スタンバイ・データベースへ送信 Thread 1 closed at log sequence 114 Successful close of redo thread 1 ARCH: Noswitch archival of thread 1, sequence 114 ARCH: End-Of-Redo Branch archival of thread 1 sequence 114 ARCH: Evaluating archive log 2 thread 1 sequence 114 ARCH: Beginning to archive thread 1 sequence 114 (378669124-Infinity) (tokyo1) ARCH: Creating remote archive destination LOG_ARCHIVE_DEST_2: 'osaka' (thread 1 sequence 114) (tokyo1) ARCH: Transmitting activation ID 0x5856024d OCISessionBegin with PasswordVerifierSYS succeeded Client pid [31825] attached to RFS pid [19164] at remote instance number [1] at dest 'osaka' ARCH: Creating local archive destination LOG_ARCHIVE_DEST_1: '+ARCH_FLASHBACK' (thread 1 sequence 114) ・・省略・・ ##プライマリ・データベースで MRP プロセスが起動しリカバリが実行される Mon Jan 21 18:23:57 2008 MRP0 started with pid=29, OS id=1825 - 31 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved MRP0: Background Managed Standby Recovery process started (tokyo1) Fast Parallel Media Recovery NOT enabled Mon Jan 21 18:24:02 2008 Managed Standby Recovery not using Real Time Apply ・・省略・・ ##MRP プロセスが停止しスイッチオーバーが完了 Media Recovery End-Of-Redo indicator encountered Media Recovery Applied until change 378669139 MRP0: Media Recovery Complete: End-Of-REDO (tokyo1) MRP0: Background Media Recovery process shutdown (tokyo1) Mon Jan 21 18:24:03 2008 Switchover: Complete - Database shutdown required (tokyo1) Completed: alter database commit to switchover to physical standby with session shutdown 以下は同じタイミングでスタンバイ・データベースのアラートログ出力例です。 OSAKA(スタンバイ)側のアラートログ出力例： ##End-Of-Redo マーカーのついた sequence#114 のアーカイブ REDO ログ・ファイルを受信 Mon Jan 21 18:23:54 2008 Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[9]: Assigned to RFS process 19164 RFS[9]: Identified database type as 'physical standby' RFS[9]: End-Of-Redo archival of thread 1 sequence 114 RFS[9]: Begin archive primary thread 1 sequence 114 (osaka1) RFS[9]: Completed archive primary log 2 thread 1 sequence 114 (osaka1) ・・省略・・ ##End-Of-Redo マーカーのついたアーカイブ REDO ログ・ファイルを適用し MRP プロセスが 停止 Identified End-Of-Redo for thread 1 sequence 114 Resetting standby activation ID 1482031693 (0x5856024d) Media Recovery End-Of-Redo indicator encountered Media Recovery Applied until change 378669139 MRP0: Media Recovery Complete: End-Of-REDO (osaka1) MRP0: Background Media Recovery process shutdown (osaka1) 9.1.3 旧プライマリインスタンスの停止 旧プライマリ・データベースでのロール変更完了後、インスタンスは nomount 状態となって おりそのまま mount および open することができないため、インスタンスを停止します。 実行例(TOKYO 側で実行)： $ srvctl stop database –d tokyo 9.1.4 旧プライマリインスタンスの起動 - 32 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 旧プライマリ・データベースを起動します。(mount もしくは open) 実行例(TOKYO 側で実行)： $ srvctl start database -d tokyo -o mount もしくは $ srvctl start database -d tokyo -o open 9.1.5 スタンバイ・データベースにてステータス確認 スタンバイ・データベースでスイッチオーバーが可能な状態であることを確認します。下記 SQL 文を実行した結果、switchover_status が“TO PRIMARY”と出力されていればスイッチ オーバー可能です。 OSAKA 側で実行： SQL> select switchover_status from v$database; 実行例： SQL> select switchover_status from v$database; SWITCHOVER_STATUS ---------------------------------TO PRIMARY スタンバイ・データベースで管理リカバリモードが開始されていない等、未適用の REDO ログ がある場合は、switchover_status が”TO PRIMARY”以外の出力となります。この場合は全ての REDO ログの適用が完了するまでスイッチオーバーを実行できません。未適用の REDO がある 場合は管理リカバリモードを開始し適用を行う必要があります。 (以下は未適用の REDO ログがある場合の switchover_status の出力の一例です) SQL> select switchover_status from v$database; SWITCHOVER_STATUS ------------------------------------SWITCHOVER PENDING SQL> alter database recover managed standby database disconnect from session; 9.1.6 スタンバイ・データベースをプライマリ・ロールへ変更 フィジカル・スタンバイ・データベースをプライマリ・ロールへ変更します。 OSAKA 側で実行： SQL> alter database commit to switchover to primary; 以下はプライマリ・ロールへロール変更を実施した際のスタンバイ・データベース側のアラート ログの出力例となります。 - 33 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved OSAKA(スタンバイ)側のアラートログ出力例： ##SQL 文実行 Mon Jan 21 18:28:28 2008 alter database commit to switchover to primary ALTER DATABASE SWITCHOVER TO PRIMARY (osaka1) ・・省略・・ ##フィジカル・スタンバイ・データベースのアクティブ化を開始 Online log +REDO1/osaka/redo01.log: Thread 1 Group 1 was previously cleared Online log +REDO1/osaka/redo02.log: Thread 1 Group 2 was previously cleared Online log +REDO1/osaka/redo03.log: Thread 1 Group 3 was previously cleared Online log +REDO2/osaka/redo04.log: Thread 2 Group 4 was previously cleared Online log +REDO2/osaka/redo05.log: Thread 2 Group 5 was previously cleared Online log +REDO2/osaka/redo06.log: Thread 2 Group 6 was previously cleared ##スイッチオーバーの完了 Standby became primary SCN: 378669137 Converting standby mount to primary mount. Switchover: Complete - Database mounted as primary (osaka1) Completed: alter database commit to switchover to primary 9.1.7 新プライマリ・データベースのステータス確認 新プライマリ・データベースのステータスを確認します。下記 SQL 文を実行し、新プライマリ・ データベースのロールが”PRIMARY”となっていることを確認します。 OSAKA 側で実行： SQL> select database_role from v$database; 実行例： SQL> select database_role from v$database; DATABASE_ROLE --------------------------PRIMARY 9.1.8 新プライマリ・データベースの open ロール変更実施後はインスタンスが mount 状態となっているため、open させる必要がありま す。 OSAKA 側で実行： SQL> alter database open; 9.1.9 管理リカバリモードの開始 新スタンバイ・データベースにて管理リカバリモードを開始し REDO 適用を開始します。 TOKYO 側で実行： - 34 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved SQL> alter database recover managed standby database using current logfile 2 disconnect from session; 以下は管理リカバリモードを開始した際の新スタンバイ・データベースでのアラートログ出力例 となります。 TOKYO(新スタンバイ)側のアラートログ出力： ##SQL 文実行 Mon Jan 21 18:34:35 2008 alter database recover managed standby database using current logfile disconnect Attempt to start background Managed Standby Recovery process (tokyo1) ##MRP プロセスの起動 Mon Jan 21 18:34:35 2008 MRP0 started with pid=41, OS id=7929 MRP0: Background Managed Standby Recovery process started (tokyo1) Fast Parallel Media Recovery enabled Mon Jan 21 18:34:40 2008 Managed Standby Recovery starting Real Time Apply ・・省略・・ ##REDO ログ・ファイルのクリア処理を実施 ##全ての REDO ログ・ファイルの数だけ実施されます Clearing online redo logfile 1 +REDO1/tokyo/redo01.log Clearing online log 1 of thread 1 sequence number 113 Mon Jan 21 18:35:55 2008 Clearing online redo logfile 1 complete ・・省略・・ ##全ての REDO ログ・ファイルのクリア処理が終了後 MRP プロセスによる ##REDO 適用が開始される Mon Jan 21 18:49:51 2008 Media Recovery Log +ARCH_FLASHBACK/tokyo/archivelog/2008_01_21/ thread_1_seq_116.1702.644611783 Media Recovery Log +ARCH_FLASHBACK/tokyo/archivelog/2008_01_21/ thread_2_seq_79.1705.644610819 Media Recovery Log +ARCH_FLASHBACK/tokyo/archivelog/2008_01_21/ thread_2_seq_80.1703.644611779 Media Recovery Waiting for thread 2 sequence 81 (in transit) Recovery of Online Redo Log: Thread 2 Group 13 Seq 81 Reading mem 0 Mem# 0: +REDO2/tokyo/st_redo13.log Media Recovery Waiting for thread 1 sequence 117 (in transit) Recovery of Online Redo Log: Thread 1 Group 10 Seq 117 Reading mem 0 Mem# 0: +REDO1/tokyo/st_redo10.log 9.1.10 Redo 転送確認 項番 6.5 と同様の手順を実施し REDO ログ・ファイルがスタンバイ・データベースへ正常に 転送、適用されていることを確認し、Oracle Data Guard 構成が正常な状態であることを確認し ます。 - 35 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 9.2 スイッチバック手順 スイッチバックとはスイッチオーバーを実行して変更したロールを元に戻す操作を指します。 スイッチオーバーと同様の手順でロールの変更を行います。スイッチオーバー実行時とはロール が入れ替わっている点を注意して実行してください。 - 36 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved １０ フェイルオーバー/フェイルバック 手順 プライマリ・データベースに障害が発生した場合 Oracle Data Guard 環境ではプライマリ・デ ータベースを切り離し、スタンバイ・データベースを新たなプライマリ・データベースとするこ とができます。 本項では一般的なフェイルオーバー、フェイルバックの実行手順を紹介します。 (本項ではプライマリ、スタンバイ両データベースでコマンド、SQL 文を実施する必要がありま す。またロールの変更も発生するため、実行コマンド、SQL 文に関しては例として使用している 環境の DB_UNIQUE_NAME(=TOKYO or OSAKA)を用いて、どちらのデータベースで実行すべ きコマンド、SQL 文であるかを明示します。フェイルオーバー実行前の状態は、TOKYO=プラ イマリ・ロール、OSAKA=スタンバイ・ロールとします。) 10.1 フェイルオーバー手順 フェイルオーバーは以下の流れで実行します。 10.1.1 10.1.2 10.1.3 10.1.4 10.1.5 10.1.6 10.1.7 10.1.8 アーカイブ REDO ログ・ファイルの GAP 確認 欠落しているアーカイブ REDO ログ・ファイルのコピー アーカイブ REDO ログ・ファイルの登録 REDO 適用と管理リカバリの停止 1 ノードを除いてインスタンスを停止 スタンバイ・データベースをプライマリ・データベースへ変更 新プライマリ・データベースのステータス確認 新プライマリ・データベースの open 10.1.1 アーカイブ REDO ログ・ファイルの GAP 確認 スタンバイ・データベースで下記 SQL を実行しアーカイブ REDO ログ・ファイルの GAP が 存在するかを確認します。GAP が存在しない場合は項番 10.1.4 の手順へ進みます。 OSAKA 側で実行： SQL>select thread#,low_sequence#,high_sequence# from v$archive_gap; 10.1.2 欠落しているアーカイブ REDO ログ・ファイルのコピー スタンバイ・データベースで欠落しているアーカイブ REDO ログ・ファイルをプライマリ・デ ータベースからコピーします。 10.1.3 アーカイブ REDO ログ・ファイルの登録 欠落しているアーカイブ REDO ログ・ファイルをスタンバイ・データベース上で登録する必要 があります。 OSAKA 側で実行： SQL> alter database register physical logfile ‘<アーカイブ REDO ログ・ファイル名>’; 項番 10.1.1 から項番 10.1.3 の手順をアーカイブ REDO ログ・ファイルの GAP が存在しなくな るまで繰り返し実行します。 - 37 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 10.1.4 REDO 適用と管理リカバリモードの停止 現在スタンバイ・データベースで受信している REDO ログ・ファイルを全て適用し管理リカバ リモードを停止します。この操作を行うと受信できていない REDO ログ・ファイルに含まれる更 新データの損失が発生します。 OSAKA 側で実行： SQL> alter database recover managed standby database finish force; ・force： force オプションを付与することでスタンバイ・データベース上のアクティブな RFS プロセ スを終了します。force オプションは Oracle Database 10g Release 2 での追加機能ですが、 Oracle Database 11g Release 1 では省略可能です。 以下は上記 SQL 文を実行した際のスタンバイ・データベースのアラートログ出力例となります。 OSAKA(スタンバイ)側のアラートログ出力例： ##SQL 文実行 alter database recover managed standby database finish force Terminal Recovery: Stopping real time apply ・・省略・・ ## thread#2 sequence#4 のアーカイブ REDO ログ・ファイルと thread#1 sequence#7 の ## アーカイブ REDO ログ・ファイルに End-Of-Redo マーカーをつけ、その時点までの ## リカバリを実行 Media Recovery Start: Managed Standby Recovery (osaka1) Fast Parallel Media Recovery enabled Tue Oct 30 17:03:52 2007 Managed Standby Recovery not using Real Time Apply parallel recovery started with 3 processes Terminal Recovery timestamp is '10/30/2007 17:03:54' Terminal Recovery: applying standby redo logs. Terminal Recovery: thread 2 seq# 4 redo required Terminal Recovery: Recovery of Online Redo Log: Thread 2 Group 14 Seq 4 Reading mem 0 Mem# 0: +REDO2/osaka/st_redo14.log Identified End-Of-Redo for thread 2 sequence 4 Terminal Recovery: thread 1 seq# 7 redo required Terminal Recovery: Recovery of Online Redo Log: Thread 1 Group 10 Seq 7 Reading mem 0 Mem# 0: +REDO1/osaka/st_redo10.log Identified End-Of-Redo for thread 1 sequence 7 Incomplete recovery applied all redo ever generated. Recovery completed through change 94726893 time 10/30/2007 16:55:14 Media Recovery Complete (osaka1) Terminal recovery recovered to last consistent point in redo stream But it did not apply all redo; some data may be lost Terminal Recovery: successful completion Resetting standby activation ID 1474839234 (0x57e842c2) - 38 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 10.1.5 1 ノードを除いてインスタンスを停止(RAC 環境固有手順) RAC 環境ではフェイルオーバー実行前に 1 ノードを除いてインスタンスを停止する必要があ ります。 実行例(OSAKA 側で実行)： $ srvctl stop instance –d osaka –i osaka2 –o immediate 10.1.6 スタンバイ・データベースをプライマリ・データベースへ変更 スタンバイ・データベースをプライマリ・データベースへと変更します。 OSAKA 側で実行： SQL> alter database commit to switchover to primary; 以下はプライマリ・ロールへロール変更を実行した際のスタンバイ・データベースのアラートロ グ出力例となります。 OSAKA(スタンバイ)側のアラートログ出力例： ##SQL 文実行 Tue Oct 30 17:13:33 2007 alter database commit to switchover to primary ALTER DATABASE SWITCHOVER TO PRIMARY (osaka1) Maximum wait for role transition is 15 minutes. ・・省略・・ ##フィジカル・スタンバイ・データベースのアクティブ化を開始 RESETLOGS after complete recovery through change 94726893 Online log +REDO1/osaka/redo01.log: Thread 1 Group 1 was previously cleared Online log +REDO1/osaka/redo02.log: Thread 1 Group 2 was previously cleared Online log +REDO1/osaka/redo03.log: Thread 1 Group 3 was previously cleared Online log +REDO2/osaka/redo04.log: Thread 2 Group 4 was previously cleared Online log +REDO2/osaka/redo05.log: Thread 2 Group 5 was previously cleared Online log +REDO2/osaka/redo06.log: Thread 2 Group 6 was previously cleared Standby became primary SCN: 94726871 ##ロール変更完了 Tue Oct 30 17:13:39 2007 Setting recovery target incarnation to 21 Converting standby mount to primary mount. Switchover: Complete - Database mounted as primary (osaka1) Completed: alter database commit to switchover to primary 10.1.7 新プライマリ・データベースのステータス確認 新プライマリ・データベースのステータスを確認します。下記 SQL 文を実行し、新プライマリ・ データベースのロールが”PRIMARY”となっていることを確認します。 OSAKA 側で実行： - 39 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved SQL> select database_role from v$database; 実行例： SQL> select database_role from v$database; DATABASE_ROLE --------------------------PRIMARY 10.1.8 新プライマリ・データベースの open 新しいプライマリ・データベースを open します。フェイルオーバー実施後はインスタンスが mount 状態となっているため、open させる必要があります。また RAC 環境の場合、停止してい た他のインスタンスも起動させます。 実行例(OSAKA 側で実行)： SQL> alter database open; $ srvctl start instance -d osaka -i osaka2 -o open 10.2 フェイルバック手順 フェイルオーバー実行後は、新プライマリ・データベースに対するスタンバイ・データベース が存在しない状態となっているため、ロールを元の状態に戻すためには旧プライマリ・データベ ースを復旧後、再度同期が取れた Oracle Data Guard 構成を構築する必要があります。旧プラ イマリ・データベースを復旧する手段は、旧プライマリ・データベースの障害の状況やバックア ップの有無等により影響されるため、状況に応じて手順を選択する必要があります。 新プライマリ・データベースが正常に動作している状況であれば、構築時と同様の手順を用い て新プライマリ・データベースからフィジカル・スタンバイ・データベースを作成し、Oracle Data Guard 構成を構築することが可能です。 今回は以下の条件を満たしている状況での旧プライマリ・データベースの復旧手順を紹介しま す。 (1) 旧プライマリ・データベースが正常に mount 可能である (2) 旧スタンバイ・データベースと通信可能である (3) フラッシュバック・データベース機能が有効となっている 10.2.1 新プライマリ・データベースがプライマリ・ロールになった SCN の確認 新プライマリ・データベースでスイッチオーバーを実行しプライマリ・ロールに変更された SCN を確認します。 OSAKA 側で実行： SQL> select to_char(standby_became_primary_scn) from v$database; 実行例： SQL> select to_char(standby_became_primary_scn) from v$database; - 40 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) -----------------------------------------------------------------------7257191 10.2.2 旧プライマリ・データベースの起動 旧プライマリ・データベースを mount モードで起動します。 RAC 環境の場合後続の処理を実施する際は 1 ノードを除いて停止している必要があるため、1 ノ ードのみ起動させます。 実行例(TOKYO 側で実行)： $ srvctl start instance -d tokyo -i tokyo1 -o mount 10.2.3 旧プライマリ・データベースでフラッシュバック・データベースを実行 旧プライマリ・データベースでフラッシュバック・データベースを実行します。フラッシュバ ックするポイントには 10.2.1 で確認した SCN を指定します。 TOKYO 側で実行： SQL> flashback database to scn <ロール変更時の SCN>; 実行例： SQL> flashback database to scn 7257191; 10.2.4 プライマリ・ロールからフィジカル・スタンバイ・ロールへ変更 旧プライマリ・データベースをプライマリ・ロールからフィジカル・スタンバイ・ロールへ変 更します。 TOKYO 側で実行： SQL> alter database convert to physical standby; 10.2.5 旧プライマリ・データベースの停止 フィジカル・スタンバイ・ロールへのロール変更の実行が完了後、インスタンスは nomount 状 態となっています。そのまま mount および open することができないため、インスタンスを停止 します。 実行例(TOKYO 側で実行)： $ srvctl stop database -d tokyo 10.2.6 旧プライマリ・データベースの起動 旧プライマリ・データベースを起動します。(mount もしくは open) 実行例(TOKYO 側で実行)： $ srvctl start database -d tokyo -o mount - 41 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved もしくは $ srvctl start database -d tokyo -o open 10.2.7 管理リカバリモードの開始 新スタンバイ・データベースにて管理リカバリモードを開始し REDO 適用を開始します。 TOKYO 側で実行： SQL> alter database recover managed standby database using current logfile 2 through last switchover disconnect from session; ・through last swithover： フェイルオーバー後、新スタンバイ・データベースにて MRP を初めて起動した際、上記 オプションを付与せずコマンドを実行すると、フェイルオーバー時の End-Of-Redo マーカー がつけられた REDO ログを適用した時点で MRP プロセスが停止します。REDO ログ適用を 継続するには、再度 MRP プロセスを起動する必要があります。 through last switchover オプションを付与することで この工程を短縮することが可能にな り、End-Of-Redo マーカーがつけられた REDO ログを適用後も MRP プロセスが起動した 状態となります。 10.2.8 REDO 転送確認 項番 6.5 と同様の手順を実施し REDO ログ・ファイルがスタンバイ・データベースへ正常に 転送、適用されていることを確認し、Oracle Data Guard 構成が正常な状態であることを確認し ます。 10.2.9 スイッチオーバーの実行 必要に応じて項番 9 と同様の手順でスイッチオーバーを実行しロールの変更を行います。 - 42 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved １１ Data Guard Broker の構成 Oracle Database 11g Release 1 ではファスト・スタート・フェイルオーバー(FSFO) の機能 も強化されました。本項ではファスト・スタート・フェイルオーバーを設定するために必要な Data Guard Broker の構成手順、ファスト・スタート・フェイルオーバーの設定手順、Data Guard Broker を使用した基本的な操作方法を紹介します。尚、本項では Data Guard Broker の構成管 理を行う手段としてコマンドラインインターフェイス(DGMGRL)を使用した手順を紹介します。 Oracle Data Guard 構成は前項までで使用していた環境をそのまま使用することを前提としてい ます。 11.1 Data Guard Broker の構成手順 ファスト・スタート・フェイルオーバーを使用するためには、プライマリ・データベース、ス タンバイ・データベースを管理するオブザーバを起動させる必要があります。オブザーバはプラ イマリ・データベース・サーバーおよびスタンバイ・データベース・サーバーとは別のマシンに て動作させることが推奨されます。本書では、プライマリ・データベース・サーバー、スタンバ イ・データベース・サーバーとは別に監視用のマシンを用意し、オブザーバを起動させ Oracle Data Guard 構成の監視をさせます。(以降の手順では監視用に用意したマシンをオブザーバマシ ンと呼ぶことします。) 11.1.1 Oracle Client のインストール コマンドラインインターフェイス(以下 DGMGRL)を使用するために、オブザーバマシンに Oracle Client ソフトウェアをインストールします。Oracle Universal Installer を起動し、イン ストールタイプの｢Administrator｣オプションを選択して Oracle Client ソフトウェアをインス トールします。インストール後 DGMGRL が使用可能となります。 11.1.2 初期化パラメータの設定 Oracle Data Guard 環境にて Broker の構成に必要な初期化パラメータを設定します。 Data Guard Broker を使用するためにはプライマリ、スタンバイの各データベースで spfile を使 用している必要があります。spfile ではなく pfile を指定している場合は項番 6.2.5 の流れを参考 に spfile を作成してください。 Broker の構成に必要な初期化パラメータは以下の通りです。 (1)DG_BROKER_CONFIG_FILE1 (2)DG_BROKER_CONFIG_FILE2 Data Guard Broker 構成ファイルの格納先を指定します。このパラメータを設定後 Broker の 初回起動時に指定したパスに Data Guard Broker 構成ファイルが作成されます。パラメータの指 定には以下の注意事項があります。 ・このパラメータは初期化パラメータ DG_BROKER_START が FALSE に設定されている 場合のみ設定、変更することが可能です。DG_BROKER_START が TRUE となっている 場合は、先に DG_BROKER_START の値を FALSE に変更する必要があります。 ・RAC 環境の場合、各インスタンスで同一の値に設定する必要があります。 ・RAC 環境の場合、Broker の構成ファイルは全てのインスタンスからアクセス可能な場所に - 43 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 配置する必要があります。 DG_BROKER_CONFIG_FILE1、DG_BROKER_CONFIG_FILE2 は alter system 文で変更可 能です。DG_BROKER_START が TRUE となっている場合は FALSE に変更後、パラメータの 変更を実施します。 両データベースにて実行： SQL> alter system set dg_broker_start=false; SQL> alter system set dg_broker_config_file1=<構成ファイルパス>; SQL> alter system set dg_broker_config_file2=<構成ファイルパス>; 実行例(プライマリ・データベースで実行)： SQL>alter system set dg_broker_config_file1='+DATA/TOKYO/dgtokyo1.dat'; SQL>alter system set dg_broker_config_file2='+DATA/TOKYO/dgtokyo2.dat'; 実行例(スタンバイ・データベースで実行)： SQL>alter system set dg_broker_config_file1='+DATA/OSAKA/dgosaka1.dat'; SQL>alter system set dg_broker_config_file2='+DATA/OSAKA/dgosaka2.dat'; (3)DG_BROKER_START Data Guard Broker の起動、停止を指定します。DG_BROKER_START=TRUE を指定すると Data Guard Broker が起動します。(指定したインスタンスで DMON プロセスが起動します) DG_BROKER_START は alter system 文で設定可能です。(1)、(2)の値を設定後、このパラメー タを TRUE に設定し Data Guard Broker を起動します。 両データベースで実行： SQL> alter system set dg_broker_start=true; 11.1.3 リスナーの設定 DGMGRL で操作中にオブザーバマシンからインスタンスを再起動できるようにするために、 プライマリ、スタンバイの各インスタンスのローカル・リスナーにサービスの静的構成を登録す る 必 要 が あ り ま す 。 各 イ ン ス タ ン ス の listene.ora の GLOBAL_DBNAME 属 性 の 値 を 、 dg_unique_name_DGMGRL.db_domain の形式とした値に設定します。この設定は全てのノー ドで実行する必要があります。 SID_LIST_LISTENER= (SID_LIST = (SID_DESC= (SID_NAME=<sid 名>) (GLOBAL_DBNAME=<db_unique_name>_DGMGRL.<db_domain>) (ORACLE_HOME=<ORACLE_HOME パス>) ) ) - 44 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved listener.ora 設定例： SID_LIST_LISTENER_TOKYO1= (SID_LIST= (SID_DESC= (SID_NAME=tokyo1) (GLOBAL_DBNAME=tokyo_DGMGRL) (ORACLE_HOME=/oracle/db/product/11.1.0/db_1) ) ) 11.1.4 オブザーバマシンのネットワーク設定 オブザーバマシンからプライマリ、スタンバイ両データベースに OracleNet 経由で接続できる 必要があります。オブザーバマシンで Oracle Net 接続の設定を行います。各データベースへの接 続情報は項番 6.2.2 で設定した接続情報を使用します。 tnsnames.ora 設定例： TOKYO = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = tokyo1-vip)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = tokyo2-vip)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = tokyo) ) ) OSAKA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = osaka1-vip)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = osaka2-vip)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = osaka) ) ) 12.1.5 DGMGRL の起動、接続 オブザーバマシンにて DGMGRL を起動します。オブザーバマシンにて dgmgrl と入力するこ とで DGMGRL が起動されます。DGMGRL 起動後はプライマリ・データベースへ接続を行いま す。 (1) DGMGRL の起動 $dgmgrl - 45 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 実行例： $dgmgrl DGMGRL for Linux: Version 11.1.0.6.0 - Production Copyright (c) 2000, 2005, Oracle. All rights reserved. DGMGRL へようこそ。詳細は"help"と入力してください。 DGMGRL> (2) プライマリ・データベースへ接続 DGMGRL> connect sys/<password>@<プライマリへの接続情報> 実行例： DGMGRL> connect sys/oracle@tokyo 接続されました。 DGMGRL> 11.1.6 Data Guard Broker 構成の作成 Data Guard Broker では管理する対象のデータベースを Data Guard Broker 構成と呼ばれる 単位で管理します。Data Guard Broker を起動した初期の状態では Broker 構成が存在しないた め、Broker 構成を作成します。本書では ‘hitachi’という名称の Broker 構成を作成します。 Broker 構成を作成するためには、プライマリ・データベースへ接続した状態で DGMGRL より create configuration コマンドを実行します。 DGMGRL> create configuration ‘<Broker 構成名>’ as primary database is > ‘<プライマリ・データベースの DB_UNIQUE_NAME>’ > connect identifier is <プライマリ・データベースへの接続情報>; 実行例： DGMGRL> create configuration 'hitachi' as primary database is 'tokyo' > connect identifier is tokyo; 構成"hitachi"が、プライマリ・データベース"tokyo"で作成されました 作成した Broker 構成情報は show configuration コマンドで確認可能です。Broker 構成が完了 後、show configuration コマンドで作成した Broker 構成が表示されることを確認してください。 DGMGRL> show configuration; 実行例： DGMGRL> show configuration; Configuration Name: Enabled: Protection Mode: hitachi NO MaxPerformance - 46 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved Databases: tokyo - Primary database Fast-Start Failover: DISABLED "hitachi"の現在のステータス: DISABLED 11.1.7 Broker 構成へのスタンバイ・データベースの追加 作成した Broker 構成へスタンバイ・データベースの情報を追加します。DGMGRL より add database コマンドを実行し、スタンバイ・データベースを追加します。 DGMGRL>add database ‘<スタンバイ・データベースの DB_UNIQUE_NAME>’ > connect identifier is <スタンバイ・データベースへの接続情報>; 実行例： DGMGRL> add database 'osaka' as connect identifier is osaka maintained as physical; データベース"osaka"が追加されました コマンド実行後、show configuration コマンドを使用して Broker 構成にスタンバイ・データ ベースが追加されていることを確認します。 実行例： DGMGRL> show configuration; Configuration Name: hitachi Enabled: NO Protection Mode: MaxPerformance Databases: tokyo - Primary database osaka - Physical standby database => スタンバイ・データベースが追加されている Fast-Start Failover: DISABLED "hitachi"の現在のステータス: DISABLED 11.1.8 Broker 構成の有効化 Broker 構成は作成した直後は無効な状態となっているため明示的に有効化する必要がありま す。DGMGRL より enable configuration コマンドを使用して Broker 構成を有効にします。 DGMGRL> enable configuration; 実行例： DGMGRL> enable configuration; 有効になりました。 - 47 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved コマンド実行後、show configuration コマンドを使用して Broker 構成が有効な状態となってい るか確認します。show configuration を実行して表示される情報内の Configuration の Enable の 部分が｢YES｣と表示されていること及び Broker 構成のステータスが｢SUCCESS｣と表示される ことを確認します。 実行例： DGMGRL> show configuration; Configuration Name: hitachi Enabled: YES => ｢YES｣と表示されている Protection Mode: MaxPerformance Databases: tokyo - Primary database osaka - Physical standby database Fast-Start Failover: DISABLED "hitachi"の現在のステータス: SUCCESS => ｢SUCCESS｣と表示されている 以上で Broker 構成の作成は完了です。Broker 構成の作成完了後は DGMGRL から Broker 構成 の設定変更やスイッチオーバー等の処理を実行することが可能です。 11.2 ファスト・スタート・フェイルオーバーの設定手順 ファスト・スタート・フェイルオーバーの設定を行うことで、プライマリ・データベースの障 害時に Data Guard Broker により、事前に選択したスタンバイ・データベースへ自動的にフェイ ルオーバーを実行することできます。本項ではファスト・スタート・フェイルオーバーの設定手 順を紹介します。 11.2.1 事前設定 ファスト・スタート・フェイルオーバーを使用するためには以下の条件を満たしている必要が あります。 1) Broker 構成が最大可用性モードまたは最大パフォーマンスモードで動作している 本書で構成している環境は最大パフォーマンスモードで稼動しています。本書と同一の手順、 設定で構成を実施した場合は上記条件は満たした状態で構成されています。 (最大可用性モードで動作させる場合の設定は、以下マニュアルを参照ください。 Oracle Data Guard 概要および管理 11g リリース 1 Oracle Data Guard Broker 11g リリース 1) 2)ファスト・スタート・フェイルオーバーのターゲットに選択したスタンバイ・データベース の LogXptMode の設定が保護モードに適した値(SYNC、ASYNC)に設定されており、プライ マリ・データベースにスタンバイ REDO ログ・ファイルが構成されている 本書で構成している環境は最大パフォーマンスモード、ASYNC で稼動しています。本書と 同一の手順、設定で構成した場合は上記条件は満たした状態で構成されています。 - 48 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved (異なる構成での設定変更手順等はマニュアルを参照ください) 3) プライマリ、スタンバイ両データベースでフラッシュバック・データベースが有効化されて おり、フラッシュ・リカバリ領域が設定されている 設定されていない場合は項番 6.6 を参照し設定を行ってください。 4) オブザーバマシンで DGMGRL が起動可能であり、プライマリ・スタンバイ両データベース に接続可能である 設定されていない場合は項番 11.1.1、11.1.4 を参照し設定を行ってください。 5) プライマリ、スタンバイ両データベース・サーバーのリスナーでサービスの静的構成を登録 し、オブザーバマシンより再起動が可能となっている 設定されていない場合は項番 11.1.3 を参照し設定を行ってください。 11.2.2 ファスト・スタート・フェイルオーバー先の登録 Broker 構成内に含まれるスタンバイ・データベースの中からフェイルオーバー先を選択し、タ ーゲットデータベースとして登録します。フェイルオーバー先の登録は DGMGRL より edit database コマンドを使用して実行することが可能です。 DGMGRL> edit database <プライマリ・データベースの DB_UNIQUE_NAME> > set property faststartfailovertarget=<スタンバイ・データベースの DB_UNIQUE_NAME>; 実行例： DGMGRL> edit database tokyo set property faststartfailovertarget=osaka; プロパティ"faststartfailovertarget"が更新されました また、ファスト・スタート・フェイルオーバー実行後のプライマリ・データベース(旧スタンバイ・ データベース)のフェイルオーバー先を選択し、ターゲットデータベースとして登録します。本書 の構成では旧スタンバイ・データベースのフェイルオーバー先として旧プライマリ・データベー スを指定します。 DGMGRL> edit database <スタンバイ・データベースの DB_UNIQUE_NAME> > set property faststartfailovertarget=<プライマリ・データベースの DB_UNIQUE_NAME>; 実行例： DGMGRL> edit database osaka set property faststartfailovertarget=tokyo; プロパティ"faststartfailovertarget"が更新されました 11.2.3 ファスト・スタート・フェイルオーバーの有効化 フェイルオーバー先を登録しただけではファスト・スタート・フェイルオーバーの設定は無効 となったままであるため、明示的に有効化する必要があります。DGMGRL より enable fast_start failover コマンドを実行してファスト・スタート・フェイルオーバーを有効化します。 DGMGRL>enable fast_start failover; - 49 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 実行例： DGMGRL> enable fast_start failover; 有効になりました。 ファスト・スタート・フェイルオーバーを有効後 show configuration コマンドを使用して Broker 構成の状態を確認し、Fast-Start Failover の部分が｢ENABLE｣となっていることを確認します。 実行例： DGMGRL> show configuration Configuration Name: hitachi Enabled: YES Protection Mode: MaxPerformance Databases: tokyo - Primary database osaka - Physical standby database - Fast-Start Failover target => フェイルオーバーのターゲットとして指定 されている Fast-Start Failover: ENABLED => ｢ENABLE｣となっている "hitachi"の現在のステータス: 警告: ORA-16608: 1 つ以上のデータベースに警告があります Broker 構成のステータスに警告が出力されていますが、これは次の手順で説明するオブザーバが 起動していないことが原因です。 11.2.4 オブザーバの起動 オブザーバマシン上でオブザーバを実行します。オブザーバを起動すると Broker 構成内のデ ータベースの状態がオブザーバにより監視されます。オブザーバを起動するためには DGMGRL より start observer コマンドを実行します。 (オブザーバの起動後は、ファスト・スタート・フェイルオーバーが発生する条件を満たすとフェ イルオーバーが発生することになります。オブザーバを起動する前に項番 11.3 の内容を確認し、 ファスト・スタート・フェイルオーバーの条件設定を確認してください。) DGMGRL> start observer; ＊start observer を実行するとオブザーバが起動されますが、start observer を実行したプロン プトは別のクライアント接続から stop observer が実行されオブザーバが停止されるまで制 御がユーザーに戻りません。オブザーバが起動した状態で DGMGRL を使用する場合は、別の クライアント接続から操作を実行する必要があります。 オブザーバの起動後 DGMGRL から show configuration を実行し、状態の確認を行います。 実行例： DGMGRL> show configuration Configuration - 50 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved Name: Enabled: hitachi YES => ｢YES｣と表示されている Protection Mode: MaxPerformance Databases: tokyo - Primary database osaka - Physical standby database - Fast-Start Failover target Fast-Start Failover: ENABLED => ｢ENABLE｣と表示されている "hitachi"の現在のステータス: SUCCESS => ｢SUCCESS｣と表示されている 以上でファスト・スタート・フェイルオーバーの設定は完了です。オブザーバマシンからプライ マリ・データベースへの通信が途切れる等、プライマリ・データベースでの障害を検知すると、 ファスト・スタート・フェイルオーバーが実行されます。 以下はプライマリ・データベースの全ノードを abort にて終了させ、ファスト・スタート・フェ イルオーバーが実行された際のオブザーバの画面出力例となります。 ファスト・スタート・フェイルオーバー時の出力例： 20:13:57.77 2007 年 12 月 14 日 金曜日 データベース"osaka"へのファスト・スタート・フェイルオーバーを開始しています... 現在フェイルオーバーを実行しています。お待ちください... フェイルオーバーに成功しました。新規プライマリは"osaka"です 20:15:07.61 2007 年 12 月 14 日 金曜日 ##フェイルオーバー完了後、旧プライマリ・データベースを mount させると自動的に ##再構成を実施しスタンバイ・データベースとして構成します 20:16:54.03 2007 年 12 月 14 日 金曜日 データベース"tokyo"の修復を開始しています... データベース"tokyo"を修復しています。お待ちください... 操作上、インスタンス"tokyo1" (データベース"tokyo") を停止する必要があります インスタンス"tokyo1"の停止中... ORA-01109: データベースがオープンされていません。 データベースがディスマウントされました。 ORACLE インスタンスがシャットダウンされました。 操作上、インスタンス"tokyo1" (データベース"tokyo") を起動する必要があります インスタンス"tokyo1"の起動中... ORACLE インスタンスが起動しました。 データベースがマウントされました。 データベース"tokyo"の修復を続行します... データベース"tokyo"の修復に成功しました 20:17:59.34 2007 年 12 月 14 日 金曜日 11.3 ファスト・スタート・フェイルオーバーの詳細設定 - 51 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved Oracle Database 11g Release 1 ではファスト・スタート・フェイルオーバーの条件やファス ト・スタート・フェイルオーバー実行時の動作をより詳細に設定することができるようになりま した。本項ではファスト・スタート・フェイルオーバーの設定のうち代表的な設定に関して設定 値の確認方法及び設定値の変更手順を紹介します。各パラメータの詳細等はマニュアル｢Oracle Data Guard Broker 11g リリース 1｣をご参照ください。 11.3.1 ファスト・スタート・フェイルオーバー実行時の動作設定 ここではファスト・スタート・フェイルオーバー実行時の動作設定について Threshold と Lag Limit の２つについて紹介します。その他のパラメータについてはマニュアル｢Oracle Data Guard Broker 11g リリース 1｣をご参照ください。 1) FastStartFailoverThreshold プライマリ・データベースの可用性に問題があることをオブザーバが検知した際に、プライ マリ・データベースに再接続を試みる期間を設定します。 ２) FastStartFailoverLagLimit 最大パフォーマンスモードで動作している際に REDO 適用に関してプライマリ・データベー スからスタンバイ・データベースが遅れることができる時間を指定します。プライマリ、ス タンバイ・データベース間の適用遅延がこの設定値を越えている状態では、プライマリ・デ ータベースに障害が発生してもファスト・スタート・フェイルオーバーは実行されません。 それぞれのパラメータの現在の設定値は DGMGRL から show fast_start failover コマンドを実 行することで確認することが可能です。FastStartFailoverThreshold は show fast_start failover の実行結果の｢Threshold｣部分、FastStartFailoverLagLimit は show fast_start failover の実行 結果の｢Lag Limit｣部分で確認することが可能です。 実行例 DGMGRL> show fast_start failover; Fast-Start Failover:DISABLED Threshold: 30 seconds => FastStartFailoverThreshold の設定値 Target: (none) Observer: (none) Lag Limit: 60 seconds => FastStartFailoverLagLimit の設定値 Shutdown Primary: FALSE Auto-reinstate: TRUE ・・(省略)・・ 各パラメータの設定値は DGMGRL より edit configuration コマンドを使用して変更することが 可能です。 DGMGRL>edit configuration set property <パラメータ名>=<設定値>; 実行例： DGMGRL>edit configuration set property FastStartFailOverLagLimit=120; 11.3.2 ファスト・スタート・フェイルオーバー実行条件の設定 - 52 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved ここではファスト・スタート・フェイルオーバー実行条件について、設定値の確認方法と設定 値の変更方法を記載します。ファスト・スタート・フェイルオーバーが実行される条件として以 下の 1)から 5)のそれぞれのケースでの条件を設定することが可能です。それぞれのケースが発生 した際に、ファスト・スタート・フェイルオーバーを実行するか否かを指定することができます。 1) データファイル・オフライン(Datafile Offline) 書込みエラーのためデータファイルがオフラインになった場合 2) 破損したディクショナリ(Corrupted Dictionary) データベース内の重要なディクショナリが破損した場合 3) 破損した制御ファイル(Corrupted Controlfile) ディスク障害のために制御ファイルが破損した場合 4) アクセス不可能なログ・ファイル(Inaccessible Logfile) I/O エラーのために LGWR がどの REDO ログメンバーにも書き込みができない場合 5) スタック・アーカイバ(Stuck Archiver) デバイスが使用できないため、REDO ログをアーカイブできない場合 また、プライマリ・データベースで発生する ORA－エラーをファスト・スタート・フェイルオー バーの条件として設定することも可能です。 それぞれの設定値は DGMGRL より show fast_start failover を実行した結果から確認すること が可能です。1)から 5)の設定に関しては｢Health Conditions:｣の部分にてフェイルオーバーが有 効となっているか否かを確認することが可能です。ORA－エラーに関しては｢Oracle Error Conditions:｣の出力から確認することが可能です。 実行例： DGMGRL> show fast_start failover; ・・(省略)・・ Configurable Failover Conditions Health Conditions: Corrupted Controlfile Corrupted Dictionary Inaccessible Logfile Stuck Archiver Datafile Offline YES YES NO NO YES Oracle Error Conditions: (none) 設定値は DGMGRL から enable/disable fast_start failover condition を実行することで変更する ことが可能です。 有効化 DGMGRL>enable fast_start failover condition <パラメータ名>; 無効化 DGMGRL>disable fast_start failover condition <パラメータ名>; - 53 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved 実行例： DGMGRL>enable fast_start failover condition 'Inaccessible Logfile'; DGMGRL>enable fast_start failover condition 60 本ドキュメントご利用にあたっての注意事項 本ホワイトペーパに記載されている内容は、Oracle GRID Center にて実施された検証結果にも とづくものあり、すべての環境において同様の結果が得られるとは限りません。効果はお客様の 環境およびその他の要因によって異なる可能性があります。 - 54 Copyright © 2008 Hitachi, Ltd. All Rights Reserved. Copyright © 2008 Oracle Corporation Japan. All Rights Reserved