[[262544]]

大規(guī)模升級來臨，咱們來談?wù)凮racle 12cR2使用經(jīng)驗(yàn)。

一、升級到12cR2的必要性

隨著2019年2月13日，Oracle 19c (Oracle 12.2.0.3) for Exadata 版本發(fā)布，Oracle 12cR2體系的數(shù)據(jù)庫版本終于迎來了長期支持版本(Oracle 12c的最后一個(gè)大版本)，也就是說數(shù)據(jù)庫版本還在Oracle 10g/11g的系統(tǒng)是時(shí)候考慮升級了。

特別是在Oracle 11.2.0.4以前的版本，用了db link的系統(tǒng)，務(wù)必要升級。

其實(shí)，根據(jù)Oracle數(shù)據(jù)庫生命周期和版本演進(jìn)路線，到2018年12月31日，Oracle 11.2已經(jīng)結(jié)束了免費(fèi)的擴(kuò)展服務(wù)期(Fee Waived ES)，一些新遇到的bug補(bǔ)丁用普通的SR賬號(hào)將沒有權(quán)限下載。

同時(shí)考慮到SCN天花板速率算法變化的問題，12c升級就變得更加必要了(當(dāng)然，應(yīng)用沒有變化，或者沒有使用dblink的可以不用考慮)。

Oracle每個(gè)版本的bug都很多，不過并非是Oracle數(shù)據(jù)庫軟件不行，而是因?yàn)镺racle是OLTP領(lǐng)域的絕對王者，提供了太多方便的功能，bug就多了。所以每次升級前，我們都會(huì)去擼一遍fix list，看看有沒有新的bug被其他人發(fā)現(xiàn)并解決了。

到目前為止，Oracle 12.2系列的fix patch數(shù)量是2078個(gè)：

當(dāng)然，這補(bǔ)丁數(shù)量還是遠(yuǎn)遠(yuǎn)低于Oracle11.2系列的27782個(gè)：

也遠(yuǎn)低于Oracle 10.2系列版本的26281個(gè)(這些補(bǔ)丁均不包含集群補(bǔ)丁)：

這個(gè)結(jié)果有些出乎意料，12cR2上的patch數(shù)量比前2個(gè)版本少了一個(gè)數(shù)量級。一個(gè)可能性是12cR2的bug少了很多，另一個(gè)可能性是12cR2還沒有迎來大規(guī)模升級，而今年就是升級到12cR2的最佳時(shí)機(jī)。

二、Oracle 12c體系的一些新特性

Oracle 12c相比Oracle 11g，有3個(gè)特性被廣為期待：

• 多租戶：12cR1最多允許252個(gè)租戶，12cR2-19c最多允許4098個(gè)租戶，由max_pdbs參數(shù)控制
• In-Memory Option
• Sharding

從兩年多的案例來看：

• Sharding功能幾乎沒有被使用

主要原因是：在12.2，一個(gè)SDB中只支持一個(gè)Table Family，一個(gè)正常業(yè)務(wù)數(shù)據(jù)庫都會(huì)需要有多個(gè)Table Family;而在Oracle 19c里，增加了Multiple Table Families特性，或許可以好好用一下

• In-Memory Option沒有大規(guī)模用起來

原因是一方面是使用場景，另一方面是維護(hù)成本，多租戶特性成了這個(gè)版本的扛鼎之作。

多租戶特性(Multitenant)是12c體系最重要的特性，在12.1.0.1版本引入。開創(chuàng)性地在一個(gè)容器數(shù)據(jù)庫(cdb)中可以包含很多個(gè)可插拔數(shù)據(jù)庫(pdb)，每個(gè)pdb之間可以有自己獨(dú)立的參數(shù)和資源占用限制，所以該特性成為了12c版本中最受歡迎的特性。

很多企業(yè)使用多租戶特性整合那些零碎且單獨(dú)占用一個(gè)數(shù)據(jù)庫的小應(yīng)用，大大減少了機(jī)器的數(shù)量，降低了數(shù)據(jù)庫許可費(fèi)用，而且pdb遷移起來更加靈活。

pdb使用過程中有幾個(gè)bug，影響還是蠻大的。其中一個(gè)是pdb在Data Guard的備端運(yùn)行一段時(shí)間后會(huì)”消失”：

