以下是一个rac one node 的架构图：

从图上我们看出，rac one node，有3个物理主机，Server A、Server B、Server C，这3个物理主机组成一个single cluster，在3个主机上，可以有5个不同的single instance的database，DB1和DB2 host在Server A上，DB3 host在Server B上，DB 4和DB 5 host在Server C上。各个数据库使用共享存储（common share storage）。

对于single cluster上的各个数据库，rac one node能提供以下优势：

1.为同一个主机上的各个数据库Caging不同比例的CPU（见下图）。我的理解是这个和单个数据库上的资源管理器中的resource limit功能类似，限定数据库使用的cpu资源。不过原来的那个是用户分不同的资源组，这个，是按照数据库分不同的资源组了：

2.提供failover，注意这个是提供了服务器级别和数据库级别——双重级别的failover。而不是像一般的虚拟机，只是在服务器级别提供failover，如果仅是数据库down了，不会提供failover。

这功能通过oracle clusterware来实现。

3.load banlance。oracle提供一种叫做Omotion的特性，来实现在业务忙时，从忙的主机将数据库透明的转移到不忙的主机。

在上图中，DB 2原来跑在Server A上，此时Server A负载较重，Omotion能实现在Server A和Server B同步的功能，在Server A和Server B上同时存在DB 2的实例，但是是一个database。（2个instance，一个database，且能负载均衡，这个就类似与rac了。只不过，rac是instance A和instance B，这个是2个一样的instance。我想，这就是rac one node的来由吧，是个rac，但是同一个instance，即一个node。）注意，在此时，Server A上DB 2和Server B上的DB 2，能实现类似rac 的cache fusion——memory mirroring；同时，由于Server A负载重，原来在Server A上的事务，也会迁移到Server B上，直到所以的连接完成迁移后，Server A上的 DB 2的instance会关闭。——instance迁移的时间不会太长，即出现2个instance B的时间，不会太长。

不过，我很怀疑，这个迁移的依据是什么，如果仅仅是根据rac的load banlance原理，数据库在2个服务器间迁移来迁移去，不是很方便管理。如果我的Server之间的配置不同，一个超大的内存，忙；一个超小的内存，闲——这个时候instance是怎么迁移的呢？

4.保证系统和数据库的在线率。当主机硬件升级，或者打os patch，可以利用Omotion进行迁移。

5. 其他优势。由于rac one node使用的共享存储是ASM，因此ASM有的一些优势它也具有。

总结：从上面的几点优势来看，rac one node确实比较吸引人，能提供较高的高可用保护，另外，新的Omotion的特性，可以用于load banlance和迁移。——这个，我目前还找不到可以替代的方案来实现数据库的memory mirroring。

一、 新的Grid架构安装选项
新的Grid架构包含了ASM、侦听和Oracle重启（Oracle Restart）。——值得一提的是oracle重启这个特性，他类似像HP service guard，能提供数据库实例、asm、侦听的监控、管理和自动重启。注意要先安装Grid架构，再安装数据库、asm等。

二、 安装时指定是系统的类型，是服务器类型，或者是一般的桌面应用类型。注意一般桌面应用类的安装，没有高级配置选项。

三、 提供DBMS_DST包来帮助透明的更新TSTZ（Timestamp Timezone）

四、 用SYSASM权限来管理ASM。

五、 提供fixup脚本，来修正安装环境的最小需求。——看上去不错，不过估计真的执行的之前，还得再看看脚本都设置什么了。

六、 提供oracle的卸载工具，OUI不再提供专门的卸载功能，而是由$ORACLE_HOME/deinstall路径下提供一个卸载工具。

七、 智能数据存放——能让你指定将最频繁访问的数据放在asm disk的热端（磁道外端）。

八、 Oracle ACFS，oracle的cluster file system，共享文件系统。这个功能很多DBA已经很兴奋了，它拓展ASM的功能，除了原来放在ASM上的东西，其他的东西也能放Oracle ACFS上。值得一提的是，它还提供了snapshot功能，这个和存储的高级容灾功能已经很像了。注意ACFS也是要求先安装Gird架构。

