最近发现论坛上关于数据库远程复制和异地容灾等问题的帖子比较多，现在把我知道的一些解决方案进行一下分析，能力有限，还希望大家多多补充、纠正！
目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案：
（1）基于存储层的容灾复制方案
这 种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大 数据量的系统来说有很大的优势（每天日志量在60G以上）,但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。
目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。
（2）基于逻辑卷的容灾复制方案
这 种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择 同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为 这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。
我一直有一个困惑，存储级的 复制，假如是同步的，能保证 数据库所有文件一致吗 ？或者说是保证在 异常发生的那一刻有足够的缓冲来保障？
也就是说，复制的时候起文件写入顺序和oracle的顺序一致吗？如果不一致就可能有问题，那么是通过什么机制来实现的呢？
上次一个存储厂商来讲产品，我问技术工程师这个问题，没有能给出答案
我对存储级的复制没有深入的研究过，主要是我自己的一些理解，你们帮我看一下吧……
我 觉得基于存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果，所以在任意时刻，如果原系统的文 件是一致的，那么目标端也应该是一致的，如果原系统没有一致，那目标端也会一样的。形象一点说它的原理可能有点像raid 0，就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外，在发生故障的那一刻，如果是类似断电的情况，那么肯定会有缓存中数据的损失， 也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份，在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启 动的（这是我接触过的很多这方面的技术人员的一种说法，我没有实际测试过）。我在一个移动运营商那里看到过实际的情况，他们的数据库没有归档，虽然使用了 存储级的备份，但是白天却是不做同步的，只有在晚上再将存储同步，到第二天早上，再把存储的同步断掉，然后由另外一台主机来启动目标端存储上的数据库，而 且基本上是有1/3的机会目标端数据库是起不来的，需要重新同步。
所以我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据库和应用进行容灾，存储级的方案是没有什么优势的，尤其是它对网络的环境要求是非常高的，在异地环境中几乎不可能实现。
不知道我的理解对不对，也不知道是不是回答了你的问题，呵呵。欢迎指正！
应该说部分地回答了我的问题，呵呵
因为 实际上存储设备的写入顺序 和 oracle 的进程的写入顺序肯定是不一样的，存储设备一定是做过重整的，那 不管同步或者异步的拷贝都 有可能 存在问题的。
所以我一直对这个方案的可靠性不敢完全相信，这样一来，倒不如 data guard 可靠了
因为很明显，存储设备拷贝过去的数据文件 不一致是有很大的概率的
你 的意思是说即使不考虑目标端，仅在源端的情况下，存储设备的写入顺序也是和Oracle不一致的？这应该是一个原因。我觉得还有一种可能性就是在忽略存储 设备的这种情况下，在主系统当机，发生切换的时候，主系统存储上的数据文件也不一定能保证一致，就算目标系统保持了完全的同步，也一样不能保正目标端数据 可可以启动。
不太理解，为什么说存储设备的写入顺序会和oracle进程的写入顺序不一致阿
如果说仅在源端情况下，存储设备的写入顺序也是和Oracle进程不一致，那么不考虑异地冗灾，那么是不是意味着即使本地服务器crash，也无法启动存储上的数据文件？
我也有这个疑问，以前一直觉得仅考虑主系统的情况下，存储设备的写入顺序应该是和数据库的写入顺序一致的， 但我觉得biti_rainy的理解也是有道理的，存储设备毕竟和一般的磁盘不一样，很可能再写入的时候会作重新的组合，不过不知道具体的证据是什么啊？
按 照这种理解，再写入的某一瞬间，数据库的写入顺序和存储的写入顺序可能是不一致的，但既然存储写入的结果跟oracle的写入结果肯定是一致的，那么我们 可以把一个比较长的写入过程分成若干个时间段，在每个时间段的结尾，oracle和存储设备的写入结果都是完全一致的，那么这个时间段的大小是多少呢？
呵呵，说得我自己都快晕了，也不知道大家明白我的意思没有……
o
biti_rainy能不能给我们解释一下啊？或者论坛里有没有对存储设备比较了解的兄弟啊？
系统上通常不一致没关系是因为还有 logfile 的存在，而日志文件通常是被写入了磁盘的，oracle本身是顺序写的，还不需要读，应该是被重整的几率比较小
还有存储设备上，比如掉电没关系，是因为存储设备都有足够的短时间供电能力使得 cache 中的数据能被写入磁盘，这个如果不能保证那一掉电基本都要出问题的
但是在复制的那端，我就不清楚是怎么处理的，比如我要停掉复制，开始用起这数据来，或者说设备掉电了，这个时候是怎么处理的
在复制的那端，我感觉是没有经过特殊处理的，因为存储设备完全是物理上的同步，在你停掉 复制的时候，他最多只能保证在停止复制或原系统掉电的这一刻所有文件在物理上是和原系统的存储是完全一致的，但他绝对不会去校验或保证oracle的数据 文件在逻辑上是否一致，所以会造成复制端在停止复制后有很大几率不能正常启动。我在客户那的情况就是在原系统正常运行的情况下，停止存储的复制，然后启动 目标端数据库，但还是有1/3的几率无法启动，如果是在原系统发生故障或断电的情况下，估计就更不好说了。
我还是比较佩服那个客户的勇气，一个省级移动运营商的数据中心，数据库连归档都没有，一旦系统崩溃，至少要损失当天的数据，同时容灾端的数据库能不能起来还是个问题……
还好目前还没有出问题，要是出了问题，不知道他们会怎么办……
上次做存储设备的来公司，谈到这个问题的时候说： 很多客户就是这么做的
我就说： 很多人这么做的并不能说就没问题，因为很多 人没有出现事故，是因为隐藏的问题没有机会暴露出来。我需要：
1：机制上的可靠保障，这个可能只有非常理解 原理的人能回答
2：实际系统的测试，要经过在我们自己提供的数据场景下反复测试
通过这两点之后我们才敢放心使用
同意，确实很多人都是这么用的，也确实都很可能出现问题，所以我一直以为基于存储的数据 库容灾方案是有问题的，但在有些环境中好像还只能这么做，例如我们的一个客户，也是一个省级的移动运营商，其数据库每天的日志量达到100G以上，在这种 条件下，好像只有这种解决方案比较可行，其他的都会有一些问题，至少那些使用软件实现的逻辑复制方案是不行的，我感觉oracle自己的standby好 像也负担不了吧？不过他们的数据库至少还是归档的，还有一点保证。呵呵。
从ORACLE的角度来衡量基于存储的容灾肯定是有问题的，不可能做到100%可用。
即使是ORACLE的DATA GUARD也不能保证100%没有数据丢失（当前日志组的数据）。
换个思路了，使用基于应用的同步方案吧。
（3）基于oracle redo log的逻辑复制方式
使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。先介绍一下第三方的软件产品吧……
目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品， 但在产品的成熟程度和成功案例上跟国外还有一定的差距。
这类产品的原理基本相同，其工作过程可以分为以下几个流程：
使 用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档 日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的 复制（主要在oracle9i环境中）。
这种技术的技术特点和优势主要有以下几点：
目标端数据库一直是一个可以访问的数据库；
能保证两端数据库的事务一致性；
因为使用oracle以外的进程进行捕捉，且其优先级低于oracle进程，所以对源系统数据库的性能影响很小；
基于其实现原理及多个队列文件的使用，复制环境可以提供网络失败、数据库失败、主机失败的容错能力；
因为这类软件复制的只是sql语句或事务，所以他可以完全支持异构环境的复制，硬件的型号，oracle的版本，操作系统的种类、版本等都没有要求。
这种方式还可以支持多种复制方式，比如数据集中、分发、对等复制、或者多层测的复制等。
由于传输的内容只是redolog 或archive log中的一部分，所以对网络资源的占用很小，可以实现不同城市之间的远程复制。
基于redolog的逻辑复制产品有很多的优势，但跟上面提到过的其他方案比较起来，也有一些缺点：
数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；
实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；
复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。
不过目前这类产品的发展很快，上面的这些问题，在大部分产品的最新版本中都有很大的改进。
您说的备中心1/3机会不可用，是同步复制还是异步复制的情况？
是指同步复制的情况。
这个数字我不敢保证它的准确性，因为我没有做过实际的实验来验证，但从我在客户那里看到的实际情况来说，基本属实。
您能告诉我你的客户用的那一家的产品吗？
不 管是同步环是异步只要不是在数据库里面做宕机时总应该有数据不一致的情况吧 因为数据库写文件是由操作系统来最终完成的，而操作系统本身又有cache，在通过逻辑复制把数据异步或同步复制到其他存储设备上，中间无论哪个环节有问 题，远程存储设备的数据都不能同现有数据保持一致，所以我认为 biti的怀疑是很有道理的。到10g oracle可以使用assm，直接同存储设备对话，这样是否能够好一些，不太确定
存储是通过快照来记录状态，然后再进行复制进行备份的。
其实最好的方法应该是捕捉redo log file 的信息，将其翻译成sql语句
这就是oracle stream 和quest shareplex实现的功能
利用oracle 9i的高级复制，加上第三方的管理工具就可以了
我对oracle 的高级复制研究较多，觉得这是最好的方法，能够完全保证数据的一致性。
但管理起来比较麻烦，需要利用第三方的管理工具就可以了。我用的是 深圳华尔东城公司的管理工具，能够自动进行简单故障处理，目前设置的10分钟增量同步，最大表有4000多万条记录，目前还只同步了一部分表，数据量达到了50G。
容灾实际例子，不知道是不是有帮助
曾 经评估了几个这方面的方案，一是利用存储本身提供的功能，在两端距离比较远（几百几千公里）的时候，只能用异步的方式，同步的话对网络的带宽要求很高，除 非两端能够用光纤直接连接。异步的方式根据厂商的解释是这样的，远端存储上的写是无序的，不会根据生产端的次序写入，对用户来说是透明的，没有办法干预， 也就是说对oracle来说是不同步的，如果没有人为的干预进行一次同步的话，数据库也没有办法启动。但是如果要同步的话就会对生产数据库产生影响，处于 suspend状态。至于停电等各种极端情况我们在同城同步做过测试，没有问题，存储能够保证数据的一致和可用。异地异步没有测试过，不知有哪位兄弟做过 这个试验，能告诉结果。
看了大家的帖子，我也想说点东西，一直以来做的就是容灾和备份的事情。
目前的所谓的容灾可能包含两种方式：
1.真正的容灾，目的就是为了防止在灾难发生的时候能减少下线时间。这个过程没有一个能做到零下线的。
2.”假“容灾，即所谓的ods，数据复制。出来的数据不单单能达到容灾的目的，而且目的端数据可以实时被使用。
第一种方式可能是鸡肋，因为花那么大的投资使用当前的硬件容灾方式去达到一个可能领导在任期间都不能发生的灾难，实在让人觉得不太值得，除非厂商给了这个领导很大一笔钱，不过当前许多电信行业都说要建容灾中心。
第二种方式确实是一种很诱人的方式，也是我现在做的产品。这种方式主要采用两种方式实现：
a.使用我们现在的同步工作实现首次同步（逻辑上的导出，也是一种鬼才写出了这个东西，当然他是我们老总），然后直接转入监控online redolog进行日志监控分析转化，然后传送到目标端装载。
b.使用类似于bcv/ca/flashcopy这些快照类软件在磁盘存储级做成首次同步，然后使用我现在的产品做日志监控，加载到目的端。
这个产品作了1年多，应该说比quest的shareplex强大的多了，但是我并非在此宣传产品，所以我要说的是公平话。
通 过oracle内部方式去达到实时同步可能本身就是一个错误，类似于oracle本身的advance replication以及data guard也是日志分析方式的，他的主要缺点在于效率上存在问题，就是装载数据量很大的时候，根本不能应付，这也是shareplex的毛病。因此我现在 的产品在这个上面是克服了这些缺点，效率绝对的高。我和oracle的stream，quest的shareplex，以及非用于容灾方式的data guard等对比过，大家互有长短。
关键就是，采用基于这种精确分析的复制方式，如何保证数据是完全准确的：
1.没有有效的检验方式，检查数据是否一致，有类似于select minus select的方式，但是对于超过100M的表，除非你有足够的耐心，我经常见到表最大是92G，没有分区，很变态。
2.就算你知道了丢失数据，如何把这个数据补回来。现在的类似于我们的软件，都采用了rowidmap的方式去做精确定位，所以如果丢失了，你如何补回来。我知道quest 是重新同步，我们是把整个表重新同步，因为我们的逻辑到处快。
这些都是基于oracle精确复制需要解决的最大的问题。
呵呵，当然了关于这个里面处理很多oracle的特殊操作的时候还有很多需要做的事情，quest做了8年多了吧，到5年后才支持chained row，不能不说这是一个悲剧。还有许多的操作类型怎么办：ddl
,truncate,rollback savepoint,nologging等等，当然日志了没有的时候，你如何做。
我个人的观点，基于oracle的精确分析复制方式，除了oracle以后能做好，其他人不要轻易尝试。
不知道能否把产品名字透露一下啊？
如果没有猜错应该是DSG的了？
DGS和shareplex的比较让市场来说话吧。
每个人都会说自己的产品好，但是希望在itpub这个地方
还是要说出一些更多技术上的东西。
samchj说“此我现在的产品在这个上面是克服了这些缺点，效率绝对的高”，并且也提到你们的产品也是通过监控redo的变化，提取SQL，那么为什么你们的效率会绝对的高？
希望能从机制上说明一下这个问题。
首先我澄清一下，我没有宣传产品的意思。
我必须让事实说话，而不是市场说话，市场存在很多人为因素。
在 效率上，对于处理chained row这种在数据库中经常出现的东西，不能采用sql statment执行的方法。而shareplex是使用的这种方法。曾经我在测试的时候就对比过这个东西。因为chained row 包括migrate row &chain row 两种。而mr在oracle中只有一个rowid，而cr却不止。因此如果你采用的是rowmap方式精确定位两边的表，那么在处理chain row的时候，除非你能很好的处理，否则最简单和准确的方式就是直接在源端找到这个行，然后通过sql statment的方式装到目的端。这样在速度上是很慢的。
效率的提高主要从分析速度和装载速度上讲的。
我不知道shareplex日志分析是如何进行的，这当然也是这类型软件的kernel了，这是算法问题，我想起基本原理和logminer都差不多，在算法上优化分析速度是很重要的。
在 装载问题上，其实shareplex也曾经使用过direct path的装载方式，但是因为direct path本身就存在很多bug，因此干脆就放弃了这种方式，因为据我所接触的通过direct path装载的bug就很多，例如索引不能使用等。所以只能通过conventional path来装载。这就是规规矩矩的转换成sql statment，然后交给oracle通过解释成binary 后在装载
了，这是很浪费时间的，而且对于qmi（基本由creat table as select引起的oracle特殊插入处理）来说，这是很不合理的，因此在这里应该做些事情，当然细节不便于说。
另外对于首次同步的导出和装载，现在的oracle10g也许就是使用的这种方式了，你可以看看oracle10g的export为什么如此快。
我还是说，不论是否市场怎么样，使用基于oracle精确分析装载的软件要慎重使用，因为他的问题是很多的。
楼上的你们产品是什么啊
关于这类产品的一些特别情况的处理我一直很关心
另： 10G 使用的 *expdp* 和 *impdp* 应该是由 DUL + SQLLDR direct 思想的结合吧
我们现在用的是Oracle 9i ，想用复制软件VERITAS Storage Replicator 3.0使两台服务器上的数据库同步，应该复制Oracle下的那些数据文件，表空间？还有复制后应该怎么做？
服务器硬件说明：
两台服务器为了节约成本，没有使用双机热备，没用磁盘阵列，每台服务器用4块SCSI硬盘做成Raid 5，两台服务器操作系统，数据库安装路径，设置都一致，有没有解决办法啊?
使用SQL Server 2000数据库把数据文件复制到另外一台服务器，数据库可以实现同步，但是Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。
对于samchj 一直说：然后通过sql statment的方式装到目的端。这样在速度上是很慢的，然后交给oracle通过解释成binary 后在装载了，这是很浪费时间的 ？
－－－－－－－－－－－－－－－－－－－－－－－－
能否举出实际的例子？拿出具体的数据来说话， 你所谓的慢是什么程度？
澄清一下，shareplex 不是使用你所谓的direct path 方式。
dx6340老兄，我不是在宣传产品，我再澄清一次。如果有人对我现在做的产品感兴趣，可以给我写邮件，但是我们只谈技术，不谈市场，但是在itpub上或者任何其它场合，我不会说我的产品是如何的好，虽然我的和shareplex做的对比测试很多。他们各有各的优缺点。
shareplex 确实不使用direct path装载，这个我也说过“其实shareplex也曾经使用过direct path的装载方式”，我是说曾经，从研发上讲。你可以用shareplex或者oracle的data guard等做实验，当大数据量的时候，你可以看看他是否能分析过来和装载过来，延迟时间多少。一秒钟能支持的update有多少，insert有多少， 如果做ddl是否需要先停止复制。这些还只是很基本的处理。logminer尚且对日志的分析很慢（不过可以用多进程来弥补，如果你有很多的系统资源）。
wbo 兄弟的“Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。”，我的理解是，如果你使用基于存储级的复制产品，你同步的应该是整个设置的卷或者卷组， 他没有什么oracle的逻辑结构复制方法吧，要么就是把这个表空间创建在一个卷组上，然后设定复制这个卷组。如果你硬是要复制一个表空间过去，我觉得你 应该先通过oracle的TRANSPORT_TABLESPACE来，但是好像很没有必要。使用存储级的复制不能实时打开，打开必须断开。
对于基于复制中的特殊方式处理，主要有这些：
1.采用何种装载方式
2.如何准确快速执行delete和update，因为这两个操作需要rowid，有人采用在数据库本身创建很多的表来维护rowid。
3.对chain row的处理
4.对各种ddl的处理(truncate,create,drop,alter)
5.对于未提交的事务的处理
等等,因为我确实还没有来总结这些资料,这里先列各提纲,我一个一个来总结.
1.装载方式:
在 oracle中装载数据库不外乎两种方式:direct path和conventinal path装载,其中类似direct path装载就是例如sqlload等工具使用的装载方式,因为它省去了sql语句的编译\绑定(kk/kx),直接转换成绑定后的格式对extent进 行操作.而conventinal path装载方式确实普通的装载方式,即类似于标准的sql语句的装载.后者比前者在同等条件下要慢5倍.当然两种方式的装载速度还和表本身的结构和大小 有关.我测试的速度最大有12倍的差距.
在装载上,你还要考虑更多内容,你不能单单调用oracle sqlloader,因为在oracle中有很多的oracle特殊处理的东西,例如:qmi,qmd.oracle在这里对于这些操作有在redo中有 特殊的标志,如果你采用create table as select来创建表,你会觉得它比现创建然后用sql语句插入要快的多,在日志中他也只有很少的记录.因此,在处理这些的时候,你要采用特殊的算法,所 以调用oracle的现成工具是不理想的,曾经在oracle7之前oracle并没有将upi (好像是这个名字)封掉,但是在oracle8i后,oracle不再开放该接口,因此很多的程序员对于这个层面了解很少.当然现在你很难找到.oci只 是封装后更高级的接口而已.
因此装载程序的设计,对于基于oracle精确分析方式的复制有很大的决定作用,这里面还有更多的处理,我也不能一一列出了.
呵呵，楼上的这个工具就是你自己开发的吗？
如果你老板能找到一个肯研究 OCI --> UPI --->OPI 的手下 并一直坚持对oracle的研究，在国内简直是太不容易了。
没其他意思,如果不是你开发的，除了对这一部分外，对oracle的整体问题你有过研究吗？
呵 呵，我不知道oracle的整体问题是什么意思，oracle太大了，我涉及的有关于oracle的备份恢复（包括非归档物理热备份，各种恢复方式，以及 你们都已经在讨论的热备到底在做什么，那都是我很早前学的，反正备份的东西夸大点就是知道原理的东西多些，不过不敢在任何地方卖弄，因为技术这个东西很难 说，嘻嘻）。
搞我们这个容灾产品也有很久了，基本涉及的有联机日志分析，各种特殊操作的原理等等，不能详细罗列，但是在装载上说实话，我只是知道 经过哪些层次，并没有开发，而是帮助开发作单元测试，所以知道比较详细些而已，知道对于我上面写的东西如何处理。同时对比过诸 如：shareplex，stream，data guard等软件产品性能和基本的一些原理，也和存储级复制软件结合，做过组合测试而已。
对于oracle的调优工作，我还是不如大家的，不过我看eygle老兄的东西都很接近我学的东西，因为确实我曾经站在了“巨人”的肩膀上，嘻嘻，还要向大家多学习，学习。
要说深入oracle，也只是在看大家写的东西的同时，自己总结在这些年学习的东西，和大家分享，因为我觉得，我在网络上学了些，当然我也想将我学到的东西给大家分享，呵呵。
明天继续对于这种产品存在的各种瓶颈作分析，也希望大家指正，我申明一点，我不做产品宣传，只是在我都测试过的基础上总结，绝不胡说
其实也没什么,整体方面是说oracle的文件、内存、进程等比较全面的东西，
对于 oracle internal 比较有兴趣一些，如 oracle 内存、文件管理、进程间通信
宏观方面 备份恢复、tuning、体系结构 ，这些都是在前面internal基础上的具体应用，了解了internal后在管理方面就不局限于固定的模式了。
比如喜欢这样的探讨：
呵呵，当然，我关注的也是这些。
我努力想成为一个像我们老板一样的高手，他能将这些东西转换成程序，呵呵。
但是我不能把他拉到itpub上来，否则，中国的oracle研究者有福了。不过我愿意将我在他那里学的东西共享给大家，和大家一起研究。也请多指教。
你们老板……当初是从哪里学来的呢
因为如果原来不是oracle的人的话，我仅仅知道国外这样的人有一些，国内的同时精通oracle+os + 开发 的人，很罕见的 。我只是听闻国内有oracle的人出去做这类产品去了，但具体名字不清楚，不知道是不是你们老板。
这 个如果基于存储的复制方式是同步的,这是可以保证的.因为同步复制是复制IO,而且是主机端写IO的顺序技术复制的顺序,主要分成以下四步:主机端一个 IO下来,存储复制到远端,然后远端完成IO,最后返回通知主机IO完成. 但是存储不保证数据库在此时逻辑上是一致的,这是靠数据库本身的机制来完成的. 即此时源端数据库崩溃,如果可以通过数据库相应恢复手段来恢复的话,远端复制的存储也可以.
但如果是异步方式的话,问题就比较麻烦. 异步与同步的区别就是,异步主机IO下来后不需要等远端存储IO完成和确认,直接返回主机端IO完成. 这些IO暂时存放在源端存储缓存里,等累计到一定程度或满足给顶条件时,在传送到远端. 此时如何保证传递的IO顺序从而保证逻辑一致,就与具体的产品有比较大的关系了. 有的产品没有保证机制,直接用存放的顺序发送, 但在实际传送过程中没有保证,如由于线路等原因造成部分传送等. 有比较好的旧有时间戳和顺序号,而且还有逻辑分组,即主机端IO下来的时候是事务相关和逻辑分组的. 存储就将这一组IO逻辑分组,按写下的顺序标号, 这样在异步传送到远端后就可以根据逻辑分组和IO标号来完成IO. 类似具有事务的性质.
同步如果是从主机下来的IO直接复制，这样频繁的小IO将造成网络的大量问题，这对网络的要求太高了。 以前都是听人说同步是从 存储的cache 来的，拷贝的时候封锁cache不允许写……
我觉得这个和同步I/O和异步I/O没有关系，对于存储级的复制，他们都有一个队列来保证I/O的次序，这是类似于ca/emc等厂商的这些存储级（varitas文件系统级）复制的一个共同点。至少我知道veritas声称的原理是这样的。
如果不能保证I/O的次序，存储级复制没有任何意义。而且像ca这样的软件，他并不是实时改变多少就穿多少，我觉得他记录在磁盘头的tab应该隔多少时间加一次锁，然后新的插入写cache，所以如果这个时间源端off的话，cache中的数据应该是丢失的（磁盘坏）。
软件级的复制也一样，你总有一个队列来处理ops/rac的事务顺序，这个队列有放在磁盘上用文件来排队的，也有直接在内存中排队的，这些也是关键的东西。当然像软件复制这样的软件可以通过重新分析日志的方式来弥补，如果磁盘没有坏的话。
同步绝对就是那样，每个在SOURCE端写入的东西必须被远端的存储设备写入成功（不一定是写入磁盘）才返回主机写入成功，基本可以认为就是一个距离很远的RAID1。一致性的问题不用担心，但是带宽要求等等都是很高的。
异步的方法，在之前很多是不能保证一致的，呵呵。最近据说多了很多能保证一致的方法，就知道HDS会吧所有写记录到本地一个日志卷，EMC和IBM的方法还没有弄的很清楚。
看看我们的实际应用
现在介绍我们数据库同步的成功案例，你们提到的问题都可以解决。
现在我们的数据同步已经投入了实际运行，采用逐步增加表的方式。目前已经同步了149个表，其中包括详单表，统计基表等。最大的6000多万记录，有16个超过1000万记录，采用10分钟异步复制。主要有以下特点：
1、关键业务数据（排出了很多垃圾数据），数据量最小
2、对生产机影响较小，目前一般只用到300M 空间
3、目标端数据不可以修改，完全保证数据一致
4、初始同步快捷、方便，不需要停止生产系统应用。影响小，只相当如一个select。
5、管理方便、灵活：能够看到各表上次同步时间；上次同步后又有多少条新数据；上次各表同步耗费多长时间等。
目前每天进行一次count(*) 检查，没有发现有问题。
我们一前也试用过dsj和shareplex的产品，从名气上来说，应该还不错。具体不是我亲自试用的，但最后没有能够成功，我想与我们的系统复杂、数据库本身不是很稳定、要求太高有关。
1、这是一个24小时运行的系统，停止应用程序来进行初始同步比较麻烦。
2、需要在每天早晨从同步的数据中产生关键的数据和报表，要求不能耽误。
3、要求管理维护简单、灵活：要求运行稳定，同步中断后能够简单快速处理完。
现在我们用的oracle机制，加上第三方数据同步管理软件，只用了1个晚上就将主体数据同步好，一周就正式投入使用。然后逐步完善增加同步的表，目前已经同步了149张表，还对同步数据进行了分区处理等优化，从目前的近一个月的情况来看效果理想。
经过一年半还多的时间试用了2家产品没有能够成功，用一周时间就解决了问题（主要报表实际上第二天就正式使用了），心里是多么的欣慰、兴奋和富有成就感。
所以写了这么多东西。
就是用了ORACLE物化视图技术+一个图形界面配置，还以为是啥东东哦。
还有谁为建立报表机和容灾的数据同步而烦恼吗？
oracle的功能确实很强大，这需要大家一起去挖掘，才会有基于oracle的更多更好的应用软件产生。
samchj 兄，你是DSG的吧？海龟从ORACLE,IBM出来，而且专攻容灾的公司，我想不出第二家。你们的技术很牛，对底层很清楚，但让人担心对ORACLE后 续版本的支持。虽然所宣称的产品功能实现很吸引人，在测试中有不少问题，亟待完善。VP忙着改BUG，应该是没有什么时间来这灌水。
关于BITI担心的存储同步问题，楼上的已经解释很清楚了。之所以存储厂商要求主节点、容灾节点更换成他们的存储设备，就是要解决I/O,CACHE的问题，从而保证同步端能够做到完全镜像。
容灾端只有停掉同步，才能打开数据库，然后下一次再重做同步。而且他们还提供SNAPSHOT的功能，建立一个快照数据库，对于一个大数据库，需要的存储很可观。
我个人认为，存储厂商的最大优势在于维护量少，有保障。DATA GUARD配置灵活，不依赖于底层，但需要人为监控。
声明：我们这用的不是DATA GUARD
是一个第三方软件，目前报表机同步底层用的是 实例化视图。
如果建立应用级的容灾，数据需要实时同步，估计需要用到同步复制技术了。目前还没有下决心做，担心性能问题。目前有过1个表的初步测试，还没有进行大量表的测试。
对你的ppt提几个疑问：
1。传统同步软件方案为10年前的技术，比较落后。
这个恐怕有些武断，相反对于数据库的复制我个人更看好如Quest的shareplex等产品。同样dataguard也使用类似技术，绝对不是如你所言是10年前的落后技术。
2。传统同步软件方案，因其本身的缺陷，导致需要大量复杂的机制和操作来保证数据的一致，实施成本大。
复 杂的机制不是最终客户需要考虑的，相反这些软件的实施成本是相应较小的（当然如果你的成本是指money的话，那自然是比物化视图高，不过仍然可以选用 DG），说起复杂的机制，即使是你使用的物化视图，也仍然有大量内部的控制是较复杂的，不过这些不需要实施者去考虑而已。
3。采用硬件存储快照的方式，同步方式不灵活，将生产系统上所有的数据全部同步。（经过长时间运行和维护的生产系统往往大量的临时表和大量的垃圾数据，这些实际上是不需要同步的。
通常基于存储的复制提供了卷一级的管理，完全可以通过配置不同的数据文件在不同的卷上来达到复制关键数据的目的。
4。采用硬件存储快照的方式，耗费大量的存储设备，成本巨大。
就我所知，至少veritas的vvr不需要太多额外的存储。
5。华尔东城公司采用的独特方案，采用oracle的各种技术相结合，结合本公司独特的同步参数设置。通过本公司软件控制进行同步的管理。
其实你这个ppt真是说的很含糊，用于单纯的sales宣传恐怕还可以，如果是用于技术交流实在是有些不痛不痒。
6。华尔东城产品重要的益处，保证容灾数据完全一致，报表数据与10分钟前一致 。
既然有10分钟的差距，为何仍然说容灾数据完全一致？如果说你们使用了物化视图的方案，那么就不可能在一个刷新期内（你们这儿的10分钟？）保证数据不丢失。除非还有业务log的分析软件作后备。
7。华尔东城产品重要的益处，对主机性能影响小。
其实物化视图的刷新对于主机并不是很小的影响，如果10分钟之内需要刷新大量的数据，可以明显的看到CPU的波峰，特别是oracle本身对于mvlog的处理还是有些问题的，所以不确定你们是否真的作过跟其它专业同步软件的主机性能影响的比较。
8。本公司得益于oracle新技术的推出，加上本公司的努力，终于能够为数据同步提供完美的方案，这也是我们值得骄傲的一件事情。
不否认你们确实作出了一个比较完备的同步解决方案，但是希望能够本着技术交流的想法在itpub讨论问题，而不是作单纯的商业宣传。我想很多人都希望知道你所指的oracle新技术是什么？不应该说就是物化视图吧。

