点击上方蓝字关注我们～
我们的文章会在微信公众号“Oracle恢复实录”和博客网站“rescureora.com” 同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
2017年1月的一天早上刚起床，接到老同事的电话说“客户核心系统数据库启动时报ORA-00600: internal error code, arguments: [16703], [1403], [20]的错误，客户只是在昨天晚上例行维护重启主机后数据库就不能启动，目前已经请Oracle原厂工程师（随后知道是代理商派的人，以Oracle原厂的名义过去）过来分析，但还没有找到原因。希望兄弟能友情帮忙支持一下”。这是一起睡过的男人的电话，必须要给兄弟扎起。
ORA-00600 16703错误，以放电影式的快速在脑中扫描一遍自己的知识点。不妙，没有一点印象。立马拿起自己的thinkpad，打开自己的mybase笔记，在搜索栏中输入16703，几秒后结果让自己瞬间失望，没有找到任何记录。继续在MYBASE中找到ORA-00600的目录，从每个笔记的命名再捋了几遍，确认自己的笔记中没有16703的记录。打开SS软件，在chrome中输入ORA-00600 16703错误，竟然没有搜到任何内容。打开bing，baidu也是无结果，再打开mos，一样的没有任何实质的内容。
此时心中是兴奋的，兴奋今天又有新技术可以研究，同时心中也是失落的，意味着不能马上帮朋友解决问题。下班后，兄弟所在公司安排专车过来，直接接到客户现场，那是一个离市区40公里的地方。通过拜访甲方DBA和甲方领导汇报一下工作，在汇报中，领导问：“需要多久恢复”，我说：“不知道，还没有具体分析”，领导突然来句“几十万没有了”。多一天就是损失10W+，吓得我突然不知道说，此时感觉天要塌了一样，心中突然想回家了，这个忙不帮了。细心的兄弟发现了我的变化，应了一句”原厂的都来了，没有分析出原因，我们一定尽快分析出原因并给出解决方案，请给我们一点时间”。通过几个小时的奋战，终于将客户的数据成功恢复。凌晨时分，跟兄弟的一个烧烤结束这场友情的支持。回到家中，久久不能入睡，直接将复制下来的日志和操作记录全部整理到Mybase笔记中，此时困意已来，但是天慢慢的亮了，困意也随着天亮慢慢的散去，新的一天工作继续，背起全家的家当（thinkpad）去客户现场上班，期待着今天又能遇到意想不到的故障。
2019年1月，一月意味着新的一年开始。新年新气象，一句一直在骗我们的话，但是我们还是每年都在说。这天，也是一位过去的同事打电话说”某客户在阿里云上的数据库启动时出现ORA-00600 16703错误“，此时立马想到原因，因为从17年后，网上出现大量的ORA-00600 16703的错误和故障原因，大致的解决方案都写得很清楚。我Mybase中的那篇日志，我已经好久没有和它见面了，不太记得里面的内容，但是对当时的激动心情还记忆犹新。有了上次的经验和本次在阿里云上的特殊性，此时故障仅用了1个小时，帮朋友解决问题。这次时间有点短、又是云上环境，连撸串的机会都没有。
ORA-00600 16703错误，算是很经典的错误，也是一个“人为故意的错误”，该故障的原因在网上有非常详细的介绍，不在此中说明。但是故障的解决方案，网上都只有简单的描述性文字或者非常简陋的一些名字，还不足以让一个中级DBA照着可以完成恢复。在最近的几期文章分享中，我们将详细介绍ORA-00600 16703错误的几种恢复方法，某些方法可能很极端、某些方法也可能需要在特殊的环境中才能遇到。
今天我们总结了TAB$表被清空后，可能遇到哪些报错或者在修复tab$过程中会遇到哪些报错，让大家通过错误代码能立马想到方向点。
alert日志内容如下：
2020-01-16T17:45:54.194717+08:00
Errors in file oracle/app/oracle/diag/rdbms/rescureora/rescureora/trace/rescureora_mz00_27044.trc (incident=17209) (PDBNAME=CDB$ROOT):
ORA-00600: internal error code, arguments: [kdfReserveSingle_1], [0], [65280], [], [], [], [], [], [], [], [], []
Incident details in: /oracle/app/oracle/diag/rdbms/rescureora/rescureora/incident/incdir_17209/rescureora_mz00_27044_i17209.trc
2020-01-16T17:45:56.379402+08:00
Errors in file oracle/app/oracle/diag/rdbms/rescureora/rescureora/trace/rescureora_mz03_27084.trc:
ORA-00600: internal error code, arguments: [insSetOpnInfo:0], [2], [2], [], [], [], [], [], [], [], [], []
这个错误是由于数据库启动后tab$被清空，导致后台的进程mz00报错。此环境是12C的环境。
alert日志内容如下：
这个错误是由于tab$被清空后，数据库重启过程中在tab$中未发现data object id为20的表的记录出发的报错。
报错信息如下：
此错误跟16703错误是一样。
日志信息如下：
此错误也是由于tab$表中缺少记录导致。但是这个看似是一条insert语句触发的报错，并且此时数据库已经是open write了，所以到这个时候，我们已经看到曙光，并且解决方案也很多，会在后面逐一说明的。
报错信息如下：
此错误是由于tab$中表的记录的部分列的值不正确导致。
今天我们列举了TAB$表被恶意清空后，可能遇到哪些报错和在修复tab$过程中会遇到哪些报错，我们将在后面给大家带来详细的分析过程和解决方案，敬请期待！
Oracle恢复实录
rescureora.com
欢迎扫码关注
让我知道你在看
