Maclean’s Oracle Database Tech Blog Archives

http://www.dbaleet.org/exadata_configuration_tools_dbm-configurator_1/ 如果您有看过Exadata的宣传资料，就会发现Oracle宣称Exadata为“开箱即用智能存储服务器网格“。 当然这句话更多是Oracle市场策略的因素在主导，就像Exadata里面提到的n多的类似于”smart“这样的词汇，它们的存在的理由是因为有人喜欢这样的字眼。客户都是抱着减少复杂性，提升工作效率的想法才购买Exadata的。相信没有客户愿意去购买一堆零件然后自己花上一两年的时间去部署一个系统。先不论Exadata是否是真的属于开箱即用，但是对于Exadata这样一个复杂的系统来说，所有的部署工作都可以在一周以内完成已经是相当了不起了。当然能把部署时间控制到这么短，主要还是得益于用来部署Exadata的两个工具“dbm configurator”和“onecommand”。今天就来简单的介绍一下其中之一的“dbm configurator”。 顾名思义， dbm configurator就是数据库一体机的一个配置工具（但不是唯一的配置工具，下一篇我们将会介绍另外一个部署工具）。刚开始看到dbm configurator的时候，很多人甚至不屑一顾。“什么？这不就是一个excel表格吗？哪是什么配置软件！”等到真正使用之后就发现“原来excel也可以这么强大！” 没错！，它就是一个excel表格，但是其复杂程度一点也不比普通的软件或者脚本差，因为其中大量的使用了宏（macro），使得很大内容都可以根据规则自动生成，而且很多选项都是使用下拉框进行选择的。填写完成以后还可以生成一系列的配置文件供安装使用。 下面我将主要的配置表格，分解为几个模块讲解： 1. 命名和规格型号信息（Naming and Sizing information）： 这一部分主要配置Exadata的主机名，域名，规格，节点数，时区， 用户名称，磁盘空间。 Oracle Exadata Database Machine Name 是所有节点（包括DB节点和Cell节点的前缀），Database Server Base Name 是DB节点的前缀， Oracle Exadata Storage Servers Base Name :是Cell节点的前缀， Domain Name 是域名，以上信息综合决定了一台机器的主机名和域名，例如上图中的第一个DB节点的主机名是dm01db01, 域名是dm01db01.us.oracle.com, 第一个Cell节点的主机名是dm01cel01, 域名是dm01cel01.us.oracle.com。 这里建议用户将Oracle Exadata Database Machine Name修改为更有意义的名称，例如rpt或者report之类的，但是不要太长，请控制这个字段在10个字母以内。因为主机名参数最好不要大于15个字符。其它的几个参数最好保持默认，不要去修改。Customer Name 填写为用户的实际名称就行，没有太多实际意义。 Region和Time Zone 决定机器的市区，中国一般Region选择Asia， Time Zone选择Shanghai。其它地区可按照实际进行填写。 Oracle Database Machine Model 表示Exadata的规格型号，例如如果这里选择Full，Database…

原文链接: http://www.dbaleet.org/collect_exadata_diagnostic_info_via_rda/ RDA是Remote Diagnostic Agent的简称，是Oracle开发的用于收集Oracle公司全系列产品诊断信息的工具，是Oracle售后工程师和技术专家标准工具之一。在向MOS（support.oracle.com）开一个服务请求（SR）的时候，可能会经常遇到Oracle Support要求收集当前系统的RDA以诊断某些疑难问题。另外由于RDA覆盖面非常广， Oracle售后工程师在进行数据库健康检查的时候也是使用RDA作为的原始素材的收集工具的。 既然RDA是Oracle全系列产品标准诊断信息的收集工具，那么必然它也可以用于Exadata。本文并不对RDA进行通用性的介绍，而仅仅提供一些Exadata下常用的rda选项以供诊断Exadata问题之用： 1. module RDA提供了一个Exadata专用模块，如果要对Exadata的信息进行收集只需带入Exadata模块专用的参数就能收集所有与Exadata相关的信息。 ./rda.sh -vC EXA 2. profile 如果module适用于对Exadata整体性能的收集，那么profile则主要偏重于诊断Exadata某个特定组建的问题。以下列出了所有的Exadata功能组件： profile COLLECTION MODULES 收集的模块（中文描述） Exadata_Assessment Oracle Exadata assessment collections Exadata配置评估相关 Exadata_CellBrownout Oracle Exadata long brownout due to cell failure-related problems Exadata Cell掉电相关 Exadata_CellFailure Oracle Exadata cell failure-related problems Exadata Cell故障相关 Exadata_DatabaseCrash Oracle Exadata database crash-related problems Exadata数据库崩溃相关 Exadata_DatabaseHang Oracle…

