oracle rac是什么

RAC，全称real application clusters，译为“实时应用集群”， 是Oracle新版数据库中采用的一项新技术，是高可用性的一种，也是Oracle数据库支持网格计算环境的核心技术。

优点

Oracle RAC主要支持Oracle9i、10g、11g版本，可以支持24 x 7 有效的数据库应用系统，在低成本服务器上构建高可用性数据库系统，并且自由部署应用，无需修改代码。在Oracle RAC环境下，Oracle集成提供了集群软件和存储管理软件，为用户降低了应用成本。当应用规模需要扩充时，用户可以按需扩展系统，以保证系统的性能。

(1)多节点负载均衡;

(2)提供高可用：故障容错和无缝切换功能，将硬件和软件错误造成的影响最小化;

(3)通过并行执行技术提高事务响应时间----通常用于数据分析系统;

(4)通过横向扩展提高每秒交易数和连接数----通常对于联机事务系统;

(5)节约硬件成本，可以用多个廉价PC服务器代替昂贵的小型机或大型机，同时节约相应维护成本;

(6)可扩展性好，可以方便添加删除节点，扩展硬件资源。

希望对你有帮助!RAC的连接URL和单实例不一样，12505是说你的SID有错误。举例来讲，如果你的RAC实例SID是orcl，那么你集群的SID是orcl，但每台机器的SID不同，分别是orcl1，orcl2，…，orclN。在配置weblogic连接池的时候使用RAC专用的URL连接才可以。举例如下：单实例普通写法：jdbc:oracle:thin:@19216811:1521:orclRAC：jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=19216811)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=19216812)(PORT=1521))(LOAD_BALANCE=yes)(failover=yes)(failover_mode=(type=select)(method=basic))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl)))请注意，这是两节点RAC的例子，HOST的地址需要写RAC集群每台机器的虚地址，而不能用实地址，否则不能实现故障转移。选项中的LOAD_BALANCE=yes是负载均衡开启failover=yes是故障转移开启failover_mode=(type=select)是故障转移级别

你可以在其中一台上安装两台虚拟机a、b，

另外一台上安装个nas服务软件，或者ip san服务的软件，linux、windows下都有很此类软件，然后就可以创建共享的磁盘分配给a、b。

这样就可以搭起一套测试环境了，ip san的速度也还过的去。

如果你的服务器性能够好，也可以在单台服务器上创建虚拟机a、b时候直接创建共享磁盘分给a、b使用，至少vm的esx支持这样操作。

RAC，全称real application clusters，译为“实时应用集群”， 是Oracle新版数据库中采用的一项新技术，是高可用性的一种，也是Oracle数据库支持网格计算环境的核心技术。简单的说就是一个数据库，多个实例，数据库是存放在共享存储上，每个实例对应一台服务器。

这个看你在哪个层面上做迁移了。做迁移前肯定是要把数据库先备份的。

一种在硬件层直接做，风险相对大一些[先充分做好测试后再实施]。但最节约时间，可以做到数据库不停服务。

1将新机器硬盘按需要替换硬件的硬盘做好相同分区

2将需要替换硬件的机器停机。

3 用dd命令将需要替换硬件的硬盘克隆到新机器的硬盘中

4 连接配置好存储网络后，点亮新机器。[一切正常的话就替换完成了。如果允许有停机时间的话风险会小的多。这个方案我完整替换过3套Oracle 11g RAC。需要留意的是EMC存储会记住原先机器对应的LUN信息，可后期清理。]

另外一种利用集群在Oracle RAC层做，双机心跳不是直连的话也可以做到数据库不停服务。

1 在线删除掉淘汰的节点

2 在新服务器上安装好之前RAC一致的操作系统

3 添加一个新的节点并配置上数据库实例。

RAC的特点

1双机并行。RAC是一种并行模式，并不是传统的主备模式。也就是说，RAC集群的所有成员都可以同时接收客户端的请求。两个节点在传统的双机热备环境中，始终有一台机器作为备用机，只有当主节点出现问题的时候才会切换到备用机上；如果主机一直没有出现问题，那么备用机始终处于空闲状态，这在资源的利用上以及成本方面都是巨大的浪费。但RAC是一种并行模式的架构，也就是说，两个节点的集群节点间是一种并行运行的关系，当一台机器出现问题，请求会自动转发到另一台机器，没有任何一台机器作为备用机一直不被使用，这样就充分利用了服务器资源。同时，传统的双机热备构架在出现问题时，常常需要数分钟的切换时间，而RAC在出现问题时，针对存在的会话只需要数十秒的时间就可以完成失败切换过程，对新会话的创建不会产生影响，在切换时间上也有比较大的优势。

2高可用性。RAC是Oracle数据库产品高可用性的解决方案，能够保证在集群中只要有一个节点存活，就能正常对外提供服务。高可用性包含两部分的内容：首先是在这种解决方案下要确保数据不丢失，这是最基础的也是必须要保证的;其次是确保不停机，使Oracle数据库一直维持在正常的运行状态，避免停机给客户带来的损失，这是讨论最多的内容。

　　停机一般分为两类，计划停机和非计划停机。所谓计划停机是有计划地安排节点或者系统的停机，一般在Oracle升级、系统维护或者硬件维护的情况下会出现。非计划停机就是在非人为计划的情况下突然停机，这种情况一般是在Oracle bug、系统故障、硬件故障或人为操作失败的时候出现。

　　在没有较高花费的情况下，想实现系统100%的不停机几乎是不可能的。通常情况下，以每月停机时间来计算对应的可用性比率。根据系统的重要性情况，应该为系统设定合理的可用性比率。

