Maclean’s Oracle Database Tech Blog Archives

http://www.dbaleet.org/exadata_performance_monitoring_swiss_army_knife_cellsrvstat/ 如果需要查找Exadata cell（存储节点）的offloading/smart scan/storage index的信息，通常我们可以在数据库端通过过滤查找v$sql, v$sysstat之类的动态性能视图得到，有没有更简单的方法呢？ 从某一个版本开始在每个Exadata存储节点中加入了一个叫做cellsrvstat的小工具，这个工具收集针对当前cell节点进行收集，并且收集的信息非常全面，堪称Exadata上的“上古神器”。 [root@slca04cel01 ~]# cellsrvstat ===Current Time=== Fri Aug 23 08:12:19 2013 == Input/Output related stats == Number of hard disk block IO read requests 0 1823855 Number of hard disk block IO write requests 0 849658 Hard disk block IO reads (KB) 0 1390317 Hard disk block IO writes…

  http://www.dbaleet.org/default_ports_which_exadata_used/   Exadata使用的默认端口，方便设置防火墙的规则，出自官方手册，简单记录下： Source Target Protocol Port Application NA Database management SSH over TCP 22 SSH NA Database servers, Exadata Storage Servers, and InfiniBand ILOMs SSH over TCP 22 SSH NA KVM SSH over TCP 22 SSH for serial sessions to MPUIQ-SRL module NA Storage management SSH over TCP 22 SSH NA KVM Telnet…

原文链接： http://www.dbaleet.org/how_to_upgrade_cell_image_of_exadata/ Exadata存储节点，即我们常说的cell节点，在Exadata中承担着双重作用： 一是提供存储的介质，所有的非二进制文件都存在在此; 二是提供大量的offloading的任务，计算节点（db 节点）通过smart scan等，把一部分任务“下沉”分布到cell节点。 而升级cell的image中主要是升级以下内容： 操作系统的信息：包括一些基本的rpm包，操作系统内核， 固件类信息：例如磁盘控制器的固件，ILOM的固件等； 驱动类信息：依赖于内核版本的infiniband驱动ofa； 升级Exadata的cell的image可以使用在线的方式进行也可以使用离线的方式进行，在线升级的好处是无需停止数据库服务，但是通常单个cell节点image升级的时间接近三个小时，如果一台满配的Exadata，升级完所有cell的image所需要花费的时间为14×3=52个小时，这还不包括检查，如果出现意外情况的troubleshooting的时间。实际上在线升级完一台满配的Exadata的cell image一般需要花费60个小时。另外就是在线升级的过程中，其它节点如果发生坏盘，那么就有可能会造成数据的丢失。为什么呢？因为在升级某一台cell的image的时候，并不做rebalance的动作，升级这个过程中，这台cell的所有盘都相当于是offline状态的，这台cell中所有盘中保存的信息，在其它所有cell节点有且仅有一份镜像。（这里说的是正常冗余的情况，如果是高冗余，则为两份）。如果这个时候其它cell中有一块盘发生了不测，则就有可能丢失数据，因为等这个cell的image升级完成以后，会自动同步Exadata的元数据和其它对应镜像的修改后的信息，如果坏的盘恰好是“某一块”，则悲剧就诞生了。当然，你也可以使用离线的方式进行升级。离线需要停止db节点上的集群和cell节点上所有节点的celld服务。但是它的好处在于，可以进行并行地进行cell image的升级，例如可以一次性的升级完所有的cell节点的image，时间也是接近三个小时。不管是四分之一配，半配，还是满配，通通只要三个小时。但是同样也存在风险，例如如果多台cell被刷坏了，操作系统起不来，这样也是比较危险的，但是这种情况相比坏盘概率小很多，可以说几乎和中彩票头奖的概率差不多，如果你不幸遇到这样的情况，请记得下次帮我去买张彩票。 在线升级cell的image往往需要较长的时间进行详细的规划，防止各种突发故障，这个并非三五百字可以讲完，所以我这里只写出离线升级cell image的方法：以下是为某客户Exadata cell image从11.2.2.4.2升级到11.2.3.2.1的全部过程: 升级前的准备工作 1.准备cell image的patch: 下载cell image的patch，patch号为14522699。使用root用户上传到eccel01节点的/opt/oracle.SupportTools/目录下。如果是使用ftp上传，需要注意使用二进制bin模式。 使用以下命令进行解压： #unzip p14522699_112321_Linux-x86-64.zip 使用md5sum对解压后的文件进行md5码校验，以下五个文件的md5码应该为： 3a8f090e9410c80b0b3a27026472cd0 patch_11.2.3.2.1.130109/11.2.3.2.1.130109.iso 69d3bf2dfc6f650bd9f4f2413b084ae2 patch_11.2.3.2.1.130109/11.2.3.2.1.130109.patch.tar f2d7a739d9b813f3ed1c38f25678b603 patch_11.2.3.2.1.130109/dcli 0a327e437d81be782e4765263cb61b22 patch_11.2.3.2.1.130109/dostep.sh 8ea5f9270dbaa1f6c8a94630ad150a58 patch_11.2.3.2.1.130109/patchmgr 如果不正确，则需要重新上传解压。 2.准备cell_group文件 检查/opt/oracle.SupportTools/onecomman/cell_group文件中的内容是否为： dm01cel01 dm01cel02 dm01cel03 以上以实际的cell主机名代替。 3. 检查所有节点的cell.conf文件是否一致: #/opt/oracle.cellos/ipconf -verify 4. 检查ssh是否支持patchmgr: 打开ssh的debug模式 #ssh -v -v ecdb02>ssh_client_debuglog.txt 按照提示输入密码…

