今早在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的部分停止了一部分，之后就没有再出现这个日志文件。