背景：客户找到我们，反馈有一套10.2.0.4版本的Oracle数据库，运行在Solaris Sparc 10的HA架构上, 因为共享存储被写满与不恰当的操作（这是后来的Sun工程师确认），
金溪ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18982081108（备注：SSL证书合作）期待与您的合作！
导致数据库异常。查看环境时，共享存储不能被集群软件挂载，同时，数据库告警日志中除了归档日志写满的告警之外，未发现有其他错误。同时，存储工程师确认存储正常。
后续Sun主机工程师修复了挂载故障后发现，数据库的当前重做日志文件损坏，无法读取。于是，我们只有做了一次强制开库。
共享存储使用的是ZFS文件系统。
首先说明一下SMON的作用。初次恢复时，因为SMON的原因，数据库OPEN之后，还是会实例崩溃。后续增加了10061事件参数，_smon_internal_errlimit参数，导致
实例崩溃的错误就少了不少
实施local instance recovery
实施OPS/RAC instance recovery
服务于排序段sort segment申请
实施transaction recovery(rollback)
清理不再使用的临时段temporary segments
清理已经被aged out的游标所使用的临时表temporary tables
清理dead instance的临时表temporary tables
删除OBJ$基表上不再存在的对象记录
若index online rebuild失败，则负责清理ind$和indpart$
合并extents
在适当的时机收缩 rollback segment
在适当的实际offline rollback segment
恢复crash/instance recovery因datafile不可用(eg. offline)而跳过的dead transaction
恢复前台进程因为crash而造成的dead transaction
SMON的控制事件event列表：
event='10061 trace name context forever, level 10'禁用SMON清理临时段(disable SMON from cleaning temp segments)
event='10269 trace name context forever, level 10'来禁用SMON合并空闲区间(Don't do coalesces of free space in SMON)
event='10052 trace name context forever'来禁止SMON清理obj$基表
设置隐藏参数_column_tracking_level(column usage tracking)，该参数默认为1即启用column使用情况跟踪。设置该参数为0，将禁用column tracking
events '10513 trace name context forever, level 2';设置10513事件来临时禁止SMON恢复死事务，这在我们做某些异常恢复的时候显得异常有效，当然不建议在一个正常的生产环境中设置这个事件
event='8105 trace name context forever'来禁止SMON清理IND$(Oracle event to turn off smon cleanup for online index build)
events '12500 trace name context forever, level 10';可以在设置了12500事件后手动删除SMON_SCN_TIME上的记录，重启实例后SMON会继续正常更新SMON_SCN_TIME。
event='10511 trace name context forever, level 1'来禁用SMON OFFLINE UNDO SEGS; 但是10511事件不会跳过”Fast Ramp Up”，而仅会限制SMON对UNDO SEGS产生的工作负载。 一旦设置了10511 event， 则所有已生成的 UNDO SEGS会始终保持ONLINE状态。
event='10512 trace name context forever,level 1' 禁用SMON shrink rollback segment
event='10510 trace name context forever,level 1' 禁用检测以便offline rollback
参考：https://www.cnblogs.com/macleanoracle/archive/2013/03/19/2968335.html
使用的参数文件：
*._allow_resetlogs_corruption=TRUE
*.audit_file_dest='/opt/oracle/app/admin/orcl/adump'
*.background_dump_dest='/opt/oracle/app/admin/orcl/bdump'
*.compatible='10.2.0.3.0'
*.control_files='/dataora/orcl/control01.ctl','/dataora/orcl/control02.ctl','/dataora/orcl/control03.ctl'
*.core_dump_dest='/opt/oracle/app/admin/orcl/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='orcl'
*.db_recovery_file_dest='/orapool/dataora/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.job_queue_processes=0
*.log_archive_dest_1='location=/orapool/dataora/arch'
*.open_cursors=30000
*.pga_aggregate_target=3424649216
*.processes=1500
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=1655
*.sga_target=1610612736
*.sort_area_size=5242880
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.fast_start_parallel_rollback=FALSE
*.user_dump_dest='/opt/oracle/app/admin/orcl/udump'
event='10061 trace name context forever, level 10'
_smon_internal_errlimit=1000000
1. 恢复数据库
recover database until cancel;
alter database open resetlogs;
2. 导出后遇到错误
ORACLE Instance orcl (pid = 11) - Error 600 encountered while recovering transaction (3, 20) on object 658092.
Sat Jan 25 11:09:23 2020
Errors in file /opt/oracle/app/admin/orcl/bdump/orcl_smon_15656.trc:
ORA-00600: internal error code, arguments: [6006], [1], [], [], [], [], [], []
重建了索引：
Database mounted.
Database opened.
SQL> select owner, object_name, object_type from dba_objects where object_id = 658092;
OWNER
------------------------------
OBJECT_NAME
--------------------------------------------------------------------------------
OBJECT_TYPE
-------------------
SCOTT
IND_TEST
INDEX
SQL>
SQL> alter index scott.IND_TEST rebuild;
Index altered.
参考：https://www.eygle.com/archives/2011/07/ora-600_6006_recovery.html
3.导出数据，重建数据库
4.导出数据
nohup exp \'/ as sysdba\' file=/new2-orapool/orcl_20200125_test.dmp owner=test &
5. 重建数据库，校验数据，业务恢复