原文链接：  http://www.dbaleet.org/how_to_upgrade_db_image_of_exadata/   相比cell image而言，db image升级的风险要小很多，因为db节点没有存储任何数据。当然为了保证万无一失，在升级db image之前请先做好数据库备份。 在升级过程中db image的版本允许与cell image版本不一致，但是不允许db和cell的image的版本长期不一致，因为有可能潜在版本兼容性的问题。 当前db image补丁的介质为一个iso文件，类似于操作系统的补丁包。在早期的版本中，是使用rpm -UVh这样的方式来更新Exadata db节点的rpm包，这种方式相对比较繁琐，容易出错，所以在以前的版本中存在一种被称为minimal pack的补丁，这个补丁只升级db节点的操作系统内核，firmware， infiniband驱动等重要组建，其它的rpm放在另外一个补丁内，作为可选安装。从11.2.3.1.0开始采用的是Linux的yum来完成的，yum的优势在于简单，并且能自动解决rpm之间的依赖性。可以搭建一台单独的yum server作为yum源，这样所有的db节点作为yum的客户端都从这台服务器获取rpm包，然后进行升级。也可以采用db节点本机作为yum的源，下面就是将db节点本机作为yum源完成一台db节点升级的详细步骤。 将iso文件mount到db节点的一个本地目录； 在db节点安装所需的yum的rpm包； 配置yum的源，将其源地址指定为iso文件挂载的目录； 运行yum update对db节点的所有rpm包进行升级； 删除老版本的rpm包 这一个过程被oracle封装到一个脚本里面，所以整个过程非常简单，只需要运行一个脚本，剩下的工作都交给自动脚本来完成。详细步骤如下： 升级前的准备工作 1.准备db image的patch 下载以下介质并且使用root用户上传到所有db节点的/u01/patches/linux_patches/iso目录下： db节点的image p16432033_112321_Linux-x86-64.zip db节点yum包p13741363_112321_Linux-x86-64.zip 解压两个介质安装包： #cd /u01/patches/linux_patches/iso #unzip p16432033_112321_Linux-x86-64.zip #unzip p13741363_112321_Linux-x86-64.zip 解压以后会得到一个名为13741363文件夹和一个名为 112_latest_repo.iso的文件 2. 对dbserver进行备份： 给dbserver_backup.sh文件赋予执行权限： #chmod +x /u01/patches/linux_patches/13741363/11.2.3.2.1/dbserver_backup.sh 运行备份脚本： #sh /u01/patches/linux_patches/13741363/11.2.3.2.1/dbserver_backup.sh 整个过程大约需要30分钟：   3. 卸载所有的nfs文件系统 如果使用了nfs，请先umount nfs。…

