June 2008 Archives

Oracle的DataGuard技术有三种实现模式，分别是max performance、max availability、max protection这三种模式。

以下是来自Oracle文档的摘要信息：
In some situations, a business cannot afford to lose data. In other situations, the availability of the database may be more important than the loss of data. Some applications require maximum database performance and can tolerate some small amount of data loss. The following descriptions summarize the three distinct modes of data protection.

Maximum protection This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits. To ensure data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to the standby redo log of at least one transactionally consistent standby database.

Maximum availability This protection mode provides the highest level of data protection that is possible without compromising the availability of the primary database. Like maximum protection mode, a transaction will not commit until the redo needed to recover that transaction is written to the local online redo log and to the standby redo log of at least one transactionally consistent standby database. Unlike maximum protection mode, the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database operates in maximum performance mode until the fault is corrected, and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode.

This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.

Maximum performance This protection mode (the default) provides the highest level of data protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database's redo data stream is also written to at least one standby database, but that redo stream is written asynchronously with respect to the transactions that create the redo data.

When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database performance.

The maximum protection and maximum availability modes require that standby redo log files are configured on at least one standby database in the configuration. All three protection modes require that specific log transport attributes be specified on the LOG_ARCHIVE_DEST_n initialization parameter to send redo data to at least one standby database. See Section 5.6 for complete information about the data protection modes.

以下是对以上摘要信息的翻译信息：

在一些情况下，业务不允许丢失数据。在另外一些情况下，数据库的可用性比丢失数据更为重要。一些应用需要最强的数据库性能并且能容忍丢失少量的数据。下面的描述概述了三种不同的数据保护模式。

最大保护模式 -- 这种保护模式确保如果主数据库故障不会发生数据丢失。要提供这种级别的保护，恢复每个事务所需的重做数据必须在事务提交之前同时写到本地联机重做日志和至少一个备数据库上的备重做日志。要确保不发生数据丢失，如果故障导致主数据库无法写重做流到至少一个事务一致性备数据库的备重做日志时，主数据库会关闭。

最大可用性模式 -- 这种保护模式提供了可能的最高级别的数据保护，而不用与主数据库的可用性相折衷。与最大保护模式相同，在恢复事务所需的重做写到本地联机重做日志和至少一个事务一致性备数据库上的备重做日志之前，事务将不会提交。与最大保护模式不同的是，如果故障导致主数据库无法写重做流到异地备重做日志时，主数据库不会关闭。替代地，主数据库以最大性能模式运行直到故障消除，并且解决所有重做日志文件中的中断。当所有中断解决之后，主数据库自动继续以最大可用性模式运行。

这种模式确保如果主数据库故障，但是只有当第二次故障没有阻止完整的重做数据集从主数据库发送到至少一个备数据库时，不发生数据丢失。

最大性能模式 -- 这种保护模式（默认）提供了可能的最高级别的数据保护，而不影响主数据库的性能。这是通过允许事务在恢复该事务所需重做数据在写到本地联机重做日志后立即提交而实现的。主数据库的重做数据流也写到至少一个备数据库，但是那个重做流相对于创建重做数据的事务是异步写的。

当所用的网络连接有足够的带宽，这种模式提供了近似于最大可用性模式的数据保护级别，并且对主数据库性能的影响最小。
最大保护和最大可用性模式需要备重做日志文件配置在配置中的至少一个备数据库上。所有三种保护模式需要在LOG_ARCHIVE_DEST_n 初始化参数上指定特定的日志传输属性以发送重做数据到至少一个备数据库。查看5.6 节以获得数据保护模式的完整信息。

Pvid是aix系统中的ODM LVM用于识别PV的序列号，操作系统通过pvid来识别pv，就好像我们每个人的ID card。

当pv被添加到系统中之后，可以通过两种方式生成pvid

1，cfgmgr -v
2，lspv 如果没有PVID的话，执行chdev -l hdiskn -a pv=yes