集群最大的优势在于它的高可用性，通过使用RAC可以在一定程度上避免因为硬件或软件故障引起的数据丢失和非计划停机，并在一定程度上减少或排除计划停机时间。

3易伸缩性。RAC可以非常容易地添加、删除节点，以满足系统自身的调整。为了在系统初始阶段保持较低的成本，避免造成不必要的浪费，集群可以按照标准硬件配置，选择适当的服务器资源、存储资源来搭建数据库环境。当系统需要更多的处理能力或者需要增加存储时，通过添加另一台服务器或存储设备到集群中，能够在不停机的情况下获得水平的扩展。在一个集群中， Clusterware和RAC支持多达100个集群节点。

　　当某个集群的处理能力过剩，另一个集群的处理能力不够时，可以从处理能力过剩的集群移动一个节点到处理能力不够的集群中。这样能够充分利用服务器资源，节约成本。11gR2版本中推出了网格即插即用(Grid Plug and Play，GPnP)，可以实现节点的快速添加。

4低成本。能使用较低廉的服务器来实现高可用性、高吞吐量的集群环境，这要比通过对某台高端服务器增加硬件实现高可用性、高吞吐量花费的成本低很多。如果想提高系统的处理能力，给集群添加节点比为高性能服务器添加硬件要容易得多。另外，使用集群还能动态地移除节点，更加充分地利用管理者掌握的所有服务器资源，从服务器整体使用上降低了服务器的采购成本。越来越多的企业愿意将集群解决方案应用到他们的系统中，以降低成本，提高系统的可用性。

5高吞吐量。随着节点数的增加，整个RAC的吞吐量也在不断增长。这在要求高吞吐量的系统中，能够得到非常明显的体现。在RAC的架构中，多个实例分布在多个服务器上，能同时打开同一个数据库，而每个实例能够接收相等数量的客户端请求，这样，随着服务器的增加，吞吐量也在不断地增加。RAC是由多台服务器构成的逻辑主体，比单台数据库服务器能接收更多的客户端请求。

故障的原因：emctlbat这个文件不能执行！

因为不可以执行，所以机器说：“Verifying dbconsole is not started already”“控制台没开始发执行命令”实际上控制台是已经发送执行命令了，只是因为执行失败而已，于是监视控制台的状态，发现控制台已经发送控制命令了。控制台发送控制命令“"D:\oracle\product\1020\db_1\bin\emctlbat"执行这个批处理文件，然后控制台跟踪发送进程，没有回应，控制台等5秒钟，又发送执行命令，又没响应，又等……又发送……又等……

以我个人的分析，确实是emctlbat这个文件无法启动，为什么不可以启动呢？可能原因：由于非法关机，程序不能正常关闭导致关联的数据文件损坏；也可能由于非法关机程序不能产生开关性质的文件或配置文件，批处理要调用这些程序执行参数时就会出现错误，比如批处理内容是：xxxexe （执行的参数文件） 后续语句…… 当参数文件找不到（如非法关机）的时候，批处理文件遇到错误就直接退出而不执行下一条语句。

解决的办法，进入安全模式，找到目录“D:\oracle\product\1020\db_1\bin”这个bin目录是主要的程序目录，里面装的都是比较主要的程序，右键点编辑emctlbat这个文件，查看该批处理调用的是什么程序，另外bin目录里面还有些其它程序，从文件名来找相关的程序执行~ 最好最简单的办法是进安全模式把ORACLE软件给卸了，重新安装ORACLE这个程序即可恢复~ 以上是我个人观点，不代表是正确的~按实际情况来做~

—— 小覃

　　对于Oracle的RAC集群数据库，一直以来对于高度JOB方面如何做到负载均衡，一直都不太清楚，这几天测试了一下，得出以下结论。

　　一个JOB在何级别运行是可以定制的。如果把job定义在db级，job可以运行在任何活动的instance上，并遵循job的调度机制；

　　如果把job定义在instance级别上，job将运行在指定的实例上，如因某种异常导致创建job的实例当机，那job将运行在存活的实例上。

　　1、目前我们的rac数据库是通过查询语句 select job,instance,what fromdba_jobs 可以看到instance=0，这表示该job是db级，可以运行在任何活动的instance上，由job的调度机制决定在哪个实例上运行。也就是说RAC会根据两台服务器的运行状态来调度JOB在不同的节点实例中运行，一个JOB可以在A机，下一次有可能在B机运行；

　　2、通过在调度中指定instance 参数，可以指定job只在某个特定实例上运行，但是如果该实例的服务器出现故障时，发现job 在实例A上不再运行，也不会切换到其它实例。如果job建立时没有指定运行在某个实例上，在job当前运行的实例关掉后，却可以切到其他活动的实例上。

　　3、一般情况下，建立不要指定JOB在特定实例运行，如果对于对于已经在运行的job，如果想指定其只在某个实例运行。建议先删除此job，然后重建job，重建时指定job运行的实例。对于有人说可以使用如下方式修改job运行的实例：SQL> exec dbms_jobinstance(26,1)。经测试，不好使，此sql执行后，job不再运行，并出现等待事件：enq: TX - row lock contention，查到执行的sql是update sysjob$ setthis_date=:1 where job=:2，也就是在更新sys的sysjob$表，最后只能杀掉此会话，才消除此等待事件。

　　4、目前还没找到SQL语句来查看某一个JOB运行在哪个实例，一查询，都是0（默认），则可能在任何节点执行。笨方法是通过在Linux中用TOP语句查看CPU的性能来判断是否负荷均衡。

转载，仅供参考。