本文是定义、设计和提供成功 Oracle RAC 项目的指南。它详细介绍了减少风险和增加成功实施机会的详细步骤。此外，它还突出了您在实施 Oracle RAC 项目过程中可能会犯的错误，并提供了避免这些错误的建议。
尽管这篇文章侧重于 Oracle RAC，但下列步骤对许多种 Oracle 实施项目均试用。（注意，本指南仅用于提供信息，无论在何种情形下，您都不可将其视为咨询服务。）
下面我们开始吧！
确定需求
成功实施 Oracle RAC 的第一个重要阶段是确定项目的真实目标。“确定 需求”一步涉及识别和记录项目实施阶段要提供的特性和功能。
在实施 Oracle RAC 过程中，您还要经常核对这些需求。将需求记录成文将有助于实施 Oracle RAC 项目。否则，您将发现该项目难以管理，这是因为在项目实施过程中会不断出现意料不到的新问题。
避免错误的方法 1： 确保关键业务和技术人员积极地参加项目需求的确定。明确地将所有需求传达给项目负责人，包括关键的管理人员、技术人员以及最终用户。
第 1 步 — 确定项目范围
“确定需求”阶段的第一步就是确定项目范围。项目范围是用于论证项目业务需求的一系列细项，它说明了项目的可交付成果。项目范围有时也称为“业务需求”。
要确定项目范围，请回答下列问题：
项目的业务目标是什么？
项目要完成什么工作？
项目成功会带来哪些重要好处？
以下是一个详细说明一个 Oracle RAC 示例的高级目标的项目范围文档。
理由 | 我们实施 Oracle RAC 是为了使我们的应用程序可伸缩和高度可用，以及为我们的客户提供更可靠的服务。 |
目标/可交付产品 | 该项目的最终产品将是一个新的 Oracle RAC 系统，它支持在我们的服务等级要求文档中详细规定的服务等级*。*见下面的附件 |
项目日程限制 | 该项目必须在 2006 8 月 前完成。 |
项目成本限制 | 项目成本应不超过 $XXX,XXX。 |
避免错误的方法 2： 努力使项目目标量化。您将能重新核对这些目标，掌握整个项目的完成情况。量化目标的工作包括记录项目日程和成本限制。
第 2 步 – 确定项目团队
确定项目团队就要确定为项目制定交付目标的人和愿意完成项目方案中的任务的人。这些人可能来自组织的多个部门，如决策人员、业务分析人员和技术人员。
下表是典型 Oracle RAC 项目的人员组成，并列明了他们的职能和完成项目所采取的步骤。
角色 | 职责 | 参与阶段 | Oracle RAC–具体任务 |
决策人 | 发起项目 提供资金 | 确定范围 确定服务等级需求 | |
IT 经理 | 提供 IT 资源 提供人力资源 向决策人报告进度 | 确定范围 确定团队 确定服务等级需求 | |
项目经理 | 协调项目 管理项目 为项目成员分派任务 向经理报告进度 | 所有阶段 | |
数据库管理员 | 安装和升级数据库软件 创建、更新、管理和监视数据库 优化数据库性能 备份和恢复数据库 创建数据库的物理设计和逻辑设计 | 确定服务等级需求 确定日程 技术架构设计和构建 | 安装 Oracle 软件 配置 Oracle Clusterware 规划和配置共享存储 配置自动存储管理 (ASM) 创建数据库和实例 创建和配置服务 配置负载管理 监视和调整性能 配置和测试备份 执行备份和恢复 |
网络管理员 | 配置网络组件 管理网络 | 确定系统需求 确定日程 技术架构设计和构建 测试 | 分配服务器 IP 地址 配置网络组件 配置专用互连 配置虚拟 IP |
系统管理员 | 管理应用程序和数据库服务器硬件和软件 监视系统性能 对系统设计和系统资源使用提供建议 提供管理支持 配置硬件和软件组件 | 确定系统需求 确定日程 技术架构设计和构建 测试 | 配置服务器硬件 安装和配置操作系统软件 配置网络组件 规划和配置共享存储 安装 Oracle 软件 规划和维护备份 |
应用程序开发人员 | 设计、开发和维护数据库应用程序 设计、开发和维护软件组件和脚本 | 确定系统需求 确定日程 技术架构设计和构建 测试 | 执行应用程序配置 创建 Oracle Clusterware 应用程序配置 提供单元/集成测试支持 |
测试人员 | 设计测试方案 执行测试 确定满足需求 | 确定日程 测试 | 执行单元测试 执行用户认可测试 执行集成测试 执行压力测试 |
应用程序用户 | 使用数据库应用程序 执行测试 确定满足需求 | 确定系统需求 测试 | 执行用户认可测试 |
Oracle RAC 项目团队成员的职责会因地制宜，这取决于场地的大小和系统需求。
在组建该项目团队的时候，可能无法找到最合适的人员，因此，您只能找到可用 的人员。在这种情况下，对项目团队成员进行适当的技术培训可以降低实施风险。技术培训通常可以降低项目风险和较高质量地完成项目。
避免错误的方法 3： 如果新的 Oracle RAC 系统要取代已有的旧系统，需要让对旧系统经验丰富的人也参与。吸纳这些团队成员将有助于确保满足所有项目需求。
第 3 步 – 确定服务等级需求
“需求确定”阶段的第三步是确定服务等级需求。服务等级需求是指期望 Oracle RAC 项目实施支持的服务等级。这些需求包含预期的服务等级和操作需求，并提供处理延期和失败的指导原则。
服务等级需求可以分为两类：服务等级需求和操作需求。
服务等级需求帮助 Oracle RAC 技术实施与项目的范围（项目的业务目标）保持一致。确定服务等级需求应先从分析现有系统的需求开始。分析包括查看现有系统的操作、技术以及支持的程序和文档。
可以通过回答诸如以下问题进一步确定服务等级需求
哪几个小时对业务至关重要，需要 Oracle RAC 系统联机？
该系统需要哪些服务等级？
最低能忍受那种级别的性能和可用性？
处理延期和失败的程序都有哪些？
这些问题的回答通常可组成一个分级、分层的服务等级需求表，该表定义了不同的服务等级。
下面是一个服务等级表示例。具体的服务等级和层数取决于您的组织数和业务部门数。
层 | 安全等级描述 | 性能 | 可用性 | 所需解决方法 |
5 | 正常操作 | 系统响应正常。 | 系统 100% 可用。所有中断均正确排定。 | 无 |
4 | 安全等级 4： 问题微不足道，影响很小或无影响 | 性能比所要求的基准低 10%-30%。 | 应用程序应用程序功能的 90%-95% 可用。 | 必须在五天内解决 |
3 | 安全等级 3： 问题很小，几乎没有影响 | 性能比所要求的基准低 30%-50%。 | 应用程序应用程序功能的 85%-90% 可用。 | 必须在三天内解决 |
2 | 安全等级 2： 问题需要关注，可感受到有影响 | 性能比所要求的基准低 50%-70%。 | 应用程序应用程序功能的 80%-85% 可用。 | 必须在一天内解决 |
1 | 安全等级 1： 问题很严重，对业务有严重影响 | 性能比所要求的基准低 70% 或更低。 | 应用程序应用程序功能的 75% 以下可用。 | 必须在三小时内解决 |
操作需求规定了维护 Oracle RAC 系统和满足以上定义的服务等级需求所需的程序。通常，操作需求包括排定的维护中断、系统启动和关闭、系统备份、Oracle RAC 系统可用性、故障切换程序以及灾难恢复计划的信息。
可以通过回答诸如以下问题确定操作需求
如何维持 Oracle RAC 系统性能基准？
维护操作应进行的时间？
哪些维护和备份操作应“联机”执行？
关闭和启动系统需要哪些程序？
要保证系统最大的可恢复性应执行那种备份？
如何准备应对灾难？
以下是一个 Oracle RAC 操作需求列表示例。
排定的维护中断 | 留出每个月的最后一个周末来进行 Oracle RAC 系统维护操作。中断时间不会超过 56 小时（从星期五晚上开始）。这些中断专门留给那些无法“联机”执行的维护操作。 |
系统备份 | 完整备份将在周末联机执行，而在一周其他天的晚上则执行累积备份。磁带上保存着相当于四周的备份，而磁盘上则保存相当于一天的备份。 |
故障切换程序 | 所有应用程序会话在发生单节点故障时都应可切换到可用的 Oracle RAC 节点上。在发生一个局部灾难，使所有 Oracle RAC 节点都不可用时，该处的备用环境应在三个小时内联机。 |
灾难恢复程序 | 当灾难遍及整个场所时，场所外的备用环境将在三个小时内联机。 |
系统容量 | 系统应支持当前的用户负载（以及两年内的用户数量预期增长）以及当前的应用程序。在系统无法满足用户负载要求时，就需要增加 Oracle RAC 节点。处理器、内存和存储需求将基于从运行在现有硬件上的当前应用程序的性能来确定。 |
避免错误的方法 4： 获得系统最终用户、客户和操作人员对服务等级和操作需求的认可和官方批准。这包括就性能、可用性以及对系统失败的适当反应达成一致。
