ORACLE 24X7 技术与技巧---数据库高可用性实现方案 (2008 年度畅销榜NO.14268 )

本书主要介绍在Oracle数据库服务器系统中实现高可用性的技术途径以及系统性能优化方法，从而为用户提供具有24×7 正常工作时间特点的系统。全书共八个部分，分别从系统需求、软硬件环境、数据库安装与维护、数据库疑难解决、高可用性解决方案、实用工具、Oracle 新特性等方面进行阐述。\r\n\r\n 本书讨论的是Oracle数据库系统管理与开发中的高级技巧，许多设计实例都来自作者的实际工作，因此具有很高的适用性。其特点是很少论及关于数据库的深奥理论，而注重于技术的实际应用。\r\n\r\n 本书的读者对象主要是公司的技术人员，包括DBA、数据库开发人员；但其内容对于各层次的读者，特别是那些从事数据库应用程序开发的人员同样具有深远的指导意义。\r\n\r\n

贺辞\r\n序\r\n译者序\r\n引言\r\n前言\r\n第一部分 简 介\r\n第1章 确定自己的正常工作时间需求\r\n1.1 理解24×7对于公司的重大作用\r\n1.1.1 分析是否需要24×7正常工作时间的系统可用性\r\n1.1.2 理解"数据库"中的各个组件\r\n1.1.3 分析数据库系统中容易出错的部分以及出错时所产生的症状 \r\n1.2 实现一个"理想的"24×7系统\r\n1.2.1 24×7数据库系统的共同目标\r\n1.2.2 利用服务级协议管理系统需求\r\n1.2.3 只有90％的系统可用性就意味着节省90％的系统开销 \r\n1.2.4 理解系统维护动作对于可用性的影响\r\n1.3 半专业技术管理员与主管人技巧\r\n1.3.1 24×7方式需要对操作管理实施的基本方法\r\n1.3.2 在关键数据库访问时间创建"24×7小组"\r\n1.3.3 维护一个在数据库系统出现问题时需要告知的扩展人员列表 \r\n1.3.4 尽量在数据库系统停工之前预先通知客户或者终端用户 \r\n1.4 小结\r\n第2章 理解与处理紧急事件\r\n2.1 什么是紧急事件\r\n2.1.1 分类与罗列公司特定数据库环境下的所有可能紧急事件 \r\n2.1.2 如何应付紧急事件\r\n2.2 小结\r\n第二部分 理解系统环境\r\n第3章 硬件配置\r\n3.1 硬件配置简介\r\n3.1.1 真正熟悉系统的构成组件\r\n3.1.2 慎重选择磁盘阵列大小\r\n3.1.3 不要在OLTP应用程序中使用预读Cache\r\n3.1.4 不要依赖于写Cache来清除I/O热点\r\n3.1.5 使用多级RAID\r\n3.1.6 确保分条大小与操作系统和数据库的数据块大小一致 \r\n3.1.7 确保硬盘与磁带的I/O数据块大小相匹配\r\n3.2 采用体系结构技术实现系统冗余和系统性能\r\n3.2.1 分析哪些组件是"可热插拔"的\r\n3.2.2 考虑实现基于簇的解决方案\r\n3.2.3 除非是大规模的实现问题，否则避免使用MPP计算机 \r\n3.2.4 考虑使用NUMA计算机代替MPP计算机\r\n3.2.5 向硬件提供商租借替代计算机\r\n3.3 小结\r\n第4章 操作系统\r\n4.1 UNIX上的Oracle与Windows NT上的Oracle\r\n4.2 内核与块大小\r\n4.2.1 定制内核\r\n4.2.2 了解操作系统的逻辑块大小与物理块大小\r\n4.3 raw设备\r\n4.3.1 熟悉raw设备及其作用\r\n4.3.2 预先创建充足的raw划分\r\n4.3.3 为raw划分选择多个标准大小\r\n4.3.4 如果使用的是raw设备，应该将联机重作日志直接放置在这些设备上 \r\n4.3.5 不要使用硬盘的0柱面来创建raw划分\r\n4.3.6 为所有的raw设备创建符号链接\r\n4.3.7 了解其他文件系统选项\r\n4.4 系统功能与瓶颈\r\n4.4.1 预先确保任何时候都不会达到系统能力极限\r\n4.4.2 将所有资源密集型应用程序分配到多个服务器上\r\n4.4.3 建立非数据库服务器对CPU与内存的使用限制\r\n4.4.4 不要为与Oracle相关的进程设置优先级\r\n4.4.5 不要在数据库服务器上使用处理器仿射\r\n4.4.6 在产品高峰期不要执行非产品作业\r\n4.4.7 避免使用与Oracle进程竞争的资源密集型命令\r\n4.4.8 经常检查内存泄漏\r\n4.4.9 将交换区空间设置为物理内存的2~4倍大小\r\n4.4.10 在最快的硬盘上分布交换区空间\r\n4.4.11 判断操作系统是否能够对2GB之外的RAM进行寻址\r\n4.4.12 如果可能，对物理内存中的共享内存区域加锁\r\n4.4.13 理解逻辑驱动器与物理驱动器映射\r\n4.4.14 在所有的产品中打开文件系统日志功能\r\n4.4.15 周期性地检查空闲硬盘空间的可用性\r\n4.4.16 保持文件系统与目录的简洁\r\n4.4.17 维护一个后备根文件系统\r\n4.4.18 尽可能启用大文件支持\r\n4.4.19 周期性地查看重要的操作系统日志\r\n4.4.20 利用自动化工具来监视系统瓶颈\r\n4.5 小结\r\n第5章 网络\r\n5.1 管理网络\r\n5.1.1 确保网络没有过载\r\n5.1.2 频繁地ping关键主机\r\n5.1.3 购买网络电缆分析器\r\n5.1.4 不要在NFS的mount分区上创建Oracle数据文件\r\n5.1.5 不要用数据库服务器作为NFS服务器\r\n5.1.6 将网络配置为能够有效地使用子网\r\n5.2 为网络配置定制SQL*Net与Net8\r\n5.2.1 增加网络队列大小\r\n5.2.2 关闭NAGEL算法\r\n5.2.3 使SQL*Net/Net8报文大小与协议MTU能够最佳匹配\r\n5.2.4 在整个公司里使用相同的服务器系列\r\n5.3 半技术性管理员与公司主管技巧\r\n5.4 小结\r\n第6章 应用程序与数据\r\n6.1 应用程序\r\n6.1.1 熟悉应用程序\r\n6.1.2 应用程序分类\r\n6.1.3 代码优化\r\n6.1.4 使应用程序独立于未来的计划改变\r\n6.1.5 利用事务分割的方法来复制数据\r\n6.1.6 对所有的会话关键型应用程序使用Pro*C或OCI\r\n6.1.7 在所有会话关键型应用程序中实现失败恢复能力 \r\n6.1.8 熟悉各种自动失败恢复选项\r\n6.1.9 将所有可变应用程序段的MAXEXTENTS设置为无穷大\r\n6.1.10 加速数据加载过程\r\n6.1.11 对应用程序源代码进行版本控制\r\n6.1.12 有效地管理索引\r\n6.1.13 在应用程序中不使用进程而使用线程\r\n6.1.14 在应用程序中使用共享库\r\n6.1.15 仔细进行物理数据库设计\r\n6.1.16 与快速应用程序相关的技巧\r\n6.2 数据\r\n6.2.1 理解计划模型\r\n6.2.2 数据分类\r\n6.3 小结\r\n第三部分 数据库安装和配置\r\n第7章 安装、配置和定制数据库环境\r\n7.1 服务器配置\r\n7.1.1 遵守OFA标准\r\n7.1.2 经常使用config.ora文件\r\n7.1.3 使用crdb_SID.sql和crdb2_SID.sql创建脚本\r\n7.1.4 确保有足够的磁盘空间以维持至少两周的跟踪文件和警告日志 \r\n7.1.5 设置数据库块大小时要考虑OS块大小和应用特点\r\n7.1.6 确保将每次写的连续块数目设置大一些\r\n7.1.7 对于Oracle7.X下的大量数据文件，允许CKPT\r\n7.1.8 使用LOG_CHECKPOINT_TIMEOUT和/或LOG_CHECKPOINT_INTERVAL来确保实例修复时间满足SLA中指定的标准 \r\n7.1.9 对于活动量很大的数据库创建多于3个的镜像联机重作日志组 \r\n7.1.10 适当放置重作日志使ARCH和LGWR相互之间不发生竞争 \r\n7.1.11 配置足够多的重作锁存器使竞争最小化\r\n7.1.12 确保DBWR能够与数据库负载保持一致\r\n7.1.13 根据段使用模式将缓冲区缓存划分为多个缓冲池 \r\n7.1.14 在数据库活动多时使用从属进程减轻I/O瓶颈\r\n7.1.15 允许向量通知\r\n7.1.16 建立专门的临时表空间\r\n7.1.17 有效地建立排序区域\r\n7.1.18 对于排序使用直接写操作\r\n7.1.19 使用配置文件以避免失去控制的进程消耗系统资源 \r\n7.1.20 对于Cooked文件系统使用向量化读操作\r\n7.1.21 使用Cooked文件系统时允许直接I/O\r\n7.1.22 对于大量并行用户访问的情况使用ISM\r\n7.1.23 对于大IPC吞吐量使用通知：等待驱动程序\r\n7.1.24 在主存中预分页并且"加锁"SGA\r\n7.1.25 只要可能，就对当前的数据库版本设置COMPATIBLE\r\n7.1.26 安装SQL*Plus帮助\r\n7.2 其他一些自解释的服务器配置技巧\r\n7.3 SQL*Net/Net8配置\r\n7.3.1 处理大量客户时使用Oracle Name\r\n7.3.2 对SQL*Net/Net8 使用out-of-band break或者当out-of-band break不可用时将轮询频率设得高一些 \r\n7.3.3 保持死连接检测为最小\r\n7.3.4 通过SQL*Net和Net8有效地管理大量用户\r\n7.3.5 预先生成专门的服务器进程\r\n7.4 小结\r\n第8章 数据库升级、降级、重组和移植\r\n8.1 升级\r\n8.2 降级\r\n8.3 重组\r\n8.4 移植\r\n8.5 何时应该升级\r\n8.5.1 在测试环境下练习移植\r\n8.5.2 分析每一步并且构造加速移植的策略\r\n8.5.3 从Oracle7升级到Oracle8/8i时要注意一些事情\r\n8.5.4 提高装入/卸载性能的快速技巧\r\n8.6 现实生活中的移植个案研究\r\n8.7 小结\r\n第9章 备份、恢复、存档策略和规程\r\n9.1 备份\r\n9.1.1 经过适当的分析后，选择至少两种备份方法\r\n9.1.2 在低DML 活动期间执行热备份\r\n9.1.3 不要同时将所有表空间置于热备份模式\r\n9.1.4 尽可能先备份到磁盘，再备份到磁带\r\n9.1.5 不要在操作系统热备份时对联机重作日志进行备份 \r\n9.1.6 考虑使用三重镜像\r\n9.1.7 确保热备份命令被同步执行\r\n9.1.8 定期检查备份日志文件\r\n9.1.9 避免手工执行备份\r\n9.1.10 确保在使用备份工具时不会影响系统的安全\r\n9.1.11 使用RMAN时，定期对恢复目录进行重同步\r\n9.1.12 确保备份策略适用于所有的Oracle文件类型\r\n9.1.13 数据库发生变化之后立即备份控制文件\r\n9.1.14 开始执行导出之前考虑好与导出相关的各个方面 \r\n9.1.15 为段间一致性形成导出组\r\n9.1.16 为导出转储预备足够的空间\r\n9.1.17 执行导出时使用直接路径而不是传统路径\r\n9.1.18 确保所有备份导出转储的兼容性和可用性\r\n9.1.19 系统时钟发生变化后立即备份\r\n9.1.20 备份中和备份后检查数据库错误\r\n9.1.21 备份时设置优化的I/O尺寸\r\n9.1.22 使用Oracle8中增加的备份\r\n9.2 存档\r\n9.2.1 考虑特定环境是否需要ARCHIVELOG模式\r\n9.2.2 以自动存档作为主要存档模式\r\n9.2.3 为 ARCHIVE _LOG_DEST分配足够的空间\r\n9.2.4 用"ALTER DATABASE ARCHIVELOG"使能存档功能\r\n9.2.5 ARCHIVELOG模式使能后，立即执行一次完整备份\r\n9.2.6 更充分地利用ARCHIVE LOG CURRENT\r\n9.2.7 不要在存档日志序列中生成空洞\r\n9.2.8 如果可能的话，在磁盘上保留存档日志的双拷贝 \r\n9.2.9 存档到脱机介质上时，创建更多的联机重作日志组 \r\n9.2.10 使用OPS时考虑存档的特殊要求\r\n9.3 恢复\r\n9.3.1 理解恢复的必要性并设法避免失败\r\n9.3.2 理解影响恢复时间的因素\r\n9.3.3 确保恢复时机与SLA MTTR规范的一致\r\n9.3.4 为时间点恢复考虑另外的备份/恢复方法\r\n9.3.5 确保检查点之间有足够的间隔并设置合理的重作日志尺寸防止恢复延迟 \r\n9.3.6 恢复的最小单元\r\n9.3.7 恢复之前检查v$datafile\r\n9.3.8 为恢复操作维持一个特殊的init.ora文件\r\n9.3.9 RESELOGS可用作最后采用的措施\r\n9.3.10 估计所有的UNRECOVERABLE和NOLOGGING操作\r\n9.3.11 为恢复将所有的段和表空间进行分类\r\n9.3.12 为加速备份和恢复，将没有写活动的表空间保持为READONLY \r\n9.3.13 恢复期间设置AUTORECOVERY\r\n9.4 给半专门的管理人和监督人准备的技巧\r\n9.4.1 经常测试备份以保证有效恢复\r\n9.4.2 确保数据库管理员能够熟练地执行恢复操作\r\n9.4.3 创建数据库恢复小组\r\n9.4.4 记录所有数据库结构上的变化\r\n9.5 小结\r\n第10章 启动和关闭过程\r\n10.1 启动与关闭过程\r\n10.1.1 将数据库的启动和关闭自动化\r\n10.1.2 使用OEM启动／关闭多个数据库\r\n10.1.3 对于紧急的数据库反应需求，考虑采用"关闭放弃" \r\n10.1.4 执行shutdown abort前先执行ALTER SYSTEM CHECKPOINT\r\n10.2 小结\r\n第四部分 数据库维护\r\n第11章 一般维护\r\n11.1 主动维护和按需维护\r\n11.1.1 在所有可能级上实现健壮的安全性\r\n11.1.2 理解"ORA-1555：Snapshot too old "错误并采取步骤避免它 \r\n11.1.3 理解、防止并解决门闩锁和排队锁的竞争\r\n11.1.4 熟悉不同的等待事件并采取步骤减少等待事件\r\n11.1.5 周期性地监测并解决锁冲突\r\n11.1.6 监测共享池的效率并在需要时调节\r\n11.2 通用维护例程需要注意的其他重要问题\r\n11.3 小结\r\n第12章 空间和增长管理\r\n12.1 理解并管理空间及增长\r\n12.1.1 理解影响段增长的商业动因\r\n12.1.2 理解空间消耗的单位\r\n12.1.3 理解构成数据库的各种段\r\n12.1.4 熟悉由于空间管理不足而引发的错误及其影响\r\n12.1.5 对所有的应用程序表空间和SYSTEM表空间使能自动扩展功能 \r\n12.1.6 使用标准化文件大小\r\n12.1.7 在标准的文件大小中分配数据文件头块\r\n12.1.8 为每个段类型使用标准的存储语句以减少分段，使空间使用最优 \r\n12.1.9 设置INITIAL和NEXT时要考虑DB_BLOCK_SIZE的影响\r\n12.1.10 最优地设置PCTINCREASE来减少分段\r\n12.1.11 理解空闲表并进行最优的设置来减少锁竞争\r\n12.1.12 周期性地合并应用程序表空间\r\n12.1.13 理解错误位置标记的影响\r\n12.1.14 周期性地释放未被使用的块\r\n12.1.15 避免显式地丢弃数据文件\r\n12.1.16 从未预期的紧急空间需求学习"表空间改组"\r\n12.1.17 在DSS环境下不要盲目接受不受限制的段增长\r\n12.2 小结\r\n第五部分 难题解决\r\n第13章 警告日志与跟踪文件\r\n13.1 警告日志\r\n13.1.1 尽可能保持对警告日志的跟踪\r\n13.1.2 熟悉警告日志中的事件或消息\r\n13.1.3 编辑重要的错误信息使之仅被列出一次\r\n13.1.4 每两个星期到三个月对警告日志进行存档整理一次 \r\n13.2 跟踪文件\r\n13.2.1 了解跟踪文件中可以获得的信息\r\n13.2.2 了解如何确认跟踪文件所述的具体事件或会话\r\n13.2.3 了解引起跟踪文件产生的原因\r\n13.3 跟踪\r\n13.4 使用SQL*Net和Net8跟踪\r\n13.5 PL／SQL跟踪\r\n13.6 ODBC跟踪\r\n13.7 核心转储文件\r\n13.8 Oracle调试工具\r\n13.9 小结\r\n第14章 标识并解决数据库中断\r\n14.1 了解、预防并修复中断\r\n14.1.1 了解中断及其出现方式\r\n14.1.2 提前检测介质中断\r\n14.1.3 了解如何防止介质中断\r\n14.1.4 了解处理内存中断的技术\r\n14.1.5 熟悉处理逻辑中断的技术\r\n14.1.6 标识并列出所有被怀疑发生中断的部件\r\n14.1.7 标识并列出用户环境下预防、检测和修复中断的措施 \r\n14.1.8 获取涉及中断的相关信息\r\n14.1.9 培训管理员处理中断的能力\r\n14.2 小结\r\n第六部分 高可用性解决方案\r\n第15章 备用方法\r\n15.1 Oracle 提供的备用方法\r\n15.1.1 利用备用数据库进行系统灾难修复\r\n15.1.2 当不特别要求24×7连续工作时考虑使用备用实例 \r\n15.1.3 利用多个解决方案构造更加有效的方案\r\n15.2 在例行维护和紧急情况下的可用性策略问题\r\n15.2.1 使用定制备用数据库评估\r\n15.2.2 考虑利用备用表处理段级故障\r\n15.2.3 本章讨论的定制解决方案相关注意事项\r\n15.3 小结\r\n第16章 Oracle并行服务器\r\n16.1 理解和管理OPS环境\r\n16.1.1 理解什么是OPS以及它是如何提高可用性的\r\n16.1.2 理解、检测、删除错误的ping\r\n16.1.3 OPS环境下在使用应用程序之前对它们进行划分\r\n16.2 小结\r\n第17章 高级复制\r\n17.1 理解AR\r\n17.1.1 熟悉AR操作和基本功能\r\n17.1.2 理解可以实施的AR高可用性选项\r\n17.1.3 AR体系结构配置方式\r\n17.2 小结\r\n第18章 第三方HA解决方案\r\n18.1 基于硬件/OS的产品\r\n18.1.1 为灾难修复目的考虑使用EMC SRDF\r\n18.1.2 利用EMC TIMEFINDER 投资回报进行评估\r\n18.2 基于数据库的产品\r\n第七部分 构建实际的高可用性系统\r\n第19章 24×7工具箱\r\n19.1 利用脚本报告问题\r\n19.1.1 通过定期运行轮询脚本监控特定的故障\r\n19.1.2 当调用PL/SQL时，要熟悉应用失败恢复技术\r\n19.2 小结\r\n第八部分 新 特 性\r\n第20章 Oracle8i中的新HA特性\r\n20.1 面向维护的特性\r\n20.1.1 为了快速移动数据子集而考虑使用可传输的表空间 \r\n20.1.2 为了避免碎片而考虑使用本地管理的表空间\r\n20.1.3 熟悉新改变的管理特性\r\n20.1.4 联机创建、重建和消除索引碎片\r\n20.1.5 熟悉对没有划分的表进行重组的特性\r\n20.1.6 如果需要的话，可以很容易地丢弃列\r\n20.1.7 提高连续工作时间的划分特性的增强\r\n20.2 难题解决特性\r\n20.3 备份和面向恢复的特性\r\n20.3.1 利用一些方法方便并且加速RMAN备份\r\n20.3.2 控制和加速恢复时间\r\n20.4 其他HA特性\r\n20.4.1 使用新的监听者失败恢复和负载平衡服务\r\n20.4.2 熟悉LogMiner功能\r\n20.4.3 去掉"胖"OS开销\r\n20.5 小结

