回答了这四个问题，少踩12c 多租户的好多坑

在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方式关闭么 ？

在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的世界又变得美好了？