月归档：2014 年三月

密码保护：Exadata X2-2 满配的硬件配置(Full Rack，高容量)

发表于 2014 年 3 月 16 日 由 Lunar

无法提供摘要。这是一篇受保护的文章。

发表在 Exadata X2-2 | 标签为 , , | 要查看留言请输入您的密码。

Exadata读取数据和传统数据库环境中读取数据的方式有什么关键区别？

发表于 2014 年 3 月 15 日 由 Lunar

在Exadata上，数据库节点跟db节点是通过libcell11.a并缺省使用RDS协议来进行通信的，我们跟踪下看看： 这里我跟踪Exadata的DB节点的ora_dbw0_lunar1进程： 这里我们看到主要的IO操作都是recvmsg和sendmsg等等，我们看一下，在Linux环境下的11.2.0.3的libcell11.a中含有哪些目标文件（即 .o 文件，object file） 那么这里recvmsg和sendmsg函数来自libskgxp11.so，关于libskgxp11.so的由来这里不赘述了，大致的介绍请参见： 在Exadata上，为什么 DUL 和 ODU不能读取ASM数据库的数据，但是Kfed却可以？ 我们看到，oracle主要是通过这个libcell11.so函数来跟cell通信，并通过libskgxp11.so在本地调用socket： [root@dm01db01 lib]# nm -D /u01/app/11.2.0.3/grid/lib/libcell11.so|grep socket 那么在传统的Oracle数据库环境下，DBWR是怎么工作的的？ 这里我们通过一个AIX环境举例说明。 首先，我们跟踪一下ora_dbw0_test570和ora_dbw1_test570进程： 这里看到ora_dbw0_test570进程空闲，因此，再开辟一个会话，制造一些测试数据，比如，我这里创建了一个表： —session 2 跟踪一下ora_dbw1_test570进程： 我们发现，在AIX上的IO操作是通过传统的kread等完成的。 下面我再看看传统的linux环境下，这是一个ASM数据库，是Exadata的ADG，我们跟踪一下ora_dbw0_lunar进程： 我们发现，非Exadata的Linux环境上，IO操作是通过传统的read和pwrite等完成的。 最后，我们记录一下AIX环境下libcell11.a包含了哪些目标文件：

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

在Exadata上，为什么 DUL 和 ODU不能读取ASM数据库的数据，但是Kfed却可以？

发表于 2014 年 3 月 15 日 由 Lunar

普通的dul在exadata上是不能读取 cell 节点的数据的： 这里很清晰看到DUL报错了“OS error 2: No such file or dire”和“DUL: Error: “, 12″，由于篇幅关系，这里我就不贴前台DUL的报错界面了，这个trace已经很清晰了。 那么，我猜ODU也是同样的采用传统的read和write的方式读取数据的，跟踪一下，主要内容如下： 我们看到，ODU读取了配置文件：“write(1, “load asm disk file ‘asmdisk.txt’”…, 44) = 44” 然后根据配置文件中的信息直接读取磁盘内容。 很明显，这种情况下ODU还是直接根据文件路径读取信息，那么在Exadata上，自然是搜索不到的。 因为，Exadata上，数据是放在cell上的，db节点调用 libcell11.a 并通过 socket 的方式通信。 但是kfed可以读取cell的数据，具体方法参见 Exadata上验证ASM磁盘头备份的位置 我跟踪了一下kfed读取cell上数据块的过程，大致如下： kfed打开socket，并读取/etc/nsswitch.conf来进行域名解析： kfed 读取自己的fd（/proc/self/fd/），fd是linux系统上进程的文件描述符： kfed 读取 ADR … 继续阅读 →

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

安装Exadata时，如果checkip有报错怎么办？

发表于 2014 年 3 月 14 日 由 Lunar

