在Exadata中，每台Storage Server称为一个Exadata Cell。每个Exadata Cell配置一块具有512MB缓存带电池的RAID卡，一块双端口的Infiniband HCA卡，每个端口连接速度能够达到16Gb/s。如下图所示，一个标准的42U机柜最多可能容纳18台Exadata Cell，配置SAS硬盘的话存储容量能够达到65TB，如果配置SATA硬盘的话则容量为216TB。每个Exadata Cell上的HCA卡双端口分别接到两台不同的Infiniband交换机上以实现冗余。如果需要扩容的话，那么可以添加新的标准机柜，机柜之间的连接通过Infiniband相连。Oracle号称采用这种方式扩容以后，Exadata存储的容量和吞吐量都能够线性增长。

在Exadata中，存储的管理全部通过ASM进行，再也没有RAID的概念，所有数据的保护方式都基于ASM硬盘组的镜像和hot swappable Disk（相当于传统存储的hot spare磁盘的概念，防止单个硬盘的故障损坏）。ASM能够自动均匀地将数据条带分布不同的Exadata Cell中，使性能达到最佳。并且ASM的镜像方案能够访问Exadata中的单盘或者一台Exadata Cell的损坏而使数据不受丢失。每个Exadata Cell中的前两块硬盘都会划分出一个13GB的LUN供系统使用，这块空间称为System Area，用于存放Exadata的操作系统、软件及配置信息，这些信息会自动在这两块磁盘上进行镜像存放，防止单点故障。除去System Area，这两块盘剩余的空间都可以供用户使用。Exadata中的每块磁盘都自动划分为一个LUN。每块物理硬盘称为一个Cell Disk，每个Cell Disk可以划分为一个或者多个Grid Disk，每个Grid Disk对应一个ASM磁盘。划分如下图所示：

通常来说一个Grid Disk就对应一个Cell Disk，不过Oracle的方案中也可以把物理硬盘性能好的那部分空间划分为一个Cell Disk（具体怎么划分没有详细的信息，一般来说每块硬盘靠近外面扇面IO性能较好）,性能较差的那部分空间划分为另外一个Cell Disk，然后可以把性能好的Cell Disk组成一个ASM磁盘组，性能差的Cell Disk组成一个ASM磁盘组，ASM磁盘组的镜像容灾方案可以再根据需求调整。整个方案如下图所示：

多个Exadata Cell组成给数据库使用的存储集合称为Realm，一个Realm可以供一个或者多个数据库使用。每台Exadata Cell的操作系统都是Oracle Enterprise Linux 5.1，可以供用户以受限模式访问，用户只能在上面做一些维护性的操作。正如之前所说，Oracle数据库和Exadata之间的通信协议通过iDB进行，iDB基于工业标准的RDSv3协议。iDB集成于Oracle数据库内核，能够将数据库的操作转换为iDB命令传递至Exadata端执行，传输的内容是结果集而不是传统意义上的数据块。当然像传统存储的传输协议一样，iDB在Smart Scan无法使用的情况下，能够直接读写磁盘上的数据。Exadata上的软件包含CELLSRV（Cell Services）、MS(Management Server)和RS（Restart Server）这三个部分。其中CELLSRV是最核心的部分，提供和Oracle实例的数据传输接口，数据传输都通过CELLSRV来进行的；MS主要用于日常管理维护Exadata及监控运行状态；RS的作用则是保障、监控Exadata服务的正常运行，如果哪个服务没有启动，它将会去重启这个服务。在OEM Grid Control中安装插件，OEM也可以方便地管理监控Exadata，在OEM中可以看到Exadata的配置信息、运行状况及性能信息，非常简单易用。

正如前面所说，一个Realm可以跟一台传统存储一样供多个数据库使用，但是传统存储无法控制不同数据库之间的IO消耗能力，有可能一个数据库把一台存储的IO使用完了，导致使用这个存储的其他数据库的IO性能受到影响。而在Exadata上则可以定制IORM（IO Resource Management），方便地将一个Realm中的IO资源分配给不同的数据库使用，比如一个Realm同时给A和B两个数据库使用，我们可以将40%的IO资源给A使用，剩余60%的IO资源给B使用，方便地解决了同一存储不同数据库的IO需求冲突。
Exadata提供的这些强大的功能，革命性更改了Oracle数据库和存储之间传输数据的模式，使得Oracle在数据仓库环境下性能有了极大的提升，让我们共同期待Exadata的早日量产。