九、 增强的数据泵，能兼容之前的exp和imp。

十、 单实例的自动重启（Oracle Restart），这个在第一点介绍Gird架构的时候就讲过。这个功能看上去很像在10gR2出现的single instance的HA（搭建方法可以参见这里）。注意该功能的使用也需要先安装Grid架构。

十一、 增强了的SRVCTL命令，可以用来管理单实例的Oracle Restart或者RAC。

十二、 被废弃的一些特性：
1.OUI和DBCA在安装和建库的时候，不再支持裸设备。oracle要求使用文件系统或者ASM。
2.Oracle Ultra Search不再支持。

总体感觉：Grid架构很重要，很多功能都是基于Grid架构才能安装使用；Oracle越来越霸道，也越来越强大，裸设备已经在OUI和DBCA中不支持，已经倾向使用oracle自身的ASM；Oracle的自身管理也越来越智能，Restart似乎可以解决HA的问题，ACFS似乎可以能做存储容灾。只是，这一切不知收费如何？

锁的申请：
1.使用hash算法将资源做hash，做完hash得到一个结果值将对应一个hash bucket
2.申请enqueue hash chain以访问hash bucket。
3.此时，将资源放到hash bucket的hash chain上。如果在hash chain上没有找到对应的资源结构，就到free resource list上找，找到后放入到hash chain上。
4.获得enqueue latch
5.获得free lock的结构（与lock free list的头部断连）
6.将正确的资源信息放到lock上。
7.将lock结构连接到资源结构上。
8.释放enqueue latch
9.释放enqueue hash chain latch。

锁的释放：
1.使用hash函数得到resource的hash chain
2.获得enqueue hash chain来访问hash bucket
3.找到hash bucket，顺着hash chain找到resource。
4.申请enqueue latch
5.将lock结构和resource结构断连
6.将lock结构再次连到free lock list上
7.释放enqueue latch
8.如果resource结构有converter或者waiter，这继续处理。
9.如果可能的话，将resource结构从hash chain上断开，将resource 结构放到free resource list中。
10.释放enquene hash chain latch。

注：上面的resource是指能被session共享的resource，如一个表、一个library cache中的child handle等等。enqueue是用于控制如何访问这些共享资源的后续会具体说明。

打个比方吧，有个钻石加工厂，要把钻石镶嵌到项链上，项链有不同大小的眼以供钻石镶嵌上去。由于为了清洗项链，项链被放在一个开水桶里面，开水桶做了标记，1，2，3，4……

开水桶就是我们的hash bucket，钻石是我们的resource，项链上的眼是resource structure，enquene hash chain是能伸进开水桶的钳子，free resource list是放了一堆链子托盘，如果某个桶里面没有链子，可以到这个上面去找一条来放入到开水桶中，enqueue是做镶嵌工作时小榔头。lock structure是项链上的眼需要抓紧钻石的爪子。该工厂就只有一把钳子和一把榔头，因此后续要操作的人必须等待。

钻石根据其自身的成色/切工/大小，根据hash算法，知道需要镶嵌在5号桶的一条项链上，于是，首先获得enqueue hash chain钳子，去捞那条链子，如果发现5号的hash bucket桶里面没有这条链子，则去free resource list上找一条链子，再泡到开水桶中。如果找到，就把抓钻石的小爪子安放到项链的眼上，小榔头把爪子敲好。

相关视图和基表：
X$KSQRS——v$resource的基表
x$ksqst——可以看系统级的enqueue的type，gets和waits
X$KSQEQ——v$lock的基表

enqueue可以通过v$session_wait来查询，这里的v$session_wait中的p1、p2也就是resource name中对应的ID1和ID2.
如果v$session_wait中的等待是enqueue，那么对应的p1raw就能找出对应的type，而不必通过p1的繁琐运算：
如：