在安装老版本 Exadata （Image 11.2.3.2.0以前）时，我们通常会使用一个叫做 的excel来完成环境配置，并生成和这个 onecommand 配套的配置文件。 大概在2013年1月份后，新的版本 Exadata （ Image 11.2.3.2.0以后 ）上，我们会使用一个基于java的onecommand工具，图形化的生成配置文件。 通常安装前，我们会跟客户有一个沟通，把Exadata上的各个网络配置等信息跟客户做一个充分沟通，然后根据客户的要求使用onecommand生成配置脚本，其中有一个checkip.zip 这个checkip.zip（使用里面的 checkip.sh ）我们会交给客户，用来检查现有环境。 有时候，运行checkip后，发现错误，不是说环境就一定不ready，需要看具体的情况而定： 例如：先插现有环境，发现有2个地方放报错了： 这里，我们发现了两个错误，但是这两个错误是不是致命错误，以至于不能安装呢？ 我们来检查一下 checkip.sh 的详细日志，分析下，到底什么问题： [root@dm01db01 onecommand]# cat dbm.out 从上面的分析，我们可以看到，主要是2个错误： 1，在onecommand中生成配置文件时填写了两个DNS，但是安装的时候，我们的环境当时只配置了一个DNS Server 2，在2个PDU上连接网线到Exadata内置的Cisco交换机 这些都是非致命的问题，解决方法： 1，重新生成配置文件，只填写一个DNS 2，给PDU加上连线，连接到Cisco 再或者，其实这2个错误，可以忽略，O(∩_∩)O哈哈~

发表在 日常运维 | 标签为 , | 一条评论

Exadata 环境下修改NTP Server的方法

发表于 2014 年 3 月 14 日 由 Lunar

如果NTP SERVER 的配置有问题，那么在使用 onecommand 进行安装时，会在最初的环境校验过程报错。 当然，从11.2.3.2.0开始，Exadata 上执行 onecommand 之前，必须先使用 checkip 脚本进行环境验证，如果该脚本返回关键错误，那么必须先根据提示解决问题，再继续安装。 例如，“Step 0 = ValidateEnv”就是执行环境校验： 这里我们看到NTP server在安装时都已经ok了: 在使用中，有时候客户有更改NTP SERVER的IP的需求。 如果没有在 Exadata 的db节点和cell节点上完成相应配置文件的修改，那么cell节点的alert中会类似如下报错： 此时，在cell节点上验证会报失败“FAILED”： 场景1：使用过程中，客户更改了NTP Server的解决方法 解决方法： 直接修改/opt/oracle.cellos/cell.conf，将10.9.26.230替换成 10.9.26.62 修改之后，再次使用“ /usr/local/bin/ipconf -verify -semantic ”来验证。 可以看到，已经验证通过了: 场景2：初始安装过程中，错误的填写了NTP Server的地址 解决办法: （1）重新生成配置文件： 按照新的NTP SERVER的IP，重新生成配置文件。 … 继续阅读 →

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

使用ILOM收集Exadata的硬件故障信息（snapshot）

发表于 2014 年 3 月 13 日 由 Lunar

    当遇到硬件故障时，我们通常会收集硬件故障的信息提交到SR或者硬件工程师，那么如何收集故障信息呢？ 在Exadata或者配置了ILOM模块的X86机器上，我们都可以使用两种方法收集信息。 方法一，使用Web界面登陆ILOM： 点击run后，会弹出一个窗口让你选择将收集的信息保存在那个目录，之后，点击保存按钮，然后就可以将这些日志发送到SR或者给硬件工程师确认。 这个过程也可以通过命令行完成。 方法2：使用命令行收集故障信息，大致步骤如下： 使用SSH登陆故障节点的ILOM（IP地址在配置文件中可以查找到）： 这里dump_uri的格式如下： 执行完这不后，看到“Snapshot Complete”提示就可以完成了. 生成的日志在该主机的（这里是 192.168.1.2 ）的“/tmp”目录下。

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

Exadata更换硬盘的操作过程和解释

发表于 2014 年 3 月 13 日 由 Lunar

