[发明专利]一种营销业务系统运维应急处置及快速恢复方法

摘要

本发明提供一种营销业务系统运维应急处置及快速恢复方法，其特征在于：包括下述情况处理：一、数据中心站点灾难：二、发现数据丢失；三、数据库主机的CPU高；四、应用系统表现慢；五、数据库归档文件占满存储空间；六、unix系统某个挂载点的空间使用率超过预警阀值的处理方法；七、关键业务应用策略。规范紧急故障的处理流程，实现迅速、有序、高效的故障排查与解决，最大程度缩短故障时间，保证营销基础数据平台系统的安全稳定运行，提高运行维护水平。

主权项

1.一种营销业务系统运维应急处置及快速恢复方法，其特征在于：包括下述情况处理：一、数据中心站点灾难：需要进一步分析判断故障的严重程度，再决定是否启用经过数据复制生成的查询库，作为生产数据库；如决定使用查询库，则需要如下关键步骤：(1)停止数据库复制软件在查询库上的进程；(2)停止业务应用程序；(3)将业务应用程序的对原有生产数据库的连接访问配置全部调整到对查询库进行访问；(4)重新启用应用程序；二、发现数据丢失：(1)少量数据丢失处理方法：由应用程序设计、开发人员检查数据不一致的状况，具体丢失情况在本文档中无法尽述，总体而言，要分析严重程度，考察是否能够通过业务操作进行弥补，能够弥补的，则通过业务操作来完成；否则采用“数据库恢复处理方法”；(2)通过数据库恢复的处理方法：不论是少量数据或是大量数据，只要无法通过业务操作、业务流程等手段恢复的，都需要通过数据库恢复的处理方法来完成恢复；三、数据库主机的CPU高：(1)通过top‑h查看CPU高的进程，得到进程号，即pid；(2)用sql工具语句找到相应的会话，和执行SQL；(3)管理员身份登录数据库服务器，执行杀掉此会话(session)；(4)数据库中长时间存在锁(锁等待)；应急步骤：(1)通过sql工具查看锁的状况；(2)观察哪个session是起头加锁的；(3)记录下会话的当前sql；(4)如果锁等待的时间超过10分钟，同时锁的个数比较少，可以杀掉进程；(5)如果锁的数量比较多，且存在继续增加迹象，也应立即杀锁；(6)将所获取的sql发给技术专家组进行分析；四、应用系统表现慢：(1)查看数据库上是否有锁，如果有按照对应的技术方法处理；(2)查看数据库主机CPU是否高。如果高，则查找相应sql，并按照对待数据库CPU高的方式来处理会话；(3)查看应用服务器是否异常(CPU高、垃圾回收异常、等待队列>0)，如果是，则按应用服务器CPU高的方法进行处理；(4)后续处理：做数据库的stackpack性能分析；分析线程导出的结果，定位应用中可能存在的问题，并将结果反馈给技术专家组。由技术专家组对这个缺陷进行分析并完善；五、数据库归档文件占满存储空间：分两种情况，一种是当前数据库归档文件占满存储空间。这种需要马上处理，直接登录服务器将归档文件转移，然后删除相应的归档文件，如果时间来不及则直接删除归档文件；第二种情况是预计在下一次数据库备份之前，归档文件会占满存储空间，这种情况最好是登录备份服务器手动执行一次备份，如果判断时间来不及则采用第一种情况的处理方法；需要提前制定出手动执行备份的方法；六、unix系统某个挂载点的空间使用率超过预警阀值的处理方法：(1)通过du‑s*命令在该挂载点下查看每个目录和文件的大小情况；(2)进入空间占用比较大的目录，用同样的方法确定目录和文件的大小；(3)判断原因的属于哪一种。如果是a，则联系相关人员确定可否删除；如果是b或c，则联系系统管理人员或相关厂商进行确认；(4)确认可以删除后，如果时间和条件允许，要先将待删除的文件备份到本地；(5)使用rm命令删除时，要确认使用的命令选项完全正确。使用通配符进行批量删除时，要先用ls命令验证通配符的用法是否正确，以免误操作；七、关键业务应用策略：当发生数据库或应用服务器故障，短时间不能恢复时建议采取以下应急措施：(1)概述说明由于系统故障，对应用业务的影响，如何恢复正常；(2)按照压力优先级别，窗口，优质服务等分出应用业务的恢复顺序。