Oracle Data Guard basics and how to create manually 18c plus

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. |
Oracle Data Guard physical standby
動作原理と手組構成最短手順
日本オラクル株式会社
日下部明
2019年7月10日

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、
情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。
以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するもの
ではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関
して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決
定されます。
2

この資料はなんですか？
• Data Guard physical standbyを手作業で構築することになったときに最低
限何を設定しなければならないかの手順を説明します。
• もっとも手間がかかるのはプライマリ・データベースを複製するところです。
• Oracle Enterprise Manager Cloud Controlを構成していればEMCCから簡単
にData Guardを構成できるのですが、EMCCがあるとは限りません。
• Oracle Databaseに付属のDatabase Configuration Assistant（dbca）コマンド
を使用すると、かなり簡単に複製を作ることができます。
– 12c Release 2ではnon-CDBかつシングル・インスタンス構成のみ対応
– 18c以降ではCDBにもRAC/RAC One Node構成にも対応
– この資料はLinux x86-64版のRAC 18cとRAC 19cで動作確認しながら作成（同じ手順）
3

Agenda
Oracle Data Guard physical standbyの動作原理
手組でData Guardを構成する
1
2
4

Oracle Data Guard physical standbyの
動作原理
5

Data Guard physical standbyの動作原理
• Data Guard physical standbyはバックアップ/リストア/リカバリの応用
– データファイルのバックアップを変更の起点に、REDOログで変更の差分を適用する
• スタンバイ・データベースはプライマリ・データベースとデータブロックの構
造まで同じになる
– 高可用性目的のレプリケーションでそもそもやりたいことはプライマリ・データベース
で動作していたアプリケーションがスタンバイ・データベースでも全く同じように動作
すること（まったく同じであるのが強制されること自体がメリット）
– 対向データベースで取得したデータファイルのバックアップを自データベースにリスト
ア/リカバリすることも可能
– データブロックの破損を検出すると、対向データベースのデータブロックを取得し自
動リカバリできる（Active Data Guard）
6

バックアップ/リストア/リカバリのおさらい
7

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 8
Oracle Databaseのアーキテクチャ
System
Global
Area
DBWn
SMON
PMON
LGWR
ARCn
バックグラウンド・
プロセス
共有メモリデータ・ファイル
オンラインREDOログ・ファイル
アーカイブREDOログ・ファイル
制御ファイル
パラメータ・
ファイル
データベースの状態
インスタンスのパラメータ
表や索引データの実体
更新の履歴
オンラインREDOログ
のバックアップ

Oracle Databaseのバックアップ/リストア/リカバリの文脈
バックアップ（主に）データファイルのコピーを取得すること
リストア（主に）データファイルのバックアップから書き戻すこと
リカバリデータブロックにREDOログを適用しロールフォワード
＆ロールバックすること

バックアップ/リストア/リカバリ
時間
INSERT
UPDATE
DELETE
（固定長、循環式）
更新の履歴はまずオンラインREDOログ
に記録される

時間
INSERT
UPDATE
DELETE
（固定長、循環式）アーカイブREDOログ
更新の履歴はまずオンラインREDOログ
に記録される
オンラインREDOログのコピーが
アーカイブREDOログとして残される

時間
INSERT
UPDATE
DELETE
バックアップ
（データファイルのコピー）
時刻t0
時刻t0に取得したバックアップには時刻t0まで
の変更情報しか含まれていない

時間
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
オンラインREDOログアーカイブREDOログ
バックアップ
時刻t0
時刻t0に取得したバックアップには時刻t0まで
の変更情報しか含まれていない

バックアップ/リストア/リカバリデータファイル障害発生
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
バックアップ
時刻t0 時刻t1

INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
時間
バックアップ
時刻t0 時刻t1
データファイル障害発生

INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
時間
バックアップ
リストア
（データファイルの書き戻し）
時刻t0 時刻t1
時刻t0までのデータブロックの復元

INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
時間
バックアップ
リストア
（データファイルの書き戻し）
リカバリ
（REDOログの適用）
時刻t0 時刻t1
時刻t0から時刻t1までの
更新差分の適用

• データファイルのバックアップにはバックアップを取得した時点までの情報
しか含まれていない
• データファイルのリストア（更新の起点） + REDOログ（更新の差分）でデー
タファイル障害直前の状態までリカバリできる
18
時間
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
バックアップ
時刻t0

Oracle Data Guard physical standbyの
動作原理
19

