24小时实现方法 - 第5页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

要进行日切时,修改一个标志位.
然后将这个时间点上的帐务状况进行复制.复制完成后,复原标志位.
在此时间段内发生的交易信息,记录到另外的临时表(多个)中,该临时表和帐务信息表结构完全相同..
复制表和临时表的内容相加,就是前一日的全部帐务信息.
24小时也不是很复杂,想清楚了就是那么回事.楼主好好考虑一下,我们这个方案已经实施很久了. [/B]
稳定性怎么样啊？
前不久我们也遇到类似的问题
24小时的实现方法，是每个核心业务系统的机密，怎么可能在网上公布呢？我做的核心业务系统，实现了真正意义上的24小时，零秒切换。
最初由 jacsonljs 发布
[B]24小时的实现方法，是每个核心业务系统的机密，怎么可能在网上公布呢？我做的核心业务系统，实现了真正意义上的24小时，零秒切换。 [/B]
爱说不说，临走还要吹一吧。没必要吧？兄弟
现在国内银行实现24小时主要是解决银行日间业务结束后，仍支持象ATM、POS、电话银行等自助业务。binss所提到的方案仅是从帐务角度去考虑24小时方案，在下觉得并不完善。前年我实施一个项目，银行的营业部是24小时办理业务，也就是即使凌晨2点也可以去办理贷款业务，这样的需求着实让我头疼。因此，我认为24小时方案应该支持包括ATM等自助、柜面业务、后台业务等银行所有对外业务。这样做就不是仅仅几个临时表能搞定的，而是一套应用程序，两套数据。日切前两套数据同步，日切后一套运行24小时业务，另一套做批量。日初后两套数据又归于同步。
最初由 jacsonljs 发布
[B]24小时的实现方法，是每个核心业务系统的机密，怎么可能在网上公布呢？我做的核心业务系统，实现了真正意义上的24小时，零秒切换。 [/B]
零秒切换？值得怀疑！
每天银行系统必做的事情就是备份，DBMS执行备份指令时，首先要做一些检查，比如是否“reach a checkpoint ”或者“in a consistent state in relationship to each other”等，各DBMS的处理有不同，但备份前必须做一些检查工作。这个步骤所花的时间视不同的DBMS不同的数据量从几秒到几分钟不等。此间DBMS是不允许应用对数据库做任何操作。等DBMS做这些检查后，才执行真正的数据备份。
所以acsonljs 声称的零秒切换，估计也是单纯从应用设计上考虑，而没有考虑到系统的限制！
零秒切换？值得怀疑！
每天银行系统必做的事情就是备份，DBMS执行备份指令时，首先要做一些检查，比如是否“reach a checkpoint ”或者“in a consistent state in relationship to each other”等，各DBMS的处理有不同，但备份前必须做一些检查工作。这个步骤所花的时间视不同的DBMS不同的数据量从几秒到几分钟不等。此间DBMS是不允许应用对数据库做任何操作。等DBMS做这些检查后，才执行真正的数据备份。
所以acsonljs 声称的零秒切换，估计也是单纯从应用设计上考虑，而没有考虑到系统的限制！ [/B]
零秒切换！完全可行！
我不认识前面那位已经实现7*24零秒切换的朋友，不过，我们银行也实现了7*24，也是零秒切换，效果很好，方案不复杂。不过方案不便这里公开。
楼上这位怀疑DBMS的能力，其实在线备份是DBMS的基本功能，你完全不必怀疑的。所谓状态检查是DBMS内部的事情，对应用是透明的，它停顿的时间不至于感觉到应用停止，否则没有资格用在银行OLTP中，所以也不会影响到7*24的实施。
零秒切换！完全可行！
我不认识前面那位已经实现7*24零秒切换的朋友，不过，我们银行也实现了7*24，也是零秒切换，效果很好，方案不复杂。不过方案不便这里公开。
楼上这位怀疑DBMS的能力，其实在线备份是DBMS的基本功能，你完全不必怀疑的。所谓状态检查是DBMS内部的事情，对应用是透明的，它停顿的时间不至于感觉到应用停止，否则没有资格用在银行OLTP中，所以也不会影响到7*24的实施。 [/B]
你也知道DBMS在线备份时做的状态检查需要停顿的，那么为什么说“它停顿的时间不至于感觉到应用停止”呢？你测试过这个停顿时间有多长吗？我02年时测试过，DMBS是AS/400的DB2，数据量大概是30万帐户，在线备份检查状态停顿时间大概10秒，此间应用是无法使用数据库。10秒可能就是你所说“不至于感觉到”，但是如果帐户数是300万，3000万呢？停顿时间可能是几分钟到十几分钟，你还能说“不至于感到到”吗？客户几分钟取不到钱就会很感觉到了。其他的DBMS在线备份也会有停顿时间，如果停顿1分钟以上，还能说所谓的“零秒切换”吗？
你也知道DBMS在线备份时做的状态检查需要停顿的，那么为什么说“它停顿的时间不至于感觉到应用停止”呢？你测试过这个停顿时间有多长吗？我02年时测试过，DMBS是AS/400的DB2，数据量大概是30万帐户，在线备份检查状态停顿时间大概10秒，此间应用是无法使用数据库。10秒可能就是你所说“不至于感觉到”，但是如果帐户数是300万，3000万呢？停顿时间可能是几分钟到十几分钟，你还能说“不至于感到到”吗？客户几分钟取不到钱就会很感觉到了。其他的DBMS在线备份也会有停顿时间，如果停顿1分钟以上，还能说所谓的“零秒切换”吗？ [/B]
你没有理解我的意思，状态检查需要停顿，此间不能做交易，但是如果这个时间太长，长到应用能感觉到停顿，那么这个系统是需要调优的，哪怕不实行7*24的方案，也需要调优，否则没有资格用在银行的OLTP中。哪一个OLTP系统允许应用可以有几分十几分的停顿呢？10秒也是不可以接受的。