今天比较郁闷的说，周末一个人在yh局里干活。
问题起因：项目部兄弟们说前置机通讯服务提示说异常数据保存异常，shit,又不知道是什么错误。
检查发现表空间是刚加过的，手工insert也是没有问题的。通讯服务里面提示任务和异常数据都保存异常。很奇怪的说，按道理这个两个表在不同的表空间，就算是空间问题也不太可能这么巧吖，难道是索引问题？
查过来查过去也没搞聆清问题在哪里，那就应该不是数据库的问题咯?alert.log也没有报告任何错误。
select * from dba_data_files,突然发现不太对，索引表有个文件和别的文件放的路径不统一，连到主机上查看。
shit,居然根本就没有那个文件，数据库居然还显示文件为available,因为该文件为索引表空间下的数据文件，为确认问题，手工create index，果然提示错误，不能访问该文件。物理文件根本就不存在了马晕哟，立马问添加数据文件的管理员是怎么回事，果如所料，在添加了该文件后发现路径不对，然后又在数据库关闭状态下删除了改物理文件。
为了进一步确认问题，又把开发人员找来，抛出保存异常时的oracle错误信息，正是这个文件罪魁祸首。
现在来解决问题：
(1) 找出该文件中存在对象select * from dba_extents where file_id=43;这里是几个索引
(2)删除索引－－－原一个简单的操作居然花了一个晚上的时间，真是郁闷，就因为索引的存储参数设置得不够合理（ｎｅｘｔ ２４Ｋ），最大的一个索引有８万多个分区。在Ｄｉｃｔｉｏｎａｒｙ管理模式下，系统回收空间真ｔｍｄ的慢哟
（３）好不容易干掉了索引，终于可以ｄｒｏｐ那个文件了
（４）ａｌｔｅｒ ｄａｔａｂａｓｅ ｄａｔａｆｉｌｅ ＇ｘｘｘｘ＇ ｏｆｆｌｉｎｅ ｄｒｏｐ；好，最郁闷的事情发生了，执行结果显示ｄａｔａｂａｓｅ ａｌｔｅｒｅｄ．再ｓｅｌｅｃｔ ＊ ｆｒｏｍ ｄｂａ＿ｄａｔａ＿ｆｉｌｅｓ ｗｈｅｒｅ ｆｉｌｅ＿ｉｄ＝４３
居然看到那个文件居然还是ａｖａｉｌａｂｌｅ！！！！！！ｓｈｉｔ，无法相信的事实，重新执行一遍，还是如此。我信他的邪。软的不行换硬的，ｓｈｕｔｄｏｗｎ，ｓｔａｒｔｕｐ ｍｏｕｎｔ，再执行ｏｆｆｌｉｎｅ ｄｒｏｐ操作。我丢，咋回事哟。搞不明白了。
这个时候数据库能够正常ｏｐｅｎ，ｓｈｕｔｄｏｗｎ？？？？？
网上搜索，问兄弟们都没有找到解决办法。
无奈之下，只有出狠招了，ｄｒｏｐ ｔａｂｌｅｓｐａｃｅ，一条语句下去已经６个小时了还没有执行完（索引已经全部ｄｒｏｐ）。ｅｎｑｕｅｕｅ＋ｌａｔｃｈ ｆｒｅｅ等待着。
ｄｅｌｅｔｅ ｆｒｏｍ ＄ｆｅｔ，也不知道撒时能完成。只有明天接着干了，希望明天早上能ｄｒｏｐ掉，再把索引重建就ＯＫ了。这个周末是黄了，这么好的天气，正好和ｍｍ到西湖喝茶的时候．．．．．．ｓｉｇｈ
——继续昨天
早晨过来发现索引已经建好了，OK,开启前置机程序，没有提示错误。至此问题总算得到解决。欣喜之余，不由得
庆幸还好这次是索引表空间除了问题，否则就麻烦了（没有物理备份）！。
只可惜好好的周末没了...晚上加班觉也没有睡好......
1 Comment to “offline drop 不起作用？–yh出差记”
Write a comment
You need tologin.
shit
两个人都是碰到莫名其妙的问题