Oracle8 优化技术:内存/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 进行有条理的估计。
　　
　　. 在空闲时间执行报告工作。