数据安全高于一切

    单位一直用Landmark2003，其中一台机器有重点工区项目，多个解释员同时登录该机干活。

    一天，井工区突然坏掉了，提示某某oracle文件丢失，无法连接数据库。为不影响生产，赶紧重装LM2003，恢复工区数据库，折腾半个多时辰，终于搞定了。

 

    通过这次故障恢复，总结以下几点体会：

 

1、定期备份工区数据是重中之重（备份oracle、OW_PROJ_DATA和地震工区目录）；

 

2、由于LM软件介质问题（D版），无法对oracle表空间进行排错操作，只能重装LM软件，因而排错效率不是很高；

 

3、对全新安装的LM软件，可以备份一下OpenWorks、oracle和oracle8目录（必须关闭数据库后再备份），以备以后遇到类似问题时可提高排错效率；

 

4、对恢复后的LM工区目录要保持其属主和属组的正确性（如：ow2003用户，工区属主为ow2003，属组为dba），以便工区数据能正常存取；

 

5、恢复井工区时，先换名并设置环境变量。即：在兰马用户下的terminal窗口，敲 setenv OW_ALLOW_IMPORT_ERRORS yes 回车；在同一窗口输入 admprj 回车，打开工区管理工具，恢复换名井工区。如果待恢复的oracle数据大于400MB，则点Advanced选项，手工输入适合的大小（虽然有过用Novice选项成功恢复500MB的数据，但为保险起见，还是强烈建议用Advanced选项，同时检查一下 $OWHOME/conf/lgcenv.cf文件，确保要打开autoextend选项），试恢复一下，看能否成功，如果因备份数据内部错误无法恢复时，可尝试用另一个备份版本来恢复，这样可避免因恢复失败而无法删除已用井工区名，从而导致无法使用同名井工区的现象，当试恢复成功后，再以上述方法恢复同名井工区，并将测试工区删除；

 

6、系统管理员应经常运行工区tune，然后进入 Seismic Project Manager-->SeisWorks Fault Data Manager，在File菜单下，运行 Clean Fault Data 批量清除损坏的断层数据；运行Delete Statistics清除tune统计信息（以提高SeisWorks断层检索性能），应用这些操作可降低数据库出错的几率。

 

    经历此事后，出于数据安全考虑，将该机上的LM2003工区迁移到了另一台配置较高的Dell T7500的R5000.8上，但由于解释员们对R5000还不熟，且R5000本身有许多bug，所以不敢将该机用于生产机器，于是将该机上的RHEL5.5和R5000删除，重新安装RHEL4.6和LM2003，并在该机上恢复生产工区。运行后比原来的机器快多了。

 

    还有一次，同一台机器，当打开工区session时，提示无法初始化地震工区，即打不开3D地震工区了。

 

    以下是解决办法，如3D工区名为A：

1、将地震工区目录改名为A.bak；

 

2、进入地震工区管理器，删除地震工区A；

 

3、新建同名地震工区，然后将工区目录改名为A.new；

 

4、在当前目录下建一个A_3dv目录，将A.bak里的.3dv、.3dh、.bri文件暂时mv到A_3dv目录里，然后备份一下A.bak目录，如：cp -r A.bak A.bak.bak（这时因移除了上述文件，目录已经很小了）。备份A.bak目录是为了保险起见；

 

5、将A.new目录中的层位索引文件改名或删除（如：yd3d_12.hrz，目的是防止覆盖A.bak目录中的同名层位索引文件yd3d_12.hrz），然后将目录中的所有文件复制到A.bak目录中，再将A_3dv目录中的文件移回A.bak目录中；

 

6、将A.bak改回原名A，这时选SeisWorks 3D工区，打开保存的session，一切正常。然后将无关目录删除。以上操作看起来有些繁琐，但为安全起见还是值得的。

    有了这两次经历后，一改以前只手工备份的作法，改用脚本每天自动备份工区数据，并把数据放在稳定可靠的储存介质上。关于脚本自动备份的内容，本博客有介绍（Landmark工区自动备份实例:  http://blog.chinaunix.net/uid-124509-id-3069622.html ）。