印刻数据库

外观

Oracle 计划切换 ​

计划切换的概念和目的 ​

基本概念 ​

  1. 计划切换定义

    • Oracle Data Guard 中的一种受控操作
    • 将主数据库角色切换到备数据库
    • 同时将原主数据库转换为备数据库角色
    • 是一个可逆的、零数据丢失的操作

  2. 与故障转移的区别

    • 计划切换：受控操作，零数据丢失，主库和备库都可用
    • 故障转移：非受控操作，通常在主库不可用时执行，可能有数据丢失

  3. 切换过程

    • 主库将所有重做数据传送到备库
    • 备库应用所有接收的重做数据
    • 角色转换：备库变为新主库，原主库变为新备库
    • 更新网络配置和应用程序连接

主要目的 ​

  1. 计划维护

    • 主库硬件或操作系统升级
    • 数据库补丁应用
    • 数据库版本升级
    • 存储维护或扩容

  2. 负载均衡

    • 在不同时间段使用不同的数据库作为主库
    • 平衡系统资源使用
    • 优化不同时区的应用程序性能

  3. 灾难预防

    • 定期演练切换过程，确保在真正灾难发生时能够快速响应
    • 验证备库的可用性和完整性
    • 测试灾难恢复流程

  4. 合规要求

    • 满足行业监管要求的灾难恢复测试
    • 定期验证数据保护措施的有效性
    • 记录切换过程和结果

计划切换的前提条件 ​

数据库环境要求 ​

  1. Data Guard 配置

    • 正确配置 Data Guard 环境
    • 主库和备库之间网络连接正常
    • 启用归档模式
    • 配置正确的重做传输模式

  2. 数据库状态

    • 主库处于正常运行状态
    • 备库处于同步或延迟应用状态
    • 没有悬而未决的重做数据
    • 所有归档日志都已传送到备库

  3. 软件版本

    • 主库和备库使用相同的 Oracle 版本
    • 补丁级别一致
    • 兼容的操作系统版本

  4. 硬件要求

    • 备库硬件配置至少与主库相当
    • 足够的存储空间
    • 适当的网络带宽

准备工作 ​

  1. 切换计划

    • 制定详细的切换计划和时间表
    • 明确切换步骤和责任分工
    • 确定回滚策略
    • 通知相关人员和业务部门

  2. 环境检查

    • 检查主库状态：

      sql
      SELECT database_role, open_mode FROM v$database;
SELECT SWITCHOVER_STATUS FROM v$database;

    • 检查备库状态：

      sql
      SELECT database_role, open_mode FROM v$database;
SELECT SWITCHOVER_STATUS FROM v$database;

    • 检查重做应用状态：

      sql
      SELECT recovery_mode, protection_mode FROM v$archive_dest_status WHERE dest_id = 2;

  3. 网络配置

    • 确保主库和备库之间网络连通
    • 验证监听器配置
    • 检查 tnsnames.ora 配置
    • 测试连接性

  4. 应用程序准备

    • 通知应用程序管理员
    • 安排应用程序维护窗口
    • 准备应用程序连接字符串更新
    • 测试应用程序故障转移机制

  5. 备份策略

    • 在切换前执行主库的完整备份
    • 确保备库有有效的备份
    • 验证归档日志备份
    • 准备恢复所需的备份文件

计划切换的步骤 ​

切换前准备 ​

  1. 确认切换状态

    • 在主库上检查：

      sql
      SELECT SWITCHOVER_STATUS FROM v$database;

      预期结果：TO STANDBY 或 SESSIONS ACTIVE

    • 在备库上检查：

      sql
      SELECT SWITCHOVER_STATUS FROM v$database;

      预期结果：TO PRIMARY 或 RECOVERY NEEDED

  2. 验证重做传输

    • 检查主库归档状态：

      sql
      SELECT status, error FROM v$archive_dest WHERE dest_id = 2;

    • 检查备库应用状态：

      sql
      SELECT sequence#, applied FROM v$archived_log ORDER BY sequence# DESC;

  3. 准备应用程序

    • 停止写入主库的应用程序
    • 确保所有事务已提交
    • 等待所有活动会话完成

