Maclean’s Oracle Database Tech Blog Archives

原文链接： http://www.dbaleet.org/a_simple_case_of_ntp_on_exadata     某客户反映其Exadata服务器的系统时间和NTP服务器不一致，不仅如此，Exadata集群内部的时间甚至也有较大的差异。曾经还发生过由于节点时间不一致导致节点被驱逐的情况。 以下简单的记录一下分析过程： 首先， 通过查看操作系统日志来确认各节点上一次时间同步的时间点： [root@dm02db01 onecommand]# dcli -g all_group -l root “grep ntp /var/log/messages | grep synchronized” 发现很多节点上一次与NTP服务器进行时间同步的日期竟然还是去年。。。 再来看下ntp服务是否正常启动： [root@dm01db01 ~]# ps -ef | grep ntp | grep -v grep ntp 7223 1 0 2012 ? 00:00:39 ntpd -u ntp:ntp -p /var/run/ntpd.pid -x [root@dm01db01 ~]# /etc/init.d/ntp status * NTP server is running…

原文链接： http://www.dbaleet.org/exadata_interleaved_griddisk_1     在了解什么是Interleaved Griddisk之前，首先需要弄清楚默认情况下的Griddisk是如何创建的。我们一起回顾一下之前的文章Exadata存储架构概述：Exadata的存储从底层往上层依次是PhysicalDisk=>LUN=>CellDisk=>GridDisk，  前两个步骤基本可以简单的理解为是一对一的映射，后一个步骤为一对多的映射。   在传统Griddisk的创建过程中，一块CellDisk被分成了多个部分，首先会在Cell盘的最外圈划分一定的区域创建data前缀的gridisk， 这一部分区域是磁盘访问速度最快的区域，被成为hot zone，在ASM中这些GridDisk被用创建DATA磁盘组，用来存放数据库的数据文件， 接下来再在依次往里创建reco前缀的GridDisk， 这一部分是磁盘访问速度较慢的区域，被成为cold zone，在ASM中，这一部分Griddisk被用来创建RECO磁盘组，用来存放flash recovery area以及archived log。当然通常情况下还有一个叫做DBFS的磁盘组，这个磁盘组用来存放RAC使用的OCR和voting disk，以及用来创建数据库文件系统DBFS， dbfs使用的griddisk位于磁盘的最内圈，访问速度是最慢的。当然并不是所有的盘上都创建有以dbfs为前缀的griddisk，前两块磁盘是没有创建dbfs为前缀的griddisk的，因为这一部分空间已经被cell的操作系统使用了。   下图左边就是传统的griddisk了，其中griddisk 1位于外圈，访问速度更快，griddisk 2位于内圈，访问速度相对较慢。     介绍完了传统的grid disk，我们再来看一看interleaved griddisk. interleave本身的意思是交织，交错。上面的图示中右侧就是interleaverd griddisk了。interleave的过程其实在实际上是在创建celldisk的时候发生的，一块interleaved griddisk的容量来自两个方面，例如上图右侧的griddisk 3的空间就是由最外圈部分的浅灰色区域以及中间部分的深灰色区域拼揍而成，同理griddisk 4就是有次外侧的深绿色区域以及最内测的深绿色所组成。 再来看一个具体的实例：下图为一个容量为600GB的高性能（HP）磁盘（实际可用的celldisk空间为558G），在创建celldisk的时候制定了interleaving为normal_redundancy，并且创建了两块griddisk，其中一块名字为data1_interleaving_test, 大小为200G， 另一块名字为data2_interleaving_test，大小为358G。   通过上图可以清楚的看到每块griddisk的构成，首先创建interleaving属性为normal redundancy的celldisk，就将celldisk的空间划分为两块面积均等的部分，空间各占50%。 （（如果属性为high  redundancy则会分成三个均等的部分，各占33.33%））然后创建griddisk的时候再从个50%中个取一半，例如data1_interleaving_test 大小200G，会从其中一个50%中取100G，从另外一个50%中再取100%G，data2_interleaving_test 类似。 那么这种做法的目的究竟是什么呢？ 我个人认为： interleaved更多的来说只是性能折衷的一种方案。 传统的griddisk的处理方式更加极端，使用最外圈创建出来的griddisk的性能可能是使用最内圈创建出来的griddisk的好几倍，导致使用内圈创建出来的gridisk性能比较糟糕，这在某些场景下可能是不适用的，例如某些对ASM磁盘要求性能比较均衡，归档量比较大的数据仓库应用。 那么interleaving griddisk又有什么好处呢？ 我们知道, ASM的normal redundacy中每一个分配的extent都有一个primary copy和一个secondary copy， 分别被称为primary extent和secondary extent。 如果需要读取这个extent的内容， ASM默认会从primary extent中读取所需的信息，而不会从secondary…

