12c多租户Dataguard环境中STANDBYS=NONE特性

在12.1.0.2以前,当在主库中添加一个pdb时,物理备库上所有这个pdb相关的文件、目录、权限都要准备好,否则redo apply就无法正常工作。如果这些条件没有满足,redo apply则会停止无法继续,直到所有问题被解决,并且所有的数据文件都被添加到控制文件当中。

从12.1.0.2开始,在主库通过CREATE PLUGGABLE DATABASE语句创建pdb时多了一个新的选项STANDBYS=NONE,通过这个可以指定延迟备库pdb的恢复,不影响备库现有pdbs的正常同步。这个选项允许在所有备库上创建pdb的目录结构,但是所有属于这个备库的数据文件都被标记成OFFLINE/RECOVER。处于这个状态下的备库无法被打开,而其他不处于这个状态的备库都可以被正常打开为只读模式。可以通过查看V$PDBS视图的RECOVERY_STATUS来查看备库PDBs的恢复状态,也可以通过查看数据文件的状态V$RECOVER_FILE.ONLINE,用con_id进行关联查询

延迟创建pdb以后,可能在将来的某个时间点,你需要对这个pdb进行dg保护了,则可以通过拷贝数据文件到备库,启用pdb的恢复。当主库PDB开启时,oracle提供了专门的文件拷贝工具将数据文件从主库拷贝到备库。启用备库pdb的恢复时,需要将备库置为mount状态,同时暂停redo apply

一般在下面这些场景下会用到延迟创建pdb的特性:

  • 当通过CREATE PLUGGABLE DATABASE远程克隆,redo也处于apply状态时,无法预复制数据文件到物理备库而且确保它们处于正确的状态
  • 这个pdb只是用来做测试或者临时用途很快就会删掉,不需要做dg保护
  • 应用的停机时间很短,而拷贝数据文件需要较长时间,之后可能会找时间做备库的恢复
  • 备库存放pdb的空间暂时不够
  • 某些情况下新创建的pdb不需要dg这么高的保护级别,只放在主库里运行,但是不建议这么做

通过STANDBYS=NONE创建PDB

查看data guard configuration

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
DGMGRL> show configuration;

Configuration - ora12ccfg

Protection Mode: MaxPerformance
Members:
ora12c - Primary database
ora12c_dg - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS (status updated 50 seconds ago)

DGMGRL> validate database ora12c_dg

Database Role: Physical standby database
Primary Database: ora12c

Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)

查看主库所有的pdbs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
sys@ORA12C> show parameter db_unique_name

PARAMETER_NAME TYPE VALUE
------------------------------------------------------------ ----------- ----------------------------------------------------------------------------------------------------
db_unique_name string ora12c
sys@ORA12C> select Database_role from v$database;

DATABASE_ROLE
----------------
PRIMARY

sys@ORA12C> show pdbs;

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB12C READ WRITE NO

查看备库的pdbs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
sys@ORA12C> show parameter db_unique_name

PARAMETER_NAME TYPE VALUE
------------------------------------------------------------ ----------- ----------------------------------------------------------------------------------------------------
db_unique_name string ORA12C_DG
sys@ORA12C> select database_role from v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY

sys@ORA12C> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB12C READ ONLY NO
sys@ORA12C> select name, recovery_status from v$pdbs;

NAME RECOVERY
-------------------------------------------------------------------------------------------------------------------------------- --------
PDB$SEED ENABLED
PDB12C ENABLED

通过STANDBYS=NONE选项创建pdb

1
2
3
4
5
6
7
8
9
10
11
sys@ORA12C> create pluggable database pdb2 admin user xb identified by oracle STANDBYS=NONE;

Pluggable database created.

sys@ORA12C> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB12C READ WRITE NO
5 PDB2 MOUNTED

主库上打开新建的pdb

1
2
3
sys@ORA12C> alter pluggable database pdb2 open;

Pluggable database altered.

查看备库新建的pdb情况

当在主库新建完pdb以后,创建的redo日志会传输到备库并且应用。备库能看到新建的pdb,但是如果查询V$PDBS视图的RECOVERY_STATUS字段则会显示disabled。查询对应的数据文件状态则都会显示RECOVER,然而SYSTEM表空间则会显示SYSOFF,主要是用来确认这是SYSTEM数据文件并且offline。备库的pdb则无法打开因为没有数据文件可以访问。如果查看alert日志会看到pdb的创建过程包含STANDBYS=NONE,代表没有standby,表空间创建的时候也是OFFLINE状态。

