《Oracle8 优化技术》摘录 (第二章 内存/CPU)

                           

===============

第二章 内存/CPU

===============

内存/CPU规则#1  为了更好地防范介质故障，一般应在 ARCHIVELOG 模式下运行 Oracle8 数据

   库。这使用户能在数据库打开和运行时完成数据库的一致性备份。

内存/CPU规则#2  DBAs 要定期查看跟踪文件，尤其是警报日志，并做些清除操作，只有当有人

   用手工方式编辑跟踪文件并且删除该文件内容时，警报跟踪文件才暂停增大。

内存/CPU规则#3  检查实例警报日志文件中是否存在有关在线重演日志组的错误信息。确定数据

   库是否有足够的重演日志文件是最容易的方法，假如 Oracle 因为没有清除完而不能重用重

   演日志，那么可能需要更多的重演日志。

内存/CPU规则#4  在 Oracle 首次安装时，需要设置好共享池的大小，以确保共享池中有足够大

   的空间以便使 Oracle 能在共享池中很好地调整高速缓存。

内存/CPU规则#5  在多处理器的计算机上，初始化参数文件项 LOG_SIMULTANEOUS_COPIES 应被

   设置为 CPU 数的两倍，这将有助于减少潜在的 redo copy latch 争用。

内存/CPU规则#6  当使用 MTS 时，为了 SHARED_POOL_SIZE，每个用户存在一个 1K 的额外需求，

   该额外空间用于存放关于用户进程、调度程序和服务器之间连接的信息。

内存/CPU规则#7  评估在繁忙期间用户对 CPU 提出的需求。

内存/CPU规则#8  评估用户在非繁忙时间（晚上和周末）对 CPU 的需求。

内存/CPU规则#9  评估支持用户进程与系统服务对 CPU 时间的需求之间的平衡。

小结和说明

..........

. 定期检查实例警告文件，以便了解 Oracle 产生的任何错误。

. 监视库高速缓存的成功率，如果这个成功率很低的话（少于80%），则应当考虑调整初始化参数

 文件中的 SHARED_POOL_SIZE 参数。

. 通过查看 V$LATCH 字典视图，监视重演日志缓高速缓存中失败(misses)对成功(gets)的比例，

 如果misses多于gets的1%，则结果将导致重演（redo latches）的冲突（拷贝latch和/或配置

 latch，这取决于所使用系统的CPU数量）。

. 如果有超过25%的排序请求需要磁盘空间（利用V$SYSSTAT），则应考虑增加初始化参数文件参

 数SORT_AREA_SIZE。

. 如果可能的话，最好保持数据库一天24小时开机，每次数据库重新启动时，库高速缓存和字典

 高速缓存必须被装入，在装入这些高速缓存当中，miss率将巨增。如果数据库没有一直打开，

 定义一些 SQL 语句在数据库启动后强制装载这些高速缓存。

下面前四点指出了初始化参数文件的五个关键项，按建议调整这些项，有助于 CPU 的调整运行。

. 分配尽可能多的实存给共享池和数据库缓冲区（初始化参数文件中的SHARED_POOL_SIZE项和

 DB_BLOCK_BUFFERS项）以便允许在内存中运作尽可能多的工作，与在磁盘工作相比，在内存

 中工作使用的CPU较少。

. 将初始化参数文件项 SEQUENCE_CACHE_ENTRIES 设为高值（缺省值为10，可设为1,000）。

. 分配大于缺省值的内存以便执行排序操作（初始化参数文件中的 SORT_AREA_SIZE项），不请求

 I/O的内存排序使用较少的CPU。

. 在多CPU的机器上，增大初始化参数文件项LOG_SIMULTANEOUS_COPIES的值，以便允许每个CPU的

 进程把项拷贝到重演日志缓冲区中。

. 为了释放占用的CPU，尽一切可能使I/O最小化。

. 通过合理分配工作日白天和夜间的负载来使得CPU工作能力最大化。

. 在考虑 CPU 升级前，开始着手对 CPU 进行有条理的估计。

. 在空闲时间执行报告工作。