Bug 25576813 - V$PDB and SHOW PDBS may not display some PDBs in Standby Database OR ORA-65011 on PDB Open OR PDB Datafile on Standby with wrong GUID ( Doc ID 25576813.8 )  

這個(gè)bug從17年開始有one-off patch，但是一直沒有徹底修復(fù)。徹底修復(fù)只能升級到Oracle 18c，或者今年將推出來的19c。

我此前一直非常好奇，為什么一個(gè)bug的補(bǔ)丁不能在下一次PSU的時(shí)候，將這個(gè)one-off patch一起打包進(jìn)去呢?

直到2018年一個(gè)叫oraguy的用戶在Hacker News爆出了如下信息：

Oracle 12.2這個(gè)版本，有將近2500萬行C代碼!(相比較而言，最受歡迎的NoSQL數(shù)據(jù)庫Redis最新版本5.0.4也不過2萬多行代碼，真是短小精干。)

oraguy是這么描述一個(gè)Oracle數(shù)據(jù)庫程序員的工作流程的：

1. 拿到一個(gè)新任務(wù)：解決一個(gè)新bug。
2. 花兩周時(shí)間了解20個(gè)不同的flag( 標(biāo)記 )，這些標(biāo)記用一種很奇怪的方式制造了這個(gè)bug。
3. 嘗試添加flag，寫幾行代碼，同時(shí)要小心不會(huì)制造出更多bug。
4. 將更改提交到包含大約100-200臺(tái)服務(wù)器的測試服務(wù)器集群，這些服務(wù)器將編譯代碼，構(gòu)建新的Oracle數(shù)據(jù)庫軟件，并以分布式方式運(yùn)行數(shù)百萬個(gè)測試。
5. 回家。第二天來上班，繼續(xù)處理別的bug 。測試可能需要20-30個(gè)小時(shí)才能完成。
6. 再回家。再來上班，檢查集群測試結(jié)果。順利的話，會(huì)有大約100個(gè)失敗的測試;倒霉的話，將有大約1000個(gè)失敗的測試。隨機(jī)選擇一些測試并試圖搞清楚你的假設(shè)出了什么問題。或許還需要考慮10多個(gè) flag才能真正理解bug的本質(zhì)。
7. 再添加一些flag以嘗試解決問題。再次提交更改以進(jìn)行測試。再等20-30個(gè)小時(shí)。
8. 來來回回，重復(fù)兩周，大概理解出現(xiàn)這個(gè)bug的原因了。
9. 終有一天，在你幾乎錘蛋自盡之前，發(fā)現(xiàn)某次測試完全通過了。
10. 再寫上百個(gè)測試，以防下次哪個(gè)晦氣孩子要碰項(xiàng)目的時(shí)候，不會(huì)把你的修改搞砸……
11. 提交最后一輪測試的成果。然后提交以供審核。審查本身可能還需要2周到2個(gè)月。所以接下來繼續(xù)去處理下一個(gè)bug 。
12. 在2周到2個(gè)月之后，一切已就緒，代碼將最終合并到主分支中。

再看看上面一兩萬個(gè)patch，有一些沒有能合并到主分支(PSU)中，也就可以理解了。

PDB除了可以用來做小庫整合外，還有一個(gè)便利，就是在當(dāng)機(jī)器資源使用率不均衡的時(shí)候可以在不同CDB之間做熱插拔。

但實(shí)踐證明，熱插拔最好在同版本之間做，否則可能出現(xiàn)異常。

在12c建pdb的語法里，還新出現(xiàn)了一個(gè)option叫PATH_PREFIX，用來限制一些對象(directory objects/oracle XML/create pfile/oracle wallets)只能在特定目錄下。這個(gè)目錄前綴，一旦添加將伴隨著pdb直到終老，連datapump想換個(gè)目錄都不行，所以添加一定要謹(jǐn)慎。

在Oracle 18c里做pdb遷移的時(shí)候，執(zhí)行DBMS_PDB.CHECK_PLUG_COMPATIBILITY，可能會(huì)報(bào)ORA-7445[__intel_ssse3_rep_memcpy()]，這是Bug 28502403 - ORACLE 18.3.0 MULTITENANT: COMPATIBILITY CHECK DOES NOT WORK。