也就是说当系统可以识别硬盘 并将硬盘认可为pv（即lvm的组件）的时候。系统就分配了pvid给硬盘，系统的odm库中保存有pvid。
Pvid的生成原则是 主板序列号＋形成pv时候的时间戳，pvid除了写入odm库，在硬盘头信息里（0扇区的头几个字节）以及VGDA 也将写入pvid

To make a disk into a physical volume, the PVID is placed onto the disk. ThePVID is an combination of the machine's serial number (from the systems EPROMs) and the date the PVID was generated. This combination ensures the extremely low chance of PVIDs being duplicated. When the system is booted, the disk configurator looks at the PVID residing on the disk and compares it with an entry in the ODM. If an entry is found, then the disk is given the hdiskx number in the ODM that is associated with the PVID. If there is no matching entry, then the next name in the pool of 'free' hdisk names is allocated to the physical volume.

可以通过 lquerypv -H hdisk0查看pv上的pvid

ibm150:[/]#lquerypv -H /dev/hdisk0
000af70de396426b0000000000000000
ibm150:[/]#lspv
hdisk0 000af70de396426b datavg
hdisk1 000af70d5c816fc2 rootvg
hdisk2 000af70d4d50358c rootvg

可以看到三个pv的pvid前几位数字是相同的（即主板序列号），后几位数字是不同的。

可以通过以下方法修改pvid
chdev -l hdisk1 -a pv=clear 清除pv 磁盘头的pvid
chdev -l hdisk1 -a pv=yes 重新定义pvid

如果pv已经加入卷组，首先还得先varyoffvg ，exportvg
执行以上步骤，pv的pvid将会改变。这里修改的只是磁盘头的pvid，并没有修改vgda中的pvid

当pv已经是一个卷组的成员时，切记不要随便修改pvid

因为当pv加入一个卷组的时候，pvid将被写入vgda，如果你擅自修改卷组的pvid，然后新生成的pvid将不能和卷组vgda中的pvid相匹配，这样就无法importvg，就无法varyonvg，很有可能就会丢失数据！

当importvg的时候，odm将读取pv上的vgda，如果vgda上pvid与自身磁盘上的pvid不符合的话，将出现错误！

注意：当pv加入卷组以后，pvid在硬盘上存在于至少两个地方，一个是在硬盘头，一个是在vgda中。这两个地方的pvid一般是相同的，但是由于pvid的修改，可能造成不一致，这样就有可能丢失数据。

你可以通过
#lqueryvg -Atp hdisk0 查看pv vgda中的pvid

ibm150:[/]#lqueryvg -Atp hdisk0
Max LVs: 256
PP Size: 25
Free PPs: 85
LV count: 3
PV count: 1
Total VGDAs: 2
Conc Allowed 0
MAX PPs per 1016
MAX PVs: 32
Conc Autovar 0
Varied on Co 0
Logical: 000af70d00004c0000000106e3964781.1 loglv00 1
000af70d00004c0000000106e3964781.2 lv00 1
000af70d00004c0000000106e3964781.3 lv02 1
Physical: 000af70de396426b 2 0
Total PPs: 542
LTG size: 128
HOT SPARE: 0
AUTO SYNC: 0
VG PERMISSIO 0

2.检查硬盘上VGDA 区的信息，从中得到有关逻辑卷的名称及定义：
如：

#lqueryvg -Atp hdisk2
Max LVs: ------256
PP Size: ------26
Free PPs: -----538
LV count: -----2
PV count: -----1
Total VGDAs: --2
Conc Allowed --0
MAX PPs per ---1016
MAX PVs: ------32
Conc Autovar --0
Varied on Co --0
Logical: ------0003f62a00004c00000000f52f1737c5.1 --datalv1 1
---------------0003f62a00004c00000000f52f1737c5.2 --datalv2 1
Physical: -----0003f62a2f135f0e --------------2 ----0
Total PPs: ----542
LTG size: -----128
HOT SPARE: ----0
AUTO SYNC: ----0
VG PERMISSIO --0

如：

