将Oracle ERP产品环境克隆到一个新的测试环境，是Oracle ERP DBA的日常工作。但是这次一个环境克隆到今天也没成功，遭遇了一波又一波的问题，只能用诡异来形容。
我们的产品环境服务器在各个省会城市，.而测试环境服务器则全部在北京，所以平时的操作是晚上业务可以停顿的时候，关闭数据库，然后将所有数据文件和客户化程序tar到磁带上，第二天省里面将磁带用快递送到北京，然后我们开始克隆测试环境。
关闭数据库，往磁带中tar文件，完毕以后再重新启动环境，这些都是通过脚本和crontab自动完成的。同样的操作已经成功运行了无数次。
但是这次：
1、第一天拿到磁带，作数据库clone的时候，报错说undo01.dbf找不到，然后发现磁带中根本没有没有这个文件，也就是备份的时候就出了问题，这个文件没有tar成功。最后发现原因是，HP的tar最多只能支持单个文件8G，而那个undo01.dbf在这次备份前因为需要导入大量数据而扩大到了10G，所以tar失败。
2、此时是第二天白天，无法down库，只能等到晚上12点以后，.开始用FTP直接从产品环境传输数据文件到测试环境。临晨4点登录系统发现FTP异常中止了，然后查看测试环境的文件系统，发现几乎100%空间占用，但是用du -sk却显示只使用了50G而已。
bdf的结果
/dev/hbvg01/lvhbdevdata 102432768 100529536 1888536 98% /heuat/data
du -sk 的结果
56461752 /heuat/data
反复检查，结果发现是删除原来测试环境中的数据文件时没有关闭Oracle的instance，导致磁盘空间没有释放。此时，不禁想，如果是Windows系统，那么instance打开的时候根本就不会允许删除数据文件，也就没这个问题了，所以，事务总有好和坏的两面。http://www.loveerp.com/
3、kill掉后台oracle进程，重新FTP剩余的数据文件，到早上8点，成功传输完毕，开始clone，将近10点的时候，clone结束，正在作最后的打扫工作，忽然登录数据库报错，查看数据文件，竟然发现有一堆数据文件的属主发生了变化，当时脑袋已经比较混沌了，.蒙了几分钟，然后ps后台的进程，结果发现有一个mv的进程，正在把其它位置的数据文件转移到我正在clone的这个环境中，立刻打电话给同事。。。.他的误操作覆盖掉了我刚刚做完的新数据库，彻底崩溃，我一个晚上的工作啊，又白费了，这个环境仍旧宣告clone失败。两个字评语，诡异!我不由又有些怀念Windows了。
然后就是一通疯狂的电话联系，跟这个人说明情况，跟那个人商量解决方法，一直搞到中午11点多，洗澡，睡觉。
本文整理: 爱ERP网 http://www.loveerp.com/
相关阅读：
Oracle ERP数据转换论…
解决Oracle ERP死锁的方法…
Oracle ERP中的财务管理…
详解Oracle ERP和SAP ERP种种异同…
SAP ERP 与 Oracle ERP 比较…
ORACLE ERP各个模块的缩写…
OracleERP产品功能架构
OracleERP系统实施步骤
Oracle ERP 系统模块功能概要…
Oracle ERP(EBS) 学习指南…
最新推荐：
| 发 表 评 论 |
新闻排行
资讯
热点
产品
签约
