Maclean’s Oracle Database Tech Blog Archives

原文连接： http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_3/ DRM是Oracle文档没有记录的特性，因为Oracle的架构师认为这个优化应该对于用户来说是透明的，用户没有必要去知道这些细节， 所以故意不不公开的。但是由于10g这个版本由于采取的策略过于激进，导致10g因为DRM导致的宕机和节点驱逐的概率远远高于早期的版本。所以从11g开始，Oracle决定为DRM进行了大量的代码重写，并且重新优化了其架构，当然这一切还是在“偷偷摸摸”下进行的。这些架构中最重要的两个就是read-mostly locking以及reader bypass。 Read-mostly locking Read-mostly locking是为读多写少的业务进行的优化，也就是说Read-mostly是在牺牲写性能的方式来换取读性能的一种方式，只有在绝大多数操作都是读操作才能起到很好的优化效果。为什么这么说呢？一旦某一个object被定义成read mostly，那么同时在master节点就会授予其它所有节点的S affinity lock，也就是说，所有的节点都被“预先”授予了这个object的读权限，如果此时其它节点需要读取这个object的信息，就不再需要进行单独的授权。那么与授权相关的等待例如我们熟悉的gc cr grant 2-way，gc current block 2-way/3-way等待事件将会大幅度的减少。与此同时，我们会看到db file sequential read的等待事件有所上升，因为原来的共享current block 转移将会被物理磁盘读操作所取代。 我们知道如果需要修改一个object，按照cache fusion的基本原理首先需要向这个object的master节点申请一个X锁（排他锁）， 然后才能进行修改。而read-mostly locking则需要先加一个特殊的锁：anti-lock。当一个节点需要申请X锁时，它会向其它所有的节点发送一条广播消息，告诉这些节点打开一个anti-lock。如果所有节点都打开了anti-lock锁，则对于这个object上所有的S/X锁请求都将转换为标准的cache fusion的锁定机制。只有当read-mostly locking被解除（例如写操作的请求明显增加）或者脏块被写会到磁盘并且X锁被降级以后，anti-locks才将被清理。 以上说了一堆非常绕口的话，当然可以用更简洁的话语来描述read-mostly locking的机制：read-mostly就是对于读较多的object预先加上一层锁，大幅减少了读操作所需的授权信息。对于写操作， 则需要先加一个“反锁”进行解锁，然后再按照基本的cache fusion机制完成剩余部分的工作。  reader bypass reader bypass与read-mostly locking是互斥的，主要是为读少写多的业务进行的优化。这里说的互斥是object级别的，而非database或者instance级别的，也就是说一个object不能同时既是read-mostly又是reader bypass。 与read-mostly相对，reader bypass同样引入了一种新的锁模式weak X lock（又称xw锁）。有了xw锁，我们就可以在S锁没有释放以前，立刻为一个block加上一个xw锁，加上xw锁以后，可以对这个block进行修改，但是不允许立刻commit，直到所有的的S锁都关闭或者降级到N锁，当所有的S锁都已关闭或者降级为N锁时， LMS就会向xw锁的持有者发送一条信息可以进行commit了。 read bypass 会大量减少gc current grant busy这样的等待，但是明显对于commit比较频繁的应用有较大的负面影响。   未完待续 To Be Continued…

