分类目录归档：Exadata

Exadata 的4种刷机方法——Reimage

发表于 2014 年 3 月 10 日 由 Lunar

明天又要刷机器了，装机工很久没玩，快忘光了，温习一下，O(∩_∩)O哈哈~ 1，刷机前先检查和保留当前系统关键部件的信息，例如： 2，跟NOTES 888828.1的内容，找到相关的image，download后，解压，例如： unzip ImageMaker.tar.zip tar -pxvf ImageMaker.tar DB的image解tar后，可以发现 dl360 目录 CELL的image解tar后，可以发现 dl180 目录 这是因为，Exadata早先跟HP合作推出的V1，用的都是HP的pcserver系列，计算节点的型号是 dl360，存储节点的型号是 dl180，后来也就一直都没有更改了。 我们有四种方式刷机： 1. 用U盘刷机，也就是 USB flash thumb drive 2. 制作ISO image，使用ILOM指定iso的方式（当然如果刻录成光盘，也可以使用DVD模式） 3. 制作一个紧急启动的iso文件（类似于紧急启动盘），然后把image放在NFS上，进行刷机 4. 使用PXE+NFS 上面的4种方法，对于1/4配置来说，哪个都不复杂，用U盘和ISO Image最简单，也最省心。 对于满配或者大量的reimage工作来说，显然U盘就太不可取了，会累死人的，可以使用PXE+NFS和ISO image。 无论哪种方式，制作Reimage的命令都是一个makeImageMedia.sh，语法如下： Exadata出厂时带有双操作系统，一个是Linux，一个是solaris x86，通常，至少国内的客户绝大部分都会选择使用Linux，因此，在安装完成后，我们需要做reclaim操作。 如果是Reimage，那么我们也可以在制作U盘，image或者使用PXE时带上 … 继续阅读 →

发表在 安装和升级 | 标签为 , , | 2 条评论

看图说话——ASM实例和ASMB进程

发表于 2014 年 3 月 9 日 由 Lunar

先看一下ASM实例的大体部署： 我们都知道，ASM实例管理着元数据，普通数据库实例通过查询元数据的信息来访问相应的ASM文件。 ASM实例和数据库实例都可以访问一组普通的磁盘，这套磁盘被称为磁盘组。 然后，数据库实例直接访问ASM文件的内容，并在与ASM实例通信时获取有关这些文件的分布信息。 Group Services用于注册数据库实例查找ASM实例时所需要的连接信息： Group Services用于注册数据库实例查找ASM实例所需要的连接信息。 当ASM实例mount一个磁盘组时，它就将磁盘组的信息和连接串注册到Group Services。 数据库实例知道了磁盘组的名称，就可以找到应该连接到哪个ASM实例。 ASM实例有哪些独特地方： 1，INSTANCE_TYPE = ASM 2，startup = startup mount(11.2以后，可以直接对ASM实例 startup，但是本质还是startup mount)，对于ASM实例，mount选项不会去mount数据文件，而是mount在参数文件中ASM_DISKGROUPS指定的磁盘组 3，connect / as sysdba(10g) 和 connect / as sysasm(11.2) ASM的后台进程有很多，具体可以参考reference中的描述，这里只想研究一下数据库和ASM之间负责心跳机制的ASMB进程。 我们知道ASMB进程实际上是提供了一个数据库实例和ASM实例之间通信的桥梁，比如在数据库中创建、删除文件，或者修改文件等等的跟存储物理变化相关的操作。首先，我们观察下，他们在CRS,ASM和数据库启动过程中的启动顺序和先后关系： ASM的alert： DB的alert： ASM和数据库实例的ASMB进程都分别将信息注册到css中，参看ocssd.log: 这里，数据库启动时，ASMB的活动过程： 1，ASM实例的ASMB进程启动(spid: 3637，asm_asmb_+ASM1) 2，ASM实例的ASMB进程启动了一个连接到ASM实例的进程（spid：3641，oracle+ASM1_asmb_+asm1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))） … 继续阅读 →