Continue reading 【转】数据库远程复制和异地容灾 大讨论

1：引擎还是要改进一下：动画显示很慢，没有达到指定的fps的效果【不明白】，
在有的机器上怎么cpu在85%以上，fps越高，cpu越厉害，但是这里26 fps就这么慢了【不明白】
2：音乐格式FF不支持mp3,但是ogg都支持。wav的播放很卡，safari还好。ie9不支持ogg，支持mp3和aac
3：对于坐标系统，要注意相对坐标高宽的变化，最好每次会只是都计算（要计算zoom比），因为如果canvas是百分比高宽的时候，浏览器的resize会导致绘制的图形压缩或扩大。
4:ie9需要设置html5 doctype才能运行canvas，其它的浏览器即使你用的html4 doctype也可以。
5:ie9不支持new Audio,但是document.createElement('audio');可以

Continue reading html5开发连连看问题

2009-06-12 10:04

Continue reading 【转】双机/RAC/Dataguard的区别

一、中国工商银行上海数据中心数据备份和恢复的需求
1.1. 用户的需求
中国工商银行上海数据中心(以下简称上海数据中心)，每天需要对 VSE/ESA 生产主机 和 OS/390 生产系统上的生产和系统数据进行备份，包括批处理前和批处理后的数据备份。上海数据中心每天需要从 8 个 VSE/ESA 系统和 8 个 OS/390 系统上的数百个 3390-3 型磁盘卷上备份大量 VSAM 文件(业务数据) 和备份磁盘卷的整卷数据。现在，每个VSE/ESA 生产系统的每天的数据备份量达 200 盘 3490E 磁带，其中有 60 盘左右为对磁盘卷的备份。为了不间断业务运行，缩短批处理时间，不影响生产运行。上海数据中心对数据备份操作的要求是：
确保数据安全性和完整性。
缩短备份时间，减少由于备份对业务的中断。
如果需要进行数据恢复时，恢复操作要准确、迅速，时间短。
备份和恢复操作要简捷，便于操作员的日常使用。
为了将数据备份时间缩短到最小，上海数据中心希望利用磁盘快速复制技术，或者虚 拟磁带系统来快速完成备份操作。
上海数据中心最终备份的的数据是 VSAM 文件。单个文件的数据量不大，但是文件数量众多。对这种类型数据的备份和恢复，虚拟磁带系统(VTS)技术将是最好的解决方案。上海数据中心最终利用 StorageTek 公司 的、运行在 OS/390 操作系统上的 HSC 和 VTCS 软件，配合以运行在 VSE/ESA 操 作系统上的、MT Consultant 公司的 LMS/VSE 软件来完成这些备份任务的。
二、方案介绍
由于上海数据中心需要备份的数据量庞大，将来的备份磁带数量一定很多。因此，上海数据中心应该采用自动磁带库来管理备份磁带。并采用物理磁带及 和虚拟磁带机相结合的数据备份和恢复技术，来提高数据备份的效率和存储空间的利用率。 9490 磁带机与 3490E 磁带机完全兼容，采用 IDRC 压缩和 3490E E-cart，单盘磁带的容量为 2.4 GB。由于上海数据中心的磁盘卷大多数为 3390-3 型，容量为2.89 GB，将占用 2 盘 3490E E-cart 磁带。上海中心采用 9490 磁带机 EE-tape 功能，一盘磁带的容量可以高达 4.8 GB (压缩后)。对于 OS/390 磁盘卷整卷的备份，上海数据中心采用 StorageTek 9310 自动磁带库和 9840高性能、大容量磁带机。如果配合 StorageTek exHPDM 软件，可以将数个磁盘卷同时 备份到一盘 9840 磁带上。将能充分发挥 9840 磁带机的性能和充分利用 9840 磁带的容量。
根据工商银行上海数据中心对数据备份和恢复的要求，采用 StorageTek 公司 9310 自动磁带库加 StorageTek 公司的 VSM(虚拟存储系统)的综合磁带解决方案。
VSM 主要处理大量小文件的备份和恢复，如 VSAM 文件、CICS 日志、数据库增量 备份等。而对大型文件备份和恢复，则直接使用 9310 自动磁带库中磁带驱动器，如对磁盘卷的整卷备份、数据库的全备份等操作。
本方案涉及的硬件和软件产品
1 1套 StorageTek 9310 自动磁带库系统
2. 1套 StorageTek VSM 虚拟存储系统
3. 8 套 HSC (主机软件部件) 软件
4. 1套 VTCS (虚拟磁带控制软件)
5. 8 套 LMS/VSE 软件及 8 套 5193 磁带库管理网关
6. 磁带管理软件
在 OS/390 系统上采用 CA 公司的 CA-1/TMS 磁带管理软件。
在 VSE/ESA 系统上采用 CA 公司的 DYNAM/T 磁带管理软件。
2.4. 磁带库和 VSM 系统硬件连接方案
若要实现虚拟磁带卷的迁移和回迁，VSM 至少需要 9310 磁带库中的 2 台 9840 物 理磁带驱动器与其相连接。如果迁移和回迁的工作量比较大，则需要更多的磁带机驱动器。由于 VSM 主要用于处理大量小文件的备份和恢复。而对大型文件的备份和恢复仍需要直接使用 9310 自动磁带库中 9840 磁带驱动器。因此 9310 自动磁带库必须要有 直接(或通过 ESCON 通道转接器)连接到 OS/390 主机上的磁带机驱动器。如果主机上同时提交了多个大型文件的备份或恢复作业，则需要有多个磁带机驱动器。否则，将会有作业因没有可用的磁带驱动器而等待。 如果将 9310 中的多个磁带驱动器给 VSM 专用，再将另一些磁带驱动器给主机专用，则需要更多的磁带驱动器。直连的优点是，日常操作比较简便。但是，这样做投资 比较大，而且磁带驱动器不能得到充分的利用。这样如何充分、有效地利用磁带库 中磁带驱动器，则是需要解决的问题。
上海中心每个VSE系统每天的数据备份量平均为 200 盘 3490E 磁带。不含磁盘卷的备份磁带。按照实际存储在每盘磁带上的数据量平均为 100 MB，那么 8 个 VSE 系统每天的备份数据总量为 160 GB。如果这些备份数据驻留在 VSM 的时间为 1 天，那么VSM的容量至少为 160GB。如果这些备份数据的保留时间为 30 天，则总的数据容量为 9.6 TB。 自动磁带库中将 需要至少 120 盘 9840 磁带来保留这些备份磁带。如果将每天每个 VSE 系统的备份数 据迁移到一盘 3490E 磁带中， 30 天则需要 240 盘 3490 磁带。 如果 OS/390 系统的备份的数据量与 VSE/ESA 系统的相近，则对 VSM 容量的要求将 与以上分析大体相近。
三、方案技术要点
虚拟磁带存储管理是对磁带和自动磁带库解决方案的重大革新。它是自从磁带库出现以来，第一个为批量处理而发明的新技术。虚拟磁带使现有的技术能够得到充分地利用。虚拟磁带技术将批处理中的磁带操作变得更加有效，使高密度介质、高性能磁带机和高速通道得以充分利用。
VSM 虚拟磁带系统所带来的最大利益是极大地提高了批处理的性能，这是用户可以直接感受到的虚拟磁带技术所带来的影响。其带来的间接利益还有很多，包括：充分利用现有的磁带机和磁带资源，解决磁带驱动器紧张的问题，简化了磁带管理。
对于小型批处理文件的备份，装带和卸带时间占整个磁带操作时间(占用磁带机驱动器的时间)的很大一部分。利用虚拟磁带技术，将没有装带和卸带的 时间，所以整个磁带操作时间将显著降低。 这将带来两大好处：第一，批处理作业将运行地更快，从而缩小批处理窗口;第二， 虚拟磁带机驱动器的利用率更高，减少作业等待驱动器的时间，降低了对驱动器数 量的需求。再加上虚拟磁带系统提供的虚拟磁带驱动器数量很多，使系统可以同时 处理大量批处理备份作业，减少作业的等待时间。如果需要从仍驻留在 VSM 中 虚拟磁带中恢复数据，由于该虚拟磁带卷仍然驻留在缓存中，VSM 将会直接将它恢复到主机磁盘上。整个过程不需要装带/卸带操作，缩短了恢复的时间，也缩短了批处理的时间。用户可以定义虚拟磁带卷驻留的时间。

