说说数据库诊断清单，
1.80%以上的问题是由于应用导致的，所以在遇到数据库性能问题时，首先要从应用程序和应用状况入手，看看发生问题时或之前，是否有相关的应用或设置变更等，对于数据库来说比如参数修改，表或索引的变更，大量的修改删除或错误的应用导致的连接风暴等。
2.对于一台服务器而言，包括硬件和软件；软件又可以细分为操作系统和操作系统上应用软件，数据库只是操作系统上应用软件的一个应用软件而已。
当操作系统整体较慢时，作为应用软件的数据库自然也会受到影响，成为被害者而性能低下。
所以，当我们遇到服务器的CPU/内存/I/O等资源的使用率较高时，首先要通过OSWatcher或TOP等OS命令弄清楚到底是什么应用在占用大量的CPU/内存/I/O等？这里的“罪魁祸首”可能是Oracle数据库的操作，也可能是操作系统本身进程或者其他应用软件（如杀毒软件，备份软件等）。3.如果操作系统层面没有问题的话，则需要看一看是整个数据库实例慢还是挂起（Hang/Spin）状态。
如果是数据库实例慢，我们可以通AWR/Statspack/ASH/动态试图等数据库工具来确认数据库整体性能是否真的有问题以及进一步缩小一下问题的范围。
需要注意的是，所谓的是否有问题的标准时相对的，要参考平时的负荷状态以及事先建立的基线等。
如果是挂起（Hang/Spin）状态，最好第一时间取得hanganalyze和systemstate dump信息，以便找到根本原因。4.如果能够找到某些特定的进程或会话占用大量DB时间，我们可以基于进程的信息来分析和诊断，看看是后台进程还是前台进程有问题，
如果是后台进程的话，可能和数据库内部运行程序本身相关，如果前台进程则可能是用户的应用程序有问题。5.如果能够定位某条SQL语句，可以确认问题在于SQL的哪个执行阶段（Parse？Executing？Fetch？），执行计划是否改变？我们可能会去SQL Trace 或者Optimizer Trace进一步诊断。
分析和诊断问题是一个循环的过程：从理清问题后最初的灵感开始，收集数据，确认相关信息，重新思考/调查，找突破点，提出行动方案，验证和测试，收集更多信息…重复直至最终找到原因。
数据库诊断清单，在我看来至少分两种，
一个是基于标准或者流程总结而成的，内容框架可参考 ITIL，按照数据库在 IT 系统中的定位来罗列清单，
比如，与数据库有直接关系的定位，下层是服务器硬件、网络硬件、操作系统，上层是中间件、或是连接数据库的其他服务。
这些，都会对数据库产生影响，直接或间接导致数据库异常，最常见的是硬盘损坏，严重情况会导致服务器异常甚至重启。
另一个是基于经验总结的清单，每个公司内部或者每个DBA自己都应该有长期积累的总结经验，这些宝贵的经验提炼出来就是一份清单，
就像索引一样，当遇到数据库问题时，先遍历一次这份清单，如果有类似经验就可以帮助我们快速定位问题，或者直接解决问题。
总结，知识需要积累，经验需要沉淀，课程需要学习，笔记可以分享。