不過這個(gè)bug只在18.2和18.3出現(xiàn)，用最新的18c可以規(guī)避這個(gè)問題。

隨著國家網(wǎng)絡(luò)安全法的實(shí)施，企業(yè)安全檢查愈加嚴(yán)格，“定期修改數(shù)據(jù)庫密碼”從應(yīng)付檢查變成嚴(yán)格執(zhí)行。這對11g dg的DBA來說，是一件極為痛苦的事情，每次修改主庫密碼，還得手動(dòng)同步密碼文件到各個(gè)備庫實(shí)例，稍微漏了某個(gè)實(shí)例沒同步到，數(shù)據(jù)就不同步了。

12cR2推出的一個(gè)新特性——自動(dòng)同步密碼文件到Data Guard備庫，當(dāng)SYS、SYSDG等的密碼發(fā)生更改時(shí)，主數(shù)據(jù)庫中的密碼文件被更新，然后將更改傳播到配置中的所有備庫。

與此可以配合的是11gR2推出的一個(gè)新參數(shù)REDO_TRANSPORT_USER，創(chuàng)建單獨(dú)的日志傳輸授權(quán)用戶，并賦予SYSOPER權(quán)限，然后再將此賬戶封存即可。使用過程中需要注意的是，這個(gè)用戶名是區(qū)分大小寫的。

在最新Oracle19c也推出了不少新特性，我最為關(guān)注的有2個(gè)：

自動(dòng)統(tǒng)計(jì)信息管理

統(tǒng)計(jì)信息管理一直是大企業(yè)數(shù)據(jù)庫管理的一個(gè)難題，隨著表的數(shù)據(jù)變化，統(tǒng)計(jì)信息能夠?qū)崟r(shí)更新，防止SQL語句選擇次優(yōu)執(zhí)行計(jì)劃(據(jù)官網(wǎng)介紹，這是AWS拋棄Oracle選用Aurora的重要理由)。

Oracle 19c內(nèi)置了專家系統(tǒng)，內(nèi)置算法捕獲應(yīng)用程序SQL歷史進(jìn)SQL倉庫、識(shí)別有益于新SQL的后選索引、驗(yàn)證、決策、在線驗(yàn)證、監(jiān)控的自動(dòng)索引創(chuàng)建，并且一段時(shí)間自動(dòng)創(chuàng)建的索引如果不合適還會(huì)自動(dòng)刪除。

自動(dòng)索引創(chuàng)建

自動(dòng)索引創(chuàng)建這一特性引入了一個(gè)開關(guān)視圖dba_auto_index_config。鑒于19c目前僅推出了Exadata版本，這2個(gè)特性是否能在生產(chǎn)上使用還有待評估。

三、一些謹(jǐn)慎使用的特性

將交易型生產(chǎn)數(shù)據(jù)庫遷移到Oracle 12c(包括Oracle12cR2、Oracle18c、Oracle 19c)，有一些特性建議關(guān)閉(其中部分特性是從Oracle 10g開始一直都建議關(guān)閉的)，設(shè)計(jì)很理想，現(xiàn)實(shí)很骨感，我們能做的就是幫忙盡量圓潤一些。

下面默認(rèn)數(shù)據(jù)庫都是Oracle RAC：

1、實(shí)例并行執(zhí)行

PARALLEL_FORCE_LOCAL該參數(shù)默認(rèn)是False。理論上講，集群多個(gè)節(jié)點(diǎn)，并行處理的時(shí)候多個(gè)節(jié)點(diǎn)一起來，均衡用力，是最優(yōu)方案。事實(shí)是多節(jié)點(diǎn)并行處理的協(xié)調(diào)成本很高，節(jié)點(diǎn)間通訊負(fù)載大。因此要改為True，實(shí)現(xiàn)進(jìn)程級別本地化并發(fā)處理。

2、內(nèi)存自動(dòng)管理

從10g開始sga自動(dòng)管理sga_target到12c的內(nèi)存級別自動(dòng)管理memory_target。核心生產(chǎn)庫全部建議改為手動(dòng)，非核心幾個(gè)月不看一眼的庫可以設(shè)置為自動(dòng)管理。

3、查詢結(jié)果緩存