在巡检时，发现cell的alert有如下告警： 我们注意到有这样的信息，就表示磁盘有损坏的情况，结合sundiag信息，可以发现磁盘确实损坏，需要更换。 另外，此时也可以通过直接看机柜，该磁盘为闪蓝色灯，表示进行拔出的操作了。 关键信息： SEAGATE Model Number : ST360057SSUN600G Serial Number : E0P387 Slot Number : 9 Cell Disk : CD_09_dm01cel02 换盘前，我们一般作比较细致的检查： 1.在db节点上grid用户登录，这是要确认一下asm disk是不是被drop掉。drop掉就可以直接更换，如果没有，就需要手动去drop了。 这里表示磁盘celldisk：CD_09_dm01cel02已经被ASM自动删除了，且当前没有正在运行的rebalance操作。 2. 在相应的存储节点（dm01cel02）上进行确认检查： 确认物理盘状态： 这里发现磁盘的报错信息跟alert是一致的： 磁盘的物理位置和编号如下： 我们这里是HDD9损坏。 此时从机柜边上观察，如果磁盘闪蓝灯则可以直接拔出，如果是闪橘色灯，那么需要手工关闭这个磁盘设备，然后再拔出： alter physicaldisk 20:9 serviceled off 更换完成后需要检查： 1，磁盘的LED指示灯变为绿色 2，确认新换盘的celldisk，griddisk状态是normal … 继续阅读 →

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

Exadata上的手工创建celldisk，griddisk（比如手工增加一个cell节点）

发表于 2014 年 3 月 12 日 由 Lunar

