致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,你会永远记得这样的错误多么致命对于一个生产库!

posted on 2016-10-27 23:45  张冲andy  阅读(275)  评论(0编辑  收藏  举报

导航