达梦数据库就故障处理而言，一般分成三大类问题，访问异常、性能异常、和数据库启动异常。其中数据库启动异常相对来说是比较好确定原因的，一般来说在启动数据库时会有明显的报错信息，根据报错提示信息可以进行相关文件确认，进而决定下一步处理方式。数据库无法访问和性能异常则相对更加复杂一些，需要一定的数据库运维经验和知识储备。

1.数据库启动异常
    达梦数据库的启动是一个比较复杂的过程，需要读取和加载一系列重要的文件，这些重要文件一般分为配置文件、控制文件、数据文件、重做日志文件、回滚文件、临时库文件、秘钥文件、备份文件、归档文件、系统运行日志文件和SQL追踪日志文件等。这些文件中大部分都是数据库启动和运行所必须的文件，所以丢失和损坏会影响数据库的正常运行（如数据文件），也有一些文件丢失则不影响数据库的正常运行，但是可能会对数据库运维工作造成一定的麻烦（如SQL日志文件）。在实际运维过程中我们应该关注这些重要文件，无论是否是数据库运行所必须的文件，数据库管理员都应该保持谨慎态度，不能轻易删除相关文件。

2.数据库无法访问
    数据库无法访问相对来说较容易确定原因，我们应该从外因和内因两方面来排查问题。外因一般是指需要访问数据库的客户端或应用与数据库服务端的网络连通性、防火墙设置、第三方安全隔离设备，这里的网络连通性不仅仅指ip地址能ping通，数据库服务的相关端口也应该是畅通的。其次才是内因，这里的内因是指提供数据库服务的数据库进程，数据库进程是否存活，以及访问数据库所必须的某些资源是否用尽或达到上限。当数据库进程存在却不能访问时，此时的数据库服务器或数据库进程往往伴随着明显的资源利用率不正常，可能某系资源利用率极高（例如CPU飙升），也可能极低（hang主或者正在发生状态切换）。但是如果数据库进程异常停止了，我们就应该遵照标准的分析流程进行问题确认了，如查看数据库运行日志并遵照基本core分析流程。当然如果某些应用程序存在异常，耗尽了数据库连接资源后，后来的请求就无法登录到数据库了，但此时会有比较明显的报错信息提示。

3.数据库性能异常
    数据库性能异常一般来说往往是最难分析确认的一类问题，这里的性能异常有可能是SQL执行耗时长，也可能是应用层面功能模块忽快忽慢，但总的来说就是认为数据库的响应时间相比以前明显要慢或达不到业务需求。当数据库性能出现异常时，如果用户或dba对以往时间的数据库负载或资源使用情况比较熟悉的话，或者数据库服务器配置了定时任务自动采集数据库所在服务器相关资源使用情况（例如nmon），则通过对比正常时间段和异常时间段的资源使用曲线图会更容易发现问题。遗憾的是，大部分情况下用户并不关心数据库服务器平时的负载情况，当出现异常时没有基线数据进行对比分析，这种情况下则相对更棘手一些，但从资源使用情况的角度来看总会发现一些端倪。当数据库性能下降时，经常出现的一种场景是，SQL出现并发高峰或高频SQL的执行效率明显下降，最为突出的表现是CPU使用率明显飙升，这种情况下我们只需要通过活动会话找到异常SQL进行优化即可。
    第二种比较常见的场景是，数据库可能在做计划外的大数据整理工作，无论是操作系统级别文件整理还是数据库本身的大数据量变更操作，都会给磁盘IO带来很大的压力，从而达到磁盘IO瓶颈，这种场景通过常用的磁盘检测工具或linux自带命令就可以进行确认。
    第三类可能是数据库自身在做大量的PURGE导致，例如UNDO_RETENTION设置过大，造成保留过多UNDO，回滚文件变大，大量待PURGE的事务对应的原始数据等待清理，造成大量磁盘IO的同时，也会拉长新的数据库请求对应的响应时间。还有一类是SQL锁等待或阻塞，当然这类问题严格上来说并不属于性能异常，而是等待事件了，发生SQL阻塞可以通过v$lock和v$trxwait很方便的定位出阻塞源头。
    另外，硬件层面的一些故障也会造成数据库访问性能异常，例如当数据库服务器RAID卡电池耗尽或超过使用年限而触发写保护时，这个数据库服务器所承载的业务系统性能会明显下降，在密集的事务处理型业务系统中表现尤为明显，此时在数据库会话视图中可能会观测到堆积大量被阻塞和拖慢的SQL请求，从用户侧的表现会是“忽快忽慢”，甚至是不可用状态。当出现RAID透写时，服务器硬件告警灯可能会被点亮。