原文链接： http://www.dbaleet.org/exadata_interleaved_griddisk_2 下面简单对比一下普通的griddisk和interleaving griddisk的区别： 首先创建普通的celldisk: CellCLI> create celldisk all CellDisk FD_00_cell1 successfully created CellDisk FD_01_cell1 successfully created CellDisk FD_02_cell1 successfully created CellDisk FD_03_cell1 successfully created CellDisk CD_disk01_cell1 successfully created CellDisk CD_disk02_cell1 successfully created CellDisk CD_disk03_cell1 successfully created CellDisk CD_disk04_cell1 successfully created CellDisk CD_disk05_cell1 successfully created CellDisk CD_disk06_cell1 successfully created CellDisk CD_disk07_cell1 successfully created CellDisk CD_disk08_cell1 successfully…

原文链接： http://www.dbaleet.org/the_cirle_of_hugepages_part_5   上一篇文章主要介绍了x86/x86_64架构使用hugepages的可能带来的潜在的好处，本篇则继续上一篇的话题，通过一个典型的案例介绍没有使用hugepages所带来的问题以及与之相关的一些延伸话题。 某 客户新上线的Oracle数据库系统，运行在Linux x86_64平台上，主机配置较高，32核+120G内存，SGA设置90G左右，但是每当数据库运行大约一周以后，前台应用就会变得异常缓慢，经常假 死，有时新连接都没有响应，如果DBA不加干涉杀掉部分local=NO的进程，过一段时间就可能有节点被驱逐。 经过简单的分析，当前数据库主机有如下一些特征： 前台响应缓慢或者新连接无法建立时，CPU占用率并不高，但是奇怪的是有一个系统进程kswapd0占据了单核CPU的100%，其它进程的CPU占用率都控制在单核的各位数； 通过free命令来查看剩余内存，发现所剩的内存已经不多，通过sar -B和vmstat查看发现有较为严重的page in和page out。 问题发生时刻，连接数有一定程度的增加，但是基本都是呈缓慢线性的方式增加，没有剧增的情况。从oracle进程来看，每个连接占的CPU和内存资源都差不多； 从/proc/meminfo来看，页表占用了内存的绝大部分； 操作系统重启的时候，在/var/logs/message中有类似的信息： messages: Feb  10 10:11:40 rac 01kernel: SysRq : Resetting messages:Feb  10 10:16:35 rac01 syslogd 1.4.1: restart. 这个问题并不复杂：本质就是一个内存耗尽的问题，但是另客户非常不解的是：按照规划，物理内存应该是绰绰有余的， 那为什么还出现了内存耗竭的情况呢？ 当然，如果有看过前面的文章就知道，因为没有配置hugepages，导致了随着连接数的增加页表急剧膨胀，并且SGA被频繁的从swap交换空间换入/换出。 在Linux中，  kswapd是负责内核页面交换管理的一个守护进程， 它的职责是保证Linux内存管理操作的高效。当物理内存不够时，它就会变得非常aggressive，就像上文中所说的能占用单核CPU的100%. kswapd 进程负责确保内存空间总是在被释放中， 它监控内核中的pages_high和pages_low阀值。如果空闲内存的数值低于pages_low,则每次 kswapd 进程启动扫描并尝试释放32个free pages.并一直重复这个过程,直到空闲内存的数值高于 pages_high。kswapd 进程完成以下几个操作: 1,如果该页处于未修改状态,则将该页放置回空闲列表中. 2,如果该页处于已修改状态并可备份回文件系统,则将页内容写入到磁盘. 3,如果该页处于已修改状态但没有任何磁盘备份,则将页内容写入到swap device. 注： 每次 kswapd 进程启动扫描并尝试释放32个free pages 不再适用于RHEL 5.4以后的版本。…

