Switchover 演练

 DBA 与运维团队的 **Oracle DataGuard Switchover 演练** 完整手册，覆盖“为什么要练、练什么、怎么练、练完如何复盘”四大维度，可直接作为企业年度灾备演练的 **SOP** 模板。

---

## 一、演练目的：把“计划内零丢失”真正落地
Switchover 是 DataGuard 最高可用性的“招牌功能”：
1. **RPO=0**——只要同步无延迟，数据零丢失；
2. **RTO＜5 min**——实测 2 TB 量级 OLTP 系统，业务中断 90~180 s；
3. **可回切**——维护结束后一键还原，无需重建。

但“功能存在”≠“随时可用”。演练的核心目标是把 **技术可行性** 转化为 **组织确定性**：
- 验证流程脚本、人员分工、告警通道、应用重连、DNS/SLB 切换、备份策略在真实时钟下的表现；
- 训练 DBA 形成 **肌肉记忆**，凌晨 2 点也能一条命令不出错；
- 给管理层量化 **中断窗口**，为后续 SLA 谈判与预算提供数据；
- 满足监管合规（银保监、等保 3 级、ISO 22301）对“年度实战演练”的硬性要求。

---

## 二、演练策略：让每一次切换都比生产更“苛刻”
1. **频率**：核心业务系统 **每季度 1 次**，非核心 **半年 1 次**；
2. **场景**：
- 日常维护——打 PSU、更换存储微码、机房搬迁；
- 应急演练——模拟 Primary 机头故障、网络脑裂、Far Sync 失联；
3. **范围**：
- 全链路——从应用 JDBC 连接池到最末端报表库；
- 全角色——DBA、网络、系统、存储、应用、监控、值班经理、客服；
4. **原则**：
- **“演练即实战”**——使用与生产同量级的 **影子库** 或 **夜间低峰直接切生产**；
- **“一票否决”**——只要出现 **5 min 以上数据分歧** 或 **应用报错＞1%**，立即回切并复盘；
- **“零人工”**——所有命令脚本化、参数化，杜绝手敲 SID、路径。

---

## 三、演练前准备：把风险消灭在“起跑线”
| 类别 | 检查项 | 工具/脚本 | 达标值 |
|----|------|----------|-------|
| 同步延迟 | Transport Lag | `V$DATAGUARD_STATS` | ＜1 s |
| 归档积压 | 未传输归档数 | `SELECT * FROM V$ARCHIVE_GAP;` | 0 |
| SRL 缺失 | Standby Redo 组数 | `SELECT GROUP#,THREAD#,BYTES FROM V$STANDBY_LOG;` | ≥ Primary 日志组数 + 1 |
| 密码文件 | 时间戳比对 | `ls -l orapw*` | 所有节点 md5 一致 |
| 应用连接 | 连接池预热 | `java -jar connTest.jar` | 1000 线程并发，失败率 0 |
| 备份 | 控制文件 + 归档 | `BACKUP DEVICE TYPE DISK CURRENT CONTROLFILE FOR STANDBY PLUS ARCHIVELOG;` | 完成且可验 |
| 回退方案 | Flashback Database | `SELECT FLASHBACK_ON FROM V$DATABASE;` | YES，保留 24 h |

**脚本仓库**：
- `pre_check.sh`——一键输出上述指标，任一项 FAIL 即退出；
- `gen_switch_cmd.sh`——根据当前主备角色自动生成 **dbms_service 停启语句** 与 **新 primary tns 条目**；
- `notify_dingtalk.py`——演练开始/结束/异常三节点钉钉 @全员。

---

## 四、演练执行：12 步标准化流程（含时钟）
以下步骤基于 **两节点 Physical Standby，最大可用模式，LGWR SYNC，无 Far Sync**，已固化到 Ansible Playbook，执行耗时 **4 min 30 s**（2 TB OLTP，Redo 日增量 500 GB）。

