- 0
- 0
- 约7.12万字
- 约 42页
- 2018-02-05 发布于浙江
- 举报
下载
第四部分 数据库维护
第11章 一 般 维 护
数据库的维护工作在整个数据库的使用过程中都要进行。由于O r a c l e 的RDBMS 非常严谨,
所以它在相当长的使用周期中都不会崩溃。但是,这一严谨性要求诸多组成部分之间相互协
作。这样,就需要时常维护此数据库系统,使其不仅能够正常运转而且要保证可接受的响应
时间和吞吐率,而且要对额外的负载保证其可扩展性。如果考虑到数据库的功能需要有多个
组成部分来实现,以及不断增长的数据处理需求,就可以理解数据库维护工作的必要性。这
些维护工作包括:补丁 / 版本升级、初始化参数的改变、分段、索引重构、计算段统计信息、
错误检测及修正,以及在管理权限下的其他各种维护任务,这些都是必须的。许多维护任务,
特别是在O r a c l e 8 i 以前的版本中,需要停止数据库的工作。在 2 4 ×7 环境中,在不影响服务级
协议的情况下进行数据库维护是一件非常复杂的工作,需要仔细计划和不同管理人员的协同
工作。
注意,在进行某些维护任务时,不可避免地要求停止数据库的工作。例如,当使用一个
补丁或修改表/ 索引的错误时,或者当为了消除碎片而对一个段进行重组时,就不允许访问这
些段,甚至不允许访问整个数据库,以免产生不一致。第 1 5章讨论一些可以用来避免因维护
需要而停止数据库工作的策略。这些策略 (例如客户备用数据库或备用表 ) ,允许数据库及其中
的某些表在维护过程中仍可以访问。
本章将讨论以下技巧与技术:
• 在所有可能级上实现健壮的安全性
• 理解“O R A - 1 5 5 5 :Snapshot too old ”错误并采取措施避免
• 理解、防止和解决锁和队列的竞争
• 熟悉不同的等待事件并采取步骤予以减少
• 周期性地检测并解决锁冲突
• 监视共享池效率并在需要时进行调节
11.1 主动维护和按需维护
如前几章所述,维护可以是主动维护和按需维护。按需维护一般是针对当时出现的问题,
尽快采取正确措施,通常是立刻进行。相反,主动维护包括预见到一些一般或非一般问题并
采取措施防止其发生。在任何情况下,为保证及时发现出现的问题并作出相应处理,必须进
行经常性的监测。通常情况下,按需维护可能需要立即停工以防止将来不得不进行更长时间
的停工维护。而主动维护也可能需要停工,因为没有急待处理的问题,可以在非数据库访问
高峰期再来进行需要停工才能进行的维护工作。而且,对于主动维护有了一定的熟悉之后,
可以尽量避免按需维护,防止在数据库访问的高峰期进行长时间的停工维护。然而,事实上,
324 第四部分 数据库维护
下载
需要结合主动和按需两种维护方式以提供端到端的数据库维护。在任何情况下,应该通知用
户其数据库需要哪些维护操作。准确估计这些操作的频率,估计需要停工的时间,并考虑各
种可选的维护方法以尽量减少对可用性的影响。
谈到主动维护,要想到一个虽然小但很重要的规则:如果它不崩溃,就不维护它。这意
味着不要对运行良好的系统进行所谓的主动维护。因为如果试图去维护时,有可能引起构件
崩溃。当确定了需要进行主动维护的区域后,要找到特定的可测量的帮助策略,诸如对于
S L A 中的可用性和性能的级别。那些可能存在问题的区域可以留下来以后维护。对那些目前
可能威胁可用性和性能的区域要引起重视。这些区域中的大多数易于识别(基于已有的经验)。
然而,可能存在一些对环境有特殊影响的组成部分。要保证可以用建模技术识别这些组成部
分(来自Prentice Hall 的容量设计和性能模型方法是很好的建模方法),这样可以调节当前的
负载与容量,而且也允许预见当前的容量是否适应将来的可能负载。如果当前的容量不适合,
应该对那些构件预先进行扩容。
维护工作可以按一个时间表来进行,也可以不按时间表来进行。通常,主动维护是按时
间表来进行的,而按需维护常在紧急的情况下发生,一般是不按时间表来进行的。显然,第
二种情况是可能发生的崩溃。基于时间表的维护仍产生崩溃是难以接受的。然而,一旦产生
停工,应该进行调度以便在数据库使用率小的情况下进行维护,以减小影响。如果强制使用
2 4 ×7 访问,那么应该预先实现某些备用操作(如备用数据库 /表)。
维护包括多种经常
原创力文档

文档评论(0)