发表于:2006.05.16 15:46
分类: Oracle collections
出处：http://rollingpig.itpub.net/post/81/94155
---------------------------------------------------------------
第 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： 获得系统最终用户、客户和操作人员对服务等级和操作需求的认可和官方批准。这包括就性能、可用性以及对系统失败的适当反应达成一致。