Jul 13 2006
Archive for July, 2006
Jul 12 2006
诡异的遭遇
将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点多,洗澡,睡觉。
cloneJul 11 2006
如何将UNIX Shell作为Concurrent Program来运行
通常在Oracle ERP系统中需要有数据导入的工作,比如各个模块的期初数据。这些数据导入的工作都是由客户方的人员在Oracle ERP系统中运行特定的Concurrent Program来执行的,也就是操作人员点几下鼠标,提交一个请求的事情。
那么如何实现数据导入功能变为Concurrent Program呢?
1。将数据导入功能写成一个UNIX Shell,允许接受参数,在其中调用sql loader,这个脚本如何写不是本文的内容
2。比如这个数据导入是总帐模块需要用的,那么通常我们就把这个Shell脚本放在$CGL_TOP/bin目录下,假设脚本的名字的为hostprog.prog,扩展名为prog这是必须的。
3。在相同目录下生成link,注意此处生成的link名称为去掉了prog扩展名的文件名,这同样是必须的。
link -s $FND_TOP/bin/fndcpesr $CGL_TOP/bin/hostprog
4。在ERP系统中注册Concurrent Program Executable,注意选择Type为host
5。在ERP系统中注册Concurrent Program Define,此时可以设置Shell脚本需要接受的外部参数的默认值。注意,当请求调用脚本的时候,会往脚本中传输4个参数值,依次是 orauser/pwd, userid, username, request_id,分别表示数据库用户/密码,ERP用户ID,ERP用户名,当前请求编号,这是我们在写脚本时可以使用的$1-$4这4个参数,而额外自定义的参数一定要从$5开始。
6。找到需要执行这个脚本的ERP用户所拥有的职责,然后将该Program加入职责的请求组中。
7。切换到相应职责,提交请求。
可以参看Metalink上的文章:Note:147455.1
Running a Shell Script as a Concurrent Program
Jul 10 2006
对bestdba的复选建议

2006年中国首届杰出数据库工程师评选复选阶段评选标准包括:
项目经验材料(50分)
应用创新谈(25分)
网上互动与答疑(25分)
项目经验和应用创新说来应该是比较有效的评选方法,虽然项目经验的真实也无从评审,但是只要能写出让评委满意的经验教训也是一件得有功力的事儿。而应用创新谈更是一篇需要反复考究的文章,3000字的要求并不多,如何短小精悍是个挑战。
但是,对于最后占据评分1/4的网上互动和答疑,却不得不提出一些建议:
1。为什么放着CSDN赖以出名的社区论坛不用而要单独做一个这样的答疑系统?如果是为了评分方便,那么CSDN社区完全也可以计算出哪个人在哪个时间段内作了多少有价值的问题回复,而且CSDN社区自有的评分系统本身就已经实行很久了,用来作这种互动和答疑岂不是正好合适?并且 … CSDN社区才是真正帮其他人解决问题的地方,一个人来提问,是会首先去CSDN社区还是会来bestdba的这个页面,恐怕不用多说了。
2。即使是决定使用这个页面,那么…最新有回帖的专题居然不放在最前面?如果页数多了,怎么找到自己做过回复的帖子?因为也没有任何搜索功能啊。
3。目前的情况,SQLServer的问题居多,而Oracle的问题却几乎找不到,那么对于同时参与评选的SQLServer数据库工程师和Oracle数据库工程师来说,起点就不太公平,因为只能从这里找问题回答,如果别人不问,那么就没有得分的可能,但是别人问什么问题,却是工程师无法控制的,这点如果用第一点建议来代替,则不会出现问题,因为就整个CSDN社区的大环境来说,SQL Server和Oracle的问题量是趋于相等的。
Update:
很快,张禾@CSDN就发来MSN说,有最新回帖的专题已经调整到最前面,并且搜索功能也加上了,呵呵,随需应变啊,赞一个。
![Chanel [K]](http://www.dbform.com/wp-content/chanelk.png)

