Maclean’s Oracle Database Tech Blog Archives

Maclean对Oracle社区的一点点小建设，欢迎大家不吝指正不足之处，今后我会加倍努力的    

原文链接: http://www.dbaleet.org/how_to_troubleshooting_cell_node_high_cpu_issue/ 事实上，Exadata Cell节点CPU占用率高的情况并不常见。主要是原因有两点： 一是当前Exadata smart scan发生的条件限制较多，通常情况下能够offload到cell节点进行运算的任务并不占绝大多数。 二是当前Cell节点CPU的运算能力实际上已经完全足够，在正常的情况下Cell节点CPU的空闲率都是比较高的。 而Cell节点CPU占用率高也分为所有的Cell节点CPU占用率都很高，还是只有一台或几台Cell节点占用率很高。这两者通常是不一样的，因为正常情况下，一个offloading的任务会均匀分布到所有的Cell节点上，如果所有Cell节点都很高的时候，通常说明当前系统负载较高。但是如果只有一台或者几台Cell节点CPU占用率高，那么这个大多数情况下不是正常的。本文讨论的情况属于后者。 那么如何诊断这一问题呢？可以试着按照以下步骤来解决： 是否为硬件的问题? 系统硬件的问题通常比较好判断，可以通过以下方式进行。（如果确定不是硬件问题，可以跳过这一步。） 查看操作系统的/var/log/messages和dmesg，看是否有任何报错信息； 登陆到ilom的faulty shell查看是否有faulty的信息： ->show /SP/faultmgmt ->start /SP/faultmgmt/shell Are you sure you want to start /SP/faultmgmt/shell (y/n)? y faultmgmtsp> faultmgmtsp> fmadm faulty -a No faults found faultmgmtsp> exit ->  运行Linux命令sosreport收集硬件的诊断信息。 exachk是否有帮助? exachk is your friend. 在Exadata中，出现任何与数据库无关的问题的时候最好都运行exachk进行健康检查。exachk收集的信息很全，省去大量人工收集的繁琐步骤。并且收集完成以后，可以在整体上对系统的健康状况做一个评估，从中发现一些可疑点，进而缩小范围进行下一步的诊断。 通过操作系统的命令查看进程信息？ 如果问题在当前环境下还存在，那么可以直接从操作系统中获取有用的信息。 在cell上运行top命令来查看当前最消耗CPU资源的是哪个/哪些进程。然后获取其pid。 如果是cellsrv进程占用cpu很高，可以考虑对其做一个systemstate dump。方法可以参考我之前的一篇文章。 如果是java进程，可以使用jstack来查看和分析其thread dump。jstack的语法如下： jstack [-l]…

原文链接： http://www.dbaleet.org/shoug_share_session_how_to_troubleshoot_and_fix_high_version_count_issue/ 在Oracle 10g以上的版本，High version count可谓是一个臭名昭著的问题。Hight version count不仅仅产生的原因多种多样，并且会导致各种令人头痛的问题，轻导致数据库的性能急剧下降，CPU利用率剧增，重则导致数据库挂起，触发ORA-04031或者其它bug导致宕机。 什么是verion count，什么是high？ 在弄清楚诊断和解决这个问题之前，首先需要清楚什么是version count，什么是high？换而言之就是产生version count的原因，多高的version count才算high。 一个SQL 第一次执行时，会进行硬解析，同时创建parent cursor 和child cursor。 当再次执行这个SQL时，那么首先会对SQL 语句进行特殊的hash 运算，对应生成一个hash value。Hash value存放在parent cursor中，然后会用这个hash value到paranet cursor的bucket中匹配，如果相同的hash value 已存在parent cursor里，则继续遍历这个child cursor，如果可重用，那么就沿用child cursor的信息，如果不能重用，就会重新生成一个新的child cursor。 一个parent cursor下child cursor 的总数，就是这个SQL的version count。 事实上，我们很难去准确定义一个high version count的值，只能根据不同的系统来判断是否为high verison count。在AWR报告中，默认verion count超过20的SQL就会显示在order by version count一栏中。根据经验version count如果超过100，可能就需要引起注意了。 我们可以通过查看v$sqlarea视图的loaded_versions来判断当前这个SQL的version count是多少，然后再通过address的值来查询v$sql_shared_cursor视图看那些字段的返回值为Y，Y代表mismatch。Mismatch是引起产生version count的直接原因。通常我们可以综合： v$sqlarea, v$sql_shared_cursor, v$sql_bind_metadata, v$sql_bind_captures来诊断这类问题，但是手工去查这些表往往过于繁琐，  Abel…