Oracle在今年旧金山的OOW大会上发布了自己和HP合作的第一款硬件产品——Exadata。Exadata包含主机Database Machine和存储Exadata Storage Server两种产品，硬件产品由HP提供，Oracle提供软件支持。Oracle号称该款产品在数据仓库的环境下，相比传统的Oracle数据库有着数量级的性能提升。到底该产品有着怎样的改进和亮点才会让Oracle如此自信，下面我们就Exadata的配置和产品特性做一个简单的了解。
Exadata自带一个42U的标准机柜，一个机柜满配的情况下包含8台Database Machine服务器和14台Exadata Storare Server。以下是具体的硬件配置情况：

可以看到数据库服务器事实上就是HP的中端PC服务器-HP DL360 G5，配置2颗4核主频为2.66G Hz的Intel至强E5430 CPU，32GB内存，1块双卡口的Infiniband网卡，4块146G的本地SAS硬盘。而存储事实上就是一台插满12块本地硬盘的HP DL180 G5的PC服务器，配置为2颗4核主频为2.66G Hz的Intel至强E5430 CPU，8 GB内存，1块双卡口的Infiniband网卡，硬盘则为12块300G 15000转的SAS硬盘或者12块1TB 7200转的SATA硬盘。另外配置4个24口的Infiniband交换机，这4台交换机是互为冗余配置，分别给Database Machine之间的RAC内部互联使用，以及用于主机和存储的连接。当存储配置为SAS硬盘时，每台存储能够达到1GB/S的IO吞吐量，1TB用户可用空间（这个用户可用空间按Oracle的说法是指存储上面的盘经过镜像以后，并且排除日志文件、UNDO数据文件和TEMP临时文件占用空间后的的可用空间，不过这个指标应该是根据不同数据库的配置而异的，不具备通用的参考意义），整个机柜14台存储可以提供14GB/S的IO传输速度，14TB用户可用空间；存储配置为SATA硬盘时，能够提供750MB/S的IO吞吐量，3.3TB用户可用空间，整个机柜14台存储可以提供10.5GB/S的IO传输速度，46TB用户可用空间。软件部分，服务器和存储的OS都采用Oracle Enterprise Linux 5.1，数据库为了使用Exadata的一些特性，必须采用Oracle 11.1.0.7或者之后的版本。存储的软件则称为Oracle Exadata Storage Server Software 11g。
Exadata提供的最强大的功能便是Oracle宣称的Smart Scan的功能，这个功能Oracle能够在存储端直接进行SQL预处理。传统上我们对Oracle数据库进行查询时，整个过程如下图所示：

首先用户执行语句，Oracle确认该语句需要全表扫描并定位到哪些区间需要扫描，数据库向存储端发出把该表所有数据全部提取的请求，存储把该表高水位下的所有数据块全部返回给数据库（例子中该表有1TB之多，那么就需要把1TB的数据从存储返回给数据库），然后数据库再进行过滤，把用户需要的1000行数据返回给用户。事实上整个查询过程用户只需要1000行，2MB左右的数据，但是由于Oracle数据库的存储特性，决定了Oracle需要将整张表的数据从存储中提取出来返回数据库端，再在数据库端对数据进行过滤最终返回给用户。
而在Exadata中整个处理过程如下图所示：