Continue reading 【转】工商银行上海数据中心备份方案解析

用来保存计算最终结果的数据库是整个信息系统的重要组成部分，技术也相对成熟。然而，对于所有数据库而言， 除了记录正确的处理结果之外，也面临着一些挑战：如何提高处理速度，数据可用性、数据安全性和数据集可扩性。将多个数据库联在一起组成数据库集群来达到上 述目标应该说是一个很自然的想法。
集群（Cluster）技术是使用特定的连接方式，将价格相对较低的硬件设备结合起来，同时也能提供高性能相当的任务处理能力。
本文试图对当前主要的数据库集群用到的具体技术和市场上的主流产品进行分析并作点评，从而为读者提供一个数据库集群的评价参考。
下面讨论的数据库集群技术分属两类体系：基于数据库引擎的集群技术和基于数据库网关（中间件）的集群技术。

基于数据库引擎的集群技术（共享磁盘或非共享磁盘）

基于数据库网关（中间件）的集群技术（不共享磁盘）
关键技术
在复杂的数据库集群技术之间做比较，其实就是比较它所包含的各项子技术性能和它们之间的协调运作能力，下面的文字将介绍数据库集群最需要得到重视的核心技术，同时也关注到了一些技术细节。
提高处理速度的四种办法
提高磁盘速度：主要思想是提高磁盘的并发度。尽管实现方法各不相同，但是它们最后的目的都是提供一个逻辑数据库的存储映象。
【点评】系统为了提高磁盘访问速度，建立一个虚拟的涵盖所有数据“大”数据库，而不用去考虑数据的实际物理磁盘存放位置。
分散数据的存放：利用多个物理服务器来存放数据集的不同部分，使得不同的服务器进行并行计算成为可能。
ORACLE RAC是共享磁盘的体系结构，用户只需简单地增加一个服务器节点，RAC就能自动地将这节点加入到它的集群服务中去，RAC会自动地将数据分配到这节点 上，并且会将接下来的数据库访问自动分布到合适的物理服务器上，而不用修改应用程序；UDB是非共享磁盘的体系结构，需要手工修改数据分区，MSCS和 ASE也是同样情况。ICX是一种基于中间件的数据库集群技术，对客户端和数据库服务器都是透明的。可以用来集群几个数据库集群。
【点评】系统通过化整为零的策略，将数据表格分散到多个服务器或者每个服务器分管几个内容不同的表格，这样做的目的在于通过多服务器间并行运算以提高访问速度。
对称多处理器系统：
利用多处理机硬件技术来提高数据库的处理速度。
所有基于数据库引擎的集群都支持这个技术。
【点评】将多CPU处理器进行合理调度，来同时处理不同的访问要求，但这种技术在数据库上的应用的实际收益是很有限的。
交易处理负载均衡：在保持数据集内容同步的前提下，将只读操作分布到多个独立的服务器上运行。因为绝大 多数的数据库操作是浏览和查询，如果我们能拥有多个内容同步的数据库服务器，交易负载均衡就具有最大的潜力（可以远远大于上面叙述的最多达四个处理器的对 称多处理器系统）来提高数据库的处理速度，同时会具有非常高的数据可用性。
所有基于数据库引擎的集群系统都只支持一个逻辑数据库映象和一个逻辑或物理的备份。这个备份的主要目的 是预防数据灾难。因此，备份里的数据只能通过复制机制来更新，应用程序是不能直接更新它的。利用备份数据进行交易负载均衡只适用于一些非常有限的应用，例 如报表统计、数据挖掘以及其它非关键业务的应用。
【点评】负载平衡算是一项“老”技术了。但将性能提高到最大也是集群设计所追求的终极目标。传统意义上，利用备份数据进行交易负载均衡只适用于一些非常有限的应用。
上述所有技术在实际部署系统的时候可以混合使用以达到最佳效果。
提高可用性的四种方法
硬件级冗余：让多处理机同时执行同样的任务用以屏蔽瞬时和永久的硬件错误。有两种实现方法：构造特殊的冗余处理机和使用多个独立的数据库服务器。
基于数据库的集群系统都是用多个独立的数据库服务器来实现一个逻辑数据库，在任意瞬间，每台处理器运行的都是不同的任务。这种系统可以屏蔽单个或多个服务器的损坏，但是因为没有处理的冗余度，每次恢复的时间比较长。
【点评】传统意义上，硬件越贵，性能越高，但往往事与愿违。想通过追加和升级硬件设备来改善硬件级的冗余，要进行详细的需求分析和论证。
通讯链路级冗余：冗余的通讯链路可以屏蔽瞬时和永久的通讯链路级的错误。
基于数据库引擎的集群系统有两种结构：共享磁盘和独立磁盘。RAC, MSCS 可以认为是共享磁盘的集群系统。UDB和ASE 是独立磁盘的集群系统。共享磁盘集群系统的通讯的冗余度最小。
【点评】通讯链路级的冗余具有容错功能。
软件级冗余：由于现代操作系统和数据库引擎的高度并发性，由竞争条件、死锁、以及时间相关引发的错误占 据了非正常停机服务的绝大多数原因。采用多个冗余的运行数据库进程能屏蔽瞬时和永久的软件错误。基于数据库引擎的集群系统都用多个处理器来实现一个逻辑数 据库，它们只能提供部分软件冗余，因为每一瞬间每个处理器执行的都是不同的任务。
【点评】改善软件设计来提高冗余性能和屏蔽软件级错误是每个技术开发商的梦想。传统的集群系统只能提供部分软件冗余。
数据冗余：
1. 被动更新数据集：所有目前的数据复制技术(同步或异步)，例如磁盘镜像、数据库文件复制以及数据库厂商自带的数据库备份工具都只能产生被动复制数据集。它一般只用于灾难恢复。
【点评】大多数应用都是采用被动更新数据集的方法。这种方法容灾能力差，资源占用多，已面临淘汰和革新。
2. 主动更新数据集：这种数据集需要一台或多台备份数据库服务器来管理，它可用于报表生成，数据挖掘，灾难恢复甚至低质量负载均衡。分同步和异步两种。
异步主动复制数据集：先把事务处理交给主服务器来完成，然后事务处理再被串行地交给备份服务器以执行同样操作来保证数据一致性。所有的商用数据库都支持异步主动复制技术。
同步主动复制数据集：要求所有并发事务处理在所有数据库服务器上同时完成。直接好处就是解决了队列管理 问题，同时通过负载均衡实现更高性能和可用性。RAC, UDB, MSCS 和 ASE是用完全串行化并结合两阶段提交协议来实现的，设计目标就是为了获得一份可用于快速灾难恢复的数据集。
【点评】主动更新数据集是目前比较先进的数据冗余方法。专业人员还可以进行更底层的技术细节比较。底层技术的差异直接影响着一些重要指标。
提高安全和数据集可扩性的技术
在提高数据库安全性和数据集可扩性这两方面，可以创新的空间是很小的。数据库最常见的安全办法是口令保 护，要么是分布式的，要么是集中式的。在数据库前面增加防火墙会增加额外的延迟，因此，尽管许多安全侵犯事件是来自于公司内部，但是数据库防火墙还是很少 被采用。如果数据库集群技术是基于中间件技术实现的，就有可能在不增加额外延迟的情况下，在数据经过的路径上实现防火墙功能。数据库数据集的可扩性只能通 过将数据分布到多个独立的物理服务器上来实现。
主流产品
在数据库集群产品方面，其中主要包括基于数据库引擎的集群技术的Oracle RAC、Microsoft MSCS、IBM DB2 UDB、Sybase ASE，以及基于数据库网关（中间件）的集群技术的ICX-UDS等产品。
Oracle RAC
Oracle RAC 支持 Oracle 数据库在集群上运行的所有类型的主流商业应用程序。这包括流行的封装产品，如 SAP、PeopleSoft 和 Oracle E-Business Suite 等，以及自主研发的应用程序，其中包括 OLTP 和 DSS，以及 Oracle 有效支持混合 OLTP/DSS 环境的独有能力。Oracle 是唯一提供具备这一功能的开放系统数据库的厂商。 Oracle RAC 运行于集群之上，为 Oracle 数据库提供了最高级别的可用性、可伸缩性和低成本计算能力。如果集群内的一个节点发生故障，Oracle 将可以继续在其余的节点上运行。如果需要更高的处理能力，新的节点可轻松添加至集群。为了保持低成本，即使最高端的系统也可以从采用标准化商用组件的小型 低成本集群开始逐步构建而成。
Oracle 的主要创新是一项称为高速缓存合并的技术，它最初是针对 Oracle9i 真正应用集群开发的。高速缓存合并使得集群中的节点可以通过高速集群互联高效地同步其内存高速缓存，从而最大限度地低降低磁盘 I/O。高速缓存最重要的优势在于它能够使集群中所有节点的磁盘共享对所有数据的访问。数据无需在节点间进行分区。Oracle RAC 支持企业网格。Oracle RAC 的高速缓存合并技术提供了最高等级的可用性和可伸缩性。Oracle RAC能显著降低了运营成本，增强了灵活性，从而赋予了系统更卓越的适应性、前瞻性和灵活性。动态提供节点、存储器、CPU 和内存可以在实现所需服务级别的同时，通过提高的利用率不断降低成本。
Oracle RAC采用了“sharing everything”的实现模式,通过CPU共享和存储设备共享来实现多节点之间的无缝集群，用户提交的每一项任务被自动分配给集群中的多台机器执行， 用户不必通过冗余的硬件来满足高可靠性要求。另一方面，RAC可以实现CPU的共享，即使普通服务器组成的集群也能实现过去只有大型主机才能提供的高性 能。
Microsoft MSCS
数年以来，Microsoft一直致力于对自身服务器解决方案的伸缩能力、可用性与可靠性进行扩展。最 初代号为Wolfpack且先后被称为Microsoft集群服务器与Microsoft集群服务的MSCS是Microsoft在NT集群技术领域中的 首次重拳出击，它是公认的最佳Microsoft集群解决方案。在MSCS群集中，MSCS软件最多可以同四台运行在高速网络上的物理计算机建立连接。通 常情况下，群集中的计算机能够按照“活动--活动”方式共享相同的存储子系统与功能，这意味着所有集群计算机（节点）均可主动通过共享负载的方式协同完成 工作，并在某个节点出现故障时分担它的工作。MSCS的主要用途是通过自身提供的容错能力提高应用程序可用性。容错能力是指将相关处理过程从某个节点上的 故障应用程序移植到集群中其它健康节点上的集群功能。当故障应用程序得到恢复后，集群应当能够对原先的集群节点实现“故障返回”。MSCS能够在不丢失任 何与故障应用程序相关数据的前提下对集群上所运行的应用程序进行故障恢复与故障返回管理，并且能够在故障恢复过程中维护用户及应用程序状态。这种类型的集 群功能被称作有状态集群功能。MSCS同时还允许用户在应用程序升级过程中继续进行工作。您可以采取滚动升级方式（例如每次在一个集群节点上升级应用程序 并确保其它节点上的应用程序继续处于可用状态）而不必在升级过程中停止使用应用程序。
SQL Server 2005是微软的下一代数据管理和分析解决方案，给企业级应用数据和分析程序带来更好的安全性、稳定性和可靠性，更易于创建、部署和管理。它凭借针对故障 转移群集机制的支持能力，得以增强的多实例支持能力以及分析服务对象与数据备份及恢复能力，分析服务的可用性得到了提高。它提供了诸如表分区、快照隔离、 64位支持等方面的高级可伸缩性功能，使用户能轻松构建和部署关键应用。表和索引的分区功能显著增强了对大型数据库的查询性能。