原文链接： http://www.dbaleet.org/seperate_read_and_write_by_oracle_active_dataguard_reader_farm/ Oracle Database 作为通用关系型数据库，常常需要满足客户的各种不同的业务模式，最典型的如交易密集型系统，决策分析型系统等等。很多人都发现了这么一个规律：互联网公司例如Google，Facebook等很少甚至没有使用Oracle的数据库产品，于是乎得出一个结论：互联网公司的基因决定了MySQL之类的开源数据库最佳之选，而Oracle Database并不适用于互联网公司的业务场景，故选用Oracle的产品是不明智的。这句话乍看上去有一定的道理，Oracle Database本身过于庞大，对于要求业务逻辑要求灵活多变的互联网确实不是太搭噶。 互联网公司是很少使用Oracle Database，但这其中最重要的因素绝非是技术层面的。绝大多数互联网公司都会对Oracle那价格不菲的license退避三舍，况且前面已经有足够使用开源技术的范例可以参详，购买Oracle Database实属毫无必要。互联网公司的业务逻辑比较类似，大多数（不是所有）互联网公司都是内容提供商，绝大多数业务以读为主，所以系统设计最基本的一条就是实现读写分离。那么有没有一些互联网公司基于Oracle Database来实现读写分离呢？又是怎么实现的呢？ 据我所致，国外很多内容提供商都是基于Oracle Database实现的读写分离。例如Netflix， Amazon， Pandora等。早期Oracle Database自身能实现读写分离的技术非常有限，能做到实时同步的更是屈指可数。因为早期的Dataguard无法在应用日志的时候同时打开，最常用的技术都是逻辑复制的技术，例如Streams，Logical Standby，goldengate等。逻辑型复制技术存在的一个最大的问题就是无法保障同步的实时性，即使是goldengate也只能提供准实时的数据同步。另外就是逻辑性复制受限于业务逻辑本身，如果存在大量大事务，则可能出现拥塞，对于读写密集型的业务而言这种方式基本不可取。而11g的新特性Active Dataguard则很好的解决了这个问题。 Active Datagurad， 简单的说也就是可以打开的Dataguard，可以在应用Primary传过来的日志的同时将数据库以read only的模式打开。那么也就意味着，有了Active Dataguard， Standby Database不仅仅只是DR了，而是可供实时查询的备库，可以做到将“闲置”资源充分利用起来。而Active Dataguard Reader Farm看似是一个新名词，其实就是多个Active Standby组成的一个Farm，供大量的实时查询来使用。 当然以上只是一张概念图，以下是Apple使用Active Dataguard Reader Farm的一张架构图： 简单地对以上架构图做一些阐述： 1. Primary Database通常还会连接另外一个最大可用性模式的的Standby Database作为DR，以同步的方式应用Primary的变更。一旦Primary Database发生故障就可以切换到Standby Database而不会丢失任何数据。 2. Active Dataguard Reader Farm一般采用异步实时的模式应用日志，防止对Primary Database造成负面影响。在11.2还可以通过Query SLA的来监控和控制。通过V$DATAGUARD_STATS和V$STANDBY_EVENT_HISTOGRAM来监控其延迟，以及通过session级别设置STANDBY_MAX_DATA_DELAY来控制其延迟的行为。 3. 在应用服务器层面进行负载均衡，将多个应用服务器发送过来的请求通过一个硬件的load balancer （例如BigIP F5或者Citrix  NetScaler ADC）均衡分布到Active Dataguard…