分布式事务的死锁无法判断，因为不在一个SGA中，无法判断是真的死锁，还是等待时间太长的锁，可以通过_DISTRIBUTED_LOCK_TIMEOUT隐含参数来设置分布式事务锁的时间。

v$lock:
lmode>0 request=0 ->owner
lmode=0 request>0 ->waiter
lmode>0 request>0 ->converter

数据字典的锁：row cache lock，type是QA～QZ， 隐含参数_ROW_CACHE_INSTANCE_LOCKS定义了系统最多的row cache lock，默认值是100.
获取过程：申请-如果未获取，则等3秒-再次申请，如此反复1000次，如果还是未获取，就放弃，报错Waited too long for row cache enqueue lock，考虑加大shared pool（主要是share pool中的data dictionary部分）
注意：row cache lock的resource structure是cached row

库缓存的锁：library cache lock是加在library cache对象的句柄上，type是LA～LP。
在parse阶段，会在parent handle和child handle上加library cache lock的独占锁，在dependency上加library cache lock的共享锁。
library cache lock在以下情况会保持null状态：1）检测无效对象；2）避免再次locate handle。
注意：library cache lock的resource structure是object handle
相关视图：
X$KGLLK

library cache pin是加在library data heap上，type有NA～NZ。
当修改data heap的时候，library cache pin会以独占的模式获取
在读取data heap或者需要保护被修改的对象的时候，library cache pin会以share的模式获取。
当一个client修改或检查一个对象的时候，会先在对应的handle上获取library cache lock，再在合适的heap上获取pin。
注意：library cache pin的resource structure是object handle。
相关视图：X$KGLPN

DML行锁是包含行级锁（row level lock）和事务锁：
行级锁是由于：1.行头争用，2.数据块或者索引块的ITL争用
事务锁是TX的enqueue表现的。

（一）行级锁：
行头争用：

如update一行记录：
1.访问对应的block，并且allocate一个ITL
2.通过rowid访问对应的行，如果确认没有其他的事务锁住该行，则将行头的第二个byte当时应该是0
3.找到ITL对应的索引值，通过这个值将行头的lock field改成非0。
4.当另一个事务update这一行时，就会发现行头的标记已经是非0。
5.事务2想知道事务1是否已经commit或者rollback，事务2执行ITL cleanout，当执行完ITL cleanout之后，发现事务1还是active的，于是enqueue等待。

ITL争用：
ITL的初始值为INITRANS的值。最大值为MAXTRANS，能动态修改。

如一个表的maxtrans为3，里面有4行，
1.update第一行记录，这个事务占据一个ITL
2.再开一个窗口update第二行，即又一个事务占据另一个ITL，
3.再开一个窗口update第三行记录，即又占据一个ITL。此时3个ITL已经都被占满，
4.如果此时又开一个窗口update另一行，则此session被挂起。该session会有一个TX的lmode为4（即S锁）的锁。

（二）事务锁：
事务锁是针对活动事务来说的，他们是在回滚段头的块中。transaction identifiers（XID）唯一数据block或者index block的ITL中，是唯一的。XID的格式是：
XID=USN#.SLOT#.WRAP#
XID和回滚段头的关系如下：

dump transaction table：
主要是dump回滚段头：
alter system dump undo header ‘_SYSSMU8$’;
dump出来的结果中state为10表示active，9表示inactive

Buffer 锁：
注意：buffer lock的resource structure是buffer header。session通过buffer handle来访问buffer，buffer handle是lock structure。
buffer header为session提供buffer handle双向链表，一方面指向session使用的buffer，另一方面指向session等待的buffer。正在等待buffer lock的session会报buffer busy wait或者write complete wait。
buffer busy wait在v$session_wait中 p1表示绝对文件好，p2表示block号，p3表示错误代码。
可以通过v$waitstat看各个类型：

1.如buffer busy wait是data block争用：
1.1 如果是data block的读等待，则限制使用选择性不高的索引。
1.2 如果是data block的修改等待，则增加行的选择性：修改pctfree或pctused，增加initrans，减少RECORDS_PER_BLOCK，减小db_block_size，避免使用right hand index。