用户执行完语句后，Oracle会将该语句转换成一句iDB（the Intelligent Database protocol，Oracle和Exadata存储通讯的协议，后续会详细介绍）命令语句发送给Exadata存储，Exadata中的每个单元智能地扫描该单元中表的数据块并将符合SQL语句条件所需要的行和列数据过滤出来返回给数据库，Oracle再把Exadata每个单元返回的数据汇合以后返回给用户。由于符合条件的结果集只有2MB之多，这样只需要从存储端返回2MB数据给数据库，再也不需要将1TB的全表数据返还，大大降低了存储到数据库的流量。由于存储具备了SQL预处理功能，存储到数据库的数据流量会有大量的减少，这样极大的减少了数据库的负荷，数据库的处理能力有了数量级的提升。这是Oracle革命性的改进，之前从来没有一个数据库能够在存储底层就对数据进行过滤，而Oracle开创性地做到了这点！
Exadata的Smart Scan提供了行、列过滤的功能，可以在存储级别直接提取出用户所需的行数据和列数据。除此以外，Smart Scan还具备表连接处理功能，在存储级别直接进行表连接处理，最终再把连接好的结果集返回给用户。另外Smart Scan还能加快增量备份和创建表空间或者添加数据文件的速度。常规增量备份块记录变更是以一组块为单位，而Exadata中则是以单独的数据块为块变量记录单位，这样备份时对IO消耗的带宽更小。而在我们创建表空间或者添加数据文件时，我们都需要把数据文件从存储读取到数据库的内存进行格式化处理后再写进存储，这样有多大的数据文件我们就需要从存储端读取多大的数据到数据库层面再写入。而在Exadata中，Exadata只需要简单地执行一条iDB命令就可以将表空间创建好或者数据文件添加好，而不需要将数据文件读取到数据库里面进行格式化，大大加快了创建表空间或者添加数据文件的进程。

传统的RAC内部互联大部分都是基于普通网络实现的，目前最为普及的是百兆和千兆网络，最快的也就是尚不普及的万兆网。由于普通网络的速度限制，在需要频繁进行内部通信的多节点RAC数据库中性能就无法得到保证。正是基于这一点，Oracle和Qlogic在2006年2月24号共同发布了基于Infiniband高速互联网络的RDS for Oracle RAC内部互联方案。

如图所示，传统的RAC内部互联协议都是使用UDP协议，这样无论内部互联网络是用普通网络交换机还是Infiniband交换机，都需要先把UDP协议转换成IP协议才能通过网络传输，如果使用Infiniband交换机的话，那么还需要把IP协议转换成为IPoIB协议(IP over Infiniband)，这样几经转换，内部互联传输显然效率不高。而使用RDS内部互联的话，那么，Oracle RAC数据库内核可以直接通过RDS协议传输信息，少了几层转换，性能会有质的提升。
不光如此，RDS还有如下优点：
1、高带宽。相比普通网络交换机现在最大带宽是10Gbps，Infiniband最快能够达到40Gbps。
2、低延迟。比起普通UDP内部互联，能够成倍的网络延迟。
3、低CPU利用率。内部互联的CPU开销只有原来的一半以下。
由于RDS高效传输的特性，从Oracle 11g开始众多硬件厂商也加入了对RDS的支持，不再仅仅是Oracle 10g时仅有Qlogic一家。而Oracle最新发布的硬件产品Exadata中，RDS已经成为RAC内部互联的默认选项。目前业界使用RDS内部互联方案的案例相对较少，只有YAHOO、DELL等部分企业采用了这一方案，国内目前就淘宝、阿里巴巴使用。相信随着多节点RAC数据库的需求方案越来越多，RDS也会逐渐流行开来。

RAC的负载均衡主要是指新会话连接到RAC数据库时，如何判定这个新的连接要连到哪个节点进行工作。在RAC中，负载均衡分为两种，一种是基于客户端连接的，另外一种是基于服务器端的。
客户端的负载均衡配置相对简单，只需要在tnsnames.ora中添加LOAD_BALANCE=ON这么一个选项即可。比如下面的TNS：

RAC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
(LOAD_BALANCE = ON)
(FAILOVER = ON)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = rac)
)
)

