Maclean’s Oracle Database Tech Blog Archives

http://www.dbaleet.org/exadata_configuration_tools_onecommand/   最早Exadata安装部署过程十分繁琐，几乎所有的步骤都需要手工完成。对于非Oracle Database和Linux的专家，几乎是不可能完成的，当时除了X team的几个成员以外，其它人很少能够在一周以内完成一台Exadata的安装。从V2开始（我也不是太确定），Oracle引入了一个新的工具叫onecommand，从它的名字就可以看出，这个工具用于简化Exadata安装的流程，提供傻瓜化的安装过程，一条命令就可以搞定。 而onecommand本身的历史却更早，这个项目的雏形是Oracle的一些员工旨在方便大规模部署Oracle RAC减少重复劳动而编写的一个工具，用户只要提前填写好一个配置文件，就可以通过一个脚本在30分钟以内安装完成GI的安装，在网上可以找到一些ppt： One Command Install How to Install the Grid in 30 minutes Lessons from the RAC Pack: How to install Grid in 30 Minutes   但是每几个人见过这个onecommand的真容，也无法找到这个用于RAC安装的onecommand版本。看完上面这两个ppt，就会发现Exadata上的onecommand实际就是由用于安装grid的onecommand发展演化起来的。 到了Exadata时代，onecommand也是一直在不停的演化。这两年来onecommand的版本的一直在变化。从早期的33步发展到现在的28步，从仅仅支持V2版本到支持几乎所有的Exadata版本（包括最新的X3）, 从单纯支持Linux，到支持Solaris（X86，SPARC）， 从早期的纯shell脚本到采用perl完全重写（为了保持兼容调用的接口还是使用shell，但是核心功能都是perl来实现的），当然这些仅仅只是冰山一角。可以这么说正是onecommand使得Exadata真正实现了安装傻瓜化，标准化，个性化。   将dbm configurator生成的内容全部拷贝到onecommand目录下，就可以开始使用它了。onecommand中的command指的实际上是deploy112.sh这个脚本。deploy112.sh默认安装的数据库版本是11.2.0.2, 如果要安装11.2.0.3则需要运行deploy11203.sh这个脚本。运行deploy11203.sh -h查看帮助， 可以看到这个命令有三个选项：   -l 列出所有的安装步骤 -s <step #> 运行具体安装步骤 -r <num-num> 如果没有报错的话，连续运行安装步骤。 # ./deploy11203.sh -l INFO:…

原文链接： http://www.dbaleet.org/exadata_configuration_tools_onecommand_2 最近陆续收到几名读者的反馈，说我以前的一篇文章Exadata的配置工具——onecommand http://www.dbaleet.org/exadata_configuration_tools_onecommand/ 对于Exadata onecommand的功能描述的不是很具体，希望能更详细的了解每个步骤实现的功能。另外之前那篇文章在介绍onecommand的功能的时候也有一些小错误，所以我这里再旧话重提，一来是更正以前的一些说法，二来则是更详细的介绍一下onecommand每个步骤完成的功能。 以下还是以27个步骤的版本为例进行说明： Step 0 = ValidateEnv Step 1 = CreateWorkDir Step 2 = UnzipFiles Step 3 = setupSSHroot Step 4 = UpdateEtcHosts Step 5 = CreateCellipinitora Step 6 = ValidateIB Step 7 = ValidateCell Step 8 = PingRdsCheck Step 9 = RunCalibrate Step 10 = CreateUsers Step 11 = SetupSSHusers Step 12 =…

