有關SQL ID with large Version Count encountered.

今早在bdump下面發現生成*m000*.arc，每個小時生成一次，內容大致相同：

/home/oracle/admin/newadm/bdump/newadm_m000_12663.trc
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /home/oracle/product/10.1.0/db_1
System name:    Linux
Node name:      bj
Release:        2.4.21-20.ELsmp
Version:        #1 SMP Wed Aug 18 20:46:40 EDT 2004
Machine:        i686
Instance name: newadm
Redo thread mounted by this instance: 1
Oracle process number: 32
Unix process pid: 12663, image: oracle@bj (m000)

*** ACTION NAME:(Auto-Flush Slave Action) 2005-06-01 13:00:25.412
*** MODULE NAME:(MMON_SLAVE) 2005-06-01 13:00:25.412
*** SERVICE NAME:(SYS$BACKGROUND) 2005-06-01 13:00:25.412
*** SESSION ID:(231.35338) 2005-06-01 13:00:25.412
SQL ID with large Version Count encountered.
SQL Id: 8r1dp0zt91gm9
  Version Count: 237, Parse Calls: 0, Shareable Mem: 7199871
  Elapsed Time: 0, CPU Time: 0, Executions: 0
  Disk reads: 0, Buffer Gets: 0, I/O Wait Class: 0
  Application WC: 0, Concurrency WC: 0, Cluster WC: 0
SQL ID with large Version Count encountered.
SQL Id: 3yhgrrdznkvqf
  Version Count: 236, Parse Calls: 0, Shareable Mem: 7213340
  Elapsed Time: 0, CPU Time: 0, Executions: 0
  Disk reads: 0, Buffer Gets: 0, I/O Wait Class: 0
  Application WC: 0, Concurrency WC: 0, Cluster WC: 0
 
在alert.log中沒有發現任何異常，也沒有應用程式反映錯誤，當前也沒有任何正在執行的程式或者批處理的任務。
警告檔案從5月26日的夜裡10：00開始寫，每次的內容都是一樣的。
在v&sql和v$sqlarea中沒有找到對應的sql_id的紀錄。

在網上查到有人提到Version Count的問題是8.1.7.4的ｂｕｇ，修改timed_statistics=false就可以解決，修改了這個引數，
但是仍然有問題，而且８ｉ的ｂｕｇ怎麼會到１０ｇ了還出現了，應該不是這個問題吧。

暫時沒有發現解決辦法，在metalink上發了帖子詢問，還沒有得到回覆。

早上繼續察看有關的文件，發現這個文章中提到的BUG和我的現象類似：
http://support.oracle.com.sg/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=296765.1
http://support.oracle.com.sg/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=3941893.8
需要打patch到10.1.0.4或者升級到10.2解決。

在metalink上我的問題有人回覆，請檢視V$SQL_SHARED_CURSOR以獲得更多資訊：
根據SQL_ID檢視V$SQL_SHARED_CURSOR檢視，可以看到相同的SQL_ID的確有很多的child_address對應，除了OPTIMIZER_MISMATCH欄位='Y',
其他欄位的值都是'N'，還沒有進一步的解決辦法。
這篇文章提到有關V$SQL_SHARED_CURSOR的說明：
http://support.oracle.com.sg/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=120655.1
其中：
OPTIMIZER_MISMATCH
 VARCHAR2(1)
 (Y|N) The optimizer environment does not match the existing child cursor
 
 
我按照上面提到的bug的解決方案，進行了一些修改：
SQL> alter session set events 'immediate trace name awr_flush_table_off level 12';

Session altered.

SQL>
SQL>  alter session set events 'immediate trace name awr_flush_table_off level 13';

Session altered.

SQL>
SQL>  alter session set events 'immediate trace name awr_flush_table_off level 15';

Session altered.

SQL>
 alter session set events 'immediate trace name awr_flush_table_off level 56';
SQL>
Session altered.

SQL>
 alter session set events 'immediate trace name awr_flush_table_off level 64';
SQL>
Session altered.

將AWR中定期收集SQL的部分停止了一部分，之後就沒有再出現這個日誌檔案。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/51862/viewspace-180642/，如需轉載，請註明出處，否則將追究法律責任。