Oracle学习总结（8）—— 面向程序员的数据库访问性能优化法则

2023-11-10 来源：花图问答

No batch

Batch=10

Batch=100

Batch=1000

Batch=10000

服务器事务处理时间

0.1

服务器IO处理时间

0.02

0.2

200

网络交互发起时间

0.1

网络数据传输时间

0.01

0.1

100

小计

0.23

0.5

3.2

30.2

300.2

平均每条记录处理时间

0.23

0.05

0.032

0.0302

0.03002

从上可以看出，Insert操作加大Batch可以对性能提高近8倍性能，一般根据主键的Update或Delete操作也可能提高2-3倍性能，但不如Insert明显，因为Update及Delete操作可能有比较大的开销在物理IO访问。以上仅是理论计算值，实际情况需要根据具体环境测量。

3.2、In List

很多时候我们需要按一些ID查询数据库记录，我们可以采用一个ID一个请求发给数据库，如下所示：

for :var in ids[] do begin

select * from mytable where id=:var;

end;

我们也可以做一个小的优化，如下所示，用ID INLIST的这种方式写SQL：

select * from mytable where id in(:id1,id2,...,idn);

通过这样处理可以大大减少SQL请求的数量，从而提高性能。那如果有10000个ID，那是不是全部放在一条SQL里处理呢？答案肯定是否定的。首先大部份数据库都会有SQL长度和IN里个数的限制，如ORACLE的IN里就不允许超过1000个值。

另外当前数据库一般都是采用基于成本的优化规则，当IN数量达到一定值时有可能改变SQL执行计划，从索引访问变成全表访问，这将使性能急剧变化。随着SQL中IN的里面的值个数增加，SQL的执行计划会更复杂，占用的内存将会变大，这将会增加服务器CPU及内存成本。

评估在IN里面一次放多少个值还需要考虑应用服务器本地内存的开销，有并发访问时要计算本地数据使用周期内的并发上限，否则可能会导致内存溢出。

综合考虑，一般IN里面的值个数超过20个以后性能基本没什么太大变化，也特别说明不要超过100，超过后可能会引起执行计划的不稳定性及增加数据库CPU及内存成本，这个需要专业DBA评估。

3.3、设置Fetch Size

当我们采用select从数据库查询数据时，数据默认并不是一条一条返回给客户端的，也不是一次全部返回客户端的，而是根据客户端fetch_size参数处理，每次只返回fetch_size条记录，当客户端游标遍历到尾部时再从服务端取数据，直到最后全部传送完成。所以如果我们要从服务端一次取大量数据时，可以加大fetch_size，这样可以减少结果数据传输的交互次数及服务器数据准备时间，提高性能。

以下是jdbc测试的代码，采用本地数据库，表缓存在数据库CACHE中，因此没有网络连接及磁盘IO开销，客户端只遍历游标，不做任何处理，这样更能体现fetch参数的影响：

String vsql ="select * from t_employee";

PreparedStatement pstmt = conn.prepareStatement(vsql,ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY);

pstmt.setFetchSize(1000);

ResultSet rs = pstmt.executeQuery(vsql);

int cnt = rs.getMetaData().getColumnCount();

Object o;