2.如buffer busy wait是undo的争用
2.1 undo header的争用，则需要更多的undo segment，或者减少transactions_per_rollback_segment。注：9i开始由于使用AUM，自动管理undo，所以该等待出现的情况不多。

3.如buffer busy wait是free list争用，主要是buffer cache中segment header block的争用。
3.1 增加 free list
3.2 增加free list group

SMON的作用：
1.合并free extent，注，会有ST enqueue。
2.清理temporary segment——注：不一定是temp表空间，如truncate之后的表，就被列为temporary segment了。
3.清理不存在的object
4.清理online rebuild但crash后的IND$
5.回缩undo segment
6.启动时的事务恢复
7.事务回滚（被PMON触发）。

检查配置，网络，都没有问题，浮动IP也是启动在10.203.41.11上，但是侦听就是起不来，检查/etc/hosts文件，也是没发现错误。

无奈之下只能开侦听的trace，呵呵，发现遇到侦听无法启动的问题，开trace是个很好的诊断方法。
在trace中发现：
[000001 04-SEP-2009 02:47:41:888] nttcon: entry
[000001 04-SEP-2009 02:47:41:888] nttcon: toc = 2
[000001 04-SEP-2009 02:47:41:888] nttcnp: entry
[000001 04-SEP-2009 02:47:41:889] ntvlin: entry
[000001 04-SEP-2009 02:47:41:889] ntvllt: entry
[000001 04-SEP-2009 02:47:41:889] ntvllt: Not successful in reading /oracle/app/oracle/product/9.2.0/network/admin/sqlnet.ora
[000001 04-SEP-2009 02:47:41:889] ntvllt: exit
[000001 04-SEP-2009 02:47:41:889] ntvlin: exit
[000001 04-SEP-2009 02:47:41:889] nttcnp: Validnode Table **NOT** used; err 0×1f6
[000001 04-SEP-2009 02:47:41:889] nttcnp: exit
[000001 04-SEP-2009 02:47:41:889] nttcon: exit
[000001 04-SEP-2009 02:47:41:889] nserror: entry
[000001 04-SEP-2009 02:47:41:890] nserror: nsres: id=0, op=65, ns=12532, ns2=12560; nt[0]=502, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
[000001 04-SEP-2009 02:47:41:890] nsopen: unable to open transport
[000001 04-SEP-2009 02:47:41:890] nsbfr: entry

看来是和sqlnet.ora文件有关系了，该文件在前段时间安全加固中加上了IP鉴权：

咋一看，是没什么问题，其实，在实际的操作过程中，之前操作的同事可能把格式写错了。呵呵，这样的问题谁都预料不到。我们应该写成：

这样就正常了。

我们可以在自己的机器上（oracle 10.2.0.1）做测试：
（一）当sqlnet.ora写成：

侦听启动正常：

（二）当我们的sqlnet.ora写成：

侦听启动报错：

（三）当我们把sqlnet.ora写成：

侦听启动正常：

一个艺术中心占地很广（我们把它类比做数据库），有许多独立的建筑-艺术馆（艺术馆相当于数据库中的“表”），各个艺术馆中又有许多展馆（相当于表中的记录），为了使各个艺术馆得到有效的管理，对进出艺术馆的人员进行了分类并对他们各自的行为做了如下限制：

到时我会守在艺术馆的门口，对于：

题外话：从10G R2开始select for update已经改成了RX的模式，即lmode为3，这应该说是一个改进，因为从之前的文档上看，select for update是RS锁，可以兼容S锁，前提条件是*Yes, if no conflicting row locks are held by another transaction. Otherwise, waits occur.但是在实际的测试中，如果我select * from table where 1=2 for udpate，这样的不锁任何数据的RS锁，也会让lock table in share mode阻塞。因此，现实的情况select for update为RX锁的情况吻合了，所以10G R2这个版本被改成RX锁，算是修正了。