http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_8/   在11.2.0.2以上的版本中，DRM的read mostly的功能同样也有一些细微的改进，但是这些改变都是背后“偷偷摸摸”进行的，不大可能能在oracle的官方文档或者支持网站中找到。 首先一大改进叫做persistent read mostly，在以往的版本中， read mostly这个特性并不是可以持续的。换而言之，如果集群彻底的关闭或者重启，那么重启以前的read mostly就复位了，本来read mostly的特性已经根据应用的业务特点做了足够的优化，但是重启以后，所有的优化都消失了。而persistent read mostly就是为了解决这一问题而来。 所以11gR2中引入了一个新的后台进程叫做GEN0， 这个进程其中一部分工作就是与persistent read mostly 相关的，这一部分工作包括: kcl downconvert object locks GEN0 kcl update persistent read mostly info GEN0 kcl initiate persistent read mostly GEN0 以上GEN0的功能节选来自：Maclean Liu的blog： http://www.askmac.cn/archives/learning-11g-new-background-processes.html GEN0平时会把read mostly的对象做一个read mostly的标记，然后更新到对应的seg$条目中去。我们可以通过以下SQL来查询其对应的persistent read mostly的对象： PROCEDURE list_readmostly IS BEGIN FOR cur IN (select owner, segment_name, partition_name…

http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_7/ 我们可以从新版本引入的一些隐含参数中推测到DRM会有哪些改进。其中最重要的三个隐含参数是控制DRM频率以及最大值的参数：_lm_drm_batch_time，_lm_drm_max_requests, _lm_drm_min_interval，这三个参数互相配合共同控制DRM的行为。 _lm_drm_batch_time这个隐含参数默认值为10秒。简单的说就是LMD进程会检测DRM请求的最小间隔为10秒钟。更详细的说就是LMD进程如果需要进行DRM操作，那么必须距离上一次DRM中间需要间隔10秒钟。这样做的好处在于在DRM请求比较频繁的情况下降低LMD进程的繁忙程度，防止多个节点的来来回回的进行DRM请求导致的性能下降。如果按照时间间隔进行批量的提交则能很大程度上避免这个问题的发生。 同样_lm_drm_max_requests则是控制DRM请求的上限的，如果DRM请求累计的数量超过参数默认值的100次，那么这样就达到了LMD提交量临界值上限，即使没有超过10秒钟，LMD依然会进行DRM。 _lm_drm_min_interval这个隐含参数的模式值为300秒，大小为_gc_policy_time的一半。其中_gc_policy_time的默认值为10分钟。300秒只是一个最小值，准确的说对于同一个对象的两次连续的DRM操作时间间隔至少需要300秒，同时需要注意的是这个开关对于read mostly和undo affinity并不适用。 另外几个隐含参数我这里就不介绍了，有些是为了解决某些bug引入的，有一部分则对于drm行为的控制并不是那么关键。

原文链接：  http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_4/ 这篇文章不打算做过多的描述，主要看图表说话：（当然反过来说图表也不一定代表事实，例如某声称用事实说话的节目不也经常借着这个幌子向全国人民撒下弥天大谎？） 如果您在metalink上，搜索DRM bug， 将会得到如下结果： （我这里仅仅只是截取了其中的很小的一部分）     这些bug一来是数量多，而来危害大，我大致总结了下其结局包括以下四类：   数据库宕机，节点驱逐， 数据库挂起， ORA-00600。 以前在MOS上有一篇专门的文档， 列举了所有的与DRM相关的bug，不过这篇文章现在已经消失了，我已经不记得那个文档的ID了，只能找到一个非常早的DRM bug列表 (注意这个表格可以翻页)： BUG# FIXED VERSION DESCRIPTION BUG:5031173 10106 10203 Instance terminated by LMON ORA-602 BUG:4755405 10106 10203 EXCESSIVE WAITS FOR “GCS DRM FREEZE IN ENTER SERVER MODE” IN GSIAT BUG:4151363 10203 Drop / truncate slow in RAC BUG:3659289 10105 10201…

