Maclean’s Oracle Database Tech Blog Archives

原文链接： http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_1/   Oracle的DRM可谓是臭名昭著的一个特性，更是很多DBA谈之色变的一个特性，相信不少dba有在睡梦中半夜被老板/客户的电话叫醒：“赶快过来处理一下，紧急故障，数据库宕机了”。dba半夜打车到客户现场，再alert中发现如下信息：   Mon Mar 14 04:13:13 2011 LMS1 (ospid: 24229) received an instance eviction notification from instance 1 [2] Mon Mar 14 04:13:13 2011 LMON received an instance eviction notification from instance 1 The instance eviction reason is 0x2 The instance eviction map is 7 Mon Mar 14 04:13:15 2011 PMON (ospid: 24201):…

http://www.dbaleet.org/how_to_modify_the_password_of_exadata   Exadata上的密码可谓是纷繁复杂，名目繁多。总的来说可以分为两类，一类是数据库的密码，另外一类则是操作系统用户的密码。通常在安装完Exadata以后，客户会收到一份初始的密码表，上面列出了所有以后可能用到的各类密码。例如： DB节点： The root password for all database servers is welcome1 The oracle password has been set to welcome All oracle database passwords are welcome The ASMSNMP password is welcome1 The ILOM username and password is root/welcome1 Cell节点： The root password for all storage servers is welcome1 The celladmin password for all storage…

原文链接：http://www.dbaleet.org/how_to_modify_exadata_password_policy/   使用onecommand安装Exadata的最后一个步骤会执行一个叫做ResecureMachine的过程。这个过程的主要目的就是对操作系统本身进行一些必要的安全加固。例如：设置ssh的登录超时，移除root用户的等效性，对密码进行策略进行加强等。但是这个过程增强了Exadata安全的同时，也给很多Exadata造成了一些不必要的麻烦。以下来自用户经常遇到的一些与密码有关系的case：   case 1: 无法从oracle用户/grid su到root用户；   [oracle@dm01db01 ~]$ su – root Password: su: incorrect password 原因： oracle用户/grid用户不再wheel用户组，所以无法su到root。这是系统默认的行为： 解决方法： 退出以后，直接使用root登录。不从oracle/grid之类的用户su到root。 解除限制：将这些用户加入到wheel组。 #usermod -aG wheel <username> case 2: 用户需要修改密码， 但是无论怎么输入都无法达到密码复杂度的要求； 原因： Exadata在做ResecureMachine这个步骤修改了pam_passwdqc中的密码复杂度的要求。 解决方法： 选择复杂度更高的密码。 解除限制： 去掉了pam_passwdqc中的密码复杂度限制。 #vi /etc/pam.d/system-auth 将其中的min=disabled,disabled,16,12,8替换为min=1,1,1,1,1。这样你就可以将密码设置为任何值。如果需要明白修改代表什么意思，请查看pam_passwdqc的manpage： http://linux.die.net/man/8/pam_passwdqc   case3： 用户因为输入密码多次错误，导致操作系统用户被锁； 这种情况解决的方法比较复杂，留到下篇文章。   case 4： 90天后，用户密码过期，需要重置； 原因： ResecureMachine这个步骤修改了密码的过期策略。 解决方法： 达到90天阈值以后，用户手工修改这些用户的密码。 解除限制： #chage -d 14000 -E -1…

http://www.dbaleet.org/how_to_reimage   Image的版本通常就是指Exadata软件的版本， 而reimage 在Exadata中就是对其重做镜像的意思，通俗的说就是重灌系统。在Exadata上我们用imageinfo来查看当前Exadata image的版本，用imagehistory来查看历史版本。例如：   #imageinfo dm01db01: dm01db01: Kernel version: 2.6.18-238.12.2.0.2.el5 #1 SMP Tue Jun 28 05:21:19 EDT 2011 x86_64 dm01db01: Image version: 11.2.2.4.2.111221 dm01db01: Image activated: 2012-04-13 12:38:51 +0800 dm01db01: Image status: success dm01db01: System partition on device: /dev/mapper/VGExaDb-LVDbSys1 dm01db01:   以上是在db01节点上运行的结果，能得到这些信息：当前操作系统kernel的版本， image版本（即Exadata版本）， 此image激活的时间， image的状态，以及操作系统分区的位置。当然可以使用imageinfo -all来查看更多的信息。   #imagehistory dm01db01: Version : 11.2.2.2.2.110311…