http://www.dbaleet.org/exadata-faq_how_to_choose_exadata_os_linux_or_solaris/ 在安装Exadata之前，部分客户会问道：既然Exadata的操作系统既可以使用Solaris，又可以使用Linux，那么我应该如何选择？能不能给我们点参考意见？ 对于用户而言，没有最好的，只有最合适的。我这里并不想深入的对两个操作系统进行深入的比较，只是谈谈一些事实和个人的意见，仅供参考。当然最终决定权还是用户的手里。 以下列举一些事实： 事实一： 首先并不是Exadata的操作系统既可以使用Solaris，又可以使用Linux。准确的说法应该是DB节点的操作系统可以选择Solaris或者Linux，这里的Solaris不是Sun小型机使用的SPARC架构，而基于Intel/AMD的X86_64架构，也就是说是Solaris i86pc。而cell节点的操作系统只能是Linux。以下除非特别注明，否则Solaris i86pc统称为Solaris。 事实二： Solaris 11 不是一个免费的系统，是需要单独付费license的。参见Oracle Solaris 11 Frequently Asked Questions， Solaris 11只提供30天的评估试用。   How can I obtain an Oracle Solaris license for a system purchased on the open market, given that an Oracle Solaris license is non-transferable? For Oracle systems purchased on the open market, you may obtain…

原文链接： http://www.dbaleet.org/what_is_new_in_exadata_x3-2/   Oracle在2012年的10月的openworld宣布了最新一代的Exadata一体机X3, 时间已经过去快半年了，但是很少有看到全面介绍X3的中文文章。故我这里以对比的形式列出X2-2和X3-2的软硬件的异同，读者可以通过对比来发掘X3到底都有哪些料。（注：X3-8不在此讨论范围）   DB节点  从上面可以看出最大的一个变化在于CPU从Intel Xeon L5640 （Nehalem平台）升级到了Intel Xeon E5 (Sandy Bridge平台)。Intel宣称Xeon E5充分利用了其睿频（Turbo Frequency (MHz)）技术，所以能以更低的主频提供更高的性能，并且单核的电压更低，更省电。以下是CPU world对这两者参数的对比图：   其中一个比较显眼的地方是其中Xeon E5支持AVX指令集，Intel声称其能大幅提升浮点运算的性能和Linux平台RAID驱动的性能。关于AVX的性能提升可参看IBM印度工程师Nagarajan Kathiresan的文章http://spscicomp.org/wordpress/wp-content/uploads/2012/05/ScicomP-2012-Prabhakar-Kathiresan-AVX.pdf, 不过从传统的TPC-C以及SPECint的测试对比结果来看，Xeon E5的性能与IBM Power 7大致持平，当然IBM利用其Turbocore技术，在单核上性能有明显的提升，但是就吞吐量而言却显得更慢。 内存方面， 也由原来的X2-2 96G内存升级到X3-2的128G，单个DIMM模块的大小也从原来的8G升级为16G，一台满配的Exadata（8个DB节点）就从原来X2-2的96G×8=768G扩展到X3-2的1TB，另外还有一点就是单个DB节点最大内存限制也从X2-2平台最高144G扩展到了X3-2平台的256G。 网络方面，从原来X2-2的4块千兆以太网网口升级为4块千兆/万兆自适应的以太网网口。但是如果需要使用万兆的以太网，用户依然需要自掏腰包单独购买万兆以太网的SPF+光纤模块。 另外在PCIe总线上，也有原来的PCI-e 2.0升级为PCI-e 3.0， PCI-e总线的带宽理论上提高了1倍，但是同时需要特定的PCI-e 3.0的卡支持。   Cell节点   相比DB节点而言，Cell节点的升级就显得有些波澜不惊。 CPU方面，6核的E5-2630L 2.0G与6核 Xeon L5640 2.26G性能大致相当，变化不大。 内存方面， 由原来X2-2的24G内存升级到X3-2的64G, 一来是内存颗粒的工艺有了进步，使得内存的价格更低，二来主要是因为闪存卡的容量增加了4倍，需要管理这些闪存卡实际上需要更大的内存做支撑。 闪存卡方面的变化可能是最引人注目的了。Exadata X3之所以号称Database In-Memory Machine， 闪存卡容量是最重要的一个方面了。Exadata的闪存卡从原来X2-2的4×96G=384G直接升级到了X3-2的4×400G=1600G，容量增加了4倍，所以Larry Ellison就单凭借这一点来当作嘲笑SAP hana的砝码。可见波澜不惊只是表面的，实际上还是暗藏汹涌。而新的F40卡相比较F20卡， 更耐擦写，寿命更长，读写的速率也有较大幅度的提升，F40卡的读写速率接近是原来F20卡的1.4倍，其相应的ESM模块的寿命也更长，防止写性能降级。 其他方面 其它组建基本没有太显著的变化。例如硬盘，infiniband交换机， PDU，值得一提的是X3系列去掉了KVM（Keyboard，Video，…