当主库的PDB创建完成,redo传输到备库且应用完毕后,查看备库PDBs的状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
sys@ORA12C> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB12C READ ONLY NO
5 PDB2 MOUNTED

sys@ORA12C> select name, recovery_status from v$pdbs;

NAME RECOVERY
-------------------------------------------------------------------------------------------------------------------------------- --------
PDB$SEED ENABLED
PDB12C ENABLED
PDB2 DISABLED

查看数据文件的状态

1
2
3
4
5
6
7
8
9
10
11
sys@ORA12C> alter session set container=pdb2;

Session altered.

sys@ORA12C> col name for a80
sys@ORA12C> select name, status from v$datafile;
NAME STATUS
-------------------------------------------------------------------------------- -------
/u01/app/oracle/product/12.2.0/dbhome_1/dbs/UNNAMED00016 SYSOFF
/u01/app/oracle/product/12.2.0/dbhome_1/dbs/UNNAMED00017 RECOVER
/u01/app/oracle/product/12.2.0/dbhome_1/dbs/UNNAMED00018 RECOVER

尝试打开PDB2

1
2
3
4
5
sys@ORA12C> alter pluggable database pdb2 open;
alter pluggable database pdb2 open
*
ERROR at line 1:
ORA-01111: name for data file 16 is unknown - rename to correct file

alert日志

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
PDB2(4):Datafile 13 added to flashback set
PDB2(4):Successfully added datafile 13 to media recovery
PDB2(4):Datafile #13: '/u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_system_gczyjjms_.dbf'
2019-04-24T13:55:23.737483+08:00
Recovery copied files for tablespace SYSAUX
Recovery successfully copied file /u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_sysaux_gczyjjnf_.dbf from /u01/app/oracle/oradata/ORA12C_DG/86DF1439DC9B8E60E0536892A8C0ECA0/datafile/o1_mf_sysaux_gcxbqyr5_.dbf
PDB2(4):Datafile 14 added to flashback set
PDB2(4):Successfully added datafile 14 to media recovery
PDB2(4):Datafile #14: '/u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_sysaux_gczyjjnf_.dbf'
2019-04-24T13:55:25.426806+08:00
Recovery copied files for tablespace UNDOTBS1
Recovery successfully copied file /u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_undotbs1_gczyjjnf_.dbf from /u01/app/oracle/oradata/ORA12C_DG/86DF1439DC9B8E60E0536892A8C0ECA0/datafile/o1_mf_undotbs1_gcxbsf50_.dbf
PDB2(4):Datafile 15 added to flashback set
PDB2(4):Successfully added datafile 15 to media recovery
PDB2(4):Datafile #15: '/u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_undotbs1_gczyjjnf_.dbf'
2019-04-24T13:55:27.687506+08:00
Buffer Cache Full DB Caching mode changing from FULL CACHING ENABLED to FULL CACHING DISABLED
Full DB Caching disabled: DEFAULT_CACHE_SIZE should be at least 70 MBs bigger than current size.
2019-04-24T13:56:40.020461+08:00
PDB2(4):Recovery dropped temporary tablespace 'TEMP'
PDB2(4):Recovery deleting file #15:'/u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_undotbs1_gczyjjnf_.dbf' from controlfile.
PDB2(4):Deleted Oracle managed file /u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_undotbs1_gczyjjnf_.dbf
PDB2(4):Recovery dropped tablespace 'UNDOTBS1'
PDB2(4):Recovery deleting file #14:'/u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_sysaux_gczyjjnf_.dbf' from controlfile.
PDB2(4):Deleted Oracle managed file /u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_sysaux_gczyjjnf_.dbf
2019-04-24T13:56:41.232472+08:00
PDB2(4):Recovery dropped tablespace 'SYSAUX'
PDB2(4):Recovery deleting file #13:'/u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_system_gczyjjms_.dbf' from controlfile.
PDB2(4):Deleted Oracle managed file /u01/app/oracle/oradata/ORA12C_DG/874155556D1A9CB6E0536892A8C0B4D1/datafile/o1_mf_system_gczyjjms_.dbf
PDB2(4):Recovery dropped tablespace 'SYSTEM'
PDB2(4):Recovery dropped pluggable database 'PDB2'
2019-04-24T13:56:43.248383+08:00
Buffer Cache Full DB Caching mode changing from FULL CACHING DISABLED to FULL CACHING ENABLED
2019-04-24T13:58:13.327411+08:00
Recovery created pluggable database PDB2
PDB2(5):File copy for ts-SYSTEM skipped for excluded/offline tablespace
PDB2(5):File #16 added to control file as 'UNNAMED00016'. Originally created as:
PDB2(5):'/u01/app/oracle/oradata/ORA12C/874155556D1B9CB6E0536892A8C0B4D1/datafile/o1_mf_system_gczyo7v3_.dbf'
PDB2(5):because the pluggable database was created with nostandby
PDB2(5):or the tablespace belonging to the pluggable database is
PDB2(5):offline.
2019-04-24T13:58:14.710452+08:00
PDB2(5):File copy for ts-SYSAUX skipped for excluded/offline tablespace
PDB2(5):File #17 added to control file as 'UNNAMED00017'. Originally created as:
PDB2(5):'/u01/app/oracle/oradata/ORA12C/874155556D1B9CB6E0536892A8C0B4D1/datafile/o1_mf_sysaux_gczyo7v3_.dbf'
PDB2(5):because the pluggable database was created with nostandby
PDB2(5):or the tablespace belonging to the pluggable database is
PDB2(5):offline.
2019-04-24T13:58:15.722284+08:00
PDB2(5):File copy for ts-UNDOTBS1 skipped for excluded/offline tablespace
PDB2(5):File #18 added to control file as 'UNNAMED00018'. Originally created as:
PDB2(5):'/u01/app/oracle/oradata/ORA12C/874155556D1B9CB6E0536892A8C0B4D1/datafile/o1_mf_undotbs1_gczyo7v4_.dbf'
PDB2(5):because the pluggable database was created with nostandby
PDB2(5):or the tablespace belonging to the pluggable database is
PDB2(5):offline.
2019-04-24T13:58:16.826353+08:00
PDB2(5):File copy for ts-TEMP skipped for excluded/offline tablespace

