诡异的遭遇

将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点多,洗澡,睡觉。

3 thoughts on “诡异的遭遇

  1. 其实我也一直想用RMAN,可惜我来的时候人家就是这些脚本了。
    而且最近白天作期初数据导入,又是折旧,一堆事儿,人客户怕影响性能,不让用热备。。。

  2. windows下面的clone也不是次次都能成功的。

    我总感觉clone古里古怪的,不成功的时候,会连原因都找不到:(

Leave a Reply

Your email address will not be published. Required fields are marked *