バックアップ/リストア/リカバリの応用
Data Guard physical standbyの動作原理
プライマリ・データベース
（レプリケーション元）
スタンバイ・データベース
（レプリケーション先）
Oracle
インスタンス
1
Oracle
インスタンス
2
(1)プライマリ・データベースのフル
バックアップを別のノードにリスト
アする（変更の起点の作成）
(2)プライマリ・データベースに
更新が発生するとREDOログ
情報が生成される
(3)REDOログ情報を転送する
(4)プライマリ・データベースの
REDOログ情報でリカバリ

Oracle Data Guard physical standbyの作成
21

Data Guard physical standbyの作成
• Oracle CloudのDatabase Cloud Serviceならばデータベースを作成する時点
でRAC+Data Guardの構成も選択可能
• オンプレミスではOracle Enterprise Manager Cloud Controlの管理対象下に
あるORACLE_HOMEならばGUIで構成可能
• コマンドライン手作業（この資料が説明する手順）
– Database Configuration Assistant（dbca）のコマンドラインでデータベースを複製
– 18c以降だとシングル・インスタンス構成もRACも同じ手順にできる
– REDOログの送受信とリカバリの設定
22

REDOログを一方的に送り付ける最小限の構成手順
Data Guard physical standbyの作成
Oracle
インスタンス
1
Oracle
インスタンス
2
(3)dbcaでプライマリ・データ
ベースを複製する
(1)アーカイブ・ログ・モード/FORCE LOGGING
(5)REDOログ送信設定
(4)REDOログ受信設定(2)スタンバイREDOログの作成
(6)リカバリ開始
(0)名前を考えておく

Data Guard physical standbyの構成手順
1. アーカイブ・ログ・モード
2. FORCE LOGGING
3. スタンバイREDOログ
4. dbcaで複製
5. BCTファイル（Optional）
6. FLASHBACK ON（Optionalただし実質的に必須）
7. tnsnames.ora
8. 初期化パラメータ
9. リカバリ開始
24
プライマリ・データベースの停止を伴うのはアーカイブ・ログ・
モードの設定のみ
本番稼働しているデータベースならばアーカイブ・ログ・モー
ドになっているはずなので実質的に無停止で構成可能

dbcaで複製する前に決めておかなければならないことがある
スタンバイ・データベースに関する名前
Oracle
インスタンス
1
Oracle
インスタンス
2
スタンバイ・データベースの：
• データベース名 DB_UNIQUE_NAME
• Oracleインスタンス名の接頭辞 SID

• DB_NAME
– CREATE DATABASE xxx として作成した名前
– データベースを構成するファイルに埋め込まれており、プライマリ・データベースをコピーして作るData Guardを構成するすべて
のデータベースが同じ名前を持つ
• DB_UNIQUE_NAME
– 管理操作上データベースを区別する名前
– デフォルト値はDB_NAME（CREATE DATABASEしたプライマリ・データベースのDB_UNIQUE_NAMEはDB_NAMEになっている）
– Data Guardを構成するすべてのデータベースは異なる一意な名前を持つ
26
Oracle Databaseでは「データベースの名前」は2階層ある
DB_UNIQUE_NAME = databaseA
DB_NAME = databaseA
DB_UNIQUE_NAME = databaseB
DB_NAME = databaseADB_NAMEは同じ
DB_UNIQUE_NAMEは一意

DB_UNIQUE_NAME
• データベースのファイルパスに含まれるデータベース名
– +ASM_DISKGROUP/DB_UNIQUE_NAME/DATAFILE/...
• srvctlコマンドで指定するデータベース名 -db
– srvctl start database -db DB_UNIQUE_NAME
27
管理操作上区別するデータベースの名前

• デフォルトのサービス名SERVICE_NAMES のデフォルト値は DB_UNIQUE_NAME.DB_DOMAIN
• つまりData Guardを構成するデータベースごとに異なる
• PDBのデフォルト・サービス名はPDB_NAME.DB_DOMAINで同じになる
• これらのデフォルト・サービスにはアプリケーションから接続してはならない
• アプリケーション用のサービスは追加で作成すること
28
デフォルトのサービス名はDB_UNIQUE_NAMEから生成される
DB_UNIQUE_NAME = databaseA
DB_NAME = databaseA
DB_UNIQUE_NAME = databaseB
DB_NAME = databaseADB_NAMEは同じ
DB_UNIQUE_NAMEは一意
SERVICE_NAMES = databaseA.DB_DOMAIN SERVICE_NAMES = databaseB.DB_DOMAIN

