DBA日常工作职责--我对DBA的7点建议

DBA的工作职责是什么？每天DBA应该做哪些工作？稳定环境中的DBA该如何成长与优化？这是很多人都曾经提出过的问题，下面是我的观点和建议

，供参考。

1. 实时监控数据库告警日志

作为一个DBA，或者哪怕仅仅是和Oracle数据库打交道的技术人员，你都必须知道告警日志是什么，在何处。

而对于DBA来说，实时的监控数据库的告警日志是必须进行的工作，监控并且应该根据不同的严重级别，发送不同级别的告警信息（通过邮件、短

信），这可以帮助我们及时了解数据库的变化与异常，及时响应并介入处理。

2. 实时监控数据库的重要统计信息

实施监控对于数据库运行至关重要、要高度关注那些能够表征数据库重要变化的统计信息，并且据此发送告警信息。那么应当监控哪些统计信息

呢？大家应当区别条件深入思考，对于单机、RAC环境等各不相同。

3. 部署自动的Statspack/AWR报告生成机制

每天检查前日的AWR报告，熟悉数据库的运行状况，做到对于数据库了如指掌。

4. 每天至少优化和熟悉一个Top SQL

根据AWR或Statspack报告，每天至少了解或熟悉一个Top SQL，能优化的要提出优化和调整建议。一个DBA应当对稳定系统中的SQL非常熟悉和了解

，这样才可能在系统出现性能问题时见微知著，快速地作出判断和响应。

5. 部署完善的监控和数据采样系统

DBA应该对数据库部署完善的监控系统，并对重要信息进行采样，能够实时或定期生成数据库重要指标的曲线图，展现数据库的运行趋势。

6. 全面深入地了解应用架构

不了解应用的DBA是没有前途的DBA，对应用了解不深入的DBA算不上Expert，所以一定要深入了解应用。

在数据库本身变得更加自动化和简化之后，未来的DBA应该不断走向前端，加深对于应用的了解，从应用角度对数据库及全局进行把握和优化。

7. 撰写系统架构、现状、调整备忘录

根据对数据库的研究和了解，不断记录数据库的状况，撰写数据库架构、现状及调整备忘录，不放过任何可能的优化与改进的机会。

 

DBA职业生涯之误删除篇

前面我提到严谨这一素质对于DBA的重要性，在ITPUB论坛上曾经有过一个热烈的主题："请列出你在从事DBA生涯中，最难以忘怀的一次误操作"。

这一主题引起了大家普遍的兴趣，很多有趣的案例呈现出来，我摘录了一些和误删除有关的操作，看看都有哪些一时马虎、不够严谨会犯下的过

失，大家应引以为戒，共同警醒：

1. 在Linux平台上，一次不小心操作，把oradata下所有的东西全删除了。

这样的误操作，教训是极其惨痛的，所以备份对于DBA来说仍然是最重要的。

2. 一次误删了个表，最后恢复了，丢了一天的数据。加了一晚上班，至今记得。

人越累的时候就越容易犯错误，我就是在最后快下班的几分钟犯的错误。

一定要记住墨菲定律，越着急就越容易犯错误，DBA千万不要赶着去做一件事。

3. 在一次测试过程中，把一个在本机执行的删除所有非系统用户的脚本，错误地粘到一个开发数据库的sqlplus窗口中了。

如果你不注意剪贴板，它就会害你！

4. 有一次一不小心把一个表给truncate了，上千万条记录一眨眼就没了。

ddl操作一定要谨慎啊！

