资讯专栏INFORMATION COLUMN

上云采购季！| 爆款云服务器低至4.6元/月，首单享0.9折

免费试用
首页/文章专栏/Oracle的块改变跟踪引发的宕库案例

Oracle的块改变跟踪引发的宕库案例

IT那活儿 / 436人阅读
Oracle的块改变跟踪引发的宕库案例
  背  景 

某天晚上22点16分左右，收到了一个RAC数据库两节点的所有实例宕库告警，登录服务器，启动数据库时，数据库open失败。


处理过程

1、排查alert日志，日志中发现了ora-600报错，信息如下：

▼▼▼
Mem# 1: +DG_DATA_SSD_1/NSFDB/ONLINELOG/group_4.272.1008028019
2021-01-04T22:26:37.030965+08:00
OS process OFSD (ospid 5144) idle for 30 seconds, exiting
2021-01-04T22:26:38.543347+08:00
Errors in file /u01/app/oracle/diag/rdbms/nsfdb/nsfdb1/trace/nsfdb1_ora_20131.trc  (incident=993166):
ORA-00600: internal error code, arguments: [krccfl_chunk], [0x9FFFFFFFBDE54DF0], [2], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/nsfdb/nsfdb1/incident/incdir_993166/nsfdb1_ora_20131_i993166.trc
2021-01-04T22:26:40.532334+08:00
Dumping diagnostic data in directory=[cdmp_20210104222640], requested by (instance=1, osid=2298720), summary=[incident=993166].
2、登录mos网站，搜索ora-600报错

匹配到了一个文章“Ora-600 Krccfl_chunk When Block Change Tracking enabled (Doc ID 2046745.1)”

文章中提到了“Backup change tracking is enabled，Datafile in Rac added to local destination rather then shared location and later taken offline”，出现了Ora-600 Krccfl_chunk报错，需要先禁用块改变跟踪，才能open数据库。

3、检查alert日志最近的中是否有数据文件offline/online的操作

节点1

▼▼▼
2021-01-04T20:11:39.709767+08:00
alter database datafile +DG_DATA_SSD_2/NSFDB/DATAFILE/tbs_data.282.1060977401 online
Completed: alter database datafile +DG_DATA_SSD_2/NSFDB/DATAFILE/tbs_data.282.1060977401 online
2021-01-04T20:13:15.647462+08:00
Thread 1 advanced to log sequence 68674 (LGWR switch)
  Current log# 4 seq# 68674 mem# 0: +DG_DATA_SSD_1/NSFDB/ONLINELOG/group_4.271.1008028017
  Current log# 4 seq# 68674 mem# 1: +DG_DATA_SSD_1/NSFDB/ONLINELOG/group_4.272.1008028019
2021-01-04T20:13:16.273721+08:00

节点2

▼▼▼
2021-01-04T19:46:14.210687+08:00
alter tablespace TBS_DATA add datafileDG_DATA_SSD_2 size 30g autoextend off
ORA-1537 signalled during: alter tablespace TBS_DATA add datafileDG_DATA_SSD_2 size 30g autoextend off...
2021-01-04T19:46:21.320437+08:00
alter tablespace TBS_DATA add datafileDG_DATA_SSD_2 size 30g autoextend off
ORA-1537 signalled during: alter tablespace TBS_DATA add datafileDG_DATA_SSD_2 size 30g autoextend off...
2021-01-04T19:51:10.043864+08:00
2021-01-04T19:56:41.886951+08:00
ALTER DATABASE MOVE DATAFILE /u01/app/oracle/product/12.2.0/db_1/dbs/DG_DATA_SSD_2  TO +DG_DATA_SSD_2
2021-01-04T19:56:41.908716+08:00
Moving datafile /u01/app/oracle/product/12.2.0/db_1/dbs/DG_DATA_SSD_2 (686) to +DG_DATA_SSD_2
2021-01-04T20:00:11.018835+08:00
Thread 2 advanced to log sequence 54383 (LGWR switch)
  Current log# 5 seq# 54383 mem# 0: +DG_DATA_SSD_1/NSFDB/ONLINELOG/group_5.273.1008028023
  Current log# 5 seq# 54383 mem# 1: +DG_DATA_SSD_1/NSFDB/ONLINELOG/group_5.274.1008028025
