摘要: 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 的未提交的改變不被該語句處理?？?br />
以想象：當一個長時間的查詢正在執行時，若其他會話改變了該查詢要查詢的某個數據塊，
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）
當當前回滾段區的所有塊用完而事務還需要更多的回滾空間時，回滾段的指針將移到下
一個區。當最后一個區用完，指針將移到第一個區的前面?；貪L段指針移到下一個區的前提
是下一個區沒有活動的事務，同時指針不能跨區。當下一個區正在使用時，事務將為回滾段
分配一個新的區，這種分配稱為回滾段的擴展?；貪L段將一直擴展到該回滾段區的個數到達
回滾段的參數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. ...
閱讀全文