原文链接：http://www.dbaleet.org/what_if_two_disks_reside_different_cell_failure_will_lead_to_data_corruption/ 在 如何升级Exadata 存储节点cell image这一篇文章中提到：在升级一个cell的过程中，由于此时这个cell的所有的磁盘都是离线的，这个cell上的盘没有被drop并且完成镜像的重组，那么也就意味着这个cell上的所有的数据在其它cell中只有一份镜像，假如其它cell节点此时同时出现了坏盘，则有可能导致数据的丢失。 有个同学追问道： 是不是只要是不不同Cell同时发生两块以上的坏盘是否会导致数据的丢失？如果不是，那么是我有没有办法知道是哪些盘损坏可能造成数据丢失？这个概率有多大？相比传统的raid 10相比如何？ 我想说： theses are  really good questions，but you just asked too many. 天气太热，记得多喝水。 回到正题上，这个课题其它可以写满满一篇论文了，尤其是后面那个概率的问题。我这里只是简单的描述下，因为大多数人不要关心如此多的细节。Anyway, we are engineers, not scientist. 我们知道， ASM与传统的RAID技术的冗余方式并不一样，ASM不是以disk而是以extent为单位的，而这些extents会分布在多块磁盘中，此时ASM引入概念将其称为Partner DIsk， 这些Partner disk会有系统分配放置在一个或者多个failure group上。假如其中的一块磁盘操作失败，那么ASM会更新其extent map，然后只对其正常状态的Partner disk进行操作。注意：以上只是针对ASM Normal Redundancy而言，External Redundancy没有partner disk的概念。 在10g版本中，ASM failure group中的每一块盘都会存在最多10个DIsk partner，而在11gR2中默认的disk partner 的数量为8, 它是受到隐含参数”_asm_partner_target_disk_part”控制的。也就是说，对这块盘的数据镜像分布在其它8块partner disk中。 在一台1/4配的Exadata中，通过以下SQL查询 group#=1 disk#=0的partner disk的分布情况。 select DISK, NUMBER_KFDPARTNER, NAME, FAILGROUP from V$ASM_DISK…

