DBASK問答集萃第五期

引言

近期咱們在DBASK小程序新關聯了韓鋒頻道、互聯網偵察、數據庫SQL、SQL數據庫開發、跨界架構師、石杉的架構筆記等數據領域的公衆號，聚合更新展現，歡迎你們閱讀分享。

問答集萃

接下來，咱們分享本期整理出的問題和診斷總結，供你們參考學習，詳細的診斷分析過程能夠經過標題連接跳轉到小程序中查看。

問題1、Windows 系統是否須要設置filesystemio_options

如題，數據版本爲10g

診斷結論：不須要設置，參考《Best Practices For Oracle Database Performance On Windows》

問題2、windows 安裝oracle dbca建庫報錯ora-27102 out of memory

windows 2016(64bit) 安裝oracle 11g r2 (64bit) dbca建庫報錯 ora-27102 out of memory，windows 系統內存 64G 分配給oracle 內存 24G 空閒內存充足，這個是由於 2016系統有啥限制嗎該如何解決？

診斷結論：問題爲window操做系統參數的問題。在控制面板中將處理器核數由默認的1改爲8或最大值便可 ，從新啓動，而後再dbca建庫. 成功。

問題3、集羣資源ora.LISTENER_LEAF.lsnr,資源offline,這是什麼資源？

集羣資源ora.LISTENER_LEAF.lsnr,資源offline。db版本12.2.0.1。

診斷結論：這是12c Oracle Flex Cluster的特性，引入了葉子節點的概念，不須要直接鏈接共享存儲。而LISTENER_LEAF是用來註冊leaf node上運行的實例的。

問題4、Execute to Parse %指標24.95，硬解析比例很高

數據庫中，Execute to Parse %指標24.95，SQL硬解析比例很低，排除cursor_sharing= force，系統負載很是低,AWR採樣時間60分鐘，db time1mins。

但願獲取SQL能找到形成大量硬解析的SQL文本，或者應用鏈接mode，

獲取下降硬解析的方法。

診斷結論：通常來講硬解析高的SQL主要的緣由就是沒有使用綁定變量，其次就是內存不夠或者BUG等緣由了。

可使用詳情中的SQL查出沒有使用綁定變量的SQL。

問題5、Asm磁盤組冗餘模式IO性能有差別麼

Asm磁盤組冗餘模式，IO性能有差別麼？差別有多大？

診斷結論：在讀場景下，不論冗餘方式，都只讀其中一份AU，因此不會有讀性能的損失。

在寫的場景下，外部冗餘的ASM磁盤組的IO性能，能夠近似理解爲是全部LUN的IO綜合，包括IOPS及吞吐量。Normal冗餘是雙寫嘛，由於每次要寫兩個相同的AU，因此能夠理解爲IO相關指標損失一半。High冗餘損失三分之二。

問題6、ogg 12c能夠應用源爲10g的trail文件嗎？

如題，10g的trail文件是否能夠應用到12c中，須要注意什麼？

診斷結論：應該是沒問題，建議測試驗證下。源端抽取進程和傳輸進程加下參數FORMAT RELEASE。另外目標端須要非PDB模式。

問題7、刪除一張上億記錄數表的惟一性約束和索引有什麼影響

如題，刪除了一張記錄數有一億的表的惟一性約束和索引，會有影響麼？重建會花多久？

診斷結論：刪除自己固然沒有影響。只不過數據完整性無法保證，索引沒法利用。至於建立時間要根據表大小，當前業務量，系統i/o狀況，須要全掃表讀取數據，而後內存排序建立惟一索引。能夠看下session_longops，或者根據索引的段大小推測所需時間。

問題8、TB級別數據庫搭建goldengate

在這個級別搭建ogg使用table仍是schema進行？？，在後期表結構會發生變化的狀況下哪一種方式方便後期維護？

診斷結論：若是非要用OGG，建議按表拆分多個進程吧，否則一個進程出現問題會影響整個庫的同步。

問題9、oracle rac時間被調整的影響

rac配置了時鐘同步，因爲時鐘同步服務器出問題致使rac兩個節點時間被同時調整到了3天后，而後關閉集羣手動調整系統時間，啓動集羣后發現undo的begintime和快照時間都有問題，目前重建了undo，這種事故對數據庫有其餘影響嘛？？業務數據問題已與研發溝經過，沒形成影響

專家解答：若是業務數據確認沒有問題，數據庫能正常啓動運行的話問題不大，依賴時間戳的主要是日誌和監控數據類，建議重要的檢查處理下:

一、grid/db的相關alertlog備份清理下問題的日誌

二、AWR備份刪除部分snapshot，以避免混淆

三、sys.WRH$_ACTIVE_SESSION_HISTORY的相關記錄

問題10、Oracle Stream 再也不被支持了嗎？從什麼版本開始的？

以前的舊系統，有些還在使用 Stream 流複製，據說不被Oracle支持了。未來要怎麼辦？

診斷結論：Oracle Streams在Oracle Database 12c第1版（12.1）中已棄用。不支持 Oracle Database 12c 及更高版本中引入的支持功能，包括多租戶架構，LONG VARCHAR數據類型，長標識符和其餘功能。

Oracle Database 18c是Oracle Streams支持的最終版本。從Oracle Database 19c開始，Oracle Streams將再也不受支持。

對於複製來講，Oracle GoldenGate是Oracle數據庫複製的最終解決方案。

問題11、ASM新加DG，數據文件如何遷移

oracle12c數據庫原來建立的表空間所在asm上的DG用完，我又新加了一個DG如何修改原來DG上表空間的參數設置，好比表空間自動擴展

診斷結論：關閉以前DG上全部數據文件的自動擴展，而後在新DG上爲相應表空間建立數據文件便可。還有temp、undo這些方便遷移的，能夠移到新的DG上。

問題12、關於Extended RAC兩種模式壓測存儲複製的方式都優於ASM冗餘

咱們正在實施容災項目，對比Extended RAC在存儲複製和ASM冗餘兩種方案的性能，供客戶方案選型，目前測試的結果顯示存儲複製的方式都優於ASM冗餘的方式。請問測試結果符合預期嗎如何理解這種結果？

診斷結論：我認爲應該是符合預期的。存儲複製層面會有比較多的額外硬件支持，好比cache，好比硬件級別的IO複製優化。而這些都是單純的ASM多副本寫出所不具有的。畢竟存儲級複製產品做爲一個商業產品要賣出價格，必需要有更值得付錢的功能。

想了解更多知識問答嗎？登陸「墨天輪」立刻學習！