SYSDG権限
• SYSDBAはOracle Databaseの最上位の権限
• SYSDGはData Guard操作用のSYSDBAよりも小さな権限
• この資料で説明しているData Guard構成に関わるsqlplusでの操作は
SYSDBAでもSYSDGのどちらでも可能
29
SYSDBAよりも小さなData Guard操作用の権限
$ sqlplus / as sysdba
$ sqlplus / as sysdg

アーカイブ・ログ・モードにする
• プライマリ・データベースをアーカイブ・ログ・モードにする
• Data Guardの構築でOracleインスタンス再起動が必要な唯一の操作
– 本番稼働データベースならばもともとアーカイブ・ログ・モードになっているはず
– これ以外の操作はすべてプライマリ・データベースを稼働させたまま構成可能
30
$ srvctl stop database -db ...
SQL> startup mount
SQL> alter database archivelog;
SQL> alter database open;
SQL> exit
$ srvctl start database -db ...
SQL> select LOG_MODE from v$database;
LOG_MODE
------------------------------------
ARCHIVELOG
設定確認

強制ロギングモードにする
• NOLOGGING操作でもREDOログを生成させるモード
31
Data GuardはREDOログに乗らない情報は伝搬しない
SQL> alter database force logging;
SQL> select force_logging from v$database;
FORCE_LOGGING
--------------------
YES

REDOログ情報を受信する（スタンバイ）側が永続化するためのREDOログファイル
スタンバイREDOログ
Oracle
インスタンス
1
Oracle
インスタンス
2
REDOログ情報送信 REDOログ情報受信
スタンバイREDOログに格納

スタンバイREDOログの作成
• スタンバイ・データベース側に必要なファイルであるが、プライマリ・データベースにも
作成することになる
– 最初はプライマリだったとしてもいつかスタンバイになる
• どちらの方法でも作成可能（1の方がミスを抑制）
1. プライマリ・データベースでスタンバイREDOログを作成してからdbcaでデータベースを複製（スタン
バイREDOログ構成も複製される）
2. スタンバイ・データベースを複製してから各データベースにスタンバイREDOログを作成
33
REDOログ情報を受信する（スタンバイ）側が永続化するためのREDOログファイル
プライマリ・データベーススタンバイ・データベース
スタンバイREDOログスタンバイREDOログ

オンラインREDOログの構成を調べる
THREAD 1
GROUP
1
GROUP
2
THREAD 2
GROUP
3
GROUP
4
Oracleインスタンスは自分が書き込む専用のREDOストリーム
（REDO THREAD）を持っている。
RACの場合REDO THREADがOracleインスタンスの数だけある。
アーカイブREDOログはREDO THREADごとに生成される。
スタンバイREDOログを作成するために、まずオンラインREDOログ
のTHREADとGROUPの構成、サイズを調べる。
> select thread#,group#,bytes from v$log;
THREAD# GROUP# BYTES
---------- ---------- ----------
1 1 1073741824
1 2 1073741824
2 3 1073741824
2 4 1073741824
RAC
インスタンス
1
RAC
インスタンス
2

オンラインREDOログの構成をもとに作成する
> alter database add standby logfile thread 1
group 5 size 1073741824,
group 6 size 1073741824,
group 7 size 1073741824;
> alter database add standby logfile thread 2
group 8 size 1073741824,
group 9 size 1073741824,
group 10 size 1073741824;
オンラインREDOログのGROUP数+1のスタンバイREDOログGROUP
を各REDO THREADに作成する。
サイズはオンラインREDOログと同じ。
THREAD 1
GROUP
1
GROUP
2
THREAD 2
GROUP
3
GROUP
4
RAC
インスタンス
1
RAC
インスタンス
2
GROUP
5
GROUP
6
GROUP
7
GROUP
8
GROUP
9
GROUP
10

最も時間がかかるのはこの工程
プライマリ・データベースの複製
Oracle
インスタンス
1
Oracle
インスタンス
2
Oracle
インスタンス
3
Oracle
インスタンス
4
1. ログ格納用ディレクトリ作成
2. 初期化パラメータ作成
3. パスワード・ファイルのコピー
4. RMAN DUPLICATE
5. サーバー・パラメータ・ファイル作成
6. Oracle Grid Infrastructureへのリソース登録
手作業でやるとこれだけ手間がかかることを
Database Configuration Assistant（dbca）のコマン
ド1つで完了できる

