【故障】EXP-00056: ORACLE error 1466 encountered

EXP-00056: ORACLE error 1466 encountered

ORA-01466: unable to read data - table definition has changed

• Sense:2016年4月创金合信基金DB-EXP导出表过程后台日志出现如下告警和错误：

• why?
• SMON进程维护SMON_SCN_TIME数据字典基表，导致在EXP导出数据的过程中发生针对数据字典基表的DDL操作。因为在EXP的过程中，export导出程序会首先读取部分数据字典基表来定位要导出的数据的概况。但是，很可能在导出过程的某个时间点SMON会去维护SMON_SCN_TIME数据字典基表，使得export程序读取的基表发生DML变化，由此引发ORACLE ORA-1466错误。

• 针对运维人员和部分DBA的疑问在于该错误时常出现，但是并不是规律性的常规性错误。原因在于SMON维护SMON_SCN_TIME等数据字典基表的时间点不是常规性的，而是根据一定的频率和数据库的统计状态（SCN）进行维护操作。故此，当频率和数据库状态两者完全符合，SMON就会发起维护数据字典基表的任务。所以DBA仅仅从EXP的导出日志查看相关表的DDL，无异于缘木求鱼。
• 在创金合信数据库版本Release 11.2.0.4.0 Production Version，我们可以通过Oracle内部错误guide工具来初步的判定出现故障或者问题的原因：

• 
  

  根据guide ORA-信息可以验证我们基于直观的EXP日志文件的故障诊断猜测，我们猜对了：）

• SMON（系统监视器）后台进程的作用还有不为人知的维护SMON_SCN_TIME数据字典基表

• SMON_SCN_TIME基表用于记录过去时间段中SCN(system change number)与具体的时间戳(timestamp)之间的映射关系，因为Oracle是采样记录这种映射关系，所以SMON_SCN_TIME可以较为粗糙地(不精确地)定位某个SCN的时间信息。实际的SMON_SCN_TIME映射是一张cluster table簇表。
• SMON_SCN_TIME时间映射表最大的用途是为闪回类型的查询(flashback type queries)提供一种将时间映射为SCN的途径(The SMON scn time mapping is mainly for flashback type queries to map a time to an SCN)。
• Metalink文档<Error ORA-01466 while executing a flashback query. [ID 281510.1]>介绍了SMON更新SMON_SCN_TIME的规律：

1. 在版本10g中SMON_SCN_TIME每6秒钟被更新一次(In Oracle Database 10g, smon_scn_time is updated every 6 seconds hence that is the minimum time that the flashback query time needs to be behind the timestamp of the first change to the table.)
2. 在版本9.2中SMON_SCN_TIME每5分钟被更新一次(In Oracle Database 9.2, smon_scn_time is updated every 5 minutes hence the required delay between the flashback time and table properties change is at least 5 minutes.)

• 另外从10g开始SMON也会清理SMON_SCN_TIME中的记录，SMON后台进程会每5分钟被唤醒一次，检查SMON_SCN_TIME在磁盘上的映射记录总数，若总数超过144000条，则会使用以下语句删除最老的一条记录(time_mp最小): 若仅仅删除一条记录不足以获得足够的空间，那么SMON会反复多次执行以上DELETE语句。

• SMON 维护SMON_SCN_TIME的触发场景
  

• 虽然Metalink文档<Error ORA-01466 while executing a flashback query. [ID 281510.1]>指出了在10g中SMON会以每6秒一次的频率更新SMON_SCN_TIME基表，但是实际观测可以发现更新频率与SCN的增长速率相关，在较为繁忙的实例中SCN上升极快时SMON可能会以6秒一次的最短间隔频率更新，但是在空闲的实例中SCN增长较慢，但仍会以每5或10分钟一次的频率更新，例如：

• 在ora11g_smon_3922.trc跟踪文件中找出SMON进程insert数据到SMON_SCN_TIME映射表的记录如下，我们可以发现其更新频率:

• 可以通过以上INSERT语句的TIME_DP绑定变量值发现其更新SMON_SCN_TIME的时间规律，一般为5或10分钟一次。这说明SMON_SCN_TIME的更细频率与数据库实例的负载有关，更为贴切的说是与SCN的生成速度有关，其最短的间隔是每6秒一次，最长的间隔为10分钟一次。具体请见附件trace文件。
• SMON维护SMON_SCN_TIME时相关的Stack CALL，ktf_scn_time是更新SMON_SCN_TIME的主要函数,但是11G的11.2.0.4版本的SMON跟踪文件中并没有相关的函数记录，如果使用10046高级别的跟踪事件，我们会在相关的追踪文件中发现处理函数的调用状态。
• 根据My Oracle Support支持文档，可以发现因SMON_SCN_TIME更新而引起的数据库错误有十分经典的案例。例如以下的两则，来源于MOS官方支持：
• 由于SMON_SCN_TIME的更新频率问题可能引起ORA-01466错误，详见:Error ORA-01466 while executing a flashback query. [ID 281510.1]
• 由于SMON_SCN_TIME数据不一致可能引起ORA-00600[6711]或频繁地执行”delete from smon_scn_time”删除语句，详见：ORA-00600[6711]错误一例 High Executions Of Statement “delete from smon_scn_time…” [ID 375401.1]
• SMON 还可能使用以下SQL语句维护SMON_SCN_TIME字典基表:

• 查询映射表的统计状态如下所示：

?

• 如何禁止SMON更新SMON_SCN_TIME基表

• 可以通过设置诊断事件events=’12500 trace name context forever, level 10’来禁止SMON更新SMON_SCN_TIME基表(Setting the 12500 event at system level should stop SMON from updating the SMON_SCN_TIME table.):

• 一般我们不推荐禁止SMON更新SMON_SCN_TIME基表，因为这样会影响flashback Query闪回查询的正常使用，但是在某些异常恢复的场景中SMON_SCN_TIME数据讹误可能导致实例的Crash，那么可以利用以上12500事件做到不触发SMON_SCN_TIME被更新。
• 如何手动清除SMON_SCN_TIME的数据

• 因为SMON_SCN_TIME不是bootstrap自举核心对象，所以DBA可以手动更新该表上的数据、及重建其索引。尤其需要注意的是，当SMON_SCN_TIME表中的数据和其索引中的数据不一致时会造成一些比较严重的后果，所以其索引的状态是否一致也是需要我们关注的核心问题，例如delete语句无法删除表中的记录问题，此时可以通过重新创建索引来解决。
  

• 可以在设置了12500事件后手动删除SMON_SCN_TIME上的记录，重启实例后SMON会继续正常更新SMON_SCN_TIME。除非是因为SMON_SCN_TIME表上的记录与索引smon_scn_time_tim_idx或smon_scn_time_scn_idx上的不一致造成DELETE语句无法有效删除该表上的记录:文档<LOCK ON SYS.SMON_SCN_TIME [ID 747745.1]>说明了该问题，否则我们没有必要手动清除SMON_SCN_TIME的数据。
• 具体的操作步骤如下所示：

?

?

原文：http://askerain.iteye.com/blog/2294590