分类目录归档：内部机制

kcfis的相关隐含参数

发表于 2014 年 3 月 20 日 由 Lunar

记录一下kcfis的相关隐含参数：

发表在 Exadata, 内部机制 | 留下评论

Exadata上cell如何判断何时进行智能扫描？————2.在非Exadata环境的测试

发表于 2014 年 3 月 20 日 由 Lunar

创建测试表： 使用gdb跟踪： ———— 回到 session 2 —————- (gdb) c Continuing. 继续跟踪 ———— 回到 session 1 —————- 执行： LUNAR@lunar>select count(1) from lunar; ……. ———— 回到 session 2 继续跟踪 —————- ———— 回到 session 1 —————- 回到session 1，此时已经返回了结果： LUNAR@lunar>select count(1) from lunar; COUNT(1) … 继续阅读 →

发表在 内部机制 | 留下评论

Exadata上cell如何判断何时进行智能扫描？————1.在Exadata环境的测试

发表于 2014 年 3 月 20 日 由 Lunar

我们知道，SmartScan的先决条件是下面3个： 1，必须是对象上的全表扫描或者全索引快速扫描（TABLE ACCESS FULL或INDEX FAST FULL SCAN） 2，必须使用直接路径读取（Direct Path Read）。SmartScan的数据流是无法缓存在SGA缓冲池中的。直接路径读取可以串行，也可以并行，缓冲在进程的PGA(heap)中。 3，对象必须存储在Exadata的Cell节点上 . 在Exadata环境的数据库节点上： 1，ASM实例使用libcell11.a这个动态库跟cell节点通信, 2，数据库实例使用kcfis（ Kernel File Intelligent Storage ）执行SmartScan。 3，Diskmon进行心跳监控，I/O fencing和IORM 。 . 而cell节点上，主要是cellsrv（多线程的服务）完成相关的IO请求的操作（MS主要是监控，RS是重启其他进程） . 并且，对于Linux环境，Exadata和非Exadata上面安装的Oracle介质并无却别，那么有两个问题： 1，这两个环境是上执行计划为什么会不同（一个是全表扫描，一个是智能扫描）？ 2，cell在收到数据库节点的请求后，怎么判断是否执行只能扫描呢？ . 首先，在Exadata上大体有下面3种读取数据块的方式： 1，普通的block读：从磁盘读取数据块，读入到SGA 2，直接路径读：从磁盘读取数据块，读入PGA 3，智能扫描：由cell直接从底盘读取，读入PGA . 而在非Exadata环境，通常只有前两种。 我们分别用gdb跟踪一下。 首先在我的Exadata VM上测试： 创建测试表： … 继续阅读 →

发表在 内部机制 | 留下评论

Exadata上的常用工具介绍（Troubleshooting Tools）

发表于 2014 年 3 月 18 日 由 Lunar

Utility Path Usage/Comments Infiniband Some of these tools may be found in /opt/oracle.SupportTools/ibdiagtools on cells or database servers. Also see the  Infiniband Triage wiki page. /opt/oracle.SupportTools/ibdiagtools/infinicheck /opt/oracle.SupportTools/ibdiagtools/verify-topology ibqueryerrors /usr/bin/ibdiagnet Detecting fabric issues /usr/sbin/ibaddr Examining HCA state & guids /usr/sbin/ibcheckerrors Detecting fabric issues … 继续阅读 →

发表在 FAQ, 内部机制, 故障诊断, 日常运维 | 标签为 , , | 留下评论

Exadata的数据保护机制（冗余机制）-4-ASM PST

发表于 2014 年 3 月 17 日 由 Lunar

Exadata的数据保护机制（冗余机制）- 1 Exadata的数据保护机制（冗余机制）- 2 Exadata的数据保护机制（冗余机制）- 3- Failure Group 为了补充前面两篇的一些概念，这里，我们简单介绍下ASM的PST。 我们知道，asmfile extent是分布在多个磁盘之间，称为partner，Partner disk会存放在一个或者多个分离的failure group上。ASM自动选择Disk partner并限制其数量，这是受隐含参数”_asm_partner_target_disk_part”控制的。在10g中，每盘都会存在最多10个Disk partner，而在11gR2中每盘都会存在最多8个Disk partner。ASM会自动创建和维护Partner关系，如果磁盘损坏（failure），那么ASM会更新其extent map使今后的读取操作指向剩余的健康的partner。 对于external redundancy 的磁盘组，每个磁盘组只有一个PST table，对于normal redundancy 的磁盘组，每个磁盘组有3个PST table，对于high redundancy 的磁盘组，每个磁盘组有5个PST table。 . PST的信息是由GMON进程维护的。PST 包含了一个磁盘组中ASM disk的状态信息：disk number，status（online or offline），partner disk number，heartbeat的信息，11g的ASM中，PST 还引包含了failure group的信息。因此，ASM根据PST(Partner Status Table)的信息就知道哪个盘的partner是offline状态的。 … 继续阅读 →

发表在 ASM, 体系架构, 内部机制 | 标签为 , , | 留下评论

Exadata的数据保护机制（冗余机制）- 3-Failure Group

发表于 2014 年 3 月 17 日 由 Lunar

