大規模升級來臨，談談Oracle 12cR2使用經驗
大規模升級來臨，咱們來談談Oracle 12cR2使用經驗。
一、升級到12cR2的必要性
隨著2019年2月13日，Oracle 19c (Oracle 12.2.0.3) for Exadata 版本發布，Oracle 12cR2體系的數據庫版本終于迎來了長期支持版本(Oracle 12c的最后一個大版本)，也就是說數據庫版本還在Oracle 10g/11g的系統是時候考慮升級了。
特別是在Oracle 11.2.0.4以前的版本，用了db link的系統，務必要升級。
其實，根據Oracle數據庫生命周期和版本演進路線，到2018年12月31日，Oracle 11.2已經結束了免費的擴展服務期(Fee Waived ES)，一些新遇到的bug補丁用普通的SR賬號將沒有權限下載。
同時考慮到SCN天花板速率算法變化的問題，12c升級就變得更加必要了(當然，應用沒有變化，或者沒有使用dblink的可以不用考慮)。
Oracle每個版本的bug都很多，不過并非是Oracle數據庫軟件不行，而是因為Oracle是OLTP領域的絕對王者，提供了太多方便的功能，bug就多了。所以每次升級前，我們都會去擼一遍fix list，看看有沒有新的bug被其他人發現并解決了。
到目前為止，Oracle 12.2系列的fix patch數量是2078個：
當然，這補丁數量還是遠遠低于Oracle11.2系列的27782個：
也遠低于Oracle 10.2系列版本的26281個(這些補丁均不包含集群補丁)：
這個結果有些出乎意料，12cR2上的patch數量比前2個版本少了一個數量級。一個可能性是12cR2的bug少了很多，另一個可能性是12cR2還沒有迎來大規模升級，而今年就是升級到12cR2的最佳時機。
二、Oracle 12c體系的一些新特性
Oracle 12c相比Oracle 11g，有3個特性被廣為期待：
- 多租戶：12cR1最多允許252個租戶，12cR2-19c最多允許4098個租戶，由max_pdbs參數控制
- In-Memory Option
- Sharding
從兩年多的案例來看：
- Sharding功能幾乎沒有被使用
主要原因是：在12.2，一個SDB中只支持一個Table Family，一個正常業務數據庫都會需要有多個Table Family;而在Oracle 19c里，增加了Multiple Table Families特性，或許可以好好用一下
- In-Memory Option沒有大規模用起來
原因是一方面是使用場景，另一方面是維護成本，多租戶特性成了這個版本的扛鼎之作。
多租戶特性(Multitenant)是12c體系最重要的特性，在12.1.0.1版本引入。開創性地在一個容器數據庫(cdb)中可以包含很多個可插拔數據庫(pdb)，每個pdb之間可以有自己獨立的參數和資源占用限制，所以該特性成為了12c版本中最受歡迎的特性。
很多企業使用多租戶特性整合那些零碎且單獨占用一個數據庫的小應用，大大減少了機器的數量，降低了數據庫許可費用，而且pdb遷移起來更加靈活。
pdb使用過程中有幾個bug，影響還是蠻大的。其中一個是pdb在Data Guard的備端運行一段時間后會”消失”：
- 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 )
這個bug從17年開始有one-off patch，但是一直沒有徹底修復。徹底修復只能升級到Oracle 18c，或者今年將推出來的19c。
我此前一直非常好奇，為什么一個bug的補丁不能在下一次PSU的時候，將這個one-off patch一起打包進去呢?
直到2018年一個叫oraguy的用戶在Hacker News爆出了如下信息：
Oracle 12.2這個版本，有將近2500萬行C代碼!(相比較而言，最受歡迎的NoSQL數據庫Redis最新版本5.0.4也不過2萬多行代碼，真是短小精干。)
oraguy是這么描述一個Oracle數據庫程序員的工作流程的：
- 拿到一個新任務：解決一個新bug。
- 花兩周時間了解20個不同的flag( 標記 )，這些標記用一種很奇怪的方式制造了這個bug。
- 嘗試添加flag，寫幾行代碼，同時要小心不會制造出更多bug。
- 將更改提交到包含大約100-200臺服務器的測試服務器集群，這些服務器將編譯代碼，構建新的Oracle數據庫軟件，并以分布式方式運行數百萬個測試。
- 回家。第二天來上班，繼續處理別的bug 。測試可能需要20-30個小時才能完成。
- 再回家。再來上班，檢查集群測試結果。順利的話，會有大約100個失敗的測試;倒霉的話，將有大約1000個失敗的測試。隨機選擇一些測試并試圖搞清楚你的假設出了什么問題?；蛟S還需要考慮10多個 flag才能真正理解bug的本質。
- 再添加一些flag以嘗試解決問題。再次提交更改以進行測試。再等20-30個小時。
- 來來回回，重復兩周，大概理解出現這個bug的原因了。
- 終有一天，在你幾乎錘蛋自盡之前，發現某次測試完全通過了。
- 再寫上百個測試，以防下次哪個晦氣孩子要碰項目的時候，不會把你的修改搞砸……
- 提交最后一輪測試的成果。然后提交以供審核。審查本身可能還需要2周到2個月。所以接下來繼續去處理下一個bug 。
- 在2周到2個月之后，一切已就緒，代碼將最終合并到主分支中。
再看看上面一兩萬個patch，有一些沒有能合并到主分支(PSU)中，也就可以理解了。
PDB除了可以用來做小庫整合外，還有一個便利，就是在當機器資源使用率不均衡的時候可以在不同CDB之間做熱插拔。
但實踐證明，熱插拔最好在同版本之間做，否則可能出現異常。
在12c建pdb的語法里，還新出現了一個option叫PATH_PREFIX，用來限制一些對象(directory objects/oracle XML/create pfile/oracle wallets)只能在特定目錄下。這個目錄前綴，一旦添加將伴隨著pdb直到終老，連datapump想換個目錄都不行，所以添加一定要謹慎。
在Oracle 18c里做pdb遷移的時候，執行DBMS_PDB.CHECK_PLUG_COMPATIBILITY，可能會報ORA-7445[__intel_ssse3_rep_memcpy()]，這是Bug 28502403 - ORACLE 18.3.0 MULTITENANT: COMPATIBILITY CHECK DOES NOT WORK。
不過這個bug只在18.2和18.3出現，用最新的18c可以規避這個問題。
隨著國家網絡安全法的實施，企業安全檢查愈加嚴格，“定期修改數據庫密碼”從應付檢查變成嚴格執行。這對11g dg的DBA來說，是一件極為痛苦的事情，每次修改主庫密碼，還得手動同步密碼文件到各個備庫實例，稍微漏了某個實例沒同步到，數據就不同步了。
12cR2推出的一個新特性——自動同步密碼文件到Data Guard備庫，當SYS、SYSDG等的密碼發生更改時，主數據庫中的密碼文件被更新，然后將更改傳播到配置中的所有備庫。
與此可以配合的是11gR2推出的一個新參數REDO_TRANSPORT_USER，創建單獨的日志傳輸授權用戶，并賦予SYSOPER權限，然后再將此賬戶封存即可。使用過程中需要注意的是，這個用戶名是區分大小寫的。
在最新Oracle19c也推出了不少新特性，我最為關注的有2個：
自動統計信息管理
統計信息管理一直是大企業數據庫管理的一個難題，隨著表的數據變化，統計信息能夠實時更新，防止SQL語句選擇次優執行計劃(據官網介紹，這是AWS拋棄Oracle選用Aurora的重要理由)。
Oracle 19c內置了專家系統，內置算法捕獲應用程序SQL歷史進SQL倉庫、識別有益于新SQL的后選索引、驗證、決策、在線驗證、監控的自動索引創建，并且一段時間自動創建的索引如果不合適還會自動刪除。
自動索引創建
自動索引創建這一特性引入了一個開關視圖dba_auto_index_config。鑒于19c目前僅推出了Exadata版本，這2個特性是否能在生產上使用還有待評估。
三、一些謹慎使用的特性
將交易型生產數據庫遷移到Oracle 12c(包括Oracle12cR2、Oracle18c、Oracle 19c)，有一些特性建議關閉(其中部分特性是從Oracle 10g開始一直都建議關閉的)，設計很理想，現實很骨感，我們能做的就是幫忙盡量圓潤一些。
下面默認數據庫都是Oracle RAC：
1、實例并行執行
PARALLEL_FORCE_LOCAL該參數默認是False。理論上講，集群多個節點，并行處理的時候多個節點一起來，均衡用力，是最優方案。事實是多節點并行處理的協調成本很高，節點間通訊負載大。因此要改為True，實現進程級別本地化并發處理。
2、內存自動管理
從10g開始sga自動管理sga_target到12c的內存級別自動管理memory_target。核心生產庫全部建議改為手動，非核心幾個月不看一眼的庫可以設置為自動管理。
3、查詢結果緩存
一次緩存，百次使用。對某些特定“靜態”查詢類的系統可能適用，在OLTP里這種場景幾乎沒有。所有result_cache_max_size=0。
4、布隆過濾算法
Bloom Filter由布隆在1970年提出，用來檢索一個對象是否在某個集合中，優點是空間效率高于其他算法，缺點是有一定的誤識別率。一旦識別錯誤，效率就是百倍降低，這對于高效穩定的系統來說是不可接受的。
- _bloom_filter_enabled=false;_bloom_pruning_enabled=false
動態資源重組：每個數據庫資源，都有其Master，擁有者和請求者，初衷是根據請求情況來動態調整Master，減少實例間數據傳輸。
- _gc_policy_time=0;_gc_undo_affinity=false;"_gc_read_mostly_locking"=FALSE。
5、 段延遲創建
新建一個數據表，Oracle只會建這個對象而暫不分配segment，只有當往表里插入第一條數據的時候才創建segment。初衷是節約存儲空間，但該特性bug極多。
- deferred_segment_creation=false
6、內存列式存儲
In-Memory Option是12c的一大亮點，對特定的應用適用。
通常建議關閉：inmemory_size=0;inmemory_query=disable;
四、幾個問題/bug
升級到Oracle 12c后遇到的一些重要bug，建議要去整改。
問題1：SGA手動管理模式下，Oracle偷偷去自動增大Shared pool了(Oracle 19.2解決)。
命中Bug 26405036 Large Allocation Of "ges enqueues" and "ges resource dynamic" In The Shared Pool 會把共享池從20g不斷自動resize到200g以上，直到sga_max_size中無法有空余空間了，應用報ora-04031。
解決方法是打補丁，目前Oracle 18.5的補丁也出來了：
臨時解決方案如下：
SQL> oradebug setmypid
SQL> oradebug lkdebug -m reconfig lkdebug
問題2：在home目錄產生大量trace文件或者是單個超大文件，空間滿導致系統hang。
這個問題現象相似，但不止是一個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集群環境下，對大表進行truncate會導致另一個節點hang住。dbaplus社群有過專門診斷文章：你敢在Oracle 12c R2上做大表truncate嗎?
該bug在最新版的PSU中已經修復：
問題4：升級到Oracle 12c/18c后，低版本數據庫客戶端連接會報錯：
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)
五、幾個重要參數
還有其他一些建議設置的參數，大多數是為了避免bug，還有一部分是為了關閉某些Oracle特性。
ASM初始化參數，memory_target設為2G，process設置為200或以上。
數據庫參數：
- _serial_direct_read= AUTO; 避免high direct path read
- _lm_tickets=5000;默認1000，增加GES messaging tickets
- _px_use_large_pool=TRUE;并行會話使用large pool而不是共享池，降低ora4031
- _b_tree_bitmap_plans=FALSE;
- SEC_CASE_SENSITIVE_LOGON=FALSE;禁用密碼大小寫敏感
- _gc_defer_time=0;減少進程對熱塊爭用
- _datafile_write_errors_crash_instance=FALSE;數據文件(sysytem以外表空間)I/O讀寫錯誤被發現時，發生錯誤的數據文件進行offline而不關閉實例。
- event='10949 trace name context forever:28401 trace name context forever, level 1:10849 trace name context forever, level 1' ;關閉數據庫當中用戶持續輸入錯誤密碼導致大量library cache lock;關閉自動serial direct path read特性，避免出現過多的直接路徑讀，消耗過多的IO資源
- _undo_autotune=FALSE;關閉undo自動調整
- _use_adaptive_log_file_sync=FALSE;寫日志緩沖區到文件方式默認是采用Post/wait方式，在11.2.0.3版本開始增加了Polling的方式。關閉該參數不允許切換。
- "_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'
- 當然，同時要說明的是，這些僅僅是認為必要注意的參數，真實環境還有其他參數也同樣要注意。如果你在閱讀過程中，認為還有某些參數是應該必須調整的，歡迎在文章后面留言，給其他同行做一個參考。
六、升級參考文章
核心數據庫升級是一件復雜的系統工程，必須經過嚴謹的方案制定、升級測試、性能測試及最后的割接遷移流程，雖然我們已經經歷過上千套系統的12c升級，但是每次升級前的測試仍然能發現新的缺陷。
有些是應用代碼的，有些是SQL性能的，有些是數據庫軟件的甚至有些是存儲鏈路的，充分的測試才是確保成功升級的唯一保證。
對于大數據量的升級遷移，Oracle副總裁swonger有一個演講：migrate + 200TB database in less than 1 day，講的是歐洲電網的案例，使用了TTS+expdp+perl等多種手段，值得一看。
鏈接：
https://www.neooug.org/gloc/Presentations/2018/Swonger_Migrate_200TB.pdf
對于升級來說，不僅要關心升級本身能否按時間完成，關于升級之后的性能如何、穩定性如何、可用性、數據一致性和完整性如何也同樣重要，而且都應在正式升級割接前進行充分的模擬驗證。
作者介紹
楊志洪，dbaplus社群聯合發起人，新炬網絡首席布道師，對數據庫、數據管理有深入研究，合譯《Oracle核心技術》《Oracle Exadata專家手冊》。
