重要批量和备份的监控优化

一、问题和处理过程

1、月底批量超时

2月1日19:40告警报出ORSS-SG excess time。经值班人员和DBA分析是ORSS-SG月批SGP_2701_MANUAL作业执行计划偏离引起，重新收集相关表统计信息后，杀掉会话并重启SG批量进程和重提SGP_2701_MANUAL作业后，1月31日批量于2月2日4:56完成。2月2日9:00巡检SG批量发现1月31日批量完成后并未切日。值班人员检查SG批量进程错误的启动在节点2，与维护A角和开发人员确认正确是应该在节点2启动后，在节点2上启动了SG批量进程，批量日期成功切日到2月1日，此时已经是2月2日11:40。

2、备份检查未通过

批量切日到2月1日后，发现SGP_DB_BK_STATUS_CHECK作业卡住。检查etl_db_bk_status表的SUC_FLG字段为N，代表上一日批后的备份尚未完成，需等待上一日批后备份完成。后台检查当时并无备份进程在运行，分析可能是前一晚应急措施后导致备份作业没调起。开发和业务在行信群中提出月底备份必须要留存，不能跳过，商定手工调起上一日备份脚本。查看备份脚本（如图），发现备份脚本存在2点问题

1. 全库备份没有开并行
2. 备份后再压缩
据A角反应此前备份约需要10个小时左右，如仍按此方式调起备份，2月1日批量的真正开始时间将会在2月2日22:00以后，批量仍将延迟。

3、压缩备份时间

12：50手工执行数据库导出expdp 命令时增加parallel=4 compression=ALL参数，预计3个小时完成备份。实际备份完成时间在17：50左右。备份时间比预计长的原因是库中有大表且不是分区表，对于单个表导出时，无法并行，如图：

备份完成后，18：04修改etl_db_bk_status表的状态，2月1日批量开始正式跑起，2月2日批量中的出报表作业也在2月3日SG分行9：00前跑完。

二、备份和监控优化建议

1、备份

• 适当开并行 parallel=N
• 导出即压缩 compression=ALL
• 剔除掉无用的大表，例如MUREX_CSHFLOW_BAK201907

2、监控

• 增加备份完成监控， etl_db_bk_status表的suc_flg字段
• 增加重要作业监控，例如业务非常看重月底报表，每月1号应增加SGP_2701_MANUAL完成时间和耗时的监控