一个客户，因为现有的一台Exadata要从一个地方搬迁到另一个地方的机房，因此机器中所有部件的IP都需要修改（ILOM，SWITCH，DNS，NTP SERVER，VIP，SCAN，PDU等等）…… 这些都可以修改IP的方式完成，也并不复杂。 但是，考虑到机器上以前部署了很多应用（包括SAP的一些东西），本地空间凌乱且空闲不多。 因此，给客户的解决方案： 1，机器不用重刷，只更改相关IP 2，重装RAC(GI和Database) 3，安装Bundle Patch和SAP需要的patch 清理已经的RAC环境很简单，参考我以前写的一个《Linux下手工卸载11.2 RAC(非MOS的deinstall方法)》 类似这种方法，在11.2以前，是常用的，简单干净，O(∩_∩)O哈哈~ 顺便也提一下，《AIX环境下11.2 rac的快速卸载脚本》 下载环境并重新安装时，发现可用的找不到ASM盘，客户想起来清理环境的时候忘记先删除ASM磁盘了。 这里我们说下，ASM中，如果不指定asm_diskgroups和asm_diskstring（比如现在，我们重新安装），那么ASM在不同平台会按照缺省路径来扫描磁盘。 具体请参考：Default Disk Discovery Path by Platform (Doc ID 1389618.1) 缺省平台的扫描路径： Operating System Default Search String 那么Exadata呢，我猜它的缺省路径是o/cell_ip/* 。 例如，我这里是Exadata的VM，asm_diskgroups和asm_diskstring都为空，ASM启动没有问题，因为他按照缺省路径已经扫描到了需要的磁盘组和磁盘信息：   下面的图，更加清晰，所有盘都不在Candidate Disk中，也就是以前划分的cell上griddisk都不可用： 因为没有清理磁盘头，这些盘被ASMB进程扫描到了，也就是以前我们常说，11.2开始，重装RAC后，ASM和数据库都可以手工保留以前的状态，如果以前数据库和ASM是完好的，那么重装完成后，ASMB进程将信息注册到CSS中，数据库直接识别到ASM磁盘，因此，直接手工启动数据库就可以（如果要crs启动，那么必须使用crsctl命令将asm和db都注册到crs中）：  现在，我们需要手工的删除griddisk，celldisk等等，然后手工创建这些盘…… 我们都知道Exadata上使用onecommand来创建celldisk和griddisk的时候，是按照磁盘效率分布不同的数据的，比如数据库文件需要较高的访问效率，而用来存放归档和备份的磁盘组则需要不那么高的访问效率，这些是通过创建cell的时候指定offsize来实现的。 … 继续阅读 →

发表在 安装和升级, 日常运维 | 标签为 , , , , , | 留下评论

Exadata上本地盘的使用（reclaimdisks.sh）

发表于 2014 年 3 月 12 日 由 Lunar

Exadata出厂时，其计算节点本地有4块盘，两两做RAID 1，安装了双OS，一个是Linux，一个是Solaris X86（不是Sparc，O(∩_∩)O哈哈~） X2是每块本地盘300G，从X3开始，每块本地盘600G。 多出一个没用的OS，这样就浪费了很多空间，因此，安装或者重装后，一般都做Reclaim的操作，将出厂时的双OS改为单独的Linux系统启动，并释放空间。 例如这里： 这里显示当前4块本地盘，做了双启动系统，每两块盘做了RAID 1，没有Hot Spares盘 使用reclaimdisks.sh -free -reclaim可以更改为一个单独的系统，大部分客户会选择使用Linux，例如： reclaim的过程大概2小时左右，完成后的结果类似下面： 这里，我们看到，4块本地盘，一个做了Hot spare disk，其余3块做RAID5，只有一个Linux OS了。 这样就把以前Solaris X86 OS 的空间释放出来了，但是这部分空间缺省并没有自动mount上，你需要手工的mount上，或者自己使用LVM扩充到根目录（/）或者非根目录（比如/u01等等），或者扩到Swap区。 例如： 这里我们看到做完reclaim后，释放出来400G左右的空间，这个是X2，每块本地盘300G。 如果是X3，每块本地盘600G，做完reclaim后释放出来600G左右的空间，就类似下面的样子： 现在你就可以使用lvm lvexten等命令，将这些空间扩到你需要的放了，O(∩_∩)O哈哈~。

发表在 安装和升级, 日常运维 | 标签为 , | 留下评论

看图说话——Exadata和Exalogic（或者Exadata）级联-2

发表于 2014 年 3 月 11 日 由 Lunar

上一篇，我们梳理了Exadata内部连接和2个Exadata的连接 看图说话——Exadata的网络架构 看图说话——Exadata和Exalogic（或者Exadata）级联-1 事实上，Exalogic和Exadata的 物理连线和两个Exadata之间的物理连线没有太大区别，只是对外出口，如果是Exalogic和Exadata的话，通常客户会买万兆模块，这个万兆模块从Exalogic上连接到客户的核心工作网络，提供应用接口。 当然，如果客户数据量很大，对备份有较高要求，那么也可以购买万兆模块安装在Exadata上，用于连接到客户的备份服务网络中（一般用在每个db节点的net3上）。 下面的图是一个1/4 Exalogic和1/4 Exadata的连接： 1/4 Rack没有Spine switch，因此，从这个图，我们看到，每个Leaf switch都需要连接到其他的Leaf switch上。小学2今年的奥数中貌似有类似的题目，O(∩_∩)O哈哈~ 计算下，总共几根线？ 答：  每个Leaf switch需要连接两外3个Leaf switch，那么不考虑冗余的话，加上单机柜中本身两个Leaf switch的连线，总共是6跟。也就是说，客户最少需要额外购买的4根Infiniband线（客户可以从oracle购买，也可以自己找符合要求的厂商定做），当然，如果考虑冗余的话，需要至少8跟。 下面看下1/4 Exalogic跟1/2 Exadata或者Full Rack连接的情况： 我们看到，实际上，除了Exadata上本身两个Leaf连接自身的Spine switch外，没有多余的概念，也就是仍然是客户需要额外购买至少4跟Infiniband，考虑冗余的话，需要至少8根。 就这么简单的算法，学过奥数的同学们或者家里有宝宝学习奥数的，下次有这样需求，直接出一道题给孩纸们，他们会很快算出来的，O(∩_∩)O哈哈~ 从上我们讲的Exalogic连接Exadata，我们知道他们走了Infiniband的高速互联网络，那么这个网络在软件层面如何搭建呢？ 如何配置他们的SDP连接？ 下次，我们讲这个，O(∩_∩)O哈哈~

发表在 体系架构 | 标签为 , , , , | 留下评论