http://www.dbaleet.org/about_rac-interconnectjumbo-frame Jumbo Frame也叫9000字节帧， 此术语广泛的应用在计算机网络和存储网络行业。Jumbo在中文中的意思是“超大”。之所以叫它为超大帧，是因为传统的以太网的标准帧的最大值为1518字节，（其中数据帧1500字节， 头部大小14字节，CRC校验位为4字节）相比而言， Jumbo Frame几乎是其6倍。 那为什么要使用Jumbo Frame呢，也就是说它相比标准帧而言有什么好处呢？跟Oracle RAC的私网又有什么关系呢？ Jumbo Frame 相比传统的标准帧而言，其主要的优势在于它能减少在拆包，传输，解包过程中带来的CPU开销并且提升数据的传输效率。下面举个例子来说明一下传统的以太网标准帧对于Oracle数据块传输的一些不足之处： Oracle数据库的块大小默认为8192字节， 如果使用以太网标准帧进行传输，至少需要将这个数据块拆分为至少6个帧进行传输。在发送的过程中，发送端网卡需要将数据块进行拆分，然后再进行发送，拆分数据块这个过程单靠网卡是无法完成的，主要依靠CPU进行计算，也就是这实际是一个软件算法。这么一来拆包的过程势必会造成一定额外的CPU开销，另外我们知道CPU是多线程的，频繁的拆包必然会带来较大的上下文切换（Context Switch）的开销。在传输的过程中，目标端的网卡一直在等待所有这六个数据包就绪，如果其中的一个发送失败，则需要重传，那么这个时间，目标端的网卡除了等待什么也不能做，直到6个数据帧全部传输完成。很明显这个过程会增大传输的延迟，尤其是对于带宽较小的网络而言。最后目标端的网卡又通过一定的算法对这些数据帧进行组装，将拆散的数据帧重新还原出一个完整的数据块。这个过程与拆分的时候一样，同样会消耗额外的CPU资源。 早期的以太网采用1500字节作为标准实际上是有其历史原因的：那个时候网络普遍都是半双工的，如果采用较大的帧则可能会造成单方向的传输会长期占据所有的带宽。如果采用较小的帧，则有拆包/解包这个过程需要花费一定的时间，使得对方节点有机会进行通信。同理可以类比计算机键盘采用qwert布局而非abcde布局的原因。 现在的网络几乎都是全双工， 也就是双向收发互不阻塞。这个时候1500字节帧就显得有点捉襟见肘了。但是网络发展的时间这么长，以太网已经成为网络的标准，要兼容大于1500字节的帧比想象中难度要大很多，事实上几乎没法完全兼容的。好在可以用其它技术进行弥补，例如拆包解包需要消耗CPU资源就增加CPU资源，网络传输带宽小就增大其带宽，这些技术对于提高传输效率都是至关重要的。那为什么还需要大于1500字节的帧呢？ 理由很简单，之前已经叙述过了，还是提升CPU开销和提升传输效率。如果使用9000字节的巨帧，则对于单个标准8192字节数据块，只需要一个帧就可以进行传输了。没有繁琐拆包解包的过程，自然也就没有CPU的开销。同时不需要等待多个数据帧同时传输成功才进行组装，则传输本身的效率要更高。但是如果一个巨帧传输失败，则需要重传整个巨帧，所以如果传输失败，开销相比标准帧而言要更大，所以jumbo frame特别适合于比较稳定可靠的网络传输，例如RAC的私网通信。 Oracle的最佳实践推荐使用jumbo frame提升私网的传输效率，试验显示使用jumbo frame能提升大约10%的传输效率，见附录。但是请注意使用jumbo frame存在如下一些限制： 1. Jumbo Frame尽管听起来很诱人，但是目前还并不是IEEE的标准，所以并不是所有厂商都支持这种。（主流操作系统和交换机厂商都支持，Oracle VM server2.2不支持jumbo frame,如果需要请单独申请oneoff，见mos文档Oracle VM: Jumbo Frame on Oracle VM Doc ID 1166925.1， 另外较早的交换机可能不支持jumbo frame） 2. Jumbo Frame的牵涉面较广，不仅仅是收发的网卡的MTU size需要调整到9000, 所有涉及到私网的通信的所有交换机的MTU size都需要调整到9000, 否则节点之间可能无法进行通信。 在网络存储行业实际上很早就开始推荐使用jumbo frame作为最佳实践，例如nas，iscsi san之类的设备使用jumbo frame能明显提升传输的效率和减少cpu开销。可以自行google： jumbo frame…