while (rs.next()) {

for (int i = 1; i <= cnt; i++) {

o = rs.getObject(i);

}

测试示例中的employee表有100000条记录，每条记录平均长度135字节

以下是测试结果，对每种fetchsize测试5次再取平均值：

fetchsize	elapse_time（s）
1	20.516
2	11.34
4	6.894
8	4.65
16	3.584
32	2.865
64	2.656
128	2.44
256	2.765
512	3.075
1024	2.862
2048	2.722
4096	2.681
8192	2.715

技术分享

Oracle jdbc fetchsize默认值为10，由上测试可以看出fetchsize对性能影响还是比较大的，但是当fetchsize大于100时就基本上没有影响了。fetchsize并不会存在一个最优的固定值，因为整体性能与记录集大小及硬件平台有关。根据测试结果建议当一次性要取大量数据时这个值设置为100左右，不要小于40。注意，fetchsize不能设置太大，如果一次取出的数据大于JVM的内存会导致内存溢出，所以建议不要超过1000，太大了也没什么性能提高，反而可能会增加内存溢出的危险。

注：图中fetchsize在128以后会有一些小的波动，这并不是测试误差，而是由于resultset填充到具体对像时间不同的原因，由于resultset已经到本地内存里了，所以估计是由于CPU的L1,L2 Cache命中率变化造成，由于变化不大，所以笔者也未深入分析原因。

iBatis的SqlMapping配置文件可以对每个SQL语句指定fetchsize大小，如下所示：

select * from employee

</select>

3.4、使用存储过程

大型数据库一般都支持存储过程，合理的利用存储过程也可以提高系统性能。如你有一个业务需要将A表的数据做一些加工然后更新到B表中，但是又不可能一条SQL完成，这时你需要如下3步操作：

a：将A表数据全部取出到客户端；

b：计算出要更新的数据；

c：将计算结果更新到B表。

如果采用存储过程你可以将整个业务逻辑封装在存储过程里，然后在客户端直接调用存储过程处理，这样可以减少网络交互的成本。

当然，存储过程也并不是十全十美，存储过程有以下缺点：

a、不可移植性，每种数据库的内部编程语法都不太相同，当你的系统需要兼容多种数据库时最好不要用存储过程。

b、学习成本高，DBA一般都擅长写存储过程，但并不是每个程序员都能写好存储过程，除非你的团队有较多的开发人员熟悉写存储过程，否则后期系统维护会产生问题。

c、业务逻辑多处存在，采用存储过程后也就意味着你的系统有一些业务逻辑不是在应用程序里处理，这种架构会增加一些系统维护和调试成本。

d、存储过程和常用应用程序语言不一样，它支持的函数及语法有可能不能满足需求，有些逻辑就只能通过应用程序处理。

e、如果存储过程中有复杂运算的话，会增加一些数据库服务端的处理成本，对于集中式数据库可能会导致系统可扩展性问题。

f、为了提高性能，数据库会把存储过程代码编译成中间运行代码(类似于java的class文件)，所以更像静态语言。当存储过程引用的对像(表、视图等等)结构改变后，存储过程需要重新编译才能生效，在24*7高并发应用场景，一般都是在线变更结构的，所以在变更的瞬间要同时编译存储过程，这可能会导致数据库瞬间压力上升引起故障(Oracle数据库就存在这样的问题)。

个人观点：普通业务逻辑尽量不要使用存储过程，定时性的ETL任务或报表统计函数可以根据团队资源情况采用存储过程处理。

3.5、优化业务逻辑

要通过优化业务逻辑来提高性能是比较困难的，这需要程序员对所访问的数据及业务流程非常清楚。

举一个案例：

某移动公司推出优惠套参，活动对像为VIP会员并且2010年1，2，3月平均话费20元以上的客户。

那我们的检测逻辑为：

select avg(money) as avg_money from bill where phone_no=‘13988888888‘ and date between ‘201001‘ and ‘201003‘;

select vip_flag from member where phone_no=‘13988888888‘;

if avg_money>20 and vip_flag=true then

begin

执行套参();

end;

如果我们修改业务逻辑为:

select avg(money) as avg_money from bill where phone_no=‘13988888888‘ and date between ‘201001‘ and ‘201003‘;

if avg_money>20 then

begin

select vip_flag from member where phone_no=‘13988888888‘;

if vip_flag=true then

begin

执行套参();

end;

通过这样可以减少一些判断vip_flag的开销，平均话费20元以下的用户就不需要再检测是否VIP了。

如果程序员分析业务，VIP会员比例为1%，平均话费20元以上的用户比例为90%，那我们改成如下：

select vip_flag from member where phone_no=‘13988888888‘;

if vip_flag=true then

begin

select avg(money) as avg_money from bill where phone_no=‘13988888888‘ and date between ‘201001‘ and ‘201003‘;

if avg_money>20 then

begin

执行套参();

end;

这样就只有1%的VIP会员才会做检测平均话费，最终大大减少了SQL的交互次数。

以上只是一个简单的示例，实际的业务总是比这复杂得多，所以一般只是高级程序员更容易做出优化的逻辑，但是我们需要有这样一种成本优化的意识。

3.6、使用ResultSet游标处理记录

现在大部分Java框架都是通过jdbc从数据库取出数据，然后装载到一个list里再处理，list里可能是业务Object，也可能是hashmap。

由于JVM内存一般都小于4G，所以不可能一次通过sql把大量数据装载到list里。为了完成功能，很多程序员喜欢采用分页的方法处理，如一次从数据库取1000条记录，通过多次循环搞定，保证不会引起JVM Out of memory问题。

以下是实现此功能的代码示例，t_employee表有10万条记录，设置分页大小为1000：

d1 = Calendar.getInstance().getTime();

vsql = "select count(*) cnt from t_employee";

pstmt = conn.prepareStatement(vsql);

ResultSet rs = pstmt.executeQuery();

Integer cnt = 0;

while (rs.next()) {

cnt = rs.getInt("cnt");

}

Integer lastid=0;

Integer pagesize=1000;

System.out.println("cnt:" + cnt);

String vsql = "select count(*) cnt from t_employee";

PreparedStatement pstmt = conn.prepareStatement(vsql);

ResultSet rs = pstmt.executeQuery();

Integer cnt = 0;

while (rs.next()) {

cnt = rs.getInt("cnt");

}

Integer lastid = 0;

Integer pagesize = 1000;

System.out.println("cnt:" + cnt);

for (int i = 0; i <= cnt / pagesize; i++) {

vsql = "select * from (select * from t_employee where id>? order by id) where rownum<=?";

pstmt = conn.prepareStatement(vsql);

pstmt.setFetchSize(1000);

pstmt.setInt(1, lastid);

pstmt.setInt(2, pagesize);

rs = pstmt.executeQuery();

int col_cnt = rs.getMetaData().getColumnCount();

Object o;

while (rs.next()) {

for (int j = 1; j <= col_cnt; j++) {

o = rs.getObject(j);

}

lastid = rs.getInt("id");

}

rs.close();

pstmt.close();

}

以上代码实际执行时间为6.516秒

很多持久层框架为了尽量让程序员使用方便，封装了jdbc通过statement执行数据返回到resultset的细节，导致程序员会想采用分页的方式处理问题。实际上如果我们采用jdbc原始的resultset游标处理记录，在resultset循环读取的过程中处理记录，这样就可以一次从数据库取出所有记录。显著提高性能。

这里需要注意的是，采用resultset游标处理记录时，应该将游标的打开方式设置为FORWARD_READONLY模式(ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY)，否则会把结果缓存在JVM里，造成JVM Out of memory问题。

代码示例：

String vsql ="select * from t_employee";

PreparedStatement pstmt = conn.prepareStatement(vsql,ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY);

pstmt.setFetchSize(100);

ResultSet rs = pstmt.executeQuery(vsql);

int col_cnt = rs.getMetaData().getColumnCount();

Object o;

while (rs.next()) {

for (int j = 1; j <= col_cnt; j++) {

o = rs.getObject(j);

}

调整后的代码实际执行时间为3.156秒

从测试结果可以看出性能提高了1倍多，如果采用分页模式数据库每次还需发生磁盘IO的话那性能可以提高更多。

iBatis等持久层框架考虑到会有这种需求，所以也有相应的解决方案，在iBatis里我们不能采用queryForList的方法，而应用该采用queryWithRowHandler加回调事件的方式处理，如下所示：

MyRowHandler myrh=new MyRowHandler();

sqlmap.queryWithRowHandler("getAllEmployee", myrh);

class MyRowHandler implements RowHandler {

public void handleRow(Object o) {

//todo something

}

iBatis的queryWithRowHandler很好的封装了resultset遍历的事件处理，效果及性能与resultset遍历一样，也不会产生JVM内存溢出。

4、减少数据库服务器CPU运算4.1、使用绑定变量

绑定变量是指SQL中对变化的值采用变量参数的形式提交，而不是在SQL中直接拼写对应的值。

非绑定变量写法：Select * from employee where id=1234567

绑定变量写法：

Select * from employee where id=?

Preparestatement.setInt(1,1234567)

Java中Preparestatement就是为处理绑定变量提供的对像，绑定变量有以下优点：

1、防止SQL注入

2、提高SQL可读性

3、提高SQL解析性能，不使用绑定变更我们一般称为硬解析，使用绑定变量我们称为软解析。

第1和第2点很好理解，做编码的人应该都清楚，这里不详细说明。关于第3点，到底能提高多少性能呢，下面举一个例子说明：

假设有这个这样的一个数据库主机：

2个4核CPU

100块磁盘，每个磁盘支持IOPS为160

业务应用的SQL如下：

select * from table where pk=?

这个SQL平均4个IO（3个索引IO+1个数据IO）

IO缓存命中率75%（索引全在内存中，数据需要访问磁盘）

SQL硬解析CPU消耗：1ms （常用经验值）

SQL软解析CPU消耗：0.02ms（常用经验值）

假设CPU每核性能是线性增长，访问内存Cache中的IO时间忽略，要求计算系统对如上应用采用硬解析与采用软解析支持的每秒最大并发数：

是否使用绑定变量	CPU支持最大并发数	磁盘IO支持最大并发数
不使用	241000=8000	100*160=16000
使用	241000/0.02=400000	100*160=16000

从以上计算可以看出，不使用绑定变量的系统当并发达到8000时会在CPU上产生瓶颈，当使用绑定变量的系统当并行达到16000时会在磁盘IO上产生瓶颈。所以如果你的系统CPU有瓶颈时请先检查是否存在大量的硬解析操作。

使用绑定变量为何会提高SQL解析性能，这个需要从数据库SQL执行原理说明，一条SQL在Oracle数据库中的执行过程如下图所示：

技术分享

当一条SQL发送给数据库服务器后，系统首先会将SQL字符串进行hash运算，得到hash值后再从服务器内存里的SQL缓存区中进行检索，如果有相同的SQL字符，并且确认是同一逻辑的SQL语句，则从共享池缓存中取出SQL对应的执行计划，根据执行计划读取数据并返回结果给客户端。

如果在共享池中未发现相同的SQL则根据SQL逻辑生成一条新的执行计划并保存在SQL缓存区中，然后根据执行计划读取数据并返回结果给客户端。

为了更快的检索SQL是否在缓存区中，首先进行的是SQL字符串hash值对比，如果未找到则认为没有缓存，如果存在再进行下一步的准确对比，所以要命中SQL缓存区应保证SQL字符是完全一致，中间有大小写或空格都会认为是不同的SQL。

如果我们不采用绑定变量，采用字符串拼接的模式生成SQL,那么每条SQL都会产生执行计划，这样会导致共享池耗尽，缓存命中率也很低。

一些不使用绑定变量的场景：

a、数据仓库应用，这种应用一般并发不高，但是每个SQL执行时间很长，SQL解析的时间相比SQL执行时间比较小，绑定变量对性能提高不明显。数据仓库一般都是内部分析应用，所以也不太会发生SQL注入的安全问题。

b、数据分布不均匀的特殊逻辑，如产品表，记录有1亿，有一产品状态字段，上面建有索引，有审核中，审核通过，审核未通过3种状态，其中审核通过9500万，审核中1万，审核不通过499万。

要做这样一个查询：

select count(*) from product where status=?

采用绑定变量的话，那么只会有一个执行计划，如果走索引访问，那么对于审核中查询很快，对审核通过和审核不通过会很慢；如果不走索引，那么对于审核中与审核通过和审核不通过时间基本一样；

对于这种情况应该不使用绑定变量，而直接采用字符拼接的方式生成SQL，这样可以为每个SQL生成不同的执行计划，如下所示。

select count(*) from product where status=‘approved‘; //不使用索引

select count(*) from product where status=‘tbd‘; //不使用索引

select count(*) from product where status=‘auditing‘;//使用索引

4.2、合理使用排序

Oracle的排序算法一直在优化，但是总体时间复杂度约等于nLog(n)。普通OLTP系统排序操作一般都是在内存里进行的，对于数据库来说是一种CPU的消耗，曾在PC机做过测试，单核普通CPU在1秒钟可以完成100万条记录的全内存排序操作，所以说由于现在CPU的性能增强，对于普通的几十条或上百条记录排序对系统的影响也不会很大。但是当你的记录集增加到上万条以上时，你需要注意是否一定要这么做了，大记录集排序不仅增加了CPU开销，而且可能会由于内存不足发生硬盘排序的现象，当发生硬盘排序时性能会急剧下降，这种需求需要与DBA沟通再决定，取决于你的需求和数据，所以只有你自己最清楚，而不要被别人说排序很慢就吓倒。

以下列出了可能会发生排序操作的SQL语法：

Order by

Group by

Distinct

Exists子查询

Not Exists子查询

In子查询

Not In子查询

Union（并集），Union All也是一种并集操作，但是不会发生排序，如果你确认两个数据集不需要执行去除重复数据操作，那请使用Union All 代替Union。

Minus（差集）

Intersect（交集）

Create Index

Merge Join，这是一种两个表连接的内部算法，执行时会把两个表先排序好再连接，应用于两个大表连接的操作。如果你的两个表连接的条件都是等值运算，那可以采用Hash Join来提高性能，因为Hash Join使用Hash 运算来代替排序的操作。具体原理及设置参考SQL执行计划优化专题。

4.3、减少比较操作

我们SQL的业务逻辑经常会包含一些比较操作，如a=b，a<b之类的操作，对于这些比较操作数据库都体现得很好，但是如果有以下操作，我们需要保持警惕：

Like模糊查询，如下所示：

a like ‘%abc%’

Like模糊查询对于数据库来说不是很擅长，特别是你需要模糊检查的记录有上万条以上时，性能比较糟糕，这种情况一般可以采用专用Search或者采用全文索引方案来提高性能。

不能使用索引定位的大量In List，如下所示：

a in (:1,:2,:3,…,:n) ----n>20

如果这里的a字段不能通过索引比较，那数据库会将字段与in里面的每个值都进行比较运算，如果记录数有上万以上，会明显感觉到SQL的CPU开销加大，这个情况有两种解决方式：

a、将in列表里面的数据放入一张中间小表，采用两个表Hash Join关联的方式处理；

b、采用str2varList方法将字段串列表转换一个临时表处理，关于str2varList方法可以在网上直接查询，这里不详细介绍。

以上两种解决方案都需要与中间表Hash Join的方式才能提高性能，如果采用了Nested Loop的连接方式性能会更差。

如果发现我们的系统IO没问题但是CPU负载很高，就有可能是上面的原因，这种情况不太常见，如果遇到了最好能和DBA沟通并确认准确的原因。

4.4、大量复杂运算在客户端处理

什么是复杂运算，一般我认为是一秒钟CPU只能做10万次以内的运算。如含小数的对数及指数运算、三角函数、3DES及BASE64数据加密算法等等。

如果有大量这类函数运算，尽量放在客户端处理，一般CPU每秒中也只能处理1万-10万次这样的函数运算，放在数据库内不利于高并发处理。

5、利用更多的资源5.1、客户端多进程并行访问

多进程并行访问是指在客户端创建多个进程(线程)，每个进程建立一个与数据库的连接，然后同时向数据库提交访问请求。当数据库主机资源有空闲时，我们可以采用客户端多进程并行访问的方法来提高性能。如果数据库主机已经很忙时，采用多进程并行访问性能不会提高，反而可能会更慢。所以使用这种方式最好与DBA或系统管理员进行沟通后再决定是否采用。

例如：

我们有10000个产品ID，现在需要根据ID取出产品的详细信息，如果单线程访问，按每个IO要5ms计算，忽略主机CPU运算及网络传输时间，我们需要50s才能完成任务。如果采用5个并行访问，每个进程访问2000个ID，那么10s就有可能完成任务。

那是不是并行数越多越好呢，开1000个并行是否只要50ms就搞定，答案肯定是否定的，当并行数超过服务器主机资源的上限时性能就不会再提高，如果再增加反而会增加主机的进程间调度成本和进程冲突机率。

以下是一些如何设置并行数的基本建议：

如果瓶颈在服务器主机，但是主机还有空闲资源，那么最大并行数取主机CPU核数和主机提供数据服务的磁盘数两个参数中的最小值，同时要保证主机有资源做其它任务。

如果瓶颈在客户端处理，但是客户端还有空闲资源，那建议不要增加SQL的并行，而是用一个进程取回数据后在客户端起多个进程处理即可，进程数根据客户端CPU核数计算。

如果瓶颈在客户端网络，那建议做数据压缩或者增加多个客户端，采用map reduce的架构处理。

如果瓶颈在服务器网络，那需要增加服务器的网络带宽或者在服务端将数据压缩后再处理了。

5.2、数据库并行处理

数据库并行处理是指客户端一条SQL的请求，数据库内部自动分解成多个进程并行处理，如下图所示：

技术分享

并不是所有的SQL都可以使用并行处理，一般只有对表或索引进行全部访问时才可以使用并行。数据库表默认是不打开并行访问，所以需要指定SQL并行的提示，如下所示：

select /*+parallel(a,4)*/ * from employee;

并行的优点：

使用多进程处理，充分利用数据库主机资源（CPU,IO），提高性能。

并行的缺点：

1、单个会话占用大量资源，影响其它会话，所以只适合在主机负载低时期使用；

2、只能采用直接IO访问，不能利用缓存数据，所以执行前会触发将脏缓存数据写入磁盘操作。

注：

1、并行处理在OLTP类系统中慎用，使用不当会导致一个会话把主机资源全部占用，而正常事务得不到及时响应，所以一般只是用于数据仓库平台。

2、一般对于百万级记录以下的小表采用并行访问性能并不能提高，反而可能会让性能更差。

Oracle学习总结（8）—— 面向程序员的数据库访问性能优化法则

标签：

小编还为您整理了以下内容，可能对您也有帮助：

如何优化ORACLE数据库性能

调整数据结构、应用程序结构和SQL语句是优化ORACLE数据库性能的关键。本文将从这三个方面入手，为读者提供优化ORACLE数据库性能的实用方法。

🏗️调整数据结构的设计

在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。

📐调整应用程序结构设计

在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。

🔍调整数据库SQL语句

应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器（Oracle Optimizer）和行锁管理器（row-level manager）来调整优化SQL语句。

Oracle数据库系统调优方法

Oracle 数据库广泛应用在社会的各个领域，特别是在Client/Server模式的应用，但是应用开发者往往碰到整个系统的性能随着数据量的增大显着下降的问题，为了解决这个问题，从以下几个方面：数据库服务器、网络I/O、应用程序等对整个系统加以调整，充分发挥Oracle的效能，提高整个系统的性能。
1 调整数据库服务器的性能
Oracle数据库服务器是整个系统的核心，它的性能高低直接影响整个系统的性能，为了调整Oracle数据库服务器的性能，主要从以下几个方面考虑：
1.1 调整
操作系统以适合Oracle数据库服务器运行
Oracle数据库服务器很大程度上依赖于运行服务器的操作系统，如果操作系统不能提供最好性能，那么无论如何调整，Oracle数据库服务器也无法发挥其应有的性能。
1.1.1 为Oracle数据库服务器规划系统资源
据已有计算机可用资源，规划分配给Oracle服务器资源原则是：尽可能使Oracle服务器使用资源最大化，特别在Client/Server中尽量让服务器上所有资源都来运行Oracle服务。
1.1.2 调整计算机系统中的内存配置
多数操作系统都用虚存来模拟计算机上更大的内存，它实际上是硬盘上的一定的磁盘空间。当实际的内存空间不能满足应用软件的要求时，操作系统就将用这部分的磁盘空间对内存中的信息进行页面替换，这将引起大量的磁盘I/O操作，使整个服务器的性能下降。为了避免过多地使用虚存，应加大计算机的内存。
1.1.3 为Oracle数据库服务器设置操作系统进程优先级
不要在操作系统中调整Oracle进程的优先级，因为在Oracle数据库系统中，所有的后台和前台数据库服务器进程执行的是同等重要的工作，需要同等的优先级。所以在安装时，让所有的数据库服务器进程都使用缺省的优先级运行。
1.2 调整内存分配
Oracle数据库服务器保留3个基本的内存高速缓存，分别对应3种不同类型的数据：库高速缓存，字典高速缓存和缓冲区高速缓存。库高速缓存和字典高速缓存一起构成共享池，共享池再加上缓冲区高速缓存便构成了系统全程区（SGA）。SGA是对数据库数据进行快速访问的一个系统全程区，若SGA本身需要频繁地进行释放、分配，则不能达到快速访问数据的目的，因此应把SGA放在主存中，不要放在虚拟内存中。内存的调整主要是指调整组成SGA的内存结构的大小来提高系统性能，由于Oracle数据库服务器的内存结构需求与应用密切相关，所以内存结构的调整应在磁盘I/O调整之前进行。
1.2.1 库缓冲区的调整
库缓冲区中包含私用和共享SQL和PL/SQL区，通过比较库缓冲区的命中率决定它的大小。要调整库缓冲区，必须首先了解该库缓冲区的活动情况，库缓冲区的活动统计信息保留在动态性能表v$librarycache数据字典中，可通过查询该表来了解其活动情况，以决定如何调整。
1.2.2 数据字典缓冲区的调整
数据字典缓冲区包含了有关数据库的结构、用户、实体信息。数据字典的命中率，对系统性能影响极大。数据字典缓冲区的使用情况记录在动态性能表v$librarycache中，可通过查询该表来了解其活动情况，以决定如何调整。
1.2.3 缓冲区高速缓存的调整
用户进程所存取的所有数据都是经过缓冲区高速缓存来存取，所以该部分的命中率，对性能至关重要。缓冲区高速缓存的使用情况记录在动态性能表v$sysstat中，可通过查询该表来了解其活动情况，以决定如何调整。
2 调整 Client/Server 模式下的网络 I/O
Client/Server环境中的应用处理是分布在客户应用程序和数据库服务程序之间的。在 Client/Server环境中Client与Server之间的网络I/O是整个系统性能提高的瓶颈，一个客户应用程序引起的网络I/O越少，应用及整个系统的性能越好。减少网络I/O的最重要的一条原则：将应用逻辑集中在数据库服务器中。
2.1 使用Oracle数据库的完整约束性
当为应用建表时，应当为一些有特殊要求的数据加上适当的完整性约束，这样就能实现由数据库本身而不是应用程序来约束数据符合一定的条件。数据库服务器端的完整约束的执行操作是在比SQL语句级别更低的系统机制上优化，它与客户端无关，只在服务器中运行，不需在Client 端和Server端之间传递SQL语句，有效地减轻网络I/O负担。
2.2 使用数据库触发器
完整约束性只能实现一些较简单的数据约束条件，对一些较复杂的事物处理规则就*为力，这时最好不要在应用程序中实施复杂的程序控制，而是应当采用数据库触发器来实施复杂的事物规则。数据库触发器能实现由数据库本身，而不是应用程序，来约束数据符合复杂的事物处理规则，并且容易创建，便于管理，避免大量的网络I/O。
2.3 使用存储过程、存储函数和包
Oracle的存储过程和存储函数是命名的能完成一定功能并且存储在Server端的PL/SQL的集合。包是一种把有关的过程和函数组织封装成一个数据库程序单元的方法。它们相对于应用程序的过程、函数而言，把SQL命令存储在Server端。使用存储过程和存储函数，应用程序不必再包含多个网络操作的SQL语句去执行数据库服务器操作，而是简单调用存储过程和存储函数，在网络上传输的只是调用过程的名字和输出结果，这样就可减少大量的网络I/O。
3 应用程序的调整
3.1 SQL语句的优化
SQL语句的执行速度，可以受很多因素的影响而变化。但主要的影响因素是：驱动表、执行操作的先后顺序和索引的运用。可以由很多不同的方法间接地改变这些因素，以达到最优的执行速度。这里主要探讨当对多个表进行连接查询时应遵循的优化原则：
3.2 建立和使用视图、索引
利用视图可以将基表中的列或行进行裁减、隐藏一部分数据，并且能够将涉及到多个表的复杂查询以视图的方式给出，使应用程序开发简洁快速。利用索引可以提高查询性能，减少磁盘 I/O，优化对数据表的查询，加速SQL语句的执行。但任何时候建立索引都能提高性能，何时建立索引应当遵循以下原则：该表常用来在索引列上查询，该表不常更新、插入、删除等操作，查询出来的结果记录数应控制在原表的2%～4%。
3.3 使用 Oracle 的数组接口
当一个客户应用程序插入一行或用一个查询来向服务器请求某行时，不是发送具有单个行的网络包，而是采用数组处理，即把要插入的多个行或检索出的多个行缓冲在数组中，然后通过很少的几个包就可在网上传送这些数组。例如，一个给定的Select语句返回2000行数据，每行平均大小为40个字节，数据包的大小为4kB，而数组大小参数（arraysize）设置为20 ，则需从服务器发送100个数据包到客户机。如果简单地把（arraysize）设置为2000，那么同样的操作只需要传送 20个数据包。这样就减少了网络的传输量，提高了所有应用的性能。
4 总结
我们在开发应用程序时，遵循上述的方法和原则，对系统进行调整，收到了令人满意的效果。但是应当指出，由于客户机、网络、服务器这3个相互依存的组成部分都必须调整和同步才能产生最佳的性能，因此还应根据系统的具体情况，具体分析和调整。

Oracle数据库系统调优方法

Oracle数据库系统性能优化策略

一个数据库系统的生命周期可以分成设计开发和成品三个阶段在设计阶段进行数据库性能优化的成本最低收益最大在成品阶段进行数据库性能优化的成本最高收益最小数据库的优化可以通过对网络硬件操作系统数据库参数和应用程序的优化来进行最常见的优化手段就是对硬件的升级据统计对网络硬件操作系统数据库参数进行优化所获得的性能提升全部加起来只占数据库系统性能提升的 %左右其余的 %系统性能提升来自对应用程序的优化许多优化专家认为对应用程序的优化可以得到 %的系统性能的提升

一数据库性能的优化

数据库设计是应用程序设计的基础其性能直接影响应用程序的性能数据库性能包括存储空间需求量的大小和查询响应时间的长短两个方面为了优化数据库性能需要对数据库中的表进行规范化规范化的范式可分为第一范式第二范式第三范式 BCNF范式第四范式和第五范式一般来说逻辑数据库设计会满足规范化的前级标准但由于满足第三范式的表结构容易维护且基本满足实际应用的要求因此实际应用中一般都按照第三范式的标准进行规范化但是规范化也有缺点由于将一个表拆分成为多个表在查询时需要多表连接降低了查询速度

由于规范化有可能导致查询速度慢的缺点考虑到一些应用需要较快的响应速度在设计表时应同时考虑对某些表进行反规范化反规范化可以采用以下几种方法

分割表

分割表包括水平分割和垂直分割

水平分割是按照行将一个表分割为多个表这可以提高每个表的查询速度但查询更新时要选择不同的表统计时要汇总多个表因此应用程序会更复杂

垂直分割是对于一个列很多的表若某些列的访问频率远远高于其它列就可以将主键和这些列作为一个表将主键和其它列作为另外一个表通过减少列的宽度增加了每个数据页的行数一次I/O就可以扫描更多的行从而提高了访问每一个表的速度但是由于造成了多表连接所以应该在同时查询或更新不同分割表中的列的情况比较少的情况下使用

保留冗余列

当两个或多个表在查询中经常需要连接时可以在其中一个表上增加若干冗余的列以避免表之间的连接过于频繁由于对冗余列的更新操作必须对多个表同步进行所以一般在冗余列的数据不经常变动的情况下使用

增加派生列

派生列是由表中的其它多个列计算所得增加派生列可以减少统计运算在数据汇总时可以大大缩短运算时间

二应用程序性能的优化

应用程序的优化通常可分为两个方面源代码和SQL语句由于涉及到对程序逻辑的改变源代码的优化在时间成本和风险上代价很高而对数据库系统性能的提升收效有限因此应用程序的优化应着重在SQL语句的优化对于海量数据劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍可见对于一个系统不是简单地能实现其功能就行而是要写出高质量的SQL语句提高系统的可用性

下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍在这些where子句中即使某些列存在索引但是由于编写了劣质的SQL 系统在运行该SQL语句时也不能使用该索引而同样使用全表扫描这就造成了响应速度的极大降低

IS NULL 与 IS NOT NULL

不能用null作索引任何包含null值的列都将不会被包含在索引中即使索引有多列的情况下只要这些列中有一列含有null 该列就会从索引中排除也就是说如果某列存在空值即使对该列建索引也不会提高性能

任何在where子句中使用is null或is not null的语句优化器是不允许使用索引的

联接列

对于有联接的列即使最后的联接值为一个静态值优化器不会使用索引的例如假定有一个职工表（employee）对于一个职工的姓和名分成两列存放（FIRST_NAME和LAST_NAME）现在要查询一个叫乔治？布什（Gee Bush）的职工下面是一个采用联接查询的SQL语句

select * from employee where first_name|| ||last_name = Gee Bush

上面这条语句完全可以查询出是否有Gee Bush这个员工但是这里需要注意系统优化器对基于last_name创建的索引没有使用

当采用下面这种SQL语句的编写 Oracle系统就可以采用基于last_name创建的索引

Select * From employee where first_name = Gee and last_name = Bush

遇到下面这种情况又如何处理呢？如果一个变量（name）中存放著Gee Bush这个员工的姓名对于这种情况我们又如何避免全程遍历使用索引呢？可以使用一个函数将变量name中的姓和名分开就可以了但是有一点需要注意这个函数是不能作用在索引列上下面是SQL查询脚本

select * from employee where first_name = SUBSTR（ &&name INSTR（ &&name ））

and last_name = SUBSTR（ &&name INSTR（ &&name ）+ ）

带通配符（%）的like语句

同样以上面的例子来看这种情况目前的需求是这样的要求在职工表中查询名字中包含Bush的人可以采用如下的查询SQL语句

select * from employee where last_name like %Bush%

这里由于通配符（%）在搜寻词首出现所以Oracle系统不使用last_name的索引在很多情况下可能无法避免这种情况但是一定要心中有底通配符如此使用会降低查询速度然而当通配符出现在字符串其他位置时优化器就能利用索引例如在下面的查询中索引得到了使用

select * from employee where last_name like c%

Order by语句

Order by语句决定了Oracle如何将返回的查询结果排序 Order by语句对要排序的列没有什么特别的* 也可以将函数加入列中（象联接或者附加等）任何在Order by语句的非索引项或者有计算表达式都将降低查询速度

仔细检查order by语句以找出非索引项或者表达式它们会降低性能解决这个问题的办法就是重写order by语句以使用索引也可以为所使用的列建立另外一个索引同时应绝对避免在order by子句中使用表达式

NOT

我们在查询时经常在where子句使用一些逻辑表达式如大于小于等于以及不等于等等也可以使用and（与） or（或）以及not（非） NOT可用来对任何逻辑运算符号取反下面是一个NOT子句的例子

…… where not （status = VALID ）

如果要使用NOT 则应在取反的短语前面加上括号并在短语前面加上NOT运算符 NOT运算符包含在另外一个逻辑运算符中这就是不等于（<>）运算符换句话说即使不在查询where子句中显式地加入NOT词 NOT仍在运算符中见下例

…… where status <> INVALID

再看下面这个例子

select * from employee where　salary<>

对这个查询可以改写为不使用NOT的语句

select * from employee where　salary< or salary>

虽然这两种查询的结果一样但是第二种查询方案会比第一种查询方案更快些第二种查询允许Oracle对salary列使用索引而第一种查询则不能使用索引

IN和EXISTS

有时候会将一列和一系列值相比较最简单的办法就是在where子句中使用子查询在where子句中可以使用两种格式的子查询

第一种格式是使用IN操作符 …… where column in（select * from …… where ……）

第二种格式是使用EXIST操作符 …… where exists （select X from ……where ……）

绝大多数人会使用第一种格式因为它比较容易编写而实际上第二种格式要远比第一种格式的效率高在Oracle中可以将几乎所有的IN操作符子查询改写为使用EXISTS的子查询

第二种格式中子查询以 select X 开始运用EXISTS子句不管子查询从表中抽取什么数据它只查看where子句这样优化器就不必遍历整个表而仅根据索引就可完成工作（这里假定在where语句中使用的列存在索引）相对于IN子句来说 EXISTS使用相连子查询构造起来要比IN子查询困难一些

通过使用EXISTS Oracle系统会首先检查主查询然后运行子查询直到找到第一个匹配项这就节省了时间 Oracle系统在执行IN子查询时首先执行子查询并将获得的结果列表存放在一个加了索引的临时表中在执行子查询之前系统先将主查询挂起待子查询执行完毕存放在临时表中以后再执行主查询这也就是使用EXISTS比使用IN通常查询速度快的原因

同时应尽可能使用NOT EXISTS来代替NOT IN 尽管二者都使用了NOT（不能使用索引而降低速度）但NOT EXISTS要比NOT IN查询效率更高

lishixin/Article/program/Oracle/201311/17060

Oracle数据库系统性能优化策略

一数据库性能的优化

分割表

分割表包括水平分割和垂直分割

水平分割是按照行将一个表分割为多个表这可以提高每个表的查询速度但查询更新时要选择不同的表统计时要汇总多个表因此应用程序会更复杂

保留冗余列

增加派生列

派生列是由表中的其它多个列计算所得增加派生列可以减少统计运算在数据汇总时可以大大缩短运算时间

二应用程序性能的优化

IS NULL 与 IS NOT NULL

任何在where子句中使用is null或is not null的语句优化器是不允许使用索引的

联接列

select * from employee where first_name|| ||last_name = Gee Bush

上面这条语句完全可以查询出是否有Gee Bush这个员工但是这里需要注意系统优化器对基于last_name创建的索引没有使用

当采用下面这种SQL语句的编写 Oracle系统就可以采用基于last_name创建的索引

Select * From employee where first_name = Gee and last_name = Bush

select * from employee where first_name = SUBSTR（ &&name INSTR（ &&name ））

and last_name = SUBSTR（ &&name INSTR（ &&name ）+ ）

带通配符（%）的like语句

同样以上面的例子来看这种情况目前的需求是这样的要求在职工表中查询名字中包含Bush的人可以采用如下的查询SQL语句

select * from employee where last_name like %Bush%

select * from employee where last_name like c%

Order by语句

NOT

…… where not （status = VALID ）

…… where status <> INVALID

再看下面这个例子

select * from employee where　salary<>

对这个查询可以改写为不使用NOT的语句

select * from employee where　salary< or salary>

虽然这两种查询的结果一样但是第二种查询方案会比第一种查询方案更快些第二种查询允许Oracle对salary列使用索引而第一种查询则不能使用索引

IN和EXISTS

有时候会将一列和一系列值相比较最简单的办法就是在where子句中使用子查询在where子句中可以使用两种格式的子查询

第一种格式是使用IN操作符 …… where column in（select * from …… where ……）

第二种格式是使用EXIST操作符 …… where exists （select X from ……where ……）

同时应尽可能使用NOT EXISTS来代替NOT IN 尽管二者都使用了NOT（不能使用索引而降低速度）但NOT EXISTS要比NOT IN查询效率更高

lishixin/Article/program/Oracle/201311/17060

ORACLE数据库性能优化概述

实际上为了保证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数据缓冲池的大小每个进程所能使用的内存大小等参数

lishixin/Article/program/Oracle/201311/17687

ORACLE数据库性能优化概述

数据库用户响应时间＝系统服务时间＋用户等待时间

性能优化包括如下几个部分

ORACLE数据库性能优化之一调整数据结构的设计

这一部分在开发信息系统之前完成程序员需要考虑是否使用ORACLE数据库的分区功能对于经常访问的数据库表是否需要建立索引等

ORACLE数据库性能优化之二调整应用程序结构设计

ORACLE数据库性能优化之三调整数据库SQL语句

ORACLE数据库性能优化之四调整服务器内存分配

ORACLE数据库性能优化之五调整硬盘I/O 这一步是在信息系统开发之前完成的

数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上做到硬盘之间I/O负载均衡

ORACLE数据库性能优化之六调整操作系统参数

例如运行在UNIX操作系统上的ORACLE数据库可以调整UNIX数据缓冲池的大小每个进程所能使用的内存大小等参数

lishixin/Article/program/Oracle/201311/17687

oracle sql性能优化需注意哪些

1，sql的写法，有很多资料，不一一列举
比如 >= , <= 在一起的时候，直接用between and 等等。。。
2，加index

oracle sql性能优化需注意哪些

1，sql的写法，有很多资料，不一一列举
比如 >= , <= 在一起的时候，直接用between and 等等。。。
2，加index

Oracle调优(入门及提高篇)

在过去的十年中， Oracle 已经成为世界上最专业的数据库之一。对于 IT 专家来说，就是要确保利用 Oracle 的强大特性来提高他们公司的生产力。最有效的方法之一是通过 Oracle 调优。它有大量的调整参数和技术来改进你的 Oracle 数据库的性能。
Oracle 调优是一个复杂的主题。关于调优可以写整整一本书，不过，为了改善 Oracle 数据库的性能，有一些基本的概念是每个 Oracle DBA 都应该遵从的。
在这篇简介中，我们将简要地介绍以下的 Oracle 主题：
-- 外部调整：我们应该记住 Oracle 并不是单独运行的。因此我们将查看一下通过调整 Oracle 服务器以得到高的性能。
--Row re-sequencing 以减少磁盘 I/O ：我们应该懂得 Oracle 调优最重要的目标是减少 I/O 。
--Oracle SQL 调整。 Oracle SQL 调整是 Oracle 调整中最重要的领域之一，只要通过一些简单的 SQL 调优规则就可以大幅度地提升 SQL 语句的性能，这是一点都不奇怪的。
-- 调整 Oracle 排序：排序对于 Oracle 性能也是有很大影响的。
-- 调整 Oracle 的竞争：表和索引的参数设置对于 UPDATE 和 INSERT 的性能有很大的影响。
我们首先从调整 Oracle 外部的环境开始。如果内存和 CPU 的资源不足的话，任何的 Oracle 调整都是没有帮助的。
外部的性能问题
Oracle 并不是单独运行的。 Oracle 数据库的性能和外部的环境有很大的关系。这些外部的条件包括有：
． CPU--CPU 资源的不足令查询变慢。当查询超过了 Oracle 服务器的 CPU 性能时，你的数据库性能就受到 CPU 的*。
．内存 -- 可用于 Oralce 的内存数量也会影响 SQL 的性能，特别是在数据缓冲和内存排序方面。
．网络 -- 大量的 Net8 通信令 SQL 的性能变慢。
许多新手都错误的认为应该首先调整 Oracle 数据库，而不是先确认外部资源是否足够。实际上，如果外部环境出现瓶颈，再多的 Oracle 调整都是没有帮助的。
在检查 Oracle 的外部环境时，有两个方面是需要注意的：
1 、当运行队列的数目超过服务器的 CPU 数量时，服务器的性能就会受到 CPU 的*。补救的方法是为服务器增加额外的 CPU 或者关闭需要很多处理资源的组件，例如 Oracle Parallel Query 。
2 、内存分页。当内存分页时，内存容量已经不足，而内存页是与磁盘上的交换区进行交互的。补救的方法是增加更多的内存，减少 Oracle SGA 的大小，或者关闭 Oracle 的多线程服务器。
可以使用各种标准的服务器工具来得到服务器的统计数据，例如 vmstat,glance,top 和 sar 。 DBA 的目标是确保数据库服务器拥有足够的 CPU 和内存资源来处理 Oracle 的请求。
以下让我们来看一下 Oracle 的 row-resequencing 是如何能够极大地减少磁盘 I/O 的。
Row-resequencing （行的重新排序）
就象我们上面提到的，有经验的 Oracle DBA 都知道 I/O 是响应时间的最大组成部分。其中磁盘 I/O 特别厉害，因为当 Oracle 由磁盘上的一个数据文件得到一个数据块时，读的进程就必须等待物理 I/O 操作完成。磁盘操作要比数据缓冲慢 10,000 倍。因此，如果可以令 I/O 最小化，或者减少由于磁盘上的文件竞争而带来的瓶颈，就可以大大地改善 Oracle 数据库的性能。
如果系统响应很慢，通过减少磁盘 I/O 就可以有一个很快的改善。如果在一个事务中通过按一定的范围搜索 primary-key 索引来访问表，那么重新以 CTAS 的方法组织表将是你减少 I/O 的首要策略。通过在物理上将行排序为和 primary-key 索引一样的顺序，就可以加快获得数据的速度。
就象磁盘的负载平衡一样，行的重新排序也是很简单的，而且也很快。通过与其它的 DBA 管理技巧一起使用，就可以在高 I/O 的系统中大大地减少响应的时间。
在高容量的在线事务处理环境中（ online transaction processing ， OLTP ），数据是由一个 primary 索引得到的，重新排序表格的行就可以令连续块的顺序和它们的 primary 索引一样，这样就可以在索引驱动的表格查询中，减少物理 I/O 并且改善响应时间。这个技巧仅在应用选择多行的时候有用，或者在使用索引范围搜索和应用发出多个查询来得到连续的 key 时有效。对于随机的唯一 primary-key （主键）的访问将不会由行重新排序中得到好处。
让我们看一下它是如何工作的。考虑以下的一个 SQL 的查询，它使用一个索引来得到 100 行：
selectsalaryfromemployeewherelast_name like 'B%';
这个查询将会使用 last_name_index ，搜索其中的每一行来得到目标行。这个查询将会至少使用 100 次物理磁盘的读取，因为 employee 的行存放在不同的数据块中。
不过，如果表中的行已经重新排序为和 last_name_index 的一样，同样的查询又会怎样处理呢？我们可以看到这个查询只需要三次的磁盘 I/O 就读完全部 100 个员工的资料（一次用作索引的读取，两次用作数据块的读取），减少了 97 次的块读取。
重新排序带来的性能改善的程度在于在你开始的时候行的乱序性如何，以及你需要由序列中访问多少行。至于一个表中的行与索引的排序键的匹配程度，可以查看数据字典中的 dba_indexes 和 dba_tables 视图得到。
在 dba_indexes 的视图中，查看 clustering_factor 列。如果 clustering_factor 的值和表中的块数目大致一样，那么你的表和索引的顺序是一样的。不过，如果 clustering_factor 的值接近表中的行数目，那就表明表格中的行和索引的顺序是不一样的。
行重新排序的作用是不可以小看的。在需要进行大范围的索引搜索的大表中，行重新排序可以令查询的性能提高三倍。
一旦你已经决定重新排序表中的行，你可以使用以下的工具之一来重新组织表格。
. 使用 Oracle 的 Create Table As Select (CTAS) 语法来拷贝表格
. Oracle9i 自带的表格重新组织工具
以下，我们来看以下 SQL 语句的调优。
SQL 调优
Oracle 的 SQL 调优是一个复杂的主题，甚至是需要整本书来介绍 Oracle SQL 调优的细微差别。不过有一些基本的规则是每个 Oracle DBA 都需要跟从的，这些规则可以改善他们系统的性能。 SQL 调优的目标是简单的：
. 消除不必要的大表全表搜索：不必要的全表搜索导致大量不必要的 I/O ，从而拖慢整个数据库的性能。调优专家首先会根据查询返回的行数目来评价 SQL 。在一个有序的表中，如果查询返回少于 40% 的行，或者在一个无序的表中，返回少于 7% 的行，那么这个查询都可以调整为使用一个索引来代替全表搜索。对于不必要的全表搜索来说，最常见的调优方法是增加索引。可以在表中加入标准的 B 树索引，也可以加入 bitmap 和基于函数的索引。要决定是否消除一个全表搜索，你可以仔细检查索引搜索的 I/O 开销和全表搜索的开销，它们的开销和数据块的读取和可能的并行执行有关，并将两者作对比。在一些情况下，一些不必要的全表搜索的消除可以通过强制使用一个 index 来达到，只需要在 SQL 语句中加入一个索引的提示就可以了。
. 在全表搜索是一个最快的访问方法时，将小表的全表搜索放到缓存中，调优专家应该确保有一个专门的数据缓冲用作行缓冲。在 Oracle7 中，你可以使用 alter table xxx cache 语句，在 Oracle8 或以上，小表可以被强制为放到 KEEP 池中缓冲。
. 确保最优的索引使用：对于改善查询的速度，这是特别重要的。有时 Oracle 可以选择多个索引来进行查询，调优专家必须检查每个索引并且确保 Oracle 使用正确的索引。它还包括 bitmap 和基于函数的索引的使用。
. 确保最优的 JOIN 操作：有些查询使用 NESTED LOOP join 快一些，有些则是 HASH join 快一些，另外一些则是 sort-merge join 更快。
这些规则看来简单，不过它们占 SQL 调优任务的 90% ，并且它们也无需完全懂得 Oracle SQL 的内部运作。以下我们来简单概览以下 Oracle SQL 的优化。
我们首先简要查看 Oracle 的排序，并且看一看排序操作是如何影响性能的。
调整 Oracle 的排序操作
排序是 SQL 语法中一个小的方面，但很重要，在 Oracle 的调整中，它常常被忽略。当使用 create index 、 ORDER BY 或者 GROUP BY 的语句时， Oracle 数据库将会自动执行排序的操作。通常，在以下的情况下 Oracle 会进行排序的操作：
使用 Order by 的 SQL 语句
使用 Group by 的 SQL 语句
在创建索引的时候
进行 table join 时，由于现有索引的不足而导致 SQL 优化器调用 MERGE SORT
当与 Oracle 建立起一个 session 时，在内存中就会为该 session 分配一个私有的排序区域。如果该连接是一个专用的连接 (dedicated connection) ，那么就会根据 init.ora 中 sort_area_size 参数的大小在内存中分配一个 Program Global Area (PGA) 。如果连接是通过多线程服务器建立的，那么排序的空间就在 large_pool 中分配。不幸的是，对于所有的 session ，用做排序的内存量都必须是一样的，我们不能为需要更大排序的操作分配额外的排序区域。因此，设计者必须作出一个平衡，在分配足够的排序区域以避免发生大的排序任务时出现磁盘排序（ disk sorts ）的同时，对于那些并不需要进行很大排序的任务，就会出现一些浪费。当然，当排序的空间需求超出了 sort_area_size 的大小时，这时将会在 TEMP 表空间中分页进行磁盘排序。磁盘排序要比内存排序大概慢 14,000 倍。
上面我们已经提到，私有排序区域的大小是有 init.ora 中的 sort_area_size 参数决定的。每个排序所占用的大小由 init.ora 中的 sort_area_retained_size 参数决定。当排序不能在分配的空间中完成时，就会使用磁盘排序的方式，即在 Oracle 实例中的临时表空间中进行。
磁盘排序的开销是很大的，有几个方面的原因。首先，和内存排序相比较，它们特别慢；而且磁盘排序会消耗临时表空间中的资源。 Oracle 还必须分配缓冲池块来保持临时表空间中的块。无论什么时候，内存排序都比磁盘排序好，磁盘排序将会令任务变慢，并且会影响 Oracle 实例的当前任务的执行。还有，过多的磁盘排序将会令 free buffer waits 的值变高，从而令其它任务的数据块由缓冲中移走。
接着，让我们看一下 Oracle 的竞争，并且看一下表的存储参数的设置是如何影响 SQL UPDATE 和 INSERT 语句的性能的。
调整 Oracle 的竞争
Oracle 的其中一个优点时它可以管理每个表空间中的自由空间。 Oracle 负责处理表和索引的空间管理，这样就可以让我们无需懂得 Oracle 的表和索引的内部运作。不过，对于有经验的 Oracle 调优专家来说，他需要懂得 Oracle 是如何管理表的 extent 和空闲的数据块。对于调整拥有高的 insert 或者 update 的系统来说，这是非常重要的。
要精通对象的调整，你需要懂得 freelists 和 freelist 组的行为，它们和 pctfree 及 pctused 参数的值有关。这些知识对于企业资源计划（ ERP ）的应用是特别重要的，因为在这些应用中，不正确的表设置通常是 DML 语句执行慢的原因。
对于初学者来说，最常见的错误是认为默认的 Oracle 参数对于所有的对象都是最佳的。除非磁盘的消耗不是一个问题，否则在设置表的 pctfree 和 pctused 参数时，就必须考虑平均的行长和数据库的块大小，这样空的块才会被有效地放到 freelists 中。当这些设置不正确时，那些得到的 freelists 也是 "dead" 块，因为它们没有足够的空间来存储一行，这样将会导致明显的处理延迟。
Freelists 对于有效地重新使用 Oracle 表空间中的空间是很重要的，它和 pctfree 及 pctused 这两个存储参数的设置直接相关。通过将 pctused 设置为一个高的值，这时数据库就会尽快地重新使用块。不过，高性能和有效地重新使用表的块是对立的。在调整 Oracle 的表格和索引时，需要认真考虑究竟需要高性能还是有效的空间重用，并且据此来设置表的参数。以下我们来看一下这些 freelists 是如何影响 Oracle 的性能的。
当有一个请求需要插入一行到表格中时， Oracle 就会到 freelist 中寻找一个有足够的空间来容纳一行的块。你也许知道， freelist 串是放在表格或者索引的第一个块中，这个块也被称为段头（ segment header ）。 pctfree 和 pctused 参数的唯一目的就是为了控制块如何在 freelists 中进出。虽然 freelist link 和 unlink 是简单的 Oracle 功能，不过设置 freelist link (pctused) 和 unlink (pctfree) 对 Oracle 的性能确实有影响。
由 DBA 的基本知识知道， pctfree 参数是控制 freelist un-links 的（即将块由 freelists 中移除）。设置 pctfree=10 意味着每个块都保留 10% 的空间用作行扩展。 pctused 参数是控制 freelist re-links 的。设置 pctused=40 意味着只有在块的使用低于 40% 时才会回到表格的 freelists 中。
许多新手对于一个块重新回到 freelists 后的处理都有些误解。其实，一旦由于一个删除的操作而令块被重新加入到 freelist 中，它将会一直保留在 freelist 中即使空间的使用超过了 60% ，只有在到达 pctfree 时才会将数据块由 freelist 中移走。
表格和索引存储参数设置的要求总结
以下的一些规则是用来设置 freelists, freelist groups, pctfree 和 pctused 存储参数的。你也知道， pctused 和 pctfree 的值是可以很容易地通过 alter table 命令修改的，一个好的 DBA 应该知道如何设置这些参数的最佳值。
有效地使用空间和高性能之间是有矛盾的，而表格的存储参数就是控制这个方面的矛盾：
. 对于需要有效地重新使用空间，可以设置一个高的 pctused 值，不过副作用是需要额外的 I/O 。一个高的 pctused 值意味着相对满的块都会放到 freelist 中。因此，这些块在再次满之前只可以接受几行记录，从而导致更多的 I/O 。
. 追求高性能的话，可以将 pctused 设置为一个低的值，这意味着 Oracle 不会将数据块放到 freelists 中直到它几乎是空的。那么块将可以在满之前接收更多的行，因此可以减少插入操作的 I/O 。要记住 Oracle 扩展新块的性能要比重新使用现有的块高。对于 Oracle 来说，扩展一个表比管理 freelists 消耗更少的资源。
让我们来回顾一下设置对象存储参数的一些常见规则：
．经常将 pctused 设置为可以接收一条新行。对于不能接受一行的 free blocks 对于我们来说是没有用的。如果这样做，将会令 Oracle 的性能变慢，因为 Oracle 将在扩展表来得到一个空的块之前，企图读取 5 个 "dead" 的 free block 。
．表格中 chained rows 的出现意味着 pctfree 太低或者是 db_block_size 太少。在很多情况下， RAW 和 LONG RAW 列都很巨大，以至超过了 Oracle 的最大块的大小，这时 chained rows 是不可以避免的。
．如果一个表有同时插入的 SQL 语句，那么它需要有同时删除的语句。运行单一个一个清除的工作将会把全部的空闲块放到一个 freelist 中，而没有其它包含有任何空闲块的 freelists 出现。
． freelist 参数应该设置为表格同时更新的最大值。例如，如果在任何时候，某个表最多有 20 个用户执行插入的操作，那么该表的参数应该设置为 freelists=20 。
应记住的是 freelist groups 参数的值只是对于 Oracle Parallel Server 和 Real Application Clusters 才是有用的。对于这类 Oracle ， freelist groups 应该设置为访问该表格的 Oracle Parallel Server 实例的数目。

Oracle调优(入门及提高篇)

Oracle数据库查询优化方案(处理上百万级记录如何提高处理查询速度)

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查询也将导致全表扫描：
select id from t where name like ‘%abc%‘
若要提高效率，可以考虑全文检索。
7. 如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)=‘abc‘--name以abc开头的id
select id from t where datediff(day,createdate,‘2005-11-30‘)=0--‘2005-11-30’生成的id
应改为:
select id from t where name like ‘abc%‘
select id from t where createdate>=‘2005-11-30‘ and createdate<‘2005-12-1‘
10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(...)
13.很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15. 索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
21.避免频繁创建和删除临时表，以减少系统表资源的消耗。
22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27. 与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29.尽量避免大事务操作，提高系统并发能力。
30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
Oracle数据库查询优化方案（处理上百万级记录如何提高处理查询速度）
标签：开始sql查询truncate大数返回大型大量调整ast

Oracle数据库查询优化方案(处理上百万级记录如何提高处理查询速度)

数据库性能优化主要包括哪些方面？

包括网络、硬件、操作系统、数据库参数和应用程序。

数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。

根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来只占数据库系统性能提升的40%左右，其余的60%系统性能提升来自对应用程序的优化。许多优化专家认为，对应用程序的优化可以得到80%的系统性能的提升。

扩展资料

数据库性能优化法则归纳为5个层次：

1、减少数据访问（减少磁盘访问）

2、返回更少数据（减少网络传输或磁盘访问）

3、减少交互次数（减少网络传输）

4、减少服务器CPU开销（减少CPU及内存开销）

5、利用更多资源（增加资源）

由于每一层优化法则都是解决其对应硬件的性能问题，所以带来的性能提升比例也不一样。传统数据库系统设计是也是尽可能对低速设备提供优化方法，因此针对低速设备问题的可优化手段也更多，优化成本也更低。

任何一个SQL的性能优化都应该按这个规则由上到下来诊断问题并提出解决方案，而不应该首先想到的是增加资源解决问题。

参考资料来源：百度百科--数据库系统优化

数据库性能优化有哪些措施？

1、调整数据结构的设计

这一部分在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。

2、调整应用程序结构设计

这一部分也是在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。

3、调整数据库SQL语句

应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器(OracleOptimizer)和行锁管理器(row-levelmanager)来调整优化SQL语句。

4、调整服务器内存分配

内存分配是在信息系统运行过程中优化配置的，数据库管理员可以根据数据库运行状况调整数据库系统全局区(SGA区)的数据缓冲区、日志缓冲区和共享池的大小;还可以调整程序全局区(PGA区)的大小。需要注意的是，SGA区不是越大越好，SGA区过大会占用操作系统使用的内存而引起虚拟内存的页面交换，这样反而会降低系统。

5、调整硬盘I/O

这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O负载均衡。

6、调整操作系统参数

例如：运行在UNIX操作系统上的ORACLE数据库，可以调整UNIX数据缓冲池的大小，每个进程所能使用的内存大小等参数。

实际上，上述数据库优化措施之间是相互联系的。ORACLE数据库性能恶化表现基本上都是用户响应时间比较长，需要用户长时间的等待。但性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。

一、ORACLE数据库性能优化工具

常用的数据库性能优化工具有：

ORACLE数据库在线数据字典，ORACLE在线数据字典能够反映出ORACLE动态运行情况，对于调整数据库性能是很有帮助的。

操作系统工具，例如UNIX操作系统的vmstat，iostat等命令可以查看到系统系统级内存和硬盘I/O的使用情况，这些工具对于管理员弄清出系统瓶颈出现在什么地方有时候很有用。

SQL语言跟踪工具(SQLTRACEFACILITY)，SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个操作系统的文件，管理员可以使用TKPROF工具查看这些文件。

ORACLEEnterpriseManager(OEM)，这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的ORACLE数据库管理的命令。

EXPLAINPLAN——SQL语言优化命令，使用这个命令可以帮助程序员写出高效的SQL语言。

二、ORACLE数据库的系统性能评估

信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统的类型着重考虑不同的数据库参数。

1、在线事务处理信息系统(OLTP)，这种类型的信息系统一般需要有大量的Insert、Update操作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的ORACLE数据库需要主要考虑下述参数：

数据库回滚段是否足够?

是否需要建立ORACLE数据库索引、聚集、散列?

系统全局区(SGA)大小是否足够?

SQL语句是否高效?

2、数据仓库系统(DataWarehousing)，这种信息系统的主要任务是从ORACLE的海量数据中进行查询，得到数据之间的某些规律。数据库管理员需要为这种类型的ORACLE数据库着重考虑下述参数：

是否采用B*-索引或者bitmap索引?

是否采用并行SQL查询以提高查询效率?

是否采用PL/SQL函数编写存储过程?

有必要的话，需要建立并行数据库提高数据库的查询效率

三、SQL语句的调整原则

SQL语言是一种灵活的语言，相同的功能可以使用不同的语句来实现，但是语句的执行效率是很不相同的。程序员可以使用EXPLAINPLAN语句来比较各种实现方案，并选出最优的实现方案。总得来讲，程序员写SQL语句需要满足考虑如下规则：

1、尽量使用索引。试比较下面两条SQL语句：

语句A：SELECTdname,deptnoFROMdeptWHEREdeptnoNOTIN

(SELECTdeptnoFROMemp);

语句B：SELECTdname,deptnoFROMdeptWHERENOTEXISTS

(SELECTdeptnoFROMempWHEREdept.deptno=emp.deptno);

这两条查询语句实现的结果是相同的，但是执行语句A的时候，ORACLE会对整个emp表进行扫描，没有使用建立在emp表上的deptno索引，执行语句B的时候，由于在子查询中使用了联合查询，ORACLE只是对emp表进行的部分数据扫描，并利用了deptno列的索引，所以语句B的效率要比语句A的效率高一些。

2、选择联合查询的联合次序。考虑下面的例子：

SELECTstuffFROMtabaa,tabbb,tabcc

WHEREa.acolbetween:alowand:ahigh

ANDb.bcolbetween:blowand:bhigh

ANDc.ccolbetween:clowand:chigh

ANDa.key1=b.key1

AMDa.key2=c.key2;

这个SQL例子中，程序员首先需要选择要查询的主表，因为主表要进行整个表数据的扫描，所以主表应该数据量最小，所以例子中表A的acol列的范围应该比表B和表C相应列的范围小。

3、在子查询中慎重使用IN或者NOTIN语句，使用where(NOT)exists的效果要好的多。

4、慎重使用视图的联合查询，尤其是比较复杂的视图之间的联合查询。一般对视图的查询最好都分解为对数据表的直接查询效果要好一些。

5、可以在参数文件中设置SHARED_POOL_RESERVED_SIZE参数，这个参数在SGA共享池中保留一个连续的内存空间，连续的内存空间有益于存放大的SQL程序包。

6、ORACLE公司提供的DBMS_SHARED_POOL程序可以帮助程序员将某些经常使用的存储过程“钉”在SQL区中而不被换出内存，程序员对于经常使用并且占用内存很多的存储过程“钉”到内存中有利于提高最终用户的响应时间。

四、CPU参数的调整

CPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时CPU的使用率在90%以上。如果空闲时间CPU使用率就在90%以上，说明服务器缺乏CPU资源，如果工作高峰时CPU使用率仍然很低，说明服务器CPU资源还比较富余。

使用操作相同命令可以看到CPU的使用情况，一般UNIX操作系统的服务器，可以使用sar_u命令查看CPU的使用率，NT操作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。

数据库管理员可以通过查看v$sysstat数据字典中“CPUusedbythissession”统计项得知ORACLE数据库使用的CPU时间，查看“OSUserlevelCPUtime”统计项得知操作系统用户态下的CPU时间，查看“OSSystemcallCPUtime”统计项得知操作系统系统态下的CPU时间，操作系统总的CPU时间就是用户态和系统态时间之和，如果ORACLE数据库使用的CPU时间占操作系统总的CPU时间90%以上，说明服务器CPU基本上被ORACLE数据库使用着，这是合理，反之，说明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时间。

数据库管理员还可以通过查看v$sesstat数据字典来获得当前连接ORACLE数据库各个会话占用的CPU时间，从而得知什么会话耗用服务器CPU比较多。

出现CPU资源不足的情况是很多的：SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。

1、数据库管理员可以执行下述语句来查看SQL语句的解析情况：

SELECT*FROMV$SYSSTATWHERENAMEIN

('parsetimecpu','parsetimeelapsed','parsecount(hard)');

这里parsetimecpu是系统服务时间，parsetimeelapsed是响应时间，用户等待时间，waitetime=parsetimeelapsed_parsetimecpu

由此可以得到用户SQL语句平均解析等待时间=waitetime/parsecount。这个平均等待时间应该接近于0，如果平均解析等待时间过长，数据库管理员可以通过下述语句

SELECTSQL_TEXT,PARSE_CALLS,EXECUTIONSFROMV$SQLAREA

ORDERBYPARSE_CALLS;

来发现是什么SQL语句解析效率比较低。程序员可以优化这些语句，或者增加ORACLE参数SESSION_CACHED_CURSORS的值。

2、数据库管理员还可以通过下述语句：

SELECTBUFFER_GETS,EXECUTIONS,SQL_TEXTFROMV$SQLAREA;

查看低效率的SQL语句，优化这些语句也有助于提高CPU的利用率。

3、数据库管理员可以通过v$system_event数据字典中的“latchfree”统计项查看ORACLE数据库的冲突情况，如果没有冲突的话，latchfree查询出来没有结果。如果冲突太大的话，数据库管理员可以降低spin_count参数值，来消除高的CPU使用率。

五、内存参数的调整

内存参数的调整主要是指ORACLE数据库的系统全局区(SGA)的调整。SGA主要由三部分构成：共享池、数据缓冲区、日志缓冲区。

1、共享池由两部分构成：共享SQL区和数据字典缓冲区，共享SQL区是存放用户SQL命令的区域，数据字典缓冲区存放数据库运行的动态信息。数据库管理员通过执行下述语句：

select(sum(pins-reloads))/sum(pins)"LibCache"fromv$librarycache;

来查看共享SQL区的使用率。这个使用率应该在90%以上，否则需要增加共享池的大小。数据库管理员还可以执行下述语句：

select(sum(gets-getmisses-usage-fixed))/sum(gets)"RowCache"fromv$rowcache;

查看数据字典缓冲区的使用率，这个使用率也应该在90%以上，否则需要增加共享池的大小。

2、数据缓冲区。数据库管理员可以通过下述语句：

SELECTname,valueFROMv$sysstatWHEREnameIN('dbblockgets','consistentgets','physicalreads');

来查看数据库数据缓冲区的使用情况。查询出来的结果可以计算出来数据缓冲区的使用命中率=1-(physicalreads/(dbblockgets+consistentgets))。

这个命中率应该在90%以上，否则需要增加数据缓冲区的大小。

3、日志缓冲区。数据库管理员可以通过执行下述语句：

selectname,valuefromv$sysstatwherenamein('redoentries','redologspacerequests');

查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率：

申请失败率=requests/entries，申请失败率应该接近于0，否则说明日志缓冲区开设太小，需要增加ORACLE数据库的日志缓冲区。

昌平北大青鸟java培训班转载自网络如有侵权请联系我们感谢您的关注谢谢支持

显示全文

全部频道

Oracle学习总结（8）—— 面向程序员的数据库访问性能优化法则

扩展资料