执行切换操作 ​

  1. 主库角色转换

    • 将主库转换为备库：

      sql
      ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

    • 关闭并重启原主库：

      sql
      SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

  2. 备库角色转换

    • 将备库转换为主库：

      sql
      ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

    • 打开新主库：

      sql
      ALTER DATABASE OPEN;

  3. 启动重做应用

    • 在新备库（原主库）上启动重做应用：
      sql
      ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

  4. 验证新备库状态

    • 检查新备库状态：
      sql
      SELECT database_role, open_mode FROM v$database;
SELECT recovery_mode FROM v$archive_dest_status WHERE dest_id = 2;

切换后操作 ​

  1. 网络配置更新

    • 更新 tnsnames.ora 文件中的连接字符串
    • 更新监听器配置（如需）
    • 更新负载均衡器配置
    • 更新 DNS 记录（如需）

  2. 应用程序连接更新

    • 更新应用程序连接字符串
    • 重启应用程序服务
    • 测试应用程序连接
    • 验证应用程序功能

  3. 监控和验证

    • 监控新主库的性能和状态
    • 验证重做数据传输到新备库
    • 检查应用程序日志中的错误
    • 执行基本的数据库操作测试

  4. 文档更新

    • 记录切换过程和结果
    • 更新数据库拓扑文档
    • 更新监控系统配置
    • 记录任何遇到的问题和解决方案

不同环境下的计划切换 ​

物理备库切换 ​

  1. 特点

    • 使用物理备用数据库
    • 基于块级复制
    • 支持实时应用重做数据
    • 切换过程相对简单

  2. 切换步骤

    • 按照标准计划切换步骤执行
    • 确保物理备库处于 MOUNT 或 READ ONLY 状态
    • 验证重做应用已完成

  3. 示例

    • 主库操作：

      sql
      ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

    • 备库操作：

      sql
      ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;

逻辑备库切换 ​

  1. 特点

    • 使用逻辑备用数据库
    • 基于 SQL 应用
    • 支持异构平台
    • 切换过程相对复杂

  2. 切换步骤

    • 确保逻辑备库已应用所有重做数据
    • 执行切换操作
    • 验证逻辑备库转换为主库后的状态

  3. 示例

    • 主库操作：

      sql
      ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP;

    • 备库操作：

      sql
      ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

RAC 环境切换 ​

  1. 特点

    • 主库和备库都是 RAC 集群
    • 需要考虑集群资源管理
    • 网络配置更复杂
    • 需要协调多个节点

  2. 切换步骤

    • 停止主库集群上的应用程序
    • 按照标准切换步骤执行
    • 协调所有节点的切换操作
    • 更新 RAC 相关的网络配置

  3. 注意事项

    • 确保所有 RAC 节点都已准备就绪
    • 协调集群资源的启动和停止
    • 更新 SCAN 监听器配置
    • 验证所有节点的状态

多备库环境切换 ​

  1. 特点

    • 一个主库对应多个备库
    • 需要更新所有备库的配置
    • 切换后需要重新配置重做传输

  2. 切换步骤

    • 选择一个备库作为新主库
    • 执行标准切换操作
    • 重新配置其他备库以指向新主库
    • 验证所有备库的重做传输

  3. 配置更新

    • 更新其他备库的重做源：
      sql
      ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=new_primary LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=new_primary' SCOPE=BOTH;

计划切换的监控和验证 ​