プライマリ・データベースの設定から継承されるもの
プライマリ・データベースのdbcaでの複製
Oracle
インスタンス
1
Oracle
インスタンス
2
Oracle
インスタンス
3
Oracle
インスタンス
4
継承される設定
（プライマリで設定していたらスタンバイ側であら
ためての設定は不要）
• アーカイブ・ログ・モード
• FORCE LOGGING
• スタンバイREDOログ
継承されない設定
（プライマリで設定していてもスタンバイ側であら
ためて設定が必要）
• FLASHBACK ON
• Block Change Trackingファイル

（Optional）プライマリ・データベースの複製を実行する前に
• （Optional）PARALLELISMでバックアップの並列度をプライマリ・データベー
スに設定しておく
38
dbca内部ではRMANでプライマリ・データベースを複製している
$ rman target /
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 4;

18c以降のdbcaではRAC/RAC One Node構成でも複製可能
スタンバイ・データベース側ノードでdbcaを実行
$ export LANG=C
$ export NLS_LANG=American_America.US7ASCII
$ dbca -silent -createDuplicateDB -createAsStandby
-gdbName DB_NAME.DB_DOMAIN
-sysPassword SYSユーザーのパスワード
-primaryDBConnectionString scan-host-name:port/SERVICE_NAMES
-dbUniqueName DB_UNIQUE_NAME
-sid ORACLE_SID接頭辞
-initParams db_create_file_dest=+DATA,db_recovery_file_dest=+RECO
-databaseConfigType RAC
-adminManaged
-nodelist node3,node4
プライマリ・データベースへの接続情報
スタンバイ・データベースで変更する情報
スタンバイ・データベースのRAC構成
RACの場合ORACLE_SID接頭辞に1,2,3,...と番号が付く
CDB$ROOTに接続するための情報

もしdbcaでの複製が失敗したら
• Oracle Grid Infrastructureにリソース登録されているのでdbcaで
DB_UNIQUE_NAMEを指定して削除する
– ファイルの削除とCRSリソースの登録解除
40
$ dbca -silent -deleteDatabase
-sourceDB 削除対象のDB_UNIQUE_NAME
-sysDBAUserNAME SYS
-sysDBAPassword SYSユーザーのパスワード

OPEN READ ONLY状態の複製が出来上がる
dbcaで複製が完了した状態
SQL> select DBID,NAME,DB_UNIQUE_NAME,OPEN_MODE,DATABASE_ROLE from v$database;
DBID NAME DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE
---------- --------------- --------------- --------------- --------------------
1650164401 RAC19B rac19bst READ ONLY PHYSICAL STANDBY
プライマリ・データベースと
同じ識別子
NAME列はDB_NAMEのこと
このデータベースの
識別子
READ ONLYでOPENしている
PHYSICAL STANDBYデータベース

Block Change Trackingファイル
• スタンバイ・データベースで高速増分バックアップするのに必要
42
プライマリ・データベースで有効だったとしてもdbcaで複製されない設定
> select status from V$BLOCK_CHANGE_TRACKING;
STATUS
----------
DISABLED
> alter database enable block change tracking;
> select status from V$BLOCK_CHANGE_TRACKING;
STATUS
----------
ENABLED
プライマリ・データベースでENABLEDだったとしてもdbcaで複製するとDISABLEDになる

FLASHBACK ON
• Data Guardを運用するにはFLASHBACKは実質的に必須
43
プライマリ・データベースで有効だったとしてもdbcaで複製されない設定
> select flashback_on from v$database;
FLASHBACK_ON
--------------------
NO
> alter database flashback on;
> select flashback_on from v$database;
FLASHBACK_ON
--------------------
YES
プライマリ・データベースでYESだったとしてもdbcaで複製するとNOになる

リカバリ開始したあとにFLASHBACK ONを設定するには
• 一旦リカバリを停止してFLASHBACKの設定をしなければならない
44
リカバリ中だとFLASHBACKの設定はできない
alter database flashback on
*
ERROR at line 1:
ORA-01153: an incompatible media recovery is active
> RECOVER MANAGED STANDBY DATABASE CANCEL;
> RECOVER MANAGED STANDBY DATABASE DISCONNECT;
リカバリ停止
リカバリ再開

