广义上，不只是发生故障才需要应急响应，所有超出集群设计能力、规划预期的情况可能都需要紧急处理。应急事件处理的首要目的并不是排查根因，而是快速止血，先让集群尽快恢复正常服务能力。
问题发现渠道
应急事件的发现，通常分为主动发现和被动感知两类，一般分为以下几个渠道：
业务监控报警（应用层监控）
数据库日常巡检（详情请参见 监控和告警 章节的 监控 ）
数据库监控报警（详情请参见 监控和告警 章节的 告警 ）
应急事件分类
硬件&基础设施故障
通常由软硬件问题导致。其中多数单机问题 OceanBase 可以自行恢复，但是一些情况依然需要通过应急手段进行主动干预。常见的基础设施类故障分为以下几类：
服务器硬件故障导致的宕机
服务器 NTP 时钟偏移
机柜/机房级电力故障
单机网卡故障、或机柜/机房网络抖动等
ODP 集群负载均衡设备故障
业务访问变化导致的容量不足
当业务层的访问量由于营销活动等原因突然上涨，或者有新业务发布上线时，往往可能导致数据库访问超过前期设计容量。此时就会表现为性能下降、响应时间变长、连接超时等一系列问题。对于 OceanBase，性能容量不足通常表现为以下几种情况：
SQL 查询导致的集群资源占用率过高
集群节点磁盘 IO 过高
集群节点网卡负载过高
租户请求队列积压
租户内存写满
ODP 线程满
集群节点日志盘空间满
集群节点数据盘空间满
OceanBase 集群的其他问题
除上述两大类情况意外，还有一类问题是在 OceanBase 的分布式架构下，一些特有的使用场景或用户习惯触发的问题。导致这些问题的原因多样，可能是业务的访问方式导致，少数情况下也可能是触发了软件bug，您可以使用一些通用的应急手段止血处理。这些问题一般包括：
租户转储卡住
集群冻结/合并卡住
悬挂事务&长事务
sys 租户队列积压
节点进程异常退出
内部模块内存不足/泄漏
buffer 表问题
上述三类问题，有些问题直接表现为"现象"，有些则是导致其他异常现象的原因。关于如何针对这些不同的应急场景进行正确的处理，请参见 分析诊断&决策流程。
