避免错误的方法 3: 如果新的 Oracle RAC 系统要取代已有的旧系统,需要让对旧系统经验丰富的人也参与。吸纳这些团队成员将有助于确保满足所有项目需求。
第 3 步 – 确定服务等级需求
“需求确定”阶段的第三步是确定服务等级需求。服务等级需求是指期望 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 系统维护操作。中断时间不会超过 56 小时(从星期五晚上开始)。这些中断专门留给那些无法“联机”执行的维护操作。 |
|
系统备份 |
完整备份将在周末联机执行,而在一周其他天的晚上则执行累积备份。磁带上保存着相当于四周的备份,而磁盘上则保存相当于一天的备份。 |
|
故障切换程序 |
所有应用程序会话在发生单节点故障时都应可切换到可用的 Oracle RAC 节点上。在发生一个局部灾难,使所有 Oracle RAC 节点都不可用时,该处的备用环境应在三个小时内联机。 |
|
灾难恢复程序 |
当灾难遍及整个场所时,场所外的备用环境将在三个小时内联机。 |
|
系统容量 |
系统应支持当前的用户负载(以及两年内的用户数量预期增长)以及当前的应用程序。在系统无法满足用户负载要求时,就需要增加 Oracle RAC 节点。处理器、内存和存储需求将基于从运行在现有硬件上的当前应用程序的性能来确定。 |
避免错误的方法 4: 获得系统最终用户、客户和操作人员对服务等级和操作需求的认可和官方批准。这包括就性能、可用性以及对系统失败的适当反应达成一致。
第 4 步 – 确定项目日程
“确定需求”阶段的最后一步就是确定项目日程。由于需要确保有足够的时间建立 Oracle RAC 解决方案来满足以上定义的所有需求,因此日程安排对项目成败至关重要。
日程安排涉及构建系统、为每个任务分配时间、以最优的顺序排列任务等所有任务的细节。
避免错误的方法 5: 在安排项目日程的过程中,应努力使每个项目成员清楚所有时间限制(见“第 1 步”)。征询每个团队成员的意见,准确评估和规划项目日程。
有时,可以在项目日程中同时执行多个任务。巧妙地并行安排任务通常会按时完成项目并节省项目成本。
以下是一个高级 Oracle RAC 日程示例。它展示了在 Oracle RAC 部署中经常执行的任务。
|
任务名称 |
存在期间 |
开始时间 |
结束时间 |
前置任务 | |
|
1 |
服务器硬件配置 |
2 天 |
2005 年 12 月 1 日星期四 |
2005 年 12 月 2 日星期五 |
|
|
2 |
共享存储配置 |
1 天 |
2005 年 12 月 1 日星期四 |
2005 年 12 月 1 日星期四 |
|
|
3 |
OS 安装 |
1 天 |
2005 年 12 月 5 日星期一 |
2005 年 12 月 5 日星期一 |
1 |
|
4 |
网络配置 |
1 天 |
2005 年 12 月 6 日星期二 |
2005 年 12 月 6 日星期二 |
3 |
|
5 |
Oracle 数据库软件安装 |
1 天 |
2005 年 12 月 7 日星期三 |
2005 年 12 月 7 日星期三 |
4 |
|
6 |
数据库构建 |
2 天 |
2005 年 12 月 8 日星期四 |
2005 年 12 月 9 日星期五 |
5 |
|
7 |
数据加载 |
5 天 |
2005 年 12 月 12 日星期一 |
2005 年 12 月 16 日星期五 |
6 |
|
8 |
单元测试 |
2 天 |
2005 年 12 月 19 日星期一 |
2005 年 12 月 20 日星期二 |
7 |
|
9 |
压力/集成测试 |
5 天 |
2005 年 12 月 21 日星期三 |
2005 年 12 月 29 日星期四 |
8 |
|
10 |
故障切换测试 |
2 天 |
2005 年 12 月 30 日星期五 |
2005 年 1 月 3 日星期二 |
9 |
|
11 |
备份与恢复测试 |
19 天 |
2006 年 12 月 12 日星期三 |
2005 年 1 月 4 日星期三 |
5 |
|
12 |
系统集成 |
5 天 |
2006 年 1 月 5 日星期四 |
2006 年 1 月 11 日星期三 |
11 |
|
… |
… |
一个相对详细的项目日程可以使 Oracle RAC 团队跟踪项目的进度,主动对日程迟延做出回应。当需要更改日程时,一定要确保完全记录了所有更改。最初的项目日程和该更改报告为以后项目日程的制定提供了重要的参考。

