三墩IT人经过多年的技术沉淀，已建设完整的运维体系，并通过运维数智化转型不断向自智IT系统演进。以数据库为例，当前已建设20余类自愈模型，日均自愈200余次，通过“一键应急”容灾切换平台，可确保95%以上故障10分钟内恢复，全年数据库可用性超99.99%。但由于业务增长迅猛、应用层伸缩自如的海量并发及早期ADG版本技术限制等情况，导致了我们距离RTO<1分钟的目标尚有较大差距。Oracle 19C作为当前Oracle对外提供的最新的长期支持稳定版本，已有相关的新特性改善11g、12c的部分技术限制。三墩IT人在Oracle 19c过程中对Far Sync、SQL隔离、统计信息自动化等新特性进行了充分的实践，极大的改善了MTTR及MTBF。浙江移动信息技术部自2019年IE全面下线，核心数据库的容灾能力使用ADG来实现，通过容灾端只读供服，分流外围抽数系统降低生产压力。在应用实践的过程中，ADG在给生产环境降低部分访问压力的同时也存在部分隐患，影响较大的两个问题如下。1、最大可用、最大保护模式的使用会影响生产环境的稳定性。跨机房层面的最大可用模式、redo实时同步设置，易导致业务高峰期的性能波动，log file sync延迟耗时会有显著提升，前台业务卡顿感知明显，降低生产环境稳定性。2、最大性能模式，在主端不可用情况下无法保障容灾端数据零丢失，影响容灾供服效率。主端异常情况下，为确保数据零丢失，备端switchover需要优先恢复主端，导致故障场景无法实现业务供服能力的快速恢复。以11g为例，业务低峰期切换演练，整体耗时可以控制在5~10分钟，而故障期间，主端额外恢复至可切换状态就需额外耗时5~10分钟，导致RTO大幅增长。
1、新增Far Sync 实例，加强数据同步效率，降低生产同步压力与性能波动风险。19C具备的Active Data Guard Far Sync功能，通过在距离主库相对较近的地点配置 Far Sync 实例，可运行在最大可用和最大性能模式（不支持最大保护），根据ADG同步模式的差异，主库优先实时/异步传输redo 到 Far Sync 实例，再由Far Sync 实例将redo异步传输到一个或多个备端，主库和 Far Sync 距离较近，网络延时很小，降低主库压力的同时确保数据零丢失。2、Far Sync 配置对于 Data Guard 角色转换是透明的，即 switchover/failover 命令方式与之前相同。3、考虑到可能发生 Data Guard 角色转换，即 switchover/failover，可以在距离备库较近的地方也配置Far Sync实例，这个 Far Sync 实例只有在当前的备库切换为主库后才启用。
现网生产环境采用Primary+Single Far Sync+ Standby+ Single Far Sync架构，通过Group和 Priority来控制日志传输的优先级。
对于已经部署ADG的19C环境，新增Far Sync节点时，主备环境只需关注log_archive_config、log_archive_dest_n参数的变动，并利用Group和 Priority的配置，控制日志传输的优先级和方向。SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=yytxd_farsync2 SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=1 DB_UNIQUE_NAME=yytxd_farsync2'; System altered. SQL> alter system set LOG_ARCHIVE_DEST_3='SERVICE=yytxd ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) GROUP=1 PRIORITY=8 DB_UNIQUE_NAME=yytxd'; System altered. SQL>alter system set LOG_ARCHIVE_DEST_STATE_2=ENABLE ; System altered. SQL>alter system set LOG_ARCHIVE_DEST_STATE_3=ALTERNATE; System altered. |
1、 以大数据资源池为例，演练时模拟主库宕机，Far Sync节点采用sync模式同步日志，容灾端采用“ alter database commit to switchover to primary;“或“alter database failover to standby_unque_name;”方式进行激活，4次演练，均未出现因为归档缺失(ORA-16434)导致的激活失败报错信息。2、 采用failover激活时，主端因为未进行主切备操作，备库激活后，尽管数据零丢失，但会存在容灾丢失的问题。需要尽快恢复主端灾备能力。
19C版本之前，Oracle提供了无损（Switchover）、有损（Failover）两种切换方案（当前failover RPO>0,RTO<120s;switchover RPO=0,RTO不可控）。但由于Failover会导致数据丢失，实际生产中仅使用了Switchover，导致故障场景覆盖不全。Oracle 19C通过增加Far Sync日志同步实例，可在主端不可用情况下提供无损Failover服务，将Failover的RPO降为0，有效降低MTTR，数据库在出现灾难性故障的情况下，备端依然可以进行零数据丢失的failover尝试，弥补了11g、12c版本切换方案场景覆盖不全的问题，有了选择尝试的余地。
现网数据库运维过程中，DBA通过部署自动查杀功能，对满足一定条件并持续一段时间的异常会话及时进行查杀，避免异常影响范围扩大。例如：①维护不规范操作导致的并发使用异常，②sql不规范导致的temp消耗异常，③作业集中发起导致的IO争用，④维护未及时提交导致的锁堵塞等。但自动查杀功能为每分钟一次的定时查杀，针对每秒数千次的高频劣质sql，一分钟一次的查杀进程，无法有效处理并隔离。而在19C使用过程中发现，SQL隔离功能，能够很好的补足这一短板。
SQL Quarantines是Oracle database 19c中新增加的特性，该特性可以隔离SQL语句的特定执行计划，当SQL语句以隔离的执行计划再次执行时将被终止执行，从而避免数据库因效率不高的执行计划导致的性能下降问题。此外，还可以使用DBMS_SQLQ包针对sql语句的执行计划创建SQL隔离配置（quarantine configuration），然后根据需求来指定隔离阈值（quarantine thresholds）。同时，Resource Manager中也设置了各种系统资源阈值，当其中任何一个阈值不大于SQL隔离配置中的设置的阈值时，quarantine configuration中对应的SQL执行计划将无法再次运行。
配置使用resource manager工具，将目标用户执行SQL语句的执行时间限制在3秒以内，超过3秒的SQL将被终止执行。主要分以下几步：2）将目标用户加入到创建的consumer group中3）创建一个resource plan，该plan中执行时间超过3秒的SQL将被终止4）将新创建的resource plan和consumer group关联2. 通过DBA_SQL_QUARANTINE视图确认SQL隔离配置情况，业务发起前会发现并无SQL隔离结果。示例SQL： select name,PLAN_HASH_VALUE,CPU_TIME,ELAPSED_TIME,ENABLED,CREATED from DBA_SQL_QUARANTINE; |
3. 以目标用户登陆数据库执行耗时超过3秒的SQL语句，此时出现ORA-00040报错，显示执行耗时超时被中断。ORA-00040: active time limit exceeded - call aborted |
4. 问题SQL再次执行，会被加入隔离列表，再次尝试执行会出现ORA-56955报错ORA-56955: quarantined plan used |
quarantine configuration每隔15分钟会自动刷新一次，刷新时间在每个小时的10、25、40、55分，因此在执行sql后最多等待15分钟即可看到以上报错信息。此外，也可以手动创建quarantine configuration并指定阈值使得对应的执行计划立即被隔离。通过DBA_SQL_QUARANTINE、V$SQL视图来确认SQL隔离详情及隔离次数等相关信息（可通过sql_quarantine列进行关联）
现网维护团队可以在当前数据库自动查杀的基础上，结合SQL隔离功能，能够解决持续高频SQL无法及时查杀隔离的问题，进一步提升数据库稳定性。
默认情况下，oracle数据库每天会进行一次自动统计信息收集任务，在更新统计信息的同时，也会导致部分表统计信息失效，例如每日凌晨建空表，白天写入数据后再进行查询，oracle在生成执行计划时极易因为统计信息不准确导致执行计划出现偏差，进而导致SQL资源消耗异常。
实时统计信息：在执行DML操作时自动更新相关表的统计信息，使得优化器能够产生更为合理的执行计划。该特性默认打开，由隐藏参数_optimizer_gather_stats_on_conventional_dml控制，可以将该参数设置为false来禁用该特性。高频率优化器统计信息：默认每15分钟会执行一次，该任务是轻量级的且只收集过期的统计信息，从而在对数据库性能影响很小的前提下使SQL生成更准确的执行计划。实时统计信息与高频率优化器统计信息收集可以对每天的自动统计信息收集任务进行有效地补充。
1) 实时统计信息会针对每个DML操作进行统计，并定时将DML操作结果刷新到统计信息中，所以表的统计信息总是最新的，CBO在计算SQL执行成本时可以更加准确，从而生成正确的执行计划。2) 高频统计信息功能在数据库存在大量过期统计信息的表时，会导致进程一直处于IN PROGRESS状态，重启数据库后仍然无法解决，需手动搜集异常表来恢复进程。3) 高频统计信息与实时统计的操作都会消耗一定的数据库资源，当有大量DML同时进行操作，或大量的过期统计信息需要更新时，会消耗大量的数据库资源，反而影响数据库稳定性。
统计信息是否准确直接影响sql的执行计划，19C之前只提供了搜集统计信息的调度作业，在业务低峰期的统计信息搜集窗口内对统计信息过期或没有统计信息的表进行批量搜集，一旦超出搜集窗口还没有进行搜集统计信息的表，只能在下次搜集窗口进行搜集操作。实时统计信息搜集和高频统计信息搜集能够解决这类因为统计信息不准导致sql产生错误执行计划的情况发生。但结合生产环境评估，此类特性更适合承载OLAP类业务的系统，数据库内表对象的访问并发度低，每日数据变动大，可有效解决统计信息不准确导致的执行计划偏差问题。
如何在灾难场景下实现零数据丢失的快速恢复是长久以来困扰我们的问题，19c的三大新特性有效解决了这一难题，显著提升了Oracle数据库稳定性，极致接近实现RTO<1分钟的目标。三墩IT人未来也将在各类数据库中探索更多技术特性并实践落地，持续提升数据库预测性维护能力，减少故障发生；在现有运维自智L3能力的基础上，提升自动化决策、故障恢复的能力，持续向运维自智L4推进，将运维应急从机器辅助人+人决策后续应急操作，转向机器完成决策与应急操作+人优化机器的能力，实现数据库服务零中断的目标。
最后修改时间：2022-03-04 13:11:39
文章转载自
甲骨文云技术，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
