将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打开的时候根本就不会允许删除数据文件，也就没这个问题了，所以，事务总有好和坏的两面。 3。kill掉后台oracle进程，重新FTP剩余的数据文件，到早上8点，成功传输完毕，开始clone，将近10点的时候，clone结束，正在作最后的打扫工作，忽然登录数据库报错，查看数据文件，竟然发现有一堆数据文件的属主发生了变化，当时脑袋已经比较混沌了，蒙了几分钟，然后ps后台的进程，结果发现有一个mv的进程，正在把其它位置的数据文件转移到我正在clone的这个环境中，立刻打电话给同事。。。他的误操作覆盖掉了我刚刚做完的新数据库，彻底崩溃，我一个晚上的工作啊，又白费了，这个环境仍旧宣告clone失败。两个字评语，诡异！我不由又有些怀念Windows了。 然后就是一通疯狂的电话联系，跟这个人说明情况，跟那个人商量解决方法，一直搞到中午11点多，洗澡，睡觉。