#vi /tmp/lvname
datalv1:datalv1
datalv2:datalv2

4. 在硬盘上重新创建卷组，保留原有卷组的数据结构。

#recreatevg -y vgname -l lv_file hdisk_name...
如：
#recreatevg -y testvg -l /tmp/lvname hdisk2

5. 如果卷组上有文件系统，还需修改 /etc/filesystems ，使对应的文件系统的加载点与原来的一致。首先修改/etc/filesystems文件，不行的话就执行下面的步骤
或者：

如果在重新import后，发现mountpoint不同，可以通过smitty chlv修改lv属性，即修改Logical volume LABEL，使之与mount point相同。

为什么要修改/etc/filesystem呢？

recreatevg 后，系统自动创建了目录/fs，所有的文件系统加载到了/fs下，原来的mountpoint是以/为基准的.

来源链接：
http://blog.chinaunix.net/u1/39140/showart_304297.html

Oracle兔死狗烹？　　文/《知识经济》记者 辛云勇

　　2004年7月19日，中国上海，Oracle大中华区董事总经理陆纯初带着他的新高管班子集体亮相于Oracle World会场。对于陆纯初治下的Oracle中国公司来说，这是一次集体兴奋。

　　不过，更需要陆纯初面对的是，Oracle中国公司的问题并没有因此而平息下来，人事变动只是其中一环，更致命的问题在于Oracle中国公司盲目举起直销大旗，多少有兔死狗烹之嫌。尽管陆纯初并不否认合作伙伴过去在Oracle中国发展中的作用，但这仅仅是过去。

　　"我们现在连鸡肋都不如！"依着Oracle这棵大树做了两年代理的陈昆，已经开始考虑下一步的走向。

　　"鸡肋丢掉的话，人家还会有些可惜。对于Oracle和我们，应该是到了双方信任难关的时候。"陈昆的话极具代表性，这个信任，在陈看来，其中包括商业道德的成分。

　　变革本无可厚非。讲究流程和注重严明纪律的陆纯初这一次入主Oracle中国公司靠走胡伯林、张书恒等之后，开始从渠道入手，清理门户，充分展示了陆式铁腕手段。其"猛药下沉疴，快刀斩乱麻"的外科手术打法，有如2003年的美国对伊拉克战争，看起来干净利索，最后结果如何还有待考量。

　　毕竟，从根本上忽视合作伙伴和客户利益的行为是商业大忌。而这种商业大忌，在过去的10多年里，不断在Oracle中国公司的合作史中上演。

　　美的Oracle往事

　　对于张伟来说，1997年进入美的集团是个机会。在这之前，张伟曾在武汉做过一段时间的市场策划，初来到美的也是做跟策划相关的工作。 1996年，美的集团已经确定上线Oracle的系统管理软件，当时ERP的概念还不普及，更多的处于MRP‖阶段。张伟"没想到自己会被抽调到关键用户的岗位"，并由此开始了IT咨询顾问的职业生涯。

　　"现在中国做IT咨询资历比较老的人多数是从美的、华为出来的。"----华为跟美的一样，是Oracle在中国的早期客户。1999年，从美的电脑部脱胎而来的美的信息科技有限公司成立，汉普、汉得等一批如今久负盛名的IT咨询公司刚成立不久。

　　"那时候的汉普是个空架子，除了张后启，没有什么人拿得出手。"而汉普、汉得都是依着Oracle起家，没有客户实施经验是它们的硬伤，"包括当年的普华永道。"于是，美的仍在进行Oracle系统上线的时候，美的实施队伍和关键用户就开始有人被不断挖走，这在1999年美的信息成立的时候达到高潮。

　　"美的100多人的参与队伍，那时候在这些咨询公司看来，是一个现成的金矿。"也是从美的出来，现为某IT咨询公司首席咨询顾问的李宽对几年前业内的这场"挖人运动"仍记忆犹新。

　　美的、华为被挖走的实施人员和关键用户，多数流入到了中国新近兴起的IT咨询界，