原文链接： http://www.dbaleet.org/auto_disk_management_feature_in_exadata/   众所周知，Exadata使用的是自动存储管理（ASM）来管理它的物理磁盘，这意味着以前所有在ASM上的特性在Exadata上仍然是适用的，但是同时Exadata的磁盘管理方式依然有其独特之处。本文需要介绍的是Exadata特有的自动磁盘管理特性（auto disk management）。 自动磁盘管理，简而言之，就是Exadata能够自动的对磁盘的某些行为进行识别，从而对这些行为进行自动判断，从而自动完成特定的工作，以减少干预干预，减轻Exadata管理员的工作量。 这些自动管理的工作包括以下几个方面： grididks自动在线离线（griddisk offline/online） 如果一块griddisk暂时无法访问，（并不意味着一定是磁盘损坏，有可能是cellsrv进程状态不正常）那么其在ASM中的状态就是自动变为offline， 如果在某一时刻变为可用，则其对应的ASM磁盘会自动变为online状态。 gridisk自动删除（griddisk drop） 如果一块physical disk失效了，那么在这块physical disk上所有的griddisk在ASM中会被自动的强制的drop掉（drop force） 如果physcial disk的状态变为predictive failure， 那么这块physical disk上所有的griddisk在ASM中会被自动的drop 如果flashdisk性能出现下降，那么其对应的griddisk会在ASM中被自动的强制的drop掉（drop force） griddisk自动添加（griddisk add） 如果更换了一块物理盘（physical disk），那么这块physical disk对应的celldisk和griddisk会被自动创建，并且自动的加到asm磁盘组中。但是有一个重要的前提就是之前损坏的physical disk是Exadata自动强制删除的才会有效，如果griddisk是被手工使用删除并且没有使用force选项的，那么更换physical disk以后则必须手工的加回到asm磁盘组。 在正常情况下，如果我们使用force选项手工从ASM磁盘组中删除一块griddisk，那么这块griddisk会被自动重新加回到ASM中。所以在正常情况下，如果需要把一块griddisk从asm磁盘组中删除，那么请不要使用force选项。 cell image滚动升级的时候自动online/offline（griddisk offline/online for rolling Exadata software (storage cells) upgrade） 在进行exadata存储节点cell image升级之前，所有的griddisk在asm中会被自动offline，等到cell image升级完成以后，所有的griddisk在ASM中又会重新online。 griddisk手工激活与去激活（Manual griddisk activation/inactivation） 如果一块griddisk在cell上被去激活，那么其在ASM中会自动变为offline的状态， 如果一块griddisk在cell上被重新激活，那么其在ASM中又会重新变为online的状态。 下图总结概括了Exadata自动磁盘管理的触发条件：     但是依然有两类情况需要人为干预的： 1. 因同一AU在所有的镜像都已经丢失或者同时不可访问导致的磁盘组dismount，需要其可访问之时手动重新mount。…

原文链接： http://www.dbaleet.org/exadata_sundiag/   sundiag是exadata上收集磁盘信息的利器，这个脚本十分全面，涵盖了与磁盘包括flash盘有关的所有信息。在早期的与HP合 作的Exadata V1上不存在这个脚本，从脚本的命名方式就能看出来，是属于收购sun以后的产物。Exadata V1类似的脚本，名字叫GetSCConf.zip , 相比sundiag而言，这个脚本非常简陋，仅仅只能查看cell, lun, physicaldisk, celldisk, griddisk的信息。   在exadata image 11.2.2.2.0版本以后都自带这个脚本，此脚本位于# /opt/oracle.SupportTools/sundiag.sh。Solaris X86也存在对应的版本，收集到的信息与Linux基本一致。   如果您怀疑Exadata机器的磁盘有损坏，例如机器有盘亮黄灯，就可以在这台机器上运行sundiag，完成以后会生成对应的一个压缩包，然后将 其上传到SR，供Exadata后台支持工程师分析。在很多硬件相关的SR中，SR工程师通常也要求客户上传sundiag的信息以供诊断。所以掌握 sundiag的使用对于Exadata维护工程师至关重要。一下就是对这个脚本进行简单的分析，看sundiag收集了一些什么信息。   这个脚本本身比较简单，但是涵盖了所有与磁盘相关的信息。 #!/bin/bash # Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved. megacli_status () { CONT=”a0″ STATUS=0 MEGACLI=/opt/MegaRAID/MegaCli/MegaCli64 echo -n “Checking RAID status on ” hostname for a in $CONT…