原文链接： http://www.dbaleet.org/the_cirle_of_hugepages_part_4     有同学看完我前面三篇文章问到： 虽然内容很多，但是比较零散，我仍然不是太清楚为什么一定要用hugepages，能介绍一下使用hugepages的好处吗? Stay tuned, this is exactly what this article about. 看上去前人之述备矣，我本打算丢一个文档号（ MOS文档 HugePages on Linux: What It Is… and What It Is Not… [ID 361323.1] ）或者网上对这篇文章的翻译给他，但是考虑到网上这篇文档的翻译并不能很清楚地解释更深层次的原因，大多数只是列举了一些事实，所以写下了这篇文章。注意以下是我个人对这篇文档的一些理解，本人力求准确，但是毕竟水平有限，难免出现一些遗漏甚至错误。 Not swappable （使得SGA不可交换） 为啥SGA是可以被换到虚拟内存的？？？ The fact is that Bug 160033 – Kernel swaps out Oracle instead of releasing cache 这个bug最终关闭的状态为Not a bug, 但是同时在这个bug中提到： The basic design of the VM in…

原文链接： http://www.dbaleet.org/the_cirle_of_hugepages_part_3   众所周知，x86是32位的，所以默认情况下，其可寻址的空间为2的32次方——4G。在X86设计之初，4G内存似乎是一个遥不可及的天文数字，但是摩尔定律打破了这一切，所以软硬件的设计和开发商必须想出一个对策来解决4G以上不可寻址的问题。 注意：这里没有说4G以上的内存不可寻址，而是说4G以上的地址空间不可寻址，这两者实际上有区别的。例如4G内存的CPU在32bit的Windows（非server版本）能识别到的内存一般在3G左右。 这其中的主要是主板或者操作系统的限制。因为计算机上一些其他的设备同样需要可寻址，而这一部分地址需要从总的可寻址空间中预留，例如BIOS芯片的ROM，显卡上的显存(RAM)和BIOS(ROM)，以及PCI、PCI-E设备上的RAM和ROM都需要占用一定的可寻址的空间。这个叫MMIO（Memory-mapped I/O）。这里有点off the topic了，所以不再赘述，要了解更详细的原因和机制，请参考以下链接：（RAM limit    PCI hole,   Conventional memory,   3GB barrier ） CPU的设计者碰到了难题了：既要解决4G以上可寻址，又要兼容已有的架构和程序，那该怎么办呢？一种最可行的方式就是通过增加扩展地址来解决4G以上的寻址问题。于是Intel引入一个workaround PAE (Physical Address Extensions)机制：增加20位扩展地址，将原来的32位的物理地址扩展为52位，那么可寻址的空间就增加到了2的52次方——4PB，但是实际上x86只使用了其中的36位，也就是X86实际可寻址的物理地址为64G，而转化的过程为操作系统通过使用页表将4GB的地址空间映射到大小为64GB的物理地址空间。尽管物理地址为52位，但是线性地址还是32位，所以在这种架构下单个程序/进程使用的内存限制实际上仍然还是4G。     注： PSE（Page Size Extension） 使得用户可以使用4M的页表。 PAE （Physical Address Extension）使得32位的系统就能够使用接近64GB的内存的一种技术。 如果PAE和PSE同时使用，则只能使用2M的页表。 x86_64默认使用PAE的扩展—— long mode。 通过上面两个图可知： 是否使用分页是通过CR0寄存器的PG表示来控制的，如果只使用传统的分段模式，则将CR0.PG置为0, 如果启用分页则需要将PG设置为1。使用page的大小则是由IA32_EFER寄存器LME标志以及CR4寄存器的PAE标志和PSE标志控制的， 其中IA32_EFER.LME标志控制是否是否启用IA-32e模式，而CR4.PAE标志为控制是否启用PAE， CR4.PSE标志控制是否启用PSE。但是并不是这三者的任意组合都是存在的，现实中存在的情况为以下几种： page size paging mode CR0.PG IA32_EFER.LME CR4.PAE CR4.PSE 4M PSE 1 0 0 1 4k PAE 1 0 1 0 2M…

