在发生故障时，首先需要确认故障点是硬件、网络、操作系统还是数据库问题。不同故障恢复数据库服务的方法不一样。可以通过以下步骤判断故障原因。
通过SSH或者其他远程登录工具登录GaussDB 100所在服务器。
若操作系统发生内核错误Kernel panic（操作系统监测到内部的致命错误），则系统需经过较长时间（大约20分钟）才能重启。建议每过5分钟尝试连接一次，若20分钟后仍然不能连接成功，表明这台机器已故障无响应或网络连接有问题，需要联系管理员到现场进行检查处理。
以root用户，本地登录GaussDB 100所在服务器。
查看GaussDB 100服务是否启动。
ps ux | grep zengine
显示zengine状态为“open”、“mount”、“nomount”则表示数据库服务已经启动。
omm 14342 2.5 6.8 1059336 510404 ? Sl May21 104:44 /home/omm/app/bin/zengine open -D /home/omm/data
查看磁盘状况。
查看是否有未挂载的磁盘。
fdisk -l
查看磁盘空间是否不足。
df -h
请保证GaussDB 100所在的磁盘空间充足。
尝试写入文件，以确定磁盘是否正常。
排查操作系统问题
登录操作系统后，如果执行操作时响应缓慢，需检查系统运行情况后，进行进一步处理。执行的操作包括但不限于收集系统信息，确定系统版本、硬件、参数设置及登录用户情况。
系统资源不足（如CPU或I/O资源过载）引起的机器不响应外部连接。建议重试几次。若5分钟内仍不能操作这台机器，需管理员到现场进行检查处理。
登录成功系统反应慢，需收集以下系统信息：
当前在线用户。
--查看当前在线用户who
CPU使用状况。
确定是否因为某个进程导致CPU使用率过高。
top -H
I/O使用状况。
iostat -x 1 3 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util xvda 0.01 1.10 0.07 1.01 0.83 10.25 20.40 0.03 24.88 4.04 26.36 1.38 0.15 xvde 0.00 0.39 0.13 1.62 3.47 33.83 42.78 0.03 18.01 4.94 19.05 1.21 0.21 dm-0 0.00 0.00 0.13 2.01 3.47 33.83 34.94 0.03 15.71 4.95 16.40 0.99 0.21
rrqm/s：每秒进行merge的读操作数目。即delta(rmerge)/s
wrqm/s：每秒进行merge的写操作数目。即delta(wmerge)/s
r/s：每秒完成的读I/O设备次数。即delta(rio)/s
w/s：每秒完成的写I/O设备次数。即delta(wio)/s
rKB/s：每秒读K字节数。是rsec/s的一半，因为每扇区大小为512字节
wKB/s：每秒写K字节数。是wsec/s的一半
avgrq-sz:平均每次设备I/O操作的数据大小(扇区)。即delta(rsect+wsect)/delta(rio+wio)
avgqu-sz：平均I/O队列长度。即delta(aveq)/s/1000(因为aveq的单位为毫秒)
await：平均每次设备I/O操作的等待时间(毫秒)。即delta(ruse+wuse)/delta(rio+wio)
svctm：平均每次设备I/O操作的服务时间(毫秒)。即delta(use)/delta(rio+wio)
%util：一秒中有百分之多少的时间用于I/O操作，或者说一秒中有多少时间I/O队列是非空的。即delta(usr)/s/1000(因为usr的单位为毫秒)
内存使用状况。
vmstat 1 3
操作系统情况。
“cat /etc/SuSE-release”检查SUSE系统版本。
“cat /etc/redhat-release”检查Red Hat系统版本。
“cat /etc/euleros-release”检查欧拉系统版本。
以root用户查看操作系统日志信息(/var/log/messages)或dmesg信息，检查是否操作系统发生过异常错误。
以root用户执行“sysctl -a”命令和“cat /etc/sysctl.conf”命令获得系统参数信息。
执行“uname -a”查询系统内核信息。
执行如下命令检查系统的版本。
“cat /proc/cpuinfo”和“cat /proc/meminfo”获得CPU和内存信息。
排查网络问题
通信网络层是数据库的基础组件，在数据库正常工作的情况下，网络层对上层用户是透明的，但数据库在长期运行时，可能会由于各种原因导致出现网络异常或错误。
netstat
如果网络正常，请尝试连接数据库。
单机连接失败，请根据报错信息检查zenith.ini文件的配置项是否正确。
连接数据库或执行查询时发生hang
处理办法：
以root用户，本地登录GaussDB 100所在服务器。
登录GaussDB 100数据库。
zsqlconn jack/database_123@192.168.0.1:1888
jack/database_123为登录数据库的用户名和密码，192.168.0.1为数据库所在的服务器IP地址，1888为连接的端口号。
通过如下SQL语句查询正在运行的SQL。
SELECT SID,SERIAL#, EVENT, PROGRAM, CLIENT_IP, (SYSDATE - SQL_EXEC_START)*86400, WAIT_SID, CURRENT_SQL,SQL_ID, MODULE FROM DV_SESSIONS WHERE STATUS = 'ACTIVE';
其中：
WAIT_SID表示阻塞会话ID，为空表示不阻塞。
(SYSDATE - SQL_EXEC_START)*86400表示该会话当前SQL已经执行的时间，单位：秒。
请根据具体情况处理。
如果确定该阻塞会话关闭后不影响数据库正常运行，执行如下命令，关闭该会话。
ALTER SYSTEM KILL SESSION 'SID,SERIAL#';
如果关闭该阻塞会话可能会影响数据库正常运行，建议联系华为技术支持确认是否可执行关闭会话操作。
排查数据库问题
数据库发生故障时，需要及时收集日志、视图、错误码和黑匣子（或core文件）的信息来分析问题产生的原因。
查看错误码信息
GaussDB 100提供了丰富的错误码显示机制。并期望通过不断丰富每条错误码的可能原因和处理办法，协助用户在遇到问题时可以快速和顺利地定位和解决问题。
错误码详细信息请参见《GaussDB 100 V300R001C00 错误码参考》。
通过日志定位故障
GaussDB 100在运行过程中，会产生大量用于数据库日常维护的运行、审计、DEBUG、告警等日志。在数据库发生故障时，可以使用这些日志进行问题定位和数据库恢复的操作。
具体日志记录内容，请参见《GaussDB 100 V300R001C00 用户指南（单机）》中“数据库系统管理 > > 管理日志 > 查看日志”章节。
运行日志
打印GaussDB 100数据库运行信息，如果数据库运行故障，请查看zengine.rlog。
日志目录：默认为“$GSDB_DATA/log/run/zengine.rlog”。
DEBUG日志
打印GaussDB 100数据库运行DEBUG级别信息，如果数据运行故障，且开启DEBUG级别日志，请查看zengine.dlog。
日志目录：默认为“$GSDB_DATA/log/debug/zengine.dlog”。
告警日志
打印GaussDB 100数据库运行告警信息。如需了解告警信息，请查看zenith_alarm.log。
日志目录：“$GSDB_DATA/log/zenith_alarm.log”。
zctl日志
打印使用zctl.py运维操作数据库的信息，zctl是日志为zctl-yyyy-mm-dd_xxx.log。如需获取GaussDB 100完整的运维信息，请查看zctl-yyyy-mm-dd_xxx.log和数据库启动输出信息zenithstatus.log。
日志目录：“$GSDB_DATA/log/zctl-yyyy-mm-dd_xxx.log”。
启动日志
记录数据库启动输出信息zenithstatus.log。如需获取GaussDB 100完整的运维信息，请查看zctl-yyyy-mm-dd_xxx.log和数据库启动输出信息zenithstatus.log。
日志目录：“$GSDB_DATA/log/zenithstatus.log”。
TRACE日志
记录数据库会话死锁的信息。如需查看会话死锁信息，请查看zengine_00003_xxxxxx.trc。
日志目录：“$GSDB_DATA/trc/zengine_00003_xxxxxx.trc”。
通过视图查看信息
GaussDB 100提供了丰富的视图，在定位故障时，可以根据实际情况查看相关视图。如，SQL长时间无响应时，可以查看视图DV_LOCKED_OBJECTS。
通过Core文件定位故障
GaussDB 100的相关进程在运行过程中可能会因为各种意外情况导致数据库崩溃（Coredump），而崩溃时产生的core文件对于迅速定位程序崩溃的原因及位置非常重要。如果进程运行时出现Coredump现象，建议立即开启core文件便于分析、定位故障。
操作系统自带Core dump机制。开启后，系统中所有出现Core dump问题时都会生成core文件，对操作系统带来性能和磁盘占用的影响。为了定位GaussDB 100 Coredump问题时不影响操作系统中其他程序，GaussDB 100支持操作系统不配置core机制时仍可产生core文件。
查看core文件位置命令如下所示：
cat /proc/sys/kernel/core_pattern
