几个简单的步骤大幅提高Oracle性能 我优化数据库的三板斧
10年积累的成都网站建设、网站设计经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先做网站后付款的网站建设流程，更有邹城免费网站建设让你可以放心的选择与我们合作。
数据库优化的讨论可以说是一个永恒的主题 资深的Oracle优化人员通常会要求提出性能问题的人对数据库做一个statspack 贴出数据库配置等等 还有的人认为要抓出执行最慢的语句来进行优化 但实际情况是 提出疑问的人很可能根本不懂执行计划 更不要说statspack了 而我认为 数据库优化 应该首先从大的方面考虑 网络 服务器硬件配置 操作系统配置 Oracle服务器配置 数据结构组织 然后才是具体的调整 实际上网络 硬件等往往无法决定更换 应用程序一般也无法修改 因此应该着重从数据库配置 数据结构上来下手 首先让数据库有一个良好的配置 然后再考虑具体优化某些过慢的语句 我在给我的用户系统进行优化的过程中 总结了一些基本的 简单易行的办法来优化数据库 算是我的三板斧 呵呵 不过请注意 这些不一定普遍使用 甚至有的会有副作用 但是对OLTP系统 基于成本的数据库往往行之有效 不妨试试 （注 附件是Burleson写的用来报告数据库性能等信息的脚本 本文用到）
一．设置合适的SGA
常常有人抱怨服务器硬件很好 但是Oracle就是很慢 很可能是内存分配不合理造成的 ( )假设内存有 M 这通常是小型应用 建议Oracle的SGA大约 M 其中 共享池（SHARED_POOL_SIZE）可以设置 M到 M 根据实际的用户数 查询等来定 数据块缓冲区可以大致分配 M M i下需要设置DB_BLOCK_BUFFERS DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于数据块缓冲区大小 i 下的数据缓冲区可以用db_cache_size来直接分配
( )假设内存有 G Oracle 的SGA可以考虑分配 M 共享池分配 M到 M 数据缓冲区分配 M到 M
( )内存 G SGA可以考虑分配 G 共享池 M到 M 剩下的给数据块缓冲区
( )内存 G以上 共享池 M到 M就足够啦 再多也没有太大帮助 (Biti_rainy有专述)数据缓冲区是尽可能的大 但是一定要注意两个问题 一是要给操作系统和其他应用留够内存 二是对于 位的操作系统 Oracle的SGA有 G的限制 有的 位操作系统上可以突破这个限制 方法还请看Biti的大作吧
二．分析表和索引 更改优化模式
Oracle默认优化模式是CHOOSE 在这种情况下 如果表没有经过分析 经常导致查询使用全表扫描 而不使用索引 这通常导致磁盘I/O太多 而导致查询很慢 如果没有使用执行计划稳定性 则应该把表和索引都分析一下 这样可能直接会使查询速度大幅提升 分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令 对于少于 万的表 可以考虑分析整个表 对于很大的表 可以按百分比来分析 但是百分比不能过低 否则生成的统计信息可能不准确 可以通过DBA_TABLES的LAST_ANALYZED列来查看表是否经过分析或分析时间 索引可以通过DBA_INDEXES的LAST_ANALYZED列
下面通过例子来说明分析前后的速度对比 （表CASE_GA_AJZLZ大约有 万数据 有主键）首先在SQLPLUS中打开自动查询执行计划功能 (第一次要执行\RDBMS\ADMIN\utlxplan sql来创建PLAN_TABLE这个表)
SQL SET AUTOTRACE ON SQLSET TIMING ON
通过SET AUTOTRACE ON 来查看语句的执行计划 通过SET TIMING ON 来查看语句运行时间
SQL select count(*) from CASE_GA_AJZLZ; COUNT(*) 已用时间: : : Execution Plan SELECT STATEMENT Optimizer=CHOOSE SORT (AGGREGATE) TABLE ACCESS (FULL) OF CASE_GA_AJZLZ ……………………
请注意上面分析中的TABLE ACCESS(FULL) 这说明该语句执行了全表扫描 而且查询使用了 秒 这时表还没有经过分析 下面我们来对该表进行分析
SQL *** yze table CASE_GA_AJZLZ pute statistics;
表已分析 已用时间: : : 然后再来查询
SQL select count(*) from CASE_GA_AJZLZ; COUNT(*) 已用时间: : : Execution Plan SELECT STATEMENT Optimizer=FIRST_ROWS (Cost= Card= ) SORT (AGGREGATE) INDEX (FAST FULL SCAN) OF PK_AJZLZ (UNIQUE) (Cost= Card= ) …………………………
请注意 这次时间仅仅用了 秒！这要归功于INDEX(FAST FULL SCAN) 通过分析表 查询使用了PK_AJZLZ索引 磁盘I/O大幅减少 速度也大幅提升！下面的实用语句可以
用来生成分析某个用户的所有表和索引 假设用户是GAXZUSR
SQL set pagesize SQL spool d:\ *** yze_tables sql; SQL select *** yze table ||owner|| ||table_name|| pute statistics; from dba_tables where owner= GAXZUSR ; SQL spool off SQL spool spool d:\ *** yze_indexes sql; SQL select *** yze index ||owner|| ||index_name|| pute statistics; from dba_indexes where owner= GAXZUSR ; SQL spool off SQL @d:\ *** yze_tables sql SQL @d:\ *** yze_indexes sql
解释 上面的语句生成了两个sql文件 分别分析全部的GAXZUSR的表和索引 如果需要按照百分比来分析表 可以修改一下脚本 通过上面的步骤 我们就完成了对表和索引的分析 可以测试一下速度的改进啦 建议定期运行上面的语句 尤其是数据经过大量更新
当然 也可以通过dbms_stats来分析表和索引 更方便一些 但是我仍然习惯上面的方法 因为成功与否会直接提示出来
另外 我们可以将优化模式进行修改 optimizer_mode值可以是RULE CHOOSE FIRST_ROWS和ALL_ROWS 对于OLTP系统 可以改成FIRST_ROWS 来要求查询尽快返回结果 这样即使不用分析 在一般情况下也可以提高查询性能 但是表和索引经过分析后有助于找到最合适的执行计划
三．设置cursor_sharing=FORCE 或SIMILAR
这种方法是 i才开始有的 oracle 不支持 通过设置该参数 可以强制共享只有文字不同的语句解释计划 例如下面两条语句可以共享
SQL SELECT * FROM MYTABLE WHERE NAME= tom SQL SELECT * FROM MYTABLE WHERE NAME= turner
这个方法可以大幅降低缓冲区利用率低的问题 避免语句重新解释 通过这个功能 可以很大程度上解决硬解析带来的性能下降的问题 个人感觉可根据系统的实际情况 决定是否将该参数改成FORCE 该参数默认是exact 不过一定要注意 修改之前 必须先给ORACLE打补丁 否则改之后oracle会占用 %的CPU 无法使用 对于ORACLE i 可以设置成SIMILAR 这个设置综合了FORCE和EXACT的优点 不过请慎用这个功能 这个参数也可能带来很大的负面影响！
四．将常用的小表 索引钉在数据缓存KEEP池中
内存上数据读取速度远远比硬盘中读取要快 据称 内存中数据读的速度是硬盘的 倍！如果资源比较丰富 把常用的小的 而且经常进行全表扫描的表给钉内存中 当然是在好不过了 可以简单的通过ALTER TABLE tablename CACHE来实现 在ORACLE i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP) 一般来说 可以考虑把 数据块之内的表放在keep池中 当然要根据内存大小等因素来定 关于如何查出那些表或索引符合条件 可以使用本文提供的access sql和access_report sql 这两个脚本是著名的Oracle专家 Burleson写的 你也可以在读懂了情况下根据实际情况调整一下脚本 对于索引 可以通过ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)来钉在KEEP池中
将表定在KEEP池中需要做一些准备工作 对于ORACLE i 需要设置DB_KEEP_CACHE_SIZE 对于 i 需要设置buffer_pool_keep 在 i中 还要修改db_block_lru_latches 该参数默认是 无法使用buffer_pool_keep 该参数应该比 * *CPU数量少 但是要大于 才能设置DB_KEEP_CACHE_BUFFER buffer_pool_keep从db_block_buffers中分配 因此也要小于db_block_buffers 设置好这些参数后 就可以把常用对象永久钉在内存里
五．设置optimizer_max_permutations
对于多表连接查询 如果采用基于成本优化(CBO) ORACLE会计算出很多种运行方案
从中选择出最优方案 这个参数就是设置oracle究竟从多少种方案来选择最优 如果设置太大 那么计算最优方案过程也是时间比较长的 Oracle 和 i默认是 建议改成 对于 i 已经默认是 了
六．调整排序参数
( ) SORT_AREA_SIZE:默认的用来排序的SORT_AREA_SIZE大小是 K 通常显得有点小 一般可以考虑设置成 M（ ） 这个参数不能设置过大 因为每个连接都要分配同样的排序内存
lishixinzhi/Article/program/Oracle/201311/18879
问 oracle进程内存占用一直增加 达到 G左右的时候就会连接失败 监听进程死掉 或者CPU达到 % 如何解决?
Peak Wong
Oracle性能调优一直是一个很有意思的命题 增强硬件配置是一种方法 但我们平时遇到的最多的问题是如何在没办法增强硬件配置的情况下 将数据库性能优化 这里给出一个思维流程 希望对各位有益
PATCH是否都打了 ORACLE系统内存参数是否太大 超出OS的MEMORY
查查是不是程序没有关闭连接导致连接数不断上升引起的 你是什么操作系统?
服务器都作了什么设置呢?比如sga的分配 是什么情况呢?
要进行调优 及参数设置
启动 Enterprise Management Console 以SYS/**** as SYSDBA身份进入系统
ORACLE i调优只涉及如下几个参数
a) processes = ;
b) open_links = ;
c)open_cursors = ;
d)sessions= ;
e) parallel_automatic_tuning=true
f) undo_retention=
g) undo_management=AUTO
请确保在 SPFILE 中保存 在Oracle i缺省的启动参数是spfile 不要用pfile文件启动数据库
物理内存大于 G以上的通用设置:
启动 Enterprise Management Console 以SYS/**** as SYSDBA身份进入系统
配置SGA和PGA大小方法如下
物理内存大于 G以上的通用设置
中文名 参数名 参数值 设置方法
SGA的最大大小 Sga_max_size M 例程 配置 内存项卡
日志缓冲区 Log_buffer 例程 配置 一般信息选项卡 所有初始化参数
大型池 Large_pool_size M 例程 配置 内存项卡
Java池 Java_pool_size M 例程 配置 一般信息选项卡 所有初始化参数
共享池 Shared_pool_size M 例程 配置 内存项卡
数据缓冲区高速缓存 Db_cache_size M 例程 配置 内存项卡
Keep池 Db_keep_cache_size M 例程 配置 一般信息选项卡 所有初始化参数
Pga自动管理 workarea_size_policy AUTO 例程 配置 一般信息选项卡 所有初始化参数
总计pga目标 pga_aggregate_target M 例程 配置 内存项卡
说明:
此内存设置不包含在数据库服务器上的其它应用程序的物理内存的大小 如果有其它的应用程序 可以参照下面的计算: sga_max_size+ pga_aggregate_target+应用程序物理内存+OS物理内存 = 系统物理内存* % 如果服务器上只有Oracle服务器 在 G以上物理内存的服务器上Oracle内存参数都可以参照上面的设置 如果服务器上有其它的应用 而服务器总的物理内存大于 请自己计算后再选择的方案
sga_max_size+ pga_aggregate_target = G 在 bit操作系统上有这个限制
lishixinzhi/Article/program/Oracle/201311/17386
Oracle性能优化基本方法包括一下几个步骤 包括
）设立合理的Oracle性能优化目标
）测量并记录当前的Oracle性能
）确定当前Oracle性能瓶颈（Oracle等待什么 哪些SQL语句是该等待事件的成分）
）把等待事件记入跟踪文件
）确定当前的OS瓶颈
）优化所需的成分（应用程序 数据库 I/O 争用 OS等）
）跟踪并实施更改控制过程
）测量并记录当前性能
）重复步骤 到 直到满足优化目标
下面来一一详述
设立合理的Oracle性能优化目标
重点 关于设立目标的最重要的一点是它们必须是可量化和可达到的
方法 目标必须是当前性能和所需性能的的陈述形式的语句
测量并记录当前Oracle性能重点
）需要在峰值活动时间获得当前系统性能快照
）关键是要在出现性能问题的时间段内采集信息
）必须在合理的时间段上采集 一般在峰值期间照几个为期 分钟的快照
确定当前Oracle性能瓶颈重点 从Oracle 等待接口v$system_event v$session_event和v$session_wait中获得等待事件 进而找出影响性能的对象和sql语句 方法如下
)首先 利用v$system_event视图执行下面的查询查看数据库中某些常见的等待事件
select * from v$system_event
where event in ( buffer busy waits
db file sequential read
db file scattered read
enqueue
free buffer waits
latch free
log file parallel write
log file sync );
)接着 利用下面对v$session_event和v$session视图进行的查询 研究具有对上面显示的内容有贡献的等待事件的会话
select se sid s username se event se total_waits se time_waited se average_wait
from v$session s v$session_event se
where s sid = se sid
and se event not like SQL*Net%
and s status = ACTIVE
and s username is not null;
)使用下面查询找到与所连接的会话有关的当前等待事件 这些信息是动态的 为了查看一个会话的等待最多的事件是什么 需要多次执行此查询
select sw sid s username sw event sw wait_time sw state sw seconds_in_wait SEC_IN_WAIT
from v$session s v$session_wait sw
where s sid = sw sid
and sw event not like SQL*Net%
and s username is not null
order by sw wait_time desc;
)查询会话等待事件的详细信息
select sid event p text p p text p p text p
from v$session_wait
where sid beeen and
and event not like %SQL%
and event not like %rdbms% ;
)利用P P 的信息 找出等待事件的相关的段
select owner segment_name segment_type tablespace_name
from dba_extents
where file_id = fileid_in
and blockid_in beeen block_id and block_id + blocks ;
)获得操作该段的sql语句
select sid getsqltxt(sql_hash_value sql_address)
from v$session
where sid = sid_in;
)getsqltxt函数
)至此已经找到影响性能的对象和sql语句 可以有针对性地优化
把等待事件记入跟踪文件
重点 如果在跟踪系统上的等待事件时 由于某种原因遇到了麻烦 则可以将这些等待事件记入一个跟踪文件 方法如下
)对于当前会话
alter session set timed_statistics=true;
alter session set max_dump_file_size=unlimited;
alter session set events trace name context forever level ;
)执行应用程序 然后在USER_DUMP_DEST指出的目录中找到跟踪文件
)查看文件中以词WAIT开始的所有行
)对于其它的会话
)确定会话的进程ID（SPID） 下面的查询识别出名称以A开始的所有用户的会话进程ID
select S Username P Spid from V$SESSION S V$PROCESS P
where S PADDR = P ADDR and S Username like A% ;
)以sysdba进入sqlplus执行
alter session set timed_statistics=true;
alter session set max_dump_file_size=unlimited;
oradebug setospid
oradebug unlimit
oradebug event trace name context forever level X /* Where X = ( ) */
)跟踪某个时间间隔得会话应用程序
)在USER_DUMP_DEST 的值指出的目录中利用SPID查看跟踪文件
)查看文件中以词WAIT开始的所有行
确定当前OS瓶颈 ）Windows NT上的监控
使用控制面板 〉管理工具 〉性能即可
）UNIX上的监控
使用通用性的工具 包括sar iostat cpustat mpstat netstat top osview等
．Oracle性能优化所需的成分（应用程序 数据库 I/O 争用 OS等）
．跟踪并实施更改控制过程
．测量并记录当前Oracle性能
lishixinzhi/Article/program/Oracle/201311/18709
在User Schema 上 用人工指定方式指定 Tmp 的tablespace 换句话说要人工定义一个tmp 的tablespace 给user schema ——为colm v这个user单独开一个临时表空间 个人认为调整之后效果不会有很明显的变化临时表空间的作用是当sql语句中出现order by group by（也就是需要排序的时候） 如果排序的数据比较少 就会在内存中排序 排序的数据量很大时 oracle会把排序的任务放在临时表空间中完成 内存中排序（逻辑排序）比在磁盘上排序（物理排序）理论上快 倍！所以临时表空间很大并不是一件好事情 说明sql中存在大量排序的动作 sql语句需要优化！ 所以深圳那里需要看一下临时表空间的大小！
当然johanna的意见也会有一定的作用 临时表空间独立出来之后 就不会和sys system等一系列oracle 内部使用临时表空间的操作产生资源竞争！
请检查SQL 使用到的where 条件是否均有定index 除此以外 检查使用到的where 条件最好以index 之顺序来写——这部分比较复杂 也是性能最关键的地方 几乎所有的oracle专家都认为 %以上的性能调整都和sql语句优化有关 需要check所有的sql语句where后面的条件是否有用到index的必要 工程量比较浩大！需要一个个小心谨慎的check！
把index 做一次 dbms_stats dbms stats 是oracle内部的api 可以对index table进行分析 收集统计信息 这样oracle优化器就会有一个最佳的选择 使性能达到最佳方法如下
SQLselect tt table_name tt num_rows tt blocks tt empty_blocks tt avg_row_len from dba_tables tt where tt owner= COLMTEST ; SQL select ttt index_name ttt num_rows ttt distinct_keys ttt avg_leaf_blocks_per_key ttt clustering_factor from dba_indexes ttt where ttt owner= COLMTEST ;
执行上述两条命令之后会发现除了table_name和index_name 其余列的统计信息都是不完全的
SQLexecute dbms_stats gather_schema_stats（ownname = COLMTEST cascade=true）
执行完dbms_stats 再调用上述两句语句 会发现所有的列基本上都已经被填充！
PS 执行统计比较慢 相当于所有table index都扫描一遍的时间 COLMTEST 改一下另外 对单个表执行统计分析的语句如下
EXECUTE dbms_stats gather_table_stats (ownname= citic tabname= col_cust_id estimate_percent= cascade=true)
做过以上处理之后 再看情形 再依情况放参数
——参数暂时不用调整！
建议做一个STATSPACK通过Statspack我们可以很容易的确定Oracle数据库的瓶颈所在 记录数据库性能状态 迅速了解数据库运行状况
方法如下
安装Statspack安装Statspack拥有SYSDBA（connect / as sysdba）权限的用户登陆 需要在本地安装或者通过telnet登陆到服务器 ——客户端登录不可以
必要条件 先创建名称为perfstat的表空间 至少 M
在那台oracle数据库上用colmv 登录SQL*PLUS 然后输入SQL connect sys/sys@（你们那里的sid） as sysdba SQL alter system set timed_statistics = true System altered——使用statspack收集统计信息时建议将该值设置为 TRUE 否则收集的统计信息大约只能起到 %的作用
SQL @C \oracle\ora \rdbms\admin\spcreate sql 输入 perfstat_password 的值 perfstat输入default_tablespace的值 perfstat输入temporary_tablespace 的值 temp
NOTE SPCPKG plete Please check spcpkg lis for any errors ——需要出现上述语句才算成功 否则请查看 lis文件并执行 进行重建SQL @C \oracle\ora \rdbms\admin\spdrop sql SQL @C \oracle\ora \rdbms\admin\spcreate sql
查看文件夹会产生三个文件C \oracle\ora \bin spcpkg lis spctab lis spcusr lis
——从下面开始都可以在客户端SQL_PLUS进行操作 手动执行STATSPACK收集统计信息SQL show user USER为 PERFSTAT SQL execute statspack snap ——快照
然后需要经过 个小时（跑批需要包含在里面） 再执行SQL execute statspack snap ——快照
最后生成STATSPACK调整报告
SQL @C:\oracle\ora \rdbms\admin\spreport sql;
Current Instance ~~~~~~~~~~~~~~~~ DB Id DB Name Inst Num Instance COLM colm Instances in this Statspack schema ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DB Id Inst Num DB Name Instance Host COLM colm STEVENHUANG Using for database Id Using for instance number Completed Snapshots Snap Snap Instance DB Name Id Snap Started Level Comment colm COLM 月 : 月 : Specify the Begin and End Snapshot Ids ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 输入 begin_snap 的值: 输入 end_snap 的值: End Snapshot Id specified: Specify the Report Name ~~~~~~~~~~~~~~~~~~~~~~~ The default report file name is sp_ _ To use this name press return to continue otherwise enter an alternative 输入 report_name 的值: report txt End of Report
查看产生的report 文档C \oracle\ora \bin\report txt
lishixinzhi/Article/program/Oracle/201311/17298
1、使用两边加‘%’号的查询，Oracle是不通过索引的，所以查询效率很低。
例如：select count(*) from lui_user_base t where t.user_name like '%cs%';
2、like '...%'和 like'%...'虽然走了索引，但是效率依然很低。
3、有人说使用如下sql，他的效率提高了10倍，但是数据量小的时候
select count(*) from lui_user_base where rowid in (select rowid from lui_user_base t where t.user_name like '%cs%')
我拿100w跳数据做了测试，效果一般，依然很慢，原因：
select rowid from lui_user_base t where t.user_name like '%cs%' 这条sql执行很快，那是相当的快，但是放到select count(*) from lui_user_base where rowid in（）里后，效率就会变的很慢了。
4、select count(*) from lui_user_base t where instr(t.user_name,'cs') 0
这种查询效果很好，速度很快，推荐使用这种。因为我对oracle内部机制不是很懂，只是对结果做了一个说明。
5、有人说了用全文索引，我看了，步骤挺麻烦，但是是个不错的方法，留着备用：
对cmng_custominfo 表中的address字段做全文检索：
1，在oracle9201中需要创建一个分词的东西：
BEGIN
ctx_ddl.create_preference ('SMS_ADDRESS_LEXER', 'CHINESE_LEXER');
--ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer'); 不用
end;
2，创建全文检索：
CREATE INDEX INX_CUSTOMINFO_ADDR_DOCS ON cmng_custominfo(address) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('LEXER SMS_ADDRESS_LEXER');
3，查询时候，使用：
select * from cmng_custominfo where contains (address, '金色新城')1;
4，需要定期进行同步和优化：
同步：根据新增记录的文本内容更新全文搜索的索引。
begin
ctx_ddl.sync_index('INX_CUSTOMINFO_ADDR_DOCS');
end;
优化：根据被删除记录清除全文搜索索引中的垃圾
begin
ctx_ddl.optimize_index('INX_CUSTOMINFO_ADDR_DOCS', 'FAST');
end;
5，采用job做步骤4中的工作：
1)该功能需要利用oracle的JOB功能来完成
因为oracle9I默认不启用JOB功能，所以首先需要增加ORACLE数据库实例的JOB配置参数:
job_queue_processes=5
重新启动oracle数据库服务和listener服务。
2)同步 和 优化
--同步 sync:
variable jobno number;
BEGIN
DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.sync_index(''INX_CUSTOMINFO_ADDR_DOCS'');',
SYSDATE, 'SYSDATE + (1/24/4)');
commit;
END;
--优化
variable jobno number;
begin
DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.optimize_index(''INX_CUSTOMINFO_ADDR_DOCS'',''FULL'');', SYSDATE, 'SYSDATE + 1');
commit;
END;
其中， 第一个job的SYSDATE + (1/24/4)是指每隔15分钟同步一次，第二个job的SYSDATE + 1是每隔1天做一次全优化。具体的时间间隔，可以根据应用的需要而定。
6，索引重建
重建索引会删除原来的索引，重新生成索引，需要较长的时间。
重建索引语法如下：
ALTER INDEX INX_CUSTOMINFO_ADDR_DOCS REBUILD;
据网上一些用家的体会，oracle重建索引的速度也是比较快的，有一用家这样描述：
Oracle 的全文检索建立和维护索引要比ms sql server都要快得多，笔者的65万记录的一个表建立索引只需要20分钟，同步一次只需要1分钟。
因此，也可以考虑用job的办法定期重建索引。
实际上 为了保证ORACLE数据库运行在最佳的性能状态下 在信息系统开发之前就应该考虑数据库的优化策略 优化策略一般包括服务器操作系统参数调整 ORACLE数据库参数调整 网络性能调整 应用程序SQL语句分析及设计等几个方面 其中应用程序的分析与设计是在信息系统开发之前完成的
分析评价ORACLE数据库性能主要有数据库吞吐量 数据库用户响应时间两项指标 数据库吞吐量是指单位时间内数据库完成的SQL语句数目 数据库用户响应时间是指用户从提交SQL语句开始到获得结果的那一段时间 数据库用户响应时间又可以分为系统服务时间和用户等待时间两项 即
数据库用户响应时间＝系统服务时间 ＋ 用户等待时间
上述公式告诉我们 获得满意的用户响应时间有两个途径 一是减少系统服务时间 即提高数据库的吞吐量 二是减少用户等待时间 即减少用户访问同一数据库资源的冲突率
性能优化包括如下几个部分
ORACLE数据库性能优化之一 调整数据结构的设计
这一部分在开发信息系统之前完成 程序员需要考虑是否使用ORACLE数据库的分区功能 对于经常访问的数据库表是否需要建立索引等
ORACLE数据库性能优化之二 调整应用程序结构设计
这一部分也是在开发信息系统之前完成 程序员在这一步需要考虑应用程序使用什么样的体系结构 是使用传统的Client/Server两层体系结构 还是使用Browser/Web/Database的三层体系结构 不同的应用程序体系结构要求的数据库资源是不同的
ORACLE数据库性能优化之三 调整数据库SQL语句
应用程序的执行最终将归结为数据库中的SQL语句执行 因此SQL语句的执行效率最终决定了ORACLE数据库的性能 ORACLE公司推荐使用ORACLE语句优化器（Oracle Optimizer）和行锁管理器（row level manager）来调整优化SQL语句
ORACLE数据库性能优化之四 调整服务器内存分配
内存分配是在信息系统运行过程中优化配置的 数据库管理员可以根据数据库运行状况调整数据库系统全局区（SGA区）的数据缓冲区 日志缓冲区和共享池的大小 还可以调整程序全局区（PGA区）的大小 需要注意的是 SGA区不是越大越好 SGA区过大会占用操作系统使用的内存而引起虚拟内存的页面交换 这样反而会降低系统
ORACLE数据库性能优化之五 调整硬盘I/O 这一步是在信息系统开发之前完成的
数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上 做到硬盘之间I/O负载均衡
ORACLE数据库性能优化之六 调整操作系统参数
例如 运行在UNIX操作系统上的ORACLE数据库 可以调整UNIX数据缓冲池的大小 每个进程所能使用的内存大小等参数
lishixinzhi/Article/program/Oracle/201311/17687