发表在 ASM, Exadata | 标签为 , , | 留下评论

快速创建1000用户，每用户1000表，1000索引，1000个trigger

发表于 2014 年 3 月 4 日 由 Lunar

有时候为了方便测试，我们需要制造一些复杂的数据，比如这里，我们快速的创建1000用户，每用户1000表，1000索引，1000个trigger

发表在 POC和性能调整, Scripts | 标签为 , | 一条评论

Exadata上验证ASM磁盘头备份的位置

发表于 2014 年 3 月 3 日 由 Lunar

我们都知道，从Oracle 10.2.0.5开始，ASM磁盘会自动备份磁盘头块，备份块的位置在第2个AU的倒数第2个块上。 通常，缺省情况下，AU SIZE是1M，每个AU可以有256个block（每个block 4k），256*4k()=1M 因此，第2个AU同样存放了256个block（0~255），其备份块的位置为 au=1 blkn=254(au和block都是从0开始计数的) 具体的恢复案例，可以参考： ASM磁盘头被fdisk损坏的修复过程 那么在exadata上，缺省的AU是4M，也就是每个AU可以存储 1024个block，即 block 0 ~ block 1023 那么第二个AU的倒数第二个block就是 au=1 blkn=1022 ( au和block都是从0开始计数的 ) 我们来检测一下是不是这样： 注意： 这里kfed命令中，需要指定ausz=4m，否则kfed缺省按照1M来计算，那么结果就是错误的了： 在kfed中指定ausz=4m，检测结果： 经过检查，我们发现，这个规律在exadata上依然有效，ASM除了缺省4M的AU，其余没什么变化，O(∩_∩)O哈哈~ 顺便介绍一个小方法，快速计算备份块的位置：（该方法根据ASM Support Guy修改而来）

发表在 ASM, 内部机制 | 标签为 , , | 一条评论

exadata存储节点上的/etc/init.d/cell.d和celladmin

发表于 2014 年 2 月 27 日 由 Lunar

在cell节点上，系统启动时，Oracle 运行 /etc/init.d/cell.d。使用celladmin操作系统用户执行 /etc/init.d/cell.d，运行“alter cell startup services rs”脚本启动Restart 服务。 休眠1秒钟后，这个脚本运行“alter cell startup services all”来启动了所有其他的进程，包括CELLSRV和MS。 在/etc/init.d/cell.d脚本中存在一个检测机制，用以确定是否存在任何故障或不正确的配置。如果存在，Oracle会尝试从最近一次好的状态重新启动。 上述内容，在/etc/init.d/cell.d中相关内容如下： #this is just to make sure that if MS was running then it is down (with/without RS) su celladmin -c “. /etc/profile.d/cell_env.sh; cellcli -e … 继续阅读 →

发表在 内部机制 | 标签为 , , | 留下评论

整理了一下以前老blog中的exadata介绍的link，顺便更新下Exadata X4的内容

发表于 2014 年 1 月 7 日 由 Lunar

