您好,登錄后才能下訂單哦!
原文: https://www.enmotech.com/web/detail/1/796/1.html
引言
近期我們在DBASK小程序新關聯了韓鋒頻道、互聯網偵察、數據庫SQL、SQL數據庫開發、跨界架構師、石杉的架構筆記等數據領域的公眾號,聚合更新展示,歡迎大家閱讀分享。
問答集萃
接下來,我們分享本期整理出的問題和診斷總結,供大家參考學習,詳細的診斷分析過程可以通過標題鏈接跳轉到小程序中查看。
問題一、Windows 系統是否需要設置filesystemio_options
如題,數據版本為10g
診斷結論:不需要設置,參考《Best Practices For Oracle Database Performance On Windows》
問題二、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建庫. 成功。
問題三、集群資源ora.LISTENER_LEAF.lsnr,資源offline,這是什么資源?
集群資源ora.LISTENER_LEAF.lsnr,資源offline。db版本12.2.0.1。
診斷結論:這是12c Oracle Flex Cluster的特性,引入了葉子節點的概念,不需要直接連接共享存儲。而LISTENER_LEAF是用來注冊leaf node上運行的實例的。
問題四、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。
問題五、Asm磁盤組冗余模式IO性能有差異么
Asm磁盤組冗余模式,IO性能有差異么?差異有多大?
診斷結論:在讀場景下,不論冗余方式,都只讀其中一份AU,所以不會有讀性能的損失。
在寫的場景下,外部冗余的ASM磁盤組的IO性能,可以近似理解為是所有LUN的IO綜合,包括IOPS及吞吐量。Normal冗余是雙寫嘛,因為每次要寫兩個相同的AU,所以可以理解為IO相關指標損失一半。High冗余損失三分之二。
問題六、ogg 12c可以應用源為10g的trail文件嗎?
如題,10g的trail文件是否可以應用到12c中,需要注意什么?
診斷結論:應該是沒問題,建議測試驗證下。源端抽取進程和傳輸進程加下參數FORMAT RELEASE。另外目標端需要非PDB模式。
問題七、刪除一張上億記錄數表的唯一性約束和索引有什么影響
如題,刪除了一張記錄數有一億的表的唯一性約束和索引,會有影響么?重建會花多久?
診斷結論:刪除本身當然沒有影響。只不過數據完整性沒法保證,索引無法利用。至于創建時間要根據表大小,當前業務量,系統i/o情況,需要全掃表讀取數據,然后內存排序創建唯一索引。可以看下session_longops,或者根據索引的段大小推測所需時間。
問題八、TB級別數據庫搭建goldengate
在這個級別搭建ogg使用table還是schema進行??,在后期表結構會發生變化的情況下哪種方式方便后期維護?
診斷結論:如果非要用OGG,建議按表拆分多個進程吧,不然一個進程出現問題會影響整個庫的同步。
問題九、oracle rac時間被調整的影響
rac配置了時鐘同步,由于時鐘同步服務器出問題導致rac兩個節點時間被同時調整到了3天后,然后關閉集群手動調整系統時間,啟動集群后發現undo的begintime和快照時間都有問題,目前重建了undo,這種事故對數據庫有其他影響嘛??業務數據問題已與研發溝通過,沒造成影響
專家解答:如果業務數據確認沒有問題,數據庫能正常啟動運行的話問題不大,依賴時間戳的主要是日志和監控數據類,建議重要的檢查處理下:
1. grid/db的相關alertlog備份清理下問題的日志
2. AWR備份刪除部分snapshot,以免混淆
3. sys.WRH$_ACTIVE_SESSION_HISTORY的相關記錄
問題十、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數據庫復制的最終解決方案。
問題十一、ASM新加DG,數據文件如何遷移
oracle12c數據庫原來創建的表空間所在asm上的DG用完,我又新加了一個DG如何修改原來DG上表空間的參數設置,比如表空間自動擴展
診斷結論:關閉之前DG上所有數據文件的自動擴展,然后在新DG上為相應表空間創建數據文件即可。還有temp、undo這些方便遷移的,可以移到新的DG上。
問題十二、關于Extended RAC兩種模式壓測存儲復制的方式都優于ASM冗余
我們正在實施容災項目,對比Extended RAC在存儲復制和ASM冗余兩種方案的性能,供客戶方案選型,目前測試的結果顯示存儲復制的方式都優于ASM冗余的方式。請問測試結果符合預期嗎如何理解這種結果?
診斷結論:我認為應該是符合預期的。存儲復制層面會有比較多的額外硬件支持,比如cache,比如硬件級別的IO復制優化。而這些都是單純的ASM多副本寫出所不具備的。畢竟存儲級復制產品作為一個商業產品要賣出價格,必須要有更值得付錢的功能。
出處:墨天輪(ID:enmocs)
(注:問題具體解答請進入DBASK小程序或公眾號“數據和云”文章歷史查看)
想了解更多關于數據庫、云技術的內容嗎?
快來關注“數據和云”公眾號、“云和恩墨”官方網站,我們期待與大家一同學習和進步!
(掃描上方二維碼,關注“數據和云”公眾號,即可查看更多科技文章)
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。