这样当客户端连接RAC数据库时，会随机在TNS里面挑个监听地址进行连接。在Oracle10g以前，假如有节点宕机或者类似事故时，客户端可能还是选择连接到这个节点，这样会发生较长时间的TCP等待超时。而在10g以后，由于VIP和FAN的引入，这样的情况可以得到很大程度的改善。客户端的负载均衡在通常情况下能够较好地工作，但是由于连接是在客户端随机发起的，这样客户端并不知道RAC各节点的负荷及连接数情况，有可能负荷大的节点还会源源不断地增加新的连接，导致RAC节点无法均衡工作。
从Oracle 10g开始，服务器端的负载均衡可以根据RAC中各节点的负荷及连接数情况，而判定将新的客户端连接分配到负荷最小的节点上去。RAC中各节点的PMON进程每3秒会将各自节点的负荷（包括LOAD、最大LOAD、CPU使用率）及连接数更新到service_register里面，然后假如节点的负荷有发生变化，将会通知到监听程序，由监听程序再决定新的客户端连接分配至哪个节点。假如RAC中一个节点的监听失败了，PMON每一分钟会去检查一次是否已经恢复正常。
服务器端的监听配置是在各节点的tnsnames.ora里面添加一个连接到各个节点监听的条目，然后再在初始化参数里面设置remote_listeners这个参数。比如：

LISTENERS_RAC =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
)

ALTER SYSTEM SET REMOTE_LISTENER = LISTENERS_RAC;

这样服务器端的LOAD BALANCE便配置完成。
但是有时候由于PMON取节点负荷的延迟，导致客户端连接可能还是会连接到负荷较大的节点上，这时候便可以在服务器各节点的listener.ora里面加入PREFER_LEAST_LOADED_NODE=OFF这么一行，这样服务器端的负载均衡将不再根据节点的负荷来进行分配，而是根据节点的连接数进行分配，达到各个节点连接数比较平衡的效果。
另外一个不得不说的便是并行操作，假如有个会话连接以后要进行并行操作。由于连接时是按负荷或连接数连接，这样可能连接时各个节点连接数和负荷等比较平衡，但是这个并行会话启动多个并行进程以后，那么这个节点的负荷及连接数就会有可能上升得比较快。如果在RAC中开启了节点并行，那么有可能会把并行进程分配到多个节点运行以达到负载均衡的效果。
从Oracle 10.2开始，Oracle引入了Load Balance Advisor，对负载均衡有了进一步的改进。结合Service，可以对不同的SERVICE设置不同的负载均衡策略。Load Balance Advisor的配置可以通过DBMS_SERVICE包对SERVICE进行更改而完成。在Load Balance Advisor首先必须设置SERVICE负载均衡的目标，目标分为3种：

GOAL_NONE Disables the load balancing advisory
GOAL_SERVICE_TIME The LBA calculates a weighted moving average of the total elapsed time for completed work plus the bandwidth that’s available to the service to calculate the service goodness. This goal is ideal for services whose workload may change dramatically over a short period of time, e.g. an application that services a “clicks and mortar” store that provides customer self-service through an internet-based shopping web site.
GOAL_THROUGHPUT The LBA calculates a weighted moving average of throughput (i.e. the rate at which work is completed) in addition to the bandwidth available to the service to calculate the service goodness. This goal is best suited for long-duration tasks that are typically queued to run serially, e.g. scheduled jobs that handle large batches of transactions.

另外可以额外设置连接的负载均衡：

CLB_GOAL_SHORT The Load Balancing Advisory will be used for connection load balancing only if it is enabled (i.e. set to other than GOAL_NONE). If the LBA has been disabled, connection load balancing will utilize abridged advice determined by CPU utilization.
CLB_GOAL_LONG Connection load balancing will be determined by first tallying the total number of connections per instance, and then by counting the number of sessions per each service. Oracle recommends using this setting for services whose applications tend to connect for long periods of time (e.g. Oracle Forms). The Load Balancing Advisory can be used in conjunction with this setting as long as the connection pool has been sized to accommodate “gravitation “ within the pool without adding or subtracting connections. Oracle recommends this option as the most efficient design.

The behavior of the write-to-read transfer is determined by the _FAIRNESS_THRESHOLD parameter,which was introduced in Oracle 8.1.5 and defaults to 4. Prior to the introduction of this parameter,when Instance A held a block in exclusive mode and Instance B requested a read-only copy of that block, Instance A would downgrade its exclusive lock to a shared lock and send the block to Instance B,which would also set a shared lock on the block. However, if Instance A is performing frequent updates
on the block, it will need to reacquire the block and set an exclusive lock again. If this process is repeated frequently, then Instance A will be continually interrupted, as it has to downgrade the exclusive lock to a shared lock and wait until Instance B has finished reading the block before it can convert the shared lock back into an exclusive lock.
The _FAIRNESS_THRESHOLD parameter modifies this behavior. When this parameter is set,Instance A will no longer downgrade the exclusive lock. Instead, it sends a null lock to Instance B,and then it can continue processing. However, if instance B requests the block _FAIRNESS_THRESHOLD times, by default 4, then Instance A will revert to the original behavior—it will downgrade the exclusive lock to a shared lock and ship the block to Instance B, which will also set a shared lock on the block.