原文链接如下： http://www.dbaleet.org/understand_rac_cluster_health_monitor_overview_of_chm Oracle Grid Infrastructure在11.2.0.2开始集成了一个新的功能叫CHM（Cluster Health Monitor），从名字就能猜测到CHM是一个用于Oracle集群健康状况的监控的工具。然而CHM并非是一个brand new utility，而是由一个被称为Instantaneous Problem Detection OS Tool (IPD/OS) 的工具发展演化而来，直到11.2.0.2, Oracle RAC的product management team终于决定把它集成到GI中，成为GI的一个标准QoS组件。 Oracle RAC有一类非常令人头疼的问题——节点的驱逐问题，相信每个在这个行业摸爬滚打多年的老dba或者技术支持工程师会对此深有体会。 一种非常典型的情况是： 从操作系统的日志来看，发起系统重启的命令的是Oracle的ocssd.bin进程，但是在操作系统层面却没有更多其它信息，CRS/GI中的日志也是空空如也，最多出现一些类似于节点网络心跳超时的错误。这类案例屡见不鲜，最终分析的结果往往是怀疑当时的心跳网络出现闪断，或者由于某节点操作系统负载过高出现内存不足的情况或者是Oracle的bug。但因缺乏足够的证据，建议将crs diagwait设置为13（10g）,并且安装OSW bb对操作系统的资源进行监控。如果这个问题不再出现，就往往成了一桩无头案，最终不了了之。事实上，这种结果是谁也不愿意看到的，但是dba也很无奈，因为系统或者网络与数据库往往属于不同的职能部门，在一个大型的企业需要协调其它部门的资源往往只是一厢情愿的事情，当然一般能很快能得到回复：网络监控没有发现什么异常，系统负载没有什么问题，当时的日志已经被清空，诸如此类。甚至很多客户根本就没有部署任何监控，dba要部署一个osw bb遇到的阻力却非常大。如果Oracle RAC能自带一个系统性能监控的工具，那么对于这些dba而言， CHM的出现可以算得上是福音了，或许CHM也同时意味着混沌扯皮背黑锅的时代即将结束。也许过几年回过头看，这段时间可以算得上是dark ages了。 废话少说，进入正题。从CHM的faq note（文档号1328466.1）和 Introducing Cluster Health Monitor (IPD/OS) (文档号736752.1)两篇文章我们可以窥测出关于CHM的大致情况。我这里将其信息整合起来并结合我所知道的一些所谓内幕，总结到如下几点： 1. 引入CHM的初衷是用于诊断操作系统重启，hang， 节点驱逐，性能骤降等一系列需要操作系统性能信息的问题。在Oracle支持网站的服务请求中，这些问题可以归结为一大类了，这样的惨案可谓多到数不胜数，用印地语来说就是多到比恒河的砂子还多，但是Oracle却一直没有处理这类问题的一件真正神兵利器，所以CHM的出现也就顺理成章，众望所归了。如果将OSW bb比作屠龙刀，那么CHM就是倚天剑了。 2.  在11.2.0.2开始， Linux平台和solaris平台的GI开始集成CHM；11.2.0.3开始AIX平台和Windows平台的GI开始集成CHM；如果使用更早的版本， Linux平台可以到http://www.oracle.com/technetwork/database/clustering/downloads/ipd-download-homepage-087212.html下载，Windows 32位可以到http://download.oracle.com/otndocs/products/clustering/ipd/crfpack-winnt.zip下载， 其它平台不提供单独下载。如果GI已集成CHM，请不要再单独安装，否则会造成冲突。CHM暂不支持HP Itanium平台，如果需要类似的功能只能使用OSW bb。 3. 从功能上看，CHM和OSW bb很多都是重合的，那么为什么不集成OSW bb来做同样的事情呢呢？CHM的原理是使用操作系统API来获取系统性能监控信息。注意CHM和OSW bb等监控工具并不是一样的， OSW…

原文链接： http://www.dbaleet.org/understand_rac_cluster_health_monitor_usage_of_chm 上篇文章对CHM做了一个整体的概述，本篇则着重介绍CHM的架构以及如何使用CHM收集操作系统的性能诊断信息。 一. CHM架构： 以下是两个节点的RAC CHM的架构图：   CHM的自身的架构非常简单：总共包括三个守护进程（daemon）： osysmond，ologgerd和oproxyd。 osysmond 这个进程在所有节点上运行，负责监控和收集本地操作系统的性能数据，并将本节点其收集到的信息发送给ologgerd进程。 ologgerd这个进程在所有节点上运行，但是属于primary-standby的模式，也就是真正工作的只有运行在master节点的primary，其它节点上的进程作为备用。这个进程接收来自所有节点osysmond收集的信息，并将其存入到Berkeley DB（BDB）， 在存入以前它会对原始数据进行压缩以节约空间。可以使用如下命令来获得master节点的信息： $ oclumon manage -get master Master = racnode1 done oproxyd 这个进程运行在所有的节点，实际上是运行在公网之上的一个监听程序，使用端口61027。前面也提到过CHM为可以在图形界面客户端（oclumon命令行也是可以的）发送指令然后在Server端执行，并将结果返回client端。oproxyd相当于一个client/server的一个代理。   二. CHM Repository 默认情况下，会存在于GI的ORACLE_HOME下 ，占用1 GB 的磁盘空间，可以将其增加到使用3天的大小。 获取路径： $ oclumon manage -get reppath CHM Repository Path = /u01/app/grid/crf/db/racnode1 Done 修改路径： $ oclumon manage -repos reploc /shared/Oracle/chm 获取大小： $ oclumon…