在这里我将告诉大家在编写本书过程中的一些想法. 本书的需求背景 1994年10月, Mosaic公司（后来的Netscape公司）发行了其浏览器Netscape的Beta 0.9版本, 这一软件使得世界各地的用户都可以非常自由地下载软件. 当时, 几乎没有人会想到就是这个软件为世界各地的商家打开了万千商机. 那些曾经被认为是研究人员与专业技术人员才能够涉及的Internet天堂, 由于这个神奇的浏览器的作用, 使得它对于成千上万的普通人已经不再神秘. Netscape这种易用性的特点掀起了一场革命, 以致于使得家庭主妇可以在自己的小孩熟睡时通过Internet为他们在网上购买圣诞节玩具, 也可以使得远离中心办公室的销售经理能够在午饭时间进行股票交易. 也就是说, 这个具有纪念意义软件的出现使得许多公司面临着越来越大的电子商务市场：全球市场. 但是, 这场革命也带来了对系统与资源的新要求, 也就是要求系统与资源全天候地打开并可访问, 使世界不再有黑夜. 正如Oracle公司最近所提出的一个口号“Internet正在改变整个世界”一样, 事实也确实如此. 随着电子商务与基于Web的数据库的迅速发展, 世界各地的公司都感到在Internet上建立自己的Web页面的重要性与紧迫性. 此外, 为了保持竞争优势, 它们不仅需要建立自己的Web页面, 还要求通过Web来拓展市场, 可以通过开发基于Web的数据库来收集与处理顾客订单来解决这个需求. 由于不再受地理位置的限制, 全球各地的顾客都可以访问公司页面与数据库系统. 这样, 当北美洲的顾客正在睡觉时, 来自澳大利亚与亚洲国家的顾客则有可能正在进行订货, 反之亦然. 即使是在某个特定的地理位置（例如北美洲）进行运作的商务活动, 公司顾客也有可能随时（白天和晚上）在自己的家中进行购物. 顾客的这种操作不可避免地要求公司必须使自己的数据库系统运行于24×7工作方式. 也就是说, 公司迫切需要自己的数据与信息全天候地对客户都是可以访问的. 哪怕是一个小时的停工时间, 也有可能会对公司造成上百万美元的损失, 更别说是对公司信誉所造成的影响. 这样, 为了保证系统的完全可用, IS人员在对系统进行预先维护与管理方面承受巨大的压力. 在Internet与电子商务革命之前, 某些商务活动就要求系统具有高可用性的特点. 但是, 与这些商务活动相关的公司（例如航空公司）都有足够的能力来提供巨型机以满足高可用性需求. 但随着电子商务的出现, 即使是很小的公司为了保证商务活动的正常运行, 都必须提出高可用性需求. 大公司为了保证自己的竞争优势, 更是为达到可用性需求而付出很高的代价. 由于人们对高可用性需求是如此强烈, 不难想象, 那些没有实力购买大型机/巨型机的公司也必须想尽办法来获取与巨型机相接近的可靠性与可用性. 这样一来, 它们该怎么办呢？任何系统停工都将会造成很坏的影响, 从而失去顾客. 销售能力. 销售数量以及减少盈利. 是不是只有巨型机或类似的设备才是解决可用性问题的唯一选择呢？显然, 答案是否定的. 从最近几年的形势来看, 中小型机日益表现出超过巨型机的诸多优势. 解决问题的关键是要进行全盘分析. 必须对公司所需要的可用性问题进行正确的分析, 并且将系统正常工作时间需求集成到体系结构技术. 应用程序分析以及应用程序的设计与实现周期中, 适当地提供系统健壮性备用与失败恢复解决方案, 系统的维护与监视应该保证对可用性所造成的影响很小. 也就是说, 必须在系统生命周期中从概念设计到物理实现的全阶段都考虑可用性问题. 此外, 无论是DBA. 体系结构设计者还是开发人员, 都必须在相关方面对系统高可用性发挥特有的作用. 成功地实现高可用性解决方案的关键取决于公司数据库管理人员对自己的作用以及自己所应该完成任务的熟悉程度. 这就是本书试图通过各种技巧以及实际的例子（也就是将高可用性目标集成到最终的基于Oracle的解决方案中）进行阐述的基点. 本书所面向的读者以及推荐的阅读方法 并非只有具有24×7正常工作时间需求的读者才能够从本书中获益. 事实上, 那些需要改进自己当前的Oracle可用性技术（这些技术在标准文档中没有给出）以及那些想要使自己当前的系统可用性更为持续与可靠的读者, 都能够从本书中获得有益的知识. 本书中所给出的技巧都是在假设任何24×7站点上可用性与性能是最先考虑的因素的基础上提出的, 我们很难说可用性与性能哪个更为重要. 在某些站点上, 一个运行速度很慢的数据库几乎与没有数据库毫无差别. 本书中所讨论的其他重要因素包括系统可维护性与管理的简易性. 本书中的许多技巧都是比较高级的技巧, 对这些技巧的讨论是在假设读者对于基本的管理与开发有相当的熟练程度的基础上进行的. 但即使是对于Oracle新用户, 本书也可以作为很好的参考资料, 对读者想要深入了解的特定领域的信息提供指导. 同样, 本书中给出的大多数技巧都是针对技术人员（例如DBA. 开发人员等等）而给出的. 但在有些站点上, 笔者发现非技术人员/半技术人员往往对高级的技术性操作与技术人员进行管理. 因此, 在本书的某些章节中也提供了面向这些管理者以及高层管理人员的一些技巧, 以便他们能够更容易地管理硬件. 操作系统. 网络. 数据库以及管理那些直接与这些组件直接打交道的技术人员. 如果您的上司正好是非技术人员或半技术人员, 可以考虑将这些技巧交给他（她）参考. 处于不同技术角度的人员可以以不同的方式来阅读本书, 笔者推荐最好是能够从头到尾地进行阅读, 但这对于许多人来说是不现实的. 事实上, 笔者本人也很少从头到尾地完全阅读一本技术手册. 我常常是跳过一些不重要的问题, 而直接对自己感兴趣的部分或者是能够解决当前问题的部分进行仔细阅读. 本书按照“技巧与技术”的风格来进行编写, 也便于读者按照自己所需要的方式进行阅读. 如前所述, 也可以利用本书作为解决与Oracle相关问题的参考手册. 但是, 如果读者更倾向于按照某种特定的次序进行阅读, 下面给出了对于特定的技术人员所推荐使用的阅读顺序. 技术人员类型 推荐的章节阅读顺序 体系结构设计者 1. 2. 3. 4. 5. 6. 15. 16. 17. 18. 20以及其他感兴趣/有用的章节 DBA 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20 开发人员 1. 2. 3. 4. 5. 6. 15. 16. 19. 20以及其他感兴趣/有用的章节 除了前面5~6章, 读者可以按照自己的需要阅读相关章节. 本书的每章都试图给出关于某个特定领域的全部技巧, 必要时, 给出了对其他适当的章节进行参考的信息. 编写本书的原因 真正使我能够完成本书的动力来自Internet网络文化, 在这里更不用提及电子商务的繁荣. 可以说, 对于包括我在内的大多数人来说, 金钱是最大的推动力. 但是, 本书的编写工作并没有什么报酬（至少是这种报酬不值一提）. 正如大多数技术性作者将会告诉大家的那样, 除非你是Stephen King或Michael Crichton, 否则就不应该指望通过写作来维持生活. 作为一名技术顾问, 我能够从中得到足够多的报酬来维持自己的生活, 而从本书的编写中所得到的报酬对我来说是无足轻重的. 说实话, 有时我们必须为了公共利益来获取比金钱更为重要的一些东西, 来体现自己的价值, 而这正好是能够驱动我花费大量的夜间时间在兼顾自己全职工作的情况下来编写本书的原因所在. 在Internet上, 有许多富有创见精神以及努力工作精神的人免费为人们提供很好的服务, 以至于造成网络拥塞. 我经常听说Netscape公司的Marc Andreessen与他的组员们将自己的“金饭碗”（也就是所开发的浏览器）免费公诸于世, 也常常听说Linus Torvalds将自己的Linux源代码免费公开的报导. 当然, 我不是Marc Andreessen也不是Linus Torvalds, 但我至少可以将自己多年来所掌握的知识几乎免费地与大家共享. 无论读者是否相信, 对本书的编写确实几乎是免费的. 通过编写本书所获取的报酬甚至不足以用来支付在编写本书的过程中购买比萨饼. 咖啡. 威士忌酒以及可乐的开销. 多年来我从各种渠道（书籍. 白皮书. 各种团体）所收集到的信息都被融入本书中, 并且, 为了进行试验, 几乎在产品环境下与对软件进行了大量的试验与测试, 经常因为需要进行列表信息的分析而工作到深夜两点半. 但是, 我们必须将自己所收集与学习到的这些知识贡献给别人, 并且与周围的人们共享这些知识. Internet至少为它的网民灌输了这样一种精神：就是牺牲自己一点点的乐趣, 来换取大多数人的利益. 带着这种动力, 在编写这本关于数据库方面的高级主题的书籍时就有一种强烈的责任感跟随着自己, 就是必须为那些对于数据库技术的基本问题与基本技术比较了解的人提供一种关于技巧与技术的指导, 而且必须将这些人带入一种数据库应用的更高境界. 曾经, 我强烈地意识到为那些经常从事实际工作的人们编写一本没有很多深奥理论书籍的重要性. 在许多客户站点上, 我也经常看到技术人员为了获取所需要的正常工作时间而进行的艰苦努力. 但由于他们缺乏关于如何实现24×7正常工作时间需求所需要的指导信息, 因此迫切地希望市场上能有一本关于如何实现高可用性的Oracle专用书籍. 的确, 市场上有许多从理论上深入讨论Oracle某个组件的书籍, 但是, 又有多少人真正对于纯理论性的东西感兴趣呢？许多这样的书籍都很少与现实世界中的实例联系起来. 我曾经看到许多DBA对于这些过多的理论失去了信心, 以致于他人总是回避阅读那些理论性的文档与书籍. 我希望自己编写的这本书不会将读者带入梦乡, 而是能够为他们提供一些在特定的现实世界环境下有用的技巧. 希望通过对本书的学习, 读者能够从中获取自己所需要的知识, 从而对Oracle核心问题有更好的理解并且能够对Oracle进行优化配置以最大限度地获取可用性与性能. 对于那些在大多数其他书籍中都可以获取的信息, 笔者在这里没有进行详述. 相反, 我侧重于在本书中讨论那些若很好地解决就能够使应用程序得到优化的小问题. 当然, 必须切记所有这些小问题都应该与使用手册以及其他出版物中所讨论的原则性大问题结合起来, 才能够达到最终目的. 开始阅读前的重要声明 在读者对本书的内容进行阅读之前, 还需要说明一个重要的问题：书中列出了一些在先前的Oracle文档中没有说明的一些特性与功能（例如：init.ora参数. 跟踪等等）, 本书只是从了解信息的角度对这些问题进行解释, 以便帮助读者理解Oracle的内部工作原理. 除非Oracle Support有特别的要求, 否则, 请不要改变任何没有进行文档声明的特性, 因为其中有些特性将会直接影响到Oracle的工作过程. 如果对它们的功能没有精确的认识以及深入的理解就进行随意的改动, 将有可能使自己的数据库系统崩溃. 此外, 在没有得到Oracle Support特别许可的情况下所进行的改动, 将使自己的Support合同协议发生冲突而成为一个不受支持的合同协议.