一、引言
在我们日常运维项目中，数据库的运维都位于核心的位置，原因有两个，一是数据库的运维涉及的范围非常广泛，数据库的种类比较多，二是数据库的安全性非常重要，所有涉及到数据库的操作，都需要非常谨慎。
数据库的问题，大致可分为两大类，一是数据库系统稳定问题，一是数据库系统性能问题。系统稳定类的问题偏向管理，系统性能类的问题偏向优化。在实际分析与处理这两类问题时，需要采用不同的思路。
本文就Oracle数据库系统的故障排查思路做下分析，以期解决大家在Oracle数据库运维中遇到的问题，寻求一个基本的解决思路。
二、数据库系统稳定性问题排查思路
1、查看数据库报警日志
当数据库遇到错误或故障时，首先需要查看的是发生错误或者故障时的错误代码以及数据库的警报日志。经验分析，数据库绝大部分的故障都能从故障号或者警报日志中清晰定位到。
根据不同的数据库版本，数据库报警日志的位置有所不同：
Oracle 10g及之前版本报警日志位置：$ORACLE_BASE/ADMIN/SID/BDUMP下alert_SID.log
Oracle 11g报警日志位置：$ORACLE_BASE/diag/rdbms/SID/SID/trace/alert_SID.log
2、数据库错误故障号
Oracle数据库本身提供一套完善的错误代码说明体系，详细定义了各类错误说明以及给出相应的修正建议。
通常，Oracle将错误主要分为几大类：
数据库软件及数据库本身相关（ORA-），如：ORA-12514
数据库导入导出工具相关（EXP-/IMP-），如：EXP-00008
数据库监听程序、网络服务相关（TNS-），如：TNS-12560
数据库rman备份恢复相关（RMAN-），如：RMAN-06564
Oracle针对各类错误号，提供了一个名为“oerr”的工具用于查阅引起相应错误号的原因以及针对该错误的一些执行建议。
oerr工具的用法： oerr ERROR TYPE
其中： [ERROR TYPE]表示的是错误号的类型，数据库及产品相关的错误类型为“ORA”；数据库导入导出工具相关的错误类型为“EXP”或“IMP”；监听程序或网络服务相关的错误类型为“TNS”；RMAN相关的错误类型为“RMAN”。如：
oerr ORA 2396
02396, 00000, "exceeded maximum idle time, please connect again"
// *Cause: as stated
// *Action:
几个典型案例：
A、归档日志满造成sqlplus无法登录
在alert_SID.log中，发现以下报错：
ORA-16014: log 1 sequence# 61 not archived, no available destinations
ORA-00312: online log 1 thread 1: '/alidata/app/oracle/oradata/orcl/redolog/redo01.log'
ARCH: Connecting to console port...
处理方法：
df -h检测文件系统
删除日期靠前的归档日志
处理完毕后，撰写归档自动删除脚本，防止类似问题再次发生。
B、初始化参数中SGA设置过大，数据库无法启动
设置数据库的SGA过大，重启数据库的时候，数据库无法启动。
处理方法：
create pfile from spfile，通过spfile生成pfile
修改pfile文件，把SGA设置在一个合理的范围，然后启动数据库。
C、用户密码过期问题
在客户端，用户连接时，报错：
ERROR: ORA-28002: the password will expire within 5 days
说明用户密码即将过期，默认创建的用户策略，密码需要90天修改一次。
处理方法：
更改用户密码，或者设置策略，密码永不过期：
alter user smsc identified by <新密码>
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED。
3、操作系统日志
有些时候，数据库、集群出故障了，或许在数据库的警报日志、集群的各类日志中无法直接定位到问题的原因。这时，操作系统日志可能能提供一些关于系统、及主机硬件相关的日志记录协助诊断。 不同的操作系统平台，操作系统日志存放路径有所不一致。
Linux:/var/log/messages、messages.N(N为1-4)；
Solaris:/var/adm/messages、messages.N(N为0-3)；
AIX：errpt |more查看；
HP-UX：/var/adm/syslog/syslog.log；
从操作系统的日志中，可以获取跟系统运行有关的相关日志记录。譬如，网卡、光纤卡出现异常中断；磁盘空间满等等。这对诊断数据库、集群故障提供了很大帮助。 详细的系统日志提示意义，可参阅各平台系统管理手册。
三、数据库性能问题排查思路
如果遇到数据库性能方面的问题，建议采用Oracle提供的几个内置工具（awr、addm、ash）与系统提供的工具（top、vmstat、iostat）相结合。通过这些工具生成的报告，进一步分析出问题的根源，解决问题。下面就几个工具的使用，结合我们之前的案例做描述。
1、AWR报告
AWR报告是Oracle提供的一种性能收集和分析工具，它能提供一个时间段内整个系统资源使用情况的报告，通过这个报告，我们就可以了解一个系统的整个运行情况，这就像一个人全面的体检报告。
如何分析AWR报告：
在看awr报告的时候，我们并不需要知道所有性能指标的含义，就可以判断出问题的所在，这些性能指标其实代表了oracle内部实现，对oracle理解的越深，在看awr报告的时候，对数据库性能的判断也会越准确。数据库出现性能问题，一般都在三个地方，io，内存，cpu，这三个又是息息相关的，当io负载增大时，肯定需要更多的内存来存放，同时也需要cpu花费更多的时间来过滤这些数据，相反，cpu时间花费多的话，有可能是解析sql语句，也可能是过滤太多的数据，倒不一定是和io或内存有关系了；
当我们把一条sql送到数据库去执行的时候，我们要知道，什么时候用到cpu，什么时候用到内存，什么时候用到io：
A、cpu：解析sql语句，尝试多个执行计划，最后生成一个数据库认为是比较好的执行计划，不一定是最优的，因为关联表太多的时候，数据库并不会穷举所有的执行计划，这会消耗太多的时间，oracle怎么就知道这条数据时你要，另一个就不是你要的呢，这是需要cpu来过滤的；
B、内存：sql语句和执行计划都需要在内存保留一段时间，还有取到的数据，根据lru算法也会尽量在内存中保留，在执行sql语句过程中，各种表之间的连接，排序等操作也要占用内存；
C、io：如果需要的数据在内存中没有，则需要到磁盘中去取，就会用到物理io了，还有表之间的连接数据太多，以及排序等操作内存放不下的时候，也需要用到临时表空间，也就用到物理io了。
这里有一点说明的是，虽然oracle占用了8G的内存，但pga一般只占8G的20%，对于专用服务器模式，每次执行sql语句，表数据的运算等操作，都在pga中进行的，也就是说只能用1.6G左右的内存，如果多个用户都执行 多表关联，而且表数据又多，再加上关联不当的话，内存就成为瓶颈了，所有优化sql很重要的一点就是，减少逻辑读和物理读。
AWR报告生成方法：
cd $ORACLE_HOME/rdbms/admin
@awrrpt.sql;
html 保存格式，有text和html两种选择
选择保留天数；
输入起始ID
输入结束ID
输入报告保留路径及名字
2、top、vmstat、iostat等工具使用
top、vmstat、iostat等工具均是操作系统层面的工具，可以很方便的观测到目前CPU、内存、IO等使用情况，具体使用不再赘述。
四、小结
以上我们简述了当数据库遇到各类问题时，该如何利用各类日志、工具做循序渐进的诊断分析。作为数据库管理员，务必将上述各类日志功能及相关位置记牢。做到在遇到问题时，能沉着应对，冷静处理。 在实际的日常运维中，数据库问题涉及到多个方面，需要结合具体的问题进行具体的分析和处理。