http://www.dbaleet.org/uncover_the_secret_of_exadata_flash_cache_compression/ Exadata X4的更新主要是集中在硬件层面的更新换代以及改进，相对硬件而言，软件层面的新特性乏善可陈，大多数集中在一些小细节的完善。 当然也有令人“眼前一亮”的新特性，比如Exadata Flash Cache Compression, 在Oracle的官方关于Exadata X4新特性介绍的ppt中，我们可以找到如下关于Exadata Flash Cache Compression的介绍： 有几个关键词看上去是“人见人爱，花见花开”: 1. 自动压缩/解压（automatic compressed/decompressed） 2. flashcache能存储多达2倍的数据（up to 2x more data） 3. 硬件级的压缩解压，零额外开销（implemented in hardware, zero performance overhead ） 4. 支持Exadata X3和 Exadata X4 （supported on X3 and X4 storage servers） 官方没有提供更多的实现细节，但是告知如果需要使用这个特性，就需要在cell一段启用高级压缩的特性（Advanced Compression Option）， CellCLI> alter cell flashCacheCompress=TRUE 而高解压缩的特性是一个独立的组件，需要额外的license。 Oracle Advanced Compression Option must be licensed  to…

http://www.dbaleet.org/exadata_configuration_tools_exaconf/ 上两篇文章介绍了的Exadata的配置工具dbm configurator， dbm configurator功能很强大，并且一直是Exadata默认的配置工具，但是存在以下几个明显的缺点   1. 不跨平台 dbm configurator 是使用基于Microsoft Office 2007 宏开发的，如果不使用Windows平台（老外用Mac的人很多），则无法进行配置。即使是Windows平台，如果Office不是2007版本，也可能存在兼容性的问题。 2. 缺乏向导 dbm configurator工具的好处就是一目了然，从一个文件可以一眼看到所有的配置信息，但是需要配置的信息太多，看上去非常复杂，用户需要一个step-by-step向导式的配置模式就更好了，并且dbm configurator在生成配置以前无法进行错误检查。 3. 对于非标准配置支持较差 dbm configurator可以很方便的配置出标准规格的Exadata，但是对于非标准的配置则比较麻烦，例如用户在购买一个半配（half）的基础之上可能希望再增加1个DB节点，或者需要增加2个Cell节点，dbm configurator对于这类型的配置支持不是太好。 针对以上问题，在新版的onecommand（Patch 14734044）中增加了一个基于java的向导式的工具Exaconf，全称是Oracle Exadata Deployment Assistant。Oracle推荐用户使用新版的Exaconf进行配置，但是同时也保留了dbm configurator。 在使用这个工具前，请先确保您的机器上安装了JRE 1.5以上的版本。在Exaconf目录下，运行exaconf.sh或者exaconf.cmd（取决于您运行在什么平台之上）。 one picture is worth more than ten thousand words， let’ s get started. 第一步：显示向导，当然这里也可以导入先前的配置文件。 第二步：输入用户信息。 第三步： 输入Exadata的规格。 第四步： 网络配置要求 第五步： 输入管理网的IP信息， 从这里开始，节点主机名默认增加了adm这样的前缀。 第六步： 输入生产网的信息， 从这里开始，节点主机名默认增加了client这样的前缀。…