利用Windows 2000 MSCS实现的4节点集群
性能指标
这部分将介绍集群系统的细节技术指标。在做系统规划时，用户就可去掉一些应用中不太重要的指标，或赋予这些指标以不同的权重，从而进行专业的技术性能比较，选择最适合自己的数据库集群系统。
处理速度
磁盘技术：所有集群系统都能很好地应用磁盘技术，但是由于DM，FM会对磁盘系统带来传输速度的负面影响，因此这方面它们相对欠缺。
数据分割：所有基于数据库引擎的集群系统都有很好数据分割能力。
SMP：所有基于数据库引擎的集群系统的SMP性能指标都比较接近。
负载均衡：一般的数据库引擎的集群系统由于使用了备份的数据集，因此只能支持有限的负载均衡。这一指标不同产品之间有差异。
数据可用性
处理器和软件冗余：只有部分集群系统支持该功能。
通讯链路冗余：一般来说，共享磁盘的集群系统通讯链路冗余指标较低，独立磁盘的集群系统指标较高。
数据冗余：
主动异步复制：除了磁盘和文件镜像外，其他集群系统支持该功能。
主动同步复制：所有集群系统支持该功能，细节指标略有不同。
被动异步复制：所有集群系统该性能指标都比较接近。
被动同步更新：所有集群系统该性能指标都比较接近。
通过广域网的复制技术：
远程主动异步复制：所有的集群系统都支持这种复制技术，只不过对队列的管理能力有所不同。DM，FM和RAID的此性能相对较低。RAID不支持远程复制功能。
远程主动同步复制：ICX在这方面做的比较好。
远程被动异步复制：DM 和 FM支持这种类型的复制，因为DM和FM对集群是透明的，是在集群系统的下一层工作的，所有的集群系统都可以利用它们提供的功能。
远程被动同步复制：DM和FM支持这种类型的复制，因为这种复制方式只在距离很近的时候才能使用（使用双模光纤，半径五英里）。同样地，因为DM和FM对集群是透明的, 所有的集群系统都可以利用它们提供的功能, 如果部署的话，所有的集群系统都是类似的。
安全性
口令：这是所有集群系统的基本性能。分布式或集中式的口令保护基本上保证了数据的安全。
数据库防火墙：大多数数据库集群系统得数据库防火墙很少被采用，而ICX则采用在数据经过的路径上实现防火墙功能。
数据集的可扩性
数据分区：所有基于数据库引擎的集群系统都具备数据分区以保证数据集的可扩展。
数据分区的可用性：所有集群系统该性能指标比较接近。
集群管理
共享磁盘的集群系统，比如RAC、MSCS，它们的管理比较方便，其中RAC的服务更多。但是，由于此 种系统中的每一单独的服务器需要特殊处理，和独立磁盘的集群系统比较，就容易管理多了（虽然进行初始化和修改配置的时候也不那么容易）,但它们都要求应用 程序对集群不透明，而且配置，修改也比较麻烦。
独立磁盘的集群系统象 UDB、ASE此性能相对稍低，因为用的都是非共享磁盘，所以管理相对繁琐。
ICX在易管理性（初始配置和将来的修改）方面和独立磁盘集群系统的性能相当，但是在对底层数据管理复杂性方面做得比较好。在对数据库引擎和数据进行底层修复的时候任务需要直接到每台数据库处理器上去做。
那些磁盘工具，即DM、FM和RAID，它们对集群是透明的。管理相对简单得多。
应用透明度
因为在错误回复和分区方面对应用程序不透明以及它们对应用程序都有些特殊的要求，基于数据库引擎的RAC、MSCS、UDB、ASE和ICX在这方面都有待提高的地方。而DM、FM和RAID它们对应用程序可以说是完全透明的。
IBM DB2 UDB
DB2 UDB大量自动或自我管理功能可使管理员能够节省更多时间来集中精力考虑驱动业务价值的问题，甚至可以消除较小的实施项目对专职管理员的需求。
UDB的优势体现在DB2的开放无界:支持Unix, Linux 以及Windows等主流操作系统；支持各种开发语言和访问接口；同时具有良好的数据安全性和稳定性。DB2 V8.2的高可用性灾备技术，可在极短时间内使关键应用得到恢复。利用DB2数据分区部件(DPF)实现横向扩展，可以支持多达1000台服务器组成的庞 大数据库群集，为构建企业级数据仓库提供坚实的技术基础。利用DB2的数据分区部件以及DB2信息集成器(DB2 II)技术，数据库操作可综合利用网格中的每台服务器的运算能力，实现真正意义上的网格运算。
UDB V8.2应用更多的创新技术，Design Advisor可以帮助 DBA 制定全面的数据库设计决策，包括集成复杂的功能划分、物化查询表，大大缩短部署时间。自动生成统计信息概要代表了来自 IBM LEO研发项目的首次部署。自主对象维护特性可自动执行基于策略的管理和维护功能，如表重构、统计信息收集和数据库备份。高可用性灾难恢复和客户机重路由 特性实现了具备随选能力的企业所需的24*7信息可用性和恢复力。此外，DB2 UDB 提供与 Java/Eclipse 和 Microsoft .NET IDE的深入集成或插件。

