还需要多少Oracle DBA?

我几乎不敢相信我眼前这个将近10T的数据库(Oracle10.2.0.2)的现状。

10个T的数据,大量的分区表,但是没有任何readonly的表空间设置(即使这个分区中的数据再也不可能更新了),每个月作3次全库的level 0备份,其它时间都是备份归档日志,每天产生的归档大概有将近200G,使用catalog数据库作RMAN信息的存储,但是没有任何备份catalog数据库的措施。

试想一下,如果在上一次level 0备份后的第9天有人误删除了数据,那么这个系统,需要restore 10T的数据,然后再前滚1.8T(200G*9)的归档,这样的恢复需要多长时间?这样的备份跟没有备份有什么区别?

正值新旧系统割接期间,厂商在不断地用各种手段往新系统中导入数据,产生每分钟将近2G的redo数据,数据装载仍然要产生那么多redo,也就是各种手段都没有考虑到如果避免产生redo,甚至在整个装载数据的过程中,归档仍然是启用的,每个redo文件有2G大小,每小时归档60-70次。

业务数据的大批量更新是由程序人员在PL/SQL Developer中手动地开十几个窗口,然后进行“并行”操作,大量的latch: cache buffers chains等待,这个更新需要涉及2000万数据,预测要执行20个小时,这完全不符合性能要求。

分区表中的主键是全局hash分区的索引,即使是读取一个分区中的数据,也仍然要做这个主键全部32个分区的index range scan。

最让人担心的是现在整个系统没有一个有效的备份。

在RMAN里面report need backup,除了归档日志以外,居然还有几十个从来没有备份的数据文件,问旁边的厂商人员,一开始很确定的说在这次割接前做过一次level 0的备份了,我几乎要怀疑是不是RMAN的report出现问题了。
检查了这些没有备份过的数据文件的创建日期以后,再次向厂商人员确认,在XX日之后,确认一定是做过RMAN备份了吗?
厂商人员开始打电话找别人确认,最后告诉我,是做过备份,但是只是尝试做过备份,因为备份需要太长的时间所以中途放弃了。
那么也就是说,如果在割接的过程中,24小时轮班制连轴转的人员万一错误地发生了删除数据,删除表,删除表空间,甚至删除用户的操作,那么将无法用RMAN来恢复数据,如果重新导入数据在时间上不再允许,那么这次割接很有可能就宣告失败了。
也许,10g的回收站在这个时候会成为救世主?

为了这次割接整个省的业务已经停了2天了,整个市的业务还准备要停3天。哦,看来一个市的业务停个一周也不是什么大不了的事情嘛。

最后,回到题目上,我觉得这个地方需要一个专职的DBA来作统一的管理,这是非常闻名的大企业,还有多少地方象这里一样?我们还需要多少Oracle DBA?

7 thoughts on “还需要多少Oracle DBA?

Leave a Reply

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