IBM的创始人Thomas J. Watson曾经说： “全世界只需要5台电脑就足够了”。 Microsoft的创始人Bill Gates曾在一次演讲中说：“个人用户的计算机内存只需640K ”。 Intel创始人之一Gordon Moore曾经说：“当价格不变时，集成电路上可容纳的晶体管数目，约每隔18个月便会增加一倍，性能也会增加一倍”。 前面两句话在今天看来实际上是十分荒谬的，而最后那条就是著名的摩尔定律。 hugepages的出现同样也是因为摩尔定律导致了主机内存越来越大，最后不得不对于标准pages的改进以提高效率。要了解hugepages首先必须清楚Unix/Linux内存的分配机制。本文从入门的角度介绍Linux的内存分配机制，当然这一部分内容相信很多人都在计算机体系结构这门课程中学到过，这里就重新温习一下。 早期因为程序非常简单并且使用的内存也非常小，程序的内存地址都是使用程序地址对应物理地址这种这种直接映射的模式，通俗的说就是物理地址是在程序中写死的。想想使用汇编直接操作物理地址是多么壮观的工程呀。对于一个大型的软件系统来说，这部分工作几乎是不可能完成的。后来开始使用“段页式”的方式来管理内存的寻址。用一个时髦的词来说就是引入了“虚拟化”技术。现代操作系统都会使用受保护的虚拟地址模式（protected virtual address mode）来管理内存，Linux下分为三类地址：逻辑地址（Logic Address）、线性地址（Linear Address）与物理地址（Physics Address）。这三者的对应关系如下所示：     简单的说就是逻辑地址通过分段机制映射转化为线性地址，然后线性地址通过分页机制映射转化为物理地址。因为这里是介绍hugepages，所以我这里不打算介绍分段机制，主要对分页机制做简单的阐述。 事实上，地址映射的过程远远不止上图中这么简单。例如在分页机制映射中，一般需要经过四级映射，也就是将线性地址映射为物理地址的过程中，需要从内存中读取至少四次页目录表（Page Directory）和页表 (Page Table)。众所周知，CPU寄存器与内存的访问速率相差至少一个数量级，所以如果使用传统的分页机制的开销将会非常大。所以在现代的X86架构中，集成了一种被成为TLB（Translation Lookaside Buffer）的硬件级缓存。TLB读写速度非常快，基本和CPU寄存器的速率在一个数量级，而TLB中保缓存了最近使用过的线性地址和物理地址的映射关系。如下图所示：   那么将线性地址映射为物理地址的过程如下：首先到TLB中找到这个条目是否存在，如果不存在则为TLB miss，然后使用页表的方式进行寻址，最后把这个映射关系更新到TLB中以备下次使用。由于TLB是大小有限，而一旦出现TLB miss，则其查询的代价很高，所以现代CPU架构基本都进行了一些优化以提高地址映射的效率。例如： 线性地址到物理地址转换一开始就选择同时在TLB和页表进行查询，而不经过TLB查找是否成功的等待； 使用多级TLB以及软TLB， 在CPU context swtch的时候不flush整个TLB。 下面用例子来说明为什么使用传统的 4k大小的页表相比hugepages对大内存的管理效率会很低。在x86平台，一条PTE的大小为4Byte；而在x86_64平台，一条PTE的大小为8Byte。 以下这种场景并不罕见： Linux x86_64, SGA大小为100G，使用常规的4k的page，连接到数据库的进程数约1000。page table一共需要100×1024×1024K/4K=26214400条PTE； 那么26214400条PTE需要100×1024×1024K/4K×8Byte=209715200Byte=200M； 从而1000个进程需要100×1024×1024K/4K×8Byte×1000=209715200000Byte=200G。 计算出来的结果真是令人崩溃，但是事实上在你没有崩溃以前，数据库就已经因为没有内存而崩溃了。同样条件下，如果使用2M的hugepages进行对比，则以上的计算方法变为： page table一共需要100×1024M/2M=51200条PTE； 那么51200条PTE需要100×1024M/2M×8Byte=409600Byte=400K； 从而1000个进程需要100×1024M/2M×8Byte×1=409600Byte=400K。 综上，可以看到同样是1000个进程，同样是管理100G的SGA，结果却大不相同。使用传统的4k大小的page开销竟然会达到惊人的200G；而使用2M的hugepages，开销只有400K。 这其中不仅仅只是对于因为单个进程而言，2M page需要的PTE小于4K  page的PTE，最大的一个原因是在于使用4K page的话，有多少进程使用SGA，就需要多少套PTE，相反如果使用2M page则无论有多少进程使用SGA，共享的都是同一套PTE。 众所周知，x86是32位的，所以默认情况下，其可寻址的空间为2的32次方——4G。在X86设计之初，4G内存似乎是一个遥不可及的天文数字，但是摩尔定律打破了这一切，所以软硬件的设计和开发商必须想出一个对策来解决4G以上不可寻址的问题。注意：这里没有说4G以上的内存不可寻址，而是说4G以上的地址空间不可寻址，这两者实际上有区别的。例如4G内存的CPU在32bit的Windows（非server版本）能识别到的内存一般在3G左右。 这其中的主要是主板或者操作系统的限制。因为计算机上一些其他的设备同样需要可寻址，而这一部分地址需要从总的可寻址空间中预留，例如BIOS芯片的ROM，显卡上的显存(RAM)和BIOS(ROM)，以及PCI、PCI-E设备上的RAM和ROM都需要占用一定的可寻址的空间。这个叫MMIO（Memory-mapped I/O）。这里有点off…

