模板
教程
環境
性能
功能
管理
Oracle 10g第2版新特性之性能特性
掛起但未癱瘓：附連內存的 SGA 查詢 假設您使用 Oracle 企業管理器診斷和解決 性能 問題。一天，出現了一個棘手的問題：一個設計糟糕的應用程序引起了嚴重的庫高速緩存鎖定問題，并且數據庫呈現掛起狀態。您必須快速確定導致該問題發生的會話，并快速終止這
掛起但未癱瘓：附連內存的 SGA 查詢 假設您使用 Oracle 企業管理器診斷和解決性能問題。一天，出現了一個棘手的問題：一個設計糟糕的應用程序引起了嚴重的庫高速緩存鎖定問題，并且數據庫呈現掛起狀態。您必須快速確定導致該問題發生的會話，并快速終止這些會話。
您可以啟動 Oracle 企業管理器來診斷此問題。且慢！如果整個數據庫充滿了掛起的會話，那么 Oracle 企業管理器中的查詢是否也會掛起？
如果使用 Oracle 數據庫 10g 第 2 版，則答案是否定的。正如我在第 2 部分中所介紹的，在該版本中，“在內存訪問模式下進行監控”選項使企業管理器可以直接從 SGA 內存（而不是 V$SESSION）中選擇會話。因為在該模式下繞過了 SQL 層，掛起的數據庫就不會阻礙此查詢的執行。相反，將自動啟動查詢。
讓我們看看該特性是如何工作的。在 Enterprise Manager 屏幕上，選擇 Performance 選項卡并滾動到該頁面底部的“Additional Monitoring Links”部分，屏幕與下圖類似。
注意紅色橢圓框中“Hang Analysis”的超鏈接。單擊該鏈接，將顯示一個與下圖類似的屏幕。
該圖展示了各種“死”會話。在該示例中，您可以看到 SID 為 193 的會話（根會話）已經阻止了其他兩個會話，即 192 和 214。該圖中的會話顏色表示會話受阻的時間?？梢詥螕?SID 訪問 Session Details 屏幕，以獲取更多信息。
還記得 ORADEBUG 實用程序嗎？Oracle 企業管理器使用該實用程序獲得有關系統掛起的數據。啟用 SGA 直接連接時，Oracle 將對每個實例使用一個 SQL 收集器。該收集器隨企業管理器自動啟動。檢索到以下視圖中的數據：
V$SESSION V$SESSION_WAIT V$SYSTEM_EVENT V$SYSSTAT
附連內存的 SGA 查詢是一個非常強大的特性，以后肯定能幫您解決棘手問題。我們都對可“征服”數據庫的應用程序有一種親切感，為什么呢？現在，您可以給出答案了。我認為此特性是第 2 版一個最適用于數據庫管理員的特性。
可中斷的 SQL Aclearcase/" target="_blank" >ccess Advisor
您可能熟悉 Oracle 數據庫 10g 中的 SQL Access Advisor。它主要提供了一個自動化的方法，通過確定可提高 SQL 性能的索引和物化視圖來調整 SQL 工作負載。
但請考慮下面這種情況：您遇到了一些性能問題，并希望對一組 SQL 語句運行 SQL Access Advisor。為獲得一個更準確的分析，您選擇了“綜合模式”選項。隨后，您將等待結果。
如果 SQL 工作負載很大（包含上百條語句）并且 SQL 語句比較復雜，您可能等待較長的時間。但與些同時卻用戶迫切要求您提供答案。您該怎么辦？
在 Oracle 數據庫 10g 第 2 版中，您可以輕松地中斷此顧問程序并查看到目前為止生成的建議或查找結果。第 1 版中的 SQL Tuning Advisor 中提供這些功能，現在已經擴展到 SQL Access Advisor。
讓我們看看該功能的工作方式。從 Advisor Central 屏幕中，單擊 SQL Access Advisor 鏈接。
從標題“Actions”旁邊的右側下拉列表中選擇“Interrupt”選項，然后按 Go 按鈕。該命令將中斷 SQL Access Advisor，您可以立即看到建議。當然，這些建議并不是完整的集合，但在大多數情況下可以滿足用戶的需要。
如果您使用的是命令行版本的 SQL Access Advisor 而不是 Oracle 企業管理器，那么您是否仍可以查看工作進度？當然，您可以使用新的視圖 V$ADVISOR_PROGRESS。
SQL> desc v$advisor_progress Name Null?類型 ----------------------------------------- -------- ----------- SID NUMBER SERIAL# NUMBER USERNAME VARCHAR2(30) OPNAME VARCHAR2(64) ADVISOR_NAME VARCHAR2(64) TASK_ID NUMBER TARGET_DESC VARCHAR2(32) SOFAR NUMBER TOTALWORK NUMBER UNITS VARCHAR2(32) BENEFIT_SOFAR NUMBER BENEFIT_MAX NUMBER FINDINGS NUMBER RECOMMENDATIONS NUMBER TIME_REMAINING NUMBER START_TIME DATE LAST_UPDATE_TIME DATE ELAPSED_SECONDS NUMBER ADVISOR_METRIC1 NUMBER METRIC1_DESC VARCHAR2(64)
此處的列 TOTALWORK 和 SOFAR 顯示了已經完成的工作量以及總工作量，這與您從 V$SESSION_LONGOPS 視圖中看到的內容相似。
檢查是否啟用了跟蹤
如果會話執行的任務和預期不符，或者執行速度比較慢，那么大多數數據庫管理員的第一步是檢查等待事件。要構建配置文件，您可能還需要長期跟蹤會話，那么在 user_dump_dest 目錄中將生成一個跟蹤文件。
現在，假設您在某段時間內對多個會話使用了端到端跟蹤，但現在不知道哪些會話處于跟蹤狀態。如何找出這些對話呢？
方法之一是對大量跟蹤文件進行篩選，以提取 SID 和 Serial# 列并在數據庫的 V$SESSION 視圖中進行匹配。毋庸質疑，這個過程比較復雜、困難并且容易出錯。Oracle 數據庫 10g 第 2 版中提供了一個更優秀、更簡單的方法：您所要做的只是查看一個視圖，即 V$SESSION。
新增了三個新列顯示跟蹤狀態：
- sql_trace - 如果在會話中啟用了 SQL 跟蹤，則顯示 TRUE/FALSE
- sql_trace_waits - 如果啟用了會話跟蹤，則可以讓跟蹤程序將等待信息寫入跟蹤文件，這對于診斷性能問題很有用。
- sql_trace_binds - 如果會話使用綁定變量，則可以讓跟蹤程序將綁定變量值寫入跟蹤文件。該列顯示 TRUE/FALSE。
select sid, serial#, sql_trace, sql_trace_waits, sql_trace_binds from v$session where username = 'HR'
輸出結果如下：
SID SERIAL# SQL_TRAC SQL_T SQL_T ---------- ---------- -------- ----- ----- 196 60946 DISABLED FALSE FALSE
此處您可以看到，SID 為 196、Serial# 為 60946 的會話未啟用跟蹤。
現在，您可以對等待事件（而不是綁定變量）啟用跟蹤?？梢允褂贸绦虬?dbms_monitor 啟用跟蹤。
begin dbms_monitor.session_trace_enable ( session_id => 196, serial_num => 60960, waits => true, binds => false ); end; /
現在，如果您要查看會話信息：
select sid, serial#, sql_trace, sql_trace_waits, sql_trace_binds from v$session where username = 'HR'
輸出結果如下：
SID SERIAL# SQL_TRAC SQL_T SQL_T ---------- ---------- -------- ----- ----- 196 60960 ENABLED TRUE FALSE
注意，僅當使用程序包 dbms_monitor 中的過程 session_trace_enable 啟用跟蹤（而不是通過 alter session set sql_trace = true 或設置事件 10046）時，才會填充視圖 V$SESSION。在以后的某個時間點上，如果您要查明哪些會話已經啟用了跟蹤，可以使用以上查詢執行此操作。
如果使用程序包 dbms_monitor 中的其他過程（如 SERV_MOD_ACT_TRACE_ENABLE 或 CLIENT_ID_TRACE_ENABLE）啟用了跟蹤，V$SESSION 視圖將不顯示該信息。相反，它們將記錄到另一個視圖 DBA_ENABLED_TRACES 中?？梢詫⒃撘晥D與其他相關信息存儲連接在一起以查看啟用了跟蹤的會話。例如，使用
SELECT * FROM (SELECT SID, 'SESSION_TRACE' trace_type FROM v$session WHERE sql_trace = 'ENABLED') UNION (SELECT SID, t.trace_type FROM v$session s, dba_enabled_traces t WHERE t.trace_type = 'CLIENT_ID' AND s.client_identifier = t.primary_id) UNION (SELECT SID, t.trace_type FROM v$session s, dba_enabled_traces t, v$instance i WHERE t.trace_type = 'SERVICE' AND s.service_name = t.primary_id AND (t.instance_name IS NULL OR t.instance_name = i.instance_name)) UNION (SELECT SID, t.trace_type FROM v$session s, dba_enabled_traces t, v$instance i WHERE t.trace_type = 'SERVICE_MODULE' AND s.service_name = t.primary_id AND s.module = t.qualifier_id1 AND (t.instance_name IS NULL OR t.instance_name = i.instance_name)) UNION (SELECT SID, t.trace_type FROM v$session s, dba_enabled_traces t, v$instance i WHERE t.trace_type = 'SERVICE_MODULE_ACTION' AND s.service_name = t.primary_id AND s.module = t.qualifier_id1 AND s.action = t.qualifier_id2 AND (t.instance_name IS NULL OR t.instance_name = i.instance_name)) UNION (SELECT SID, t.trace_type FROM v$session s, dba_enabled_traces t, v$instance i WHERE t.trace_type = 'DATABASE' AND (t.instance_name IS NULL OR t.instance_name = i.instance_name))
輸出結果如下：
SID TRACE_TYPE ---------- --------------------- 136 SERVICE_MODULE 136 SERVICE_MODULE_ACTION
您可以看到，您已經對會話 136 的 Service Module 和 Service Module Action 啟用了跟蹤。但 DBA_ENABLED_TRACES 并未顯示綁定變量或等待事件。
活動會話歷史記錄
現在您應該很清楚自動工作負載信息庫 (AWR) 的重要性和有用性。（如果需要，請閱讀有關 AWR 的內容。）簡單而言，AWR 以預定時間間隔在用戶和系統級別捕獲與工作負載相關的性能數據，包括按不同的維度、量度捕獲的性能統計信息、操作系統統計信息以及 ASH 數據。
活動會話歷史記錄 (ASH) 中記錄了最近所有活動會話的活動，它通過內存中的循環緩沖區高效地捕獲這些活動并將它們高效地寫入 AWR ，可將開銷降低到最低程度?？梢园床煌木S度增加 ASH 數據：TOP SQL、對象、文件、會話、模塊、操作等。
然而，大多數數據庫管理員通常只要診斷臨時的性能問題。為診斷此類問題，Oracle 數據庫 10g 第 2 版引入了 ASH 報表。ASH 報表可用于整個數據庫或特定會話、SQL_ID、模塊、操作或這些維度的組合。
訪問 ASH 報表的方法之一是從數據庫頁面進行訪問。選擇 Performance 選項卡，將出現一個類似下圖的屏幕。
注意“Run ASH Report”按鈕（位于紅色橢圓框內）。單擊該按鈕將顯示 Active Session History 報表：
您可以在該屏幕中輸入你期望的時段的起始時間和結束時間的日期和時間。根據需要輸入日期和時間，然后按右上角的“Generate Report”按鈕。默認的日期和時間將有一個 5 分鐘的間隔。
單擊該按鈕后，您將在屏幕上看到該時段的 ASH 報表。如果仔細觀察，您將看到該報表類似于 STASPACK 報表；但由于它源自 AWR 數據，因此其中的量度更為有用。下面顯示了該屏幕的一小部分：
可以按按鈕“Save to File”將該報表保存到文件，以便以后查看。
注意“ASH Report”部分中的鏈接。在此處，您可以全覽不同類型的與性能相關的可用統計信息。例如，您只需單擊 Top Events 鏈接便會看到該時段中的最重要事件。如果該時段出現性能問題，該信息將為您提供很大的幫助。通過查看 ASH 報表中列出的各個維度的偏差，您通?？梢源_定導致瞬時尖峰的瓶頸。
注意，該報表是根據相應的從 AWR 收集的或從內存中緩沖區提取的數據而得出的；因此，如果要診斷先前出現的性能問題，只需激活該時段的 ASH 報表便會看到任何可能已經出現的問題。
也可以通過命令行運行 ASH 報表，方法是運行位于 $OH/rdbms/admin/ashrpt.sql 中的由 Oracle 附帶的 SQL 腳本。
優化程序統計信息管理
Oracle 數據庫 10g 提供了多個非常有用的用于管理優化程序統計信息的特性，如一個用于鎖定統計信息以防止后期覆蓋的特性。這些特性使收集和管理優化程序統計信息這一任務變得輕而易舉。在 Oracle 數據庫 10g 第 2 版中，您可以使用 Oracle 企業管理器執行該操作。
從 Database 主頁中，單擊 Administration 選項卡。向下滾動到“Statistics Management”的部分，在該部分中您將看到如下所示的 Manage Optimizer Statistics 鏈接。
單擊該超鏈接將轉到下個屏幕：Manage Optimizer Statistics 頁面。
從該屏幕中，您可以使用右側的超鏈接執行各種與統計信息相關的任務。例如，使用 Configure 按鈕，您可以通過選擇一個新窗口輕松地為作業配置一個不同的時段。
一個尤其有用的特性是位于“Related Links”下的 Statistics Options 鏈接。單擊它將顯示以下屏幕：
從該屏幕中您可以執行許多有用的任務，如更改并行度的默認值以及估算百分比。
傳輸 AWR 數據
假設您要嘗試解決生產數據庫中的某些性能問題。本文有一部分已經說明了 AWR 數據對于分析是很重要的。但在正常的生產期間分析 AWR 數據可能并不合適，甚至是不可行的。相反，您可能希望將數據加載到某個中心位置以進行比較分析。如何完成該任務呢？
Oracle 數據庫 10g 第 2 版中提供了一個用于此目的的新程序包 DBMS_SWRF_INTERNAL。要將它下載到 Data Pump 轉儲文件，您將使用過程 AWR_EXTRACT：
1 begin 2 DBMS_SWRF_INTERNAL.AWR_EXTRACT ( 3 dmpfile => 'awr_data.dmp', 4 dmpdir => 'TMP_DIR', 5 bid => 302, 6 eid => 305 7 ); 8* end;我們來更詳細地介紹一下以上各行。
| 行 | 說明 |
| 3 | 此處介紹了數據的目標文件名。這是一個 Data Pump 導出文件。如果未提供文件名，則使用默認值 awrdat.dmp。 |
| 4 | 寫入轉儲文件的目錄對象。在本示例中，您可能已將目錄 TMP_DIR 定義為 /tmp。 |
| 5 | 該時段起始快照的 ID。 |
| 6 | 結束快照 ID。您在此處導出位于 302 和 305 之間的快照。 |
現在，您可以將轉儲文件 awr_data.dmp 置于一個新位置，并使用同一程序包中的另一個過程 AWR_LOAD 加載它：
1 begin 2 DBMS_SWRF_INTERNAL.AWR_LOAD ( 3 SCHNAME => 'ARUP', 4 dmpfile => 'awr_data', 5 dmpdir => 'TMP_DIR' 6 ); 7* end;在此代碼中，您將轉儲文件 awr_data.dmp 的內容加載到由目錄對象 TMP_DIR 指定的目錄中。加載 AWR 數據時，它并不直接加載到 SYS 模式中，而是先進入另一個模式中。參數 SCHNAME 中提供了模式名（如第 3 行中所示）。導入后，該數據移動到 SYS 模式中：
1 begin 2 DBMS_SWRF_INTERNAL.MOVE_TO_AWR ( 3 SCHNAME => 'ARUP' 4 ); 5* end;此處，您將模式 ARUP 中的 AWR 數據移動到 SYS。
正如我在上面指出的，將 AWR 移動到其他數據庫具有很多優點和用途?？梢栽诓煌臄祿熘蟹治鰯祿粫ιa造成太大的影響。此外，可以構建一個由從多個數據庫中收集的 AWR 數據組成的中心數據庫。
所有這些加載步驟都已經放置到一個名為 awrload.sql 的文件（位于 $ORACLE_HOME/rdbms/bin 目錄中）中。同樣，腳本 awrextr.sql 包含提取過程的所有步驟。
盡管這個將生產 AWR 數據卸載到備用數據庫的機制已被外部化，但它在 Oracle 數據庫 10g 第 2 版中的主要用途是幫助解決客戶報告的任何問題。使用此方法，客戶可以發送 AWR 轉儲文件格式的原始數據，支持人員隨后可以將這些數據導入到他們的模式中以幫助重現和診斷問題。
比較時段報表
假設出現這樣一種情況：您剛剛通知業務和應用程序小組召開一個緊急會議。原因很明顯：數據庫很慢。（是否有任何其他原因？）開發技術主管指出了會議的要點：于昨天凌晨 1 點至凌晨 3 點之間運行的批處理程序非常慢。該程序在該時間通常運行大約 30 分鐘，而昨天凌晨卻運行了兩個小時。業務小組主管果斷聲明：“公司經歷了潛在的收入損失。”
“最近是否進行過更改”，您問到。“沒有，一切都未更改”，開發技術主管非?？隙ǖ鼗卮鸬?。（“是的，沒錯”，您心里是這樣認為的。）
聽起來熟悉嗎？如果您從事生產支持這個苦差事的時間甚至是我的十倍，您便會立即同意。您會怎么做？
幸運地是，您擁有 Oracle 數據庫 10g 第 2 版，并在 Oracle 企業數據庫中啟動了 Snapshot 或 Time Periods 比較。使用此特性，您可以看到兩個時間間隔（而不僅僅是兩個時間點）之間的量度更改。例如，在本示例中，您可能請求查看昨天凌晨 1 點至凌晨 3 點之間的快照更改，并查看前天同一時段之間的快照更改。如果批處理過程在前天運行良好，而在昨天凌晨出現異常，那么快照更改將給您提供一個重要線索。
以下是它的工作方式：啟動 Oracle 企業管理器并轉到 Performance 選項卡。在該頁面底部，您將看到“Additional Monitoring Links”部分。在該鏈接組中，搜索“Snapshots”。單擊該鏈接將顯示一個類似如下所示的屏幕。
