799
回答了這四個問題，少踩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方式關閉麼 ？
那該怎麼辦呢？我們來看一道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的世界又變得美好了？
最後更新：2017-07-18 10:33:00