原文链接： http://www.dbaleet.org/the_cirle_of_hugepages_part_2 下面用例子来说明为什么使用传统的 4k大小的页表相比hugepages对大内存的管理效率会很低。 some facts: 在x86平台，一条PTE的大小为4Byte；而在x86_64平台， 一条PTE的大小为8Byte。 以下这种场景并不罕见： Linux x86_64, SGA大小为100G， 使用常规的4k的page，连接到数据库的进程数约1000。 page table一共需要100×1024×1024K/4K=26214400条PTE； 那么26214400条PTE需要100×1024×1024K/4K×8Byte=209715200Byte=200M； 从而1000个进程需要100×1024×1024K/4K×8Byte×1000=209715200000Byte=200G。 计算出来的结果真是令人崩溃，但是事实上在你没有崩溃以前， 数据库就已经因为没有内存而崩溃了。 同样条件下，如果使用2M的hugepages进行对比， 则以上的计算方法变为： page table一共需要100×1024M/2M=51200条PTE； 那么51200条PTE需要100×1024M/2M×8Byte=409600Byte=400K； 从而1000个进程需要100×1024M/2M×8Byte×1=409600Byte=400K。 是的，你没有看错，只要乘以1，而不是乘以1000。 综上，可以看到同样是1000个进程，同样是管理100G的SGA，结果却大不相同。 使用传统的4k大小的page开销竟然会达到惊人的200G； 而使用2M的hugepages，开销只有400K。 这其中不仅仅只是对于因为单个进程而言，2M page需要的PTE小于4K  page的PTE， 最大的一个原因是在于使用4K page的话，有多少进程使用SGA， 就需要多少套PTE，相反如果使用2M page则无论有多少进程使用SGA，共享的都是同一套PTE。 注： 此问题曾经困惑了我很长时间，在公司Linux PM的帮助下终于弄懂了这个算法，这里表示诚挚的感谢，当然希望对本文的读者能有一些帮助。 Hugepages really make some differents。

原文链接： http://www.dbaleet.org/the_cirle_of_hugepages/   故事的开始得从三句名人名言说起： IBM的创始人Thomas J. Watson曾经说： “全世界只需要5台电脑就足够了”； Microsoft的创始人Bill Gates曾在一次演讲中说：“个人用户的计算机内存只需640K ”； Intel创始人之一Gordon Moore曾经说：“当价格不变时，集成电路上可容纳的晶体管数目，约每隔18个月便会增加一倍， 性能也会增加一倍”。 后 来的故事我想大家都知道了，前面两句话在今天看上是十分可笑的，而最后那条就是著名的摩尔定律。有句话叫前人栽树，后人乘凉，同时也有一句话叫做父债子偿，天经地义。现今大多数科技成果都是后 人都是基于前人的一些经验或者教训，然后逐步增强或者改良，直至完善。hugepages的出现同样也是因为摩尔定律导致了主机内存越来越大，最后不得不 对于标准pages的改进以提高效率。要了解hugepages首先必须清楚Unix/Linux内存的分配机制。本文从入门的角度介绍Linux的内存 分配机制，当然这一部分内容相信很多人都在计算机体系结构这门课程中学到过，这里就重新温习一下。 早期因为程序非常简单并且使用的内存也非常小，程序的内存地址都是使用程序地址对应物理地址这种这种直接映射的模式，通俗的说就是物理地址是在程序中写死的。想想使用汇编直接操作物理地址是多么壮观的工程呀。对于一个大型的软件系统来说，这部分工作几乎是不可能完成的。后来开始使用“段页式”的方式来管理内存的寻址。用一个时髦的词来说就是引入了“虚拟化”技术。现代操作系统都会使用受保护的虚拟地址模式（protected virtual address mode）来管理内存，Linux下分为三类地址：逻辑地址（Logic Address）、线性地址（Linear Address）与物理地址（Physics Address）。下面是这三者的对应关系。     简单的说就是逻辑地址通过分段机制映射转化为线性地址，然后线性地址通过分页机制映射转化为物理地址。因为这里是介绍hugepages，所以我这里不打算介绍分段机制，主要对分页机制做简单的阐述。 事实上，地址映射的过程远远不止上图中这么简单。例如在分页机制映射中，一般需要经过四级映射，也就是将线性地址映射为物理地址的过程中，需要从内存中读取至少四次页目录表（Page Directory）和页表 (Page Table)。 众所周知，CPU寄存器与内存的访问速率相差至少一个数量级，所以如果使用传统的分页机制的开销将会非常大。所以在现代的X86架构中，集成了一种被成为TLB（Translation Lookaside Buffer）的硬件级缓存。TLB读写速度非常快，基本和CPU寄存器的速率在一个数量级，而TLB中保缓存了最近使用过的线性地址和物理地址的映射关系。如下图所示：   那么将线性地址映射为物理地址的过程如下：首先到TLB中找到这个条目是否存在，如果不存在则为TLB miss，然后使用页表的方式进行寻址，最后把这个映射关系更新到TLB中以备下次使用。由于TLB是大小有限，而一旦出现TLB miss，则其查询的代价很高，所以现代CPU架构基本都进行了一些优化以提高地址映射的效率。，例如 线性地址到物理地址转换一开始就选择同时在TLB和页表进行查询，而不经过TLB查找是否成功的等待； 使用多级TLB以及软TLB， 在CPU context swtch的时候不flush整个TLB。 To be continued…     © Steven Lee for Oracle Exadata & Best…

