修改数据库的补丁等级

　　这是我曾经面对的麻烦情况之一，我记得在一个Oracle 9iR2数据库上从9.2.0.1.0升级到9.2.0.3.0，在更新有效的补丁集后不久，我的QA测试员立即报告我们的旗舰OLTP应用程序的订单条目查看屏幕 — 一个使用了简单的SQL查询的Powerbuilder DataWindow从一个包含上百万行数据的表中检索一个特定的订单子集 — 现在它的响应时间从一秒增加到了1到2分钟，最后我们调查了这个响应时间是由于9.2.0.3.0版本中基于成本的优化器处理FIRST_ROWS优化提示时有所变化引起的，不需要解释，我们立即决定抛弃新的补丁集直到我们所有的应用程序代码都可以通过复审为止。

　　迁移Oracle数据库到一个不同的数据库发行版

　　我作为一个Oracle DBA遇到的最艰难的挑战是当我已经从它当前的Oracle数据库版本到下一个版本升级一个完整的数据库系统时，如果我有一个QA或测试环境，实际上升级通常是相对琐碎地执行和做准备，升级真实的挑战来自现有SQL和PL/SQL代码的影响。

　　修改一个数据库的平台配置

　　这是我作为一个DBA最多的尝试经历，我遇到的挑战包括：

　　◆添加或移除主服务器的CPU

　　◆扩展或减少主机总共可用的内存

　　◆修改或升级主服务器的磁盘I/O子系统，包括传统的基于文件系统（如NTFS或EXT3）、原生磁盘分区或Oracle自动存储管理（ASM）文件系统的存储之间的转换

　　◆迁移到一个完全不同的（或少量不同的）硬件平台

　　◆迁移到一个不同的操作系统（如从windows迁移到linux）
　　
　　◆从一个32位的操作系统迁移到一个64位的操作系统

　　Oracle数据库11g SQL性能分析器：一个简短的示例

　　幸运地，Oracle数据库11g提供了一个崭新的工具集 — SQL性能分析器（SPA），它让Oracle DBA可以测量在两个不同数据库配置之间的改变的影响，因为它允许我们：

　　◆捕获一套由数据库工作负载典型样本构成的SQL语句

　　◆使用当前数据库系统创建一个前置的映像或基线建立当前工作负载性能的样本

　　◆在数据库系统配置后测试相同的工作负载的性能

　　◆通过建议的修改识别工作负载的哪个组件有影响或没有影响，以及哪个保留不做修改

　　◆确定如何为表现不佳的SQL语句找到最合适的方法以便它们在新的环境中能最有效率地运行

　　为了说明SQL性能分析器如何工作，我将执行下面的步骤来评估一组相当简单的SQL语句在Oracle 11g数据库样例的映像前后的性能：