ACOUG的年终大会上，我分享了一个主题，列举了使用Oracle 12c多租户的过程中可能遇到的各种坑，当你使用一个新产品或者新特性时，如果你不了解，就可能是使用中，陷入其中。
首先我们已经知道，Oracle 12c的多租户特性，允许在一个容器数据库中，创建多个PDB，这些PDB彼此隔离和独立，但是依赖CDB而存在。
问题一：PDB丢失一个文件数据库会如何？
现在请大家思考一个问题：如果某个PDB中，因为意外而丢失了一个数据文件，那么数据库会怎样？
目前我们涉及的版本包括：12.1.0.1.0 ，12.1.0.2.0，12.2.0.1.0
12.1.0.1.0版本
[oracle@12c01db oradata]$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.1.0 Production on Fri Dec 2 15:35:36 2016
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Database mounted.
SQL> alter database open;
Database altered.
SQL>alter pluggable database yhem open;
Pluggable database altered.
移除PDB中的一个数据文件，模拟一次数据文件的损失：
SQL> ! mv /oradata/EYGLE/YHEM/datafile/o1_mf_users_d3zb3hpq_.dbf /oradata/EYGLE/YHEM/datafile/o1_mf_users_d3zb3hpq_.dbf.bak
然后执行检查点，让数据库意识到这个损失：
SQL> alter system checkpoint;
alter system checkpoint
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 23337
Session ID: 1 Serial number: 5
我们注意到进程终端，事实上整个数据库都崩溃了：
Fri Dec 02 15:35:12 2016
Errors in file /u01/app/oracle/diag/rdbms/eygle/eygle/trace/eygle_ckpt_23049.trc:
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01116: error in opening database file 8
ORA-01110: data file 8: '/u01/app/oracle/oradata/EYGLE/YHEM/datafile/o1_mf_users_d3zb3hpq_.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Fri Dec 02 15:35:13 2016
USER (ospid: 23337): terminating the instance due to error 1242
Fri Dec 02 15:35:14 2016
Instance terminated by USER, pid = 23337
一个PDB里丢失了一个数据文件，崩溃了整个CDB，要知道CDB里可能有数十个或上百个PDB啊！要知道在12.1里多租户可以包含252个PDB，而12.2里可以包含4096的PDB。
这一切到底是为什么？
要想解释清楚这个问题，我们还要倒退一步，倒退到 Oracle 11.2.0.2 吧。
问题二：Oracle 11g 如何处理数据文件的丢失异常？
事情是这样的：
从Oracle 11.2.0.2版本开始，一个新的隐含参数 - _datafile_write_errors_crash_instance 被引入到数据库中，通过这个参数名就可以了解到其含义：当发生数据文件写错误时，Crash数据库实例。
为什么要引入这个参数呢？这个参数后台解决的是什么问题呢？
我在《数据安全警示录》一书上曾经写过多个案例，在归档模式下当发生文件（非SYSTEM文件）写错误时，Oracle会自动将数据文件离线，这造成了很多灾难，类似的错误日志可能是这样的：
Fri Jan 13 19:32:21 2013
KCF: write/open error block=0xf1fa6 online=1
file=73 /dev/rods_gm05
error=27063 txt: 'IBM AIX RISC System/6000 Error: 22: Invalid argument
Additional information: -1
Additional information: 557056'
Automatic datafile offline due to write error on
file 73: /dev/rods_gm05
鉴于很多用户遇到的困境，Oracle做出了修正，这一修正在MOS上以BUG形式被提交，其内容为：Bug 7691270 Crash the DB in case of write errors (rather than just offline files) 。
在11.2.0.2之前，如果数据库运行在归档模式下，并且写错误发生在非SYSTEM表空间文件，则数据库会将发生错误的文件离线，在从11.2.0.2开始，数据库会Crash实例以替代Offline。注意：在非归档模式下或者SYSTEM遭受错误时，数据库会直接崩溃。
好了，现在答案清楚了：为了解决数据文件损失，离线控制存在的不确定性风险，Oracle引入的 _datafile_write_errors_crash_instance 控制数据库实例直接崩溃。
可是不要忘了，你现在是多租户啊，以前是一个人，可以任性，现在可是带队伍的了！这样不好吧？
问题三：PDB 能够以ABORT方式关闭么 ？
那该怎么办呢？我们来看一道OCP考试题吧。当然，学习Oracle技术可以到『恩墨学院』来，专业的老师们可以更详细的为你解惑。
在Oracle 12c的考试中，有这样一道题目：
When executing shutdown abort in a pluggable database (PDB), you _____.
A. shut down abort the CDB
B. shut down abort the PDB
C. shut down immediate the PDB
D. shut down immediate the CDB
当我们通过shutdown abort的方式关闭PDB时，事实上我们做了什么？这个简单的题目，如果不加限定条件，答案是不确定的。
Oracle 12.1.0.1版本
通过10046的跟踪，可以清楚的找到事实真相:
[oracle@12c01db trace]$ sqlplus / as sysdba
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> select con_id,name,open_mode from v$pdbs;
CON_ID NAME OPEN_MODE
---------- ---------------------- ----------
2 PDB$SEED READ ONLY
3 YHEM MOUNTED
SQL> alter pluggable database YHEM open;
Pluggable database altered.
SQL> alter session set container=YHEM;
Session altered.
SQL> alter session set events '10046 trace name context forever,level 12';
Session altered.
SQL> shutdown immediate;
Pluggable Database closed.
SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
[oracle@12c01db trace]$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.1.0 Production on Thu Dec 1 15:21:05 2016
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> alter session set container=YHEM;
Session altered.
SQL> startup
Pluggable Database opened.
SQL> alter session set events '10046 trace name context forever,level 12';
Session altered.
SQL> shutdown abort;
Pluggable Database closed.
对比两个跟踪文件，可以清晰的看到，在后台两种关闭方式事实上都被转换成immediate的方式关闭数据库，无论是归档模式还是非归档模式表现相同：
[oracle@12c01db trace]$ grep -i pluggable eygle_ora_14095.trc
ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE
[oracle@12c01db trace]$ grep -i pluggable eygle_ora_14115.trc
ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE
在跟踪文件中的这一段代码如下：
=====================
PARSING IN CURSOR #140136925772400 len=40 dep=0 uid=0 oct=227 lid=0 tim=67757313673 hv=1239515853 ad='9346b320' sqlid='65jadw14y30qd'
ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE
END OF STMT
PARSE #140136925772400:c=0,e=215,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=67757313673
CLOSE #140136925778208:c=0,e=3,dep=1,type=0,tim=67757313767
=====================
在这个版本中的CDB中，标准的命令不包含ABORT选项：
SQL> alter pluggable database YHEM CLOSE;
Pluggable database altered.
SQL> alter pluggable database YHEM open;
Pluggable database altered.
SQL> alter pluggable database YHEM CLOSE ABORT;
alter pluggable database YHEM CLOSE ABORT
*
ERROR at line 1:
ORA-00922: missing or invalid option
所以在12.1.0.1版本中，这个问题的答案应该选择C。
看明白了么？也就是说，在Oracle 12.1.0.1版本中，Oracle根本就不支持PDB的异常关闭，所以Crash Instance，就只能Crash CDB的Instance了。
你一定会说：这不科学！是的，Oracle在不断修正和进化啊，所以不要害怕，我们看看 Oracle 12.1.0.2.0 版本中，发生了什么改变。
问题四：Oracle 的 PDB 能以ABORT的方式关闭么？
首先，必要要允许PDB Crash。
在Oracle 12.1.0.2.0 版本中，通过一个补丁修正 Bug 19001390 Oracle引入了两个隐含的初始化参数：
- 第一个参数是： _enable_pdb_close_abort ，设置该参数，允许PDB异常关闭。
- 第二个参数是：_enable_pdb_close_noarchivelog，允许PDB在非归档模式下异常关闭。
注意，不管是哪一种，如果异常关闭了PDB，又不能保留所有的归档日志，以后这个PDB可能永远也无法正常启动了。
Bug 19001390 的主题是：PDB system tablespace media failure causes the whole CDB to crash，在以下版本中被引入：
12.2 (Future Release)
12.1.0.2.1 (Oct 2014) Database Patch Set Update
12.1.0.2 Bundle Patch 1 (Oct 2014) for Engineered Systems / DB In-Memory (DBBP)
12.1.0.2 Patch 1 on Windows Platforms
我们看看以下测试，通过启用该参数，模拟之前的操作：
SQL> alter system set "_enable_pdb_close_abort"=true ;
System altered.
SQL> alter pluggable database PDBPROD1 open;
Pluggable database altered.
SQL> ! mv /oradata/PRODCDB/PDBPROD1/PDBPROD1_users01.dbf /oradata/PRODCDB/PDBPROD1/PDBPROD1_users01.dbf.bk
SQL> alter system checkpoint;
System altered.
SQL> select con_id,name,open_mode from v$pdbs;
CON_ID NAME OPEN_MODE
---------- ------------------------------- --------------------
2 PDB$SEED READ ONLY
3 PDBPROD1 MOUNTED
4 PDBPROD2 READ WRITE
注意，此时告警日志输出如下，我们已经看到，现在PDB被单独的ABORT掉了，CDB和其他PDB未受到影响，这下科学了吧：
Fri Dec 02 15:58:39 2016
Errors in file /oracle/diag/rdbms/prodcdb/PRODCDB/trace/PRODCDB_ckpt_14527.trc:
ORA-63999: data file suffered media failure
ORA-01116: error in opening database file 10
ORA-01110: data file 10: '/oradata/PRODCDB/PDBPROD1/PDBPROD1_users01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Fri Dec 02 15:58:43 2016
Internal PDB shutdown abort of PDBPROD1 (container=3)
当然，我们如果不想这个数据库崩溃，希望数据库回复到以前的效果，可以关闭11.2.0.2引入的参数：_datafile_write_errors_crash_instance，当该参数设置为FALSE之后，数据库将仅仅离线失去的数据文件：
Mon Jan 09 16:23:41 2017
Errors in file /oracle/diag/rdbms/prodcdb/PRODCDB/trace/PRODCDB_ckpt_13304.trc:
ORA-01171: datafile 10 going offline due to error advancing checkpoint
ORA-01116: error in opening database file 10
ORA-01110: data file 10: '/oradata/PRODCDB/PDBPROD1/PDBPROD1_users01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Mon Jan 09 16:24:02 2017
Checker run found 1 new persistent data failures
我们注意到在12.2版本中的变化是：_enable_pdb_close_abort 参数的初始值被设置为TRUE，也就是缺省的，就只是异常关闭PDB，而不会影响整个CDB。
是不是觉得Oracle的世界又变得美好了？
文章转自数据和云公众号，原文链接