> 文章列表 / Page 124

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…

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. 对于非标准配置支持较差…

原文链接： 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这样的神器又给人以用牛刀杀鸡的感觉。…

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节点公网和私网的主机名，为前两者之和;…

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…

原文链接: 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 收集的模块（中文描述）…

原文链接： 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，…

原文链接：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…

原文地址：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…

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根？从以上图片中很难找到答案。  …