http://www.dbaleet.org/how_to_reimage_remotely_without_usb/ 前面的文章讲述了如何Exadata reimage的整个过程，其中有一个问题是并不是每个software engineer都是全副武装，随身携带n个usb。如果在没有携带usb，又需要对Exadata进行升级，那应该怎么做呢？ 实际远程image是依托于sun硬件自带的一个功能叫做virtual CD-ROM。通俗的说就是可以通过ilom来加载一个iso文件到虚拟的CD-ROM，然后从这个虚拟的CD-ROM启动进而安装操作系统。 那么现在一共就有两个问题：第一个问题是如何制作Exadata的ISO镜像文件，另外一个就是如何使用ILOM来把这个ISO文件加载到这个虚拟光驱。 首先是如何制作这个ISO文件，方法在之前的reimage一文中已经提到过：使用makeImageMedia.sh脚本。具体的流程如下：准备preconf.csv文件，然后在edelivery下载Exadata Software的介质，解压以后得到dl360和dl180两个文件夹。 以下是制作db节点的iso安装镜像文件命令：   [root@dm01db01 dl360]# ./makeImageMedia.sh dbimage.iso -reboot-on-success -updfrm -stit -dualboot no -preconf /tmp/preconf.csv   以下是制作cell节点的iso安装镜像文件命令： [root@dm01db01 dl180]# ./makeImageMedia.sh cellimage.iso -reboot-on-success -updfrm -stit -preconf /tmp/preconf.csv   完成以后就会生成dbimage.iso和cellimage.iso两个文件，这两个文件分别就是db节点和cell节点的安装介质。 有了安装介质，那么怎么将挂载到虚拟光驱呢？将生成的两个iso文件拷贝到本机，然后通过浏览器登录到web版本的ilom， 进入Remote Control的标签页，然后找到Host Control， 在Next Boot Device中选择CDROM，然后附加对应的iso文件，然后选择Save。这种方式仅单次有效，再次启动会按照默认BIOS中设置的启动顺序启动， 重启主机，则系统会自动进行reimage。