原文链接：http://www.dbaleet.org/collect_exadata_diagnostic_info_via_ips/ IPS是Incident Packaging Service的简称，即事件打包服务。在此之前，能提供打包服务的一般是物流公司，例如Fedex或者UPS。从Oracle 11g开始，Oracle也介入这个行业与他们开始正面竞争了。   事件打包服务是FDI(Fault Diagnosability Infrastructure)故障诊断基础架构中的一项技术， 属于ADR的一部分。IPS可以针对某一特定错误或故障相关的数据进行打包，一次性收集诊断此问题需要的日志，例如traces, dumps, health check reports等，免去多次索要和提供日志之苦。Just wait for 1 minutes. 收集日志我用diagcollection.pl脚本不就行了么？何苦还需要另外学习收集日志方式？ diagcollection.pl一般用于收集集群某个特定时间段的信息，或者某种特定类型的日志，例如chm；而IPS通常使用来收集数据库或者cell软件的诊断信息，例如可以用它来针对某一错误进行日志收集，例如ORA-00600，这两者并不冲突并且可以互补。   在Exadata上除了可以使用IPS收集DB节点的日志信息，还可以使用它来收集Cell节点的日志信息。DB节点的收集方式同样可以用于非Exadata的数据库，Cell节点的收集方式仅用于Exadata。以下分别讲述如何在DB节点和Cell节点使用IPS收集日志信息。我这里并不打算介绍所有的IPS的特性，仅仅只是针对某一错误进行日志收集。   DB节点：  进入adrci界面: $adrci adrci> help ips HELP IPS [topic] Available Topics: ADD ADD FILE ADD NEW INCIDENTS CHECK REMOTE KEYS COPY IN FILE COPY OUT FILE CREATE PACKAGE DELETE PACKAGE FINALIZE PACKAGE…

原文链接：http://www.dbaleet.org/how_to_take_systemstate_dump_on_exadata_cell/   有经验的Oracle DBA都知道， 在Oracle数据库上分析挂起（hang）或者性能问题有两大利器：hanganalyze和systemstate dump。在Exadata上不仅仅DB节点可以做systemstate dump，Cell节点同样也可以做Systemstate dump。 在cell端的systemstate dump主要用于诊断cell节点核心进程cellsrv的异常，例如内存CPU占用率高，cellsrv挂起的并在cell节点的alert中有报RS-7445 CELLSRV HUNG的错误。 Cell节点的systemstate dump有两种方法： 方法一. 利用 cell event （推荐） cell event是在Oracle内部都未公开的用于诊断和调试（debug）cell软件的一系列事件。相信随着时间的推移，越来越多的event会逐渐露出水面。（我也会在blog公开一些cell events的使用方法） 在cellcli运行alter cell events = “immediate cellsrv.cellsrv_statedump(2,0)”命令就会生成一个cell systemstate dump的trace文件。 CellCLI> alter cell events = “immediate cellsrv.cellsrv_statedump(2,0)” Dump sequence #1 has been written to /opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/log/diag/asm/cell/sinacel01/trace/svtrc_25081_91.trc Cell sinacel01 successfully altered 这里的2猜测是statedump的level。当然在根据mos上的描述，此参数为0的用法也是可以的。 CellCLI> alter cell events =…

