简单点判断的话，你top或topas观察下，cpu和磁盘读的负载情况。
创新互联建站专注于迁安企业网站建设,成都响应式网站建设公司,商城建设。迁安网站建设公司,为迁安等地区提供建站服务。全流程定制网站，专业设计，全程项目跟踪，创新互联建站专业和态度为您提供的服务
然后生成一份业务高峰时段的AWR报告，看看top 5等待事件主要是哪些，是不是跟磁盘读相关的等待事件(比如全表扫描)
降低IO最有效的方法就是优化sql语句，避免大表全表扫描，根据awr报告中sga各个内存组件的使用情况，适当调整buffer cache的值，来减少磁盘IO
查询优化器参数
1. optimizer_mode
查询优化器是为了找一个最高效的执行计划，这个参数用来定义什么是“高效”，比如是更快还是占用资源更少。在oracle10g中只支持两个参数值：
all_rows：提供全部数据
first_rows(n)：n为大于0的自然数，表示尽快传输前面n条数据（比如分页查询的时候，我第一次只查询前面10条数据）
oracle10g默认为all_rows，可以再数据库级别，会话级别，或者执行SQL的时候修改该参数的值。
数据库级别：alter system set optimizer_mode=first_rows(10) scope=spfile;
会话级别：ALTER SESSION SET OPTIMIZER_MODE=first_rows(10);
SQL级别：SELECT /*+ first_rows(10) */ id,name from t1 order by id;
其实，默认all_rows是最好的方式，如果确实是只要查询小部分数据，可以在sql级别加上提示，看是否能提高性能。
2. db_file_multiblock_read_count
在多块读的情况下（比如全表扫描），该参数说明一次最多可读取的数据块数目。设置得太小的话，效率低。设置得太高也不见得就好（太高，会受I/O最大吞吐量限制。比如设置成一次最多读取1024块，但I/O最大吞吐量只允许32块，那一次最多也只读取32块。而且一次读取很多块，开销会偏高。）应该通过测试，才能知道应该把该参数设置成哪一个值。
测试过程：
1. 创建一张大表，比如上千万行级别的数据
2. 循环设置该参数的值，查看全表扫描的速度。类似于以下语句：
[sql] view plain copy
span style="font-size:14px;" declare
l_count pls_integer;
l_time pls_integer;
l_starting_time pls_integer;
l_ending_time pls_integer;
begin
dbms_output.put_line('dbfmbrc seconds');
for l_dbfmbrc in 1..32
loop
execute immediate 'alter session set db_file_multiblock_read_count='||l_dbfmbrc;
l_starting_time := dbms_utility.get_time();
select /*+ full(t) */ count(*) into l_count from big_table t;
l_ending_time := dbms_utility.get_time();
l_time := round((l_ending_time-l_starting_time)/100);
dbms_output.put_line(l_dbfmbrc||' '||l_time);
end loop;
end;
//span
3. optimizer_index_cost_adj
影响走索引扫描的开销计算。 取值范围1到10000.默认值为100，超过100后，走索引扫描的开销越高，从而使得查询优化器更加倾向于使用全表扫描。相反，小于100，索引扫描的开销就越低，从而使得查询优化器更加倾向于使用索引扫描。从下面索引扫描开销计算公式可以看出：
io_cost=(blevel+(leaf_blocks+culstering_factor)*selectivity) *optimizer_index_cost_adj/100.
一般是默认值不需要修改，但是如果发现本应该走索引扫描结果走了全表扫描，可以适当调低该值，但是，这个值不应该设置过低，因为，过低的话，如果两个索引扫描的开销不同，可能通过该公式一算，开销就变成一样的了。总之，不建议修改该参数的值。
PGA参数
1. workarea_size_policy
管理工作区域内存（PGA）的方式，
auto：oracle10g默认方式，委托给内存管理器自动管理（建议不需要修改）
manual：oracle9i默认方式，oracle9i没有自动管理功能。
2. pga_aggregate_target
如果是自动管理PGA，那么该参数用于指定实例可用的PGA的大小，默认是SGA的20%。即使今后用的内存超过了设置的值，也没有关系，oracle会自动增大PGA的值。比如该参数设置的是200M，今后某一时刻，需要300M，也是没问题的，会自动增长。
3. sort_area_size
手动管理PGA，该参数指定分配多大的内存用于排序操作，过小的话，会影响性能，过大的话浪费空间。很难说一个合适的默认值，因为用户场景变化非常大，实际情况得实际处理。
4. hash_area_size
手动管理PGA，该参数用于指定哈希连接的工作区域大小，同样建议它的值也很困难。如果过小，那么查询优化器就会高估哈希连接的开销，偏向于合并连接。
有很多种方法可以用来找出哪些SQL语句需要优化，但是很久以来，最简单的方法都是分析保存在V$SQL视图中的缓存的SQL信息。通过V$SQL视图，可以确定具有高消耗时间、CUP和IO读取的SQL语句。
1.查看总消耗时间最多的前10条SQL语句
select *
from (select v.sql_id,
v.child_number,
v.sql_text,
v.elapsed_time,
v.cpu_time,
v.disk_reads,
rank() over(order by v.elapsed_time desc) elapsed_rank
from v$sql v) a
where elapsed_rank = 10;
2.查看CPU消耗时间最多的前10条SQL语句
select *
from (select v.sql_id,
v.child_number,
v.sql_text,
v.elapsed_time,
v.cpu_time,
v.disk_reads,
rank() over(order by v.cpu_time desc) elapsed_rank
from v$sql v) a
where elapsed_rank = 10;
3.查看消耗磁盘读取最多的前10条SQL语句
select *
from (select v.sql_id,
v.child_number,
v.sql_text,
v.elapsed_time,
v.cpu_time,
v.disk_reads,
rank() over(order by v.disk_reads desc) elapsed_rank
from v$sql v) a
where elapsed_rank = 10;
希望能帮到您！
在日常基于数据库应用的开发过程中，我们经常需要对多个表或者数据源进行关联查询而得出我们需要的结果集。那么Oracle到底存在着哪几种连接方式？优化器内部又是怎样处理这些连接的？哪种连接方式又是适合哪种查询需求的？只有对这些问题有了清晰的理解后，我们才能针对特定的查询需求选择合适的连接方式，开发出健壮的数据库应用程序。选择合适的表连接方法对SQL语句运行的性能有着至关重要的影响。下面我们就Oracle常用的一些连接方法及适用情景做一个简单的介绍。
3.1 嵌套循环连接(nested loop)
嵌套循环连接的工作方式是这样的：
1、 Oracle首先选择一张表作为连接的驱动表，这张表也称为外部表（Outer Table）。由驱动表进行驱动连接的表或数据源称为内部表（Inner Table）。
2、 提取驱动表中符合条件的记录，与被驱动表的连接列进行关联查询符合条件的记录。在这个过程中，Oracle首先提取驱动表中符合条件的第一条记录，再与内部表的连接列进行关联查询相应的记录行。在关联查询的过程中，Oracle会持续提取驱动表中其他符合条件的记录与内部表关联查询。这两个过程是并行进行的，因此嵌套循环连接返回前几条记录的速度是非常快的。在这里需要说明的是，由于Oracle最小的IO单位为单个数据块，因此在这个过程中Oracle会首先提取驱动表中符合条件的单个数据块中的所有行，再与内部表进行关联连接查询的，然后提取下一个数据块中的记录持续地循环连接下去。当然，如果单行记录跨越多个数据块的话，就是一次单条记录进行关联查询的。
3、 嵌套循环连接的过程如下所示：
Nested loop
Outer loop
Inner loop
我们可以看出这里面存在着两个循环，一个是外部循环，提取驱动表中符合条件的每条记录。另外一个是内部循环，根据外循环中提取的每条记录对内部表进行连接查询相应的记录。由于这两个循环是嵌套进行的，故此种连接方法称为嵌套循环连接。
嵌套循环连接适用于查询的选择性强、约束性高并且仅返回小部分记录的结果集。通常要求驱动表的记录（符合条件的记录，通常通过高效的索引访问）较少，且被驱动表连接列有唯一索引或者选择性强的非唯一索引时，嵌套循环连接的效率是比较高的。
嵌套循环连接驱动表的选择也是连接中需要着重注意的一点，有一个常见的误区是驱动表要选择小表，其实这是不对的。假如有两张表A、B关联查询，A表有1000000条记录，B表有10000条记录，但是A表过滤出来的记录只有10条，这时候显然用A表当做驱动表是比较合适的。因此驱动表是由过滤条件限制返回记录最少的那张表，而不是根据表的大小来选择的。
在外连接查询中，如果走嵌套循环连接的话，那么驱动表必然是没有符合条件关联的那张表，也就是后面不加(+)的那张表。这是由于外连接需要提取可能另一张表没符合条件的记录，因此驱动表需要是那张我们要返回所有符合条件记录的表。比如下面这个查询，
嵌套循环连接返回前几行的记录是非常快的，这是因为使用了嵌套循环后，不需要等到全部循环结束再返回结果集，而是不断地将查询出来的结果集返回。在这种情况下，终端用户将会快速地得到返回的首批记录，且同时等待Oracle内部处理其他记录并返回。如果查询的驱动表的记录数非常多，或者被驱动表的连接列上无索引或索引不是高度可选的情况，嵌套循环连接的效率是非常低的
-- 删除原表
drop table t1;
-- 建立测试表
create table t1(
f1 varchar2(10),
f2 varchar2(1000)
)
tablespace CTL
pctfree 98;
-- 填充测试内容
insert into t1(f1,f2)
select rownum, lpad(rownum,700,'0')
from dba_tables a, dba_tab_cols b
where a.owner = b.owner
and rownum 10000;
commit;
-- 检查测试内容格式
select sys.dbms_rowid.rowid_block_number(rowid), f1, f2 from t1;
-- 每条记录都存储在单独的数据块中
select count( distinct sys.dbms_rowid.rowid_block_number(rowid)) from t1;
/*
用同样的方式建立表t2
*/
-- 删除原表
drop table t2;
-- 建立测试表
create table t2(
f1 varchar2(10),
f2 varchar2(1000)
)
tablespace CTL
pctfree 98;
-- 填充测试内容
insert into t2(f1,f2)
select rownum * 10, lpad(rownum * 10,700,'0')
from dba_tables a, dba_tab_cols b
where a.owner = b.owner
and rownum 1000;
commit;
-- 检查测试内容格式
select sys.dbms_rowid.rowid_block_number(rowid), f1, f2 from t2;
-- 每条记录都存储在单独的数据块中
select count( distinct sys.dbms_rowid.rowid_block_number(rowid)) from t2;
create index ind_t1_f1 on t1(f1);
create index ind_t2_f1 on t2(f1);
--首先我们来看使用nested loop关联方式, 不同表作为驱动时的情况.
1, 表t2作为驱动表
select /*+ ordered use_nl(t1 , t2)*/
t1.f1, t2.f1
from ctl.t2 t2,ctl.t1 t1
where t1.f1 = t2.f1
and t1.f1 1000;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=84 Card=4 Bytes=56)
1 0 NESTED LOOPS (Cost=84 Card=4 Bytes=56)
2 1 TABLE ACCESS (FULL) OF 'T2' (Cost=2 Card=82 Bytes=574)
3 1 INDEX (RANGE SCAN) OF 'IND_T1_F1' (NON-UNIQUE) (Cost=1 C
ard=1 Bytes=7)
Cost = outer access cost + (inner access cost * outer cardinality)
Cost = 2 + 1 * 82 = 84;
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2020 consistent gets
23 physical reads
0 redo size
2650 bytes sent via SQL*Net to client
721 bytes received via SQL*Net from client
8 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
99 rows processed
2, t1作为驱动表
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=4 Bytes=56)
1 0 NESTED LOOPS (Cost=6 Card=4 Bytes=56)
2 1 TABLE ACCESS (FULL) OF 'T1' (Cost=2 Card=4 Bytes=28)
3 1 INDEX (RANGE SCAN) OF 'IND_T2_F1' (NON-UNIQUE) (Cost=1 C
ard=1 Bytes=7)
Cost = outer access cost + (inner access cost * outer cardinality)
Cost = 2 + 1 * 4 = 84;
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
11123 consistent gets
3 physical reads
0 redo size
2650 bytes sent via SQL*Net to client
721 bytes received via SQL*Net from client
8 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
99 rows processed
3.2, 哈希连接(hash join)
哈希连接分为两个阶段，如下。
1、 构建阶段：优化器首先选择一张小表做为驱动表，运用哈希函数对连接列进行计算产生一张哈希表。通常这个步骤是在内存（hash_area_size）里面进行的，因此运算很快。
2、 探测阶段：优化器对被驱动表的连接列运用同样的哈希函数计算得到的结果与前面形成的哈希表进行探测返回符合条件的记录。这个阶段中如果被驱动表的连接列的值没有与驱动表连接列的值相等的话，那么这些记录将会被丢弃而不进行探测
哈希连接比较适用于返回大数据量结果集的连接。
使用哈希连接必须是在CBO模式下，参数hash_join_enabled设置为true，
哈希连接只适用于等值连接。从Oracle9i开始，哈希连接由于其良好的性能渐渐取代了原来的排序合并连接。
SQL select /*+ ordered use_hash(t1 , t2) */
t1.f1, t2.f1
from ctl.t1 t1,ctl.t2 t2
where t1.f1 = t2.f1 2 3 4 ;
999 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=5 Card=82 Bytes=1148
)
1 0 HASH JOIN (Cost=5 Card=82 Bytes=1148)
2 1 TABLE ACCESS (FULL) OF 'T1' (Cost=2 Card=82 Bytes=574)
3 1 TABLE ACCESS (FULL) OF 'T2' (Cost=2 Card=82 Bytes=574)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
11113 consistent gets
0 physical reads
0 redo size
23590 bytes sent via SQL*Net to client
1381 bytes received via SQL*Net from client
68 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
999 rows processed
3.3, 排序合并连接(merge join)
排序合并连接的方法非常简单。在排序合并连接中是没有驱动表的概念的，两个互相连接的表按连接列的值先排序，排序完后形成的结果集再互相进行合并连接提取符合条件的记录。相比嵌套循环连接，排序合并连接比较适用于返回大数据量的结果。
排序合并连接在数据表预先排序好的情况下效率是非常高的，也比较适用于非等值连接的情况，比如、=、=等情况下的连接（哈希连接只适用于等值连接）。由于Oracle中排序操作的开销是非常消耗资源的，当结果集很大时排序合并连接的性能很差，于是Oracle在7.3之后推出了新的连接方式——哈希连接。
1, rbo模式;
2, 不等于关联( = = )
3, hash_join_enabled = false;
4, 数据源已排序
通过配置本地数据库的tns配置文件实现：
去oracle安装目录下oracle\product\10.2.0\db_2\NETWORK\ADMIN\ 找到tnsnames.ora，用记事本打开，里边有远程数据库的tns连接配置串如下
ORCL23 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.3.23)(PORT = 1521))
)
(CONNECT_DATA =
(SID = ORCL)
)
)
添加好ip、端口和目标数据库的实例名(SID)，然后确保tns名称(ORCL23)在整个文档中唯一，保存后打开数据库连接工具，输入远程数据库上的用户名密码，选择数据库对象为你配置的连接名就可以了
ORACLE 不会自动建立索引，之所以快是因为从内存中读取比disk IO要快的原因。
LZ的概念理解有误，我来举例说明下。
ORACLE data一般缓存在SGA中的data cache中 1.表A有10000条数据，在0:00时刻对其进行查询，则将表A的所有数据块从disk缓存至data cache中。因此第二次查询时直接从data cache中获得速度变快。 2.0:05时刻 对表A进行更新等操作，20000行。再次对表A进行查询，之前没有变化的数据块仍然直接从data cache中直接获得。发生过变更，或新增的数据块，需要重新从disk读入data cache中，如果data cache空间已满，就会将之前发生变更的脏数据块及不常使用的数据块清空出data cache，然后缓存新的数据块。 因此整个过程中，不会出现你说的只能查到缓存数据的现象。分析你遇到的问题，很有可能是你用userA 进行查询后发现表10000行，然后使用userB进行更新至20000行，但是userB并没有commit。因此userA在查询时仍然只能看到10000行。
重庆分公司
重庆分公司
