致Oracle DBA 的一封信 （网上流传）

1． 数据库的可用度，DBA 说了“不算”   --物化视图，加快查询速度

某些时候数据库的可用性，并不由DBA所设定。因为即使DBA对数据库有绝对掌控权，但用户可能从自己的工作和应用角度，与DBA的感受是不一样的。

他们要的是速度！很简单的道理，也许你也曾遇见。某天当你正在岗位上忙碌的时候。这时在同一时间，你的老板正在查看公司的财报，在他的电脑里有个应用，其中有一个按钮，只需轻轻一点就能查看当月甚至当年的财报。当他点了一下之后，结果并没有按他预计的时间返回，于是他拿起电话打给你，问数据库为什么“崩溃”了！

这让你一头雾水，好像他说的不是你眼前的数据库！有时候一个全局设置良好的库也存在这样问题。我们遇到这样的问题，也只有对老板当前所用到的表进行重新的设计，也可以创建物化视图。  

2． 对于成本，他们很在意！　　　　　　--不得不迁移，慎重行事

有时候公司可能为了成本或是开发需要，要求更换操作系统，那原数据库上的数据导入新数据库就是我们经常要做的了。公司对成本很看重！对于TB级的数据库，Exp/imp过于老慢，dpexp/dpimp又对版本有限制，跨平台表空间迁移也有部分不完美的地方。选择怎样的数据迁移方案和是我们要慎重的!

3.有计划的资源分配　　　　　　　　　　--服务也有优先级，选择RAC

公司各部门在使用数据库资源时可能不太均衡。有时会有很高的时间性和规律性，这需要甚为DBA的你做出相应的改变！资源的合理分配！财务年终和月底会做结算，开发测试会不定期的进入等等。这就需要以服务为优先级，选择分配工作负载和系统资源。RAC一个是不错的选择，可以把服务和RAC结合，不同的服务访问不同的节点数。对于大业务量来说它是在恨也没有的了。

4． 宕机和停机

有时候人力不可抗拒的因素也是需要DBA 考虑的。也许正当你在梦中的时候，值班员打来电话，公司机房漏水，服务器全挂了。这种情况谁听了脑袋都大。你试着打电话给系统管理员，询问前一阶段淘汰的服务器是否可用，并且跑回公司产看，异地备份是否完好。也许这不是你的错，但是解决不了，错就是你的了。

这一点不用多说，群集和备库是你最好的选择。对于7*24这是多么重要。尤其dg是你免除人力不可抗拒灾难的最好方案！

5． 坏块挡不住你

有时候你会被数据库告知出现坏块，这时RMAN 就是你最好的工具，上帝保佑你做了备份。如果你丢失了或是存储相对区域无法使用，等待从磁带还原是你唯一的选择，前提你有这样的保险机制！但如果只是用户误操作，闪回的使用是再好不过的了！

6． 空间不足，热点区域的负载均衡

你有一个重要的表空间，它无时无刻不在被使用，他很大很大，大到你的存储对应的lun 无法容纳他，这时你如何处理!当然对于日志文件我们可以去删除它来实现。但数据文件呢？Asm我想你会想到，他会自动平衡文件负载和i/o分布。支持在线添加新磁盘去asm磁盘组！

7． 误操作 DBA 的梦魇

清晨一个倒霉蛋，睡眼惺忪的坐在DB 前，作这那每日的维护工作，突然当一次不起眼的手指敲击键盘发生后，他再无睡意。一次错误的回车，删掉了一张重要表的部分记录。这在我们实际工作中是无数次的发生，怎么办！清醒地他想到了动用不完全恢复的，来挽回错误!但是这一切并无人看见，要是不完全恢复，意味着停机申请，领导的变身。。。。太可怕了！其实FLASHBACK 给你它机会：使用FLASHBACK 实现行级恢复.事情注定是往一起凑，当着倒霉蛋惊魂未定的时候，电话响了。电话是财务部打来的，意思是由于失误，他对财务软件的修改把工资表的涨工资一项误打错了数字，你发现自己月薪已成百万（玩笑）。其实大家都是这么期望的！它需要你挽救一下他的失误！使用FLASHBACK也可以帮你快速解决问题.

8．做一个良好习惯的 DBA

有时你会发现自己的udump 下的trace文件暴涨，多数情况他是你的马虎所造成的，去关闭那些不必要的SQL_trace，你会永远记得这样的错误多么致命对于一个生产库！