REDOログ送受信の設定
• REDOログ送信先の指定にtnsnames.oraのTNSエイリアスを使用する
• 初期化パラメータ
45

初期化パラメータでREDO転送先のTNSエイリアスを指定するのでそのエントリを用意
デフォルト・サービスに接続するTNSエイリアスの記述
（REDOログ送信側）
（REDOログ受信側）
LOG_ARCHIVE_DEST_n=送信先のTNSエイリアス
転送モード
送信先のDB_UNIQUE_NAME
standby_database_net_alias =
(DESCRIPTION = ...)
初期化パラメータ
tnsnames.ora

全ノードのORACLE_HOME/network/admin/tnsnames.oraに全データベースのエントリ
デフォルト・サービスに接続するTNSエイリアスの記述
primary_database_net_alias =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = scan-host-name-primary)(PORT = scan-port))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = primary_SERVICE_NAMES)
)
)
standby_database_net_alias =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = scan-host-name-standby)(PORT = scan-port))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = standby_SERVICE_NAMES)
)
)
Data Guardを構成するすべてのデータベースのCDB$ROOT
に接続するエントリをすべてのノードに用意しておく。

アーカイブREDOログの格納先の設定
• 自データベースのアーカイブREDOログの格納先の設定
– DB_RECOVERY_FILE_DESTを想定
– DB_UNIQUE_NAMEに自データベースの名前を指定する
– 全データベースで設定する
48
> alter system set DB_RECOVERY_FILE_DEST_SIZE=195G scope=spfile sid='*';
> alter system set DB_RECOVERY_FILE_DEST='+RECO' scope=spfile sid='*';
> alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db_unique_name' scope=spfile sid='*';
> alter system set LOG_ARCHIVE_DEST_STATE_1='ENABLE' scope=spfile sid='*';

最小限の初期化パラメータ
（REDOログ送信側）
（REDOログ受信側）
LOG_ARCHIVE_CONFIG=Data Guardに関わる
全DB_UNIQUE_NAME
LOG_ARCHIVE_DEST_n=送信先のTNSエイリアス
転送モード
送信先のDB_UNIQUE_NAME
LOG_ARCHIVE_CONFIG=Data Guardに関わる
全DB_UNIQUE_NAME
FAL_SERVER=アーカイブREDOログを
取得するTNSエイリアス

• すべて alter system set ... scope=spfile sid='*'; で動的に設定可能
• 設定した瞬間にREDOログの送受信が開始される
50
最小限の初期化パラメータ
プライマリ・データベース（REDOログ送信側）
スタンバイ・データベース（REDOログ受信側）
LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_DB_UNIQUE_NAME,standby_DB_UNIQUE_NAME)'
LOG_ARCHIVE_DEST_2='SERVICE=standby_database_net_alias
ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=standby_DB_UNIQUE_NAME'
LOG_ARCHIVE_DEST_STATE_2='ENABLE'
STANDBY_FILE_MANAGEMENT='AUTO'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_DB_UNIQUE_NAME,standby_DB_UNIQUE_NAME)'
STANDBY_FILE_MANAGEMENT='AUTO'
FAL_SERVER='primary_alias'

• 役割が入れ替わってもいいようにあらかじめ全データベースに設定することになる
– LOG_ARCHIVE_CONFIG
– LOG_ARCHIVE_DEST_n
– LOG_ARCHIVE_DEST_STATE_n
– FAL_SERVER
51
プライマリとスタンバイの役割はいつか入れ替わる
DB_UNIQUE_NAME_1 DB_UNIQUE_NAME_2

dbcaで複製した直後はOPEN READ ONLY状態
スタンバイ・データベースでリアルタイムREDO適用開始
> select OPEN_MODE,DATABASE_ROLE from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- --------------------
READ ONLY PHYSICAL STANDBY
> RECOVER MANAGED STANDBY DATABASE DISCONNECT;
> select OPEN_MODE,DATABASE_ROLE from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- --------------------
READ ONLY WITH APPLY PHYSICAL STANDBY
OPEN READ ONLYかつリカバリ中
Active Data Guard
OPEN READ ONLYだがリカバリしていない
リアルタイムREDO適用開始