Exadata的数据保护机制（冗余机制）- 1 Exadata的数据保护机制（冗余机制）- 2 为了补充前面两篇的一些概念，这里，我们简单介绍下ASM的Failgroup。 ASM提供了3种冗余方法。 EXTERNAL，即ASM本身不做镜像，而依赖于底层存储阵列资深实现镜像；在External下任何的写错误都会导致Disk Group被强制dismount。在此模式下所有的ASM DISK必须都完好，否则Disk Group将无法MOUNT。 . NORMAL， 即ASM将为每一个asmfile extent创建一个额外的拷贝以便实现冗余；默认情况下所有的asmfile都会被镜像，这样每一个asmfile extent都有2份拷贝。若写错误发生在2个Disk上且这2个Disk是partners时将导致disk Disk Group被强制dismount。若发生失败的磁盘不是partners则不会引起数据丢失和不可用。 . HIGH， 即ASM为每一个asmfile extent创建两个额外的拷贝以便实现更高的冗余。2个互为partners的Disk的失败不会引起数据丢失，当然，不能有更多的partners Disk失败了。 数据镜像依赖于failure group和extent partnering实现。 . ASM在NORMAL 或 HIGH 冗余度下可以容许丢失一个failure group中所有的磁盘。 . 下面我来详细说下，Oracle如何通过failure group来提供数据的高可用性。 首先，ASM使用的镜像算法并不是镜像整个disk，而是作extent级的镜像。ASM会自动优化文件分布以降低设备故障造成数据丢失的可能性。 在normal redundancy模式下，ASM的按照extent进行striping时是在一个DiskGroup中完成的（即，在一个DG的2个Fail group之间完成的，而不是一个单独的FG中完成），ASM环境中每分配一个extent都会有一个primary copy和一个secondary copy，ASM的算法保证了secondary … 继续阅读 →

发表在 ASM, 体系架构, 内部机制 | 标签为 , , | 留下评论

Exadata的数据保护机制（冗余机制）- 2

发表于 2014 年 3 月 16 日 由 Lunar

在上一篇中，我们讲了存储节点上的盘的划分，请参考Exadata的数据保护机制（冗余机制）- 1 那么这次我们来说说，在Exadata上有ASM哪些不同于传统架构（非Exadata环境）的特点，他是怎么保护数据的。 首先我们来回顾一下ASM的相关知识点 我们知道，就像数据库文件从逻辑上分为很多extents一样（每个segment由多个extents组成），ASM的文件（ASM FILE）也分为很多extent(ASM FILE EXTENTS)。也就是说，数据库中datafile包含的逻辑存储单元是segment，extent等等，而ASM上ASMFILE的逻辑存储单元是asmfile extent。 数据库文件的物理单元是block，而ASM文件的物理单元是AU。 因此，我们知道了，每个ASM file包含很多extent，ASM FILE和extent之间对应关系就是 EXTENT MAP（每个asmfile上extents的分布） 每个物理磁盘包含很多AU，磁盘和AU之间的对应关系就在ALLOCATION TABLE中（每个磁盘上AU的分布）。 ASM的镜像是基于文件extent的粒度，extent分布在多个磁盘之间，称为partner。Partner disk会存放在一个或者多个分离的failure group上。 在ASM中，每个文件都按照AU的尺寸打散到磁盘组中所有的磁盘上，我们把这种条带划叫做粗糙条带划（COARSE striping），粗糙条带划是根据AU的尺寸的（即，缺省为1M，Exadata上通常为4M）。对于控制文件的条带划，是采用128k的Striping的，称之为“Fine striping”。 AU的缺省尺寸是1M，ASM的block缺省大小是4k，这其实是受隐含参数控制的： _asm_blksize 4096 metadata block size _asm_ausize 1048576 allocation unit size 在Exadata上缺省的AU为4M（推荐值），ASM block为4k。 查询各种文件条带划的信息（下面是在我的Exadata VM上测试的输出）： SQL> select … 继续阅读 →

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

Exadata的数据保护机制（冗余机制）- 1

发表于 2014 年 3 月 16 日 由 Lunar

在Exadata中，对数据库的保护（数据的冗余机制）是通过ASM实现的（不是通过RAID那种外部冗余来实现的）： Exadata中通常我们建立磁盘组的时候会采用 Normal Redundancy。 当然，初始配置或者安装时，你可以通过onecommand进行配置，至少采用 Normal Redundancy ，可选的是High Redundancy （无论是Image 11.2.3.2.x以前那种excel表格形式的，还是2013年年初后来时推出的Java模式的onecommand） 采用Normal保护方式，任何一份数据会同时分布到两个不同的Failure Group中，任何两个不同的Failure Group一定不来自同一个Storage Cell。 如果需要增加数据保护，可以增加Failure Group数量实现数据更多重的保护 请注意，voting disk会分布在3个cell上（这也是为什么Exadata 1/4 Rack和 1/8 Rack必须至少3个cell的原因）： 当然，你可以修改voting disk到其他磁盘组： Exadata的Storage Cell内部虽然配置的RAID卡，但是实际上数据的保护并不是通过每个Storage Cell内部的RAID卡实现保护的。 对于Storage Cell，所有的DISK是以原始的状态提供给位于DB server层的ASM作为ASM Disk使用 Exadata的每个存储节点有12块物理磁盘。 每个物理磁盘都映射为逻辑单元LUN，每个存储节点的前两个磁盘中都包含一个系统区域。 这两个磁盘上的系统区域是彼此镜像的副本，他们是使用软件镜像维护的。系统区域在每个磁盘上大约占用29GB的空间。 系统区域包括OS映像、交换空间、Exadata Image的二进制文件、度量和警报系统信息库以及各种其它配置和元数据文件。 前两块盘上除了每盘前面29G用于存储本地系统文件（使用LVM管理），其余部分都作为数据盘使用，和存储节点上从第3块盘开始到第12块盘一样，是纯数据。 参加下图： 存储节点的前两块盘类似下面： … 继续阅读 →

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

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 … 继续阅读 →

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