一次緩存，百次使用。對某些特定“靜態(tài)”查詢類的系統(tǒng)可能適用，在OLTP里這種場景幾乎沒有。所有result_cache_max_size=0。

4、布隆過濾算法

Bloom Filter由布隆在1970年提出，用來檢索一個(gè)對象是否在某個(gè)集合中，優(yōu)點(diǎn)是空間效率高于其他算法，缺點(diǎn)是有一定的誤識(shí)別率。一旦識(shí)別錯(cuò)誤，效率就是百倍降低，這對于高效穩(wěn)定的系統(tǒng)來說是不可接受的。

_bloom_filter_enabled=false;_bloom_pruning_enabled=false 

動(dòng)態(tài)資源重組：每個(gè)數(shù)據(jù)庫資源，都有其Master，擁有者和請求者，初衷是根據(jù)請求情況來動(dòng)態(tài)調(diào)整Master，減少實(shí)例間數(shù)據(jù)傳輸。

_gc_policy_time=0;_gc_undo_affinity=false;"_gc_read_mostly_locking"=FALSE。 

5、 段延遲創(chuàng)建

新建一個(gè)數(shù)據(jù)表，Oracle只會(huì)建這個(gè)對象而暫不分配segment，只有當(dāng)往表里插入第一條數(shù)據(jù)的時(shí)候才創(chuàng)建segment。初衷是節(jié)約存儲(chǔ)空間，但該特性bug極多。

deferred_segment_creation=false 

6、內(nèi)存列式存儲(chǔ)

In-Memory Option是12c的一大亮點(diǎn)，對特定的應(yīng)用適用。

通常建議關(guān)閉：inmemory_size=0;inmemory_query=disable;

四、幾個(gè)問題/bug

升級到Oracle 12c后遇到的一些重要bug，建議要去整改。

問題1：SGA手動(dòng)管理模式下，Oracle偷偷去自動(dòng)增大Shared pool了(Oracle 19.2解決)。

命中Bug 26405036 Large Allocation Of "ges enqueues" and "ges resource dynamic" In The Shared Pool 會(huì)把共享池從20g不斷自動(dòng)resize到200g以上，直到sga_max_size中無法有空余空間了，應(yīng)用報(bào)ora-04031。

解決方法是打補(bǔ)丁，目前Oracle 18.5的補(bǔ)丁也出來了：

臨時(shí)解決方案如下：

SQL> oradebug setmypid

SQL> oradebug lkdebug -m reconfig lkdebug

問題2：在home目錄產(chǎn)生大量trace文件或者是單個(gè)超大文件，空間滿導(dǎo)致系統(tǒng)hang。

這個(gè)問題現(xiàn)象相似，但不止是一個(gè)bug：

原因1：

Trace files generation with message “AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1”.

這是Bug 25415713，安裝one-off patch可以解決。

原因 2：

Trace files generated from RMAN module with KRB messages.

可能是：

Bug 28174827 ：RMAN Unconditional KRB Trace File After Installing Fix Of Bug 22700845

Bug 28390273 ：RMAN UNCONDITIONAL KRB TRACE FILE AFTER PATCH 27674384

通過alter system set events 'trace[krb.*] disk disable, memory disable';解決。

原因3：

KZAN: ORA-55917 during CLI write.

KZAN: SYS user audit records will written to files now.

需要禁用KTLI tracing：

alter system set event='55901 trace name context off';

alter system set event='TRACE[RecordCompose] off';

alter system set event='TRACE[FileWrite] off';

alter system set event='TRACE[QueueWrite] off';

問題3：在RAC集群環(huán)境下，對大表進(jìn)行truncate會(huì)導(dǎo)致另一個(gè)節(jié)點(diǎn)hang住。dbaplus社群有過專門診斷文章：你敢在Oracle 12c R2上做大表truncate嗎?

該bug在最新版的PSU中已經(jīng)修復(fù)：

問題4：升級到Oracle 12c/18c后，低版本數(shù)據(jù)庫客戶端連接會(huì)報(bào)錯(cuò)：

ORA-28040: No matching authentication protocol/ORA-01017: invalid username/password; logon denied

需要先在sqlnet.ora中加入SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8/SQLNET.ALLOWED_LOGON_VERSION_SERVER=8，然后再重置密碼解決。(參考MOS文檔 ID 2296947.1)