切换过程监控 ​

  1. SQL*Plus 监控

    • 检查切换状态：

      sql
      SELECT SWITCHOVER_STATUS FROM v$database;

    • 监控重做传输：

      sql
      SELECT status, error FROM v$archive_dest WHERE dest_id = 2;

    • 监控会话状态：

      sql
      SELECT sid, serial#, status, username FROM v$session;

  2. Enterprise Manager 监控

    • 使用 Data Guard 控制台监控切换过程
    • 查看切换进度和状态
    • 监控重做应用速率
    • 查看任何错误或警告

  3. 日志监控

    • 查看告警日志：

      bash
      tail -f $ORACLE_BASE/diag/rdbms/<dbname>/<instance>/trace/alert_<instance>.log

    • 查看 listener 日志：

      bash
      tail -f $ORACLE_HOME/network/log/listener.log

切换后验证 ​

  1. 数据库状态验证

    • 检查新主库状态：

      sql
      SELECT database_role, open_mode FROM v$database;
SELECT instance_name, status FROM v$instance;

    • 检查新备库状态：

      sql
      SELECT database_role, open_mode FROM v$database;
SELECT recovery_mode FROM v$archive_dest_status WHERE dest_id = 2;

  2. 重做传输验证

    • 检查新主库的归档状态：

      sql
      SELECT status, error FROM v$archive_dest WHERE dest_id = 2;

    • 检查新备库的应用状态：

      sql
      SELECT sequence#, applied FROM v$archived_log ORDER BY sequence# DESC;

  3. 应用程序验证

    • 测试应用程序连接
    • 执行基本的 CRUD 操作
    • 验证业务功能
    • 检查应用程序日志

  4. 性能验证

    • 监控新主库的性能指标
    • 检查资源使用情况
    • 验证响应时间
    • 比较切换前后的性能

计划切换的最佳实践 ​

切换前准备 ​

  1. 详细的切换计划

    • 制定分步骤的切换计划
    • 明确每个步骤的责任人
    • 设定时间窗口和期望完成时间
    • 准备回滚方案

  2. 充分的测试

    • 在测试环境中演练切换过程
    • 记录测试结果和遇到的问题
    • 根据测试结果优化切换计划
    • 确保所有参与人员熟悉切换流程

  3. 全面的检查

    • 检查 Data Guard 配置状态
    • 验证网络连接和带宽
    • 检查存储空间使用情况
    • 确认备份的完整性

  4. 有效的沟通

    • 提前通知所有相关团队
    • 建立切换期间的沟通渠道
    • 及时通报切换进度和状态
    • 记录所有沟通内容

切换执行 ​

  1. 严格按照计划执行

    • 按照预定的步骤顺序执行
    • 确认每个步骤完成后再进行下一步
    • 记录每个步骤的开始和完成时间
    • 及时处理遇到的问题

  2. 最小化停机时间

    • 优化切换步骤，减少不必要的等待时间
    • 并行执行可以同时进行的操作
    • 提前准备所有需要的命令和脚本
    • 确保网络和存储性能良好

  3. 确保数据完整性

    • 等待所有重做数据传送到备库
    • 验证备库已应用所有重做数据
    • 确认没有数据丢失
    • 验证新主库的数据一致性

  4. 安全操作

    • 使用合适的数据库权限执行切换操作
    • 确保操作过程有适当的审计
    • 保护敏感信息，如密码和连接字符串
    • 遵循公司的安全策略

切换后管理 ​

  1. 全面的验证

    • 验证所有数据库功能正常
    • 确认应用程序连接和功能
    • 检查性能和资源使用
    • 验证 Data Guard 配置恢复正常

  2. 及时的配置更新

    • 更新所有相关的网络配置
    • 修改监控系统配置
    • 更新文档和记录
    • 通知所有相关方切换完成

  3. 持续的监控

    • 增加切换后一段时间的监控频率
    • 密切关注数据库性能和稳定性
    • 监控重做传输和应用状态
    • 准备应对可能出现的问题

  4. 经验总结

    • 记录切换过程中的经验和教训
    • 分析切换时间和效率
    • 提出改进建议
    • 更新切换计划和流程