原文链接：http://www.dbaleet.org/about_rac_interconnect_flow_control/   通常流量控制是如此的不起眼，以至于很少有dba知道它的存在，更不用说去了解它。“听名字，这个通常是网络工程师的该做的，不是吗？”“保持默认的就可以了，dba没有必要了解一些无关紧要的细支末节，因为这简直是浪费时间。法律没有规定不允许的事情都是允许的，没有哪条法律写的是你可以做什么。“ 说得有道理，流量控制通常是属于网络工程师管辖的领地，但是有时诊断问题的时候难免会越界，越是一些边界问题，越是容易遇到扯皮的事情。这就像大部分国家确实是法律没有规定不允许的事情都是允许的，但是你永远无法排除某些少数几个神奇国家的存在。 流量控制打个比方就跟生产车间的流水线一样，一个工艺完毕，才可以交给下一个工艺。例如生产啤酒，只有先把啤酒装入啤酒瓶中，然后才能把盖封上。如果不这样那就是空瓶了，最终消费者会退货，所产生的代价反而更大。在网络通信中，流控制就是防止源端的发送速率超过目标段的接受速率的一种机制。但是它和拥塞控制又不同，拥塞控制的一个前提就是拥塞已经发生了，然后是如何去解决拥塞的一种机制。一句话流量控制是限制，而拥塞控制是疏导，这又是题外话了。如果接受端的流量远大于发送端的流量或者接受端的处理能力远小于发送端，那么这个时候就需要用到流量控制了。所以流量控制就分为了发送端流量控制（我们用tx来表示）以及接受端流量控制（我们用rx来表示）。 我们能从Oracle官方的文档中找到Oracle是否推荐打开流量控制。 在MOS 400959.1 LINUX: POOR RAC-INTERCONNECT PERFORMANCE AFTER UPGRADE FROM RHEL3 TO RHEL4/OEL4中我们找到了这么一句话： TX flow control in both Linux 2.4 and 2.6.9 are disabled (by default). It is not advised enabling TX flow control. 在MOS 563566.1 Troubleshooting gc block lost and Poor Network Performance in a RAC Environment中我们可以找到这么一句话： tx flow…

原文地址：http://www.dbaleet.org/a_bit_thought_of_exadata_from_a_technical_point_of_view/ 本文是针对IBM系统架构师王文杰先生（[email protected]）在其博客园的置顶博文思考EXADATA（链接原文地址： http://www.cnblogs.com/wenjiewang/archive/2012/10/07/2714406.html）中提到的一些关于Exadata观点，从技术角度给出我个人的一些不同的见解，当然本人水平有限，难免出现疏漏甚至错误，请诸位读者不吝赐教，同时也欢迎王文杰先生和广大读者提出不同的看法。您可以在Maclean Liu的qq群（23549328）中与我一起探讨与Oracle Exadata有关的技术。 以下简要总结一下文杰先生博文中提到关于Exadata的观点： 1. 数据仓库（Data Warehouse）类型的应用无法充分利用smart scan的特性，尤其是对于数据仓库中常见的星型转换（star transformation）， Exadata无法优化； 2. Exadata Bug众多，某些新特性名存实亡，并举例说明其在布隆过滤器的使用过程中遭遇到的bug。 3. Oracle数据库Bug众多，使用Exadata对于业务逻辑复杂，数据正确性非常敏感的金融行业存在很大的风险； 4. 维护成本高，要使用Exadata，DBA需要重新学习大量的主机，存储，网络方面的知识，否则无法胜任一体机管理员的工作； 5. 对于动辄单表上百个字段的数据仓库而言，Exadata 的Storage Index形同鸡肋，因为对于每个表只能自动维护8个列，与杯水车薪无异； 6. Exadata还是RAC， RAC的share everything架构导致存在大量的cache fusion争用，与OLTP应用格格不入。 7. RAC对ERP支持不好，导致很多ERP用户不使用RAC，Exadata只提供RAC的模式。 8. Exadata磁盘容量太大，对于OLTP而言这简直就是浪费； 9. Exadata不提供任何虚拟化技术，不能充分利用其硬件资源，而它的竞争对手确提供非常成熟的虚拟化解决方案； 10.  （这年头，要凑不齐十条出门都不好意思跟人打招呼）Exadata的价格十分昂贵，普通的用户根本无法承受。 以下是我个人的回应，不代表Oracle公司的官方立场。Oracle的salary还没到我想做Oracle公司5毛的冲动。 如果您爱看软文，那么您可以请移步Loveunix和AIXchina，因为那里比较多。很多技术细节三言两语很难解释清楚的，限于篇幅，这里力求简介或者一笔带过。 1. 实际上smart scan可谓是Exadata所有技术的核心，离开了smart scan，Exadata就没有了灵魂。而Exadata的smart scan的条件过于苛刻，一直以来备受竞争对手的诟病，这个也是事实。 但是文中提到的 “如果我们的报表如果不是走FULL TABLE SCAN，则无法利用到这一特性。复杂的查询，诸如Joins, sorts, group-bys, aggregation都很可能无法利用到智能扫描。” 这一说法是不准确的。我这里不厌其烦的列举一下目前smart scan的条件：（虽然这是一个错误的“真理”） Full scans——Table, Partition, Materialized View,  Index (FAST FULL SCAN Only)…

