专利名称：一种电信客户服务系统数据库故障处理方法
技术领域：
本发明属于通信运营商的客户服务领域。本数据库故障处理方案针对现有的客 户服务系统特点，采用创新的故障处理，有效提高了客户服务系统的可用性，提升了 企业服务质量。该发明创造可直接应用于各通信运营商对其用户提供客户服务领域。
二背景技术：
随着社会的发展，呼叫中心成为一个热门行业，呼叫中心的规模也逐步壮大，后 台的支撑系统也随之复杂，系统出现故障的风险也逐步增大。客服系统由大量的部件 组装而成，包括数据库、与其他系统接口、网络等，都有可能引起系统的过程，影响 客户服务质量。为了能未雨绸缪，防患于未燃，需要预先考虑以下几个点
1) 预先评估系统架构中可能存在的故障点；2) 针对故障点采取预先的解决方案和预防措施；3) 整理、归纳处理方案，理清思路，指导日后的工作； 以保证客服系统稳定、可靠、持续的运行。
客服系统架构中对于数据层数据库服务器，已通过双机集群方式实现硬件与操作 系统级故障时的互为热备份，但技术上无法实现数据库软件级故障时的互为热备份， 单个数据库实例故障直接影响业务，而数据库实例故障发生较频繁、故障原因复杂、 恢复时间较长(约需15分钟以上)、对客服业务影响极大(所有1860/12580座席无 法查询用户资料或办理业务)。本发明就是在这方面做出了有益的尝试并取得了成功， 在实际应用中取得了良好的效果。本发明2007年6月份启动研究，经充分技术调研，长达6个月的研发，反复细 化需求，并于2008年1月应用于最新版的客户服务系统，经实际试用，反映良好， 在此基础上我们对功能进行了进一步完善，已于2008年3月全面使用。三
发明内容
针对上述问题，本发明提出了客服系统数据库故障处理的技术方案。
本发明的技术方案如下-一种电信客户服务系统数据库故障处理方法，它包括以下步骤上层应用数据访问步骤，自动语音交互服务器IVR及人工座席软件访问主用客服 数据库，获取呼叫处理逻辑配置数据；监听步骤，监听器定期采集有关数据库的状态数据，并反馈给检测分析主体，作 为分析、判断以及策略执行的依据；检测分析步骤，策略控制服务器上的检测分析主体分析数据库状态数据，根据自 己的知识库判断数据库是否异常；如判断结果为异常，则进入故障处理流程；策略控制服务步骤，策略控制服务器定期向本地应急关键数据库发送指令以同步 主数据库的关键数据，以备故障中使用。上述电信客户服务系统数据库故障处理方法，其特征在于所述故障处理流程按如下过程进行监听器检测到主体的故障数据，故障处理策略控制主体判断数据库是否异常，如 数据库确认异常，则发出进入故障处理流程控制指令；故障处理策略控制主体收到数据访问指令SQL,进行必要的判断记录需要重做的 指令，待故障恢复后自动重做；故障处理策略控制主体将上层应用对关键数据的访问重定向到本地数据库，保证 核心业务的运行；故障处理策略控制主体在获得监听器反馈的数据，判断故障恢复后，将控制系统 恢复常态操作。上述电信客户服务系统数据库故障处理方法，其进一步特征在于 故障恢复时，根据数据库故障情况可以使用两种不同方式根据执行时间，在对应的数据库备份上依次运行所记录的数据访问指令SQL,以 便恢复到最新的数据库状态；或者，根据指令执行结果标记过滤，重新执行操作失败的数据访问指令SQL，以 便恢复到最新的数据库状态。对应的，本发明还提出了一种电信客户服务系统数据库故障处理装置，它包括上层应用数据访问单元，自动语音交互服务器IVR及人工座席软件访问主用客服 数据库，获取呼叫处理逻辑配置数据；监听器，监听器定期采集有关数据库的状态数据，并反馈给检测分析主体，作为 分析、判断以及策略执行的依据；检测分析主体，策略控制服务器上的检测分析主体分析数据库状态数据，根据自己的知识库判断数据库是否异常；如判断结果为异常，则进入故障处理策略控制主体;
策略控制服务器，策略控制服务器定期向本地应急关键数据库发送指令以同步主 数据库的关键数据，以备故障中使用。
上述电信客户服务系统数据库故障处理装置，其进一步特征在于，所述本地应急 关键数据库将系统完成最小给你所必需的信息记录在本地，保证在数据库故障后， 这些信息仍然能被访问到；这些信息包括配置信息、公共数据和用户信息等。
上述的电信客户服务系统数据库故障处理装置，其更进一步特征在于，所述故障 处理策略控制主体部署于单独的策略控制服务器，负责定期査询检测分析主体，获 取是否处于故障状态；负责控制客服系统数据库故障处理子系统内部处理流程，并与 故障恢复后建立重做线程根据日志进行恢复和重做；
所述故障处理策略控制主体记录数据访问指令SQL,存放在制定的数据库中， 并记录指令执行成功与否作为故障修复时是否重做的依据；故障恢复时，根据数据库 故障情况可以使用两种不同方式根据执行时间，在对应的数据库备份上依次运行所 记录的数据访问指令SQL，以便恢复到最新的数据库状态；或者，根据指令执行结 果标记过滤，重新执行操作失败的数据访问指令SQL，以便恢复到最新的数据库状 态。
本发明的实施可以保证客服系统稳定、可靠、持续的运行。根据本发明所述的方 案，可以完善客服系统。当客服系统故障时，客服系统数据库故障处理子系统可以 完成1)探测数据库系统健康状态，通知应用；
2) 记录故障状态下应用请求，并在探测到数据库系统恢复后进行重做；
3) 建立关键数据的本地记录，保证一些重要应用在数据库故障状态下任能完 成服务响应。
四
图1为本发明实施例中数据库故障处理子系统逻辑图。
图2为本发明实施例中数据库故障处理子系统系统架构图。
五具体实施例方式
下面结合附图和实施例对本发明进一步描述。 本发明创造可以由以下模式构筑1) 设计应急系统的软件架构，由以下模块组成
1.1) 检测分析主体(DAS-Detecting and Analysis System):部署于数据层的主备 用数据库服务器，负责定期(每2分钟)采集本机有关数据库状态的数据并加 以分析，根据自己的知识库判断数据库状态是否异常，如判断结果为异常， 则介入故障处理流程；
1.2) 故障处理策略控制主体部署于单独的策略控制服务器，负责定期査询检 测分析主体，获取是否处于故障状态；负责控制客服系统数据库故障处理 子系统内部处理流程，并与故障恢复后建立重做线程根据日志进行恢复和 重做；
1.3) 监听器完成监控系统域内数据库资源状态；负责定期被检测数据库发送 握手消息，收集主备用数据库状态并反馈给DAS;
1.4) 本地应急关键数据库将系统完成最小给你所必需的信息记录在本地，保 证在数据库故障后，这些信息仍然能被访问到；这些信息包括配置信息、 公共数据和用户信息等；
2) 设计应急系统的硬件架构，由以下模块组成
2.1) 策略控制服务器安装有故障处理策略控制主体，负责定期查询检测分析 主体，获取是否处于故障状态；负责控制客服系统数据库故障处理子系统 内部处理流程，并与故障恢复后建立重做线程根据日志进行恢复和重做；
2.2) 本地数据库服务器用于存储、管理系统完成最小给你所必需的信息，并 在非故障状态定期完成与主系统的数据同步。
本发明实施中系统参数和处理流程如下 1)数据库状态的收集 1. 1) telnet指定端口；
1.2) 通过定制软件检査服务的状态；
1.3) 尝试连接；
1.4) 尝试执行一个査询；
1. 5)査询数据库状态(SYSDATABASES (SQL 2000), SYS. DATABASES (SQL 2005));
1.6) 尝试访问指定库；
1.7) 尝试在指定库下执行査询；
1.8) 在指定库上用DBCC CHECKDB;2) 根据图1所示数据库故障处理流程，在主用数据库正常运行阶段，可按如下协议 过程进行
2.1) 上层应用(即包括自动语音交互服务器(IVR)及人工座席软件访问主用客服 数据库(如获取呼叫处理逻辑配置数据)；
2.2) 监听器定期采集有关数据库的状态数据，并反馈给检测分析主体，作为分 析、判断以及策略执行的依据；
2.3) 策略控制服务器上的检测分析主体分析数据库状态数据，根据自己的知识 库判断数据库是否异常；如判断结果为异常，则进入故障处理流程；
2. 4)策略控制服务器定期向本地数据库发送指令以同步主数据库的关键数据， 以备故障中使用；
3) 数据库故障，故障处理可按如下过程进行
3.1) 监听器检测到主体的故障数据，故障处理策略控制主体判断数据库是否异 常，如数据库确认异常，则发出进入故障处理流程控制指令；
3.2) 故障处理策略控制主体收到数据访问指令(SQL),进行必要的判断记录需 要重做的指令，待故障恢复后自动重做；
3.3) 故障处理策略控制主体将上层应用对关键数据的访问重定向到本地数据 库，保证核心业务的运行；
3.4) 故障处理策略控制主体在获得监听器反馈的数据，判断故障恢复后，将控 制系统恢复常态操作；
4) 日志的记录与重做
4.1) 故障处理策略控制主体记录数据访问指令(SQL)，存放在制定的数据库(独 立于业务数据库)中，并记录指令执行成功与否作为故障修复时是否重做 的依据；
4.2) 日志内容包括提交时间、执行时间、提交用户、目标实例、目标数据库、 SQL内容、运行时间、结果标记以及其他辅助信息；
4.3) 故障恢复时，根据数据库故障情况可以使用两种不同方式
4.3.1) 根据执行时间，在对应的数据库备份上依次运行所记录的数据访问指令
(SQL)，以便恢复到最新的数据库状态；
4.3.2) 根据指令执行结果标记过滤，重新执行操作失败的数据访问指令
(SQL)，以便恢复到最新的数据库状态。图2是本发明实施例中数据库故障处理子系统系统架构图。
虽然本发明通过实施例进行了描述，但实施例并非用来限定本发明。本领域技术 人员可在本发明的精神的范围内，做出各种变形和改进，因此本发明的保护范围应当 以本申请的权利要求保护范围所界定的为准。
权利要求
1、一种电信客户服务系统数据库故障处理方法，它包括以下步骤上层应用数据访问步骤，自动语音交互服务器IVR及人工座席软件访问主用客服数据库，获取呼叫处理逻辑配置数据；监听步骤，监听器定期采集有关数据库的状态数据，并反馈给检测分析主体，作为分析、判断以及策略执行的依据；检测分析步骤，策略控制服务器上的检测分析主体分析数据库状态数据，根据自己的知识库判断数据库是否异常；如判断结果为异常，则进入故障处理流程；策略控制服务步骤，策略控制服务器定期向本地应急关键数据库发送指令以同步主数据库的关键数据，以备故障中使用。
2、 根据权利要求1所述的电信客户服务系统数据库故障处理方法，其特征在于 所述故障处理流程按如下过程进行监听器检测到主体的故障数据，故障处理策略控制主体判断数据库是否异常，如 数据库确认异常，则发出进入故障处理流程控制指令；故障处理策略控制主体收到数据访问指令SQL，进行必要的判断记录需要重做的 指令，待故障恢复后自动重做；故障处理策略控制主体将上层应用对关键数据的访问重定向到本地数据库，保证 核心业务的运行；故障处理策略控制主体在获得监听器反馈的数据，判断故障恢复后，将控制系统 恢复常态操作。
3、 根据权利要求2所述的电信客户服务系统数据库故障处理方法，其特征在于: 故障恢复时，根据数据库故障情况可以使用两种不同方式 根据执行时间，在对应的数据库备份上依次运行所记录的数据访问指令SQL，以便恢复到最新的数据库状态；或者，根据指令执行结果标记过滤，重新执行操作失败的数据访问指令SQL，以 便恢复到最新的数据库状态。
4、 一种电信客户服务系统数据库故障处理装置，其特征在于，它包括 上层应用数据访问单元，自动语音交互服务器IVR及人工座席软件访问主用客服数据库，获取呼叫处理逻辑配置数据；监听器，监听器定期采集有关数据库的状态数据，并反馈给检测分析主体，作为 分析、判断以及策略执行的依据；检测分析主体，策略控制服务器上的检测分析主体分析数据库状态数据，根据自 己的知识库判断数据库是否异常；如判断结果为异常，则进入故障处理策略控制主体;策略控制服务器，策略控制服务器定期向本地应急关键数据库发送指令以同步主 数据库的关键数据，以备故障中使用。
5、 根据权利要求4所述的电信客户服务系统数据库故障处理装置，其特征在于， 所述本地应急关键数据库将系统完成最小给你所必需的信息记录在本地，保证在数 据库故障后，这些信息仍然能被访问到；这些信息包括配置信息、公共数据和用户信 息等。
6、 根据权利要求4所述的电信客户服务系统数据库故障处理装置，其特征在于， 所述故障处理策略控制主体部署于单独的策略控制服务器，负责定期査询检测分析 主体，获取是否处于故障状态；负责控制客服系统数据库故障处理子系统内部处理流 程，并与故障恢复后建立重做线程根据日志进行恢复和重做。
7、 根据权利要求6所述的电信客户服务系统数据库故障处理装置，其特征在于， 所述故障处理策略控制主体记录数据访问指令SQL，存放在制定的数据库中，并记 录指令执行成功与否作为故障修复时是否重做的依据；故障恢复时，根据数据库故障 情况可以使用两种不同方式根据执行时间，在对应的数据库备份上依次运行所记录 的数据访问指令SQL，以便恢复到最新的数据库状态；或者，根据指令执行结果标 记过滤，重新执行操作失败的数据访问指令SQL，以便恢复到最新的数据库状态。
全文摘要
本发明提出了一种电信客户服务系统数据库故障处理方法，它包括以下步骤上层应用数据访问步骤，自动语音交互服务器IVR及人工座席软件访问主用客服数据库，获取呼叫处理逻辑配置数据；监听步骤，监听器定期采集有关数据库的状态数据，并反馈给检测分析主体，作为分析、判断以及策略执行的依据；检测分析步骤，策略控制服务器上的检测分析主体分析数据库状态数据，根据自己的知识库判断数据库是否异常；如判断结果为异常，则进入故障处理流程；策略控制服务步骤，策略控制服务器定期向本地应急关键数据库发送指令以同步主数据库的关键数据，以备故障中使用。
文档编号H04M3/50GK101321207SQ200810022179
公开日2008年12月10日 申请日期2008年7月22日 优先权日2008年7月22日
发明者泓 乙, 伟 彭, 俊 李, 江心勇, 王丛刚, 王宏图, 欣 陈, 瑛 陈 申请人:中国移动通信集团江苏有限公司