当前位置:Gxlcms > mysql > Oracle参数调优

Oracle参数调优

时间:2021-07-01 10:21:17 帮助过:19人阅读

Oracle数据库升级助手(DBUA)配置工具包括一个自动扩展系统文件的命令选项,能够从oracle express(XE或免费版)升级到其 他版本。

一.升级到11gR2之后
Oracle数据库升级助手(DBUA)配置工具包括一个自动扩展系统文件的命令选项,能够从oracle express(XE或免费版)升级到其 他版本。
升级前脚本检查以下各项:
1.无效用户或角色
2.无效数据类型或对象
3.不支持的字符集
4.统计信息的收集
5.足够的资源(undo/rollback段,表空间和空闲磁盘空间)
6.缺失的升级需要的脚本
7.运行的监听器
8.oracle数据库软件已连接到database vault选件
如果在安装过程中指定ORACLE_BASE环境变量,oracle将使用此值设置DIAGNOSTIC_DEST参数,其中包括所有的ADR目录。

1.11g新特性
默认安装完,密码是区分大小写的
SEC_CASE_SENSITIVE_LOGON 默认是true 大小写敏感
SEC_MAX_FAILED_LOGIN_ATTEMPTS 默认值是10 设定尝试次数。

alter user username account unlock;

2.oracle的重要参数
MEMORY_TARGET
MEMORY_MAX_TARGET
SGA_TARGET
SGA_MAX_SIZE
PAG_AGGREGATE_TARGET
DB_CACHE_SIZE
SHARED_POOL_SIZE


默认读取参数文件的顺序
1.spfile.ora
2.spfile.ora
3.init.ora

如果使用alter system命令只修改spfile,而且在启动的时候发现设置错误,数据库将不会启动。这时,不能使用alter system命令去解决这个问题,需要根据spfile创建一个pfile,修改这个pfile,然后使用这个pfile来启动数据库。之后需要再创建spfile然后使用spfile重启数据库。

在V$PARAMETER视图里有两个关键的字段(V$PARAMETER显示会话级别有效的参数,V$SYSTEM_PARAMETER显示在整个实例级别有效的参数):
ISSES_MODIFIABLE:表明拥有alter session权限的用户是否可以在他们的会话级别修改这个初始化参数
ISSYS_MODIFIABLE:表明拥有ALTER SYSTEM权限的用户是否可以修改这个参数。

select name,value,isdefault,isses_modifiable,issys_modifiable from V$PARAMETER where issys_modifiable <> 'FALSE' or isses_modifiable <> 'FALSE' order by name;
alter session set sort_area_size=10000000;
动态地修改初始化参数对开发人员和DBA来说是非常强大的特性。因此,,如果不做限制的话,拥有alter session 特权的用户就可以随意地为某个会话的sort_area_size 分配大于100M的内存。


3.优化DB_CACHE_SIZE来提高性能
oracle 10g DB_BLOCK_BUFFERS变为隐含参数,在11g又被启用,默认为0,意思是除非设置它,否则它不会被使用(用DB_CACHE_SIZE取而代之)。
DB_CACHE_SIZE是为主数据库缓存或存放数据而初始分配的内存量。如果设置了MEMORY_TARGET或SGA_TARGET,那么该参数就无须设置。我们的目标应该是实现一个驻留在内存的数据库,至少要把所有将被查询的数据都放进内存里。
如果DB_CACHE_SIZE设置太低,不论怎样优化这个系统,oracle也没有足够的内存来有效的执行操作,系统运行状态也会很糟糕。如果设置过高,您的系统可能会使用交换空间,甚至停机。DB_CACHE_SIZE是SGA的一部分,用于存储和处理数据以及查询访问。设置过低,那么最近使用的数据会从内存中清除出去,如果有另外一个查询重新调用这些被清除的数据,就必须重新从磁盘中读取(将会使用到I/O和CPU资源).
MEMORY_TARGET,SGA_TARGET(如果使用的话)和DB_CACHE_SIZE(如果设置了最小值) 是用来优化数据缓存命中率的关键参数:命中率就是指那些不用从磁盘上执行物理读操作就可以访问到的数据块的比例。
如果系统负载情况不变,而缓存命中率剧烈变化,就应该立刻调查发生的原因。糟糕的连接和索引也会由于读取许多索引块而产生非常高的命中率,因此一定要保证命中率不是因为这些因素而提高的,而是因为系统经过良好调优而得到的。异常高的命中率通常也暗示有代码用到了糟糕的索引或连接。
通过比较随时间变化的命中率,可以帮助您注意系统某天发生的重大改变。

4.使用V$DB_CACHE_ADVICE优化DB_CACHE_SIZE
可以利用如下清单查看修改DB_CACHE_SIZE后对数据缓存命中率的影响
select name,size_for_estimate,size_factor,estd_pyhsical_read_factor from v$db_cache_advice;
NAME size_for_estimate size_factor estd_pyhsical_read_factor
DEFAULT 4 .1667 1.8322
DEFAULT 8 .3333 1.0169
DEFAULT 12 .5 1.0085
DEFAULT 16 .6667 1
DEFAULT 20 .8333 1
DEFAULT 24 1 1
当前的缓存大小为24M size_factor=1
我们可以吧缓存大小减小为16M 并维持当前的缓存命中率,因为SGA减小到16M时,PHYSICAL_READ_FACTOR仍为1


保持数据缓存命中率超过95%
有些例子中,将命中率从95%增大到98%,就可以显著得提高性能--特别是最后命中在磁盘的那5%是系统的主要延迟,或者说磁盘的缓存已经不够用了。



5.监控V$SQLAREA视图以查找较慢的查询
尽管低于95%的命中率通常都表明DB_CACHE_SIZE被设置得过低。命中率失真和那些非DB_CACHE_SIZE问题包括:
1.递归调用
2.缺少索引或抑制索引
3.内存中驻留的数据
4.UNDO/回滚段
5.数倍的逻辑读
6.导致系统使用CPU的物理读
通过监控V$SQLAREA视图或企业管理器可以找到较慢的查询。

人气教程排行