http://www.dbaleet.org/exadata_faq_when_raid_cache_write_policy_will_become_write_through/   前面的文章介绍了磁盘/flash cache的两种写策略：write-back和write-through，write-through模式会影响Exadata I/O的性能。那么cache的写策略合何时会变为write-through呢？以下简单的介绍几种常见的场景，从而尽可能的避免发生这样的情况： 1. 一种最典型的是电池供电不足导致cache写策略会自动从write-back模式变为write-back模式。这里说的的电池是通用性术语，磁盘阵列控制器的电池专指备用电池单元（Battery Backup Unit 也叫BBU），flash F20卡中专指双电曾电容器（Electric double-layer capacitor也叫EDLC）。如果电池的容量不足以维持特定长一段时间（通常是24小时）的数据时，磁盘阵列控制器的cache模式就会从write-back自动变为write-through。 2. 第二种情况实际是第一种情况的特殊情况： 比如Exadata第一次加电的时候，一般磁盘阵列的cache策略是write-through模式，经过了一段时间以后就自动变为write-back了。这是因为Exadata在出厂之前其磁盘控制器的电量本身就是不足的，需要加电一段时间以后（在快速充电的模式下一般是至少是6个小时，见MegaRAID Battery Backup Unit User’s Guide第16页），电池的电量才能充满。 3. 另外一种情况也是很常见的，就是磁盘阵列控制器的电池温度过高，导致BBU停止充电。进而其cache写模式变为write-through模式。因为磁盘阵列控制器电池是锂电池或者镍氢电池，温度过高会影响到电池本身的寿命。如果电池温度大于或者等于55摄氏度，则磁盘阵列控制器电池的寿命也会从三年缩短到两年。如果电池温度大于或者等于40度，则电池无法进行快速充电（Fast Charging），只能进行微电流充电（Trickle Charging), 可见高温是电池的天敌。 4. 还有一种情况是电池本身的特性决定的，这个特性叫做learn cycle， 即电池会周期性的发生电池电量校准的现象，防止电池老化。（跟famale的period类似，XD），通俗的来说就是周期性的充电与放电的过程。整个过程如下： 1) 控制器把BBU电池充满，如果本身已满则进行下一个步骤; 2) 对BBU电池执行放电, 开始校准; 3) 放电完成后，校准完成。重新开始充电，直到充满。 这个过程叫做auto learn的过程，在不同的Exadata版本，learn cycle的周期是不同的，在Exadata 11.2.1.3之前，这个过程每1个月发生发生一次，在11.2.1.3以后，修改为每3个月一次。 在learn cycle的过程中，磁盘阵列控制器的cache策略自动变为write-through。你可以在cell节点的alert中看到类似的信息： “The disk controller battery is executing a learn cycle and may temporarily enter WriteThrough…

原文链接： http://www.dbaleet.org/exadata_f20_flash/ 在Exadata一体机中，大量的使用了flash加速技术以提高其I/O的读写性能。在之前的文章中有提到了磁盘的性能指标，目前仅限于传统磁盘的读写速率，还无法满足I/O密集型的OLTP系统的要求，Exadata可能会在这些方面出现I/O性能瓶颈。所以在Sun的Exadata V2时代开始，每个存储节点就提供四块96G的F20卡，也就是说每个存储节点提供384G的Flash存储空间。 下面具体来看一下F20卡的部分参数指标： 注意到其中的几个关键的性能指标：随机写88000 IOPS，  顺序写101000 IOPS， 顺序读1.1GB/s, 顺序写567MB/s，另外其访问延迟也是非常小。不过这只是F20卡的纯粹技术指标，而没有考虑DB和Exadata。在磁盘IOPS计算一文中曾经有提到，在数据库服务器上小于8k的I/O请求都是没有意义的。所以在Exadata上这个指标需要重新评估，所以在Exadata的datasheet中提到单块F20卡的Database IOP为375000/3/4=312500, 比4k的I/O请求测试出来的IOPS慢了3倍多（笑）。 除了性能的指标以外还有容量指标，单块F20卡的实际可用空间为96GB, 实际裸容量为128G。这是怎么回事呢？ 再回答这个问题之前，我们先来看一下F20卡内部结构的布局。 一块F20卡实际上是由四个固态闪存模块（FDOM）组成的， 也就是图中所表示的DOM（Disk on module）, 这个词没有合适的中文翻译，可以简单的认为它是一个ssd设备，但是提供更灵活的接口机制。例如F20卡就是使用PCIe的接口，直接插在主板上的，所以Oracle公司一再强调not flash disks, 就是为了说明这个PCIe的接口能够不受到磁盘控制器接口（例如SAS和SATA）速度的限制，单卡能够提供1GB/s的带宽，而4块卡其带宽几乎是线性扩展。 每个DOM包含8个（4个在前，4个在后）4GB的SLC NAND 组件， 一共为32GB，但是确只有24GB的空间是可寻址的，也就是说只有24GB是系统可识别的，另外的8GB作为备用空间用作地址重定向使用。这种方法是固态硬盘设备为了延长使用寿命最常用的办法。不过无须担心，NAND为企业级的闪存，通常比消费电子品所用的闪存寿命更长，使用寿命一般在5年以上。 F20卡还包含有电源存储模块ESM（Energy Storage Module ）, 也就是我们常说的电池。实际上它并不是常规意义上的电池，而是一个叫做超级电容（supercapacito）的东西。它和普通的电池相比， 具有寿命更长，充放电率高，功率更高的优点。不过这种ESM只有2-3年的寿命（Oracle Exadata Owner‘ Guide上说的是3-4年， 这里以 Sun Flash Accelerator F20 Energy Storage Module (ESM) Lifespan. [ID 1327000.1]文档为准，早期的计算ESM的耗损率以两年为基准，现在基本都是以三年的寿命来计算的），2-3年以后需要更换这个ESM，更换ESM的时候，可以用rolling的方式进行，只在存储节点段逐一进行，而不需要停止数据库。 如果ESM的电量耗尽，则闪存的写模式自动从write-back切换到write-through模式，造成性能下降。当然Exadata Smart Flash Cache（ESFC）这个特性早期只能使用write-through的模式，所以通常不是什么大问题，而使用write-through模式的FSFC性能提升比较有限。在最新版的Exadata 11.2.3.2这个版本（X3都是在这个版本以上）正式引入ESFC的write-back的写模式，这个特性才真正开始发挥ESFC的威力，下一篇将介绍这方面的内容。 F20卡的技术细节，可以在F20的用户手册中找到。

