Oracle24.7技术与技巧—数据库高可用(十一).pdf

下载 第四部分 数据库维护 第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 访问，那么应该预先实现某些备用操作（如备用数据库 /表）。 维护包括多种经常