2024年10月21日 星期一

Refresh MATERIALIZED View 產生 ORA-31934 錯誤案例

Oracle 版本: 19.16

OS 版本: Aix 7.2


問題描述:

MATERIALIZED View Refresh 失敗,於 DB alert log 發現 ORA-31934 錯誤訊息:

2024-08-18T00:14:15.350739+08:00

MVRF: kkzlShrinkMVLog: executed: alter table "SCOTT"."MLOG$_REGIONS" shrink space

ORA-31934: error occurred while shrinking the materialized view log at kkzlRunSA:execute

ORA-06502: PL/SQL: numeric or value error

ORA-06512: at line 1


問題分析:

從 Oracle 12c 開始,在 MATERIALIZED View Refresh 之後會自動觸發 Segment Advisor 並對 MATERIALIZED View Log 進行 Shrink 的動作,由於 MATERIALIZED View Log 預設是使用 delete 進行資料的刪除,進行 Shrink 的動作可以避免 MATERIALIZED View Log 的空間越來越大, ORA-31934 就是由於 Segment Advisor 所觸發 Shrink 動作所造成的錯誤。


ORA-31934 很有可能是由於 Bug 32433627 所引起的,原因在於 Segment Advisor 對 MATERIALIZED View Log 的處理上不夠完善,可以設定參數 "_mv_refresh_shrink_log"=false 來停用 MATERIALIZED View Refresh 時所觸發的 Segment Advisor 。


解決方法:

設定參數 "_mv_refresh_shrink_log"=false 避免觸發 Segment Advisor 。

SQL> alter system set "_mv_refresh_shrink_log"=false;


除此之外,設定 atomic_refresh 為 false 來進行 MATERIALIZED View Refresh 的動作。 atomic_refresh 預設為 true ,表示 MATERIALIZED View Log 會使用 delete 來刪除資料,設定為 false 表示使用 truncate 來刪除MATERIALIZED View Log 的資料。


由於設定了 "_mv_refresh_shrink_log"=false 使得 MATERIALIZED View Log 不再 Shrink ,此時使用 truncate 來刪除 MATERIALIZED View Log 就可以避免其空間越來越大。

BEGIN  

 DBMS_MVIEW.REFRESH( 'V_REGIONS',method => '?', atomic_refresh => false);

END;

/



2024年9月30日 星期一

ssh 造成 ORA-27515 錯誤案例

Oracle 版本: 12.2.0.1

OS 版本: Linux 7.6


問題描述:

執行程式報錯,於資料庫的 alert log 顯示 ORA-27515 錯誤 :

ORA-00603: ORACLE server session terminated by fatal error

ORA-27515: inadequate memlock limit or driver settings

opiodr aborting process unknown ospid (125480) as a result of ORA-603


由錯誤訊息顯示 memlock 的設定不足,檢查 ulimit -a 的 max locked memory 只有 64 :


但是 /etc/security/limits.conf 的設定是對的 :


limits.conf 的設定並沒有生效。


但是使用 root 登入後再 su - oracle , limits.conf 的設定是有生效的 :


問題分析:

這個現象只有在使用 oracle 直接登入時才會發生 limits.conf 沒有生效,需要調整 ssh 設定。


解決方法:

於 /etc/pam.d/sshd 新增 pam_limits.so 設定如下 :

session required pam_limits.so


並確認 /etc/ssh/sshd_config 裡面的UsePrivilegeSeparation 設定為 NO

UsePrivilegeSeparation no


重啟 ssh 之後,重新使用 oracle 登入即可 。

[root@db19c ~]# systemctl restart sshd




2024年9月16日 星期一

Nologging 造成 corruption 案例

Oracle 版本: 12.2.0.1

OS 版本: Linux 6.7


問題描述:

Standby DB 出現 file corruption 錯誤:

ORA-01578: ORACLE data block corrupted (file # 5, block # 135)

ORA-01110: data file 5: '/opt/app/oradata/ORA12st/users021.dbf'

ORA-26040: Data block was loaded using the NOLOGGING option


問題分析:

由錯誤訊息顯示, data file 5 因為來源端的 nologging 操作造成 corruption ,使得這個檔案無法進行同步。這個問題常常是因為 Primary DB 沒有設定 force logging 並且有 nologging 的操作所導致:


解決方法:

在 Oracle 12.2 的版本之前要解決這個錯誤只能重新 restore datafile ,從 12.2 的版本開始可以直接 recover nonlogged block ,於 standby 查詢 nonlogged block :

SQL> select file#,block#,blocks,object#,reason from v$nonlogged_block;


停止 MRP 後使用 RMAN 來 recover nonlogged block :

SQL> alter database recover managed standby database cancel;

SQL> exit;

[oracle@db12c rman]$ rman target /

RMAN> recover database nonlogged block;



recover 成功後查詢 v$nonlogged_block 已無資料 :


重新啟動 MRP 恢復同步即可 :