在内存中检查数据块完整性，而非在磁盘上检查
活动的数据库实例将大量数据从用户会话移动到缓冲区缓存，从缓存移动到磁盘，反之亦然。这些移动可能使数据块容易遭到损坏。
Oracle 通过在将数据块写入磁盘之前计算数据值的校验和确保数据块的完整性。同时将该检验和值写入磁盘。当从磁盘中读取该块时，读取过程将再次计算校验和，然后与存储的值进行对比。如果值已损坏，校验和将不同，从而表明数据已经损坏。
由于大多数操作发生在内存中，因此在源本身（即缓冲区缓存）中执行该检查应谨慎。在 Oracle 数据库 10g 第 2 版中，还可以通过将初始化参数 DB_BLOCK_CHECKSUM 设置为 FULL 来执行内存检查。
在进行此设置后，Oracle 将在进行任何更改之前计算校验和并将该校验和与存储的值进行比较。该方法可以发现内存本身中的任何数据损坏，并在数据损坏时报告错误，这对防止磁盘级别的数据损坏以及防止将该损坏传播到备用数据库很帮助。
请注意，默认情况下，该参数设置为 FALSE，这与早期版本不同，那时该参数设置为 TRUE。
联机限制更改
当需要更改在创建数据库期间定义的参数（MAXDATAFILES、MAXLOGFILES 等）时，您有哪些选择？在 Oracle 数据库 10g 第 2 版之前，唯一的选择就是遵循以下步骤：
- 备份要跟踪的控制文件。
- 在跟踪文件中修改要更改的参数。
- 关闭数据库。
- 开始挂载。
- 重新创建控制文件。
- 在 RESETLOGS 模式下打开数据库。
不用说，该方法降低了可用性。此外，由于 RMAN 将有关备份的元数据保存在控制文件和目录中，因此该信息将在此过程中丢失。由于控制文件是在 RESETLOGS 模式下创建的，因此某些备份信息也将丢失。
在 Oracle 数据库 10g 第 2 版中，您无需重新创建控制文件便可更改这些参数。这样，您将不会丢失其中存储的 RMAN 信息。
更快的启动
2GB 内存即被视为够大的年代已像恐龙一样成为了历史。现在，100GB 的大型缓冲区缓存并不鲜见。实例启动时，初始化这样大小的缓冲区缓存可能需要数分钟甚至数小时。
如果您深入研究这种情况将会发现，在数据库实例启动时无需启动整个缓冲区缓存。当实例启动时，缓冲区缓存是空的；随着用户从表中选择数据，该缓冲区缓存将逐渐填满。因此，在实例启动时无需初始化整个缓冲区缓存。
在 Oracle 数据库 10g 第 2 版中，此行为在启动逻辑中受到控制。当启动实例时，只初始化 10% 的缓冲区缓存；剩余缓冲区缓存在检查点进程打开数据库之后才被初始化。这个新方法显著减少了实例启动的时间。
但请注意，在初始化整个缓冲区之前，无法使用缓冲区缓存大小自动调整功能。
在 Oracle Enterprise Manager 中管理多个对象
如果某个模式中的多个对象均无效，您通常怎么办？您很有可能创建一个 SQL 脚本来动态生成另一个编译这些无效对象的脚本。至少，在缺少第三方工具的情况下，这个方法还不错。
但如果可以为此使用 Oracle Enterprise Manager Grid Control 岂不是更好？不是只选择一个无效对象并单击编译，而是同时选择多个无效对象并通过一次单击操作编译它们？
在 Oracle 数据库 10g 第 2 版中，您确实可以这么做。如下所示，您所要做的就是选中对象旁边的复选框。然后，就可以从“Actions”旁边的下拉列表中选择“Compile”来同时编译所有对象。
除了编译以外，您还可以执行大量其他操作，如创建 DDL 或删除对象。
XML 格式的审计跟踪
如果您长期以来一直在使用 Oracle 中内置的审计工具则可能会注意到，一个非常有用的特性就是能够将审计跟踪写入一个文件系统中。将条目写入文件系统而非数据库本身中可以建立额外级别的安全性。
您所要做的就是设置两个初始化参数：
audit_file_dest = '/auditfs' audit_trail = xml并重新启动该实例。但这两个参数不是动态的；一旦设置，将把审计跟踪写入目录 /auditfs 中。参数 audit_file_dest 是可选的；默认为 $ORACLE_HOME/rdbms/audit 目录。这些审计跟踪文件将为扩展名为 .xml 的 XML 文件。
以下是一个 XML 格式的审计跟踪示例：
- ＜Audit xmlns="" xmlns:xsi="" xsi:schemaLocation=""＞ ＜Version＞10.2＜/Version＞ - ＜AuditRecord＞ ＜Audit_Type＞8＜/Audit_Type＞ ＜EntryId＞1＜/EntryId＞ ＜Extended_Timestamp＞2005-03-05T20:52:51.012045＜/Extended_Timestamp＞ ＜DB_User＞/＜/DB_User＞ ＜OS_User＞oracle＜/OS_User＞ ＜Userhost＞oradba＜/Userhost＞ ＜OS_Process＞18067＜/OS_Process＞ ＜Terminal＞pts/0＜/Terminal＞ ＜Instance_Number＞0＜/Instance_Number＞ ＜Returncode＞0＜/Returncode＞ ＜OS_Privilege＞SYSDBA＜/OS_Privilege＞ ＜Sql_Text＞CONNECT＜/Sql_Text＞ ＜/AuditRecord＞ ＜/Audit＞
这些跟踪文件可被 XML 分析器轻松分析，从中提取有用的信息。您甚至可以将它们作为 XML 类型加载到数据库中，然后使用 XML 查询在 SQL 内部查询它们。
在 Oracle 数据库 10g 第 2 版中，可以将此 XML 文件与 SQL 查询相结合，从中进行选择，就好像它是来自一个 SQL 源似的。还有一个预定义的动态视图 V$XML_AUDIT_TRAIL，用于从固定表 X$XML_AUDIT_TRAIL 中进行选择。此动态视图在结构方面类似于常规审计跟踪视图 DBA_AUDIT_TRAIL。
对于 DBA 而言，使用 XML 格式的审计跟踪就可以通过第三方的 XML 分析器和编辑器操作文件，并可以通过接受 XML 作为输入的工具发布报表。您不再需要编写自己的分析器来解释这些审计跟踪文件。