原文链接：http://www.dbaleet.org/about-rac-interconnect-os-bonding/   对于维护mission critical的高可用系统的DBA而言，SPOF（单点故障）永远是无法回避的话题，因为它会影响到SLA （服务等级协议）， 对于任何一个设计良好的系统都应该尽量避免出现单点故障。 RAC的私网，我们有时称其为心跳线，可见其迁一发而动全身的作用。上一篇我们讲述了Oracle自带的一种防止私网单点故障的方式HAIP。 限于其局限性，本篇主要讲用途更为广泛的操作系统级别的网卡绑定。 绑定，简单的说就是使用多块物理网卡捆绑成逻辑上的一块网卡，它对于操作系统之上的应用程序是完全透明的，以提供故障转移或者负载均衡，消除单点故 障的隐患。 这看上去是一件非常简单的工作。但实际上远远不是像它看上去的，其中涉及到很多有关的网络方面的概念和细节，当然这些细节超出了本文的范畴，在此不做详细 的论述。 绑定（bond）是Linux平台的叫法，它还有其它的各种名字例如port trunking（端口汇聚，常见于交换机领域），Link aggregation（链路聚合， 事实上，这个才是业界的标准IEEE 802.3称谓， LACP——link aggregation control protocol），  NIC teaming （网卡组合， 常见于HP和Microsoft的称法），Ethernet Channel（以太网通道， Cisco/IBM的叫法）。当然这里面会存在一些细微的差异，例如绑定本身与交换机的概念无关，整个过程不需要交换机主 动参与，而链路聚合则需要交换机厂商本身的聚合协议支持。例如并不是所有交换机都支持IEEE 802.3ad（现在主流厂商基本都支持）。至于支持PAGP，则是Cisco的私有协议，国内厂商huawe和ZTE都有其对应的协议，这里就不一一赘 述了。 各主流的操作系统平台都提供各自的绑定方法。IBM AIX为Ethernet Channel, HP-UX上为APA（顺便提一下，这个功能是收费的。）， Linux为bond， Solaris平台IPMP 。 这些绑定技术通常都可以配置为Active-Active， 或者是Active-Standby的方式。 需要注意的是Active-Active并不意味着能提供双向负载均衡的能力。以IBM AIX上的Ethernet Channel（此Ethernet Channel并不依赖于Cisco的交换机的Ethernet Channel协议）为例， 对于负载均衡只是针对操作系统所管辖的网卡outgoing（发送）的流量而言，而对于网卡Incoming（接收）的流量则是取决于交换机端配置使用的 算法。在绝大多数情况下，outgoing可以负载均衡，但incoming使用的总是同一个设备，也就是说是单向负载均衡。（HAIP可以提供双向负载 均衡） 对于interconnect，除Linux以外，其它Unix厂商绑定的配置和选项相对比较简单，私网配置错误的可能性较小。Linux平台由于 其复杂性和模式过于复杂需要在这里单独罗列出来。Linux的绑定模式一共分为7种：Mode 0： Round Robin，Mode 1： Active-Standby， Mode 2： XOR，Mode 3: Broadcast， Mode…