五、幾個(gè)重要參數(shù)

還有其他一些建議設(shè)置的參數(shù)，大多數(shù)是為了避免bug，還有一部分是為了關(guān)閉某些Oracle特性。

ASM初始化參數(shù)，memory_target設(shè)為2G，process設(shè)置為200或以上。

數(shù)據(jù)庫參數(shù)：

• _serial_direct_read= AUTO; 避免high direct path read
• _lm_tickets=5000;默認(rèn)1000，增加GES messaging tickets
• _px_use_large_pool=TRUE;并行會(huì)話使用large pool而不是共享池，降低ora4031
• _b_tree_bitmap_plans=FALSE;
• SEC_CASE_SENSITIVE_LOGON=FALSE;禁用密碼大小寫敏感
• _gc_defer_time=0;減少進(jìn)程對熱塊爭用
• _datafile_write_errors_crash_instance=FALSE;數(shù)據(jù)文件(sysytem以外表空間)I/O讀寫錯(cuò)誤被發(fā)現(xiàn)時(shí)，發(fā)生錯(cuò)誤的數(shù)據(jù)文件進(jìn)行offline而不關(guān)閉實(shí)例。
• event='10949 trace name context forever:28401 trace name context forever, level 1:10849 trace name context forever, level 1' ;關(guān)閉數(shù)據(jù)庫當(dāng)中用戶持續(xù)輸入錯(cuò)誤密碼導(dǎo)致大量library cache lock;關(guān)閉自動(dòng)serial direct path read特性，避免出現(xiàn)過多的直接路徑讀，消耗過多的IO資源
• _undo_autotune=FALSE;關(guān)閉undo自動(dòng)調(diào)整
• _use_adaptive_log_file_sync=FALSE;寫日志緩沖區(qū)到文件方式默認(rèn)是采用Post/wait方式，在11.2.0.3版本開始增加了Polling的方式。關(guān)閉該參數(shù)不允許切換。
• "_fix_control"='14142884:ON','8560951:ON','8893626:OFF','9344709:OFF','9195582:OFF','9380298:ON','13704562:OFF','16053273:OFF','8611462:OFF','17760375:OFF','17938754:OFF','8560951:ON'
• 當(dāng)然，同時(shí)要說明的是，這些僅僅是認(rèn)為必要注意的參數(shù)，真實(shí)環(huán)境還有其他參數(shù)也同樣要注意。如果你在閱讀過程中，認(rèn)為還有某些參數(shù)是應(yīng)該必須調(diào)整的，歡迎在文章后面留言，給其他同行做一個(gè)參考。

六、升級參考文章

核心數(shù)據(jù)庫升級是一件復(fù)雜的系統(tǒng)工程，必須經(jīng)過嚴(yán)謹(jǐn)?shù)姆桨钢贫?、升級測試、性能測試及最后的割接遷移流程，雖然我們已經(jīng)經(jīng)歷過上千套系統(tǒng)的12c升級，但是每次升級前的測試仍然能發(fā)現(xiàn)新的缺陷。

有些是應(yīng)用代碼的，有些是SQL性能的，有些是數(shù)據(jù)庫軟件的甚至有些是存儲(chǔ)鏈路的，充分的測試才是確保成功升級的唯一保證。

對于大數(shù)據(jù)量的升級遷移，Oracle副總裁swonger有一個(gè)演講：migrate + 200TB database in less than 1 day，講的是歐洲電網(wǎng)的案例，使用了TTS+expdp+perl等多種手段，值得一看。

鏈接：

https://www.neooug.org/gloc/Presentations/2018/Swonger_Migrate_200TB.pdf

對于升級來說，不僅要關(guān)心升級本身能否按時(shí)間完成，關(guān)于升級之后的性能如何、穩(wěn)定性如何、可用性、數(shù)據(jù)一致性和完整性如何也同樣重要，而且都應(yīng)在正式升級割接前進(jìn)行充分的模擬驗(yàn)證。

作者介紹

楊志洪，dbaplus社群聯(lián)合發(fā)起人，新炬網(wǎng)絡(luò)首席布道師，對數(shù)據(jù)庫、數(shù)據(jù)管理有深入研究，合譯《Oracle核心技術(shù)》《Oracle Exadata專家手冊》。