原文链接： http://www.dbaleet.org/what_is_dcli/ 在上篇文章中， 介绍group文件的用途的时候曾经提到过一个叫做dcli的工具，但也只是一笔带过，这篇文章主要介绍dcli的用途及用法。 随着云计算的越来越盛行，未来可预见集群的规模会变得越来越大， 而在大型的数据中心，一个系统管理员/数据库管理员有可能同时需要管理几十上百的主机。例如要进行一些常规性的维护或者配置工作，如果还使用原始的方式进行管理，这几乎是碟中谍（Mission Impossible）了。 科技的发展从来都是靠聪明的懒人来驱动的，人类不想打猎，于是就学会了驯养家畜；不想采摘，于是发明了种植；不想洗衣服，于是发明了洗衣机。不想步行，于是发明了机动车等等。虽然这个过程所付出的艰辛往往不是外人三言两语能说清道明的。当然“要有光， 于是便有了光”那就只能靠神明的力量了。同样，集群节点的成倍增长， 配置管理系统的诞生便是一件理所当然的事情了。 很多有经验的系统管理员一定听过其中大名鼎鼎的Puppet ， 这个工具非常强大，并且现在被广泛的应用在各大型的IT企业，例如Dell， Twitter, Oracle, Citrix, Google, Wikipedia等。例如Google就曾经用它来管理几千台Mac桌面电脑。今天提到的DCLI(全称分布式命令行 Distributed command line interface)也是类似的工具，不过远比puppet简单，无需系统的学习就能迅速的掌握。Exadata的节点数众多，要是纯粹通过手工来管理则过于繁琐，并且无法达到整齐划一的配置，而如果使用Puppet这样的神器又给人以用牛刀杀鸡的感觉。 来看一下DCLI有多简单, 以下是一台半配的Exadata用来获取各节点的系统时间： [root@dm01db01 ~]# /usr/local/bin/dcli -g /opt/oracle.SupportTools/onecommand/all_group -l root “date” dm01db01: Sat Jun 2 16:59:47 CST 2012 dm01db02: Sat Jun 2 16:58:32 CST 2012 dm01db03: Sat Jun 2 17:00:00 CST 2012 dm01db04: Sat Jun 2…

http://www.dbaleet.org/exadata_configuration_tools_dbm-configurator_2/   上一篇说到了如何填写dbm configurator，本篇则着重介绍点击generator以后dbm configurator的输出对象。 最明显的变化就是在dbm configurator 这个工作簿的右侧会自动生成一张Installation template的工作表，里面记录了安装的详细信息。通常可以将这一部分内容输出成pdf，发送给客户或者打印出来进行逐一核对。 这些文件分为几类： 1. group文件 这类文件记录了Exadata各节点的主机名，主要用于onecommand内部调用dcli命令，当然您也可以自己使用dcli来管理方便管理Exadata的节点。dcli是Oracle Linux上用来管理多主机的一个工具。 all_group 记录所有的DB节点和Cell节点的公网主机名; all_ib_group 记录所有DB节点和Cell节点私网的主机名; all_nodelist_group 记录DB节点和Cell节点公网和私网的主机名，为前两者之和; cell_group 记录所有Cell节点的公网主机名; cell_ib_group 记录所有Cell私网的主机名; dbs_group 记录DB节点私网主机名; dbs_ib_group 记录DB节点私网的主机名 priv_ib_group 记录DB节点和Cell节点私网的ip地址，域名，主机名 2. preconf文件 preconf.csv文件用来辅助修改Exadata DB节点和Cell节点的网络配置信息，例如主机名，域名，节点类型，网络地址，绑定，ntp， 时区， DNS服务器。Exadata在出厂的时候默认设置的是192.168.1.*这个网段， 通过使用 /opt/oracle.Supporttools/firstconf/applyconfig.sh 或者reimage makeImageMedia.sh调用这个文件将DB节点和Cell节点的网络配置信息设置成用户期望的目标。但是这个文件不能修改除DB节点和Cell节点以外的设备，例如KVM， PDU， Cisco交换机， infiniband交换机，这些设备的网络配置需要手工设置。 preconf-11-2-1-1-0.csv， preconf-11-2-1-2-2.csv， preconf-11-2-2-1-0.csv是早期Exadata使用的preconf文件的格式，后面的数字对应Exadata的版本号，从11.2.2.1.0以后，这个文件格式就是当前的preconf.csv。 3. checkip脚本 checkip.sh脚本用来在运行onecommand之前检查ip的配置。checkip.sh调用dbm.dat这个文件内的配置信息进行检查： 例如，在调用applyconfig.sh之前可以使用以下命令进行检查： ./checkip.sh -m pre_applyconfig 在调用applyconfig.sh之后可以使用以下命令进行检查： ./checkip.sh -m post_applyconfig 4. 配置文件 这一部分是onecommand调用的配置文件，包括onecommand.params，…