原文链接： http://www.dbaleet.org/about_protocols_of_infiniband/   这不是一篇介绍infiniband是什么的文章，而仅仅站在Oracle RAC和Exadata的角度上阐述infiniband。 如果您不知道infiniband是什么，请点击这里。 很多人可能不知道，绝大多数高性能计算机内部或者集群之间都是使用infiniband互联的。在国家超算中心，在亚马逊的云计算中心都有它的身 影。为什么infiniband会如此受欢迎呢？原因无非有两个： 一是目前infiniband本身能提供比传统以太网更高的带宽， 二是通常infiniband的开销比以太网要小，对于节点间通信大量数据传输比以太网效率要更高。当然Oracle也是这一技术的主导者， 其中RDS本身就是Oracle的一个开源项目。常见的运行在infiniband之上协议有哪些呢？下面就简单介绍一下Oracle DB可能会用到的几个： IPoIB协议： Internet Protocol over InfiniBand 简称IPoIB 。传统的TCP/IP栈的影响实在太大了，几乎所有的网络应用都是基于此开发的，IPoIB实际是infiniband为了兼容以太网不得不做的一种折 中，毕竟谁也不愿意使用不兼容大规模已有设备的产品。IPoIB基于TCP/IP协议，对于用户应用程序是透明的，并且可以提供更大的带宽， 也就是原先使用TCP/IP协议栈的应用不需要任何修改就能使用IPoIB。例如如果使用infiniband做RAC的私网，默认使用的就是 IPoIB。下图左侧是传统以太网tcp/ip协议栈的拓扑结构，右侧是infiniband使用IPoIB协议的拓扑结构。 RDS协议： Reliable Datagram Sockets (RDS)实际是由Oracle公司研发的运行在infiniband之上，直接基于IPC的协议。之所以出现这么一种协议，根本的原因在于传统的 TCP/IP栈本身过于低效，对于高速互联开销太大，导致传输的效率太低。RDS相比IPoIB， CPU的消耗量减少了50%， 相比传统的UDP协议，网络延迟减少了一半。下图左侧是使用IPoIB协议的infiniband设备的拓扑图，右侧是使用RDS协议的 infiniband设备的拓扑结构。默认情况下，RDS协议不会被使用，需要进行额外的relink。另外即使relink RDS库以后，RAC节点间的CSS通信也是无法使用RDS协议的，节点间心跳维持以及监控总是使用IPoIB。下图左侧infiniband使用 IPoIB协议的拓扑结构，右侧是infiband使用RDS协议的拓扑结构。 SDP协议： 知道并且使用过RDS协议的人不少，但是可能不少人都没有听过sdp协议 。这个协议实际早在10g时代就存在过，只是没有专门的文档。这个白皮书算 是比较少见的。其中只是简要的提到了sdp，所著笔墨不多，也没有提到如何实现，可能在这个版本属于试验性的功能。文中提到依靠一个Oracle Application Server断的驱动，SDP协议可以与TCP/IP协议栈进行透明的转换。在11g正式讲这个功能列为new feature。Database端如何配置SDP连接可以点击这里： 11.1 11.2， Exalogic端如何配置SDP的链接可以在这里找到。甚至还有如何在java程序中使用SDP协议的案例介绍。 在实际应用中，多个Exadata机柜的相连可以通过配置SDP协议连接，Exalogic和Exadata的连接也是通过SDP‘协议的。但是需要注意 的是Oracle的Net Service目前是无法走RDS协议的。下图左侧是传统以太网tcp/ip协议栈的拓扑结构，右侧是infiniband使用SDP协议的拓扑结构。 还有可能会听过的协议有ZDP和IDB协议，这两个是新名词，如果有一点了解就知道是久瓶装新酒。iDB协议用于Exadata 数据库节点（DB node）和存储节点（cell node）之间的通信。i代表 intelligence, 言下之一就是智能数据库协议，您可不要小看它，整个Exadata的精髓offloading全靠它来完成，之所以其它第三方Oracle数据库一体机只 有Exadata的形而没有Exadata的神，原因就在此。简单的说它是由Oracle数据库内核来实现的，可以智能的将表扫描的工作放到存储一端去完 成，然后由存储进行过滤，最后只返回查询需要的数据。举个简单的例子： 比如某个表有1亿行，但是满足过滤条件的就只有1万行，数据库节点会发出一个指令告诉存储节点，“我需要查询某某表过滤条件是什么，你去处理一下，把结果 告诉我就成，我还有别的事情要忙”。这个指令就是iDB。iDB的实现是Oracle公司的最高机密，除了Exadata的核心研发团队和技术高管没有人 知道内部是如何实现的，只知道iDB协议是运行在ZDP协议（Zero-loss Zero-copy Datagram Protocol）之上，基于基于RDS协议的V3版本（OFED…