From:Pro Database 10g RAC on Linux

通常我们配置DATA GUARD，都需要对主库进行备份，再把备份的备份集复制到备库端进行配置。但是当数据库非常大时，尤其是数据库采用ASM作为存储方案时，如果没有足够的空间用于存放备份集，这样显然就无法通过常规的方式来配置STANDBY。利用DBMS_FILE_TRANSFER则可以方便地将主库的数据文件直接传递至备库的ASM磁盘组，这样再也不需要使用中间存储存放备份文件。下面简单介绍一下通过DBMS_FILE_TRANSFER配置基于ASM存储方案的DATA GUARD和克隆数据库的方法。

一、在备用数据库端创建好ASM磁盘组和一个中间数据库。
首先必须要在备用数据库端配置好ASM实例，创建好ASM磁盘组，并且ASM磁盘组的名字最好是和主库一样的。当然，名字不一样也可以，那就需要一些额外的设置。另外由于DBMS_FILE_TRANSFER远程传输是基于DB LINK的，因此需要在备用库端创建一个中间数据库，这个中间数据库的主要作用便是用于DB LINK传输数据文件。假定我们创建的ASM磁盘组叫DATA，中间数据库名字叫transfer。
二、在备用库的中间数据库上创建一个到主库的DB LINK。做之前需要配置好到主库的TNS。

SQL>create database link lnk_pri connect to system identified by password using ‘primary’;

三、在主库端创建到数据文件目录的directory。

SQL> create or replace directory pri_dir as ‘+DATA/TEST/datafile’;

四、在备库端创建好备库的相应目录，比如bdump，udump等目录，另外在备库的ASM实例中创建备库的数据文件、控制文件等目录。

SQL> alter diskgroup DATA add directory ‘+DATA/TEST/’;
SQL> alter diskgroup DATA add directory ‘+DATA/TEST/DATAFILE’;
SQL> alter diskgroup DATA add directory ‘+DATA/TEST/CRONTROLFILE’;
SQL> alter diskgroup DATA add directory ‘+DATA/TEST/TEMPFILE’;

五、在备库的中间数据库上创建好两个DIRECTORY，用于存放传递过来的数据文件和控制文件。

SQL> create or replace directory stb_dir as ‘+DATA/TEST/datafile’;
SQL> create or replace directory stb_ctl_dir as ‘+DATA/TEST/controlfile’;

六、在中间数据库开始传输数据文件。
由于是在线配置STANDBY，在传输数据文件之前，必须先在主库把相应的表空间置于恢复模式，然后利用dbms_file_transfer进行数据文件的传输，最后再把相应的表空间置为正常状态：

SQL> conn sys/password@lnk_pri as sysdba
SQL> alter tablespace system begin backup;
SQL> conn /as sysdba
SQL>begin
dbms_file_transfer.get_file(
source_directory_object => ‘ pri_dir ‘,
source_file_name => ‘ system.286.650339101′,
destination_directory_object => ‘ stb_dir ‘,
destination_file_name => ‘ system01.dbf ‘,
source_database => ‘lnk_pri’);
end;
/
SQL> conn sys/password@lnk_pri as sysdba
SQL> alter tablespace system end backup;

这样依次对主库的每个数据文件进行处理传递后，主库上的数据文件都会传递至备库的ASM磁盘组上。
七、 传输备库的控制文件。
首先在主库端生成备库的控制文件：

SQL> alter database create standby controlfile as ‘+DATA/TEST/datafilefile/standby.ctl’;

如果是克隆数据库的话，那么生成一个普通备份控制文件即可：

SQL> alter database backup controlfile to ‘+DATA/TEST/datafilefile/standby.ctl’;