计划切换的故障排除 ​

常见问题及解决方案 ​

  1. 切换状态不正确

    • 问题：主库或备库的 SWITCHOVER_STATUS 不是预期值
    • 解决方案：
      • 检查 Data Guard 配置
      • 验证网络连接
      • 确保所有重做数据已传输和应用
      • 等待一段时间后重新检查

  2. 重做传输失败

    • 问题：主库无法将重做数据传送到备库
    • 解决方案：
      • 检查网络连接
      • 验证备库状态
      • 检查归档日志目录空间
      • 重启重做传输进程

  3. 应用程序连接失败

    • 问题：应用程序无法连接到新主库
    • 解决方案：
      • 检查网络配置
      • 验证监听器状态
      • 更新应用程序连接字符串
      • 重启应用程序服务

  4. 切换后性能下降

    • 问题：新主库性能比原主库差
    • 解决方案：
      • 检查硬件资源使用情况
      • 验证数据库参数设置
      • 检查索引和统计信息
      • 优化 SQL 语句

  5. 无法回滚切换

    • 问题：切换后需要回滚，但操作失败
    • 解决方案：
      • 检查新主库和新备库的状态
      • 确保网络连接正常
      • 验证重做传输状态
      • 按照标准切换步骤反向执行

故障排除工具 ​

  1. SQL*Plus 命令

    • 查看 Data Guard 状态：

      sql
      SELECT * FROM v$dataguard_config;
SELECT * FROM v$dataguard_status;

    • 查看归档状态：

      sql
      SELECT * FROM v$archive_dest;
SELECT * FROM v$archive_dest_status;

    • 查看会话状态：

      sql
      SELECT * FROM v$session WHERE status = 'ACTIVE';

  2. 日志文件

    • 告警日志：包含切换过程的详细信息和错误
    • 监听器日志：包含网络连接信息
    • 归档日志：验证重做数据传输

  3. Enterprise Manager

    • Data Guard 控制台：提供切换状态和进度
    • 性能监控：查看资源使用情况
    • 告警系统：显示任何问题或警告

  4. 网络工具

    • ping：检查网络连通性
    • tnsping：检查 Oracle 网络服务
    • traceroute：检查网络路径
    • netstat：查看网络连接状态

常见问题（FAQ） ​

Q1: 计划切换需要多长时间？ ​

A1: 计划切换的时间取决于多个因素：

  • 数据库大小和活动程度
  • 网络带宽和延迟
  • 备库应用重做数据的速度
  • 应用程序停止和重启时间

一般来说，小型数据库的切换可能在几分钟内完成，大型数据库可能需要几十分钟。主要的时间消耗在等待重做数据传输和应用的过程中。

Q2: 计划切换会导致数据丢失吗？ ​

A2: 正常情况下，计划切换是零数据丢失的操作。在切换过程中：

  1. 主库会等待所有事务完成或终止
  2. 所有重做数据会被传送到备库
  3. 备库会应用所有接收的重做数据
  4. 只有在确认所有数据都已同步后才会执行角色转换

如果在切换过程中出现网络故障或其他问题，可能会导致切换失败，但不会导致数据丢失。

Q3: 如何验证备库已准备好进行切换？ ​

A3: 验证备库准备情况的步骤：

  1. 检查备库状态：

    sql
    SELECT database_role, open_mode FROM v$database;
SELECT SWITCHOVER_STATUS FROM v$database;

  2. 检查重做应用状态：

    sql
    SELECT sequence#, applied FROM v$archived_log ORDER BY sequence# DESC;

  3. 检查备库与主库的同步状态：

    sql
    SELECT PRIMARY_DB_UNIQUE_NAME, STANDBY_DB_UNIQUE_NAME, DB_UNIQUE_NAME FROM v$dataguard_config;

  4. 验证备库的物理和逻辑完整性：

    sql
    SELECT * FROM v$database_block_corruption;