原文链接： http://www.dbaleet.org/shoug_share_session_introduction_of_exadata_core_processes/ Exadata存储服务器运行在Oracle Linux x86_64平台之上，所有的共享存储都放置在存储服务器上，除了操作系统以外，存储服务器上还使用了Exadata专有的存储管理软件。存储软件包括三大核心进程cellsrv， MS和RS。这三组进程的职责各有不同，各自都发挥着十分重要的作用。以下将逐一对这些进程进行介绍。 Cellsrv 进程 Cellsrv是Exadata存储服务器上最核心的一个进程，它是数据库服务器和存储服务器服务器之间的一座桥梁，用来处理所有的数据库服务器和存储服务器的之间的通讯。 Cellsrv通常包含以下功能： • 为简单的块请求提供服务。如果一个请求为单块读，则cellsrv将其转化为一个传统的高速缓存读取； • 为智能扫描（smart scan）提供服务，如果一个全表/全索引扫描的数据库请求中包含了direct path read，那么cellsrv则会执行与之相对应的smart scan。 • 如果使用了IORM， cellsrv对数据库服务器和存储服务器之间I/O带宽进行控制； • Cellsrv同时还会统计和收集各种与其操作相关的统计信息。   Restart server 进程   Restart server (RS)是CELLCLI命令行通过执行alter cell startup services rs 创建出来的子进程。正如其名所暗示的，它主要负责监控MS或者cellsrv等其它一些进程，它还能在其它进程崩溃或者存在内存泄漏的情况下自动完成这些进程的重启，并且不会对这些进程提供的服务可用性造成影响。在Exadata存储服务器上并不存在一个名为RS的进程，实际上RS的工作是由好几个进程共同来完成的。   如上图所示，虚线方框内的进程都是RS的组成部分，他们都以cellrs开头，如果是监控进程则会包含mt后缀。 其中 • cellrssrm为核心的RS进程 • cellrsbkm为备用的RS进程。 监控进程包括: • cellrssmt——核心主服务cellrssrm的监控进程 • cellrsbmt——备份服务cellrsbkm的监控进程 • cellrsomt——为cellsrv的监控进程，它会定时发起一种ioctl心跳消息以确认cellsrv是否存活，如果这个心跳丢失，则会创建一个adrci的时间保留现场以后，将其重启。cellsrv的状态信息存放在$OSSCONF/cellrsos.state文件内。 • cellrsmmt——为MS的监控进程。主要监控MS的http端口是否正常工作，另外监控MS的内存使用情况，确保其在正常范围以内。MS的状态信息存放在$OSSCONF/cellrsms.state文件中。 MS的告警日志信息与cellsrv的告警日志是都是存放在 $ADR_BASE/diag/asm/cell/<hostname>/trace/alert*.log里面。同时在这个trace目录下还能找到监控进程的trace文件，通常这类文件以名字中包含rstrc以标识为RS的trace文件。 Management…