2021-01-04T20:00:11.726628+08:00
TT02: Standby redo logfile selected for thread 2 sequence 54383 for destination LOG_ARCHIVE_DEST_2
2021-01-04T20:00:16.340789+08:00
Archived Log entry 178702 added for T-2.S-54382 ID 0x5a823d6f LAD:1
2021-01-04T20:01:29.321397+08:00
Move operation committed for file +DG_DATA_SSD_2/NSFDB/DATAFILE/tbs_data.282.1060977401
2021-01-04T20:01:31.385729+08:00
Completed: ALTER DATABASE MOVE DATAFILE /u01/app/oracle/product/12.2.0/db_1/dbs/DG_DATA_SSD_2  TO +DG_DATA_SSD_2

咨询了项目组同事，确认了操作时间和操作步骤都符合


问题原因

1、在alert日志中发现，最近有添加数据文件操作，但在添加文件时，磁盘组名字前面的”+”忘记添加了，数据文件添加到了本地，还好这一个12.2.0.1的库，使用了”move tablespace online“的新特性，把数据文件在线移动到了磁盘组中。但是这个操作却没有在块改变跟踪信息中体现。

22点定时备份任务开始启动，数据库备份时读取块改变跟踪的记录文件时，因为读不到了在本地添加的数据文件，触发了数据库数据保护机制，从而导致数据库实例cash掉。

2、那就根据文章中的提供的workaround，先启动实例到mount，再执行如下命令：

alter database disable block change tracking;

alter database open;

alter database enable block change tracking using file ‘+磁盘组名称/文件名’;

注意：以前的块改变跟踪信息因为disable/enable操作丢失了，需要重新进行一次0级备份之后，块改变跟踪信息才能生效。


改进措施

  1. 增加操作审核，避免误操作

  2. 在使用Move table online操作时，要注意块改变跟踪的问题。


END


更多精彩干货分享

点击下方名片关注

IT那活儿

服务器托管 GPU服务器 PPAS oracle跟踪工具 引发了 路由跟踪 跟踪路由

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129900.html

相关文章

  • Oracle最佳连接方式之service最佳实践及测试（下）

    Oracle最佳连接方式之service最佳实践及测试（下） img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%...

    IT那活儿 评论0 收藏1656

  • 云数据存储需要协助解决数据成本困境

    摘要：云消费者需要协助管理数据成本，四个战略已经形成，协助他们解决这些成本窘境。对云数据存储使用摘要数据库。在云端存储数据永远也不可能比在一个编写的硬盘上存储数据便宜，但是利用云存储这项技术的优势可能会给购买者最佳的成本和最高的投入产出比。云数据存储的高成本粉碎了企业公有云业务案例的梦想。一些企业表示他们可以以和按月云存储和用例费用相同的成本购买到硬盘。但对云消费者而言，可能很难搞清楚价格差异到底...

    trilever 评论0 收藏0

  • 看主流云数据存储怎么“整”最划算？

    摘要：云数据存储的高成本粉碎了企业公有云业务案例的梦想。企业认为访问云数据迫使他们扩展连接速度，为了避免拥挤。对云数据存储使用摘要数据库。这样就将库存项目脱离了云存储。 云数据存储的高成本粉碎了企业公有云业务案例的梦想。一些企业表示他们可以以和按月云存储和用例费用相同的成本购买到硬盘。同时微软和谷歌免费赠送其SkyDrive和Google Drive服务。云消费者可能发现很难搞清楚价格差异到底体...

    ZoomQuiet 评论0 收藏0

  • 由for update引发的血案

    摘要：微信公众号后端进阶，专注后端技术分享框架分布式中间件服务治理等等。 微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！ 公司的某些业务用到了数据库的悲观锁 for update，但有些同事没有把 for update 放在 Spring 事务中执行，在并发场景下发生了严重的线程阻...

    roundstones 评论0 收藏0

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<