http://www.dbaleet.org/about_infiniband_sdp_protocol/ 在前面的文章 Infiniband可以运行哪些协议？中介绍了基于infiniband的各种协议。引入infiniband架构的目的在于解决传统以太网遇到的一系列问题，并且提供高速的互联技术。在一个数据中心，互联并非仅仅指的是数据库节点之间的互联。有时你会发现瓶颈并不在数据库，而在于中间件与数据库之间的互联。本文要将的SDP协议就是为了解决中间件与数据库连接的短板而诞生的。 SDP的全称是Sockets Direct Protocol，它是InfiniBand Trade Association (IBTA)制定的基于infiniband的一种协议，它允许用户已有的使用TCP/IP协议的程序运行在高速的infiniband之上。所以引入SDP的目的无非有两点: 第一是能够将已有的运行基于sockets的程序透明的运行在infiniband之上； 第二是充分利用infiniband的高带宽的同时保持很低的开销。 基于以上两点，SDP的整体架构图如下：     SDP 协议提供可靠的字节流、类似于TCP的流量控制双向数据传输。InfiniBand开发通过libsdp C 库使用 SDP，这个库支持应用程序的基于套接字的 SOCK_STREAM 接口。 ORACLE支持两种不同版本的SDP协议，transparent SDP和Native SDP。 transparent SDP是指在应用程序端无须任何修改就能使用的SDP协议。它的实现方式是将TCP连接转化为SDP连接， 故在应用程序层面无需任何修改，在数据库层面也只需要进行一些很简单的配置，其配置方法可以参考这篇文章。 Native SDP是Oracle Database 10gR2的新特性，是指在listener和TNS中显式指定使用protocol=sdp，在10gR2的Net Services Admin Guide文档中，有提到具体如何进行配置，这里不赘述。从以上信息可知，实际上从Oracle Database10gR2开始， Oracle支持Native SDP。如果更早的版本需要使用SDP协议，就只能使用transparent SDP。除此以外，transparent SDP和Native SDP的一个最大的区别就是： transparent SDP只支持synchronous I/O， Native SDP则支持asynchronous I/O。也就是Native SDP可以提供更好的性能，而Transparent SDP相对其性能较差，但是其优势在于无需应用程序端做任何修改，即便如此， 目前使用Transparent SDP的infiniband依然要比基于TCP/IP的以太网提供了更高的带宽/速率。 SDP在传输数据的过程中也有两种I/O模式， 即Buffer Copy（Bcopy）和Zero Copy（Zcopy）     那么到底什么是Buffer-Copy，什么是Zero-Copy，两者有什么区别呢？当然需要回顾一下操作系统中的知识。 以下以Linux操作系统为例进行说明，当然其它操作系统也是类似的。 Linux的传统I/O操作实际上是一种缓冲I/O， I/O 操作过程中产生的数据传输通常需要在缓冲区中进行多次的拷贝。…

原文链接：http://www.dbaleet.org/interpret_cvunew_features_in_11gr2/ 对于这篇文章的绝大多数读者而言，CVU已经不是新面孔而是老朋友了，所以我这里并不打算介绍什么是CVU，而是介绍它在11gR2中的一些新特性和增强型功能。 Oracle在Oracle 10gR2时代开始引进CVU的功能，但是一直是作为一个独立的工具，对数据库的各项配置信息进行检查。一个最显著的变化就是从11.2.0.2开始，CVU已经作为一个集群资源集成到grid infrastructure 中。   [root@db01 ~]# /u01/app/11.2.0.2/grid/bin/crsctl stat res -t ——————————————————————————– NAME TARGET STATE SERVER STATE_DETAILS ——————————————————————————– Local Resources ——————————————————————————– …… ——————————————————————————– Cluster Resources ——————————————————————————– ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE db04 ora.LISTENER_SCAN2.lsnr 1 ONLINE ONLINE db03 ora.LISTENER_SCAN3.lsnr 1 ONLINE ONLINE db02 ora.cvu 1 ONLINE ONLINE db01 ora.dbm.db 1 ONLINE ONLINE db01 Open 2 ONLINE ONLINE…