原文链接： http://www.dbaleet.org/why_asm_rebanlance_hang_at_est_minutes_eq_zero/ 最早故事大概发生在一年前，当时某个客户Exadata有几个盘坏了，需要更换。当时正好我在客户现场做一个变更，正好帮忙换一下硬盘，因为Exadata换盘的步骤比较繁琐，客户也是第一次遇到这样的事情，所以也格外谨慎。变更是在凌晨，此时业务量非常小，所以索性将ASM_POWER_LIMIT开足马力调整到11。期望rebalance能快点结束。还好一切顺利，中间并没有遇到什么差错。最后一部将ASM磁盘加回到asm diskgroup也很顺利，然后不停的在刷着select * from v$asm_opearation; /之类的。两小时后，眼看EST_MINUTES就马上接近于零了，换盘工作也即将结束。于是乎就去找客户闲聊，拉拉家常。半个小时过去了，我回到座位，熟练的敲了一下/，口里还念叨了一句：no row selected大大出乎我的意料的是竟然还有记录。越想越不对，10g的ASM也算换过不少次了，从来没出现像现在这样的。难道这个参数不准？下意识的去存储节点看了下iostat的结果，发现I/O量还是很大的。这个时候已经是凌晨3点了，不应该有这么大的访问量才对呀。我又简单的看了下db的负载一切正常，这就奇怪了。干脆一不做，二不休等吧。查询v$asm_operation得到的结果基本是这样的： SQL>select * from v$asm_operation; GROUP_NUMBER OPERA STAT POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE ———— —– —- ———- ———- ———- ———- ———- ———– ——————————————– 1 REBAL RUN 11 11 5518 5917 3250 0 一个小时过去了， 没变。 两个小时过去了，不见动静。 四个小时过去了，马上就天亮了。如果还不完成的话，那么就立即到营业时间了，眼看就快过了维护窗口了，如果不能完成可能就影响到业务了。我不停的刷着/， 期望rebalace能尽快结束，终于在四个半小时小时以后出现了久违的no row selected。当时我就想肯定是这个EST_MINUTES估算值不准导致的。因为10g时代已经习惯了v$session_longops不准了。但是令人十分费解的是加几个盘也用不了这么久吧？正常情况下两个小时就结束了，Exadata号称性能最强的数据库一体机，连普通的PC server都不如？ 一个月以后，同样的事情有一次碰到，但是我不在客户现场了。这是国内某大型的金融客户。客户告诉我，他们加盘的动作是设定某个时间段进行，预估的时间是根据个EST_MINUTES算出来，然后多加一个小时，在10g时代，客户一直是这么做的。结果竟然2-3小时还没完，影响到业务了。这个时候，这个问题我已经知道是为什么了，但是我并没有说明具体的原因，只是告诉他这个估算出来的值不准，并且加盘减盘最好不要设定死固定的窗口， ASM_POWER_LIMIT不要虽然调整到最大值，设置为4就行了，这样不会影响业务。 时隔不久，竟然又有同事遇到了同样的问题，但是这次不是在exadata上，只是普通的11.2.0.2的数据。 实际上：EST_MINUTES 是按照以下公式计算的：…

原文链接：http://www.dbaleet.org/how_to_troubleshoot_asm_does_not_discover_disks/   This scenario is  far from new in a conventional Oracle database environment, there are a couple of checklist need to be done if you came across this issue.   1. Check the ownership and permission of the asm candidate disks, it should be owned by the RDBMS software owner, eg: oracle:dba, and the…

原文链接： http://www.dbaleet.org/infiniband_protocol_oracle-rac_compatible/ 上篇介绍了infiniband的的各种协议，以及他们是如何与Oracle数据库产品集成的，但是还有一个非常重要的信息没有提到，那就是在个各平台和数据库版本的兼容性。 在Oracle官方网站上有两个链接专门介绍RAC技术在Unix平台和Linux平台的兼容性。其中截取infiniband的情况如下： Oracle RAC Technologies Certification Matrix for UNIX Platforms  InfiniBand (IB) RDS over IB is supported (see notes) IP over IB is supported IBM POWER system with AIX 5.3 TL8 Service Pack 4 or AIX 6.1 TL4 with Service Pack 1 and Oracle RAC 11.1. Customers planning deployment must review MetaLink 282036.1 for details…

