《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 进行有条理的估计。
. 在空闲时间执行报告工作。