Ø         维稳期间客户应急措施建议

建议各用户平时做好应急预案的评估并加以完善,并进行应急演练;一旦出现系统故障,则立即启动应急流程。
1、  应急流程建议
1)第一时间联系恒生维护中心。遇到紧急情况时,立即通过拨打恒生维护热线(TEL0571-28829999)或通过其他应急渠道,与恒生维护中心取得联系。
2)立即成立异常事件处理小组。由于异常事件可能涉及到多个单位或者系统的多个方面,建议在3分钟内成立异常处理小组,由组长总体协调,安排小组成员分头与相关单位保持多方联系,可能涉及恒生、交易所及卫星公司、网络供应商、数据库和硬件供应商等,并且在问题未解决前确保一直在线联系,及时根据相关供应商的指导进行应急处理。
3)及时记录并提供相关信息。在对异常事件进行分析时,需要根据问题现象获取一些必要的信息。通常包括:产品版本、问题现象、报错信息(客户端、中间件、报盘等)、中间件及管理客户端的日志、报盘机的日志、银证平台日志、操作系统日志、数据库的日志、后台业务数据、配置文件及配置参数等。用户需要在日常运维过程中牢牢掌握上述信息的获取方法,并及时有效的提供给恒生或相关供应商。
     系统日志获取方法可参见:
4)有效执行应急措施。根据双方共同制定的应急处理方案,在异常小组组长协调下,有效执行应急措施,并进行及时验证和反馈。
5)处理遗留问题。异常事件过程中可能会产生一些数据错误或遗留问题,在应急处理完成后,需对这些遗留问题进行一一处理,确保问题的彻底解决。
6)总结分析异常事故,找到事故根源。
2、  应急环境建议
1)应急渠道:为确保在异常事件发生时,能够快速的与各方取得联系,需要准备应急联系方式,联系方式应包括各系统供应商及相关机构。恒生应急渠道参考本指引中的‘常用联系电话’。
2)应急工具:在发生异常时,为了能够快速的排查问题,找到应急方案,需要备有一些应急工具。常备工具参考如下:
     远程连接工具(pcanywhereVNCQQ等)、网络检测工具、病毒检查工具、应用系统相关工具。
     目前恒生提供的工具:实时备份切换工具、oiw插入空记录工具、企业版手工初始化工具、性能检查工具等。
3)应急预案:目前恒生提供的应急预案如下:
服务器操作系统异常处理方法:
数据库异常处理方法:
应用程序异常处理方法:
系统性能异常处理方法:
交易接口异常处理方法:
回报异常处理方法:
申报异常处理方法:
组件连接异常处理方法:
初始化异常处理方法:
切换备份服务器步骤:
     针对以上应急环境中的各项内容,用户应及时进行更新,保持有效性;并经常进行演练和验证。

Ø         恒生维稳服务措施

1、    恒生维稳服务内容及相关常用联系电话
服务类型
服务内容
联系方式及介绍
电话服务
业务咨询
及相关售后技术支持等
7×24小时统一服务热线:0571-28829999
远程问题诊断和支持服务
售后技术支持
7×12小时830am2030pm
远程连接工具(pcanywhereVNCQQ等)
现场服务
常规现场服务
重大异常应急服务
 
传真服务
业务需求受理
投诉建议意见等
服务传真:0571-28829016
邮件服务
业务需求受理
技术问题探讨
服务建议意见等
服务邮箱:service@hundsun.com
在线服务
程序资料下载
在线业务咨询
业务信息发布
技术问题探讨
券商交流平台等
投诉受理服务
投诉受理服务
电话:13957180701 0571-288299999
传真:0571-28823456
2、    恒生维稳扩展服务产品
       为帮助用户提高信息系统运维能力和突发事件的应急处理能力,保障信息系统安全,除了已推出的服务项目以外,恒生客服事业部凭借自己多年的服务经验积累推出了恒生维稳扩展服务产品,包括:
*      系统评估服务
*      系统运维现场驻守服务
*      ORACLE技术支持服务
*      定制培训服务
*      安全产品和安全解决方案
*      灾备外包服务
用户如需了解以上服务产品详细信息或者订购相应产品,请咨询当地市场人员。

关于oracle数据库重启后AS未正常重启造成交易异常的案例分析

异常情况:少部分股民的回报未处理进来。经查看报盘机的日志,发现有部分的回报出现执行过程失败的错误,错误信息:Exec SP ERRORPD_rept_return_control
从现象看应该是AS和后台的连接存在问题,立即重启所有AS,并对交易接口库中的成交数据进行了重新回报,原来未处理进来的回报记录能够正常回报入系统。
 原因分析:通过查看数据库日志alter.logAS和报盘机的日志,对问题的原因进行分析,具体情况如下:
