本发明涉及电力营销技术领域，具体为一种营销业务系统运维应急处置及快速恢复方法。
背景技术：
随着国网辽宁省电力有限公司大营销体系建设及不断的完善，营销分析与辅助决策系统需要根据营销系统进行相关升级变更以符合完善的报表需求，资源得到有效整合，在传统报表业务不断加强的基础上，营销分析与辅助决策系统进行报表更新、新增。现为大营销体系提供信息化支撑，保障国网辽宁省电力有限公司辅助决策系统报表稳定运行，需要大量的人力及可靠的技术支持服务，以保障顺利完成国网辽宁省电力有限公司全年的各项指标能够达标。
针对营销基础数据平台的业务特殊性，营销基础数据平台系统的维护工作作为重点技术难点，现有处置方式方法存在诸多不足；应急响应机制需要组织、技术、过程三个方面的共同作用，来保证系统事件能够及时得到处理。
在组织方面，需要电力公司共同形成一个针对系统应急响应组织。该组织的角色主要包括：领导小组、系统事件的发现者、处理步骤的决定者、技术动作的执行者等。技术方面，需要系统应用响应组织记录系统信息资产，确立系统应急技术方案，定期进行应急演练等。
技术实现要素：
本发明要解决的技术问题是，提供一种营销业务系统运维应急处置及快速恢复方法，主要涉及电力营销业务，适用于因网络故障、服务器性能故障、隔离装置故障等各类原因引起国家电网公司营销基础数据平台系统不能正常使用的突发事件。
采用的技术方案为：
一种营销业务系统运维应急处置及快速恢复方法，包括下述情况处理：
一、数据中心站点灾难：
现象：水、火、地震等带来站点的物理设施瘫痪；这需要具有容灾系统的支持和保护。生产数据库严重不可用(都合并现象，分析，处理方式)；
现象及分析：
现象：业务系统整体停顿。
分析：连接两台数据库主机发现操作系统都不可用，或者通过操作系统查看发现磁盘阵列的设备都不可访问。
处理方式：
需要进一步分析判断故障的严重程度，再决定是否启用经过数据复制生成的查询库，作为生产数据库。
如决定使用查询库，则需要如下关键步骤：
1、停止数据库复制软件在查询库上的进程；
2、停止业务应用程序；
3、将业务应用程序的对原有生产数据库的连接访问配置全部调整到对查询库进行访问；
4、重新启用应用程序；
二、发现数据丢失：
现象及分析：
发现有数据丢失，分为两种情况：
业务人员操作过程中发现数据丢失，这有两可能：1、少量行数的数据丢失2、大量的甚至是整个表的丢失；
主机、数据库或者存储系统出现故障带来的丢失无法哪种情况，都需要人工干预才能完成恢复。
(1)少量数据丢失处理方法：
由应用程序设计、开发人员检查数据不一致的状况，具体丢失情况在本文档中无法尽述，总体而言，要分析严重程度，考察是否能够通过业务操作进行弥补，能够弥补的，则通过业务操作来完成；否则采用“数据库恢复处理方法”；
(2)通过数据库恢复的处理方法：
不论是少量数据或是大量数据，只要无法通过业务操作、业务流程等手段恢复的，都需要通过数据库恢复的处理方法来完成恢复；
数据库恢复的意思是，使用已经建立的备份系统，通过备份软件来完成恢复，主要采用基于时间点的恢复方法，将数据恢复到数据丢失之前的时刻，这个时刻之后的更新数据，需要手工实录或者通过逻辑备份导出的数据进行追加。
三、数据库主机的cpu高：
现象及分析：
宏观现象：应用响应时间长，客户反映系统缓慢；
微观现象：在10.231.xx.xx或10.231.xx.xx上用top–h命令发现；
user的cpuavg利用率较高，如下所示：
cpustates:(avg)
详细表现：可能为多个oracle进程cpu的利用率接近99％或大部分cpu的利用率都较高；
处理方法：
1.通过top-h查看cpu高的进程，得到进程号，即pid；
2.用sql工具语句找到相应的会话，和执行sql；
3.管理员身份登录数据库服务器，执行杀掉此会话(session)；数据库中长时间存在锁(锁等待)；
应急步骤：
1、通过sql工具查看锁的状况；
2、观察哪个session是起头加锁的；
3、记录下会话的当前sql；
4、如果锁等待的时间超过10分钟，同时锁的个数比较少，可以杀掉进程；
5、如果锁的数量比较多，且存在继续增加迹象，也应立即杀锁；
6、将所获取的sql发给技术专家组进行分析；
四、应用系统表现慢：
处理方法：
1.查看数据库上是否有锁，如果有按照对应的技术方法处理；
2.查看数据库主机cpu是否高。如果高，则查找相应sql，并按照对待数据库cpu高的方式来处理会话；
3.查看应用服务器是否异常(cpu高、垃圾回收异常、等待队列>0)，如果是，则按应用服务器cpu高的方法进行处理；
后续处理：
做数据库的stackpack性能分析；
分析线程导出的结果，定位应用中可能存在的问题，并将结果反馈给技术专家组。由技术专家组对这个缺陷进行分析并完善；
五、数据库归档文件占满存储空间：
分两种情况，一种是当前数据库归档文件占满存储空间。这种需要马上处理，直接登录服务器将归档文件转移，然后删除相应的归档文件，如果时间来不及则直接删除归档文件(注意不要删除全部归档，至少要保留时间最近的两个归档文件)；
第二种情况是预计在下一次数据库备份之前，归档文件会占满存储空间，这种情况最好是登录备份服务器手动执行一次备份，如果判断时间来不及则采用第一种情况的处理方法；
需要提前制定出手动执行备份的方法；
六、unix系统某个挂载点的空间使用率超过预警阀值的处理方法：
现象与分析：
由系统监控过程反馈出，unix系统上某个文件系统(挂载点)的空间使用率超过预警值；
可能的原因有：a.人工备份产生的文件、b.应用报错生成大量日志文件、c.操作系统报错生成大量文件；
处理方法：
1、通过du-s*命令在该挂载点下查看每个目录和文件的大小情况；
2、进入空间占用比较大的目录，用同样的方法确定目录和文件的大小；
3、判断原因的属于哪一种。如果是a，则联系相关人员确定可否删除；如果是b或c，则联系系统管理人员或相关厂商进行确认；
4、确认可以删除后，如果时间和条件允许，要先将待删除的文件备份到本地；
5、使用rm命令删除时，要确认使用的命令选项完全正确。使用通配符进行批量删除时，要先用ls命令验证通配符的用法是否正确，以免误操作；
七、关键业务应用策略：
当发生数据库或应用服务器故障，短时间不能恢复时建议采取以下应急措施：
1、概述说明由于系统故障，对应用业务的影响，如何恢复正常；
2、按照压力优先级别，窗口，优质服务等分出应用业务的恢复顺序。
本发明的优势在于：
规范紧急故障的处理流程，实现迅速、有序、高效的故障排查与解决，最大程度缩短故障时间，保证营销基础数据平台系统的安全稳定运行，提高运行维护水平。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例：
一种营销业务系统运维应急处置及快速恢复方法，包括下述情况处理：
一、数据中心站点灾难：
现象：水、火、地震等带来站点的物理设施瘫痪；这需要具有容灾系统的支持和保护。生产数据库严重不可用(都合并现象，分析，处理方式)；
现象及分析：
现象：业务系统整体停顿。
分析：连接两台数据库主机发现操作系统都不可用，或者通过操作系统查看发现磁盘阵列的设备都不可访问。
处理方式：
需要进一步分析判断故障的严重程度，再决定是否启用经过数据复制生成的查询库，作为生产数据库。
如决定使用查询库，则需要如下关键步骤：
1、停止数据库复制软件在查询库上的进程；
2、停止业务应用程序；
3、将业务应用程序的对原有生产数据库的连接访问配置全部调整到对查询库进行访问；
4、重新启用应用程序；
二、发现数据丢失：
现象及分析：
发现有数据丢失，分为两种情况：
业务人员操作过程中发现数据丢失，这有两可能：1、少量行数的数据丢失2、大量的甚至是整个表的丢失；
主机、数据库或者存储系统出现故障带来的丢失无法哪种情况，都需要人工干预才能完成恢复。
(1)少量数据丢失处理方法：
由应用程序设计、开发人员检查数据不一致的状况，具体丢失情况在本文档中无法尽述，总体而言，要分析严重程度，考察是否能够通过业务操作进行弥补，能够弥补的，则通过业务操作来完成；否则采用“数据库恢复处理方法”；
(2)通过数据库恢复的处理方法：
不论是少量数据或是大量数据，只要无法通过业务操作、业务流程等手段恢复的，都需要通过数据库恢复的处理方法来完成恢复；
数据库恢复的意思是，使用已经建立的备份系统，通过备份软件来完成恢复，主要采用基于时间点的恢复方法，将数据恢复到数据丢失之前的时刻，这个时刻之后的更新数据，需要手工实录或者通过逻辑备份导出的数据进行追加。
三、数据库主机的cpu高：
现象及分析：
宏观现象：应用响应时间长，客户反映系统缓慢；
微观现象：在10.231.xx.xx或10.231.xx.xx上用top–h命令发现；
user的cpuavg利用率较高，如下所示：
cpustates:(avg)
详细表现：可能为多个oracle进程cpu的利用率接近99％或大部分cpu的利用率都较高；
处理方法：
1.通过top-h查看cpu高的进程，得到进程号，即pid；
2.用sql工具语句找到相应的会话，和执行sql；
3.管理员身份登录数据库服务器，执行杀掉此会话(session)；
数据库中长时间存在锁(锁等待)；
应急步骤：
1、通过sql工具查看锁的状况；
2、观察哪个session是起头加锁的；
3、记录下会话的当前sql；
4、如果锁等待的时间超过10分钟，同时锁的个数比较少，可以杀掉进程；
5、如果锁的数量比较多，且存在继续增加迹象，也应立即杀锁；
6、将所获取的sql发给技术专家组进行分析；
四、应用系统表现慢：
处理方法：
1.查看数据库上是否有锁，如果有按照对应的技术方法处理；
2.查看数据库主机cpu是否高。如果高，则查找相应sql，并按照对待数据库cpu高的方式来处理会话；
3.查看应用服务器是否异常(cpu高、垃圾回收异常、等待队列>0)，如果是，则按应用服务器cpu高的方法进行处理；
后续处理：
做数据库的stackpack性能分析；
分析线程导出的结果，定位应用中可能存在的问题，并将结果反馈给技术专家组。由技术专家组对这个缺陷进行分析并完善；
五、数据库归档文件占满存储空间：
分两种情况，一种是当前数据库归档文件占满存储空间。这种需要马上处理，直接登录服务器将归档文件转移，然后删除相应的归档文件，如果时间来不及则直接删除归档文件(注意不要删除全部归档，至少要保留时间最近的两个归档文件)；
第二种情况是预计在下一次数据库备份之前，归档文件会占满存储空间，这种情况最好是登录备份服务器手动执行一次备份，如果判断时间来不及则采用第一种情况的处理方法；
需要提前制定出手动执行备份的方法；
六、unix系统某个挂载点的空间使用率超过预警阀值的处理方法：
现象与分析：
由系统监控过程反馈出，unix系统上某个文件系统(挂载点)的空间使用率超过预警值；
可能的原因有：a.人工备份产生的文件、b.应用报错生成大量日志文件、c.操作系统报错生成大量文件；
处理方法：
1、通过du-s*命令在该挂载点下查看每个目录和文件的大小情况；
2、进入空间占用比较大的目录，用同样的方法确定目录和文件的大小；
3、判断原因的属于哪一种。如果是a，则联系相关人员确定可否删除；如果是b或c，则联系系统管理人员或相关厂商进行确认；
4、确认可以删除后，如果时间和条件允许，要先将待删除的文件备份到本地；
5、使用rm命令删除时，要确认使用的命令选项完全正确。使用通配符进行批量删除时，要先用ls命令验证通配符的用法是否正确，以免误操作；
七、关键业务应用策略：
当发生数据库或应用服务器故障，短时间不能恢复时建议采取以下应急措施：
1、概述说明由于系统故障，对应用业务的影响，如何恢复正常；
2、按照压力优先级别，窗口，优质服务等分出应用业务的恢复顺序。
虽然本发明以较佳实施例揭露如上，但并非用以限定本发明实施的范围。任何本领域的普通技术人员，在不脱离本发明的发明范围内，当可作些许的改进，即凡是依照本发明所做的同等改进，应为本发明的范围所涵盖。