最近有些小伙伴问起exadata的一些古老问题，这里总结下，顺便根据白皮书小小的更新一下X4的东东（迄今为止，我还没见过X4的真神，O(∩_∩)O哈哈~），期待年后的第一个X4项目中。。。： 最新的Exadata版本 2008年Oracle推出业界第一个全新架构的设计Exadata V1，以满配为例：内存 256G，64Core，没有flashcache 2009年到2010年年底之前，Exadata硬件是V2系列的多，image版本是11.2.2.x比较多，2011年，image版本11.2.2.4.2多（一般都升级上到这个了，相对稳定），第一次在硬件中增加了Flashcache组件，可以提高OLTP的处理能力,V2的硬件，以满配为例：64G内存，576G，内存，Flash容量5.3T 2011年和2012年的主要的exadata硬件是Exadata X2,image主要版本是11.2.3.1.0和11.2.3.1.1增加了磁盘容量（504T），CPU 96core和内存1T 2012年底推出Exadata X3系列，2013年年初随着Exadata X3系列的推出，image升级为11.2.3.2.0和11.2.3.2.1（这个是目前主流的11.2.3.2.x的版本），最显著的软件特征是WBFC(WriteBack FlashCache)。硬件增加了大幅增加了Flashcache的容量（22.4T），以及CPU 128core和内存2T 2013年底，Oracle推出了Exadata X4系列，现在最新的image版本已经是11.2.3.3.0了，最新的硬件是Exadata X4-2，硬件再次升级以满配为例：flashcahe 44.8T，CPU 192 core，内存4T，同时，IB网络的连接方式从Active-Backup到Active-Active（带宽40G/b 升级到 80Gb/b） 软件的更新（image 11.2.3.3.0）： 1，的在1/4 Rack和1/8 Rack的转换，从以前的好几条命令，封装成1一条命令（alter cell eighthRack=TRUE） 2，带有Automatic Flash compression功能（一条命令而已，相同image下，X3跟X4 硬件，命令稍微有点区别，alter cell flashCompress=TRUE和alter cell FlashCacheCompX3Support= TRUE） 3，在线替换磁盘控制器电源（Disk Controller … 继续阅读 →

发表在 FAQ | 标签为 | 留下评论

exadata HC-检查是否有硬盘需要更换

发表于 2013 年 11 月 24 日 由 Lunar

在做exadata的检查的时候，我们通常收集如下信息： 1，exachk 2，sundiag 3，diagcollect（GI版本从11.2.0.4.x开始， 可以使用TFA Collector） 4，awr 5，db节点和cell节点的alert 6，osw 根据上述检查内容是否存在异常可能还需要 CheckHWnFWProfile等等。。。。 本文主要分析如何识别磁盘损坏的内容。 ++++++++++++++++++++++++++查看cell 的alert，检查是否有磁盘需要更换的信息： 检查cell的alert告警信息： dcli -g cell_group -l root “cellcli -e list alerthistory” 查看关键内容： 例如： +++++++++++++++++++++++++++看sundiag的信息： 收集sundiag信息后，你会发现，每个db节点和cell节点的文件非常多，包括RAID，HCA, Infiniband，。。。等等 例如： 针对磁盘损坏信息，主要检查如下内容： —————–检查坏盘： ———————检查报告了“先兆失效”的盘： ———-检查告警的磁盘信息： 使用cellcli查看磁盘的错误信息： 检查ASM的日志是否有类似如下的告警： 1. WARNING: failed to … 继续阅读 →

发表在 日常运维 | 标签为 , , | 留下评论

如何看待exadata的cell节点出现的writethrough/wirteback模式更换或者控制器充放电信息

发表于 2013 年 11 月 24 日 由 Lunar

Exadata使用的是LSI的disk driver，在定期进行的HC中，如果cell上出现类似下面的信息，需要考虑是否需要更换或者bug： 这个信息意味着disk controller写cache的策略从”write-back” 更改为 “write-through” 了，原因是电池学习周期（battery learn cycle）正在进行。 这个学习周期一年回周期性的执行4次，这个操作主要是每次执行一次控制器电池的充电和放电（discharge and charge）操作。 在Image 11.2.1.3之前，每个月执行一次 从Image 11.2.1.3开始，每3个月执行一次： 每年的1月/4月/7月/10月 的17日凌晨2点 这个缺省的时间(下一次学习的时间)可以使用命令修改，例如： cellcli> alter cell bbuLearnCycleTime=”2013-01-22T02:00:00-08:00″ Oracle推荐所有cell磁盘的电源学习周期是同一个时间。 众所周知，Write-through 的性能比 write-back 差。但是当存储crash或者电源丢失（looses power）发生时，write back有丢数据的风险。 因此，在电池学习周期中，会自动将写策略从写回模式（write-back）修改为写模式（Write-through） 如果在cell 的alert上看到类似下面的信息： 需要连接到cell节点，查看一下电池充电的百分比： 当充电完成后，可以在cell的alert上看到如下信息： 连接到cell节点，查看磁盘的写模式（writethrough/writeback）的状态，可以发现： 同样在 上面信息显示了10月17日凌晨:02:00cell01上有一个逻辑盘开始学习，完成时间是10月17日早上7:33。充电完成后，磁盘驱动器已经改回了writeback模式。 通常电池充电（Learning state）可能需要几个小时，如果充电完成后没有自动改回wirteback模式，可能是控制器电源出现问题，需要联系support … 继续阅读 →

