使用 ASM 调整 Linux 上的 Oracle Database 10g

Oracle Database 10g 中的自动存储管理特性将会特别吸引 Linux 系统管理员和 DBA 来管理不断增长的存储网络

我通常对于 Oracle 新版本的反应就象电影 The Jerk（怪人）中 Steve Martin 对新的电话号码簿的反应一样。我禁不住为 Oracle 例行发布的所有新技术感到兴奋。但是，对于 Oracle Database 10g 的发布，我的热情无论如何表达都不为过。面对这一 Oracle 版本发布中大量令人感兴趣的新特性，我们将只分析自动存储管理 (ASM) 一项，它使得 Linux 数据库的磁盘空间管理非常容易。

随着现在对数据库容量的爆炸性需求以及 SAN（存储域网络）和 NAS（网络附加存储）磁盘技术的激增，系统管理员和 DBA 必须管理成百上千个磁盘 — 有时仅用于一个数据库。因此计划、初始化、分配、管理和调整这么多磁盘的任务变得很困难。作出让步经常是必然的，而许多商户只是简单地将磁盘存储群看作黑盒子，从而转移数据库的复杂性。习惯用语“您不必知道”和“只需托付给硬件来处理”经常被当成理由。这种黑盒子式的方法经常会导致那些消耗大量时间进行诊断和修复的数据库 I/O 瓶颈问题。对于其 DBA 实际上仍然管理所有磁盘的少数商户而言，这项任务消耗了太多的宝贵时间。这两种情形通常都不能令人接受，因为二者都代表极端的做法。

Oracle Database 10g 新增的 ASM 特性通过提供一种有效而简单的中间层解决方案，直接满足这些现实情况。现在，不必花费过多的时间来管理磁盘的复杂性，也不必希望一切正常而转移数据库的复杂性，我们可以简单地通过 ASM 来管理其全部事务。我们现在只需将磁盘分配给 Oracle，提供通过模板声明的划分和镜像的首选项，让 ASM 来管理空间 — 从而不再需要那些用于管理大量磁盘空间的传统工具：逻辑卷管理器 (LVM)、文件系统以及管理二者所必需的大量命令。因此，现在可以为不断增长的数据库容量需求而更加方便快速地部署 Linux 数据库服务器 — 并且具有远远高于从前的 I/O 效率。

在本文中，我将检验在 Linux 上使用带有处理文件的 LVM 与使用 ASM 的具体差别。有关 ASM 更加通用的概述，建议阅读由 Lannes Morris-Murphy 撰写的 OTN 文章“自动存储”。

传统方法

在开始之前，让我们回顾从前 DBA 如何将磁盘空间分配给 Oracle。这样做有两个原因。第一个也是首要的原因是，我们想要确保清楚地看到 ASM 使过程变得更为简单。这种简单性产生了“更为简单的图象”效果，从而减少了安装步骤和管理命令。而第二个原因是，我们将提到一些案例，其中每个选项都可能有意义。这将有助于我们看到更新的技术及其所有选项如何适用于总体的数据库存储图。图 1 显示了传统的选项。

图 1 表明必须进行两项选择：原始设备或者经过处理的设备，以及带有 LVM 或不带有 LVM。这些图片可能更加复杂，因为标有 “disk” 的图片实际上可能是伪盘。例如，在 EMC 磁盘阵列中，磁盘被称为“主轴”，可以再细分为超级磁盘。而在 Linux 中，我们标为 “disk” 的部分仅仅是设备的参照 — 可能只是实际磁盘的一个分区。为便于分析讨论，我们假定磁盘不再细分：图表中的每个磁盘表示单独的物理磁盘驱动器。

回到我们开始时所面临的问题（具有非常多磁盘的不断增长的数据库），我们经常需要从图 1 中选择一个更易于扩展到数百或数千个磁盘的选项。对于这么多数量的磁盘，普遍的做法是使用 LVM。尽管在某些操作系统中，原始设备是一个很有吸引力的选择，我已发现在 Linux 上使用原始设备不是最好的方法。（有关全部细节，请参阅我以前撰写的文章“调整运行 Linux 的 Oracle8i Database。”）当然，还有与使用原始设备相关的附加管理难题。因此我们可以得出结论，带有 LVM 的经过处理的文件系统（最右边的示例）确实是我们最好的选择 — 因此也是我们用于与 Oracle Database 10g ASM 相比较的情形。

新的方法

现在让我们来更详细地分析自动存储管理。图 2 显示了 Oracle9i 的 Oracle Managed Files (OMF) 和 Oracle Database 10g ASM。象很多功能强大的 Oracle 特性一样，发布 ASM 时也有递增的步骤 — 即 Oracle9i 的 OMF，尽管我们当时并不知道它。

在很多方面，OMF 是在 Oracle Database 引擎中将自动文件管理进行内在化的第一步。但是，即便只是作为一项递增的服务，它也有某些实际的用途。对于那些转移数据库的磁盘复杂性（即我在上面介绍过的极端的黑盒子情形）的 DBA 而言，他们只需通过 DB_CREATE_FILE_DEST 参数为数据库提供单个文件目的地即可。该参数值只能表示基于文件系统的单个存储位置 — 尽管它可以是单个的伪盘（代表隐藏在硬件 RAID 后面的多个物理磁盘）或者是结合多个物理磁盘的单个逻辑卷。另一方面，Oracle9i Database 自动管理所有文件系统的文件。主要的缺陷（除了显然只有单个存储位置之外）是它不能与原始设备协同工作，仍然需要使用基于操作系统的本地文件系统。甚至 Oracle 手册也建议 OMF 仅限于以下情况：

• 由以下程序支持的数据库：
  • 支持划分/RAID 以及可动态扩展的逻辑卷的逻辑卷管理器
  • 提供大型可扩展文件的文件系统
• 低端或测试数据库 [在其自身内部进行声明]。

现在再看图 2 并集中观察 ASM（最右边的示例）。不需要 LVM 或文件系统；只有在 ASM 管理下的磁盘分组，可供表空间使用。虽然文件管理同 OMF 一样也是自动执行的，但现在它是百分之百的内部功能。没有通过 /etc/fstab 文件装配的文件系统，也没有使用操作系统文件命令（如 ls、cp 或 tar）来访问的文件。现在可查询数据库来了解所有这些信息。

此外，ASM 还可以在文件级划分或镜像您的数据 — 而不是使用其他方法在磁盘级进行。无论何时添加或删除磁盘分组中的磁盘或者磁盘发生故障时，Oracle 的自动管理功能都为您保持所有数据完全镜像或划分，并且全部在数据库完全联机的情况下进行。

Oracle 通过利用与许多 LVM 所使用的简单算术算法根本不同的新型高效方法来达到此目的。虽然您可能认为需要额外的 ASM Oracle 实例，但以下开发的 LVM 对比 ASM 的示例表明，该实例很小，非常易于安装，允许进行百分之百的高效实用并且自动的存储管理 — 并可以为您的所有数据库实例进行这种操作。因此将会表明 ASM 更易于创建和管理，并提供预期的所有性能。

更易于安装

ASM 很明显比其文件系统和 LVM 的对手更易于安装。假定我们需要创建一个简单的数据库 — 只有所需的表空间以及一个用户数据表空间。并假定硬件和软件限制如下：

• RAID 0 — 在所有驱动器中划分全部数据
  • 划分宽度 = 4
  • 划分长度 = 64 K
• 四个 20 GB 的 IDE 磁盘 — 每个磁盘只有单个分区
• Linux ext3 文件系统（文件大小限制为 2 GB）
• 五个表空间
  • SYSTEM，2GB，1 个数据文件
  • SYSAUX，2GB，1 个数据文件
  • UNDO，8GB，4 个数据文件
  • TEMP，8GB，4 个数据文件
  • USER，60GB，30 个数据文件
• 每个磁盘驱动器有一个物理卷 (PV)
• 一个卷分组 (VG) — VG01
• 四个逻辑卷 (LV)
  • LV01，4GB，SYSTEM 和 SYSAUX
  • LV02，8GB，UNDO
  • LV03，8GB，TEMP
  • LV04，60GB，USER

图 3 显示了每个环境的相对复杂性。要记住，这是一个只有四个磁盘驱动器的简单例子 — 现在想象一下对数千个驱动器进行这种操作。

现在让我们来比较在每个环境中创建数据库的实际步骤。请注意，在 LVM 示例中我故意避免处理与所有容量设置有关的多项开销问题，以便保持示例的简单性。但是应提出警告：为最佳地利用磁盘空间，您也必须处理此问题。它也是您通过使用 ASM 可以避免的复杂存储计划和管理问题的另一个示例。

下面是使用带有 LVM 的经过处理的文件的步骤。（注意，在示例中假定 IDE 磁盘驱动器为第二个到第五个驱动器，因此 b 到 e 的设备名标注为 /dev/hdb 到 /dev/hde）：

1. fdisk /dev/hdb set its type to 0x8e (LVM partition)
2. fdisk /dev/hdc set its type to 0x8e (LVM partition) )
3. fdisk /dev/hdd set its type to 0x8e (LVM partition) )
4. fdisk /dev/hde set its type to 0x8e (LVM partition) )
5. pvcreate /dev/hdb /dev/hdc /dev/hdd /dev/hde}
6. vgcreate VG01 /dev/hdb /dev/hdc /dev/hdd /dev/hde}
7. lvcreate -L 4 G -i 4 -I 64 -n LV01 VG01}
8. lvcreate -L 8 G -i 4 -I 64 -n LV02 VG01}
9. lvcreate -L 8 G -i 4 -I 64 -n LV03 VG01}
10. -L 60 G -i 4 -I 64 -n LV04 VG01}
11. mkfs -t ext3 /dev/VG01/LV01}
12. mkfs -t ext3 /dev/VG01/LV02}
13. mkfs -t ext3 /dev/VG01/LV03}
14. mkfs -t ext3 /dev/VG01/LV04}
15. mount /dev/VG01/LV01 /home/oracle/oradata/LVMDB/system}
16. mount /dev/VG01/LV02 /home/oracle/oradata/LVMDB/undo}
17. mount /dev/VG01/LV03 /home/oracle/oradata/LVMDB/temp}
18. mount /dev/VG01/LV04 /home/oracle/oradata/LVMDB/user1}
19. edit /etc/fstab and add the new mount point entries}
20. Create initLVMDB.ora file}
• INSTANCE_TYPE = RDBMS}
21. SQL Plus connect as SYSDBA for SID=LVMDB}
22. STARTUP NOMOUNT PFILE=initLVMDB.ora}
23. CREATE SPFILE FROM PFILE=initLVM.ora}
24. Create Oracle database and user tablespace using SQL code.[参见列表 1。]

现在只需想象您需要数十个这样的用户表空间，每个用户表空间有非常多的数据文件。不难看出这个示例不能进行良好扩展的原因。跟踪所有的表空间、数据文件、逻辑卷、物理卷以及实际的磁盘驱动器（以找到热点）确实太困难。

现在给出简单得多的 ASM 示例：

1. Create initASM.ora file
• INSTANCE_TYPE = OSM
2. SQL Plus connect as SYSDBA for SID=ASM
3. STARTUP NOMOUNT PFILE=initASM.ora
4. CREATE SPFILE FROM PFILE=initASM.ora
5. CREATE DISKGROUP dgroup1 EXTERNAL REDUNDANCY DISK
‘/dev/hdb’,’/dev/hdc’,’/dev/hdd’,’/dev/hde’
6. Create initASMDB.ora file
• INSTANCE_TYPE = RDBMS
• DB_CREATE_FILE_DEST = ‘+dgroup1’
7. SQL Plus connect as SYSDBA for SID=ASMDB
8. STARTUP NOMOUNT PFILE=initASMDB.ora
9. Create Oracle database and user tablespace using SQL [列表 2。]

而如果我们想要明确地控制数据分配的大小（实际上这不再是需要考虑的因素，因为我们现在是在磁盘级进行工作），这就是其语法。因此，我们实际上只需让 Oracle 处理所有的内部空间需要，并使用简单得多的语法：

create database ASMDB;

这一语法不仅更短，从而更易阅读，而且要注意到，我们甚至获得了在我们划分的磁盘分组中所创建的重做日志。（在前面的示例中，它们只是放置在文件系统中。）要点是布置存储以及创建数据库的过程被如此显著地简化，以至于如果您正在管理非常多的磁盘驱动器（即 SAN 或 NAS），您只为 ASM 升级到 Oracle Database 10g 都不会有问题。

更易于更改

当然您只创建数据库一次，因此您可能认为以上所示的节省情况不足以成为进行更改的原因。因此，现在让我们来分析一下，如果我们添加四个磁盘，每种情况中会发生什么。这是 ASM 真正出众的方面。

假定我们的单个 USER 表空间接近已满状态，它只包含 10 个表和 10 个索引，其中每个表占用 4GB 空间，每个索引占用 2GB 空间。如果我们现在需要创建另外的表和索引，则没有足够的空间。因此我们获得与前四个磁盘相同的另外四个磁盘，将其加入到存储设计中，以便满足增加的空间需求。换句话说，我们将向单个 USER 表空间中添加 80 GB。听起来非常容易，是吗？

在 LVM 示例中，我们有三个主要的选择方法：

• 利用新增逻辑卷 LV05 创建新的卷分组 VG02
• 利用新增逻辑卷 LV05 扩展现有的卷分组 VG01
• 通过扩展逻辑卷 LV04 来扩展现有的卷分组 VG01。