DB2 UDB结构拓扑图
SYBASE ASE
ASE性能的提高是建立在虚拟服务器架构上的，这是 Sybase 独有的体系结构。当前的ASE版本是ASE15。与操作系统和相关软件保持独立让ASE15可以更智能化地进行系统自我调优。VSA只需要很少的内存资源 和内部交换开销，所以ASE15可以管理大量的联机用户。能够使ASE提高性能并控制成本的最主要原因是它采用了专利技术的、自调整的优化器和查询引擎。 它可以智能地调整复杂的查询操作并忽略那些未包含相关信息的分区上的数据。ASE15还通过一系列用来管理和诊断数据库服务器的新特性来降低运营成本。
ASE15 拥有高可靠性和极低的运行风险。个人数据的安全性是ASE特别关注的领域，使用了一种无需修改应用的独特加密系统。当应用和安全软件进行连接时将降低实施 成本并避免产生新的安全漏洞。ASE15 还通过一种简单、直接和可编程的脚本语言来方便进行加密和解密。在解决意外停机问题时，ASE15 在其已证实的可靠性和高系统利用率的基础上，增加了许多显著的功能来增强系统的可用性和灾难恢复过程。新的存储引擎支持四种数据分区方式，在不同的物理设 备上进行不同的分区操作。能帮助数据库管理员迅速地建立冗余灾难恢复节点并在异构的数据平台上同步数据库。
ASE15系统新的查询和存储引擎被设计用于支持下一代网格计算和集群技术。它结合了充分利用数据分区 技术的查询处理机制和适用于解决集群问题的优化器技术。同时ASE15为事件驱动的企业提供了一个绝好的数据库平台。与web services 和 XML的架构将减少系统内部的相互依赖性，并为应用开发提供更大的灵活性。
ICX-UDS
ICX-UDS不受基于数据库引擎的集群技术限制，可以支持不同的数据库。
它类似通常的代理服务器。把ICX放置在关键的网络路径上，监听数据库系统流量。ICX网关将自动过滤 出无状态的查询访问，并将负载均衡到所有服务器上。在这里，网关就象一个在线“编译器”，它将所有对数据库的更新操作发送到所有数据库上执行，而将无状态 的查询操作只发送到其中某一数据库服务器上。
对于统计报表和数据挖掘类应用，可以通过复制和只读去获得更快的处理速度。还能指定更多的只读来负载均衡。ICX 网关的容错可以通过备份网关来达到。加载一个非同步的数据库可以造出不影响主服务机群的近于实时的数据源。