スタンバイ・データベースの状態遷移
スタンバイ・データベースの起動・停止
• 一般的な起動手順
– ①  ⑤ (OPEN + Redo Apply)
– ③  ⑤ (MOUNT + Redo Apply)
SQL> STARTUP1
SQL> ALTER DATABASE OPEN2
SQL> STARTUP MOUNT3
SQL> SHUTDOWN IMMEDIATE4
SQL> RECOVER MANAGED STANDBY DATABASE [USING CURRENT LOGFILE] DISCONNECT;5
SQL> RECOVER MANAGED STANDBY DATABASE CANCEL;6
CLOSE
MOUNT Redo Apply
Redo Apply
受信
受信
OPEN (R/O)
3
2
5
6
5
6
1
4
4
Active Data Guard
Data Guard
Oracle Confidential – Internal

スタンバイ・データベース側でのサービスの作成
• スタンバイ・データベース側でサービスを作成しようとすると失敗する
– srvctl add service
– srvctl start service
• サービスの追加にはデータ・ディクショナリの更新が必要で、OPEN READ
WRITE状態でなければならないから
• プライマリ・データベース側で一旦サービスを作成し、そのサービス名でス
タンバイ・データベース側でもサービスを作成する
– プライマリ・データベースでのデータ・ディクショナリの更新がData Guardでスタンバ
イ・データベースに伝搬する
54

最初のsrvctl start serviceでデータ・ディクショナリを更新しようとするので失敗する
$ srvctl add service -db rac19bst -pdb pdb19b1 -service pdb19b1svc -preferred
rac19bst1,rac19bst2 -role PHYSICAL_STANDBY
$ srvctl start service -db rac19bst -service pdb19b1svc
PRCD-1133 : データベースrac19bstでサービスpdb19b1svcの開始に失敗しました
PRCR-1095 : フィルタ((NAME == ora.rac19bst.pdb19b1svc.svc) AND (TYPE ==
ora.service.type))を使用したリソースの起動に失敗しました
CRS-5017: リソース・アクション"ora.rac19bst.pdb19b1svc.svc start"に次のエラーが発生しまし
た:
ORA-44786: サービス操作を完了できません。
ORA-06512: "SYS.DBMS_SERVICE", 行76
ORA-06512: "SYS.DBMS_SERVICE", 行483
ORA-06512: 行1
。詳細は
"(:CLSN00107:)"("/u01/app/grid/diag/crs/ptvm36/crs/trace/crsd_oraagent_oracle.t
rc")を参照してください。
（以下省略）

スタンバイ側で作成したいサービス（pdb19b1svc）を一旦プライマリ側で作成する
$ srvctl add service -db rac19b -pdb pdb19b1 -service pdb19b1svc -preferred
rac19b1,rac19b2
$ srvctl start service -db rac19b -service pdb19b1svc

プライマリ側で作成したサービスのデータ・ディクショナリがスタンバイ側に伝搬する
> select con_id,NAME from cdb_services;
CON_ID NAME
---------- ------------------------------
1 SYS$BACKGROUND
1 SYS$USERS
1 rac19bXDB
1 rac19b.jp.oracle.com
1 rac19bst.jp.oracle.com
3 PDB19B1
3 pdb19bsvc1
3 SYS.SCHEDULER$_EVENT_QUEUE
3 pdb19b1svc
4 PDB19B2
> select con_id,NAME from cdb_services;
CON_ID NAME
---------- ------------------------------
1 SYS$BACKGROUND
1 SYS$USERS
1 rac19bXDB
1 rac19b.jp.oracle.com
1 rac19bst.jp.oracle.com
3 PDB19B1
3 pdb19bsvc1
3 SYS.SCHEDULER$_EVENT_QUEUE
3 pdb19b1svc
4 PDB19B2
プライマリ・データベーススタンバイ・データベース

プライマリ側で作成したサービス（pdb19b1svc）をスタンバイ側で作成する
$ srvctl add service -db rac19bst -pdb pdb19b1 -service pdb19b1svc -preferred
rac19bst1,rac19bst2 -role PHYSICAL_STANDBY
PRKO-3117 : サービスpdb19b1svcはすでにデータベースrac19bstに存在します
$ srvctl start service -db rac19bst -service pdb19b1svc
スタンバイ側で一旦srvctl add serviceしていたために起こるエラー。
すでにsrvctl add serviceしていたならばこの操作自体は不要

Oracle Data Guard basics and how to create manually 18c plus

Oracle Data Guard basics and how to create manually 18c plus

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Oracle Data Guard basics and how to create manually 18c plus

Similar to Oracle Data Guard basics and how to create manually 18c plus (20)

Oracle Data Guard basics and how to create manually 18c plus

Editor's Notes