資料庫管理-第118期 記一次開啟附加日誌導致的效能問題（202301129）

本週二凌晨，為了配合某國產資料庫從Oracle資料庫能夠實時同步資料，在X9M那套一體機上做了開啟附加日誌的操作，也正是因為這個操作帶來了一些小問題。

1 幹了些啥？

其實很標準，在主庫CDB裡面開啟附加日誌：

ALTER  DATABASE  ADD SUPPLEMENTAL  LOG  DATA;

而這時候在EMCC監控中發現某個PDB開始出現了一些問題：

資料庫兩條查詢語句出現了大量的latch: cache buffers chains等待，業務方反饋主要是查詢幾乎卡死，對應操作無法執行。而這兩條語句平時執行效率賊高，理應不會出現這個問題，那麼根據最近做了啥操作，判定肯定是因為開啟附加日誌引起的。好的一點是開啟附加日誌的操作大概在15分鐘內完成了，為了快速恢復業務，所以將對應PDB進行了重啟操作：

alter pluggable database pdb_xxx close immediate instances=all;alter pluggable database pdb_xxx open instances=all;

srvctl start service -db xxdbaas -s xxxdb

2 為什麼會這樣？

首先這裡發生的問題很奇怪，如果是開啟附加日誌引起的異常等待，那麼應該是所有PDB都會受到影響，然而受影響的只有一個PDB，在網上和MOS查了一圈過後也沒找到具體原因，只能開個SR問問，上傳了標準3件套：AWR報表、ASH、tfactl收集的檔案之後，後臺也很快給了答覆：

根據 Alter Database Add Supplemental Log Data Hangs (Doc ID 406498.1)，啟用Supplemental Log ，這個會讓所有cursor cache 裡的cursor失效，這個應該是導致這些SQL再次執行時候等待latch: cache buffers chains 的原因，通常來講， 這個等待應該不會很長時間並且這麼多會話同時等待，除非sql 效能很差，這個目前在您的環境中看不出來，因為在同一sample 裡，很多會話執行同一sql，並且blocker是不同的。這個應該是正常的， 只是在增加supplemental log data 過程中很大機率遇到的一個情況。

這個問題也是我第一次遇到，因為附加日誌開啟造成的大量等待，也算是吃一塹長一智，以後所有資料庫操作還是申請一個更高的割接操作，割接期間任何影響就有據可依。這裡也可以看到，一體機會給一些效能不大好的SQL帶來一些幻覺，因為跑的很快；另一方面即是強如Exadata也不能在稍有異常的情況下跑出非凡效能。最終還好業務側把出問題時間的坑給填了，不說了，看語句最佳化去了。

3 你以為就完了？

資料庫的效能問題確實是解決了，但是還得去PDB裡面開全列附加日誌，因為要從ADG備庫拉取資料，而備庫用於日誌儲存的磁碟組空間很小，因此該國產資料庫技術人員提供了下面的語句來開啟需要同步的對應表的全列統計資訊：

DECLARE
    sqltest VARCHAR2(200;);BEGIN
    FOR t IN (SELECT table_name FROM all_tables WHERE owner ='XXXX'))    LOOP
        Sqltest := 'ALTER TABLE '||t.table_name||'ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS';        EXECUTE IMMEDIATE sqltest;;
        DBMS_OUTPUT.PUT_LINE(sqltest;);    END LOOP;;END;;

這裡吐槽以下幾點：

• loop，查一條拼接一條執行一條，這效率，有點低
• 變數大小寫問題，主要是看著煩
• 作為DBA不干預業務使用者賬號密碼，那我肯定得用高許可權使用者去執行，那麼只不是缺了個schema拼接內容
• ADD前面少了一個空格（尷尬症還是強迫症抑或都給整出來了）

總結

老規矩，知道寫了些啥！