ICX 网关和负载均衡器配置示意图
应用点评
Oracle RAC和Oracle数据库提供的特定新管理性增强功能实现了企业网格。各种规模的企业都可以采用Oracle RAC来支持各类应用程序。
企业网格采用大型标准化商用组件配置：处理器、网络和存储器。利用Oracle RAC的高速缓存合并技术，Oracle数据库实现了最高可用性和可伸缩性。现在，利用Oracle数据库和Oracle RAC将大幅降低了运行成本，进一步增强了灵活性，其动态提供节点、存储器、CPU和内存的特性可以更轻松、高效地保持服务级别，而通过提高的利用率又进 一步降低了成本。企业网格是未来的数据中心，使企业具备更高的适应能力、前瞻性和敏捷性。
集群技术随着服务器硬件系统与网络操作系统的发展将会在可用性、高可靠性、系统冗余等方面逐步提高。我们汇集了市场上的主流产品，并从分析性能指标的角度出发，对产品进行了简要评价。
Sybase ASE是一个深受用户欢迎的高性能数据库，它具有一个开放的、可扩展的体系结构，易于使用的事务处理系统，以及低廉的维护成本。
ASE可支持传统的、关键任务的OLTP和DSS应用，并且满足Internet应用的发展需 要，Sybase可以很好地满足关键任务的企业业务应用的需求，提供数据库可靠性、集成性和高性能。ASE有效的多线索结构，内部并行机制和有效的查询优 化技术提供了出色性能和可伸缩性；还可提供先进的企业集成、强健和数据访问与数据移动技术，支持跨越远程Sybase和non-Sybase数据库的分布 事务和查询。ASE进一步扩展了这些功能，通过分布信息和管理商业事务，支持通过企业信息门户对商业系统进行个性化的用户访问。
MSCS对于诸如电子邮件服务器、数据库应用程序之类的应用程序，是一种良好的运行方式。
假设您决定在一个4节点MSCS群集上运行Microsoft Exchange 2000 Server。当安装MSCS软件以及适用于群集的Exchange 2000版本后，您可以对群集进行配置，以便使Exchange 2000能够在主要节点发生故障时在备份节点上进行故障恢复。当故障发生时，主服务器上肯定存在处于打开状态的用户会话，然而，MSCS能够在不丢失任何 数据的情况下快速、自动的完成故障恢复。备份节点将从故障节点上接替工作负载及相关数据，并继续为用户提供服务。
ICX的最大优点是在数据库集群技术面临的挑战上有了新的探索，此项基于中间件的数据库集群技术为获得具有高可扩性的高性能数据库提供了一条切实可行的途径，同时能灵活地适应未来的技术变化。
这种中间件复制技术可位于关键的网络路径上，监听所有进出数据库系统的流量，方便地提供防火墙和其它安 全服务，保护物理的数据库服务器。通过多个服务器的并发处理很容易地隐藏了处理的延迟。实时并行同步交易复制：一旦我们突破了实时并行同步交易复制的技术 障碍，用户就能通过由多个数据库服务器构成的集群来获得高性能，高可用性和高安全性。
DB2 UDB是一个可以随企业增长的数据库。当对网站的事务需求达到峰值时它可以迅速响应，它可以进行扩展以容纳分布在许多不同数据库中的数量不断增长的信息。
随着信息基础结构从一个处理器发展到多个处理器再到高度并行的多个群集，它也随之扩展。将分区技术和群 集技术集成到新的 DB2 UDB Enterprise Server Edition 中意味着该版本很灵活。DB2 UDB还添加了自主数据库技术，它使数据库管理员可以选择使用增强的自动化技术来配置、调优和管理他们的数据库。自主数据库管理意味着管理员可以在管理日 常任务上花费较少的时间。表的多维群集减轻了 DBA 创建索引的工作负担，同时提供了数据群集以快速查询。DB2内置的已规划的和未规划的可用性能力确保了业务应用程序在任何时候都可用。诸如索引重建、索引 创建和表装载之类的联机实用程序以及可以不停止数据库进行更改的配置参数，都意味着改进的性能和高可用性。
【相关链接】
理想的数据库集群应具备的特点
提高速度：只通过简单地增加数据库服务器就能相对提高数据库处理速度。
数据同步：在任何时刻需要有多个随时可用的实时同步数据服务。最好有多个异地的同步数据服务。
安全保证：除了密码保护之外，我们最好能控制企业内部对数据库的非法访问。
可扩展性：应保证我们能任意增大数据集而没有对可用性产生负面影响。
一般来说，有关数据库集群的技术都非常庞杂。更具挑战性的是，实际应用要求在提高速度、数据同步、安全保证、可扩展性方面的指标能同时提升，而不是单纯提升某一指标而牺牲其他指标。全面提升这些技术指标是数据库集群技术都将面临的重大课题。
【名词解释】
集群:是一组通过协同工作方式运行同一套应用程序并针对客户端及应用程序提供单一系统映像的独立计算机。集群技术的目标在于通过多层网络结构进一步提高伸缩能力、可用性与可靠性。
可伸缩性:是指一台计算机在维持可接受性能的前提下处理不断提高的工作负载的能力。
可用性:是指存在质量、备用能力、获取简便性以及可访问能力。
可靠性:是指系统牢固程度。

Continue reading 【转】主流数据库集群技术深入探讨

visual assist
快捷键设置：
发现tools/custermize/keyborad/category/add-ins里面有visualx的设置，但是都是些没用的。

Continue reading vc6开发环境

c 数组指针申明方法
char *p;//原始类型直接
Type (*p) [];//申明
p = (Type (*) []) long;//转换

vc6在win7上有如下毛病:
1:添加文件右键菜单不起作用，在网上搜，要装个古怪的插件
2:要将vc6快捷图标设置为管理员运行，否则有些插件运行不了

有些编译不通过时，需要更新sdk:
见下文:
http://social.msdn.microsoft.com/forums/en-US/Vsexpressvc/thread/c5c3afad-f4c6-4d27-b471-0291e099a742/
下载地址:
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=0BAF2B35-C656-4969-ACE8-E4C0C0716ADB&displaylang=en
安装后在tools/options/directories里面添加包含
但是我发现include里面由mfc文件夹，lib里面却没有。导致在编译时如果查找inlcude/mfc就会说找不到连接符号，所以就去掉mfc文件夹只包含include文件夹。

对于win7系统请使用最新sdk
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b&displaylang=en
对于web安装来说是不需要选择版本的。如果需要选择，看如下：
The Windows SDK for Windows 7 and .NET Framework 3.5 SP1: Release Candidate has been released on the Microsoft Download Center in both ISO andWeb Setup format.  Web setup allows you to install a specific subset of the SDK you select without having to download the entire SDK; whereas the DVD ISO setup allows you to download the entire SDK to install later.

With this release of the SDK, there are 3 ISOs to choose from based on the CPU (x86, x64, or Itanium) platform you are installing on. Each ISO will however allow you to build applications that target all the other CPU platforms.  Thus if you install the x86 ISO (which only installs on x86 platforms), you will be able to create applications targeting x86, x64, and Itanium. [任何版本都可以编译其它平台上的软件]

Which download is right for you?

·         If your computer is X86, download  GRC1SDK_EN_DVD.iso
·         If  your computer is X64, download GRC1SDKX_EN_DVD.iso
·         If your computer is IA64, download GRC1SDKIAI_EN_DVD.iso (and send me mail.  I’d love to hear how many folks are actually developing on IA64)

--Karin
但安装后发现这个sdk不支持vc6,那我只好试试vc2010express了，安装了后又发现express版不带mfc,+_+，没法，只有安装旗舰版了。

fatal error LNK1103: debugging information corrupt;
工程 setting/gernaral/ 去掉build debug infomation复选框

vs2010生成文件确实很大，似乎不用mfc就小些。

mfc代码可以用vs2010编码，用vc6生成。但是要改配置：
使用unicode生成方式，这样好兼容。
vc6 unicode配置:
project setting/c,c++/processor definition:加入UNICODE,_UNICODE两项，去掉之前的编码项
可以使用_WIN32_WINNT=0x0500制定生成版本(未测试)

在编译时可能会出现
1:cannot open file "uafxcwd.lib"
这是由于mfc+unicode编码需要uafxcwd.lib库，vc6安装时要选择自定义安装并全选所有组件。
2:LNK2001: unresolved external symbol [email protected]
这也是mfc+unicode需要制定入口
wWinMainCRTStartup

vs2010自动生成的targetver.h里面需要包含的头文件vc6不需要
//#include <WinSDKVer.h>
//#include <SDKDDKVer.h>