原文链接： http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_2/ Oracle RAC从10g开始正式引入DRM，但是你是否知道实际上DRM在9i甚至更早以前， Oracle产品架构师就已经在构思这个功能。我们通过查询系统隐含参数发现，在9.2版本中，如下三个十分“可疑”的隐含参数： _lm_dynamic_remastering (if TRUE enables dynamic remastering) _lm_dynamic_lms (dynamic remastering bucket window size) _lm_file_affinity (mapping between file id and master instance n umber) 可以看到这里核心参数为_lm_file_affinity，但是这个参数非常神秘，几乎鲜有人知道这些参数的用法。但是从Oracle TPCC测试的初始化参数中， 我们还是窥测到了_lm_file_affinity的真身： _lm_file_affinity=”\ 14-72,627-664,1304-1331,1641-1645,1701,1713-1717,1798,1826,1873=1:\ 73-119,665-713,1332-1359,1646-1650,1702,1718-1722,1786,1825,1827,1874=2:\ 120-166,714-762,1360-1387,1651-1655,1703,1723-1727,1787,1828,1839,1875=3:\ 167-213,763-811,1388-1415,1656-1660,1704,1728-1732,1788,1829,1840,1876=4:\ 214-260,812-860,1416-1443,1661-1665,1705,1733-1737,1789,1830,1841,1877=5:\ 261-307,861-909,1444-1471,1666-1670,1706,1738-1742,1790,1831,1842,1878=6:\ 308-354,910-958,1472-1499,1671-1675,1707,1743-1747,1791,1832,1843,1879=7:\ 355-401,959-1007,1500-1527,1676-1680,1708,1748-1752,1792,1833,1844,1880=8:\ 402-448,1008-1055,1528-1555,1681-1685,1709,1753-1757,1793,1835,1845,1881=9:\ 449-494,1056-1103,1556-1583,1686-1690,1710,1758-1762,1794,1836,1849,1882=10:\ 495-540,1104-1151,1584-1611,1691-1695,1711,1763-1767,1795,1837,1863,1883=11:\ 541-586,1152-1199,1612-1639,1696-1700,1712,1768-1772,1796,1838,1872,1884=12″ 可以猜测到以上参数出自一个12节点的rac数据库， 数据文件号从14开始到1872结束，连续的文件用连接符号隔开，每个节点上map了多个数据文件。 在9i中，上述情形更像是通过手工指定了文件的master节点，所以算不上DRM。而DRM功能的真正实现是始于10gR1这个版本，但是因为在10gR1中只实现了粗粒度的数据文件级的file affinity，但是dynamic remaster的条件过于苛刻，以至于很多人甚至根本就没有察觉到这个特性的存在。到了10gR2, file affinity进一步演化为更细粒度的object affinity，并且同时引入了undo affinity。 用一句最简单的话概括object affinity就是，哪个节点访问这个object的频率较高，就由哪个节点来充当master节点。具体的阈值可以由以下两个参数来决定： _gc_affinity_time （Time…

http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_6/ 很多童鞋以为之前的DRM专题已经结束了，或者是我已经把它遗忘了。 不！”这次大师你真的错了“。因为真相只有一个：那就是我的思维过于错乱，并且不习惯一次性把所有该说的说完。 以下基于Oracle database 11.2.0.3版本，通过一个烂大街的”magic sql”找到_lm_drm开头的隐含参数： SELECT x.ksppinm name, y.ksppstvl value, x.ksppdesc description FROM SYS.x$ksppi x, SYS.x$ksppcv y WHERE x.inst_id = USERENV (‘Instance’) AND y.inst_id = USERENV (‘Instance’) AND x.indx = y.indx AND x.ksppinm LIKE ‘_lm_drm%’ / 这样我们可以发现有这么一些有意思的参数（不要问我为什么你的库里面有些参数没有，先看看你的版本是不是在11.2.0.3哦，亲） name value description _lm_drm_batch_time 10 time in seconds to wait to batch drm requests _lm_drm_disable 0…

Some questions raised by readers regarding Exadata simulator Q1: Hi, Steven, I followed all of your steps but with no luck.  I encountered the below errors while creating flashcache, can you help me with this? Initialization of celldisk CD_disk06_cell1 on /opt/oracle/cell11.2.3.2.0_LINUX.X64_120713/disks/raw/disk06 completed. ossmmap_map: mmap failed for DiskHT len: 234881024 as there is insufficient memory max_mem 3512729600…