Maclean’s Oracle Database Tech Blog Archives
-
令人乍舌的Exadata版本号
http://www.dbaleet.org/exadata_version_what_a_surprise 在版本号领域一直存在着这么一些传说: 1. 从2008年9月开始到2012年11月,Google Chrome 版本号从1.0一路狂飙到25.0, 每六周发布一个新版本,当之无愧版本帝,远远甩开老牌浏览器firefox(这家伙也被带坏了), IE, Opera 2. 腾讯qq,如果你要问我腾讯最大的创新是什么?我会告诉你是它前无古人,后无来者,惊天地,泣鬼神的版本号: qq2010 正式稳定版,正式beta版,beta稳定版,beta正式版,稳定beta版等等,可谓开创了一个历史的新纪元。 3. foobar版本, 一个做了10年的软件一度都是不停在刷0.9,我曾一度以为它会9到天荒地老,最终也还是迈向1.0, 不得不令人感慨2012终究是来了。 以上仅仅吐槽几句,本不该出现在这里,请自觉忘记。 1. 以下是Exadata版本与其对应的操作系统版本,内核版本,OFED版本,Exadata不支持手工单独修改/升级操作系统,内核,ofed,hca固件版本。 Exadata版本 操作系统版本 内核版本 OFED版本 11.2.3.2.0 OL5.8 Default: 2.6.32-400.1.1.el5uek Optional: 2.6.18-308.8.2.0.1.el5 1.5.1-4.0.58 11.2.3.1.1 OL 5.7 2.6.18-274.18.1.0.1 1.5.1-4.0.58 11.2.3.1.0 OL 5.7 2.6.18-274.18.1.0.1 1.5.1-4.0.58 11.2.2.4.2 OL 5.5 2.6.18-238.12.2.0.2 1.5.1-4.0.53 11.2.2.4.1 OL 5.5 2.6.18-238.12.2.0.2 1.5.1-4.0.53 11.2.2.4.0 OL 5.5 2.6.18-238.12.2.0.2 1.5.1-4.0.53…
-
Cache写策略——write-through与write-back
http://www.dbaleet.org/cach_write_policy_write-through_and_write-back write-through和write-back这个概念在存储工程师眼里绝对不会陌生,而对于数据库管理员来说并却并不一定十分清楚。我说看到的数据库管理员与存储工程师的接口无非就是这些: 1. 我需要一个scalable vg,大小是100g。 2. 我需要使用三个1T的裸盘用来做asm。 3. 我需要一个IOPS为12000的阵列,底层做成raid 10, 条带大小为1M 没有人愿意去了解关于磁盘cache是怎么工作的,因为那不是我工作的范畴。 俗话说: “不想当厨师的裁缝不是个好司机“, 如果预备做Exadata的管理员,或许您应该先了解了解cache的写模式。Take it easy, it is not rocket science. 在进入正题之前,先来问问wikipedia怎么看: Writing Policies 。 wiki大神已经解释得非常清楚了,看来没有写下去的必要了。这篇文章就到这吧,再见。No, to make it more clear, I would like to interpret it in an Exadata way, that is the point. 俗话说:“No pictures, No trues”, let’ s get started. Write-Through 模式: 1. DB向Cell发送一个写请求, cellsrv进行验证确认其请求有效;…
-
0还是100?——Linux vm.swappiness
http://www.dbaleet.org/0_or_100_linux_vm_swapiness/ 在使用raccheck对RAC数据库进行健康检查的时候,你可能会看到类似这样的信息: 如果这是你第一次见到它,那么它对你将不再陌生。在安装 12c GI的时候,在安装11.2.0.4GI的Patchset的时候, CUV都会检查Linux操作系统的vm.swappiness这个参数,如果没有将其设置为100, 就会报前提条件通不过。Oracle提供的理由是:在压力测试中,我们发现将swapiness设置为100可以减少或者延迟因连接风暴导致内存耗竭而引起的节点驱逐。文档提供的内容如下: Please refer bug12890401 for more details, CVU now enforce this swappiness=100 check, it is better to have this add to the doc. swapiness是的一个内核参数,目的是用来控制页交换比例的一个阈值,其设置范围为0-100,这个值默认为60, 值越高说明内核使用交换区更加频繁。以下看wikipedia对于swapiness的解释: Swappiness is a property for the Linux kernel that changes the balance between swapping out runtime memory, as opposed to dropping pages from the system page…
-
Exadata安全最佳实践原则——Linux OS
原文链接: http://www.dbaleet.org/principal_of_exadata_security_best_practices_linux_os/ 在Exadata Overview的白皮书中有这么一段话: Exadata Database Machine is the world’s most secure database system. Building on the high security capabilities in every Oracle Database, Exadata Database Machine provides the ability to query fully encrypted databases with near zero overhead at hundreds of gigabytes of user data per second. This is done by moving decryption processing from…
-
Exadata Cell的命令行工具CellCLI
原文链接:http://www.dbaleet.org/exadata_cell_command_line_tool_cellcli/ CellCLI也许远远并没有你想象中的那么复杂,它仅仅是一个管理Exadata Cell存储节点的一个命令行工具。这个工具有点类似于Oracle数据库中的sqlplus命令行,它是用户与Exadata Cell交互的一个接口。 Cell软件使用的是java构建的,天生具有跨平台的能力。也就意味着Exadata从技术上来说, Exadata是可以移植到任何平台的,但是限于市场策略,Oracle的公司绝不会这么做,所以目前仅仅有基于自家Oracle Linux平台和Solaris平台的Exadata。CellCLI使用了部分开源项目,例如其语法分析工具使用的是 BYACC/J, 而其命令行历史信息工具使用的是JLine,这些工具是基于BSD协议的,所以可以用于商业用途并且无需开源。由于其本身完成的工作量有限,所有CellCLI甚至有望移植到其它平台例如windows的客户端。 1. CellCLI的语法 CellCLI在设计之初就考虑到了其语法的移植性,所以CellCLI的语法与sqlplus以及SQL的语法非常类似,具有sqlplus和SQL经验的dba无需经过一个新的语法学习过程就能使用它。以下举例说明CellCLI的语法: CellCLI具有sqlplus中同样的命令: EXIT/QUIT: 退出CellCLI命令行; HELP: CellCLI的语法帮助; SET : 设置CellCLI的环境变量; SPOOL: 将命令行结果写入到本地一个日志文件; START/@: 运行CellCLI的脚本 CellCLI的语法结果: CellCLI命令行语法基本结构如下: <verb> <object-type> [ALL |object-name] [<options>] 其中CellCLI verb(动词)包括:ALTER, CREATE, DROP, LIST 分别代表修改,创建,删除和查看。 CellCLI的object-type(对象类型)一共包括三类: 资源配置相关的对象: CELL, CELLDISK, GRIDDISK, IORMPLAN, KEY, LUN, PHYSICALDISK, 性能指标相关的对象: ACTIVEREQUEST, METRICCURRENT, METRICDEFINITION, METRICHISTORY 失败告警相关的对象: ALERTDEFINITION, ALERTHISTORY,THRESHOLD. Tips:…
-
如何诊断Smart Scan导致的错误结果
原文链接: http://www.dbaleet.org/how_to_diagnostic_wrong_result_issue_caused_by_smart_scan/ 虽然错误结果(Wrong Result)对于Oracle数据库来说并不是什么新鲜的事情,例如如果有细读过Patchset bugfix list, 就能看到其中有一个专门的主题就是列出导致错误结果的各种bug。 但是实际上因Exadata导致的错误结果的现象并不多见。由于Smart Scan本身的机制比较复杂,而且Exadata存储软件本身是个黑盒,所以在诊断的时候往往感到无从下手。以下是Smart Scan导致错误结果的诊断流程:虽然并不是很实用,但是通过它,可以隐约亏测到一些关于Smart Scan的内部机制。 以下摘 自Exadata: How to diagnose smart scan and wrong results (Doc ID 1260804.1) STEP 1. Set cell_offload_processing = FALSE Wrong results still occur? Yes – a data layer issue No – smart scan problem. Restore parameter’s default value; go to (2) STEP 2. Set _kcfis_cell_passthru_enabled = TRUE…
-
Exadata Cell 隐含参数的获取方式与反向负载转移(reverse offloading)
原文链接:http://www.dbaleet.org/get_exadata_cell_hidden_parameter_and_exadata_reverse_offloading/ Exadata一体机的offloading有一个很重要的功能就是db节点和cell节点之间的负载可以互相感知。 例如数据库节点大量使用smart scan,smart scan把负载offload到cell一端,在某些情况下,可能导致cell节点的cpu负载过高,甚至过载的情况。相反db节点由于把负载offload到cell节点反而比较空闲。 在这种情况下reverse offloading就派上用场了,cell如果发现cpu的占用率过高,这个时候会将一部分原本使用smart scan的查询不使用smart I/O过滤, 而是直接使用普通db的block I/O返回给db节点以缓解cell节点CPU的负载,等到cell的负载降下来,再次smart scan, 这个过程就叫做reverse offloading。当然如果此时发现db节点的CPU也很高,那么cell就不返回block I/O的数据块。整个这个过程对于数据来说是透明的。 所以在某些情况下,不要相信Exadata不需要索引的传言,即使所有的扫描都是smart scan! 也并不是说只要可能走smart scan,就一定非要强制其进行smart scan。如果smart scan过度很可能导致cell节点的cpu非常高,这个时候建立合适的索引不适用smart scan未尝不是明智之举。 有几个专有的统计信息叫做“cell physical IO bytes sent directly to DB node to balance CPU” 来标记reverse offloading这个过程。 如下: SQL> select name, value from v$sysstat where name like’%balance%’; NAME VALUE —————————————————————- ———- cell physical IO bytes sent…
-
反向负载转移(reverse offloading)的再次探索
原文链接: http://www.dbaleet.org/second_try_with_exadata_reverse_offloading/ 距上一篇关于reverse offloading文章发布已经一个多月了,但是这个功能似乎还有一些值得探究的地方。于是又顺便摸索了一把: 正好我自己也有几个一些疑惑,那么就带着问题上路吧。 第一个问题是: 在数据库db server一端是否又参数可能控制这个功能?以我对oracle的了解,就像storage index一样,reverse offloading这样的功能一定会在db一端有对应的参数的,并且通常是一个隐含参数,那么这个参数是什么呢? 我们又需要动用到人尽皆知的”秘密武器“了: SQL> set lines 180 pages 999 SQL> col name for a50 SQL> col value for a20 SQL> col describ for a70 SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ FROM SYS.x$ksppi x, SYS.x$ksppcv y WHERE x.inst_id = USERENV (‘Instance’) AND y.inst_id = USERENV (‘Instance’) AND…
-
Exadata FAQ: Exadata上的数据是否能安全的删除?
原文链接:http://www.dbaleet.org/exadata_faq_how_to_secure_erase_exadata/ 位于北京上地的甲骨文测试中心几乎每天都会迎来各行业对Exadata感兴趣的潜在客户, 很多客户听说Exadata快11倍的神奇性能(话说Exadata广告真是普天盖地,在首都机场,虹桥机场,奥林匹克公园地铁站,国航航班,和谐TV都能见到),希望有机会一睹真容,并且拿自己公司的真实数据进行测试,看Oracle是不是在吹牛。 如果只用Oracle自己提供的数据,很多人就会认为那只是Oracle公司自圆其说吹吹牛,至于数据嘛都是自己造的。敢不敢用真实的数据测试?另外很多客户也迫切想知道,Exadata是不是适合我们自己的应用。如果不用真是数据测试,那么所有的测试都是没有意义的。但是如果采用真是的数据,那么怎么保证客户的数据不被泄漏呢?怎么样保证所有的生产数据都被安全的删除了?通常来说用户做完测试以后把这个数据库删除就可以了。但是对于某些行业的客户,例如金融,政府行业的客户的要求不仅仅是删除数据库这样简单了。Exadata上是否有彻底删除用户数据的工具? 答案是肯定的,在Oracle内部有一个工具叫Exascrub, Exa代表Exadata, Scrub表示擦除的意思。或许有些熟悉Linux的DBA会知道有scrub这样工具,是的,Exascrub就是在最终调用的就是scrub。在标准的Linux repository中都有scrub这么一个包。 在Debian/Ubuntu下可以使用以下命令进行安装: sudo apt-get install scrub 在RHEL/OL/Fedora下可以使用以下命令进行安装: sudo yum -y install scrub 在srub的man手册中可以看到srub命令的介绍。 更底层一点,scrub使用的是Gutmann method对数据进行擦除。srub使用 DoD 5220.22-M标准,此标准一共包括5个部分: a- Write 0×00 on entire partition b- Write 0xFF on entire partition c- Write Random bytes on entire partition d- Write 0×00 on entire partition e- Verify that wipe was successful…
-
如何对Exadata I/O进行性能校准测试
原文链接: http://www.dbaleet.org/how_to_calibrate_exadata/ 前段时间看到MACLEAN LIU分享了一篇不错的关于Exadata I/O性能校准的文章:Calibrate测试Exadata IO,这篇文章基本涵盖到Exadata I/O性能校准的方法。刚好最近又有人问我这方面的问题,所以在这里再班门弄斧做一些补充,存在重复的地方请无视之。 在Exadata上如果需要对I/O进行性能校准或者测试,通常有如下几种方法: 1. Oracle的I/O性能校准工具orion; 2. Oracle Database 11g引入的的DBMS_RESOURCE_MANAGER.CALIBRATE_IO包; 3. EXADATA Cell端cellsrv中的calibrate命令; 当然有人说通过dd进行测试也可以得到磁盘的IOPS和MBPS。 在没有任何工具的前提下,当然dd也可以用来进行大致的估算,但是其结果通常是不可靠的,所以这里就不把dd例如这个范畴。以下分别对这几种方式做一些简单的介绍和对比。 orion orion是与数据库无关的I/O性能校准与测试的工具,几乎支持所有的操作系统平台。orion是免费的,用户可以到OTN上下载其介质(下载链接: http://www.oracle.com/technetwork/topics/index-089595.html)。 使用orion进行I/O校准也很简单,一共包括如下几个步骤:(以下以Linux x86_64为例) 1. 下载orion介质,将其上传到需要进行I/O校准的服务器上,然后解压,得到一个二进制文件; 2. 创建一个叫orion.lun的文件, 这个文件记录需要进行I/O校准的设备名(LUN),例如; /dev/sdb /dev/sdc /dev/sdd /dev/sde 3. 执行I/O校准操作; ./orion_x86_64 –run <workload_mode> 其中workload mode(负载模式)一共包括5种,对于数据库而言,常用的为dss模式和oltp模式,对于更复杂的需求可以使用advanced模式。 simple – tests random 8K small IOs at various loads, then random 1M large IOs at…