1、数据库日志分析
从数据库日志alter中,发现节点2的日志(alter_swdb2.log)中有以下信息:
……
Sat May 10 20:02:23 2008
ALTER SYSTEM SET service_names='' SCOPE=MEMORY SID='swdb2';
Sat May 10 20:02:24 2008
Immediate Kill Session#: 447, Serial#: 5
Immediate Kill Session: sess: c000000619376c08  OS pid: 23926
Immediate Kill Session#: 448, Serial#: 5
Immediate Kill Session: sess: c0000006193780b8  OS pid: 23779
Immediate Kill Session#: 449, Serial#: 237
Immediate Kill Session: sess: c000000619379568  OS pid: 23766
Immediate Kill Session#: 450, Serial#: 15
Immediate Kill Session: sess: c00000061937aa18  OS pid: 23839
Immediate Kill Session#: 451, Serial#: 13
……
该信息表明在2008510(星期六)20:02:24时,数据库的节点2出现了系统自动终止和客户端会话的情形。经确定,该时间点系统曾出现约3分钟左右的网络异常。因oracle在巡检周期内检测到网络存在问题,会自动终止和客户端的会话;因此我们在数据库日志中可看到数据库自动终止和客户端会话的记录。
2、报盘日志分析
本次回报问题的相关报盘机日志信息如下:
20080512 09:15:05.519 回报处理错误!错误信息:Exec SP ERRORPD_rept_return_control
20080512 09:15:05.519 Threadindex:2
20080512 09:15:05.519 回报处理错误!……错误信息:Exec SP ERRORPD_rept_return_control
……
以上信息表明报盘回报过程执行失败(:Exec SP ERRORPD_rept_return_control),从而导致该回报业务的处理失败。
关于该情况分析如下:
报盘AS连接在节点2上,当节点2出现oracle服务器端中止与客户端的会话后,与该节点相连的相关客户端AS没有进行重启,这样这些客户端(AS)并不知道与oracle的连接已无效(只有在实际已断开的连接上进行业务操作时才能知道该连接已不可用),收到请求时仍旧会进行处理,在执行存储过程时由于与数据库连接失效而出现oracle错误,因此导致当前业务处理的失败。
上述错误一旦发生,对当前的业务肯定是失败的,此时AS会把这个连接标记为断开,并在下次业务处理需要数据库连接时会重新和数据库建立连接,保证下次业务能够正常处理。日志中为何会有多个回报失败的业务呢?原因是AS采用的是数据库连接池,连接数量一般大于所需的并发连接数,所以排在后面的有问题(实际已断开)的连接,在有较多并发业务的时候也会被触发异常,所以会出现多条回报异常的现象。
通过以上分析,该问题不应该仅仅在回报上体现出来,在其他连接到节点2AS上处理业务时也会出现类似的问题,进一步查看AS的日志,也证实了这一点,如某个AS的日志:
{[90529] [1508] [CStatementImpl::open()] [
 select a.* from hs_fund.fund a 
 where a.client_id ='11111'
       and a.fund_account =11111 ] [数据库统一访问服务] [语句执行失败] [2]}
{[91347] [3] [CConnectionImpl::setErrMessage] [TRACE:ORA-03113: end-of-file on communication channel
] [common] [调试信息] [0]}
该日志说明客户通过连接到节点2AS查询资金业务也出现oracle返回的错误,说明当时ASoralce的连接出现异常。该错误在一般情况下,股民重新查询一下资金即能正常返回,因此表现不明显。
 解决方案:以上异常说明在出现类似后台数据库连接已断开、但AS并未知道连接已无效的情况下,需要AS的连接池中的所有连接均处理过业务后才能全部正常,否则如果并发业务没有达到连接数,则处理失败的隐患就一直存在。
建议用户加强系统运维监控,一旦发现数据库所在网络有断开情况,在数据库恢复正常后,所有与数据相连的中间件需要重新启动,重新建立连接。

程序速递

Ø         工行存管组件

1、  给银行回复证券应答包时,先按柜台错误号翻成中文,不认识的就取柜台的中文信息,便于银行方识别。
2、  支持白天交易增加的通讯检测包和证券发起查交易结果两项功能。
3、  银行请求证券应答时,发给银行的错误信息要检查一下非<0x20~0x7E>字符的情况,便于银行识别。
4、  对银行返回的错误号1096或错误信息里有超时字样的应答,做丢弃处理,防止银行错误应答时造成单边帐问题。
5、  针对证券发起结息、转入、转出,对于银行应答中的错误码在现有接口中定义的[1001->1058]以外的项,一律丢弃,防止银行错误应答时造成单边帐问题。