月归档：2014 年三月

HOW TO GENERATE SYSTEMSTATE ON THE CELLSRV TO IDENTIFY MEMORY LEAKS

发表于 2014 年 3 月 19 日 由 Lunar

1. Executing command kill -12 on the cellsrv pid. Identify the pid of cellsrv process -> ps -ef |grep ‘cellsrv 100’ kill -12 Example: 2. On the storage cell, obtain the statedump by running command from cellcli: 3. Provide to … 继续阅读 →

发表在 FAQ, 故障诊断 | 留下评论

在Exadata上修改操作系统用户口令的方法

发表于 2014 年 3 月 19 日 由 Lunar

注意修改完了要用这个用户登录一次才可以：

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

Exadata上一次POC的记录——PDML

发表于 2014 年 3 月 18 日 由 Lunar

下面的一次POC中的某2个语句的执行，可以看到除了CTAS创建的表名称不同，其余都是一样： 同样的都是Exadata x3-2，同样的环境（表结构，数据等等），但是执行效率却大相径庭： 从执行计划上看，SQL1执行时间了44秒： 1，在select阶段，所有Slave进程以直接路径读的方式并行的从cell上读取数据 2，所有Slave进程并行的将读取的数据发送给Query Coordinator，然后仍然以直接路径读取的方式并行的写入到数据文件 3，Query Coordinator进程从并行数据流中接收数据，并在所有并行写入结束后，将执行结果（Table created）反馈给SQL1 从执行计划上看，SQL1执行时间了9.3分钟： 1，在select阶段，所有Slave进程以直接路径读的方式并行的从cell上读取数据 2，所有Slave进程并行的将读取的数据发送给Query Coordinator 3，Query Coordinator进程等待所有Slave进程都执行结束后，将接收到的数据以直接路径度的方式写入到数据文件，将执行结果（Table created）反馈给SQL2 这个2个SQL的区别就在于PDML需要单独enable，缺省的只有SELECT会采用parallel。 也就是说，在执行SQL1之前，我执行了： alter session force parallel query; alter session force parallel dml; alter session force parallel ddl; . 而在执行SQL2的会话中，我没有enable PDML。 .

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

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上的IOPS和MBPS

发表于 2014 年 3 月 18 日 由 Lunar

关于IOPS和MPBS的概念网上可以有很多详细的解释和介绍。 . IOPS (Input/OutputPer Second),，即每秒读写（I/O）操作的次数总和，多用于OLTP/数据库或者小IO/小文件等场合，衡量系统的随机访问的性能。 . 我们知道，磁盘完成一个I/O请求所花费时间就磁盘本身的因素来说，跟寻道时间、转数和数据传输都有关系。 也就是说， IOPS（每秒IO次数） = 1s/(寻道时间+旋转延迟+数据传输时间) . 而实际应用中IOPS还受到很多其他因素的影响，比如存储配置和不同操作系统上的相关配置等等（读写比例，顺序和随机，工作线程数，队列深度……），因此对比测量磁盘IOPS时应该在相同的测试基准下进行。 . 与之对应的是 MBPS ，另一个重要指标是数据吞吐量(Throughput)，指单位时间内可以成功传输的数据数量。对于大量顺序读写的应用，如VOD(Video On Demand)，则更关注吞吐量指标。 传统磁盘也就是我们常说的机械盘，如SAS, SATA磁盘等等，在Exadata的存储节点上每个cell配置了12块SAS盘或者SATA盘： Exadata V1 存储节点上磁盘的选择： 300 GB串行连接SCSI (SAS) 磁盘 或者 1TB串行连接(SATA) 磁盘（3.5寸） Exadata V2 存储节点上磁盘的选择： 600 GB串行连接SCSI (SAS) 磁盘 或者 2TB串行连接(SATA) … 继续阅读 →

发表在 FAQ, POC和性能调整 | 标签为 , , | 留下评论

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 服务器创建共享文件系统（DBFS）

发表于 2014 年 3 月 17 日 由 Lunar

DBFS是Oracle 11.2的新特性，他提供了在Linux操作系统中将Oracle的ASM数据库映射成文件系统来使用的功能。操作上的文件在DBFS内部是以SecureFiles LOBs（SecureFiles LOB是11.1的新特性，对比与以前的BasicFiles LOBs，Oracle称SecureFiles LOBs为全新设计的LOBs）的形式存储在数据表中。由于篇幅关系，这里不详细描述SecureFiles LOBs了。 其配置过程非常简单，具体参见MOS: Configuring a Database for DBFS on Oracle Database Machine [ID 1191144.1] List of Critical Patches Required For Oracle 11.2 DBFS and DBFS Client [ID 1150157.1] 在Exadata上数据库节点的本地磁盘空间是有限的，因此，在做数据加载时，我们需要想办法使用更大的空间来存放数据（以便后续加载到exadata上的数据库中），通常，DBFS是一个很好的选择。 如果经常使用的话，写一个shell自己动完成所有过程，测试过，也就是几分钟，O(∩_∩)O哈哈~。 下面详细讲解一下配置的过程： 配置DBFS 文件系统 为Exadata 服务器创建共享文件系统（DBFS） … 继续阅读 →

发表在 FAQ, 安装和升级, 日常运维 | 2 条评论

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块盘一样，是纯数据。 参加下图： 存储节点的前两块盘类似下面： … 继续阅读 →

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