原文链接：http://www.dbaleet.org/how_to_apply_bundle_patch_on_exadata/   在Exadata中，数据库应用的补丁被称为Bundle Patch，简称BP （Windows上Oracle的补丁也是以BP形式发布的）。这一类型的补丁实际上是标准数据库的补丁，不包括任何Exadata特有的代码，也就是说它可以应用在Linuxx86_64平台的Oracle数据库之上。BP与标准Oracle数据库的PSU（patchset update）类似。例如BP也是累计的，最新的BP包含了之前BP的全部内容，但是同时又有其特殊性。 首先BP发布的周期较短，通常是一个月发布一次。这是因为通常情况下，Exadata并不建议打单独的one-off patch，主要是考虑到十分复杂的补丁冲突分析，以及由此带给支持后台的大量的补丁合并请求（Patch Merge Request）。   同时由于其发布的周期较短，必然会带来另外一个问题，那就是BP补丁测试可能不如PSU那么充分，甚至可能会出现有严重的问题而召回重新发布的情况发生。Exadata上决定放入BP补丁集中的补丁决定时间比较早，也就是说通常在正式发布大半个月之前补丁列表就已经冻结了，如果此后又发现新的问题，则会留到下一个版本去解决。   Oracle通常建议Exadata用户应用一种被称为QFSDP（Quarterly Full Stack Download Patch ）的补丁，QFSDP每一个季度发布一次，属于大而全的补丁集，不仅仅包括BP，QFSDP中包括了所有Exadata需要的补丁：   以下以BP16为例，介绍对GI和RDBMS应用BP的流程： 下载对应的BP和Opatch工具并将其传到db01节点上 其中BP16的补丁号为16233552，opatch的补丁号为6880880。 1. 将opatch解压到$ORACLE_HOME下，将BP16解压到/tmp下： unzip p6880880_112000_Linux-x86-64.zip -d /u01/app/11.2.0.3/grid unzip p6880880_112000_Linux-x86-64.zip –d /u01/app/oracle/product/11.2.0.2/dbhome_1 mkdir /tmp/bp16 unzip p16233552_11203_Linux-x86-64.zip -d /tmp/bp16   2. 配置OCM $ORACLE_HOME/OPatch/ocm/bin/emocmrsp   3. 分别使用grid和oracle用户检查一下OPatch 的版本是否正确： $ORACLE_HOME/OPatch/opatch version   4. 分别使用grid和oracle用户检查一下当前patch 信息： $ORACLE_HOME/OPatch/opatch lsinventory…

原文链接： http://www.dbaleet.org/how_to_enable_selinux_on_exadata_cell/ SELinux(Security-Enhanced Linux) 是美国国家安全局（NSA）为Linux设计的，对于强制访问控制的一个安全子系统。大多数Linux的发行版都在各自的内核级别启用 SELinux 的，同时提供一个可定制的安全策略。SELinux实际上是强制访问控制的一种实现，主要目的是为了控制进程可以访问的资源，能够减少或者防止0-day漏洞的探测和攻击。 在Exadata上，DB节点默认其SELInux的策略是禁止的，主要是考虑到ASM可能造成的问题：参见我之前的文章 iptables和SELinux是不是必须禁用？ http://www.dbaleet.org/is_disable_iptables_and_selinux_to_be_mandatory/ 。 SELinux有三种状态： Enforcing： 这个缺省模式会在系统上启用并实施 SELinux 的安全性政策，拒绝访问及记录行动 Permissive： 在 Permissive 模式下，SELinux 会被启用但不会实施安全性政策，而只会发出警告及记录行动。Permissive 模式在排除 SELinux 的问题时很有用。 Disabled： SELinux 已被禁用。 在Cell端，SELInux默认以Permissive的方式开启，也就意味着系统只默认将违背访问控制的的内容写入到日志文件，并不真正的实行安全性策略。 [root@dm01cel01 audit]# imageinfo Kernel version: 2.6.32-400.6.2.el5uek #1 SMP Sun Nov 18 17:02:09 PST 2012 x86_64 Cell version: OSS_11.2.3.2.1_LINUX.X64_121203 Cell rpm version: cell-11.2.3.2.1_LINUX.X64_121203-1 Active image version: 11.2.3.2.1.121203 Active image activated: 2012-12-05 18:22:16 -0700 Active image…