对包含DISABLED PDB的standby做角色转换

现在pdb2已经建好了,下面通过dg broker来展示这些信息,当在dg broker里验证完备库以后,会对其做一个switchover,最后会做一个failover切换回原状

查看当前configuration信息

1
2
3
4
5
6
7
8
9
10
11
12
13
DGMGRL> show configuration

Configuration - ora12ccfg

Protection Mode: MaxPerformance
Members:
ora12c - Primary database
ora12c_dg - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS (status updated 40 seconds ago)

执行VALIDATE DATABASE来验证备库,确认当前状态是可以做switchover和failover的。由于当前无法打开备库的PDB,所以无法给备库的PDB增加TEMPfile,所以这里会显示备库的tempfile比主库少一个

1
2
3
4
5
6
7
8
9
10
11
DGMGRL> validate database ora12c_dg

Database Role: Physical standby database
Primary Database: ora12c

Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)

Temporary Tablespace File Information:
ora12c TEMP Files: 4
ora12c_dg TEMP Files: 3

从主库switchover到备库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
DGMGRL> swithover to ora12c_dg
Unrecognized command "swithover", try "help"
DGMGRL> switchover to ora12c_dg
Performing switchover NOW, please wait...
Operation requires a connection to database "ora12c_dg"
Connecting ...
Connected to "ORA12C_DG"
Connected as SYSDBA.
New primary database "ora12c_dg" is opening...
Operation requires start up of instance "ora12c" on database "ora12c"
Starting instance "ora12c"...
ORACLE instance started.
Database mounted.
Database opened.
Connected to "ora12c"
Switchover succeeded, new primary is "ora12c_dg"


DGMGRL> show configuration

Configuration - ora12ccfg

Protection Mode: MaxPerformance
Members:
ora12c_dg - Primary database
ora12c - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS (status updated 80 seconds ago)

在备库(新主库)上,所有的pdb都处于打开状态,除了没有数据文件的pdb2

1
2
3
4
5
6
7
sys@ORA12C> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB12C READ WRITE NO
5 PDB2 MOUNTED

在主库(新备库)上,因为有所有pdb的数据文件,则可以正常打开为read only模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
sys@ORA12C> show parameter db_unique_name

PARAMETER_NAME TYPE VALUE
------------------------------------------------------------ ----------- ----------------------------------------------------------------------------------------------------
db_unique_name string ora12c
sys@ORA12C> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB12C MOUNTED
5 PDB2 MOUNTED
sys@ORA12C> alter pluggable database all open;

Pluggable database altered.

sys@ORA12C> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB12C READ ONLY NO
5 PDB2 READ ONLY NO

