标签归档：grid

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

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