記一次生產數據庫告警日志提示TTC 協議內部錯誤解決過程

最近在巡檢時觀察告警日志發現了一個很奇怪的錯誤：TTC 協議內部錯誤，下面介紹下解決的過程，以作備忘！

環境：

操作系統:AIX 6.1系統

數據庫:oracle11.2.0.1 RAC

Errors in file /u01/app/oracle/diag/rdbms/otmdb/otmdb1/trace/otmdb1_ora_3997920.trc (incident=643554):

ORA-03137: TTC 協議內部錯誤: [12333] [41] [103] [108] [] [] [] []

Incident details in: /u01/app/oracle/diag/rdbms/otmdb/otmdb1/incident/incdir_643554/otmdb1_ora_3997920_i643554.trc

$cp /u01/app/oracle/diag/rdbms/otmdb/otmdb1/incident/incdir_642914/otmdb1_ora_3518674_i642914.trc /home/oracle/ttc.trc

$tkprof /home/oracle/ttc.trc /home/oracle/ttc.txt aggregate=yes sys=no waits=yes sort=fchela

$tkprof /home/oracle/ttc.trc /home/oracle/ttc2.txt sys=no

解釋輸出文件中列的含義：CALL：每次SQL語句的處理都分成三個部分Parse：這步將SQL語句轉換成執行計劃，包括檢查是否有正確的授權和所需要用到的表、列以及其他引用到的對象是否存在。Execute：這步是真正的由Oracle來執行語句。對于insert、update、delete操作，這步會修改數據，對于select操作，這步就只是確定選擇的記錄。Fetch：返回查詢語句中所獲得的記錄，這步只有select語句會被執行。COUNT:這個語句被parse、execute、fetch的次數。CPU：這個語句對于所有的parse、execute、fetch所消耗的cpu的時間，以秒為單位。ELAPSED：這個語句所有消耗在parse、execute、fetch的總的時間。DISK：從磁盤上的數據文件中物理讀取的塊的數量。一般來說更想知道的是正在從緩存中讀取的數據而不是從磁盤上讀取的數據。QUERY：在一致性讀模式下，所有parse、execute、fetch所獲得的buffer的數量。一致性模式的buffer是用于給一個長時間運行的事務提供一個一致性讀的快照，緩存實際上在頭部存儲了狀態。CURRENT：在current模式下所獲得的buffer的數量。一般在current模式下執行insert、update、delete操作都會獲取buffer。在current模式下如果在高速緩存區發現有新的緩存足夠給當前的事務使用，則這些buffer都會被讀入了緩存區中。ROWS: 所有SQL語句返回的記錄數目，但是不包括子查詢中返回的記錄數目。對于select語句，返回記錄是在fetch這步，對于insert、update、delete操作，返回記錄則是在execute這步。

從跟蹤文件可以看到以下信息：

----- Current SQL Statement for this session (sql_id=a33v0rjbr6qm7) -----

select o.order_release_gid, o.order_release_gid from ORDER_RELEASE o, LOCATION ls, ORDER_RELEASE_TYPE ort

where (o.order_release_type_gid=ort.order_release_type_gid) and (o.order_release_gid in

(select ors1.order_release_gid from STATUS_VALUE sv1, ORDER_RELEASE_STATUS ors1 where (sv1.status_value_xid=:1)

and (ors1.status_value_gid=sv1.status_value_gid))) and (o.early_pickup_date between trunc(TO_DATE(:2,:3), :4) and

trunc(TO_DATE(:5,:6), :7)+0.99999) and (o.source_location_gid=ls.location_gid) and (ls.location_xid like :8) and

(ort.order_release_type_xid in (:9)) order by o.insert_date desc

根據報錯代碼，查閱MOS文檔

Troubleshooting ORA-3137 [12333]

Errors Encountered When Using Oracle JDBC Driver (文檔 ID 1361107.1)

此報錯信息來源于11.2.0.1其中一個bug

Unpublished Bug 9703463 - ORA-3137 [12333] or ORA-600 [kpobav-1] When Using Bind Peeking

This bug affects versions 11.1.0.6, 11.1.0.7, and 11.2.0.1 of the RDBMS. It is fixed in version 11.2.0.2 of the database.

It can also occur intermittently; similarly to unpublished Bug:8625762, this is a bind peeking bug.

5.1、禁用Bind Peeking

SQL> alter system set "_optim_peek_user_binds"=false;

此參數為oracle的隱含參數

5.2、升級數據庫版本

此bug已在11.2.0.3以上版本修復，可升級此版本或更高

SQL> col ksppinm for a30

SQL> col ksppstvl for a30

SQL> col ksppdesc for a30

SQL> SELECT ksppinm, ksppstvl, ksppdesc FROM x$ksppi x, x$ksppcv y WHERE x.indx = y.indx AND ksppinm = '_optim_peek_user_binds';

查看隱含參數，此參數為開啟狀態

這里我最終選擇了禁用隱含參數，關閉特性之后，業務系統模塊已恢復，告警日志也不再出現報錯信息

后面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注下~