通过VALIDATE DATABASE命令验证每个数据库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
DGMGRL> validate database ora12c;

Database Role: Physical standby database
Primary Database: ora12c_dg

Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)

Managed by Clusterware:
ora12c_dg: NO
ora12c : NO
Warning: Ensure primary database's StaticConnectIdentifier property
is configured properly so that the primary database can be restarted
by DGMGRL after switchover

Temporary Tablespace File Information:
ora12c_dg TEMP Files: 3
ora12c TEMP Files: 4



DGMGRL> validate database ora12c_dg;

Database Role: Primary database

Ready for Switchover: Yes

模拟failover操作,在primary库上直接shutdown abort,然后通过dg broker操作failover

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
sys@ORA12C> shutdown abort;
ORACLE instance shut down.

DGMGRL> show configuration;

Configuration - ora12ccfg

Protection Mode: MaxPerformance
Members:
ora12c_dg - Primary database
Error: ORA-1034: ORACLE not available

ora12c - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
ERROR (status updated 0 seconds ago)

DGMGRL> failover to ora12c;
Performing failover NOW, please wait...
Failover succeeded, new primary is "ora12c"
DGMGRL> show configuration;

Configuration - ora12ccfg

Protection Mode: MaxPerformance
Members:
ora12c - Primary database
ora12c_dg - Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS (status updated 217 seconds ago)

因为备库开启了flashback,所以可以很方便的reinstate

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
-- 先启动备库到mount状态
startup mount

DGMGRL> reinstate database ora12c_dg;
Reinstating database "ora12c_dg", please wait...
Reinstatement of database "ora12c_dg" succeeded
DGMGRL> validate database ora12c_dg;

Database Role: Physical standby database
Primary Database: ora12c

Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)

Temporary Tablespace File Information:
ora12c TEMP Files: 4
ora12c_dg TEMP Files: 3

通过rman复制文件实现零停机

现在数据库已经恢复到刚创建PDB时候的状态了,现在需要做的是完成备库pdb的插入,获取相关数据文件用于实现备库pdb数据的正常同步,这个实例化进程只需要主库处于开启状态下可以正常访问即可。

如果配了archive log删除策略的话,比如APPLIED ON ALL STANDBY之类,先暂时禁用掉,备库需要在拷贝过程开始时所有的归档日志用于恢复,等到全部过程顺利结束以后再修改回来,注意这里主备库都需要修改删除策略

1
Rman> configure archivelog deletion policy to none;

检查主库PDBs的状态,确保是可以读写的

1
2
3
4
5
6
7
sys@ORA12C> show pdbs;

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB12C READ WRITE NO
5 PDB2 READ WRITE NO

在通过rman拷贝之前,最后准备一个下面这样的run块,这样可以在备库恢复的过程中直接将建好的文件名写入到备库控制文件当中去,如果不通过这种方式你得一个个手动修改

1
2
3
4
5
run{
set newname for pluggable database PDB2 to new;
restore pluggable database PDB2 from service ora12c;
switch datafile all;
}

在执行切换数据文件操作之前,要先停止redo apply

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
DGMGRL> edit database ora12c_dg set state='apply-off';
Succeeded.
DGMGRL> show configuration;

Configuration - ora12ccfg

Protection Mode: MaxPerformance
Members:
ora12c - Primary database
ora12c_dg - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS (status updated 56 seconds ago)

执行之前创建的run块,从主库恢复数据文件到备库。rman只需要连到备库,不需要专门为主库创建一个连接,因为可以通过FROM SERVICE选项自动完成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
[oracle@testyum ~]$ rman target sys/oracle@ora12c_dg

connected to target database: ORA12C (DBID=383814323)

run{
set newname for pluggable database PDB2 to new;
restore pluggable database PDB2 from service ora12c;
switch datafile all;
5> }

executing command: SET NEWNAME

Starting restore at 24-APR-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=622 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service ora12c
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00025 to /u01/app/oracle/oradata/ORA12C_DG/874511D1C1D14E3BE0536892A8C07D48/datafile/o1_mf_system_%u_.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:36
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service ora12c
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00026 to /u01/app/oracle/oradata/ORA12C_DG/874511D1C1D14E3BE0536892A8C07D48/datafile/o1_mf_sysaux_%u_.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service ora12c
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00027 to /u01/app/oracle/oradata/ORA12C_DG/874511D1C1D14E3BE0536892A8C07D48/datafile/o1_mf_undotbs1_%u_.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
Finished restore at 24-APR-19