Q4: 切换后如何处理应用程序连接？ ​

A4: 处理应用程序连接的方法：

  1. 使用 Transparent Application Failover (TAF)：

    • 在 tnsnames.ora 中配置 TAF
    • 应用程序会自动切换到新主库

  2. 使用连接字符串中的多个地址：

    NEW_PRIMARY = 
  (DESCRIPTION = 
    (ADDRESS_LIST = 
      (ADDRESS = (PROTOCOL = TCP)(HOST = new_primary_host)(PORT = 1521)) 
    ) 
    (CONNECT_DATA = 
      (SERVICE_NAME = primary_service) 
    ) 
  )

  3. 使用负载均衡器：

    • 更新负载均衡器配置，将流量导向新主库
    • 应用程序使用负载均衡器地址，无需更改连接字符串

  4. 手动更新：

    • 停止应用程序
    • 更新连接字符串
    • 重启应用程序

Q5: 如何回滚计划切换？ ​

A5: 回滚计划切换的步骤：

  1. 确认当前状态：

    • 新主库和新备库都处于正常状态
    • 重做数据传输正常

  2. 执行反向切换：

    • 在当前主库（原备库）上执行：

      sql
      ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

    • 在当前备库（原主库）上执行：

      sql
      ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;

  3. 更新配置：

    • 恢复原始的网络配置
    • 更新应用程序连接字符串
    • 恢复监控系统配置

Q6: 计划切换对数据库性能有什么影响？ ​

A6: 计划切换对数据库性能的影响：

  • 切换期间：

    • 主库需要将所有重做数据传送到备库，可能导致临时性能下降
    • 应用程序需要停止并重启，导致服务中断

  • 切换后：

    • 新主库可能需要一段时间来达到最佳性能状态
    • 可能需要调整数据库参数以适应新的硬件环境
    • 缓存需要重新预热，可能导致初始查询性能较慢

  • 长期影响：

    • 如果新主库硬件配置更好，性能可能会提升
    • 定期切换可以平衡系统资源使用，提高整体可用性

Q7: 如何在 RAC 环境中执行计划切换？ ​

A7: RAC 环境中的计划切换步骤：

  1. 准备工作：

    • 停止所有节点上的应用程序
    • 确保所有 RAC 节点都已准备就绪
    • 协调所有节点的切换操作

  2. 执行切换：

    • 在主库 RAC 集群的一个节点上执行切换命令
    • Oracle 会自动协调所有节点的切换操作
    • 等待所有节点完成角色转换

  3. 更新配置：

    • 更新 RAC 集群的网络配置
    • 更新 SCAN 监听器配置
    • 更新负载均衡器配置

  4. 验证：

    • 检查所有 RAC 节点的状态
    • 验证新主库集群的可用性
    • 测试应用程序连接到所有节点

Q8: 如何定期测试计划切换？ ​

A8: 定期测试计划切换的建议：

  1. 制定测试计划：

    • 确定测试频率（如每季度或每半年）
    • 选择合适的测试窗口（如非业务高峰期）
    • 明确测试目标和成功标准

  2. 准备测试环境：

    • 使用与生产环境相似的测试环境
    • 确保测试环境配置正确
    • 准备测试数据和应用程序

  3. 执行测试：

    • 按照生产环境的切换计划执行
    • 记录测试过程和时间
    • 测试各种场景，如正常切换、中断恢复等

  4. 评估结果：

    • 分析测试过程中的问题和挑战
    • 评估切换时间和效率
    • 提出改进建议

  5. 更新文档：

    • 根据测试结果更新切换计划
    • 记录测试经验和最佳实践
    • 培训团队成员掌握最新的切换流程

定期测试计划切换不仅可以验证灾难恢复机制的有效性，还可以帮助团队熟悉切换流程，提高在真正需要时的响应速度和准确性。