http://www.dbaleet.org/how_to_cable_ib_switches/ 这个问题看似没有什么讨论的必要，因为接线从来就不是什么技术活。但是令人遗憾的是我对此并不熟悉，经过一番请教，基本上明白了其中的原理。 以下是一台1/4配Exadata infiniband内部是如何进行连接的：     1/4配的Exadata2台db节点和3台cell节点，另外还有2台叶子节点ib交换机。上图的理解如下： Exadata的每台服务器都提供了一个双口的QDR infinband HCA卡， 采用在操作系统中Active-Standby的模式进行连接，Exadata就是据此来实现节点之间互连的高可用的。所以上图中有两个port，其中port1为Active， port2为Standby。默认情况下，db01, db02, cel01, cel02, cel03同时连接到两台ib叶子节点交换机上，只是在ib1为active状态，ib2为standby状态。如果db01需要访问cel01, cel02, cel03上数据有ib1就可以搞定了，并不需要通过ib2。如果ib1发生故障，这个时候ib2会自动接管，对前段的数据库的正常运行无影响。 另外两个ib叶子节点之间还有使用了7根线进行互联，这里问题来了，为什么是7根线，而不是2根或者8根？从以上图片中很难找到答案。   这个图是一台1/1的Exadata，但是只是用了2太ib叶子交换机。port1为primary，port2为standby。如果db01需要访问的数据位于cel01-cel07, 那么则无需使用ib2, 但是如果db01需要访问的数据位于cel08-cel14, 因为cel08-cel14再ib1上处于standby状态，并不会进行数据传输。所以需要通过两台ib交换机之间内联的7根线去ib2，然后再通过ib2去访问cel08-cel14的数据。如果两台交换机之间互连的数据线低于7根，则无法获取最大的性能，因为处于standby状态的cel节点为7台。高于7根数据线则意义不大。如果使用的是1/4配或者1/2, 虽然部分线是多余的，但是也会使用7根线来实现互联，因为这种接线的方式是出厂预设的。 如果使用第三台主干交换机，则只需要在每一台叶子交换机上分别引一根线到主干交换机。如下所示：       以上。  

http://www.dbaleet.org/how_to_resize_exadat_filesystem_on_db_node/   此文整理自MOS文档How to Expand Exadata Compute Node File Systems (Doc ID 1357457.1) 虽然是Oracle的一体机，但是操作系统是Oracle Linux 5, 所以跟普通Linux文件调整文件系统大小的方法没有太多不一样，nothing special。 早于11.2.1.3.1版本的DB节点没有使用LVM，以下针对使用LVM的文件系统进行调整。 Exadata DB节点使用了一个大小为600G的VG，大小为什么是600G？，请参看上一篇文章：Exadata X2-2 db节点系统盘的RAID是如何配置的？ 首先来看一下根分区的结构： #df / Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VGExaDb-LVDbSys1 30963708 21867152 7523692 75% / 推断根分区是建立在LVDDbSys1之上的， 可以用lvscan进行验证： #lvm lvscan ACTIVE ‘/dev/VGExaDb/LVDbSys1’ [30.00 GB] inherit ACTIVE ‘/dev/VGExaDb/LVDbSwap1’ [24.00 GB] inherit ACTIVE ‘/dev/VGExaDb/LVDbOra1’…

原文链接：http://www.dbaleet.org/apply_exadata_bp_via_out_of_place_approach/ 在之前介绍Oplan这篇文章中，提到了Oplan会根据客户当前系统的实际情况，生成可执行的补丁方案，以下介绍的就是oplan生成的使用clone方式应用Exadata BP的例子。 一般情况下，我们都可以使用rolling的方式应用Exadata的bundle patch，因为这样无需停机窗口。如果允许很小的停机窗口，则可以考虑使用clone的方式来应用Exadata的Bundle Patch，这就是所谓的out-of-place的升级方式（看来out-of-place的方式是大势所趋呀）。out-of-place的方式最大的优势是能将升级/补丁的风险降到最低，一旦升级/补丁失败，则只需切换环境变量就能做到立即回滚。并且OUT-OF-PLACE升级/打补丁前期的准备工作都可以在线完成。相比rolling的方式，其不足之处在于需要停机，即使所需的停机窗口很短。另外需要本地文件系统需要保留足够的空间。 以下为一个Exadata上应用BP10（patch#14662263）的过程： 原始版本 目标版本 GI版本 11.2.0.3 BP3 11.2.0.3 BP10 RDBMS版本 11.2.0.3 BP3 11.2.0.3 BP10 GI ORACLE_HOME /01/app/11.2.0.3/grid /01/app/11.2.0.3/grid_2 RDBMS ORACLE_HOME /u01/app/oracle/product/11.2.0.3/dbhome_1 /u01/app/oracle/product/11.2.0.3/dbhome_2 LISTENER ORACLE_HOME /u01/app/11.2.0.3/grid /u01/app/11.2.0.3/grid_2 1） 开始clone前的一些准备工作： 1. 备份/u01/app/oraInventory目录; 2. 下载BP10的patch 14662263，并使用oracle用户将其上传到/tmp/patches目录下; 3. 将/opt/oracle.SupportTools/onecommand拷贝到/root, /home/grid, /home/oracle目录下； 4. 下载最新opatch（patch# 6880880）， 并且更新到所有节点； [oracle@dm01db01 ~] dcli -g ~/dbs_group -l oracle -f /tmp/patches/p6880880_112000_Linux-x86-64.zip…