　　这些早期的Oracle用户也因此帮助Oracle一度占领了中国企业级应用软件的高端市场。

　　李宽认为，"2000年前后，Oracle在中国市场的火爆很大程度上归功于美的信息、汉普、汉得这些合作伙伴。"这正值SAP在中国蛰伏4、5年后力推其"灯塔计划"的时候，当时SAP更多是携IBM、德勤等这些国际咨询界巨头在中国打单，而Oracle与中国本土咨询伙伴联合起来，使得SAP的"灯塔计划"经常被搅和。其中包括哈药和长虹等单子。

　　2001年，美的信息改名赛意信息。这一年，美的Oracle系统的一期实施已基本完成，之前参与这一项目的实施人员和关键用户都编入了赛意。赛意由此开始了Oracle的渠道角色，并一直持续到现在。

　　"这一年，也是赛意人走得最多的一年。原来美的那一批人由于待遇等问题在这个时候几乎流失殆尽。" 张伟也是在2001年被一家上线Oracle系统的港资企业挖走，做了内部顾问。今年初，张伟跳到广州科森信息科技公司，再次成为IT咨询顾问。"在科森，也有不少从美的出来的人，其中包括目前科森的3个首席顾问和我们现在一个项目的顾问经理。"

　　赛意头上的美的光环随着顾问的流失而逐渐暗淡，加上其市场操作能力的欠缺，Oracle开始将注意力转向扶持其他的合作伙伴，赛意就此沦为一家区域性的二流系统集成商。

　　伙伴的非Oracle逻辑

　　对于自己已经脱离近两年的汉普生涯，如今专做瑞典某家系统软件代理的林小兵不愿多说。但谈起Oracle以及当年的"鲲鹏计划"，他明显开始激动。

　　"除了张后启等人的原因，汉普的起身和衰落，Oracle是一大因素。"自从离开汉普之后，林小兵发誓再也不接触Oracle。

　　张后启在1997年靠3万块钱创立了汉普，自1999年从美的大规模的挖来咨询顾问，有了较强的实施队伍后，汉普在之后的两年"签单都快签疯了"，"随着单子越来越多，汉普咨询顾问的缺乏越来越成为一个问题。"这两年，林小兵南上北下，"连自己的生日都漏了两次。"

　　顾问的工资是咨询公司最大的一笔支出。没有顾问，空有单子的局面让张后启开始心头焦虑起来，最简便的方法就是去找投资。2001年底，联想集团将现金港币5500万元及联想现有IT咨询业务注入汉普，并获得汉普的51%权益。这之后，一直到近期联想卖掉包括原汉普在内的IT服务部门的几年间，汉普改名叫联想汉普。

　　一年后的2002年11月25日，Sun公司中国公司总经理薛耀琨、时任Oracle中国区总经理胡伯林和联想集团高级副总裁俞兵共同在北京启动战略联盟，也就是所谓的"鲲鹏计划"。其中，负责Oracle系统咨询服务的就是联想汉普。

　　当时的Oracle正励精图治，不遗余力推广其渠道策略，打造中国Oracle系，以正面挑战SAP在中国中小企业市场的推广。

　　组建之初，"梦之队"便发出豪言："我们想卖的不是十套八套，而是几十套上百套。"而半年后，事实结果恰恰是他们不想卖的"十套八套"。

　　那时候，林小兵也到了现场。他今日看来，"鲲鹏计划""有如一场闹剧。"

　　一年前也是从汉普出来的张凯峰，现在上海自称是"无业游民"，实则做着行业内普遍可见的独立顾问。在这之前，张已经是有4年资历的老汉普人。

　　对于"鲲鹏计划"，张凯峰的批评直指Oracle。"Oracle对中小企业市场没有战略考虑，更大程度上是一种投机活动，其业务逻辑和管理方式明显不切合中国市场需求。这是'鲲鹏计划'进展不利的重要原因。"

　　Oracle在与联想合作之初，曾经承诺针对中国的中小企业开发个性化产品，但实际上没有做到，只是将其标准版产品做了重新包装，换汤不换药。所谓的电子商务套件特别版，"其实也就是价格特别一些而已"。

　　最要命的是，其产品研发团队都不在中国，而是在新加坡，用的是印度工程师，根本不了解中国客户的需求。而且在实际运作过程中，Oracle 也不愿意做出改变。

　　林小兵曾经做过一个中小企业单子，该企业需要的一些报表，Oracle不愿意提供。联想汉普出面交涉也没有结果，"Oracle会直接告诉你，如果需要的话，必须另外购买。"

　　事实上，联想汉普打下不少单子，但最后多是因为客户发现产品不过关。为了不失去客户，汉普只能重推标准版，甚至更换其他厂商的产品。

　　在市场策略方面，Oracle也表现得急功近利。Oracle 曾经声称将和联想汉普一起加强对二级渠道的培养，这一承诺也未履行。"他们并没有培养渠道，而只是在年底跟联想要单。"这和其他公司对中国市场的潜心经营和长远战略大相径庭。整个"鲲鹏计划"的运作过程，Oracle 所做的只是对其产品的简单价格调整和一些流于表面的市场宣传推广，追求短期利润而毫无长远打算。

　　而这段时间的联想汉普，"几乎是将全力放在了'鲲鹏计划'中"，"深陷其中的同时，也是中国IT咨询发展最快的时候，其他的IT咨询公司开始超过汉普，迅速崛起。尤其是那些专做SAP代理的咨询公司。"张凯峰认为，从时间上来看，"鲲鹏计划"是汉普历史上开始走下坡路的一个转折点。

　　从这之后，汉普开始考虑自己的伙伴选择，采取"骑墙战略"，同时启动Oracle、SAP两条业务线。

　　"现在看来，汉普自那以后，业务重心越来越倾斜于SAP。"林小兵更是认为，包括汉得在内的Oracle传统合作伙伴已经不会继续把核心资源投放在Oracle这里了。

　　过河拆桥导致志杰之死

　　志杰曾经是Oracle在中国最大的合作伙伴。

　　这家名为美国实为香港背景的管理咨询公司，很早的时候就与Oracle捆绑在一起。借Oracle在港台地区、日本和新加坡等地的风头先行进入中国大陆港台背景的企业。

　　"很多港台企业应用Oracle系统，这也影响到它们在大陆的工厂。"张伟从美的出来后，就曾进了一家港资企业做Oracle实施。

　　"Oracle在中国大陆之外的亚洲地区特别是日本、港台区域要比SAP卖得好，从这一点上来看，今年Oracle中国公司的高层变化也可以理解。"

　　事实上，Oracle尤其是其企业应用软件进入中国大陆市场也是先从港、台资企业入手的。在中国本土企业市场上，直到做下华为、美的这两个单子，并借助这两家近乎集体跳槽的实施人员和关键用户的推波助澜，Oracle才开始在中国市场上风生水起。

　　志杰早期的咨询顾问多来自香港，工资要比中国大陆本土的咨询公司高出很多。跟随Oracle中国市场的开拓节奏，志杰的顾问队伍急需补充。

　　1999年到2000年，志杰以比汉普、汉得等Oracle其他伙伴高出很多的工资挖到了不少美的、华为出来的顾问，其规模急剧膨胀，就此成为Oracle在中国最大的合作伙伴。

　　而与之相随的是志杰人力成本的迅速窜升，与其他咨询公司相比，在很长一段时间内，志杰都得面对高居不下的工资支出压力。

　　"那时候的志杰也享受了Oracle排他性条款的待遇，与Oracle的关系一度亲密无间。"尽管在志杰的时间不长，黎轶超说起志杰辉煌的时候仍难以掩饰其脸上的兴奋。"可以说，在Oracle的合作伙伴中，这段时间的志杰是做得最好的。"

　　但两年后的2002年底，业内突然传出志杰"将死"的消息。

　　"不是业务的问题，也不能说是市场的问题，直接原因在于现金流突然短路。" 黎轶超和他的同事们都感到突然，"开始的时候甚至有点不太相信。"

　　在这之前，从2002年6月到11月，5个月时间里志杰就签下了1800万的合同额。而在同年6月份的"Oracle World 2002北京"大会上，作为Oracle重要合作伙伴，志杰在会场上风光无限。Oracle明确表示对中国的渠道合作伙伴，将在三个方面更多地予以支持，以提高伙伴能力：一、提高支持、服务的能力；二、扩大营销范围；三、增进伙伴特长。此外还要从资金上给重要伙伴以支持。

　　黎轶超们相信，就算志杰股东们不伸手解决当前问题，Oracle也不会坐视不管。"而且也就是200万的现金流问题。"

　　但最后的结果是，Oracle跟志杰股东们一样，"好像一夜之间不看好志杰似的，对志杰的突然死亡不闻不问。"

　　"后来我们才想到，这对Oracle来说，不会有什么损失。志杰签下的单子几乎都是跟Oracle相关的，不会因为志杰死了这些单子就飞了。" 黎轶超直到现在也难以接受这种Oracle似的冷漠。

　　分包制与oracle腐败

　　2001年，胡柏林率领下的Oracle中国公司在中国市场掀起声势浩大的渠道建设运动。"从某种程度上来说，Oracle的渠道之乱也是从这个时候开始的。" Oracle某长期合作伙伴老板这样认为。

　　也就在这一年，做Oracle代理的门槛突然全线降低，汉普、志杰等传统合作伙伴享受的排他性条款也就此作废，往日的优越感开始逐步被吞噬。

　　"那个时候，你会突然发现，做Oracle的代理原来可以这么简单，几个人找点关系就可以拿下Oracle代理商的资格。"有一天，张伟发现在他看来根本不懂什么叫ERP的一个人也做Oracle代理的时候，他开始有点迷茫。"这给中国IT咨询界造成了很大冲击。"

　　事实上，那些没做过IT咨询的人之所以敢做Oracle的代理，在于管理软件界普遍可见的分包制。

　　也就是说，只要你有关系，能跟Oracle的销售人员接上头，拿下一个单子，你可以不用自己去实施，只要能找到那些有实施能力但没有关系的小公司，或者临时拼凑起一个实施团队，一般来说，你就只要在中间等着分钱就行了。

　　"一个200万的单子，如果是在这种分包制下完成的话，客户可能只能得到50万的实际价值。"一位原来做Oracle代理的人士告诉记者，"这在Oracle一些中小渠道商里面很普遍。"

　　更有甚者，有些单子是层层分包下去的，但最后到企业客户那里实施的时候，都可以打着Oracle实施顾问的旗号。

　　2001年，香港电讯盈科成为Oracle中国移动这个单子的总包头。尽管电讯盈科在电信行业有着丰富的运营经验，但"事实上，那时候它在系统集成上根本就不强。"这也是中国移动成为Oracle中国失败第一单的源头理由。

　　电讯盈科取得总包资格后，开始往下游系统集成商分包。"科森也是在这个时候成立的。"当时的科森只有香港老板几个人，"因为都是香港人，可能是跟电讯盈科高层关系比较好"，拿到了分包资格，这也是科森起家的起点。

　　而更多的分包商则采取了层层分包的方式，到最后，中国移动这个单子连电讯盈科都说清楚到底有哪些所谓的Oracle顾问在实施了。

　　这种混乱局面到2003年底的时候演绎到极致，在中国本土，"做Oracle的人这时候就像一个金字塔似的。"塔顶上就是Oracle的销售人员。

　　这种现象也直接催生了Oracle销售人员的普遍腐败，以及现在广为人指责的Oracle渠道政策。

　　"有不少Oracle的销售人员，自己在外面开公司接单，然后再以Oracle的名义分包给代理商。"

　　有的销售人员则与某些利益相关的代理商勾结起来，除了提供客户信息外，联手推打Oracle其他的合作伙伴，"如果竞争对手在Oracle拿不到比他们更低的折扣，一般来说，都会自动退出。"

　　在Oracle的渠道体系里，逐渐形成代理商一边要努力跟Oracle销售人员打关系，一边要跟体系内的竞争对手拼折扣，一边还要跟体系外的竞争对手打单的局面。"真是苦不堪言。"李波在Oracle的关系不是很硬，后来也被迫退出了其渠道体系。

　　而另一方面，Oracle对分销商有着近乎苛刻的货款要求，"款到货到，货到一概不退"，无可争辩。代理商为了拿下客户单子，很多时候不得不先期垫付货款，有时候则是在Oracle销售人员的强迫之下拿出钱来帮其完成业绩指标。

　　现金流短缺几乎成为所有Oracle代理商的一大头痛问题。"Oracle根本不会考虑我们的难处，它特别自信自己的产品和市场影响力。对于它来说，代理商是在求它施舍。"李波对此颇为气愤。

　　事实上，Oracle系统的BUG问题业内共知，这在系统实施过程中也凸显出来。客户无论在实施过程还是实施完成之后，都会对Oracle大加指责，而这些指责一般只会落在代理商头上。"对于我们来说，一般不要奢望能完全收回签约款项。"

　　这样下来，正常情况下，代理商除了要面临Oracle销售人员的回扣要求和Oracle的货款要求，还要面对常见的难收款问题。李波认为，"志杰的死很大程度上也跟这有关。"

　　而对于客户来说，在这样的渠道体系下，"实施Oracle系统其实风险巨大。"由此来看待Oracle近些年在中国市场上的疲软，也就不难理解了。

　　对内部腐败的长期默许和合作伙伴与客户利益的习惯性忽视，这让很多了解实情的人人不可理解，但在Oracle过去几年却是不争的常态。对此，绝大多数的业内人士都认为，"这个局面错不在代理商，归根到底在于Oracle的运营机制。"

　　今年2月份，随着陆纯初在Oracle中国区的高调登场，Oracle在中国的销售策略路线已经越来越明显。继胡伯林2002年清理渠道运动之后，Oracle在中国一场更大的渠道洗牌已经开始，现在对于Oracle的问题是，它在中国是否能回归到其在全球颇有Oracle风格的直销模式--一一往无前、不达目的誓不罢休？

　　而对于过往为Oracle开辟中国本土市场立下汗马功劳的合作伙伴，包括死去的志杰，已经衰落的赛意，再次被卖掉的汉普，以及现在仍活得还可以的汉得和科森，Oracle已经或者正在成为过去。

　　对于中国更多的从业人员来讲，无论其变革路线会怎样，Oracle骨子里面的美式霸权和过河拆桥风格，他们不相信会有什么改变。

　　对于Oracle来说，在中国市场上，信任将是未来多年的主题。

　　(注：经当事人要求，本文部分采访对象采用化名)

jdbc连接oracle的连接串如下：

String url="jdbc:oracle:thin:@(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = host2)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = host1)(PORT = 1521))(LOAD_BALANCE = yes)(FAILOVER = ON)(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = db.domain)(FAILOVER_MODE=(TYPE = SELECT)(METHOD = BASIC)(RETIRES = 20)(DELAY = 15))))";

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class Test {

public static void main(String arg[]) {
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
String url="jdbc:oracle:thin:@(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = host1)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = host2)(PORT = 1521))(LOAD_BALANCE = yes)(FAILOVER = ON)(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = db.domain)(FAILOVER_MODE=(TYPE = SELECT)(METHOD = BASIC)(RETIRES = 20)(DELAY = 15))))";
Connection c = DriverManager.getConnection(url,"aa","aa");
Statement s = c.createStatement();
ResultSet r = s.executeQuery("select 1 from dual");
while(r.next()) {
System.out.println(r.getString(1));
}
}catch(Exception e) {
System.out.println(e.toString());
}
}

}