有关RAC的工作日志：
12月16日到12月23日做RAC的试验。12月24日把服务器交给QYC做DataGuard.
QYC做完DataGuard试验之后，1月4日我重新开始做RAC的试验。
当初说是要做XX集团的双机热备,因为我应用oracle的时间非常短，对oracle并不熟悉，所以我这段时间就搜集了
一些相关的信息和资料，以供大家参考。
XX集团的应用我分析了一下，应该是不要求24*7连续工作的，只要能够及时恢复访问即可，而且数据量不是太大。
而且我原来让XX方面做了NAT, 我们在这里就可以进行远端的控制，控制到XX集团内部的Intranet的个别服务器。
我在网上所能搜到的信息是高可用性解决方案分为4种，
一种是oracle提供的被用方法,Standby (=9i DataGuard)
一种是AR (高级复制Advanced Replication，在以前版本叫快照snapshot)
一种是oracle 并行服务器8i的OPS (9i RAC,Real Application Cluster)
一种是第三方HA解决方案 （如Rose HA，故障切换时间是几分钟)
oracle公司的牛人著的里也是
把这4种方法做为高可用方案的组成。
这几种方案从原理上来讲都很容易理解，但是实际上有相当多的细节和问题。
另外还有一种是大家都不太熟悉的是oracle 的 failsafe。
failsafe 采用的是SHARE NOTHING结构，即采用若干台服务器组成集群，共同连接到一个共享磁盘系统，
在同一时刻，只有一台服务器能够访问共享磁盘，能够对外提供服务.这与第3方HA方案的概念基本一样。
但是 failsafe系统局限于WINDOWS(winnt,win2k...)平台，必须配合MSCS(microsoft cluster server).
我在网上找到现成的双机热备的文档 就是讲在 oracle8i上如何做standby. 其保证了始终有一台备用的
数据库能够在很短时间内通过人工，恢复正常的访问，并保证数据一致。这是不要求24*7连续工作时所考虑的方案。
我们所能做试验的就是前三种方案，因为人手有限，所以就做了9i的DataGuard 和RAC 两种方案的试验。
高级复制据说lwd在很久以前做过。我打电话问oracle公司，他说AR对数据库的性能影响太大。
高级复制也分为两种情况
1.主动／被动策略: node1处于主动模式，数据库可读写，node2处于被动模式，数据库只读。
2.主动／主动策略: node1和node2 都处于主动模式，数据库都可读写。这种对数据库的性能影响特别大。
在讲述DataGuard和RAC这两种方案之前，我先补充一点关于oracle Client 如何能够不修改本机配置就能
访问两台oracles数据库的方法。
也就是修改本机的tnsname.ora
一个通常的tnsname.ora 如下：
RACDB =
(DESCRIPTION =
(LOAD_BALANCE = off)
(failover = on)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 211.68.29.61)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 211.68.29.62)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = racdb)
)
)
在 ADDRESS_LIST 中 写了两个地址，client 通过oracle net 在访问时，如果访问不通第一个ip,就会访问第2个ip.
这个特性是早就有了的。load_balance 特性也是有的。但是在两台数据库内容不一致的情况下是没有任何意义的。
不过，在oracle9i 的官方pdf中，load_balance 特性是不推荐使用的。
RAC 的试验我昨天已经做成了，虽然遇到了一些不大不小的Bug和不稳定现象。
环境是oracle9.2.0.1.0 , 2* RedHatAdvanceServer 2.1 和一个磁盘阵列, 采用的是裸设备。
RAC 是share everything 模式，两个数据库实例同时共享同一套数据文件，控制文件，日志文件。
客户端可以同时访问这两台数据库得到的数据都是一致的，它的重点是高性能,可扩展性。但是可靠性是不如DataGuard的。
因为首先在物理上是连接在一起的，是没法容灾的。
其次，instance1 死掉的话，可能可能影响instance2。
(Oracle 公司的电话支持说的， 以及网上的论坛中有相关的例子，一个实例down机拖累另一台不能正常工作,
我在做RAC试验的时候，也出现了node1 重起，造成node2也重起的个别现象)
当然了，与单机的oracle相比，可用性肯定是高的。
另外网上我所能找得到的RAC成功案例(论坛oracle版主之类实施)，无一例外都是oracle经过认证的服务器硬件和软件.
例如HP,DELL PowerEdge服务器。DELL/EMC fiber-channel storage array 等等。
另外，因为没有多余交换机，4块网卡中的进行内部通信用的两块网卡我采用的是直接级联
(新聚思公司的oracle支持说这样不稳定，但是为什么不稳定也没有说原因)
有关共享文件系统的一些问题：
采用裸设备无法进行日常管理，也没有办法进行文件系统级的备份。
开始我第一次在Mandrake8.1的时候，对阵列进行分区，而fdisk在linux下只能分16个分区，我只好采用
lvm（logical volume manager，支持256个)对裸设备进行管理。后来在dbca创建数据库的最后阶段无法创建，只好作罢。
第二次用RedHat AS2.1，oracle网站新推出了针对ocfs，我将其2003-1-3 更新的有关ocfs的所有rpm包(只适用
于AS2.1）安装上，但是却发现无法正常加载ocfs module, 我查了好久，估计这与我们所用的世纪曙光硬件有关，
采用的AMD双Athlon MP 1800+ 以及相关主机硬件，RedHat AS 2.1 无法正常认出，从而造成ocfs modules也无法
正常加载，因为ocfs modules与kernel是相关的。或许换成intel 的双cpu, 或换成单cpu ，然后重装系统就可以解决。
因为rhAS2.1的内核不支持 lvm, 需要重新编译内核才能支持，我只好 将磁盘阵列分成2个drive,分别进行了
分区，跳过了fdisk分区数量限制，给oracle提供了足够多的裸分区。
当初做方案时买的vertris 的冷备份软件(大概10万元)是只能在oracle停机时通过smb来copy 文件进行备份到磁带里的。
而裸设备是没有办法copy 的。
客户端在tnsname.ora配好address_list后，
当nodeA 停机时，是可以不用修改配置访问到nodeB 的。
但是这也分很多种情况
nodeA down,
listenerA down,
InstanceA down,
InstanceA in indeterminate state,
session die等等。
并非每种情况都能实现自动转到node2上。
第三方HA软件是靠自己的agent软件检测模块按照自己的故障判断标准进行强制转换的。第一台肯定不会被访问到，
在几分钟之后所有的访问都会访问到第二台刚刚起来的数据库上。
oracle 要想实现与第三方HA软件一样的功能，只能与microsoft cluster server一起 在windows平台
上实现failover.
除此之外，oracle本身的几种High Available 方案是不提供与此类似的自动failover功能的。
RAC提供并行；
standby/dataguard提供热备份服务器(需要人工维护切换)；
AR 可以基本实时提供两台数据一致的数据库，但是数据库性能受影响。而且客户端能否在各种各样的情况下都自动
切换到第二台数据库上我也不知道。(例如listener running, instance down时无法切换到第二台)
主数据库发生灾难，无法访问的情况下应该是能够切换的，但是有些情况下，只需要修改
tnsname.ora或者停掉node1的listener即可。
以前曾经有人在职成网做过 RoseHA+oracle817+Turbolinux的集成方案, 据说效果也非常差。我所看到我们这里的人去职成网
进行维护N多次。(N非常大) 所以在集成方案中如果用到了oracle数据库，就准备好有人长期进行维护，主数据库
在万一情况下发生灾难，只要有一台热的备用数据库能够在比较短(电话通知之后1天之内)的时间内继续投入使用
就达到了可用性的目的，不至于主数据库损坏，重新进行安装恢复占用星期级的时间。
要想达到failover自动切换，无需人的参予是一种理想化状态，在unix平台上无法实现，windows平台上的oracle failover
我不太清楚，应该是能实现这个想法的。
standby备用数据库 是在oracle7.x才开始提供的一项功能，到了oracle8i才能提供read only模式，
到了9i 才使日志应用等实现了自动化，但是这个自动化不是故障切换自动化，而是只为了实现热备份数据库的功能完善而
增加的一些自动化。 归根到底，oracle公司开发这么久，还没有开发完善这些高可用方案，只是一直处于完善阶段。
RAC的并行提供服务我从一些oracle技术支持那里听来的说法也是最好一台用来做读写，另一台专门提供只读操作的查询，
不然仍然影响性能。用来做我们这种failover应用的倒不多。
很容易理解的一些稍微复杂的原理，要想在实际中应用是需要大量时间的，里面所涉及到的众多细节如日志增量等等很麻烦。
就连oracle9.0.0.1在linux下的OUI(oracle univesal installer) 安装程序在它认证的linux上运行也是一堆Bug.
也就是它的jre有毛病，所以我当初在mandrake8.1上创建数据库出现了问题，无法进行下去。
特定的环境，特定的问题，很多都是没有解释的。这是网上的一个DBA的原话。
网上也有oracle81700升级到81740就出故障的案例。
使用DataGuard(standby) 是不能实现故障的自动切换的，因为据oracle公司的人说无从判断究竟算什么样的故障才开始进行转移，
这个已经超出oracle软件本身的范围了。或许可以通过自己编写程序来按照自己的标准来进行判断和转移。
但是DataGuard做到了始终有一台数据库与主数据库保持一致。在加上客户端的tnsname.ora的addresslist在一定程度上
是可以实现部分的故障切换的。
备数据库平时只能处于read only或 recovery manage 模式。
read only 不能应用主数据库传来的重作日志，recovery manage 可以进行数据恢复，但是不能被客户端访问。
备用数据库经常处于修复状态，因此不能被终端用户使用，这从管理角度是一种浪费(所以8i开始提供了read only模式)。
我的想法是
1. 主数据库发生灾难，被迫关闭，XX方面打电话通知过来，我们通过远程由人工激活备用的数据库即可。也就是敲几行sql命令即可。
完全可以写成脚本，随便找一个人执行一下即可。
2. 备数据库白天处于read only 模式，可供webserver(也就是客户端)查询，晚上12点到1点通过cron 运行在recover managed模式，
将白天主数据库的更改应用到备数据库上。
3. 通过cron将备数据库白天处于 primary 模式，可读可写，晚上通过脚本改回standby模式，并且应用主数据库的更新。
这样当主数据库down机，客户端会立刻连到第二台数据库上，同时也能够进行读写。数据分歧只有一天，并且达到了无人
切换状态。
这3种方法，第1种是最好的。
第2种是可行的，是oracle官方认可的，有数据分歧，和只读的局限性。
第3种有数据分歧并且有或大或小的细节问题没有考虑，只是我的一个临时想法。
在RAC 和 DataGuard 这两种方案中，
RAC对硬件和操作系统要求都比较高，维护也非常复杂，我们买的vertas 备份软件也没有办法使用冷备的文件。
对人员的素质要求也很高。
随便举个例子，RedHat AS 2.1 如果认不出SCSI driver，就没法做了。因为oracle9.2i只能用这个操作系统。
( webmail没有用mandrake8.1而是用mandrake8.2就是这个原因)
不确定因素太多。
在做系统集成方案和买硬件时都要仔细考虑，买什么样的服务器，阵列，网卡，几个交换机，linuxAS21能否装上等等。
而不是随便写个双机热备，买两个服务器，一个交换机就行了。
不过这个方案可以用在我们自己的机房里，提供高性能的oracle数据库服务。(但是需要比较多的时间来准备和调试）。
我现在只能做到把oracle92i装起来，具体平时的管理还要靠有数据库使用经验的其他同事来做。
安装文档我放在附件里了。
如果要应用到XX集团方案中，人员的出差以及硬件，所消耗时间等都需要考虑，我没有把握能再成功装一遍。
DataGuard对条件的要求就很低了，只要随便两台一模一样的数据库就行，不用管操作系统和硬件，网络只需要联通即可。
在主数据出问题时，可以迅速恢复到第二台上。也就是oracle8i里俗称的双机热备。(实际上不止1台热备机，可以一个主数据库
带多个备数据库）
我们在XX处实施时，只需要在这里装好，然后将两个数据库打包通过ftp 传到XX处，然后展开即可运行，也不需要重新安装操作系统和
更改硬件。
网速很快，我原来传过一些上G的文件，也就是几个小时。
要想达到比较理想化的状态，在客户端能够自动避开有故障的数据库访问没有问题的数据库的话，
比较接近这种想法的方案就是AR高级复制的双主动模式，但是oracle公司的技术支持不推荐使用。
我们这里可以找人试一下。lwd用数据库很久了，他以前做过。
实际上如果主数据库瘫痪，是需要人远程干预的， 而oracle的客户端只有2个webserver，修改不修改本机的tnsname.ora都无所谓，
都能够实现正常的访问，修改webserver 本机的tnsname.ora的时间也是不用考虑的。应用程序也是无需修改的。
另外，oracle 提供的TAF(Transparent Application failover)在实际用途中是意义不大的。[@more@]
12月16日到12月23日做RAC的试验。12月24日把服务器交给QYC做DataGuard.
QYC做完DataGuard试验之后，1月4日我重新开始做RAC的试验。
当初说是要做XX集团的双机热备,因为我应用oracle的时间非常短，对oracle并不熟悉，所以我这段时间就搜集了
一些相关的信息和资料，以供大家参考。
XX集团的应用我分析了一下，应该是不要求24*7连续工作的，只要能够及时恢复访问即可，而且数据量不是太大。
而且我原来让XX方面做了NAT, 我们在这里就可以进行远端的控制，控制到XX集团内部的Intranet的个别服务器。
我在网上所能搜到的信息是高可用性解决方案分为4种，
一种是oracle提供的被用方法,Standby (=9i DataGuard)
一种是AR (高级复制Advanced Replication，在以前版本叫快照snapshot)
一种是oracle 并行服务器8i的OPS (9i RAC,Real Application Cluster)
一种是第三方HA解决方案 （如Rose HA，故障切换时间是几分钟)
oracle公司的牛人著的里也是
把这4种方法做为高可用方案的组成。
这几种方案从原理上来讲都很容易理解，但是实际上有相当多的细节和问题。
另外还有一种是大家都不太熟悉的是oracle 的 failsafe。
failsafe 采用的是SHARE NOTHING结构，即采用若干台服务器组成集群，共同连接到一个共享磁盘系统，
在同一时刻，只有一台服务器能够访问共享磁盘，能够对外提供服务.这与第3方HA方案的概念基本一样。
但是 failsafe系统局限于WINDOWS(winnt,win2k...)平台，必须配合MSCS(microsoft cluster server).
我在网上找到现成的双机热备的文档 就是讲在 oracle8i上如何做standby. 其保证了始终有一台备用的
数据库能够在很短时间内通过人工，恢复正常的访问，并保证数据一致。这是不要求24*7连续工作时所考虑的方案。
我们所能做试验的就是前三种方案，因为人手有限，所以就做了9i的DataGuard 和RAC 两种方案的试验。
高级复制据说lwd在很久以前做过。我打电话问oracle公司，他说AR对数据库的性能影响太大。
高级复制也分为两种情况
1.主动／被动策略: node1处于主动模式，数据库可读写，node2处于被动模式，数据库只读。
2.主动／主动策略: node1和node2 都处于主动模式，数据库都可读写。这种对数据库的性能影响特别大。
在讲述DataGuard和RAC这两种方案之前，我先补充一点关于oracle Client 如何能够不修改本机配置就能
访问两台oracles数据库的方法。
也就是修改本机的tnsname.ora
一个通常的tnsname.ora 如下：
RACDB =
(DESCRIPTION =
(LOAD_BALANCE = off)
(failover = on)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 211.68.29.61)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 211.68.29.62)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = racdb)
)
)
在 ADDRESS_LIST 中 写了两个地址，client 通过oracle net 在访问时，如果访问不通第一个ip,就会访问第2个ip.
这个特性是早就有了的。load_balance 特性也是有的。但是在两台数据库内容不一致的情况下是没有任何意义的。
不过，在oracle9i 的官方pdf中，load_balance 特性是不推荐使用的。
RAC 的试验我昨天已经做成了，虽然遇到了一些不大不小的Bug和不稳定现象。
环境是oracle9.2.0.1.0 , 2* RedHatAdvanceServer 2.1 和一个磁盘阵列, 采用的是裸设备。
RAC 是share everything 模式，两个数据库实例同时共享同一套数据文件，控制文件，日志文件。
客户端可以同时访问这两台数据库得到的数据都是一致的，它的重点是高性能,可扩展性。但是可靠性是不如DataGuard的。
因为首先在物理上是连接在一起的，是没法容灾的。
其次，instance1 死掉的话，可能可能影响instance2。
(Oracle 公司的电话支持说的， 以及网上的论坛中有相关的例子，一个实例down机拖累另一台不能正常工作,
我在做RAC试验的时候，也出现了node1 重起，造成node2也重起的个别现象)
当然了，与单机的oracle相比，可用性肯定是高的。
另外网上我所能找得到的RAC成功案例(论坛oracle版主之类实施)，无一例外都是oracle经过认证的服务器硬件和软件.
例如HP,DELL PowerEdge服务器。DELL/EMC fiber-channel storage array 等等。
另外，因为没有多余交换机，4块网卡中的进行内部通信用的两块网卡我采用的是直接级联
(新聚思公司的oracle支持说这样不稳定，但是为什么不稳定也没有说原因)
有关共享文件系统的一些问题：
采用裸设备无法进行日常管理，也没有办法进行文件系统级的备份。
开始我第一次在Mandrake8.1的时候，对阵列进行分区，而fdisk在linux下只能分16个分区，我只好采用
lvm（logical volume manager，支持256个)对裸设备进行管理。后来在dbca创建数据库的最后阶段无法创建，只好作罢。
第二次用RedHat AS2.1，oracle网站新推出了针对ocfs，我将其2003-1-3 更新的有关ocfs的所有rpm包(只适用
于AS2.1）安装上，但是却发现无法正常加载ocfs module, 我查了好久，估计这与我们所用的世纪曙光硬件有关，
采用的AMD双Athlon MP 1800+ 以及相关主机硬件，RedHat AS 2.1 无法正常认出，从而造成ocfs modules也无法
正常加载，因为ocfs modules与kernel是相关的。或许换成intel 的双cpu, 或换成单cpu ，然后重装系统就可以解决。
因为rhAS2.1的内核不支持 lvm, 需要重新编译内核才能支持，我只好 将磁盘阵列分成2个drive,分别进行了
分区，跳过了fdisk分区数量限制，给oracle提供了足够多的裸分区。
当初做方案时买的vertris 的冷备份软件(大概10万元)是只能在oracle停机时通过smb来copy 文件进行备份到磁带里的。
而裸设备是没有办法copy 的。
客户端在tnsname.ora配好address_list后，
当nodeA 停机时，是可以不用修改配置访问到nodeB 的。
但是这也分很多种情况
nodeA down,
listenerA down,
InstanceA down,
InstanceA in indeterminate state,
session die等等。
并非每种情况都能实现自动转到node2上。
第三方HA软件是靠自己的agent软件检测模块按照自己的故障判断标准进行强制转换的。第一台肯定不会被访问到，
在几分钟之后所有的访问都会访问到第二台刚刚起来的数据库上。
oracle 要想实现与第三方HA软件一样的功能，只能与microsoft cluster server一起 在windows平台
上实现failover.
除此之外，oracle本身的几种High Available 方案是不提供与此类似的自动failover功能的。
RAC提供并行；
standby/dataguard提供热备份服务器(需要人工维护切换)；
AR 可以基本实时提供两台数据一致的数据库，但是数据库性能受影响。而且客户端能否在各种各样的情况下都自动
切换到第二台数据库上我也不知道。(例如listener running, instance down时无法切换到第二台)
主数据库发生灾难，无法访问的情况下应该是能够切换的，但是有些情况下，只需要修改
tnsname.ora或者停掉node1的listener即可。
以前曾经有人在职成网做过 RoseHA+oracle817+Turbolinux的集成方案, 据说效果也非常差。我所看到我们这里的人去职成网
进行维护N多次。(N非常大) 所以在集成方案中如果用到了oracle数据库，就准备好有人长期进行维护，主数据库
在万一情况下发生灾难，只要有一台热的备用数据库能够在比较短(电话通知之后1天之内)的时间内继续投入使用
就达到了可用性的目的，不至于主数据库损坏，重新进行安装恢复占用星期级的时间。
要想达到failover自动切换，无需人的参予是一种理想化状态，在unix平台上无法实现，windows平台上的oracle failover
我不太清楚，应该是能实现这个想法的。
standby备用数据库 是在oracle7.x才开始提供的一项功能，到了oracle8i才能提供read only模式，
到了9i 才使日志应用等实现了自动化，但是这个自动化不是故障切换自动化，而是只为了实现热备份数据库的功能完善而
增加的一些自动化。 归根到底，oracle公司开发这么久，还没有开发完善这些高可用方案，只是一直处于完善阶段。
RAC的并行提供服务我从一些oracle技术支持那里听来的说法也是最好一台用来做读写，另一台专门提供只读操作的查询，
不然仍然影响性能。用来做我们这种failover应用的倒不多。
很容易理解的一些稍微复杂的原理，要想在实际中应用是需要大量时间的，里面所涉及到的众多细节如日志增量等等很麻烦。
就连oracle9.0.0.1在linux下的OUI(oracle univesal installer) 安装程序在它认证的linux上运行也是一堆Bug.
也就是它的jre有毛病，所以我当初在mandrake8.1上创建数据库出现了问题，无法进行下去。
特定的环境，特定的问题，很多都是没有解释的。这是网上的一个DBA的原话。
网上也有oracle81700升级到81740就出故障的案例。
使用DataGuard(standby) 是不能实现故障的自动切换的，因为据oracle公司的人说无从判断究竟算什么样的故障才开始进行转移，
这个已经超出oracle软件本身的范围了。或许可以通过自己编写程序来按照自己的标准来进行判断和转移。
但是DataGuard做到了始终有一台数据库与主数据库保持一致。在加上客户端的tnsname.ora的addresslist在一定程度上
是可以实现部分的故障切换的。
备数据库平时只能处于read only或 recovery manage 模式。
read only 不能应用主数据库传来的重作日志，recovery manage 可以进行数据恢复，但是不能被客户端访问。
备用数据库经常处于修复状态，因此不能被终端用户使用，这从管理角度是一种浪费(所以8i开始提供了read only模式)。
我的想法是
1. 主数据库发生灾难，被迫关闭，XX方面打电话通知过来，我们通过远程由人工激活备用的数据库即可。也就是敲几行sql命令即可。
完全可以写成脚本，随便找一个人执行一下即可。
2. 备数据库白天处于read only 模式，可供webserver(也就是客户端)查询，晚上12点到1点通过cron 运行在recover managed模式，
将白天主数据库的更改应用到备数据库上。
3. 通过cron将备数据库白天处于 primary 模式，可读可写，晚上通过脚本改回standby模式，并且应用主数据库的更新。
这样当主数据库down机，客户端会立刻连到第二台数据库上，同时也能够进行读写。数据分歧只有一天，并且达到了无人
切换状态。
这3种方法，第1种是最好的。
第2种是可行的，是oracle官方认可的，有数据分歧，和只读的局限性。
第3种有数据分歧并且有或大或小的细节问题没有考虑，只是我的一个临时想法。
在RAC 和 DataGuard 这两种方案中，
RAC对硬件和操作系统要求都比较高，维护也非常复杂，我们买的vertas 备份软件也没有办法使用冷备的文件。
对人员的素质要求也很高。
随便举个例子，RedHat AS 2.1 如果认不出SCSI driver，就没法做了。因为oracle9.2i只能用这个操作系统。
( webmail没有用mandrake8.1而是用mandrake8.2就是这个原因)
不确定因素太多。
在做系统集成方案和买硬件时都要仔细考虑，买什么样的服务器，阵列，网卡，几个交换机，linuxAS21能否装上等等。
而不是随便写个双机热备，买两个服务器，一个交换机就行了。
不过这个方案可以用在我们自己的机房里，提供高性能的oracle数据库服务。(但是需要比较多的时间来准备和调试）。
我现在只能做到把oracle92i装起来，具体平时的管理还要靠有数据库使用经验的其他同事来做。
安装文档我放在附件里了。
如果要应用到XX集团方案中，人员的出差以及硬件，所消耗时间等都需要考虑，我没有把握能再成功装一遍。
DataGuard对条件的要求就很低了，只要随便两台一模一样的数据库就行，不用管操作系统和硬件，网络只需要联通即可。
在主数据出问题时，可以迅速恢复到第二台上。也就是oracle8i里俗称的双机热备。(实际上不止1台热备机，可以一个主数据库
带多个备数据库）
我们在XX处实施时，只需要在这里装好，然后将两个数据库打包通过ftp 传到XX处，然后展开即可运行，也不需要重新安装操作系统和
更改硬件。
网速很快，我原来传过一些上G的文件，也就是几个小时。
要想达到比较理想化的状态，在客户端能够自动避开有故障的数据库访问没有问题的数据库的话，
比较接近这种想法的方案就是AR高级复制的双主动模式，但是oracle公司的技术支持不推荐使用。
我们这里可以找人试一下。lwd用数据库很久了，他以前做过。
实际上如果主数据库瘫痪，是需要人远程干预的， 而oracle的客户端只有2个webserver，修改不修改本机的tnsname.ora都无所谓，
都能够实现正常的访问，修改webserver 本机的tnsname.ora的时间也是不用考虑的。应用程序也是无需修改的。
另外，oracle 提供的TAF(Transparent Application failover)在实际用途中是意义不大的。[@more@]
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/18921899/viewspace-1016881/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/18921899/viewspace-1016881/
扫一扫
99
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
