我几乎不敢相信我眼前这个将近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?