温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

Oracle-真实环境的丢失current redo log file的故障恢复

发布时间:2020-08-13 13:35:10 来源:ITPUB博客 阅读:194 作者:abstractcyj 栏目:关系型数据库

背景:客户找到我们,反馈有一套10.2.0.4版本的Oracle数据库,运行在Solaris Sparc 10的HA架构上, 因为共享存储被写满与不恰当的操作(这是后来的Sun工程师确认),

导致数据库异常。查看环境时,共享存储不能被集群软件挂载,同时,数据库告警日志中除了归档日志写满的告警之外,未发现有其他错误。同时,存储工程师确认存储正常。

后续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. 重建数据库,校验数据,业务恢复

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI