Edd*_*wad 17 oracle best-practices
RAID（廉价磁盘冗余阵列）具有不同的配置（RAID-0、RAID-1...）。在安装 Oracle 数据库时，我应该设置和使用的推荐 RAID 配置是什么。该数据库将主要用作数据仓库。
Bri*_*ton 14
这取决于。在查看数据仓库时，如果您没有特定的设计，自动存储管理可能是一个很好的途径。
请考虑AskTom、OTN 论坛、OTN 论坛 2和OTN 论坛 3 上的讨论。
没有一种正确的方法来处理事情，答案会根据大量硬件和网络因素而变化。为了自己发现，请在基于 ASM 的机器、具有由 linux 虚拟化的 Raid 的 SAN 和基于硬件的 raid 机器上预加载示例数据仓库（只有一两个演出，足以玩）。
通过对所有三种环境中的查询结果进行计时，您将能够发现哪种方法最适合您的性能。我已经使用 ASN 和基于 linux 的虚拟突袭部署了数据库，虚拟突袭的表现稍好（几年前）。但是，我怀疑这部分是驱动器设置的方式。
没有唯一的正确答案。如果您可以向我们提供有关大小和性能要求的更多详细信息，则可以探索各种测试用例。
- 编辑 -
每个“磁盘组”可能由适当子系统上的一个或多个磁盘、目录或文件组成。Oracle建议“为了获得最佳性能和可靠性，请在多个物理设备上选择一个 RAID 设备或逻辑卷，并实施条带和镜像一切 (SAME) 方法”。在文件系统上放置文件时。这读起来好像 oracle 推荐 RAID 1+0。
ASM 管理的磁盘组，但是，“如果您使用双向镜像，则普通冗余磁盘组至少需要两个故障组（或两个磁盘设备）。普通冗余磁盘组中的有效磁盘空间是其所有设备中的磁盘空间”显然会自动提供镜像。
这些设备本身可以由 RAID 设备等组成。在我设置 RAID 数据仓库时的实际测试中，文件系统上的简单虚拟 RAID 5 提供了可接受的性能，而额外的 ASM 没有增加性能优势。在这种优化任务中，首先确定您的资源，然后测试每个可能的配置，因为有时结果可能非常违反直觉。
Dav*_*ett 11
如果您有两个物理驱动器：
RAID0：快速但无冗余。任何驱动器错误都会杀死整个阵列。有些人将临时存储放在 RAID0（即 MSSQL 下的 tempdb）上，但我仍然认为这很危险，因为如果阵列倒塌，您将不会丢失任何有意义的数据，您将有服务器中断，直到它被修复。
RAID1：如果您有两个驱动器，请选择此方法。尽管您可能会看到使用良好的控制器会提高读取性能，但没有写入性能优势。RAID1 的关键特性是使其中一个驱动器死亡。
如果您有三个物理驱动器：
如果支持，您的选择是 RAID5，即非标准的 3 驱动器 RAID10（或 IBM 控制器所指的 RAID1E）。您当然可以使用 RAID1 并保留额外的驱动器作为备用驱动器，以备其他驱动器之一发生故障时使用，但无论如何您都应该在关键任务环境中保留备用驱动器，因此这是不言而喻的。
RAID5 提供比 RAID10 更大的空间（两个驱动器而不是一个半），但存在潜在的写入性能问题，因为对于写入的每个块，控制器需要读取奇偶校验块、更新它并将其写回。对于数据库写入，这种写入性能问题可能会加倍，因为每次更新至少有两次写入：一次写入事务日志，另一次写入实际数据区域。由于现在空间便宜，如果支持以获得更好的写入性能，我会推荐 3 驱动器 RAID10。Linux 的软件 RAID 提供了这一点，许多 IBM 控制器也是如此（他们称之为 RAID1E）。您也可能会以其他名称找到它，因为它不被视为标准排列，因此没有标准名称。
R5 和 R10-over-3 都提供相同的冗余（任何一个驱动器可能一次发生故障，该阵列将继续存在）和类似的读取性能指标（类似于双驱动器 RAID0 阵列）。
如果您有四个物理驱动器：
如果只创建一个阵列，则有两个选项（忽略“带热备件”的变体）：RAID6 和“传统”RAID10（RAID1 的 RAID0）。
两者都提供相同的空间（四个驱动器中有两个驱动器）。RAID6 提供了更好的冗余，因为任何两个驱动器都可能同时发生故障，而 RAID10 只能在六种可能的两块驱动器消失情况中的四种情况下幸存下来。两者都提供类似的读取性能，但 RAID6 具有类似于 RAID5 的写入性能问题（在好的控制器上也是如此，尽管它在坏控制器上可能比 RAID5 慢，或者根据操作系统和 I/O 控制功能使用软件 RAID。RAID10 是出于性能原因，通常首选用于数据库 - 如果您需要额外的冗余，您可以使用六个驱动器并拥有一个 RAID0 或 2 个 3 驱动器 RAID1。
一旦您拥有四个或更多驱动器，事情就会变得更有趣，因为您可以拥有一对单独的 RAID1 阵列。通过将数据存储在一个阵列上并将事务日志保存在另一个阵列上，这可以通过旋转磁盘提供显着的性能优势 - 在某些情况下，这可以显着减少磁头移动，并且由于“随机”访问而导致的寻道时间是一个真正的性能杀手。对于数据仓库，假设这意味着相对而言它会看到很少的写入，从数据文件中分离事务日志可能带来的好处更有限，但您可能仍然需要考虑多个数组，而是将数据分区到它们上以获得更好的读取性能.
如果您有四个以上的驱动器：
您的选择在这里变得非常开放，这实际上取决于您的数据是什么以及您预期的更新/读取负载/模式是什么。例如，我们的一项服务在 12 ~70Gb 驱动器上运行：
Tempdb 保存在系统阵列上。我们可以将它移动到其他两个阵列，然后将系统阵列作为 RAID1 中的 2 个驱动器运行，因为系统块不需要额外的速度（因为这仅在启动或交换时才真正重要，我们确保有足够的 RAM 使其永远不需要交换），但是通过我们为那组机器向托管服务提供商支付费用的方式，丢弃这两个驱动器的成本不会降低。在将备份复制到服务器外、异地和离线备份位置之前，备份也会进入系统阵列。
当然，这对于某些数据库来说是严重的矫枉过正（以这种方式运行小型博客服务器是没有意义的！）但是我们的主应用程序在这种安排下表现非常好。
如果您有六个驱动器，您可能会考虑三个 RAID1 阵列或两个三驱动器 RAID10 阵列。
一般来说
不幸的是，没有真正简单的“最佳实践”，因为它在很大程度上取决于系统的大小和使用模式。我能想到的唯一一般规则是：
硬件或软件 RAID？
过去，由于奇偶校验计算以及由于驱动器和 CPU 之间的缓慢接口导致的所有安排，软件 RAID 的性能低于 RAID 5 的硬件 RAID。对于现代 CPU，奇偶校验问题并不是真正的问题，但是如果您的驱动器速度非常快，如果驱动器的总速度可以达到任何位置，则硬件 RAID 仍然可以胜出接近（在一个数量级内，猜测）机器与磁盘控制器通信的速度。如果您有一个带有软件 RAID 的四驱动器 RAID1 阵列（即相同数据的四个副本以实现大量冗余），则每次写入操作都会导致操作系统向 I/O 控制器发送四批数据，可能是按顺序 - 使用硬件控制器操作系统只发送一个写入请求，控制器将其发送到四个驱动器，可能是并行的。
良好的硬件 RAID 还可以提供其他优势：例如，一些高规格控制器具有带备用电池的写入缓存，因此即使您的 UPS 出现故障，挂起的写入也不会在断电时丢失。
软件 RAID 显然更便宜，更便携，因此如果由于控制器/机器故障而不得不移动阵列，则您不会被绑定到特定的控制器。
廉价的硬件 RAID 通常结合了软件和硬件 RAID 的缺点，但两者都没有（或没有）优点，因此最好避免。
我倾向于在我们的开发、测试和 UAT 服务器上使用软件 RAID，而在运行实时面向客户/面向公众的服务的服务器上使用良好的硬件 RAID。
在某些情况下，JBOD 是正确的答案（即，不是RAID）。
问题是，如果 RAID 组过多，则无法灵活地指定物理存储在数据库中的布局方式，例如确保表的索引和记录存储在不同的轴上，并确保您在所有磁盘之间平衡写入。
您可以使用条带化 (RAID0) 来平衡写入，但如果它们都是一个大组，则无法将索引与记录分开。
镜像 (RAID1) 是容错的，读取速度更快（因为您可以从不忙的主轴读取），但写入速度可能较慢，因为您必须等待两个副本都已写入。
我永远不会在数据库上使用 RAID5 或 RAID6。如果数据很重要，请购买更多磁盘并使用RAID1；RAID5/6 速度很慢（尤其是在软件方面），而且在为大型磁盘组更换故障磁盘后，以今天的硬盘驱动器大小可能需要数天才能重建......更不用说大多数 RAID5/6 系统处理奇偶校验错误的方式是只是重新计算奇偶校验......但很可能是数据中的错误，而不是奇偶校验，但你不知道错误在哪里。（不幸的是，我认为数据库没有像 LOCKSS 这样的东西）
...
我在数据库上看到的最有趣的布局实际上涉及每个主轴有两个分区——磁盘的最里面部分用于生产数据库，磁盘的其他部分用于备份。（他们确保一个分区没有备份到同一个主轴；我认为有多个数据库，所以每个数据库都从不同的磁盘备份）。这为他们提供了在工作日将内容分散到更多轴上的优势，然后在晚上运行备份。
我猜如果出现问题并且您需要恢复，那么恢复速度会变慢，因为在一天中数据库都在使用时，您会从外部磁盘读取一些数据，但在所有事情中总是要权衡取舍。
...
所以，无论如何，我想说明的一点是——没有一个答案适合所有情况。如果有的话，DBA 就会失业，公司会购买预先构建的数据库设备。
我处理的数据库是我老板所说的“WORN”：一次写入，永不读取；他在开玩笑，但“数据仓库”可以指任何级别的活动......我见过一些每晚/每周从磁带加载的（并且只是 OLTP 实例的副本，并帮助我们验证磁带是否良好）和对它们运行大量分析作业，以及其他输入源和偶尔读取的源源不断的分析作业，但没有真正的资源竞争。