摘要: 1.查看 tablespace存放哪些数据表
select table_name from all_tables where tablespace_name = 'Example'
2.查看 表属于哪个用户
select owne...
阅读全文
安装tomcat后，在客户端输入地址
http://serverAddress:8080，发现默认端口8080不能访问。
由于Linux防火墙默认是关闭8080端口。因此，若要能够访问8080端口，可以用两种方式，一个是关闭防火墙，另一个就是让防火墙开放8080端口。
开放8080端口的解决步骤如下：
1、修改/etc/sysconfig/iptables文件，增加如下一行：
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT
重启 iptables
service iptables restart
2、重启防火墙，这里有两种方式重启防火墙
a) 重启后生效
开启： chkconfig iptables on
关闭： chkconfig iptables off
b) 即时生效，重启后失效
开启： service iptables start
关闭： service iptables stop
再次从客户端访问，成功！
一个回滚段可以存放多个事务的回滚信息。
回滚段的作用
1。事务回滚：当事务修改表中数据的时候，该数据修改前的值（即前影像）会存放在
回滚段中，当用户回滚事务（ROLLBACK）时，ORACLE 将会利用回滚段中的数据前影像
来将修改的数据恢复到原来的值。
2。事务恢复：当事务正在处理的时候，例程失败，回滚段的信息保存在重做日志文件
中，ORACLE 将在下次打开数据库时利用回滚来恢复未提交的数据。
3。读一致性：当一个会话正在修改数据时，其他的会话将看不到该会话未提交的修改。
而且，当一个语句正在执行时，该语句将看不到从该语句开始执行后的未提交的修改（语句
级读一致性）。当ORACLE 执行SELECT 语句时，ORACLE 依照当前的系统改变号（SYSTEM
CHANGE NUMBER-SCN）来保证任何前于当前SCN 的未提交的改变不被该语句处理。可
以想象：当一个长时间的查询正在执行时，若其他会话改变了该查询要查询的某个数据块，
ORACLE 将利用回滚段的数据前影像来构造一个读一致性视图。
事务级的读一致性
ORACLE 一般提供SQL 语句级（SQL STATEMENT LEVEL）的读一致性，可以用以下
语句来实现事务级的读一致性。
SET TRANSACTION READ ONLY；
或：
SET TANNSACTION SERIALIZABLE；
以上两个语句都将在事务开始后提供读一致性。需要注意的是，使用第二个语句对数据
库的并发性和性能将带来影响。
回滚段的种类
1。系统回滚段：当数据库创建后，将自动创建一个系统回滚段，该回滚段只用于存放
系统表空间中对象的前影像。
2。非系统回滚段：拥有多个表空间的数据库至少应该有一个非系统回滚段，用于存放
非系统表空间中对象的数据前影像。非系统回滚段又分为私有回滚段和公有回滚段，私有回
滚段应在参数文件的ROLLBACK SEGMENTS 参数中列出，以便例程启动时自动使其在线
（ONLINE）。公有回滚段一般在OPS（ORACLE 并行服务器）中出现，将在例程启动时自
动在线。
3。DEFERED 回滚段：该回滚段在表空间离线（OFFLINE）时由系统自动创建，当表
空间再次在线（ONLINE）时由系统自动删除，用于存放表空间离线时产生的回滚信息。
回滚段的使用
分配回滚段：当事务开始时，ORACLE 将为该事务分配回滚段，并将拥有最少事务的
回滚段分配给该事务。事务可以用以下语句申请指定的回滚段：
SET TRANSTRACTION USE ROLLBACK SEGMENT rollback_segment
事务将以顺序，循环的方式使用回滚段的区（EXTENTS），当当前区用满后移到下一个
区。几个事务可以写在回滚段的同一个区，但每个回滚段的块只能包含一个事务的信息。
例如（两个事务使用同一个回滚段，该回滚段有四个区）：
1、事务在进行中，它们正在使用回滚段的第三个区；
2、当两个事务产生更多的回滚信息，它们将继续使用第三个区；
3、当第三个区满后，事务将写到第四个区，当事务开始写到一个新的区时，称为翻转
（WRAP）；
4、当第四个区用满时，如果第一个区是空闲或非活动（使用该区的所有事务完成而没
有活动的事务）的，事务将接着使用第一个区。
回滚段的扩张（EXTEND）
当当前回滚段区的所有块用完而事务还需要更多的回滚空间时，回滚段的指针将移到下
一个区。当最后一个区用完，指针将移到第一个区的前面。回滚段指针移到下一个区的前提
是下一个区没有活动的事务，同时指针不能跨区。当下一个区正在使用时，事务将为回滚段
分配一个新的区，这种分配称为回滚段的扩展。回滚段将一直扩展到该回滚段区的个数到达
回滚段的参数MAXEXTENTS 的值时为止。
回滚段的回收和OPTIMAL 参数
OPTIMAL 参数指明回滚段空闲时收缩到的位置，指明回滚段的OPTIMAL 参数可以减
少回滚段空间的浪费。
V$ROLLSTAT 中的常用列
USN：回滚段标识
RSSIZE：回滚段默认大小
XACTS：活动事务数
在一段时间内增量用到的列
WRITES：回滚段写入数(单位:bytes)
SHRINKS：回滚段收缩次数
EXTENDS：回滚段扩展次数
WRAPS：回滚段翻转(wrap)次数
GETS：获取回滚段头次数
WAITS：回滚段头等待次数
V$ROLLSTAT 中的连接列
Column View Joined Column(s)
-------------- ----------------------- ------------------------
USN V$ROLLNAME USN
注意：
通过花费时间除以翻转次数，你可以得到一次回滚段翻转(wrap)的平均用时。此方法常
用于在长查询中指定合适的回滚段大小以避免'Snapshot Too Old'错误。同时，通过查看
extends 和shrinks 列可以看出optimal 是否需要增加。
示例：
1.查询回滚段的信息。所用数据字典：DBA_ROLLBACK_SEGS，可以查询的信息：回滚段
的标识(SEGMENT_ID)、名称(SEGMENT_NAME)、所在表空间(TABLESPACE_NAME)、类
型(OWNER)、状态(STATUS)。
select * from DBA_ROLLBACK_SEGS
查看回滚段的统计信息：
SELECT n.name, s.extents, s.rssize, s.optsize, s.hwmsize, s.xacts,
s.status
FROM v$rollname n, v$rollstat s
WHERE n.usn = s.usn;
3.查看回滚段的使用情况，哪个用户正在使用回滚段的资源:
select s.username, u.name
from v$transaction t, v$rollstat r, v$rollname u, v$session s
where s.taddr = t.addr
and t.xidusn = r.usn
and r.usn = u.usn
order by s.username;
学习动态性能表
第16 篇--V$ROWCACHE 2007.6.12
本视图显示数据字典缓存(也叫rowcache)的各项统计。每一条记录包含不同类型的数据
字典缓存数据统计，注意数据字典缓存有层次差别，因此同样的缓存名称可能不止一次出现。
V$ROWCACHE 常用列
PARAMETER：缓存名
COUNT：缓存项总数
USAGE：包含有效数据的缓存项数
GETS：请求总数
GETMISSES：请求失败数
SCANS：扫描请求数
SCANMISSES：扫描请求失败次数
MODIFICATIONS：添加、修改、删除操作数
DLM_REQUESTS：DLM 请求数
DLM_CONFLICTS：DLM 冲突数
DLM_RELEASES：DLM 释放数
使用 V$ROWCACHE 数据
1>.确认数据字典缓存是否拥有适当的大小。如果shared pool 过小，那数据字典缓存就
不足以拥有合适的大小以缓存请求信息。
2>.确认应用是否有效访问缓存。如果应用设计未能有效使用数据字典缓存(比如，大数
据字典缓存并不有助于解决性能问题)。例如，DC_USERS 缓存在过去某段时期内出现
大量GETS，看起来像是数据库中创建了大量的不同用户，并且应用记录下用户频繁登
陆和注销。通过检查logon 比率以及系统用户数可以验证上述数据。同时解析比率也会
很高，如果这是一个大型的OLTP 系统的中间层，它可能在中间层更有效的管理个别帐
户，允许中间层以单用户登陆成为应用所有者。通过保持活动连接来减少logon/logoff
比率也同样有效。
3>. 确认是否发生动态空间分配。DC_SEGMENTS, DC_USED_EXTENTS, 以及
DC_FREE_EXTENTS 大量的类似大小修改将指出存在大量动态空间分配。可行的解决
方案包括指定下一个区大小或者使用本地管理表空间。如果发生空间分配的是临时的表
空间，则可以为其指定真正的临时表空间(If the space allocation is occurring on the temp
tablespace, then use a true temporary tablespace for the temp. )。
4>.dc_sequences 值的变化指出是否大量sequence 号正在产生。
5>.搜集硬解析的证据。硬解析常表现为大量向DC_COLUMNS, DC_VIEWS 以及
DC_OBJECTS caches 的gets。
示例：
1.分组统计数据字典统计项
SELECT parameter,sum("COUNT"),sum(usage),sum(gets),sum(getmisses),
sum(scans),sum(scanmisses),sum(modifications),
sum(dlm_requests),sum(dlm_conflicts),sum(dlm_releases)
FROM V$ROWCACHE
GROUP BY parameter;
2.检查数据字典的命中率
select 1 - sum(getmisses) / sum(gets) "data dictionary hitratio" from
v$rowcache;
学习动态性能表
第17 篇-(1)-V$SEGSTAT 2007.6.13
本视图实时监控段级(segment-level)统计项，支持oracle9ir2 及更高版本
V$SEGSTAT 中的常用列
TS#：表空间标识
OBJ#：字典对象标识
DATAOBJ#：数据对象标识
STATISTIC_NAME：统计项名称
STATISTIC#：统计项标识
VALUE：统计项值
V$SEGSTAT 中的连接列
Column View Joined Column(s)
-------------- ----------------------- ------------------------
TS# V$TABLESPACE TS#
OBJ# ALL_OBJECTS OBJECT_ID
示例：
9. 查询指定对象的统计
select * from v$segstat where ts# = 11
and obj# = (select object_id from user_objects
where object_name = 'TMPTABLE1' and owner = 'JSS')
第 17 篇-(2)-V$SEGMENT_STATISTICS 2007.6.13
这是一个友好的视图，支持Oracle9ir2 及更高版本。实时监测段级(segment-level)统计项，
可用于鉴定性能问题源于表或索引
V$SEGMENT_STATISTICS 中的列
OWNER：对象所有者
OBJECT_NAME：对象名称
SUBOBJECT_NAME：子对象名称
TABLESPACE_NAME：对象所在表空间
TS#：表空间标识
OBJ#：字典对象标识
DATAOBJ#：数据对象标识
OBJECT_TYPE：对象类型
STATISTIC_NAME：统计项名称
STATISTIC#：统计项标识
VALUE：统计项值
基本与上相同，只是信息更加详细，不再赘述。
学习动态性能表
第18 篇--V$SYSTEM_EVENT 2007.6.13
本视图概括了实例各项事件的等待信息。v$session_wait 显示了系统的当前等待项，
v$system_event 则提供了自实例启动后各个等待事件的概括。常用于获取系统等待信息的历
史影象。而通过两个snapshot 获取等待项增量，则可以确定这段时间内系统的等待项。
V$SYSTEM_EVENT 中的常用列
1. EVENT:等待事件名称
2. TOTAL_WAITS：此项事件总等待次数
3. TIME_WAITED：此项事件的总等待时间(单位：百分之一秒)
4. AVERAGE_WAIT ： 此项事件的平均等待用时( 单位： 百分之一
秒)(time_waited/total_waits)
5. TOTAL_TIMEOUTS：此项事情总等待超时次数
示例：
1.查看系统的各项等待，按总耗时排序
SELECT event,total_waits waits,total_timeouts timeouts,
time_waited total_time,average_wait avg
FROM V$SYSTEM_EVENT
ORDER BY 4 DESC;
比如，通过checkpoint completed、log file switch（checkpoint incomplete）可以查看检查点进
程的性能。通过log file parallel write、log file switch completed 可以查看联机重做日志文件的
性能。通过log file switch（archiving needed）事件可以检查归档进程的性能。
找出瓶颈：
1。通过Statspack 列出空闲事件。
2。检查不同事件的等待时间开销。
3。检查每条等待记录的平均用时，因为某些等待事件(比较log file switch completion)可能周
期性地发生，但发生时却造成了严重的性能损耗。
学习动态性能表
第19 篇--V$UNDOSTAT 2007.6.14
本视图监控当前实例中undo 空间以及事务如何运行。并统计undo 空间开销，事务开销
以及实例可用的查询长度。
V$UNDOSTAT 中的常用列
Endtime：以10 分钟为间隔的结束时间
UndoBlocksUsed：使用的undo 块总数
TxnConcurrency：事务并发执行的最大数
TxnTotal：在时间段内事务执行总数
QueryLength：查询长度的最大值
ExtentsStolen：在时间段内undo 区必须从一个undo 段转到另一个的次数
SSTooOldError：在时间段内'Snapshot Too Old'错误发生的次数
UNDOTSN：这段时间内最后活动的undo 表空间ID
视图的第一行显示了当前时间段的统计，其它的每一条记录分别以每10 分钟一个区间。
24 小时循环，一天最多144 条记录。
示例：
1.本例显示undo 空间从16:27 到之前24 小时内的各项统计。
SQL>select * from v$undostat;
End-Time UndoBlocks TxnConcrcy TxnTotal QueryLen ExtentsStolen SSTooOldError
-------- ---------- ---------- -------- -------- ------------- -------------
16:07 252 15 1511 25 2 0
16:00 752 16 1467 150 0 0
15:50 873 21 1954 45 4 0
15:40 1187 45 3210 633 20 1
15:30 1120 28 2498 1202 5 0
15:20 882 22 2002 55 0 0
在统计项收集过程中，undo 消耗最高发生在15:30-15:40 这个时间段。10 分钟内有1187 个
undo 块被占用(基本上每秒钟2 个块)。同时，最高事务并发也是在相同的时间段，45 个事
务被并发执行。执行的最长查询(1202 秒)是在15:20-15:30 之间，需要注意的是查询实际上
是15:00-15:10 段即开始并直到15:20 这个时间段。
学习动态性能表
第20 篇--V$WAITSTAT 2007.6.15
本视图保持自实例启动所有的等待事件统计信息。常用于当你发现系统存在大量的
"buffer busy waits"时据此做出适当调整。
V$WAITSTAT 中的常用列
CLASS：块类别
WAITS：本类块的等待次数
TIME：本类块的总等待时间
等待发生的原因：
1.undo 段头部：没有足够的回滚段
2.数据段头部/数据段空闲列：空闲列争夺
3.数据块冲突
4.缓存存在大量的CR 复制
5.range 检索时，索引列存在大量不连续
6.全表检索的表有大量被删除记录
7.高并发的读写块
本视图列出session打开的所有cursors，很多时候都将被用到，比如：你可以通过它查看各个session打开的cursor数。
当诊断系统资源占用时，它常被用于联接v$sqlarea和v$sql查询出特定SQL(高逻辑或物理I/O)。然后，下一步就是找出源头。在应用环境，基本都是同一类用户登陆到数据库(在V$SQLAREA中拥有相同的PARSING_USER_ID)，而通过这个就可以找出它们的不同。V$SQLAREA中的统计项在语句完全执行后被更新(并且从V$SESSION.SQL_HASH_VALUE中消失)。因此，你不能直接找到session除非语句被再次执行。不过如果session的cursor仍然打开着，你可以通过v$open_cursor找出执行这个语句的session。
V$OPEN_CURSOR中的连接列
Column View Joined Column(s)
----------------------------- ---------------------------------------- -----------------------------
HASH_VALUE, ADDRESS V$SQLAREA, V$SQL, V$SQLTEXT HASH_VALUE, ADDRESS
SID V$SESSION SID
示例：
1.找出执行某语句的session：
SELECT hash_value, buffer_gets, disk_reads
FROM V$SQLAREA
WHERE disk_reads > 1000000
ORDER BY buffer_gets DESC;
HASH_VALUE BUFFER_GETS DISK_READS
---------- ----------- ----------
1514306888 177649108 3897402
478652562 63168944 2532721
360282550 14158750 2482065
3 rows selected.
SQL> SELECT sid FROM V$SESSION WHERE sql_hash_value = 1514306888 ;
no rows selected
--直接通过hash_value查找v$session，没有记录
SQL> SELECT sid FROM V$OPEN_CURSOR WHERE hash_Value = 1514306888 ;
SID
-----
1125
233
935
1693
531
5 rows selected.
--通过hash_value在v$open_cursor中查找sid(只有在session的cursor仍然打开的情况下才有可能找到)
2.列出拥有超过400个cursor的sessionID
SQL> SELECT sid, count(0) ct FROM v$open_cursor
GROUP BY sid HAVING COUNT(0) > 400 ORDER BY ct desc;
事实上，v$open_cursor是一个相当常用的视图，特别是web开发应用的时候。仅通过它一个视图你就能分析出当前的连接情况，主要执行语句等。
这两个视图列出的各参数项名称以及参数值。V$PARAMETER显示执行查询的session的参数值。V$SYSTEM_PARAMETER视图则列出实例的参数值。
例如，下列查询显示执行查询的session的SORT_AREA_SIZE参数值：
SELECT value
FROM V$PARAMETER
WHERE name = 'sort_area_size';
呵呵，可能有朋友还是不明白v$parameter和v$system_parameter的区别，我再举个例子，相信你马上就明白了。
SQL>select value from v$parameter where name = 'global_names';
VALUE
------------------------------------------------------------------------------------------------
TRUE
1 row selected.
SQL> alter session set global_names = false;
Session altered.
SQL> select value from v$parameter where name = 'global_names';
VALUE
------------------------------------------------------------------------------------------------
FALSE
1 row selected.
SQL> select value from v$system_parameter where name = 'global_names';
VALUE
------------------------------------------------------------------------------------------------
TRUE
1 row selected.
V$PARAMETER中的常用列：
l NAME：参名
l VALUE：参值(session或实例)
l ISDEFAULT：参值是否默认值
l ISSES_MODIFIABLE：此参数是否session级可修改
l ISSYS_MODIFIABLE：此参数在实例启动后是否可由实例修改
l ISMODIFIED：自实例启动起，参值是否被修改，如果被修改，session级或是实例(系统)级修改(如果执行一条alter session,则值将被MODIFIED，如果执行的是alter system，则值为SYS_MODIFIED)
l ISADJUSTED：
l DESCRIPTION：参数简要描述
l UPDATE_COMMENT：由dba提供的参数说明
使用v$parameter以及v$system_parameter数据：
在调优期间通过查询v$parameter以确认当前参数设置。例如，如果buffer cache hit ratio较低，那么通过查询DB_BLOCK_BUFFERS(或DB_CACHE_SIZE)可以明确当前的buffer cache大小。
SELECT name, value, isdefault, isses_modifiable, issys_modifiable, ismodified
FROM V$PARAMETER
WHERE name = 'sort_area_size';
NAME VALUE ISDEF ISSES ISSYS_MOD ISMODIFIED
-------------------- ---------- ----- ----- --------- ----------
sort_area_size 1048576 TRUE TRUE DEFERRED MODIFIED
前例显示了SORT_AREA_SIZE初始参数在实例启动时并非初始值，不过被session修改回了初始值。
注意：当查询v$parameter时要注意，如果你想查看实例参数，要查询v$system_parameter。
Oracle Rdbms应用了各种不同类型的锁定机制，latch即是其中的一种。Latch是用于保护SGA区中共享数据结构的一种串行化锁定机制。Latch的实现是与操作系统相关的，尤其和一个进程是否需要等待一个latch、需要等待多长时间有关。Latch是一种能够极快地被获取和释放的锁，它通常用于保护描述buffer cache中block的数据结构。与每个latch相联系的还有一个清除过程，当持有latch的进程成为死进程时，该清除过程就会被调用。Latch还具有相关级别，用于防止死锁，一旦一个进程在某个级别上得到一个latch，它就不可能再获得等同或低于该级别的latch。
本视图保存自实例启动各类栓锁的统计信息。常用于当v$session_wait中发现栓锁竞争时鉴别SGA区中问题所在区域。
v$latch表的每一行包括了对不同类型latch的统计，每一列反映了不同类型的latch请求的活动情况。不同类型的latch请求之间的区别在于，当latch不可立即获得时，请求进程是否继续进行。按此分类，latch请求的类型可分为两类：willing-to-wait和immediate。
l Willing-to-wait：是指如果所请求的latch不能立即得到，请求进程将等待一很短的时间后再次发出请求。进程一直重复此过程直到得到latch。
l Immediate：是指如果所请求的latch不能立即得到，请求进程就不再等待，而是继续执行下去。
V$LATCH中的常用列：
l NAME：latch名称
l IMMEDIATE_GETS：以Immediate模式latch请求数
l IMMEDIATE_MISSES：请求失败数
l GETS：以Willing to wait请求模式latch的请求数
l MISSES：初次尝试请求不成功次数
l SPIN_GETS：第一次尝试失败，但在以后的轮次中成功
l SLEEP[x]：成功获取前sleeping次数
l WAIT_TIME：花费在等待latch的时间
V$LATCH中的连接列
Column View Joined Column(s)
--------------------- ------------------------------ ------------------------
NAME/LATCH# V$LATCH_CHILDREN NAME/LATCH#
NAME V$LATCHHOLDER NAME
NAME/LATCH# V$LATCHNAME NAME/LATCH#
NAME V$LATCH_MISSES PARENT_NAME
示例：
下列的示例中，创建一个表存储查询自v$latch的数据：
CREATE TABLE snap_latch as SELECT 0 snap_id, sysdate snap_date, a.* FROM V$LATCH a;
ALTER TABLE snap_latch add (constraint snap_filestat primary key (snap_id, name));
最初，snap_id被置为0，稍后，snap_latch表的snap_id列被更新为1：
INSERT INTO snap_latch SELECT 1, sysdate, a.* FROM V$LATCH a;
注意你通过sql语句插入记录时必须增加snap_id的值。
在你连续插入记录之后，使用下列的select语句列出统计。注意0不能成为被除数。
SELECT SUBSTR(a.name,1,20) NAME, (a.gets-b.gets)/1000 "Gets(K)",
(a.gets-b.gets)/(86400*(a.snap_date-b.snap_date)) "Get/s",
DECODE ((a.gets-b.gets), 0, 0, (100*(a.misses-b.misses)/(a.gets-b.gets))) MISS,
DECODE ((a.misses-b.misses), 0, 0,
(100*(a.spin_gets-b.spin_gets)/(a.misses-b.misses))) SPIN,
(a.immediate_gets-b.immediate_gets)/1000 "Iget(K)",
(a.immediate_gets-b.immediate_gets)/ (86400*(a.snap_date-b.snap_date)) "IGet/s",
DECODE ((a.immediate_gets-b.immediate_gets), 0, 0,
(100*(a.immediate_misses-b.immediate_misses)/ (a.immediate_gets-b.immediate_gets)))
IMISS
FROM snap_latch a, snap_latch b
WHERE a.name = b.name
AND a.snap_id = b.snap_id + 1
AND ( (a.misses-b.misses) > 0.001*(a.gets-b.gets)
or (a.immediate_misses-b.immediate_misses) >
0.001*(a.immediate_gets-b.immediate_gets))
ORDER BY 2 DESC;
下例列出latch统计项，miss列小于0.1%的记录已经被过滤。
NAME Gets(K) Get/s MISS SPIN IGets(K) IGet/s IMISS
------------------ -------- ------- ----- ------ -------- ------- -----
cache buffers chai 255,272 69,938 0.4 99.9 3,902 1,069 0.0
library cache 229,405 62,851 9.1 96.9 51,653 14,151 3.7
shared pool 24,206 6,632 14.1 72.1 0 0 0.0
latch wait list 1,828 501 0.4 99.9 1,836 503 0.5
row cache objects 1,703 467 0.7 98.9 1,509 413 0.2
redo allocation 984 270 0.2 99.7 0 0 0.0
messages 116 32 0.2 100.0 0 0 0.0
cache buffers lru 91 25 0.3 99.0 7,214 1,976 0.3
modify parameter v 2 0 0.1 100.0 0 0 0.0
redo copy 0 0 92.3 99.3 1,460 400 0.0
什么时候需要检查latch统计呢？看下列项：
l misses/gets的比率是多少
l 获自spinning的misses的百分比是多少
l latch请求了多少次
l latch休眠了多少次
Redo copy latch看起来有很高的的失误率，高达92.3%。不过，我们再仔细看的话，Redo copy latches是获自immediate模式。immediate模式的数值看起来还不错，并且immediate模式只有个别数大于willing to wait模式。所以Redo copy latch其实并不存在竞争。不过，看起来shared pool和library cache latches可能存在竞争。考虑执行一条查询检查latches的sleeps以确认是否确实存在问题。
latch有40余种，但作为DBA关心的主要应有以下几种：
l Cache buffers chains latch：当用户进程搜索SGA寻找database cache buffers时需要使用此latch。
l Cache buffers LRU chain latch：当用户进程要搜索buffer cache中包括所有 dirty blocks的LRU (least recently used) 链时使用该种latch。
l Redo log buffer latch：这种latch控制redo log buffer中每条redo entries的空间分配。
l Row cache objects latch：当用户进程访问缓存的数据字典数值时，将使用Row cache objects latch。
Latches调优
不要调整latches。如果你发现latch存在竞争，它可能是部分SGA资源使用反常的征兆。要修正问题所在，你更多的是去检查那部分SGA资源使用的竞争情况。仅仅从v$latch是无法定位问题所在的。
关于latches的更多信息可以浏览Oracle Database Concepts。
第十一篇-(2)-V$LATCH_CHILDREN 2007.6.6
数据库中有些类别的latches拥有多个。V$LATCH中提供了每个类别的总计信息。如果想看到单个latch，你可以通过查询本视图。
例如：
select name,count(*) ct from v$Latch_children group by name order by ct desc;
与v$latch相比，除多child#列外，其余列与之同，不详述~~
本视图提供对象在library cache(shared pool)中对象统计，提供比v$librarycache更多的细节，并且常用于找出shared pool中的活动对象。
v$db_object_cache中的常用列：
l OWNER：对象拥有者
l NAME：对象名称
l TYPE：对象类型(如，sequence,procedure,function,package,package body,trigger)
l KEPT：告知是否对象常驻shared pool(yes/no)，有赖于这个对象是否已经利用PL/SQL 过程DBMS_SHARED_POOL.KEEP“保持”（永久固定在内存中）
l SHARABLE_MEM：共享内存占用
l PINS：当前执行对象的session数
l LOCKS：当前锁定对象的session数
瞬间状态列：
下列列保持对象自初次加载起的统计信息：
l LOADS：对象被加载次数。
示例：
1.shared pool执行以及内存使用总计
下列查询显示出shared pool内存对不同类别的对象
同时也显示是否有对象通过DBMS_SHARED_POOL.KEEP()过程常驻shared pool。
SELECT type, kept, COUNT(*), SUM(sharable_mem)
FROM V$DB_OBJECT_CACHE
GROUP BY type, kept;
2.通过载入次数找出对象
SELECT owner, name sharable_mem, kept, loads
FROM V$DB_OBJECT_CACHE
WHERE loads > 1 ORDER BY loads DESC;
3.找出使用的内存超过10M并且不在常驻内存的对象。
SELECT owner, name, sharable_mem, kept
FROM V$DB_OBJECT_CACHE
WHERE sharable_mem > 102400 AND kept = 'NO'
ORDER BY sharable_mem DESC;
本视图记录各文件物理I/O信息。如果瓶颈与I/O相关，可用于分析发生的活动I/O事件。V$FILESTAT显示出数据库I/O的下列信息(不包括日志文件)：
l 物理读写数
l 块读写数
l I/O读写总耗时
以上数值自实例启动即开始记录。如果获取了两个快照，那么二者之间的差异即是这一时间段内活动I/O统计。
V$FILESTAT中的常用列：
l FILE#：文件序号；
l PHYRDS：已完成的物理读次数；
l PHYBLKRD：块读取数；
l PHYWRTS：DBWR完成的物理写次数；
l PHYBLKWRT：写入磁盘的块数；
V$FILESTAT注意项：
l 因为multiblock读调用，物理读数和数据块读数有可能不同；
l 因为进程直写，物理写和数据块写也可能不一致；
l Sum(physical blocks read) 近似于v$sysstat中的physical reads；
l Sum(physical blocks written) 近似于v$sysstat中的physical writes；
l 数据读(由缓存读比直读好)由服务进程处理。从buffer cache写只能由DBWR进行，直写由服务进程处理。
V$FILESTAT中的连接列
Column View Joined Column(s)
----------- ------------------------- -------------------------
FILE# DBA_DATA_FILES FILE_ID
FILE# V$DATAFILE FILE#
示例：
1.获得数据文件物理读写和数据块读写信息：
select df.tablespace_name name,
df.file_name "file",
f.phyrds pyr,
f.phyblkrd pbr,
f.phywrts pyw,
f.phyblkwrt pbw
from v$filestat f, dba_data_files df where f.file# = df.file_id
order by df.tablespace_name;
注意：尽管oracle记录的读写次数非常精确，但如果数据库运行在Unix文件系统(UFS)有可能不能表现真实的磁盘读写，例如，读次数可能并非真实的磁盘读，而是UFS缓存。不过裸设备的读写次数应该是比较精准的。
本视图显示运行超过6秒的操作的状态。包括备份，恢复，统计信息收集，查询等等。
要监控查询执行进展状况，你必须使用cost-based优化方式，并且：
l 设置TIMED_STATISTICS或SQL_TRACE参数值为true。
l 通过ANALYZE或DBMS_STATS数据包收集对象统计信息。
你可以通过DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS过程添加application-specific长运行操作信息到本视图。关于DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS的更多信息可以浏览：Oracle Supplied PL/SQL Packages and Types Reference。
V$SESSION_LONGOPS列说明
l SID：Session标识
l SERIAL#：Session串号
l OPNAME：操作简要说明
l TARGET：操作运行所在的对象
l TARGET_DESC：目标对象说明
l SOFAR：至今为止完成的工作量
l TOTALWORK：总工作量
l UNITS：工作量单位
l START_TIME：操作开始时间
l LAST_UPDATE_TIME：统计项最后更新时间
l TIME_REMAINING：预计完成操作的剩余时间(秒)
l ELAPSED_SECONDS：从操作开始总花费时间(秒)
l CONTEXT：前后关系
l MESSAGE：统计项的完整描述
l USERNAME：执行操作的用户ID
l SQL_ADDRESS：用于连接查询的列
l SQL_HASH_VALUE：用于连接查询的列
l QCSID：
示例：
找一较大表，确认该表查询将超过6秒，哎呀让它快咱没把握，让它慢这可是我的强项啊~~
SQL> set timing on
SQL> create table ttt as select level lv,rownum rn from dual connect by level<10000000; --创建一个临时表
Table created
Executed in 19.5 seconds
SQL> commit;
Commit complete
Executed in 0 seconds
SQL> select * from (select * from ttt order by lv desc) where rownum<2; --执行一个费时的查询
LV RN
---------- ----------
9999999 9999999
Executed in 9.766 seconds --哈哈，成功超过6秒
SQL> select sid,opname,sofar,totalwork,units,sql_hash_value from v$session_longops; ----看看v$session_longops中是不是已经有记录了
SID OPNAME SOFAR TOTALWORK UNITS SQL_HASH_VALUE
---------- ---------------------------------------------------------------- ---------- ---------- -------------------------------- --------------
10 Table Scan 47276 47276 Blocks 2583310173
Executed in 0.047 seconds
SQL> select a.sql_text from v$sqlarea a,v$session_longops b where a.HASH_VALUE=b.SQL_HASH_VALUE; --通过hash_value联系查询出刚执行的查询语句。
SQL_TEXT
--------------------------------------------------------------------------------
select * from (select * from ttt order by lv desc) where rownum<2
Executed in 0.063 seconds
摘要:
这个视图列出Oracle 服务器当前拥有的锁以及未完成的锁或栓锁请求。如果你觉着session在等待等待事件队列那你应该检查本视图。如果你发现session在等待一个锁。那么按如下先后顺序：
1. 使用V$LOCK找出session持有的锁。
2. ...
阅读全文