然后传输控制文件：

SQL>begin
dbms_file_transfer.get_file(
source_directory_object => ‘ pri_dir ‘,
source_file_name => ‘ standby.ctl’,
destination_directory_object => ‘ stb_ctl_dir ‘,
destination_file_name => ‘ control01.ctl ‘,
source_database => ‘lnk_pri’);
end;
/

八、 配置备用库。

首先配置好备库的参数文件，并且配置好主库和备库的TNS，接下就可以配置备用库了：
启动备库至mount状态

SQL > startup nomount
SQL > alter database mount standby database;

如果是配置克隆数据库的话，则直接将数据库MOUNT就行：

SQL > alter database mount;

执行RMAN的catalog命令，以使控制文件能够识别传输过来的数据文件：

RMAN> catalog start with ‘+DATA/TEST/DATAFILE’;

然后将这些数据文件转换为备库的数据文件：

RMAN >switch database to copy;

如果是配置DATA GUARD的话，则可以将备库置为恢复模式：

SQL > alter database recover managed standby database disconnect from session;

如果是配置克隆数据库的话，那么直接恢复数据库并打开：

SQL >recover database until cancel;
SQL >alter database open resetlogs;

这样DATA GUARD和克隆数据库就配置完成了。最后可以把中间操作创建的directory，DB LINK和中间数据库删除掉。

   上周末将10.2.0.3的RAC数据库升级到10.2.0.4。在升级过程中碰到了几个问题，记录一下解决办法。

   第一个是在CRS打完Patch之后运行root102.sh脚本时报：

Preparing to recopy patched init and RC scripts.

Recopying init and RC scripts.

ocrcheck failed. Check /u01/oracle/product/10g/crs/srvm/log for more details

这一步事实上是这时候CRS无法启动，而且在/u01/oracle/product/10g/crs/srvm/log这个目录下面没有记录任何东西。尝试着手工启动CRS，报：

/u01/oracle/product/10g/crs/bin/crsctl.bin: error while loading shared libraries: /u01/oracle/product/10g/crs/lib/libclntsh.so.10.1: file too short

查看一下libclntsh.so.10.1，文件大小居然为0。查看该目录下的其他文件的大小和更改时间和备份的目录相比都没变化，解决办法便是将报错的libclntsh.so.10.1文件从升级之前备份的CRS目录COPY回来，再运行脚本就可以了。可见在升级之前做好备份有多重要。

   第二个问题是打完PATCH，准备用DBUA升级数据库时将所有节点启动至MOUNT状态，DBUA运行下一步时报错：

DBUA thinks this is a Rerun operation and is trying to connect to the database with oracle home /u01/oracle/product/10g/db. If you believe this is not a Rerun operation, remove the below file and invoke DBUA again.

 /u01/oracle/product/10g/db/cfgtoollogs/dbua/logs/Welcome_dwdb.txt

但是Welcome_dwdb.txt这个文件压根不存在。这时候只好抛弃DBUA了，手工运行升级脚本，这样数据库才能正常升级成功。

   第三个问题是发现发现我们原来RAC内部互联采用的是Infiniband RDS协议变成普通的UDP协议互联了：

Fri Mar 28 21:12:14 2008

cluster interconnect IPC version:Oracle UDP/IP (generic)

IPC Vendor 1 proto 2

    这个问题是由于在升级过程中ORACLE又重新将内部互联的方案更改为默认的UDP方式。需要重新配置一下RDS内部互联，在配置之前需要把ASM和数据库都停掉，然后重新RELINK成RDS互联：

$ cd $ORACLE_HOME/rdbms/lib

$ make -f ins_rdbms.mk ipc_rds ioracle

这样以后，内部互联就恢复成正常的RDS了：

Fri Mar 28 21:25:39 2008

cluster interconnect IPC version:Oracle RDS/IP (generic)

在升级之后我们碰到了一个新的BUG，数据库会报：

ORA-00600: internal error code, arguments: [kddummy_blkchk], [47], [935468], [18038], [], [], [], []

解决办法是将db_block_checksum这个参数改为FALSE，不过这样做会有较大的风险，目前这个BUG ORACLE已经提交BUG开发部门进行开发了。