原文链接： http://www.dbaleet.org/exadata_oplan/ 首先， 不要误会，oplan并不是在Exadata上替代opatch的补丁工具，目前，它仅仅只是提供一个替代opatch readme的功能。 opatch发展到今天已经算得上非常成熟的补丁工具了，它能在应用任何补丁之前自动检查是否和已存在的patch冲突。绝大多数的补丁都能通过一两条简单的命令直接搞定：例如opatch auto/opatch apply。但是Oracle这种补丁机制也存在一些小问题：例如补丁的readme由于只提供一些通用性的步骤，所以往往缺乏可读性，其中很多补丁的readme都是从别的文档拷贝修改过来的，甚至存在一些错误。由于上述问题，很多dba在打补丁之前甚至都不看readme文件的。下面提到的oplan却能根据客户现有的环境进行前提条件的检查，最后生成一个可执行的命令行的报告，这比原始的readme本身更有意义。 oplan并非Exadata专有的，但是最早用于Exadata平台，作为补丁应用的最佳实践。仅支持linux和solaris平台。 Product Family Product Patch Type Release Platform Oracle Database Oracle Exadata Database Machine** Recommended Bundle Patches * 11.2.0.2 Linux x86-64, Solaris x86-64 Oracle GI/RAC running on normal clusters GI PSU and DB PSU 11.2.0.2 Linux x86-64, Solaris x86-64, Solaris SPARC (64 bit) Oracle Database Oracle Exadata Database…

原文链接： http://www.dbaleet.org/how_to_build_a_pxe_virtual_machine_to_reimage_automaticaly_in_exadata/ 前面的文章介绍了如何对exadata进行reimage， 试想一台满配（Full Rack）X3-2的Exadata， 一共有8个数据库节点， 14个存储节点。每按照传统的方式每个数据库节点 reimage需要1个小时，每个存储节点 reimage需要1.5个小时来计算， 所花费的实际那为8×1+14×1.5=29小时。如果使用多个usb来并行reimage，时间也接近两天左右。有没有一种更简单的方法来完成这个费力不讨好的工作呢？ 答案是肯定的，那就是使用PXE的方式来进行reimage。使用PXE一共分为以下几个步骤： 准备工作 在开始安装以前，需要进行如下准备工作： 安装虚拟机，推荐Oracle Virtualbox （可在https://www.virtualbox.org/下载）； 虚拟机分配的内存在1GB以上，剩余磁盘空间在20G以上； 安装Oracle Linux 5.7或者其它Linux发行版。Oracle Linux 可在 https://edelivery.oracle.com/下载； 下载Exadata 安装介质。可前往 https://edelivery.oracle.com/，我这里使用的是：11.2.3.1.1版本。 VirutalBox需要配置两块虚拟网卡，其中网卡1使用的是Bridge的模式，同时安装者需要一个网线连接自己的笔记本电脑到Exadata自带的Cisco交换机。以便网卡一与Exadata的出厂地址处在同一个网段。网卡2采用的是Host Only的模式，配置次网卡的目的主要是为了方便从笔记本连接到PXE虚拟机。       网卡1在Linux操作系统中对应eth0，其网络配置信息如下：   [root@exadatapxe ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 # Intel Corporation 82540EM Gigabit Ethernet Controller DEVICE=eth0 BOOTPROTO=static BROADCAST=192.168.1.255 IPADDR=192.168.1.250 NETMASK=255.255.255.0 NETWORK=192.168.1.0 ONBOOT=yes 网卡2在Linux操作系统中对应eth1，其网络配置信息如下： [root@exadatapxe ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 #…