| 时刻 | 角色 | 动作 | 命令示例 | 预计耗时 |
|-----|----|------|----------|---------|
| T0 | Primary | 1. 创建演练归档标记 | `ALTER SYSTEM ARCHIVE LOG CURRENT;` | 5 s |
| T0+10 s | Primary | 2. 停应用流量 | `ansible app -m shell -a "systemctl stop app@"` | 20 s |
| T0+30 s | Primary | 3. 校验最后归档 & 同步 | `SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID=2;` | 10 s |
| T0+40 s | Primary | 4. 发起 Switchover | `ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;` | 30 s |
| T1+10 s | 原Standby | 5. 转换至 Primary | `ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;` | 30 s |
| T1+40 s | 新Primary | 6. 打开数据库 | `ALTER DATABASE OPEN;` | 15 s |
| T1+55 s | 新Primary | 7. 启动新归档目的地 | `ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=oldprima LGWR SYNC AFFIRM';` | 5 s |
| T2 | 新Primary | 8. 启动应用流量 | `ansible app -m shell -a "systemctl start app@"` | 20 s |
| T2+20 s | 全体 | 9. 业务黄金交易验证 | `curl -X POST https://api.xxx.com/order/test` | 30 s |
| T2+50 s | 新Standby | 10. 开启实时应用 | `ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;` | 10 s |
| T3 | 监控 | 11. AWR 对比基线 | `SELECT * FROM TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(...));` | 60 s |
| T4 | 值班经理 | 12. 发布演练公告 | 钉钉群、邮件、ITSM 关闭工单 | 30 s |

**关键断点**：
- 第 4 步若出现 **ORA-01093: ALTER DATABASE CLOSE only permitted with no other sessions**，表示仍有活跃会话；使用 `KILL SESSION` 或 `WITH SESSION SHUTDOWN` 强制断开。
- 第 9 步若 **订单接口 RT>500 ms 或错误率>1%**，立即回切——脚本已内置 `failback.sh`，30 s 内可回到原角色。

---

## 五、回切演练：让“回家”的路同样畅通
维护窗口结束后，需把角色换回原始主备。回切流程与正向切换 **完全对称**，但必须在 **低峰期** 执行，注意：
1. 确认新 Standby（原 Primary）已 **无延迟**；
2. 使用 **Flashback Database** 把新 Standby 回退至切换点，避免 ** incarnation 分叉**；
3. 更新 **DG Broker** 配置：
```sql
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
DGMGRL> SWITCHOVER TO 'OldPrimary';
```
4. 启动 **级联归档**（若存在 Cascade Standby）；
5. 应用侧 **DNS TTL** 提前改为 60 s，确保快速漂移。

---

## 六、复盘与度量：用数据说话
每次演练结束后 24 h 内输出 **《Switchover 演练报告》**，包含：
1. **RTO 实测值**——从停止流量到应用可下单的端到端时间；
2. **RPO 验证**——对比两库 `MAX(SEQUENCE#)` 与 `APPLIED_SCN`，确认 0 丢失；
3. **性能基线差异**——AWR 快照前后 **DB Time、log file sync、Transaction throughput** 波动范围；
4. **问题清单**——如 ORA-错误、脚本超时、人工干预次数；
5. **改进项**——下一次演练前必须关闭的 **P0、P1 缺陷**；
6. **签字确认**——DBA、应用、网络、存储、安全五方负责人电子签名，留档备查。

---

## 七、常见故障场景与快速修复
| 现象 | 根因 | 应急处理 |
|------|------|----------|
| Switchover hang 在 **Active sessions exist** | 业务连接池未下线 | `ALTER SYSTEM ENABLE RESTRICTED SESSION;` 或 `KILL` 批量会话 |
| 新 Primary 打开后 **ORA-01110: data file 1 needs media recovery** | 数据文件头 SCN 不一致 | 立即 `FLASHBACK DATABASE TO SCN <switchover SCN>`，重新切换 |
| 应用启动报 **ORA-12514: TNS:listener does not currently know of service** | dbms_service 未注册 | 在新 Primary 执行 `DBMS_SERVICE.START_SERVICE('PROD')` |
| 回切时 **DGMGRL 报 Warning: standby has diverged** | incarnation 分叉 | 使用 `FLASHBACK DATABASE TO RESTORE POINT` 后重新 `REINSTATE` |

---

## 八、工具与脚本清单（开源可下载）
1. **dtach**——防止 SSH 断开导致切换命令中断；
2. **oracle-dg-switchover-kit**（GitHub）——包含 `pre_check.sh、switchover.sh、failback.sh、awr_compare.sql`；
3. **Zabbix Template Oracle DG**——自动采集 `Transport Lag、Apply Lag、Role`，Lag>5 s 触发微信；
4. **Jenkins Pipeline**——一键发起演练，钉钉审批流，执行过程日志实时推送到 ELK。

---

## 九、结语：把演练写进 DNA
Switchover 演练不是“年度表演”，而是 **DataGuard 高可用闭环**的氧气：
- 一季度不练，手生；
- 半年不练，流程过期；
- 一年不练，灾难来临时就是 **Failover 重建 18 小时** 的噩梦。

只有把演练做成 **标准化、脚本化、度量化、常态化**，才能真正让“计划内零丢失”从 PPT 口号变成 **凌晨 3 点也能安心执行的确定性操作**。