Oracle8优化技术:内存/CPU

王朝oracle·作者佚名  2008-05-19
窄屏简体版  字體: |||超大  

内存/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 进行有条理的估计。

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

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航