datafile 25 switched to datafile copy
input datafile copy RECID=32 STAMP=1006453415 file name=/u01/app/oracle/oradata/ORA12C_DG/874511D1C1D14E3BE0536892A8C07D48/datafile/o1_mf_system_gd0g96yn_.dbf
datafile 26 switched to datafile copy
input datafile copy RECID=33 STAMP=1006453448 file name=/u01/app/oracle/oradata/ORA12C_DG/874511D1C1D14E3BE0536892A8C07D48/datafile/o1_mf_sysaux_gd0gb7nr_.dbf
datafile 27 switched to datafile copy
input datafile copy RECID=34 STAMP=1006453492 file name=/u01/app/oracle/oradata/ORA12C_DG/874511D1C1D14E3BE0536892A8C07D48/datafile/o1_mf_undotbs1_gd0gcnsc_.dbf

启用备库PDB恢复

现在数据文件都已经拷贝完毕,可以启用备库PDB的恢复,Enabling recovery只会影响那些执行这个命令的备库,其他备库的恢复状态则保持不变

备库将会重启到mount状态,但是redo apply必须是关闭状态,之前拷贝数据时已经停掉了。

如果备库是active dataguard状态,则重启到mount状态

1
2
3
4
5
6
7
8
9
10
11
12
13
sys@ORA12C> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
sys@ORA12C> startup mount
ORACLE instance started.

Total System Global Area 5083496448 bytes
Fixed Size 8803264 bytes
Variable Size 1207962688 bytes
Database Buffers 3858759680 bytes
Redo Buffers 7970816 bytes
Database mounted.

执行ENABLE RECOVERY命令

1
2
3
4
5
6
7
sys@ORA12C> alter session set container=pdb2;

Session altered.

sys@ORA12C> alter pluggable database enable recovery;

Pluggable database altered.

开启备库的redo apply

1
2
3
4
5
6
7
8
9
DGMGRL> edit database ora12c_dg set state='apply-on';
Succeeded.
DGMGRL> validate database ora12c_dg;

Database Role: Physical standby database
Primary Database: ora12c

Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)

Redo apply必须要运行一段时间(大概5min)用于确保datafiles能被识别,然后进程才能运行正常。过了这段时间,就可以open pdb了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
sys@ORA12C> select open_mode from v$database;

OPEN_MODE
--------------------
MOUNTED

sys@ORA12C> alter database open;

Database altered.

sys@ORA12C> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY

给pdb添加temp表空间

1
2
3
4
5
6
7
8
9
alter pluggable database all open;

sys@ORA12C> alter session set container=pdb2;

Session altered.

sys@ORA12C> alter tablespace temp add tempfile size 4g;

Tablespace altered.

检查备库pdb的数据文件状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
sys@ORA12C> col name for a120
sys@ORA12C> select name, status from v$datafile;

NAME STATUS
------------------------------------------------------------------------------------------------------------------------ -------
/u01/app/oracle/oradata/ORA12C_DG/874511D1C1D14E3BE0536892A8C07D48/datafile/o1_mf_system_gd0g96yn_.dbf SYSTEM
/u01/app/oracle/oradata/ORA12C_DG/874511D1C1D14E3BE0536892A8C07D48/datafile/o1_mf_sysaux_gd0gb7nr_.dbf RECOVER
/u01/app/oracle/oradata/ORA12C_DG/874511D1C1D14E3BE0536892A8C07D48/datafile/o1_mf_undotbs1_gd0gcnsc_.dbf RECOVER

sys@ORA12C> select * from v$recover_file;

no rows selected

sys@ORA12C> select name, recovery_status from v$pdbs where name = 'PDB2';

NAME RECOVERY
------------------------------------------------------------------------------------------------------------------------ --------
PDB2 ENABLED


DGMGRL> validate database ora12c_dg;

Database Role: Physical standby database
Primary Database: ora12c

Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)

禁用PDB的恢复

在某些情况下需要调试单独的pdb,为了不影响其他pdb的运行,可以单独对这台pdb的恢复进行禁用

步骤跟前面类似,这里就不一一赘述

  • edit database <standby_db_unique_name> set state=’apply-off’;
  • alter pluggable database disable recovery;
  • edit database <standby_db_unique_name> set state=’apply-on’;

12c多租户Dataguard环境中STANDBYS=NONE特性
https://www.xbdba.com/2019/04/24/12c-dataguard-standbysnone-in-multitenant/
作者
xbdba
发布于
2019年4月24日
许可协议