(18)谁动了你的数据库?

        除了DBA可以管理数据库，SA可以登录你的数据库服务器，不止这些，实际中，因为一些DBA不能拒绝的原因，让开发也拥有了DBA权限或某个用户的所有权限的也比比皆是。 这就造成了一些管理上的困扰。比如一时失手删除点东西，或如好学的开发把它当成测试库一样，可能在里面改点东东，或增加点东东，而又没通知DBA。 异或做了某些动作引起PLSQL程序失效而不自知。

       这些未知的东东不在你的管理之下，真是很麻烦的事。 当然DBA自已的失误我就在这忽略了，哈哈。总之防止不了各类问题，不管你是DG还是RAC,对这种操作都是无能为力的。如我听过的数据库连接错误 ，把正式库当成了测试库，执行了一些有严重后果的操作。或者最糟糕的情况是一个 rm因为路径多了一个空格，直接把一个库给弄没了。另一个糟糕的例子是，有开发在加班时在生产库误删了一个表，怕上头查，因为库很小，是个单实例，竞然偷着把整个库都给做了个一知半解全库恢复，让他给弄丢了一天的数据。   

   对于这些情况，最好的办法是管理要规范，有严格的权限划分，严格的审核和审计。才可能有效的防范这些可能性。不过能这么重视数据库管理并严格遵守的公司好像不多。 如果你刚好不在这类公司那或许可以看看我提的一些建议:

1. 尽量收拢建表，加索引之类的权限。

2. 在增加或更改东西前，做好回退或应变的准备。有时，可以先做个备份再做这些动作。

3. 多关注all_objects表，特别是我列的这三列。从这可以看，数据库最近做的更改或新增，及对象的状态。最后能定期有个history表。

   这样，别人要是偷偷在后面增加或删除了什么数据库对象，是可以查出来的。

   select a.status,a.created,a.last_ddl_time,a.* from all_objects a

          4. 对重要的表，利用Oracle做一些审计，特别是与钱有关的。

          5. 数据库用户权限要收紧。

          6. 对重要的后台程序，在调用前，必须查一下是否失效? 这个问题非常容易被开发忽视掉。以为调用了就没事了。见过后果很严重的。

          7.自己要有文档或邮件留存，记录下相关变更原因和时间。

          8. 最好开启闪回，太有必要了。          

          9. 备份，最重要的东东，恢复演练要常做，你的最后手段 ，最好别用上，用上时千万别失灵。

         实际当然还有需要其它手段，不过上面几点基本够用了，当然对于像SA误删库之类的错误，很难防得了，这只能靠运气了。

 所以DBA的工作并不只是在表设计，调优等方面。其管理方面的东东也不能小视。它有时会直接影响到你的饭鋺。

     这就是为什么数据库的备份大于一切。

MAIL:[e-mail]

Blog:http://blog.csdn.net/xcl168