9i 中保留了8i中的参数,如设置了新的参数,则忽略旧的参数。9i中用db_cache_size来取代db_block_buffers , 用db_keep_cache_size 取代buffer_pool_keep, 用db_recycle_cache_size 取代buffer_pool_recycle;这里要注意9i 中设置的是实际的缓存大小而不再是块的数量。另外9i新增加了db_nk_cache_size,这是为了支持在同一个数据库中使用不同的块大小而设置的。对于不同的表空间,可以定义不同的数据块的大小,而缓冲区的定义则依靠该参数的支持。其中n 可以为2、4、6、8、16 等不同的值。在这里顺便提及的一个参数就是db_block_lru_latches,该参数在9i中已经成为了保留参数,不推荐手工设置。
PGA 在9i 里面这部分也有了很大的变化。在独立模式下,9i已经不再主张使用原来的UGA相关的参数设置,而代之以新的参数。假如 workarea_size_policy=AUTO(缺省),则所有的会话的UGA 共用一大块内存,该内存由 pga_aggregate_target 设置。在我们根据前面介绍的方法评估了所有进程可能使用的最大PGA 内存之后,我们可以通过在初始化参数中设置这个参数,从而不再关心其他 ”*_area_size” 参数。
SGA_MAX_SIZE 在9i中若设置了SGA_MAX_SIZE,则在总和小于等于这个值内,可以动态的调整数据缓冲区和共享池的大小 SQL> show parameters sga_max_size NAME TYPE VALUE ---------------- -------------------- ------- ------------- sga_max_size unknown 193752940 SQL> SQL> alter system set db_cache_size = 30000000; System altered. SQL> alter system set shared_pool_size = 20480000; System altered.
1.5 lock_sga = true 的问题 由于几乎所有的操作系统都支持虚拟内存,所以即使我们使用的内存小于物理内存,也不能避免操作系统将SGA 换到虚拟内存(SWAP)。所以我们可以尝试使得SGA 锁定在物理内存中不被换到虚拟内存中,这样减少页面的换入和换出,从而提高性能。但在这里遗憾的是,windows 是无法避免这种情况的。下面我们来参考在不同的几个系统下怎么实现lock_sga AIX 5L(AIX 4.3.3 以上) logon aix as root cd /usr/samples/kernel ./vmtune (信息如下) v_pingshm已经是1 ./vmtune -S 1 然后oracle用户修改initSID.ora 中 lock_sga = true 重新启动数据库
HP UNIX Root身份登陆 Create the file "/etc/privgroup": vi /etc/privgroup Add line "dba MLOCK" to file As root, run the command "/etc/setprivgrp -f /etc/privgroup": $/etc/setprivgrp -f /etc/privgroup oracle用户修改initSID.ora中lock_sga=true 重新启动数据库
SOLARIS (solaris2.6以上) 8i版本以上数据库默认使用隐藏参数 use_ism = true ,自动锁定SGA于内存中,不用设置lock_sga, 如果设置 lock_sga =true 使用非 root 用户启动数据库将返回错误。
WINDOWS 不能设置lock_sga=true,可以通过设置pre_page_sga=true,使得数据库启动的时候就把所有内存页装载,这样可能起到一定的作用。
2. 应用优化 下面我们从技术的角度入手,来探讨数据库优化方面的问题。通常作为优化Oracle系统的人,或者是DBA,其实很多时候对应用并不很了解甚至可以说是完全不了解,更不要说对应用程序代码的了解。事实上呢,一个系统运行的快或者慢相信大家都明白,第一重要的是数据库的设计,然后是应用的设计, SQL语句的编写,最后才是数据库参数的调整和硬件、网络的问题,等等。所以在我们不了解一个系统的时候来优化数据库应用不是一个轻松的容易的事情。那么我们第一步应该怎么做呢? 通常有两类方法: 其中一个方法就是我们常用的,使用statspack来进行诊断系统的瓶颈所在。在statspack中oracle给出了几乎涵盖oracle大部分重要内容的信息。 另外一种方式,就是trace session。假如某个session运行很慢或者某个用户的某个查询很慢,那么这个时候我们可以通过trace session的方式来诊断到底是慢在哪里,看究竟执行计划是怎样的,然后在user_dump_dest下根据该session的进程号或者线程号可以找到一个产生的trace文件。通过使用tkprof格式化文件之后我们就可以看见很多的统计信息,这里包括了执行计划、parse/fetch等步骤消耗cpu的时间。通常我们是观察query模式下的consistent gets来首先看sql是否使用了索引,然后看执行计划是不是正常,是不是有调整的余地。当然如果您没有实际做过的话,这些内容说起来很抽象。这是在不了解应用和程序下针对特定session的诊断和调整过程。
复制本页网址和标题,发送给你QQ/Msn的好友一起分享
上一篇:Recordset.Open方法参数介绍
下一篇:很有用的oracle 函数