VC乱码                                                 
VC 中，有时会遇到当字符串资源的属性(String table properties)设置为英文时输入的中文并不能在界面上正确显示，尽管在VC中显示正确。查看.rc文件，可以看到这些资源被放到了英文资源下。那 么如何正确显示呢？现在试着将字符串资源属性改成中文，重新build，可以发现还是不能正确显示。为什么呢？退出VC，打开rc文件，你会发现尽管这些 字符串资源放到了中文资源中，其中的中文字符都变成了乱码，再打开VC你会发现确实变成了乱码。这估计是UNICODE页面映射问题。怎么解决呢？其实很 简单，关闭VC，打开.rc文件，把没变成乱码前的那些字符串拷贝到中文资源中覆盖相应的乱码即可。
http://topic.csdn.net/t/20021212/17/1255874.html所说的方法（修改code_page）应该也可行，不过没试。
另外发现Project Settings-Resources-Language设置不起任何作用，这是比较奇怪的一件事。

Continue reading pophunter琐碎

                                                             
=============================================================
标题：JAVA JNLP组件数字签名制作步骤
关键字：JNLP 数字签名 java
作者：iuprg
2009 5.15
领域：Java j2ee
web 页面 JNLP组件下载运行的数字签名
[本文禁止转载,属于个人笔记]
=============================================================
这个证书签名需要专门购买，中国的数字签名机构好象还不成熟吧？
我这里只讨论自己的证书，也就是匿名的证书。
为JAR签名需要两个工具：
1。用keytool来创建一个密匙（同时指定时效，多久会过期，默认只给 6个月）
2。用JARSigner用此密匙为JAR签名。
可以用同一个密匙来为多个JAR签名。
注意：大小写，签名一致，数字签名过期
[谢绝转载，如有刊登请email联系[email protected]]
为 什么JAR要被签名？当用户启动一个Java Network Launching Protocol (JNLP，Java网络加载协议)文件或使用一个applet时，这个JNLP或applet可能请求系统提供一些非一般的访问。比如“文件打开”等进 行这样的请求，就需要签名的JAR。
如果它是匿名的，系统会询问用户是否打算信任JAR的签署者。

1.首先生成签名文件，执行完成后，会在本目录内生成一个.keystore的密钥文件，2kByte大小。
yourProj是别名 keypass后面是密文密码，keystore密码是存储密码（要改变此文时需要输入确认此密码）【删掉默认的.的keystore就会创建新的】
在dos命令提示状态下输入
C:\Documents and Settings\Administrator>keytool -genkey -alias yourProj -keypas
s yourCompany:Kouling
[回车],屏幕提示:
输入keystore密码：  yourCompany:yourPassword
您的名字与姓氏是什么？
[Unknown]：  ChinayourCompany
您的组织单位名称是什么？
[Unknown]：  ChinayourCompany.com
您的组织名称是什么？
[Unknown]：  Company
您所在的城市或区域名称是什么？
[Unknown]：  City
您所在的州或省份名称是什么？
[Unknown]：  Province
该单位的两字母国家代码是什么
[Unknown]：  CN
CN=ChinayourCompany, OU=ChinayourCompany.com, O=Company, L=City, ST=Province, C=CN 正确
吗？
[否]：  Y
[谢绝转载，如有刊登请email联系[email protected]]
2.为此密钥加 有效期限：7200天，将近20年. [嘿嘿，足够用了吧？ 再也别想6个月]
输入命令：
C:\Documents and Settings\Administrator>keytool -genkey -alias yourProj -keypass yourCompany:Kouling -selfcert -validity 7200
屏幕提示：
输入keystore密码：  yourCompany:yourPassword
注意：-validity 7200 这个就是加时效的参数，7200单位是“天”。
检查密钥文件，输入命令：
C:\Documents and Settings\Administrator>keytool -list
屏幕提示：
输入keystore密码：  yourCompany:yourPassword
Keystore 类型： jks
Keystore 提供者： SUN
您的 keystore 包含 1 输入
yourProj, 2009-5-15, keyEntry,
认证指纹 (MD5)： D4:9D:C7:3A:91:B4:30:6A:4D:50:F1:7C:E7:F5:B9:49
说明已经生成成功完成！

3.开始为Jar包文件签名
用JARsigner工具
切换到项目jar包所在目录
D:\yourPassword's--works\yourProj\webroot\app 的目录
输入dir可以看到：
2009-04-30  18:37    <DIR>          .
2009-04-30  18:37    <DIR>          ..
2009-04-30  17:55            56,317 commons-logging-1.1.jar
2009-04-30  18:37           550,863 yourCompany-app-v1.0.1.jar

输入命令 ：
jarsigner -verbose -certs commons-logging-1.1.jar yourProj
注：
verbose输出详细信息
certs表示验证此jar包时输出证书信息
屏幕提示：
输入密钥库的口令短语： yourCompany:yourPassword
输入 yourProj 的密钥口令： yourCompany:Kouling
  正在添加： META-INF/YOURPROJ.SF
  正在添加： META-INF/YOURPROJ.DSA
  正在添加： org/
  正在添加： org/apache/
  正在添加： org/apache/commons/
  正在添加： org/apache/commons/logging/
  正在添加： org/apache/commons/logging/impl/
。。。
。。。
接着输入：
D:\yourProj\webroot\app>jarsigner -verbose -certs yourCompany-app-v1.0.1.jar yourProj
屏幕提示：
输入密钥库的口令短语： yourCompany:yourPassword
输入 yourProj 的密钥口令： yourCompany:Kouling
  正在添加： META-INF/YOURPROJ.SF
  正在添加： META-INF/YOURPROJ.DSA
  正在添加： org/
注意：重要签名给yourCompany-app-v1.0.1.jar文件，但它使用了另外的几个commonsxxxx包，也要签名，否则将来使用时会提示签名不一致的错误！
4。打开jar包文件的 META-INF目录可以看到
yourProj.SF
yourProj.DSA
以及被扩充的MANIFEST.MF文件
表明已经加入了签名文件
[完毕]
[演示图片]
1。签名文件

2。实际运行时的签名提示图和时效[谢绝转载，如有刊登请email联系[email protected]]

Continue reading JAVA JNLP组件数字签名制作步骤

注本文版权由文章原作者所有，如果作者认为本转载侵犯了原作者的权利，请与管理员联系 [email protected]

浅谈改进数据库应用系统性能的常用策略
陆兆洁  南宁经济信息中心

摘要：本文主要简述了改进数据库应用系统性能的常用策略，并从系统层次架构角度分别介绍了在不同领域所采用的方法，本文的侧重点放在解决问题的方法论上，期待能够达到抛砖引玉之效。

1  引言

数据交互复杂度与频度的提升，导致了数据库在运维、迁移和规模扩展进程中的性能问题。作为一项确保企业IT基础部件健康运营的关键技术，数据库性能优化的实现路径和IT系统管理架构越来越密不可分。

在数据库成熟应用的时代，数据库的性能优化已经演变为一项相当严密的系统工程。作为企业IT基础设施的核心部件之一，数据库并不是孤立的系统，它与网络、操作系统、存储等硬件系统紧密相连，这种与其他IT部件的多重连接特性决定了数据库性能优化是一门综合技术。

2  数据库应用系统性能的优化

完整的数据库性能优化周期可以分为两个阶段，一是设计与开发阶段，主要负责对数据库逻辑和物理结构的优化设计，使其在满足具体业务需求的前提下，系统性能达到最佳，同时系统开销最小；二是数据库的运行阶段，其优化手段以数据库级、操作系统级、网络级为主。

2.1  数据库的设计和开发阶段

数据库性能下降很大一部分的风险是能够在数据库的设计阶段予以规避的。因此，设计优化也就成为了数据库性能优化技术的源头和方向。由于数据库逻辑结构的不合理、索引设计不合理，开发阶段的技术冲突无法调适，多种因素的累积作用导致了许多数据库系统上线后不久即出现性能故障的案例不在少数。比较生命周期的调优成本与调优收益曲线，性能调优的成本随软件生命周期进程而增加，但调优收益却随软件生命周期进程而减少。在该阶段的具体实现上一般表现为某一类数据库,其性能的改进主要体现在逻辑设计和物理设计上。

2.1.1  数据库的逻辑设计

数据库的逻辑结构是由一些数据库对象组成，如数据库表空间、表、索引、段、视图、存储过程、触发器等。数据库的逻辑存储结构(表空间等)决定了数据库的物理空间是如何被使用的，数据库对象如表、索引等分布在各个表空间中。

数据库的逻辑配置对数据库性能有很大的影响,因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。

数据库逻辑设计的结果应当符合下面的准则摘要：

（1）把以同样方式使用的段类型存储在一起；

（2）按照标准使用来设计系统；

（3）存在用于例外的分离区域；

（4）最小化表空间冲突；

（5）将数据字典分离。

逻辑结构优化用通俗的话来说就是通过增加、减少或调整逻辑结构来提高应用的效率，可以从以下几个方面来精练数据库的逻辑设计:

1、基本表扩展

数据库性能包括存储空间需求量的大小和查询响应时间的长短两个方面。为了优化数据库性能，需要对数据库中的表进行规范化。一般来说，逻辑数据库设计满足第三范式的表结构轻易维护且基本满足实际应用的要求。所以，实际应用中一般都按照第三范式的标准进行规范化，从而保证了数据库的一致性和完整性，设计人员往往会设计过多的表间关联，以尽可能地降低数据冗余。但在实际应用中这种做法有时不利于系统运行性能的优化:如过程从多表获取数据时引发大量的连接操作，在需要部分数据时要扫描整个表等，这都消耗了磁盘的I/O和CPU时间。

为解决这一问题，在设计表时应同时考虑对某些表进行反规范化，方法有以下几种:一是分割表。分割表可分为水平分割表和垂直分割表两种:水平分割是按照行将一个表分割为多个表，这可以提高每个表的查询速度，但查询、更新时要选择不同的表，统计时要汇总多个表，因此应用程序会更复杂。垂直分割是对于一个列很多的表，若某些列的访问频率远远高于其它列，就可以将主键和这些列作为一个表，将主键和其它列作为另外一个表。通过减少列的宽度，增加了每个数据页的行数，一次I/O就可以扫描更多的行，从而提高了访问每一个表的速度。但是由于造成了多表连接，所以应该在同时查询或更新不同分割表中的列的情况比较少的情况下使用。二是保留冗余列。当两个或多个表在查询中经常需要连接时，可以在其中一个表上增加若干冗余的列，以避免表之间的连接过于频繁，一般在冗余列的数据不经常变动的情况下使用。三是增加派生列。派生列是由表中的其它多个列的计算所得，增加派生列可以减少统计运算，在数据汇总时可以大大缩短运算时间。

因此，在数据库的设计中，数据应当按两种类别进行组织:频繁访问的数据和频繁修改的数据。对于频繁访问但是不频繁修改的数据，内部设计应当物理不规范化。对于频繁修改但并不频繁访问的数据，内部设计应当物理规范化。有时还需将规范化的表作为逻辑数据库设计的基础，然后再根据整个应用系统的需要，物理地非规范化数据。规范与反规范都是建立在实际的操作基础之上的约束，脱离了实际两者都没有意义。只有把两者合理地结合在一起，才能相互补充，发挥各自的优点。