5. rm -rf /opt/ora92/* 在测试库中本来想删除数据库，结果错误地把Oracle软件删除了。

rm -rf是相当恐怖的，每个DBA都应该学会不要直接使用这个命令。

6. 不小心用rm -rf /home目录下的所有文件，/home目录下放的有账务系统的app。一看到删除的路径的不对时，挽救已经来不及了。

又是一个rm -rf的狠操作。

7. 删除一些trace文件，然后就直接删除rm orcl*，结果通过vpn到生产的网络太慢，命令刚慢慢地显示出来，看都没看直接按回车，结果执行的

命令却是rm orcl *，因为orcl和星号中间有个空格，所以把这个目录下面所有的内容全部删除了。

网络慢的确害惨过很多人，所以网络可能存在问题时，任何操作都要慎重，不行可以使用脚本在后台跑。

8. 有很多在OEM／Toad中误击键盘删除用户或表空间的情况。

实际上，我们看到，很多误操作都和技术能力基本无关，只是要细致、严谨，再认真一点。DBA有些素质和习惯是必须养成的。

很多时候，只要多思考一些，就可以将工作做得更加完美，就可以严谨地避免很多问题，举一个DBA可能经常面对的工作任务作为例子：

如果在数据库中执行ddl操作，比如：

CREATE INDEX / REBUILD INDEX … ONLINE COMPUTE STATISTICS   

/ GRANT / REVOKE / COMPILE / ANALYZE / DBMS_STATS…. 

进行严密严谨的思考，这些操作可能带来什么后果？

通常我们都知道，ddl会使解析过的SQL失效、会使存储过程等对象失效发生重编译、也有可能引起SQL执行计划的改变……

这些可能在一个繁忙的业务数据库中带来灾难，如果大量的SQL同时失效，同时重新解析，就可能带来大量的Shared Pool与Library Cache的竞争

，SQL解析与竞争又会导致CPU的高消耗，这些在繁忙系统中可能会导致负荷突然升高，严重的甚至会导致系统阶段性地挂起。

已经有很多DBA在这些问题上付出了惨痛代价，而我只提醒大家，做事时要能够明确工作的性质、分析潜在的风险、回避可能引发的问题。

DBA警世录--有些习惯DBA需要养成

既然DBA这个职业如此危险，那么哪些习惯是DBA必须养成的呢？

我总结过几条简单的习惯命令，通过这些习惯性命令，可以减少我们出错的可能。写下这段内容时，刚刚完成一个客户数据库的恢复，客户造成

故障的原因很简单，因为维护升级时错误地连接到生产主机，结果导致生产库故障，数据文件被删除并部分覆盖。

1. 经常使用hostname命令

在Linux/Unix上，我们使用ssh或telnet等通过多次跳转，很容易变更了连接主机，如果不经过确认就可能在不正确的主机上执行了错误的操作。

通过hostname命令可以确认我们连接到的主机，避免发生不应该的误操作。在执行操作之前一定要通过hostname命令确认连接主机，这是DBA或系

统管理员应该养成的习惯：

[oracle@jumper oracle]$ hostname  

jumper.hurray.com.cn 

2. 使用pwd确认路径

经常有朋友在错误的路径下错误地执行了"rm -rf *"等命令，这类错误的发生率居然也是很高的。

所以作为一个DBA，应经常性地执行如下的pwd命令来确认自己的工作路径：

[oracle@jumper oracle]$ pwd  

/opt/oracle 

3. 确认instance_name等数据库重要信息

在执行truncate/drop等操作之前，应该确认连接到了哪个数据库，从V$DATABASE或V$INSTANCE等视图中可以获得这些信息（可能需要授权）：

SQL> select instance_name,host_name from v$instance;   

INSTANCE_NAME HOST_NAME  

---------------- ----------------------------------  

eygle jumper.eygle.com 

4. 通过id命令确认用户信息

要经常通过id命令确认用户信息，以免切换用户而导致不自觉的异常操作：

[gqgai@jumper gqgai]$ id  

uid=2003(gqgai) gid=101(dba) groups=101(dba) 

我见到过有的案例，用户切换为root，误操作删除过大量系统文件，导致了严重的故障。

5. 对ddl语句心存敬畏

DBA应该知道truncate / drop 等ddl操作可能带来的影响，所以应该对这些ddl操作心存敬畏，甚至应该避免执行或避免草率执行这样的操作，最

好养成在ddl清除数据之前备份的习惯。

通过一些良好习惯的养成，可以使得我们少犯错误。

学会总结，学会从别人的教训中积累经验，这对DBA来说必不可少！

原文链接：http://blog.chinaunix.net/uid-8504518-id-3353310.html