Exadata X2-2 db节点系统盘的RAID是如何配置的？ http://www.dbaleet.org/exadata_x2-2_db_node_raid_configuration/ 在前面的如何reimage一文中提到， 在制作db节点的镜像的时候有一个dualboot的参数，我们需要额外将其指定为no，但是当时没有详细说明为什么一定需要指定这个参数，这里进行更深一层次的解释。 在db节点上一个有4个300G的SAS盘，这些都是本地盘，上面安装有操作系统，Exadata， 以及Oracle RAC软件。在MOS 1274318.1 Oracle Sun Database Machine Setup/Configuration Best Practices 中推荐将其中的三块盘做RAID 5, 另外一块盘作为热备（hot spare）。     For X2-2, there are 4 disk drives in a database server controlled by an LSI MegaRAID SAS 9261-8i disk controller. The disks are configured RAID-5 with 3 disks in the RAID set and 1…

iptables和SELinux是不是必须禁用？   http://www.dbaleet.org/is_disable_iptables_and_selinux_to_be_mandatory/   在刚开始学习Oracle的时候，很多老鸟告诉我应该关闭操作系统的iptables和SELInux，因为Oracle不支持， 否则会遇到无穷无尽的问题，打开iptables和SELInux就是给自己找麻烦。所以我每次安装Oracle Database的时候，第一件事情就是关闭iptables和SELinux，甚至后来在安装的时候就选择了禁用，所以iptables和SELInux形同虚设。其实我也不明白为什么需要关闭，却一直没有深究，只是觉得照做就对了。相信很多人也和我一样有着同样的经历。   但是，事情总是在发展的。。。 首先来说iptables， 很多人一直有一个误解，认为Oracle RAC是不支持iptables的。 实际上， 准确的说法是Oracle不推荐在私有网络之间使用iptables。因为可能会干扰到节点之间的心跳和数据交换，而从导致ipc timeout， crs进程无法通信等错误最终导致节点被驱逐。另外如果限制了udp通信的端口，则私网之间的global cache 通信的效率也会受到影响。 以下是对MOS文档554781.1 RAC instabilities due to firewall (netfilter/iptables) enabled on the cluster interconnect 的引用：   Oracle RAC uses the cluster interconnect to send buffer cache blocks between instances running on different nodes. The cluster interconnect is also used for…