2、索引的建立

创建索引是提高检索效率最有效的方法之一，索引把表中的逻辑值映射到安全的RowID，能快速定位数据的物理地址，可以大大加快数据库的查询速度，一个建有合理索引的数据库应用系统可能比一个没有建立索引的数据库应用系统效率高几十倍，但并不是索引越多越好，在那些经常需要修改的数据列上建立索引，将导致索引B*树的不断重组，造成系统性能的下降和存储空间的浪费。对于一个大型表建立的索引，有时并不能改善数据查询速度，反而会影响整个数据库的性能。这主要是和SGA的数据治理方式有关，Oracle在进行数据块高速缓存治理时，索引数据比普通数据具有更高的驻留权限，在进行空间竞争时，Oracle会先移出普通数据，对建有索引的大型表进行数据查询时，索引数据可能会用完所有的数据块缓存空间，Oracle不得不频繁地进行磁盘读写来获取数据，所以，在对一个大型表进行分区之后，可以根据相应的分区建立分区索引。

2.1.2  数据库的物理设计

数据库物理设计需要对时间效率、空间效率、维护代价和各种用户要求进行权衡,结果会产生多种方案,必须对此进行细致评价,选择一个较优的方案作为数据库的物理结构。

数据库的数据最终是存储在物理磁盘上的，对数据进行访问就是对这些物理磁盘进行读写，因此对于这些物理存储的优化是系统优化的一个重要部分。对于物理存储结构优化，主要是合理地分配逻辑结构的物理存储地址，这样虽不能减少对物理存储的读写次数，但却可以使这些读写尽量并行，减少磁盘读写竞争，从而提高效率，也可以通过对物理存储进行精密的计算减少不必要的物理存储结构扩充，从而提高系统利用率。

为了避免数据库文件之间的竞争，在物理设计时，文件应该被放到不同的I／O通道，跨越驱动器的文件分离，避免磁盘争用成为一个“瓶颈”。主要应该注意以下几点技巧：把关键数据文件分布在各个可用的磁盘上，这些文件包括表空间、回滚段或UNDO段、联机重做日志文件、操作系统盘、经常访问的表的数据文件以及经常访问的索引的数据文件；把数据和索引文件分开放置；对于经常连接的表，把它们的数据和索引表空间分开，这样每个表上的信息就不会放在相同的磁盘上；把控制文件的多个备份存储到不同的磁盘和控制器上，以最终实现操作并行化。

同时，还应将表数据和索引数据分开表空间存储，分别使用独立的表空间。因为假如将表数据和索引数据放在一起，表数据的I/O操作和索引的I/O操作将产生影响系统性能的I/O竞争，降低系统的响应效率。将表数据和索引数据存放在不同的表空间中，并在物理层面将这两个表空间的数据文件放在不同的物理磁盘上，就可以避免这种竞争了。

2.2  数据库的运行阶段

数据库的运行管理主要通过对数据库运行环境进行调整来达到改进性能的目的。在决定进行系统性能调优级时,首先应制定一个完善的调优级方案,先监控系统并分析问题所在,然后根据分析结果每次调整一个参数,再进一步监控系统查看系统性能有无变化,然后做进一步调节。其中有一个重要的原则:每次最好只调节一个参数。

2.2.1  数据库级参数性能调优

一般来说，数据库管理系统(DBMS)中与性能相关的参数都与对系统物理内存的设置有关，换言之，数据库级参数性能优化即是DBMS对系统内存的配置。通常，只要将这些主要参数设置好就会显著改善数据库系统的性能，因此，配置好数据库系统参数，是优化数据库系统运行环境的关键。

数据库管理系统对系统内存的配置应尽可能实现如下目标：

一是减少分页:当系统执行分页时，会将当前没有使用的信息从内存移到硬盘上。这样就可以为当前需要内存的程序分配内存。如果频繁地发生分页，系统性能就会严重降低，从而导致很多程序的执行时间变长。

二是减少内存交换：当系统执行内存交换时，会将活动进程临时地从内存移到硬盘上，这样另一个活动进程就可以得到所需要的内存。内存交换基于系统循环时间。如果内存交换过于频繁，就会产生大量的磁盘I/O，应用的性能可能会急剧恶化。

三是扩大高速数据存储内存缓冲区容量：用户的进程对这个内存区发送事务，并且以这里作为高速缓存读取命中的数据，以实现加速的目的。主要包括数据块缓冲、数据字典缓冲、恢复回滚日志缓冲以及SQL共享池等这几个部分摘要。对这些内存缓冲区的合理设置，可以大大加快数据查询速度，提高内存区的命中率。

2.2.2  操作系统级参数性能调优

(1)进行定期的磁盘检查和磁盘空间清理,当系统运行一段时间后,会出现一定的文件错误和磁盘碎片,此时就需要进行磁盘整理。

(2)自动关闭停止响应的程序,无须进行手工干预。

(3)调整应用程序优先级,让常用程序拥有较高的优先权,自然运行速度就会快些。

(4)配置操作系统核心使用更少的内存。

(5)配置操作系统与DBMS相关的内核参数以便将更多的系统内存留给DBMS使用。

2.2.3  网络级参数性能调优

网络带宽会影响系统性能，减少网络负载，可以改善系统的性能。

负载均衡将是大型应用高负荷访问和大量并发请求采用的终极解决办法,它提供了一种有效的方法来扩充服务器带宽,增加吞吐量,提高网络的灵活性和可用性。

对负载均衡的应用,可以从网络的不同层次入手,具体情况要看瓶颈所在,不外乎从传输链路聚合、采用更高层网络交换技术和设置服务器集群策略三个角度实现,一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建集群,这样的架构成本低、性能高还有很强的扩张性,随时往架构里面增减节点都非常容易。

3  结束语

在应用丛生、高度分布式的环境中，要总结出一套“放之四海皆准”的数据库性能优化方法论并不容易。但结合企业自身特色的性能优化流程却是有据可循的。同时，数据库性能优化方法还具有浓重的行业色彩。

在对数据库应用系统改进所采取的策略中,前面提到的每个方法可能都会被用到,本文介绍得比较粗浅,具体实现过程中很多细节还需要慢慢熟悉和体会,有时一个很小的参数设置,对于系统性能的影响就会很大,在此仅概而述之,以期达到抛砖引玉之效

Continue reading 【转】浅谈改进数据库应用系统性能的常用策略

            Web前端在移动                    

Web前端的起源

Web应用诞生：随着GMail、 Google Map等优秀Web应用出现，Ajax在2004年之后一度成为热门话题。经过几年的发展，一批以Prototype、Dojo、Ext为首的 Ajax+UI的浏览器兼容框架不断出现。UI和Web中间新增了一层以Javascript为核心，专门处理数据传输、Web交互等内容的开发 层，Web前端。Web前端伴随Web应用而诞生，并逐步走来。

Web宿主之争：随着RESTful Web Service潮流的发展，后台服务也迅速实现了数据云端化，接口API化。但受IE垄断和发展缓慢的影响，Web前端始终走不出浏览器能力不足和兼容性 问题突出的困局。开发维护浏览器插件、Flash控件等更是无奈的选择。Web前端往往因为需要兼容IE6、IE7、FF、有无插件、有无Flash等情 况付出巨大开发代价。2006年，John Resig的jQuery框架从某个意义上解决了这个问题。我认为最大的突破在于让老旧浏览器适配新的Web标准，满足了开发者开发高效而兼容老旧浏览器 的需要。

Web标准化之路：Google 在 2008年推出了Webkit核心的浏览器Chrome（后来也发布了ChromeOS）。随着FireFox，Chrome，Safari，Opera 等浏览器开始对HTML5和CSS3的深入支持以及性能的不断优化，IE市场占有率的持续下滑。Web标准化终于等到了一个发展机遇。2010 年，HTML5和CSS3被Webkit核心的Chrome、Safari绚丽地实现后，IE9也表示全面支持HTML5后。Web标准进入一个高速发展 阶段。随后，浏览器GPU加速也浏览器厂商们所接受。在Web标准化、离线化、硬件化的浪潮中，Web应用逐渐具备了替代桌面应用条件和能力。Web前端 开发也在逐步取代桌面应用客户端开发。

移动Web应用背景

非智能机时代：Java和WAP是取代短信SP后的第一种移动互联网实现方式。这个年代虽然荒蛮，但很纯真。

前智能机时代：HP 把一台WinPPC 的PAD增加电话功能，做成第一台智能手机时。Windows Mobile和S60是这个时代的主角。基于手机系统的客户端应用就是移动互联网应用的最好形式。但是随着系统版本的不断升级，设备的差异不断增大。手机 客户端应用开发同样面临着与Web前端开发一样的兼容性开发效率和维护成本问题。

后智能机时代：随着iPhone和 Android(HTC、摩托罗拉、三星等)手机等的热卖，两个电子市场生态链逐步形成。再加上最近诺基亚和微软和合作，电子市场生态链之争拉开帷幕。客 户端应用成为了电子市场生态链的主角。不过随着三方系统的竞争升级，也伴随浏览器的不断优化。先不论WP7，iPhone和Android阵营的浏览器都 是webkit核心的，差异只在于硬件加速能力和设备资源的差异。这恰好也是移动Web应用的发展机遇。

移动Web应用开发

需求：

互联网是个产品线丰富的产业，但不可能对所有产品都投入巨大开发成本。WAP能满足基本使用需求，而客户端应用满足主线产品的高端需求。还有一大片中高端需求无法很好满足。遗憾的是，限于开发成本，用户没有与其高端设备相匹配的非主线产品客户端可用。

开发成本无法避免，但可以择优。我们可以通过移动Web应用的方式来次优替代非主线产品客户端。这也是廉价的移动应用实现方式。

现状：

目前iOS和Android系统的浏览器都是webkit核心的，我们可以开发移动Web应用来满足这块需求。iOS支持硬件加 速，Android系统也能满足基本Webkit的API功能，适宜通过区分iOS来提供差异化服务。iOS的Mobile Safari有足够能力提供webkitTransForm（图形变换，3D变换支持硬件加速）、webkitTransition（CSS3动画）、 SQLite、LocalStorage（离线存储）、 WebSocket（iOS 4.2+）服务。至于Android，因为需要兼容参差的低端设备，还是不建议使用复杂图形变换和CSS3动画，其它能力可以通过判断能否支持来选择使 用。另外多点触摸、重力感应、地理位置还是根据能否支持和需要来使用，主要用于优化用户体验，不影响基本交互方式。

未来：

移动Web应用的起点比PC Web应用的高，但适用范围较窄。但移动Web应用将成为Web应用的一种延伸，从开发角度来看，应该是殊途同归的。

小结

Javascript的角色从诞生起的页面粘合剂转变成今天的Web应用开发语言，一路走来经过很多波折。有人喜欢他，有人讨厌他，在崇拜和谩 骂中成长过来。将来的路还很长，但迷雾已散去，前途是光明的。当中有无数人的付出汗水，也成就了少数应用的辉煌。不过他仍然是一个工具，为开发者服务，需 要人们一起来优化他，使用他。

Continue reading 【转】Web前端在移动