rale9i数据库管理实务讲座2.docVIP

Oracle9i数据库管理实务讲座(二)Oracle9i Enterprise Edition 数据库系统概论 (原文刊登于2001年12月Linuxer杂志) ：何致億，美商甲骨文公司台湾分公司特约顾问 Oracle9i数椐库除了延续Oracle 8i强大的功能之外，还加入许多革命性的数据处理技术，其 目的仵成为M呩咧络应用以及电子商务的最佳数据库平台。究竟我们应该如何来评估一个数 据库系统的优劣呢？ 一般来说，以下几点是重要的参考依据： ■ 数据库 HT用性(Availability) ■ 数据库延展性(Scalability) ■ 效能表现(Performance) ■ 程序开发环境 ■ 管理的难易度 而Oracle%对于以上各项，均提供了绝佳的解决方案: Orade9i数据库之高可用性与稳定性 不管是在任何环境下，Oracle9i都可担任执行关键性任务(mission-critical)之数据库系统。在 维持数据库的髙可用性与稳定性方面，OnKle9i期望达成三个目标： 提供零资料遗失之环境 针对已毁损之数据库，提供快速且精准之修复技术 尽量减少数据库离线处理的需求 唯有完全符合以上三点之需求，才足以称得上具备髙度可运转性与稳定性之数裾库系统！所 以Oracle提山数项特殊技术，使得Oracle9i在可运转性方面的表现傲视群雄，稳居电子商 务应用数据库之领导地位： 利用强化后的备援数据库(Standby database)与Flashback Query机制，提供零资料损失之 环境 Oracle9i数据保护方面新增了多项功能，特别是备援数据库的许多运作步骤都可以自动化， 例如初始化备援数据库、主从数据库之间的切换，以及错误移转...等。简单的说，主数据库 内的所有资料将完整地保留在备援数据库，一但主数据库发生问题，系统将会立即切换至备 援数据库，所有资料交易不致停摆，资料的一致性与完整性也不会受到影响。 不过有一点要注意的是：虽然主数据库可搭配备援数据库协同运作，将资料遗失或毁损的情 况降到最低，但是身为一个数据库管理者，您绝对无法预防勹避免人为性错误!举例来说, 业务专员可能不小心删除一笔重要的客户资料；或是程序设计师误删了产品价格文件。诸如 此类的人为性错误不胜枚举！也许有些读者心里会想”数据库不是都会做备份吗？既然资料 不小心被删除了，再还原回来不就好了？” 没错，这样的想法完全正确！但是您可能不了解一般大型数据庠的备份与还原(Backup Recovery)机制(有机会的话我也会为各位详细介绍Oracle9i数据库的备份机制)。事实上，在 进行数据库的修复或是复原动作吋，或多或少都会影响到系统的正常运作，这需视您处理的 资料量多寡以及采用的备份方式而定。 换句话说，还原数据库也需要耗费”时间”！我所指的时间不仅是DBA花在重建数椐库的时 间，也包含”数据库因为受影响而停摆的吋间”！试想，如果贵公司的数据库因为人为性错误 频率过高，导致系统的平均可运转性偏低，这样子的数据库严格来说也不能称力好数据库。 (哇！那要是以这个标准来看，岂不是没有一家数据库是可以用的！？请注意，我所探讨的 是因为人为因素所产生的问题，跟数据库是哪个厂牌并没有直接关系) 为了将上述M题发生的情况降到最低，Oracle9i新增了一项回溯查询(Flashback query)的功 能。经过适当组态之后，如果使用者不小心删除了重要数据，即使删除指令已经被commit, 也可以藉由回溯査询回存特定时间点的资料。 强大的数据库修复能力 以数据库的修复功能而言，芄实Oracle 8i就己经做的相当不错了。但是OraCle9i提供更精 确的资料复原能力。举例来说，如果某一个table所在的磁盘区块发生毁损，OraCle9i全新 的磁盘修S功能可以只针对毁损的区块进行修S，同一个资料表的其它资料K块则依旧处于 online状态，不会影响其它使用者的存取！ 利用快速的资料回写机制，缩短数据库离线时间 万一 Oracle9i数据库服务器不幸发生当机情况吋，新的资料修复算法(two-pass recovery algorithm)可以寻找岀资料文件内哪些区块是需要进行读写修复的，有效地缩短数据库重新上 线的时间。此外，Oracle9i也提供一些特殊的参数，例如：FAST_START_MTTR_TARGET可 用来限制数据库平均恢复时间(即当机之后多少时间之内必须恢i上线状态) Oracle9i的高延展性 在数据库系统的延展性力‘jif，Oracle9i Real Application Clusters可搭配适当组态的丛集架构 (Clusters),提供企业应用程序高度的延展性与可用性。藉由简单易用的单一系统管理方式， Oracle9i Real