本文是Oracle ACE總監Syed Jaffer Hussain對Oracle數據庫12c的一些新特性總結，包括數據庫管理、RMAN、高可用性以及性能調優等內容。linux
主要內容:
1. 在線遷移活躍的數據文件
2. 表分區或子分區的在線遷移
3. 不可見字段
4. 相同字段上的多重索引
5. DDL日誌
6. 臨時undo
7. 新的備份用戶特權
8. 如何在RMAN中執行SQL語句
9. RMAN中的表級別恢復
10. PGA的大小限制問題
11. 對錶分區維護的加強
12. 數據庫升級的改進
13. 經過網絡恢復數據文件
14. 對Data Pump的加強
15. 實時自動數據診斷監視器(ADDM)
16. 併發統計信息收集
sql
1. 在線重命名和從新定位活躍數據文件shell
不 同於以往的版本，在Oracle數據庫12c R1版本中對數據文件的遷移或重命名再也不須要太多繁瑣的步驟，即把表空間置爲只讀模式，接下來是對數據文件進行離線操做。在12c R1中，能夠使用ALTER DATABASE MOVE DATAFILE這樣的SQL語句對數據文件進行在線重命名和移動。而當此數據文件正在傳輸時，終端用戶能夠執行查詢，DML以及DDL方面的任務。另 外，數據文件能夠在存儲設備間遷移，如從非ASM遷移至ASM，反之亦然。數據庫
重命名數據文件：緩存
| 1 |
SQL> ALTER DATABASE MOVE DATAFILE '/u00/data/users01.dbf' TO '/u00/data/users_01.dbf'; |
從非ASM遷移數據文件至ASM：sass
| 1 |
SQL> ALTER DATABASE MOVE DATAFILE '/u00/data/users_01.dbf' TO '+DG_DATA'; |
將數據文件從一個ASM磁盤羣組遷移至另外一個ASM磁盤羣組：安全
| 1 |
SQL> ALTER DATABASE MOVE DATAFILE '+DG_DATA/DBNAME/DATAFILE/users_01.dbf ' TO '+DG_DATA_02'; |
在數據文件已存在於新路徑的狀況下，以相同的命名將其覆蓋：性能優化
| 1 |
SQL> ALTER DATABASE MOVE DATAFILE '/u00/data/users_01.dbf' TO '/u00/data_new/users_01.dbf' REUSE; |
複製文件到一個新路徑，同時在原路徑下保留其拷貝bash
| 1 |
SQL> ALTER DATABASE MOVE DATAFILE '/u00/data/users_01.dbf' TO '/u00/data_new/users_01.dbf' KEEP; |
當經過查詢v$session_longops動態視圖來移動文件時，你能夠監控這一過程。另外，你也能夠引用alert.log，Oracle會在其中記錄具體的行爲。服務器
2. 表分區或子分區的在線遷移
在Oracle 12c R1中遷移表分區或子分區到不一樣的表空間再也不須要複雜的過程。與以前版本中未分區表進行在線遷移相似，表分區或子分區能夠在線或是離線遷移至一個不一樣的表 空間。當指定了ONLINE語句，全部的DML操做能夠在沒有任何中斷的狀況下，在參與這一過程的分區或子分區上執行。與此相反，分區或子分區遷移若是是 在離線狀況下進行的，DML操做是不被容許的。
示例：
| 1 |
SQL> ALTER TABLE table_name MOVE PARTITION|SUBPARTITION partition_name TO tablespace tablespace_name; |
| 2 |
SQL> ALTER TABLE table_name MOVE PARTITION|SUBPARTITION partition_name TO tablespace tablespace_name UPDATE INDEXES ONLINE; |
第一個示例是用來在離線情況下將一個表分區或子分區遷移至一個新的表空間。第二個示例是在線遷移表分區或子分區並維護表上任何本地或全局的索引。此外，當使用ONLINE語句時，DML操做是不會中斷的。
重要提示:：
UPDATE INDEXES語句能夠避免出現表中任何本地或全局索引沒法使用的狀況。
表的在線遷移限制也適用於此。
引入加鎖機制來完成這一過程，固然它也會致使性能降低並會產生大量的redo，這取於分區和子分區的大小。
3. 不可見字段
在Oracle 11g R1中，Oracle以不可見索引和虛擬字段的形式引入了一些不錯的加強特性。繼承前者併發揚光大，Oracle 12c R1中引入了不可見字段思想。在以前的版本中，爲了隱藏重要的數據字段以免在通用查詢中顯示，咱們每每會建立一個視圖來隱藏所需信息或應用某些安全條 件。
在12c R1中，你能夠在表中建立不可見字段。當一個字段定義爲不可見時，這一字段就不會出如今通用查詢中，除非在SQL語句或條件中有顯式的說起這一字段，或是在表定義中有DESCRIBED。要添加或是修改一個不可見字段是很是容易的，反之亦然。
| 1 |
SQL> CREATE TABLE emp (eno number(6), ename name varchar2(40), sal number(9) INVISIBLE); |
| 2 |
SQL> ALTER TABLE emp MODIFY (sal visible); |
你必須在INSERT語句中顯式說起不可見字段名以將不可見字段插入到數據庫中。虛擬字段和分區字段一樣也能夠定義爲不可見類型。但臨時表，外部表和集羣表並不支持不可見字段。
4. 相同字段上的多重索引
在Oracle 12c R1以前，一個字段是沒法以任何形式擁有多個索引的。或許有人會想知道爲何一般一個字段須要有多重索引，事實上須要多重索引的字段或字段集合是不少的。 在12c R1中，只要索引類型的形式不一樣，一個字段就能夠包含在一個B-tree索引中，一樣也能夠包含在Bitmap索引中。注意，只有一種類型的索引是在給定 時間可用的。
5. DDL日誌
在 以前的版本中沒有可選方法來對DDL操做進行日誌記錄。而在12c R1中，你如今能夠將DDL操做寫入xml和日誌文件中。這對於瞭解誰在什麼時間執行了create或drop命令是十分有用的。要開啓這一功能必須對 ENABLE_DDL_LOGGING 初始參數加以配置。這一參數能夠在數據庫或會話級加以設置。當此參數爲啓用狀態，全部的DDL命令會記錄在$ORACLE_BASE/diag /rdbms/DBNAME/log|ddl 路徑下的xml和日誌文件中。一個xml中包含DDL命令，IP地址，時間戳等信息。這能夠幫助肯定在何時對用戶或表進行了刪除亦或是一條DDL語句 在什麼時候觸發。
開啓DDL日誌功能
| 1 |
SQL> ALTER SYSTEM|SESSION SET ENABLE_DDL_LOGGING=TRUE; |
如下的DDL語句可能會記錄在xml或日誌文件中：
| 1 |
CREATE|ALTER|DROP|TRUNCATE TABLE |
| 3 |
CREATE|ALTER|DROP PACKAGE|FUNCTION|VIEW|SYNONYM|SEQUENCE |
6. 臨時undo
每 個Oracle數據庫包含一組與系統相關的表空間，例如SYSTEM，SYSAUX，UNDO & TEMP，而且它們在Oracle數據庫中每一個都用於不一樣的目的。在Oracle 12c R1以前，undo記錄是由臨時表產生並存儲在undo表空間中的，這更相似於一個通用或持久的表撤銷記錄。然而，因爲在12c R1中引入了臨時undo功能，那些臨時undo記錄如今就能夠存儲在臨時表中，而不是存儲在undo表空間中。臨時undo的主要好處在於：因爲信息不 會寫入undo日誌，undo表空間的開銷得以減小而且產生的undo數據會更少。而對於在會話級仍是數據庫級開啓臨時undo功能你是能夠靈活選擇的。
啓用臨時undo功能
要使用這一新功能，須要作如下設置：
兼容性參數必須設置爲12.0.0或更高
啓用 TEMP_UNDO_ENABLED 初始化參數
因爲臨時undo記錄如今是存儲在一個臨時表空間中的，你須要有足夠的空間來建立這一臨時表空間
對於會話級，你能夠使用：ALTER SYSTEM SET TEMP_UNDO_ENABLE=TRUE;
查詢臨時undo信息
如下所列的字典視圖是用來查看或查詢臨時undo數據相關統計信息的：
要禁用此功能，你只需作如下設置：
| 1 |
SQL> ALTER SYSTEM|SESSION SET TEMP_UNDO_ENABLED=FALSE; |
7. 備份特定用戶特權
在11g R2中，引入了SYSASM特權來執行ASM的特定操做。一樣地，在12c中引入了SYSBACKUP特權用來在 RMAN中執行備份和恢復命令。所以，你能夠在數據庫中建立一個本地用戶並在不授予其SYSDBA權限的狀況下，經過授予SYSBACKUP權限讓其可以 在RMAN中執行備份和恢復相關的任務。
| 1 |
$ ./rman target "username/password as SYSBACKUP" |
8. 如何在RMAN中執行SQL語句
在12c中，你能夠在不須要SQL前綴的狀況下在RMAN中執行任何SQL和PL/SQL命令，即你能夠從RMAN直接執行任何SQL和PL/SQL命令。以下即是在RMAN中執行SQL語句的示例
| 1 |
RMAN> SELECT username,machine FROM v$session; |
| 2 |
RMAN> ALTER TABLESPACE users ADD DATAFILE SIZE 121m; |
9. RMAN中的表恢復和分區恢復
Oracle 數據庫備份主要分爲兩類：邏輯和物理備份。每種備份類型都有其自身的優缺點。在以前的版本中，利用現有物理備份來恢復表或分區是不可行的。爲了恢復特定對 象，邏輯備份是必需的。對於12c R1，你能夠在發生drop或truncate的狀況下從RMAN備份將一個特定的表或分區恢復到某個時間點或SCN。
當經過RMAN發起一個表或分區恢復時，大概流程是這樣的：
肯定要恢復表或分區所需的備份集
在恢復表或分區的過程當中，一個輔助數據庫會臨時設置爲某個時間點利用數據泵將所需表或分區導出到一個dumpfile
你能夠從源數據庫導入表或分區(可選)
在恢復過程當中進行重命名操做
如下是一個經過RMAN對錶進行時間點恢復的示例(確保你已經對稍早的數據庫進行了完整備份)：
| 1 |
RMAN> connect target "username/password as SYSBACKUP"; |
| 2 |
RMAN> RECOVER TABLE username.tablename UNTIL TIME 'TIMESTAMP…' |
| 3 |
AUXILIARY DESTINATION '/u01/tablerecovery' |
| 4 |
DATAPUMP DESTINATION '/u01/dpump' |
| 5 |
DUMP FILE 'tablename.dmp' |
| 6 |
NOTABLEIMPORT -- this option avoids importing the table automatically.(此選項避免自動導入表) |
| 7 |
REMAP TABLE 'username.tablename': 'username.new_table_name'; -- can rename table with this option.(此選項能夠對錶重命名) |
重要提示:：
確保對於輔助數據庫在/u01文件系統下有足夠的可用空間，同時對數據泵文件也有一樣保證
必需要存在一份完整的數據庫備份，或者至少是要有SYSTEM相關的表空間備份
如下是在RMAN中應用表或分區恢復的限制和約束：
SYS用戶表或分區沒法恢復
存儲於SYSAUX和SYSTEM表空間下的表和分區沒法恢復
當REMAP選項用來恢復的表包含NOT NULL約束時，恢復此表是不可行的
10. 限制PGA的大小
在Oracle 12c R1以前，沒有選項能夠用來限制和控制PGA的大小。雖然你設置某個大小爲PGA_AGGREGATE_TARGET 的初始參數，Oracle會根據工做負載和需求來動態地增大或減少PGA的大小。而在12c中，你能夠經過開啓自動PGA管理來對PGA設定硬性限制，這 須要對PGA_AGGREGATE_LIMIT 參數進行設置。所以，你如今能夠經過設置新的參數來對PGA設定硬性限制以免過分使用PGA。
| 1 |
SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=2G; |
| 2 |
SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=0; --disables the hard limit |
重要提示:：
當超過了當前PGA的限制，Oracle會自動終止/停止會話或進程以保持最合適的PGA內存。
11. 對錶分區維護的加強
我解釋瞭如何在線或是離線狀態下遷移一個表分區或子分區到另外一個不一樣的表空間。在本文中，主要介紹表分區其餘方面的改進。
添加多個新分區
在Oracle 12c R1以前，一次只可能添加一個新分區到一個已存在的分區表。要添加一個以上的新分區，須要對每一個新分區都單獨執行一次ALTER TABLE ADD PARTITION語句。而Oracle 12c只須要使用一條單獨的ALTER TABLE ADD PARTITION 命令就能夠添加多個新分區，這增長了數據庫靈活性。如下示例說明了如何添加多個新分區到已存在的分區表：
| 1 |
SQL> CREATE TABLE emp_part |
| 2 |
(eno number(8), ename varchar2(40), sal number (6)) |
| 3 |
PARTITION BY RANGE (sal) |
| 4 |
(PARTITION p1 VALUES LESS THAN (10000), |
| 5 |
PARTITION p2 VALUES LESS THAN (20000), |
| 6 |
PARTITION p3 VALUES LESS THAN (30000) |
添加兩個新分區：
| 1 |
SQL> ALTER TABLE emp_part ADD PARTITION |
| 2 |
PARTITION p4 VALUES LESS THAN (35000), |
| 3 |
PARTITION p5 VALUES LESS THAN (40000); |
一樣，只要MAXVALUE分區不存在，你就能夠添加多個新分區到一個列表和系統分區表。
如何刪除和截斷多個分區/子分區
做 爲數據維護的一部分，DBA一般會在一個分區表上進行刪除或截斷分區的維護任務。在12c R1以前，對於一個已存在的分區表一次只可能刪除或截斷一個分區。而對於Oracle 12c， 能夠用單條ALTER TABLE table_name {DROP|TRUNCATE} PARTITIONS命令來撤銷或合併多個分區和子分區。
下例說明了如何在一個已存在分區表上刪除或截斷多個分區：
| 1 |
SQL> ALTER TABLE emp_part DROP PARTITIONS p4,p5; |
| 2 |
SQL> ALTER TABLE emp_part TRUNCATE PARTITONS p4,p5; |
要保持索引更新，使用UPDATE INDEXES或UPDATE GLOBAL INDEXES語句，以下所示：
| 1 |
SQL> ALTER TABLE emp_part DROP PARTITIONS p4,p5 UPDATE GLOBAL INDEXES; |
| 2 |
SQL> ALTER TABLE emp_part TRUNCATE PARTITIONS p4,p5 UPDATE GLOBAL INDEXES; |
若是你在不使用UPDATE GLOBAL INDEXES 語句的狀況下刪除或截斷一個分區，你能夠在USER_INDEXES或USER_IND_PARTITIONS 字典視圖下查詢ORPHANED_ENTRIES 字段以找出是否有索引包含任何的過時條目。
將單個分區分割爲多個新分區
在12c中新加強的SPLIT PARTITION 語句可讓你只使用一個單獨命令將一個特定分區或子分區分割爲多個新分區。下例說明了如何將一個分區分割爲多個新分區：
| 01 |
SQL> CREATE TABLE emp_part |
| 02 |
(eno number(8), ename varchar2(40), sal number (6)) |
| 03 |
PARTITION BY RANGE (sal) |
| 04 |
(PARTITION p1 VALUES LESS THAN (10000), |
| 05 |
PARTITION p2 VALUES LESS THAN (20000), |
| 06 |
PARTITION p_max (MAXVALUE) |
| 08 |
SQL> ALTER TABLE emp_part SPLIT PARTITION p_max INTO |
| 09 |
(PARTITION p3 VALUES LESS THAN (25000), |
| 10 |
PARTITION p4 VALUES LESS THAN (30000), PARTITION p_max); |
將多個分區合併爲一個分區
你能夠使用單條ALTER TBALE MERGE PARTITIONS 語句將多個分區合併爲一個單獨分區：
| 01 |
SQL> CREATE TABLE emp_part |
| 02 |
(eno number(8), ename varchar2(40), sal number (6)) |
| 03 |
PARTITION BY RANGE (sal) |
| 04 |
(PARTITION p1 VALUES LESS THAN (10000), |
| 05 |
PARTITION p2 VALUES LESS THAN (20000), |
| 06 |
PARTITION p3 VALUES LESS THAN (30000), |
| 07 |
PARTITION p4 VALUES LESS THAN (40000), |
| 08 |
PARTITION p5 VALUES LESS THAN (50000), |
| 09 |
PARTITION p_max (MAXVALUE) |
| 11 |
SQL> ALTER TABLE emp_part MERGE PARTITIONS p3,p4,p5 INTO PARTITION p_merge; |
若是分區範圍造成序列，你能夠使用以下示例：
| 1 |
SQL> ALTER TABLE emp_part MERGE PARTITIONS p3 TO p5 INTO PARTITION p_merge; |
12. 數據庫升級改進
每當一個新的Oracle版本發佈，DBA所要面臨的挑戰就是升級過程。該部分我將介紹12c中引入的針對升級的兩個改進。
預升級腳本
在12c R1中，原有的utlu[121]s.sql 腳本由一個大爲改善的預升級信息腳本preupgrd.sql所取代。除了預升級檢查驗證，此腳本還能以修復腳本的形式解決在升級過程先後出現的各類問題。
可 以對產生的修復腳本加以執行來解決不一樣級別的問題，例如，預升級和升級後的問題。當手動升級數據庫時，腳本必須在實際升級過程初始化以前加以手動執行。然 而，當使用DBUA工具來進行數據庫升級時，它會將預升級腳本做爲升級過程的一部分加以自動執行，並且會提示你去執行修復腳本以防止報錯。
如何執行腳本：
| 1 |
SQL> @$ORACLE_12GHOME/rdbms/admin/preupgrd.sql |
以上腳本會產生一份日誌文件以及一個[pre/post]upgrade_fixup.sql 腳本。全部這些文件都位於$ORACLE_BASE/cfgtoollogs 目錄下。在你繼續真正的升級過程以前，你應該瀏覽日誌文件中所提到的建議並執行腳本以修復問題。
注意：你要確保將preupgrd.sql和utluppkg.sql 腳本從12c Oracle的目錄home/rdbms/admin directory拷貝至當前的Oracle的database/rdbms/admin路徑。
並行升級功能
數據庫升級時間的長短取決於數據庫上所配置的組件數量，而不是數據庫的大小。在以前的版本中，咱們是沒法並行運行升級程序，從而快速完成整個升級過程的。
在12c R1中，原有的catupgrd.sql 腳本由catctl.pl 腳本(並行升級功能)替代，如今咱們能夠採用並行模式運行升級程序了。
如下流程說明了如何初始化並行升級功能(3個過程);你須要在升級模式下在啓動數據庫後運行這一腳本
| 1 |
cd $ORACLE_12_HOME/perl/bin |
| 2 |
$ ./perl catctl.pl –n 3 -catupgrd.sql |
以上兩個步驟須要在手動升級數據庫時運行。而DBUA也繼承了這兩個新變化。
13. 經過網絡恢復數據文件
在12c R1中另外一個重要的加強是，你如今能夠在主數據庫和備用數據庫之間用一個服務名從新得到或恢復數據文件、控制文件、參數文件、表空間或整個數據庫。這對於同步主數據庫和備用數據庫極爲有用。
當 主數據庫和備用數據庫之間存在至關大的差別時，你再也不須要複雜的前滾流程來填補它們之間的差別。RMAN可以經過網絡執行備用恢復以進行增量備份，而且可 以將它們應用到物理備用數據庫。你能夠用服務名直接將所需數據文件從備用點拷貝至主站，這是爲了防止主數據庫上數據文件、表空間的丟失，或是沒有真正從備 份集恢復數據文件。
如下流程演示瞭如何用此新功能執行一個前滾來對備用數據庫和主數據庫進行同步：
在物理備用數據庫上：
| 1 |
./rman target "username/password@standby_db_tns as SYSBACKUP" |
| 2 |
RMAN> RECOVER DATABASE FROM SERVICE primary_db_tns USING COMPRESSED BACKUPSET; |
以 上示例使用備用數據庫上定義的primary_db_tns 鏈接字符串鏈接到主數據庫，而後執行了一個增量備份，再將這些增量備份傳輸至備用目的地，接着將應用這些文件到備用數據庫來進行同步。然而，須要確保已經 對primary_db_tns 進行了配置，即在備份數據庫端將其指向主數據庫。
在如下示例中，我將演示一個場景經過從備用數據庫獲取數據文件來恢復主數據庫上丟失的數據文件：
在主數據庫上：
| 1 |
./rman target "username/password@primary_db_tns as SYSBACKUP" |
| 2 |
RMAN> RESTORE DATAFILE ‘+DG_DISKGROUP/DBANME/DATAFILE/filename’FROM SERVICE standby_db_tns; |
14. 對Data Pump的加強
Data Pump版本有了很多有用的改進，例如在導出時將視圖轉換爲表，以及在導入時關閉日誌記錄等。
關閉redo日誌的生成
Data Pump中引入了新的TRANSFORM選項，這對於對象在導入期間提供了關閉重作生成的靈活性。當爲TRANSFORM選項指定了 DISABLE_ARCHIVE_LOGGING 值，那麼在整個導入期間，重作生成就會處於關閉狀態。這一功能在導入大型表時緩解了壓力，而且減小了過分的redo產生，從而加快了導入。這一屬性還可應 用到表以及索引。如下示例演示了這一功能：
| 1 |
$ ./impdp directory=dpump dumpfile=abcd.dmp logfile=abcd.log TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y |
將視圖轉換爲表
這是Data Pump中另一個改進。有了VIEWS_AS_TABLES 選項，你就能夠將視圖數據載入表中。如下示例演示瞭如何在導出過程當中將視圖數據載入到表中：
| 1 |
$ ./expdp directory=dpump dumpfile=abcd.dmp logfile=abcd.log views_as_tables=my_view:my_table |
15. 實時自動數據診斷監視器 (ADDM) 分析
經過使用諸如AWR、ASH以及ADDM之類的自動診斷工具來分析數據庫的健康情況，是每一個DBA日程工做的一部分。儘管每種工具均可以在多個層面衡量數據庫的總體健康情況和性能，但沒有哪一個工具能夠在數據庫反應遲鈍或是徹底掛起的時候使用。
當數據庫反應遲鈍或是掛起狀態時，並且你已經配置了Oracle 企業管理器 12c的雲控制，你就能夠對嚴重的性能問題進行診斷。這對於你瞭解當前數據庫發生了什麼情況有很大幫助，並且還可以對此問題給出解決方案。
如下步驟演示瞭如何在Oracle 企業管理器 12c上分析數據庫狀態：
在訪問數據庫訪問主頁面從Performance菜單選擇Emergency Monitoring 選項。這會顯示掛起分析表中排名靠前的阻止會話。
在Performance菜單選擇Real-Time ADDM 選項來執行實時ADDM分析。
在收集了性能數據後，點擊Findings標籤以得到全部結果的交互總結。
16. 同時在多個表上收集統計數據
在 以前的Oracle數據庫版本中，當你執行一個DBMS_STATS 程序來收集表、索引、模式或者數據庫級別的統計數據時，Oracle習慣於一次一個表的收集統計數據。若是表很大，那麼推薦你採用並行方式。在12c R1中，你如今能夠同時在多個表、分區以及子分區上收集統計數據。在你開始使用它以前，你必須對數據庫進行如下設置以開啓此功能：
| 1 |
SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='DEFAULT_MAIN'; |
| 2 |
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=4; |
| 3 |
SQL> EXEC DBMS_STATS.SET_GLOBAL_PREFS('CONCURRENT', 'ALL'); |
| 4 |
SQL> EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SCOTT'); |
發表在 ORACLE | 標籤爲 12C | 留下評論
發表於 2013 年 8 月 12 日 由 周應侯
一、buffer busy waits
從本質上來說，這個等待事件的產生僅僅說明了一個會話在等待一個Buffer（數據塊），可是致使這現象的緣由倒是不少種，常見的兩種是：
1.當一個會話試圖修改一個數據塊，但這個數據塊正在被另外一個會話修改時。
2.當一個會話須要讀取一個數據塊，但這個數據塊正在被另外一個會話讀取到內從中時。
這裏須要解釋一個概念，Oracle操做的最小單位是塊（Block）,即便你要修改一條記錄，你也須要對這條記錄所在的這個數據塊作操做，當你對這個數據塊作修改的時候，其餘的會話將被阻止對這個數據塊上的數據做修改（即便其餘用戶修改的不是當前用戶修改的數據），可是能夠以一致性的方式讀來讀取這個數據塊，當前的用戶修改完這個數據塊後，將會當即釋放掉加載這個數據塊上的排他鎖定，這樣另外一個會話就能夠繼續修改它，修改操做是一個很是短暫的時間，這種加鎖的機制咱們在前面講過，它叫作Latch。
當一個會話修改一個數據塊時，是按照如下的步驟來完成的：
a、以排他的方式得到這個數據塊（Latch）
b、修改這個數據塊
c、釋放Latch
buffer busy waits等待事件常見於數據庫中存在熱塊的時候，當多個用戶頻繁的讀取或者修改一樣的數據塊時，這個等待事件就會產生，若是等待的時間很長，咱們在AWR或者Statpack報告中就能夠看到。
| 2 |
File#--等待訪問數據塊所在的文件id 號。 |
| 4 |
Id ----在10g以前，這個值表示一個等待事件的緣由，10g以後則表示等待事件的類別。 |
二、buffer latch
內存中數據塊的存放位置是記錄在一個Hash列表(cachebufferchains)當中的，當一個會話須要訪問某個數據塊時，它首先要搜索這個Hash列表，從列表中得到數據塊的地址，而後經過這個地址去訪問須要的數據塊，這個列表Oracle會使用一個Latch來保護它的完整性，當一個會話須要訪問這個列表時，須要獲取一個Latch，這有這樣，才能保證這個列表在這個回話的瀏覽當中不會發生改變。
產生buffer latch 的等待事件的主要緣由是：
一、buffer chains太長，致使會話搜索這個列表花費的時間太長，使其它的會話處於等待狀態。
二、一樣的數據塊被頻繁訪問，就是咱們一般說的熱塊問題。
若是buffer chains太長時，咱們能夠使用多個buffer pool的方式來建立更多了buffer chains，或者使用參數DB_BLOCK_LRU_LATCHES來增長Latch的數量，以便於更多的會話能夠得到Latch，這兩種方法能夠同時使用。
| 2 |
latchaddr---會話申請的lach 在SGA中的虛擬地址，經過如下的SQL能夠根據這個 |
| 5 |
from v$latch a, v$latchname b |
| 8 |
chain#----buffer chains hash列表中的索引值，當這個參數的值等於s0xfffffff時，說明當前的會話正在等待一個LRU latch。 |
三、controlfile parallel write
當數據庫中有多個控制文件的拷貝時，Oracle須要保證信息同步的寫到各個控制文件當中，這是一個並行的物理操做過程，所以稱做控制文件並行寫，當發生這樣的操做時，就會產生controlfile parallel write等待事件。
控制文件頻繁的寫入的緣由不少，好比：
a、日誌切換太過頻繁，致使控制文件信息相應的須要頻繁的更新。
b、系統I/O出現瓶頸，致使全部的I/O出現等待。
c、當系統出現日誌切換過於頻繁時，能夠考慮適當的增大日誌的文件的大小來下降日誌切
換頻率。
當系統出現大量的controlfile parallel write等待事件時，能夠經過好比下降控制文件的拷貝數量，將控制文件的拷貝存放在不一樣的物理磁盤上的方式來緩解I/O徵用。
| 2 |
Files----Oracle要寫入的控制文件個數。 |
| 3 |
Blocks----寫入控制文件的數據塊數目。 |
| 4 |
Requests----寫入控制請求的I/O次數。 |
四、controlfile sequential read
當數據庫須要讀取控制文件上的信息時，會出現這個等待事件，由於控制文件的信息時順序寫的，因此讀取的時候也是順序的，所以稱做控制文件順序讀，它常常發生在如下狀況下：
a、備份控制文件
b、RAC環境下不一樣實例之間控制文件的信息共享。
c、讀取控制文件的文件頭信息。
d、讀取控制文件其它信息。
| 2 |
File#----要讀取信息的控制文件的文件號。 |
| 3 |
Block#----讀取控制文件信息的起始數據塊號。 |
| 4 |
Blocks----須要讀取的控制文件數據塊數目。 |
五、db file parallel read
這是一個容易引發誤導的等待事件，實際上這個等待事件和並行操做（好比並行查詢，並行DML）沒有關係，這個事件發生在數據庫恢復的時候，當有一些數據塊須要恢復的時候，Oracle會以並行的方式把它們從數據文件中讀入到內存進行恢復操做。
| 3 |
Blocks----操做須要讀取的數據塊個數。 |
| 4 |
Requests----操做須要執行的I/O次數。 |
六、db file parallel write
這是一個後臺等待事件，它一樣和用戶的並行操做沒有關係，它是由後臺進程DBWR產生的，當後臺進程DBWR向磁盤上寫入髒數據時，會發生這個等待。
DBWR會批量的將髒數據並行的寫入到磁盤上相應的數據文件中，在這個批次做業完成以前，DBWR將出現這個等待事件，若是僅僅是這一個等待事件，對用戶的操做並無太大的影響，當伴隨着出現free buffer waits等待事件時，說明此時內存中可用的空間不足，這時候將會影響的用戶的操做，好比影響的用戶將數據塊讀入到內存中。
當出現dbfile parallel write等待事件時，能夠經過啓用操做系統的異步I/O的方式來緩解這個等待，當使用異步I/O時，DBWR再也不須要一直等到全部數塊都所有寫入到磁盤上，它只須要等到數據寫入到一個百分比以後，就能夠繼續進行進行後續的操做。
| 2 |
Requests-----操做須要執行的I/O次數。 |
七、db file scattered read
這個等待事件在實際生產數據庫中常常能夠看到，這是一個用戶操做引發的等待事件，當用戶發出每次I/O須要讀取多個數據塊這樣的SQL操做時，會產生這個等待事件，最常見的2中狀況是全表掃描（FTS–FULLTABLESCAN）和索引快速掃描（IFFS–INDEX FAST FULL SCAN）。
這個名稱中的scattered（發散）可能會致使不少人認爲它是以scattered的方式來讀取數據塊的，其實偏偏相反，當發生這種等待事件時，SQL的操做都是都是順序地讀取數據塊的，好比FTS或者IFFS方式（若是忽略須要讀取的數據塊已經存在內存中的狀況）。
其實這裏scattered指的是讀取的數據塊在內存中的存放方式，它們被讀取到內存中後，是以分散的方式存放在內存中，而不是連續的。
| 2 |
File#----要讀取的數據塊所在數據文件的文件號。 |
八、db file sequential read
這個等待事件在實際生產數據庫也很是常見，當Oracle須要每次I/O只讀取單個數據塊這樣的操做時，會產生這個等待事件，最多見的狀況有索引的訪問（除IFFS之外的方式）,回滾操做，以ROWID的方式訪問表中的數據，重建控制文件，對文件頭作DUMP等。
這裏面的sequential（順序）也並不是指的是Oracle按照順序的方式來訪問數據，和db file scatteredread同樣，它指的是讀取的數據塊在內存中是以連續的方式存放的，你們不要被誤導（至少有一段時間我是被誤導了的）。
| 2 |
File#----要讀取的數據塊所在數據文件的文件號。 |
| 4 |
Blocks----須要讀取的數據塊數目（在這裏應該等於1）。 |
九、db file single write
這個等待事件一般只發生在一種狀況，就是Oracle更新數據文件頭信息時（好比發生 Checkpiont）。
當這個等待事件很明顯時，要考慮是否是數據庫中的數據文件數量太大，致使Oracle須要花較長的時間來作全部文件頭的更新操做（Checkpoint）。
| 2 |
File#----須要更新的數據塊所在數據文件的文件號。 |
| 4 |
Blocks----須要更新的數據塊數目（一般來講應該等於1）。 |
十、direct path read
這個等待事件發生在會話將數據塊直接讀取到PGA當中而不是SGA中的狀況，這些被讀取的數據一般是這個會話私有的數據，因此不須要放到SGA做爲共享數據，由於這樣作沒有意義，這些數據一般是來自於臨時段上的數據，好比一個會話中SQL的排序數據，
並行執行過程當中間產生的數據，以及Hash join，Merge join產生的排序數據，由於這些數據只對當前會話的SQL操做有意義，因此不須要放到SGA當中。
當發生direct path read等待事件時，意味着磁盤上有大量的臨時數據產生，好比排序，並行執行等操做，或者意味着PGA中空閒空間不足。
| 2 |
descriptoraddress----一個指針，指向當前會話正在等待的一個directread I/O。 |
| 3 |
first dba---- descriptoraddress中最舊的一個I/O數據塊地址。 |
| 4 |
blockcnt----descriptoraddress上下文中涉及到的有效地buffer數量。 |
十一、direct path write
這個等待事件和direct path read正好相反，是會話將一些數據從PGA中直接寫入到磁盤文件上，而不通過SGA。
這種狀況一般發生在：
a、使用臨時表空間排序（內存排序不足）。
b、數據的直接加載（使用append方式加載數據）。
c、並行DML操做。
| 2 |
descriptoraddress----一個指針，指向當前會話正在等待的一個direct I/O。 |
| 3 |
first dba---- descriptoraddress中最舊的一個I/O數據塊地址。 |
| 4 |
blockcnt----descriptoraddress上下文中涉及到的有效地buffer數量。 |
十二、enqueue
enqueue這個詞實際上是lock（鎖）的另外一個描述語，咱們能夠把它做爲lock 來理解就會好理解的鎖。當咱們在AWR報告中發現長時間的enqueue等待事件時，說明數據庫中出現了阻塞和等待，咱們能夠關聯AWR報告中Enqueue Activity部分來肯定是哪種鎖定出現了長時間等待。
Oracle的enqueue有如下類型，第一列爲enqueue的縮寫，第二列是對縮寫的解釋：
| 01 |
BL, BufferCacheManagement |
| 03 |
CF, ControlfileTransaction |
| 04 |
CI, Cross-instance CallInvocation |
| 07 |
DL, DirectLoaderIndex Creation |
| 09 |
DR, DistributedRecoveryProcess |
| 10 |
DX, DistributedTransaction |
| 17 |
IV, LibraryCacheInvalidation |
| 18 |
JI, EnqueueusedduringAJVsnapshotrefresh |
| 21 |
KO, MultipleObjectCheckpoint |
| 22 |
L[A-P], LibraryCacheLock |
| 26 |
N[A-Z], LibraryCachePin |
| 27 |
PE, ALTERSYSTEMSETPARAMETER=VALUE |
| 31 |
PS, ParallelSlaveSynchronization |
| 36 |
SC, SystemCommitNumber |
| 39 |
SQ, SequenceNumberEnqueue |
| 40 |
SR, SynchronizedReplication |
| 42 |
ST, SpaceManagementTransaction |
| 43 |
SV, SequenceNumberValue |
| 44 |
TA, TransactionRecovery |
| 48 |
TO, TemporaryTableObjectEnqueue |
| 49 |
TS, TemporarySegment(alsoTableSpace) |
| 54 |
US, UndoSegment, Serialization |
| 55 |
WL, BeingWrittenRedoLog |
| 56 |
XA, Instance AttributeLock |
| 57 |
XI, Instance RegistrationLock |
Oracle的enqueue包含如下模式：
模式代碼 解釋
能夠使用下面的SQL獲得當前會話等待的enqueue名稱和類型：
| 1 |
select sid, chr(bitand(p1, -16777216)/16777215)||chr(bitand(p1,16711680)/65535) "Name", |
| 2 |
(bitand(p1, 65535))"Mode" from v$session_wait where event='enqueue'; |
1三、free buffer waits
當一個會話將數據塊從磁盤讀到內存中時，它須要到內存中找到空閒的內存空間來存放這些數據塊，當內存中沒有空閒的空間時，就會產生這個等待; 除此以外，還有一種狀況就是會話在作一致性讀時，須要構造數據塊在某個時刻的前映像（image），此時須要申請內存塊來存放這些新構造的數據塊，若是內存中沒法找到這樣的內存塊，也會發生這個等待事件。
當數據庫中出現比較嚴重的free bufferwaits等待事件時，可能的緣由是：
a、Data buffer過小，致使空閒空間不夠。
b、內存中的髒數據太多，DBWR沒法及時將這些髒數據寫到磁盤中以釋放空間。
| 2 |
File#----須要讀取的數據塊所在數據文件的文件號。 |
1四、latch free
在10g以前的版本里，latch free等待事件表明了全部的latch 等待，而在10g中，一些經常使用的latch事件已經被獨立出來：
| 01 |
SQL>select name from v$event_name where name like 'latch%'orderby 1; |
| 03 |
---------------------------------------------------------------- |
| 06 |
latch: ChangeNotificationHashtable latch |
| 07 |
latch: In memoryundolatch |
| 08 |
latch: KCLgcelementparentlatch |
| 09 |
latch: MQLTrackingLatch |
| 11 |
latch: cachebufferhandles |
| 12 |
latch: cachebufferschains |
| 13 |
latch: cachebufferslru chain |
| 14 |
latch: checkpointqueuelatch |
| 15 |
latch: enqueuehashchains |
| 16 |
latch: gcsresource hash |
| 17 |
latch: gesresource hashlist |
| 19 |
latch: library cachelock |
| 20 |
latch: library cachepin |
| 22 |
latch: objectqueueheaderheap |
| 23 |
latch: objectqueueheaderoperation |
| 24 |
latch: parallelqueryallocbuffer |
| 25 |
latch: redo allocation |
| 28 |
latch: row cacheobjects |
| 29 |
latch: sessionallocation |
| 32 |
latch: virtualcircuitqueues |
因此latch free等待事件在10g中並不常見，而是以具體的Latch等待事件出現。
| 2 |
Address----會話等待的latch 地址 |
| 3 |
NNumber----latch 號，經過這個號，能夠從v$latchname 視圖中找到這個latch 的相 |
| 8 |
Tries----會話嘗試獲取latch的次數， |
1五、library cache lock
這個等待事件發生在不一樣用戶在共享池中因爲併發操做同一個數據庫對象致使的資源爭用的時候，好比當一個用戶正在對一個表作DDL操做時，其餘的用戶若是要訪問這張表，就會發生library cache lock 等待事件，它要一直等到DDL操做完畢後，纔可以繼續操做；
| 2 |
Handleaddress---- 被加載的對象的地址。 |
| 5 |
namespace----被加載對象在v$db_object_cache視圖中namespace的名稱。 |
1六、library cache pin
這個等待事件和labrary cache lock 同樣是發生在共享池中併發操做引發的等待事件，一般來說，若是Oracle要對一些pl/sql或者視圖這樣的對象作從新編譯時，須要將這些對象pin到共享池中，若是此時這個對象被其餘的用戶持有，就會產生一個labrary cache pin的等待。
| 2 |
Handleaddress---- 被加載的對象的地址。 |
| 5 |
namespace----被加載對象在v$db_object_cache視圖中namespace的名稱。 |
1七、log file parallel write
後臺進程LGWR負責將log buffer當中的數據寫到REDO文件中，以重用log buffer的數據，若是每一個REDOLOG組裏面有2個以上的成員，那麼LGWR進程會並行的將REDO信息寫入這些文件中。
若是數據庫中出現這個等待事件的瓶頸，主要的緣由多是磁盤I/O性能不夠或者REDO文件的分佈致使了I/O的爭用，好比同一個組的REDO成員文件放在相同的磁盤上。
| 3 |
Blocks----操做須要寫入的數據塊個數。 |
| 4 |
Requests----操做須要執行的I/O次數。 |
1八、log buffer space
當log buffer當中沒有可用空間來存放新產生的redo log 數據時，就會發生log buffer space等待事件，若是數據庫中新產生的redo log 的數量大於LGWR寫入到磁盤中的redo log 數量時，必須等待LGWR完成寫入磁盤的操做，LGWR必須確保redo log 寫到磁盤成功以後，才能在redo buffer當中重用這部分信息。
若是數據庫中出現大量的log bufferspace等待事件，能夠考慮下面的解決方法：
a、增長redo buffer的大小。
b、提生磁盤的i/o性能。
這個等待事件沒有參數。
1九、log file sequential read
這個等待事件一般發生在對redo log 信息的讀取時，好比在線redo的歸檔操做，ARCH進程須要讀取redo log 的信息，因爲redo log 的信息是順序寫入的，因此在讀取的是有也是按照順序的方式來讀取。
| 2 |
log#----發生等待時讀取的redo log 的sequence號。 |
20、log file single write
這個等待事件發生在更新redo log 文件的文件頭時，當爲日誌組增長新的日誌成員時或者redo log 的sequence號改變時，LGWR都會更新redo log 的文件頭信息。
| 2 |
log#----寫入的redo log 組的編號。 |
2一、log file switch (archiving needed)
在歸檔模式下，這個等待事件發在在線日誌切換（log file switch）時，須要切換到的在線日誌尚未被歸檔進程（ARCH）歸檔完畢的時候。當在線日誌文件切換到下一個日誌時，須要確保下一個日誌文件已經被歸檔進程歸檔完畢，不然不容許覆蓋那個在線日誌信息（不然會致使歸檔日誌信息不完整）。
出現這樣的等待事件一般是因爲某種緣由致使ARCH進程死掉，好比ARCH進程嘗試向目的地寫入一個歸檔文件，可是沒有成功（介質失效或者其餘緣由），這是ARCH進程就會死掉。若是發生這樣狀況，在數據庫的alert文件中能夠找到相關的告警信息。
這個等待事件沒有參數。
2二、log file switch (checkpointin complete)
當一個在線日誌切換到下一個在線日誌時，必須保證要切換到的在線日誌上記錄的信息（好比一些髒數據塊產生的redo log）被寫到磁盤上（checkpoint），這樣作的緣由是，如果一個在線日誌文件的信息被覆蓋，而依賴這些redo信息作恢復的數據塊還沒有被寫到磁盤上（checkpoint），此時系統down掉的話，Oracle將沒有辦法進行實例恢復。
在v$log視圖裏記錄了在線日誌的狀態，一般來講在線日誌有3個狀態：
Active—-這個日誌上面保護的信息尚未完成checkpoint。
Inactive—-這個日誌上面保護的信息已經完成checkpoint。
Current—-當前的日誌。
Oracle在作實例恢復時，會使用狀態爲current和active的日誌進行實例恢復。若是系統中出現大量的log file switch (checkpointincomplete)等待事件，緣由可能是日誌文件過小或者日誌組太少，因此解決的方式是，增日誌文件的大小或者增長日誌組的數量。
這個等待事件沒有參數。
2三、log file sync
這是一個用戶會話行爲致使的等待事件，當一個會話發出一個commit命令時，LGWR進程將會將這個事務產生的redo log 從log buffer裏寫到磁盤上，以保證用戶提交的信息被安全地記錄到數據庫中。
會話發出commit指令後，須要等待LGWR將這個事務產生的redo成功寫入到磁盤之後，才能夠繼續進行後續的操做，這個等待事件就叫作log file sync。
當系統中出現大量的log file sync等待事件時，應該檢查數據庫中是否有用戶在作頻繁的提交操做。
這種等待事件一般發生在OLTP系統上，OLTP系統中存在不少小的事務，若是這些事務頻繁被提交，可能引發大量log file sync的等待事件。
| 2 |
Buffer#----redo buffer中須要被寫入到磁盤中的buffer。 |
2四、SQL*Net break/reset to client
當出現這個等待事件時，說明服務器端在給客戶端發送一個斷開鏈接或者重置鏈接的請求，正在等待客戶端的響應，一般的緣由是服務器到客戶端的網絡不穩定致使。
| 2 |
driverid----服務器端和客戶端鏈接使用的協議信息。 |
| 3 |
break----0表示服務器端向客戶端發送一個重置（reset）消息，非零表示服務器端向客 戶端發送一個斷開（break)消息。 |
2五、SQL*Net break/reset to dblink
這個等待事件和SQL*Net break/reset to client相同。不過它表示的是數據庫經過dblink訪問另外一臺數據庫時，它們之間會創建起一個會話，這個等待事件發生的這個會話之間的通訊過程當中，一樣若是出現這個等待事件，須要檢查兩臺數據庫之間的通訊問題。
| 2 |
driver driverid----服務器端和另外一個服務器端鏈接使用的協議信息。 |
| 3 |
break----0表示服務器端向另外一個服務器端發送一個重置（reset）消息，非零表示 |
2六、SQL*Net message from client
這個等待事件基本上算是最多見的一個等待事件了，當一個會話創建成功後，客戶端會向服務器端發送請求，服務器端處理完客戶端請求後，將結果返回給客戶端，並繼續等待客戶端的請求，這時候就會產生SQL*Netmessagefrom client等待事件
很顯然，這是一個空閒等待，若是客戶端再也不向服務器端發送請求，服務器端將一直處
於這個等待事件狀態。
| 2 |
driverid----服務器端和客戶端鏈接使用的協議信息。 |
| 3 |
#bytes----服務器端收到的來自客戶端消息的字節數。 |
2七、SQL*Net message from dblink
這個等待事件和SQL*Net message from client相同，不過它表示的是數據庫經過dblink訪問另外一臺數據庫時，它們之間會創建起一個會話，這個等待事件發生的這個會話之間的通訊過程當中。
這個等待事件也是一個空閒等待事件。
| 2 |
driverid----服務器端和服務器端鏈接使用的協議信息。 |
| 3 |
#bytes----服務器端經過dblink收到的來另外一個服務器端消息的字節數。 |
2八、SQL*Net message to client
這個等待事件發生在服務器端向客戶端發送消息的時候。當服務器端向客戶端發送消息產生等待時，可能的緣由是用戶端太繁忙，沒法及時接收服務器端送來的消息，也多是網絡問題致使消息沒法從服務器端發送到客戶端。
這個等待事件包含2個參數：
driverid—-服務器端和服務器端鏈接使用的協議信息。
#bytes—-服務器端向客戶端發送消息的字節數。
2九、SQL*Net message to dblink
這個等待事件和SQL*Netmessageto client相同，不過是發生在數據庫服務器和服務器之間的等待事件，產生這個等待的緣由多是遠端服務器繁忙沒法及時接收發送過來的消息，也多是服務器之間網絡問題致使消息沒法發送過來。
| 2 |
driverid----服務器端和服務器端鏈接使用的協議信息。 |
| 3 |
#bytes----服務器端經過dblink發送給另外一個服務器消息的字節數。 |
30、SQL*Net more data from client
服務器端等待用戶端發出更多的數據以便完成操做，好比一個大的SQL文本，致使一個SQL*Net數據包沒法完成傳輸，這樣服務器端會等待客戶端把整個SQL文本發過來再作處理，這時候就會產生一個SQL* Net more data from client等待事件。
| 2 |
driverid----服務器端和服務器端鏈接使用的協議信息。 |
| 3 |
#bytes----服務器端從客戶端接收到消息的字節數。 |
3一、SQL*Net more data from dblink
在一個分佈式事務中，SQL分佈在不一樣的數據庫中執行，遠程數據庫執行完畢後將結果經過dblink返給發出SQL的數據庫，在等待數據從其餘數據庫中經過dblink傳回的過程當中，若是數據在遠程數據庫上處理時間好久，或者有大量的結果集須要返回，或者網絡性能問題都會產生SQL*Netmoredatafrom dblink等待事件，它的意思是本地數據庫須要等到全部的數據從遠端處理完畢經過dblink傳回後，才能夠在本機繼續執行操做。
| 2 |
driverid----服務器端和服務器端鏈接使用的協議信息。 |
| 3 |
#bytes----服務器端經過dblink接收到來自另外一個服務器消息的字節數。 |
3二、SQL*Net more data to client
當服務器端有太多的數據須要發送給客戶端時，可能會產生SQL*Net more data to client等待事件； 也可能因爲網絡問題致使服務器端沒法及時的將信息或處理結果發送給客戶端時，一樣會產生這個等待。
| 2 |
driver driverid----服務器端和客戶端鏈接使用的協議信息。 |
| 3 |
#bytes----服務器端向客戶端發送消息的字節數。 |
3三、SQL*Net more data to dblink
這個等待事件和SQL*Net more data to client等待事件基本相同，只不過等待發生在分佈式事務中，即本地數據庫須要將更多的數據經過dblink發送給遠程數據庫，因爲發送的數據太多或者網絡性能問題，就會出現SQL*Netmoredatato dblink等待事件。
| 2 |
driverid----服務器端和服務器端鏈接使用的協議信息。 |
| 3 |
#bytes----服務器端經過dblink向另外一個服務器發送消息的字節數。 |
發表在 troubleshooting | 標籤爲 WAIT EVENT | 留下評論
發表於 2013 年 8 月 11 日 由 周應侯
文檔中將提供關於 Library cache lock, Library cache pin 與 Library cache load lock 的一些簡明的知識。
什麼是」Library cache lock」 ?
什麼是」Library cache pin」 ?
爲何須要這兩種不一樣類型的鎖?
減小Library Cache 競爭的通常建議
如何下降 library cache lock 等待
如何下降 library cache pin 等待
什麼是 Library cache load lock?
如何減小 Library cache load lock
Library cache pin 與 library load lock 是什麼關係
什麼是」Library cache lock」 ?
這個事件控制對 library cache 的併發使用。 它獲取一個對象句柄（object handle）上的鎖，從而：
定位 library cache 中的一個對象一樣也須要這個鎖。
在解析或編譯 SQL 或 PL/SQL 語句期間，咱們須要得到被引用的數據庫對象(表，視圖，過程，函數，包，包體，觸發器，索引，聚簇，同義詞)的 library cache lock；這個鎖在解析與編譯結束時會被釋放。
cursor(SQL 與 PL/SQL 區)，管道（pipes）和其它的瞬時（transient）對象不使用這個鎖。
Library cache lock 上的死鎖不會被自動檢測到，對其的操做是同步進行的。
參數:
handle address
對象地址
lock address
鎖地址。它與 latch 與 enqueue 不一樣，它是一個 State Object。
Mode
申請鎖的級別
Namespace
對象使用的 namespace, 取自於 V$DB_OBJECT_CACHE。
什麼是」Library cache pin」 ?
這個使用者能夠長時間地維護一個依賴對象(例如，其它使用者不能更改這個對象)。
一個使用者能夠防止其它使用者訪問同一個對象。
這 個事件管理 library cache 併發。Pin 住一個對象會使它使用的 heap 被載入到內存中。若是一個使用者想要修改或檢查這個對象，它必須在得到 lock 以後再取得一個 pin。Pin 能夠用 NULL, SHARE, EXCLUSIVE 模式得到，而且能夠看作是一種特殊的 lock。等待」library cache pin」意味着這個 PIN 正被某個其它 session 以不兼容的模式持有。
訪 問當前被緩存到 library cache 中的數據庫對象（表，視圖，過程，函數，包，包體，觸發器，索引，聚簇，同義詞）的時候須要得到 library cache pin; 在 library cache 中，數據庫對象被緩存成兩部分：句柄(handle)和對象(object); 這個鎖（pin）是用來保護」object」部分的。Library cache pin 上的死鎖不會被自動檢測到，對其的操做是同步進行的。
注意：在10g之後，」library cache pin」已經被 mutex 取代。
參見：Note 1298015.1 WAITEVENT: 「cursor: pin S wait on X」 Reference Note
爲何須要這兩種不一樣類型的鎖?
Lock 與 pin 都用於訪問在 library cache 中的對象。Lock 管理不一樣進程間的併發，pin 則管理緩衝區的一致性。爲了訪問一個對象，進程必須首先鎖定（lock）這個對象的句柄(handle)，而後它本身 pin 住對象的內存堆。
Lock 與 pin 請求會一直等待直到得到爲止，這是一個引發爭用的可能的緣由，由於它沒有 NOWAIT 請求模式。
經過得到一個在對象句柄上的鎖，一個進程能防止其它進程訪問這個對象，甚至不能夠查看它的類型。它還能在維護對象依賴關係的同時不阻止其它進程訪問這個對象。獲取一個 lock 一樣也是在緩存中查找對象的惟一途徑。查找並鎖住對象是在一個操做中完成的。
若是一個進程想檢查或修改一個對象，那麼它必須得到一個在這個對象上的 pin (得到了在句柄上的鎖以後)。Pin這個動做會將相應對象的信息載入到內存，若是以前沒有的話，同時還能確保這些信息保留在內存直到 pin 被釋放。
Oracle 在分析/編譯 Package/Procedure/Function/View 時須要 Library Cache Lock 和 Library Cache Pin。這是爲了確保在分析/編譯期間, 沒有其它人能夠對這些對象的定義進行改變，或者刪除、重建這個對象。
當 一個 SQL 語句被一個 session 硬解析時，這個 session 須要得到一個 library cache lock 以便阻止其它 session 去訪問或修改同一個對象。若是這個事件等待很長時間。這代表可能 shared pool 太小或常常發生對象被 flush 出去的清醒。還有，這代表數據庫對象被常常修改。
除了硬解析，若是一個 session 要更改被 SQL 語句引用的對象的定義或對其作任何更改，就必須得到一個 library cache lock 和 library cache pin。須要 Pin 的緣由是須要加載數據字典信息到內存中來修改這個對象。
Note 34579.1 WAITEVENT: 「library cache pin」 Reference Note
減小Library Cache 競爭的通常建議
下邊會介紹一下解決不一樣競爭的不一樣的方法。可是，不少時候這些現象都是因爲 SQL 語句的版本數形成的。若是您看到了任何跟 library cache 相關的競爭，應該馬上檢查 AWR Report 確保沒有版本數很高（好比幾百）的 SQL 語句。
若是有的話請參見如下文檔解決：
Document 296377.1 Troubleshooting: High Version Count Issues
如何下降 library cache lock 等待
我 們首先要確認的是 library cache 的競爭是整個系統層面的仍是隻發生在某個或某些 SQL 語句上。這個」library cache lock」是被一個特定的 SQL 持有很長的時間嗎？或者老是在等待某個特定的對象？仍是說這個鎖在短期內被請求的次數不少從而形成的競爭？
若是問題是在整個系統層面發生的，通常來講是因爲 shared pool 過小或 SQL 語句不共享形成的。一些解決競爭的方法：
若是您發現是某條或某些SQL產生的問題，那麼須要檢查爲何它持有鎖的時間會那麼長。
如下文檔能夠用來找到誰在持有鎖以及在哪一個對象上：
Note 122793.1 How to Find which Session is Holding a Particular Library Cache Lock
增大 shared pool 從而減小 reload 的次數，這是由於 shared pool 太小會形成獲取鎖的時間加長。
經過將 cursor_sharing 設置爲 similar 或 force 來使 SQL 語句共享。
須要當心的是這樣作可能會改變SQL的執行計劃，因此作以前須要作完整的測試。
在系統不繁忙的時候作統計信息的收集或其它維護做業，從而下降無效化（invalidation）的次數。
如何減小 Library cache load lock
若是一個對象不在內存中，那麼咱們不能對其申請 library cache lock。
所以，須要將這個對象加載到內存中。
而後，session 嘗試找到數據庫對象的 load lock，以便它能載入這個對象。
爲了阻止多進程同時請求加載同一個對象，其它一樣請求的 session 將等待 library cache load lock 由於這個對象正在被加載到內存中。
等待 library cache load lock 是因爲對象在內存中是不存在的。
Library cache 中的對象不存在，是因爲 shared pool 太小引發的頻繁從新裝載，或太多的硬解析緣於不共享的 SQL。
避免這種等待的一般建議:
Note:94036.1 Init.ora Parameter 「CURSOR_SHARING」 Reference Note
設置 cursor_sharing 爲 force(減小硬解析)。—可能改變執行計劃與查詢的性能，因此要做充分的測試。
增長 session cached cursors(避免 cursor 被刷出 shared pool)
增長 shared pool(避免 reload).
Library cache pin 與 library load lock 是什麼關係
Library cache pin 和 load lock 可能出如今對 PL/SQL, views, types 等的編譯與重編譯期間。這種編譯老是顯式的(好比應用安裝，升級，打補丁)。可是對象重編譯也可能發生在對象失效期間。
在 處理那些「奇怪「的 library cache pin 和 load lock 等待時，咱們須要檢查爲何對象失效了。頗有可能失效是因爲某些操做修改了它所依賴的對象的」LAST_DDL」。一般來講這些操做包括對象維護操做，比 如 ALTER, GRANT, REVOKE, replacing views 等等。還有就是收集 optimizer statistics 也會形成 cursor 失效，進而致使 library cache 的重裝載。這個現象在 Oracle Server Application Developer’s Guide 的object dependency maintenance 部分有描述。
對 象失效之後，Oracle 嘗試在第一次訪問這個對象時去重編譯它。有些狀況下，若是其它 session 已經 pin 住這個對象，可能就會出現問題。 很顯然，在有大量活躍用戶與複雜依賴關係(例如，不少交叉依賴的 packages 或package bodies)的狀況下更容易出現問題。有些時候對對象的編譯會持續數小時從而阻止其它 session 對其的訪問。
在 library cache dump, level 10 能夠看到:
查找 ALTER … COMPILE 語句和 lock=X 或 pin=X 的 objects/handles.
提示
Load lock老是以排它模式得到的。
若是 session load lock 繁忙，session 將一直等待，直到鎖變成可用。
需 要頻繁使用的 stored PL/SQL 所依賴的對象，對其 altering, granting, evoking 操做須要特別當心。實際上，解決這種問題很大程度上依賴於應用程序和系統維護的時間。應用程序開發者須要考慮某些決定可能會對應用程序的可擴展性及性能產 生負面影響。
REFERENCES
NOTE:34579.1 - WAITEVENT: 「library cache pin」 Reference Note
NOTE:62143.1 - Troubleshooting: Tuning the Shared Pool and Tuning Library Cache Latch Contention
NOTE:7423411.8 - Bug 7423411 – Process may hang waiting for 「library cache load lock」 with no holder
NOTE:10018789.8 - Bug 10018789 – Spin in kgllock / DB hang with high library cache lock waits
NOTE:1298015.1 - WAITEVENT: 「cursor: pin S wait on X」 Reference Note
NOTE:296377.1 - Troubleshooting: High Version Count Issues
NOTE:7706138.8 - Bug 7706138 – Process may hang waiting for 「library cache load lock」 with no holder
NOTE:94036.1 - Init.ora Parameter 「CURSOR_SHARING」 Reference Note
NOTE:9675816.8 - Bug 9675816 – Self deadlock with ‘library cache lock’ waits / OERI:17059
NOTE:122793.1 - How to Find which Session is Holding a Particular Library Cache Lock
發表在 troubleshooting | 標籤爲 Library Cache | 留下評論
發表於 2013 年 8 月 9 日 由 周應侯
數據腳本名稱爲lab3.data
| 01 |
Mike Harrington:(510) 548-1278:250:100:175 |
| 02 |
Christian Dobbins:(408) 538-2358:155:90:201 |
| 03 |
Susan Dalsass:(206) 654-6279:250:60:50 |
| 04 |
Archie McNichol:(206) 548-1348:250:100:175 |
| 05 |
Jody Savage:(206) 548-1278:15:188:150 |
| 06 |
Guy Quigley:(916) 343-6410:250:100:175 |
| 07 |
Dan Savage:(406) 298-7744:450:300:275 |
| 08 |
Nancy McNeil:(206) 548-1278:250:80:75 |
| 09 |
John Goldenrod:(916) 348-4278:250:100:175 |
| 10 |
Chet Main:(510) 548-5258:50:95:135 |
| 11 |
Tom Savage:(408) 926-3456:250:168:200 |
| 12 |
Elizabeth Stachelin:(916) 440-1763:175:75:300 |
該數據中包含姓名、電話號碼、以及在最近3個月中的競選捐款數額
一、打印全部的電話號碼
| 01 |
[root@zhouyinghou awk]# awk -F: '{print $2}' lab3.data |
二、打印Dan的電話號碼
| 1 |
[root@zhouyinghou awk]# awk -F: '/^Dan/{print $2}' lab3.data |
三、打印Susan的姓名和電話號碼
| 1 |
[root@zhouyinghou awk]# awk -F: '/^Susan/{print $1,$2}' lab3.data |
| 2 |
Susan Dalsass (206) 654-6279 |
四、打印全部以D開頭的姓氏
| 1 |
[root@zhouyinghou awk]#awk -F'[: ]' '$2 ~ /^D/{print $2}' lab3.data |
五、打印全部以C或者E開頭的名字
| 1 |
[root@zhouyinghou awk]# awk '/^[CE]/{print $1}' lab3.data |
或者
| 1 |
awk -F'[: ]' '$1 ~ /^[CD]/{print $1}' lab3.data |
六、打印全部只包含4個字符的名字
| 1 |
[root@zhouyinghou awk]# awk '{if(length($1)==4)print $1}' lab3.data |
或者
| 1 |
awk '$1 ~ /^....$/{print $1}' lab3.data |
七、打印全部區號爲916的人的名字
| 1 |
[root@zhouyinghou awk]# awk '{if($2~/(916)/)print $1}' lab3.data |
八、打印Mike的資助金額，每個值都須要用$符號開頭，例如「$250$100$175」
| 1 |
[root@zhouyinghou awk]# awk -F: '{if ($1~"Mike") print "$"$3"$"$4"$"$5}' lab3.data |
九、打印全部的姓，後面跟一個逗號和名
| 01 |
[root@zhouyinghou awk]# awk -F: '{print $1}' lab3.data|awk '{print $1","$2}' |
十、編寫一個名爲facts的腳本，並完成下面的工做
a、打印全部姓氏爲Savage的人的全名和電話號碼
b、打印Chet的資助金額
c、打印全部在第一個月資助了250美圓的人
| 3 |
$2 ~ /Savage/{print $1,$2,$3,$4} |
| 4 |
/^Chet/ {print $5,$6,$7} |
| 5 |
$5 ~ /^250/ {print $1,$2} |
| 01 |
[root@zhouyinghou awk]# awk -F'[: ]' -f facts lab3.data |
| 05 |
Jody Savage (206) 548-1278 |
| 07 |
Dan Savage (406) 298-7744 |
| 11 |
Tom Savage (408) 926-3456 |
發表在 Linux, SHELL, Unix | 標籤爲 AWK, SHELL, UNIX | 留下評論
發表於 2013 年 8 月 3 日 由 周應侯
爲何會有鎖
沒有併發就沒有鎖！
Oracle中鎖的分類
Enqueues—隊列類型的鎖，一般和業務相關的。
Latches —系統資源方面的鎖，好比內存結構，SQL解析……
鎖的原則
只有被修改時，行纔會被鎖定。
當一條語句修改了一條記錄，只有這條記錄上被鎖定，在Oracle數據庫中不存在鎖升級。
當某行被修改時，它將阻塞別人對它的修改。
當一個事務修改一行時，將在這個行上加上行鎖（TX），用於阻止其它事務對相同行的修改。
讀永遠不會阻止寫。
讀不會阻塞寫，但有惟一的一個例外，就是select …for update。
寫永遠不會阻塞讀。
當一行被修改後，Oracle經過回滾段提供給數據的一致性讀。
Oracle鎖的類型
| 01 |
SQL> select type,name from V$lock_type; |
| 03 |
---------- ---------------------------------------- |
| 04 |
WM WLM Plan Operations |
| 05 |
CI Cross-Instance Call Invocation |
| 09 |
RM GES Resource Remastering |
| 13 |
RE Block Repair/Resilvering |
| 14 |
KD Scheduler Master DBRM |
TM鎖和TX鎖
TM 表鎖，發生在insert,update,delete以及select for update操做時，目的是保證操
做可以正常進行，而且阻止其它人對錶執行DDL操做。
TX鎖 事務鎖（行鎖）對於正在修改的數據，阻止其它會話進行修改。
TM鎖的幾種模式—-lock mode
Row Share (RS) –2
This lock, also called a subshare table lock (SS), indicates that the transaction holding the lock on the table has locked rows in the table and
intends to update them. A row share lock is the least restrictive mode of table lock, offering the highest degree of concurrency for a table.
Row Exclusive Table Lock (RX)—3
This lock, also called a subexclusive table lock (SX), generally indicates that the transaction holding the lock has updated table rows or issued
SELECT … FOR UPDATE. An SX lock allows other transactions to query, insert, update, delete, or lock rows concurrently in the same table.
Therefore, SX locks allow multiple transactions to obtain simultaneous SX and subshare table locks for the same table.
Share Table Lock (S) –4
A share table lock held by a transaction allows other transactions to query the table (without using SELECT … FOR UPDATE), but updates are
allowed only if a single transaction holds the share table lock. Because multiple transactions may hold a share table lock concurrently,
holding this lock is not sufficient to ensure that a transaction can modify the table.
Share Row Exclusive Table Lock (SRX) —5
This lock, also called a share-subexclusive table lock (SSX), is more restrictive than a share table lock. Only one transaction at a time can
acquire an SSX lock on a given table. An SSX lock held by a transaction allows other transactions to query the table (except for SELECT … FOR
UPDATE) but not to update the table.
Exclusive Table Lock (X) —6
This lock is the most restrictive, prohibiting other transactions from performing any type of DML statement or placing any type of lock on the
table.
TM鎖幾種模式的互斥關係
RI鎖—基於引用關係的鎖定
當對具備主外鍵關係的表作DML操做時，鎖定不僅僅發生在操做表上，相應的引用表
上也可能加上相應的鎖定。
死鎖
兩個會話互相持有對方資源致使死鎖。
結論–鎖定是一個開發的範疇
經過鎖定，能夠達到預期的業務需求。
經過對業務深刻的分析，能夠最大程度的避免沒必要要鎖定的發生。
V$LOCK
V$LOCK列出Oracle 服務器當前擁有的鎖以及未完成的鎖或栓鎖請求。若是你覺着session在等待等待事件隊列那你應該檢查本視圖。若是你發現session在等待一個鎖。那麼按以下前後順序：
1.使用V$LOCK找出session持有的鎖。
2.使用V$SESSION找出持有鎖或等待鎖的session執行的sql語句。
3.使用V$SESSION_WAIT找出什麼緣由致使session持有鎖堵塞。
4.使用V$SESSION獲取關於持有鎖的程序和用戶的更多信息。
V$LOCK定義：
| 02 |
---------- ---------- ---------- |
V$LOCK中的經常使用列
·SID：表示持有鎖的會話信息。
·TYPE：表示鎖的類型。值包括TM和TX等。
·LMODE：表示會話等待的鎖模式的信息。用數字0－6表示，和表1相對應。
·REQUEST：表示session請求的鎖模式的信息。
·ID1,ID2：表示鎖的對象標識。
公共鎖類型
在Oracle數據庫中，DML鎖主要包括TM鎖和TX鎖，其中TM鎖稱爲表級鎖，TX鎖稱爲事務鎖或行級鎖。
當Oracle執行DML語句時，系統自動在所要操做的表上申請TM類型的鎖。當TM鎖得到後，系統再自動申請TX類型的鎖，並將實際鎖定的數據行的鎖 標誌位進行置位。這樣在事務加鎖前檢查TX鎖相容性時就不用再逐行檢查鎖標誌，而只需檢查TM鎖模式的相容性便可，大大提升了系統的效率。TM鎖包括了 SS、SX、S、X等多種模式，在數據庫中用0－6來表示。不一樣的SQL操做產生不一樣類型的TM鎖，以下表1。
TX：行級鎖，事務鎖
·在改變數據時必須是排它模式(mode 6)。
·每個活動事務都擁有一個鎖。它將在事務結束(commit/rollback)時釋放。
·若是一個塊包括的列被改變而沒有ITL(interested transaction list)槽位(entries)，那麼session將鎖置於共享模式(mode 4)。當session得到塊的ITL槽位時釋放。
·當一個事務首次發起一個DML語句時就得到一個TX鎖，該鎖保持到事務被提交或回滾。當兩個或多個會話在表的同一條記錄上執行DML語句時，第一個會話在該條記錄上加鎖，其餘的會話處於等待狀態。當第一個會話提交後，TX鎖被釋放，其餘會話才能夠加鎖。
·指出回滾段和事務表項
按下列項以免競爭：
·避免TX－6類型競爭，須要根據您的應用而定。
·避免TX－4類型競爭，能夠考慮增長對象INITRANS參數值。
TM：表級鎖
·數據庫執行任何DDL語句時必須是排它模式；例如，alter table,drop table。
·執行像insert,update,delete這類DML語句時處於共享模式。它防止其它session對同一個對象同時執行ddl語句。
·任何對象擁有正被改變的數據，TM鎖都將必須存在。
·鎖指向對象。
在TM隊列避免競爭，能夠考慮屏蔽對象表級鎖，屏蔽表級鎖防止對象執行任何ddl語句。
示例：如何查找鎖並解鎖
view source
| 03 |
SQL> select distinct sid from v$mystat; |
| 09 |
SQL> update zyh set name = upper(name) where id = 1; |
| 15 |
SQL> select distinct sid from v$mystat; |
| 21 |
SQL> update zyh set name = lower(name) where id = 1; |
| 26 |
SQL> select * from v$lock where BLOCK = 1; |
| 28 |
ADDR KADDR SID TY ID1 ID2 LMODE REQUEST |
| 29 |
-------- -------- ---------- -- ---------- ---------- ---------- ---------- |
| 32 |
3E30C0A4 3E30C1C0 289 TX 589833 126 6 0 |
| 36 |
SQL> select sid,serial#,username,state,blocking_session_status,blocking_session from v$session where event like '%TX%'; |
| 38 |
SID SERIAL# USERNAME STATE |
| 39 |
---------- ---------- ------------------------------ ------------------- |
| 40 |
BLOCKING_SE BLOCKING_SESSION |
| 41 |
----------- ---------------- |
| 47 |
第一：kill掉282,13，則是kill掉被block的session。 |
| 48 |
alter system kill session '282,13'; |
| 49 |
第二：kill掉289，則是kill掉以前block別人的session。 |
| 50 |
所以經過前面的282,13所查到的SQL語句，則是後面運行被等待的SQL語句，而不是阻塞別人的SQL語句。 |
| 54 |
SQL> select /*+ NO_MERGE(a) NO_MERGE(b) NO_MERGE(c) */ a.username, a.machine, a.sid, a.serial#, a.last_call_et "Seconds", b.id1, c.sql_text "SQL" from v$session a, v$lock b, v$sqltext c where a.username is not null and a.lockwait = b.kaddr and c.hash_value =a.sql_hash_value; |
| 56 |
USERNAME MACHINE SID SERIAL# Seconds ID1 SQL |
| 57 |
------------------ ------------------ ---------- ---------- ---------- --------- ------------------------ |
| 59 |
SYS prod.localdomain 282 13 339 589833 update zyh set name = lower(name) where id = 1 |