分类：
2008-10-27 14:27:40
将 ERP产品环境克隆到一个新的环境，是 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，导致磁盘空间没有释放。此时，不禁想，如果是系统，那么instance打开的时候根本就不会允许删除数据文件，也就没这个问题了，所以，事务总有好和坏的两面。
3。kill掉后台oracle进程，重新FTP剩余的数据文件，到早上8点，成功传输完毕，开始clone，将近10点的时候，clone结束，正在作最后的打扫工作，忽然登录数据库报错，查看数据文件，竟然发现有一堆数据文件的属主发生了变化，当时脑袋已经比较混沌了，蒙了几分钟，然后ps后台的进程，结果发现有一个mv的进程，正在把其它位置的数据文件转移到我正在clone的这个环境中，立刻打电话给同事。。。他的误操作覆盖掉了我刚刚做完的新数据库，彻底崩溃，我一个晚上的工作啊，又白费了，这个环境仍旧宣告clone失败。两个字评语，诡异!我不由又有些怀念了。