[注意：由于我们假定所有 80GB 都添加到 USER 表空间，所以不需要为前两个选项创建多于一个的新增逻辑卷。]

多数人将会选择第三种方法，因为我们只想为现有的存储设计添加空间。实现该选择方法的步骤如下所示。

1. fdisk /dev/hdf set its type to 0x8e (LVM partition)
2. fdisk /dev/hdg set its type to 0x8e (LVM partition)
3. fdisk /dev/hdh set its type to 0x8e (LVM partition)
4. fdisk /dev/hdi set its type to 0x8e (LVM partition)
5. pvcreate /dev/hdf /dev/hdg /dev/hdh /dev/hdi
6. vgextend VG01 /dev/hdf /dev/hdg /dev/hdh /dev/hdi
7. lvextend -L +80 G /dev/VG01/LV04
8. ext2online /dev/VG01/LV04
9. SQL Plus connect as SYSDBA for SID=LVMDB
10. 使用 SQL 代码将新增空间添加到表空间。（如列表 3 所示。）

此示例不仅非常长，而且也有几个问题。首先，联机文件系统的大小调整是非常棘手的问题。ext2online 实用程序的作者称，“调整已装配文件系统的大小本质上很危险，可能会破坏文件系统。”而且 ext2online 实用程序只能扩大已装配文件系统；要缩小或扩大文件系统，需要使用 ext2resize 来代替 — 而该程序只能在未装配的文件系统上使用。当然这样需要将表空间脱机。

LVM 方法也有一些瑕疵。我们非常希望这种解决方案能够在所有八个驱动器中划分数据 — 而这不可能。尽管我们可以向逻辑卷添加空间，但我们不能在 Linux 上更改其划分属性（虽然某些 UNIX LVM 确实提供这种功能）。.因此我们的 10 个旧表和 10 个旧索引在驱动器 b-e 上划分，而新表和新索引在驱动器 f-i 上划分（因为 USER 表空间已满，新的对象将在新的空间中创建）。即使我们导出表空间对象，将这些对象删除，将表空间合并，然后将它们导回到表空间中，逻辑卷仍然设置为四路划分。如果我们确实想要进行八路的划分，就不得不手动完成以下操作：

1. 导出该表空间中的对象（数据库处于限制会话中，以确保安全）
2. 删除表空间
3. 删除逻辑卷
4. 创建新的逻辑卷（将划分参数设为 -i 8）
5. 创建表空间（全部 140 GB 会有很多数据文件行）
6. 将对象导入到表空间中。

ASM 在此处介入并简化了过程。其步骤要少得多：

1. SQL Plus connect as SYSDBA for SID=ASM
2. ALTER DISKGROUP dgroup1 ADD DISK ‘/dev/hdf’,’/dev/hdg’,’/dev/hdh’,’/dev/hdi’

此外，无论何时添加、删除磁盘或磁盘出现故障时，ASM 都自动对其磁盘分组的划分和镜像进行重新平衡 — 而且全部在数据库完全联机情况下进行。因此 Oracle 自动考虑使您的所有对象保持完全划分。这就是为什么 ASM 可以宣称它提供接近最优化的 I/O 平衡而不需要任何手动调整。它只是简单地将多年来 DBA 手动完成的工作进行内在化和自动化 — 尝试通过将负荷分散到尽可能多的驱动器来消除热点问题。注意，可以通过 OSM_POWER_LIMIT 以及其他参数来控制 Oracle 何时和如何执行重新平衡（但这需要撰写专门的文章来说明）。

还有一些性能……

Oracle Database 10g 的 mantra 是更简单、更自动化的数据库管理。以上所有示例都表明，为什么对于很多商户来说只需 ASM 即可正确升级到 Database 10g。但是如果缺少对 LVM 对比 ASM 情形的相关性能进行分析的示例，本文就不会完整。虽然我们消除了 LVM 和文件系统，但是我们仍然利用更多的 Oracle 技术从本质上完成很多同样的事情。因此最初的期望是想看到基本相似或略微改进的性能 — 却再次获得了在创建和管理方面简单性显著提高的好处。

以下是一些值得考虑的相关结果：

使用 Oracle Database 10g Beta 1 进行测试

尽管这些结果并不是震撼性的，但是从一项特性获得大约百分之十的提高，可以使 DBA 的工作更容易，对于进行升级的成本而言，这是不错的投资回报。并且我持乐观态度，即当 Oracle Database 10g 作为成熟产品发布时，这些数值可能会提高。当然，也许我正如“怪人”一样，再次陷入极度的兴奋中。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9665688/viewspace-608042/，如需转载，请注明出处，否则将追究法律责任。