曲折的dump导入及问题分析(r5笔记第47天)
今天下午的时候得到反馈，说开发在导入一个dump的时候报了错误，他们尝试连接数据库，发现连接都有问题，让我们赶紧看看。这是一个测试环境的库，在服务器上同时还跑着十多个数据库不同应用的数据库实例。> sqlplus / as sysdbaSQL*Plus: Release 11.2.0.3.0 Production on Mon May 25 14:28:50 2015Copyright (c) 1982, 2011, Oracle. All rights reserved.ERROR:ORA-09817: Write to audit file failed.Linux-x86_64 Error: 28: No space left on deviceAdditional information: 12ORA-01075: you are currently logged on看这个错误是audit的部分无法写入了，可能是audit表占用的空间较大，也可能是系统空间不足导致。尝试登陆其它的几个库，也是类似的问题，这个时候问题一下子变得严重起来，需要赶紧修复。使用sysdba都无法登录，所以直接定位到日志目录还是有点困难的，这个时候我们可以借助参数文件，这个路径是固定的 $ORACLE_HOME/dbs下面，直接查看init.ora文件找到diagnostic_dest对应的路径。简单定位后，发现所在的分区系统空间不足了，发现归档文件占用了大部分的空间，这个时候需要尽快释放这部分的空间，一种思路就是把修改归档路径，但是这种方式可行但不值得提倡，这个环境会有很多人来维护，其中的参数和配置信息基本都是统一的，如果随意修改，后续的人来支持就会遇到一些问题，如此反复，简单的一个小问题就可能导致一些复杂潜在的问题，这个时候还是建议保留原值，但是可以考虑创建一个链接直接链接到空间比较充足的分区下。比如下面的例子就是创建一个链接 arc, 链接到 /oravl20/oradata/CNVxxxx/arc下面。ln -s /oravl20/oradata/CNVxxxx/arc arc这个错误比较明显，基本可以判定是由于数据问题导致的，但是数据抽取工具抽取的数据都是严格按照抽取逻辑来执行的，应该不会出现这种错误。这种问题一般来说DBA都不会直接确认都会直接交给开发自己去确认这类数据问题，今天因为问题比较急，就顺带查了一下。因为提供的日志信息有限，所以就马上连接到这套环境，找到对应的外键对应关系，做了两个简单的查询。
SQL> select count(*)from csm_ben;
COUNT(*)
----------
248
SQL> select count(*)from csm_account;
COUNT(*)
----------
0
这个时候看问题就比较明显了，很显然在外键列所在的表csm_account中竟然没有数据，为什么会出现这种问题,我也怀疑是不是dump出问题了，而只是从开发提供的一个ORA错误还是所知甚少。需要更多的信息来佐证。我们可以直接尝试把数据导入csm_account，做一个尝试，看看dump中是否丢失了这个表的数据。IMP-00058: ORACLE error 904 encountered
ORA-00904: "L9_xxxxxx_NO": invalid identifier
Import terminated successfully with warnings问题真是层出不穷，而且解决问题的思路都是类似的，为什么会出现这个问题，接下来改做些什么，开发会这么问我，我也会自问。最后排查得知，这套环境的版本很低，和现有的生产环境的版本相去甚远，所以这些额外的变更就不存在，这个时候就可以和开发确认，为什么要选用这套很老的环境，最后他们确认后，找了一套版本比较新的环境就没有问题了。从这个问题的处理来看，问题本身比较简单，处理思路也很简单，感觉每个问题都是一些很常规的处理方式，但是带给我们的反思就是很多简单的问题凑在一块儿，就可能是一个严重的问题，在问题的处理过程中，也需要明确分工和职责，有时候仅仅得到一个ora错误就去做全面的分析是远远不够的，还得结合环境和具体的场景，上面两个简单的问题从表面来看似乎都很明显，但是结合具体的处理场景来分析发现原因和错误提示信息还是有比较大的出入。