原文链接： http://www.dbaleet.org/buildin_security_features_of_exadata/     Oracle在这篇白皮书（ORACLE EXADATA DATABASE MACHINE SECURITY OVERVIEW）中对Exadata的安全特性做了一个总体性的概括。不过先等一等，不要急于打开。为什么？因为它基本上什么都没说！！！我来简单概括一下吧：文中一共介绍了“Exadata的几大安全特性”： 1. Exadata可以使用Advanced Security Option来对数据进行加密解密。使用ASE算法的时候可以利用Intel XEON 5600 CPU内建的硬件级的加密/解密技术大幅提升加/解密的速度； 2. Exadata可以使用Oracle Database Vault对数据库进行访问控制； 3. Exadata可以使用Oracle Audit Vault对数据库进行审计； 4. Exadata可以使用Oracle Database Firewall防范数据库的非法访问和注入攻击； 5. Oracle ERP/SAP已经对Advanced Security Option, Oracle Database Vault， Oracle Audit Vault， Oracle Database Firewall进行了认证。 拜托， 老兄，这个也能算作Exadata的安全特性？被你打败了。。。 Exadata除了可以支持标准Oracle Database 11gR2的一些安全组件和安全特性以外，还提供了三大安全模式。它们分别是：Open Security Mode（开放安全模式）， ASM-Scoped Security Mode （ASM范畴安全模式）以及Database-Scoped Security Mode（数据库范畴安全模式）。这三大模式是针对ASM/database访问cell节点的griddisk是否进行限制以及如何限制进行划分的。     Open Security Mode 最简单的肯定是Open Security…

我(maclean)参加了中国IT博客大赛, 以下是我自荐的一些博文，如果觉得好 请移步到http://blog.51cto.com/contest2013/2923249 投我一票         【视频教学：性能优化】Maclean Liu的Oracle性能优化讲座第一回《真正读懂Oracle SQL执行计划》 推荐理由:  真正读懂ORACLE执行计划，即是必要的，也是困难的     【性能调优】Oracle AWR报告指标全解析 推荐理由:  可能是最详尽的关于ORACLE AWR快照的解释     深入理解Oracle中的Mutex 推荐理由:  作者详尽介绍了Oracle内互斥锁mutex的原理，不过多得的关于ORACLE原理的研究分享     【Oracle Database 12c】12c 常见问题FAQ 推荐理由:  database 12是当红炸子鸡，研究Oracle 12c推荐看这篇     全面解析9i以后Oracle Latch闩锁原理 推荐理由:  如果你对深入了解ORACLE内部原理感兴趣，那么这篇关于latch的介绍值得一看   Maclean教你读Oracle 10046 SQL TRACE 推荐理由:  10046 是 ORACLE入门必备工具节能   深入了解Oracle ASM(一):基础概念 推荐理由:  ASM是ORACLE提供的适合于存放ORACLE数据库的LVM，ASM在近年的使用率大大普及，有必要了解一下其基础概念     Oracle数据恢复专题 推荐理由:  恢复恢复是Oracle中永恒的话题， 只要有数据 就有备份恢复的需求。 而在国内对于备份以及备份的可用性往往被企业所忽视。这造成了再数据库恢复上存在着东西方的差异。 更多的老外DBA把经历花在对Oracle内部原理和性能优化的研究上。…