发表在 体系架构, 安装和升级, 硬件配置 | 标签为 , , , | 留下评论

解除部分exadata上的“强安全策略”

发表于 2013 年 11 月 9 日 由 Lunar

在安装Exadata时，执行onecommand的后面几步ResecureMachine相关的内容后，安全性会得到增强，我们戏称为“强安全步骤”，不同的onecommand版本的step稍有差别，但是可以从deploy脚步的执行步骤的名称中识别出来，例如onecommand p14210449 （对应image 11.2.3.1.1）的如下（其中setp24~setp26）： 在onecommand p16383189（对应 image 11.2.3.2.0，image 11.2.3.2.1的步骤跟这个一样的）中是如下步骤，其中step25~step28是“强安全”： 在执行了上述步骤后，一些客户使用一段时间后对于其中的“强安全”感觉很不方便，希望我们修改其中的部分限制，比如90天必须修改口令等等，下面就类似问题给出解决方案。 本文的方法来自于内部exadata的一个文档，且在多个客户都已经实施过了： 1， 解除口令限制和复杂度： 使用root用户修改/etc/pam.d/system-auth，这是一个password的的入口文件（老一点的linux系统一般用/etc/pam.d/passwd），将其中的”min=disabled,disabled,16,12,8″ ，使用这个规则建立的口令很难被破解，修改为”min=1,1,1,1,1″，大大降低了口令的复杂程度（容易被破解，例如“oracle”，或者exadata上的缺省的welcome等等，都是常用词汇。。。） 然后重置root口令即可（exadata上大部分缺省口令是welcome） 2， 解除90修改口令的限制： 执行下面的命令修改用户口令修改策略： 当然，你需要在所有节点依次执行，exadata上的dcli可以很方便的完成： 然后使用上述用户登录的缺省口令就可以登录了（缺省口令都是welcome） 3， 重新配置各个节点的SSH信任关系（因为执行了ResecureMachine以后，SSH信任关系操作就不可以了）： 也可以参考我之前的一篇blog（其中的脚本在11.2.0.1的除windows平台外的任何一个安装包中都可以找到）： 使用Oracle安装包的ssh配置机器互信 注意： 如果有问题可以参考bug 12389246 4， 解除SSH连接超时的限制： 顺便多说一下，由于某些原因用户可能会出现密码尝试次数过多账号被锁定的问题，具体的设置在/etc/pam.d/system-auth文件，例如，exadata上的： 清除某个用户的登陆失败次数，让改用户可以重新登陆的命令： pam_tally2 -r -u username 例如， 清除 oracle用户的失败登录次数：pam_tally2 -r … 继续阅读 →

发表在 FAQ, 日常运维 | 标签为 | 留下评论

Flashcache WriteBack的常用Metric和event

发表于 2013 年 6 月 30 日 由 Lunar

User guide上列出了全部的Metric，这里只说些一般比较关注的： FC_BY_USED – number of MB cached (total) FC_BY_DIRTY – number of dirty MB cached (data written only to FlashCache but not to disks) GD_BY_FC_DIRTY – number of dirty MB cached for the griddisk CD_BY_FC_DIRTY – number of dirty … 继续阅读 →

发表在 FAQ, POC和性能调整, 体系架构, 硬件配置 | 标签为 , , | 留下评论