数据库性能检查指导方案
生活随笔
收集整理的這篇文章主要介紹了
数据库性能检查指导方案
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
在系統穩定之后，應該按照本指導方案每個月檢查一次產品數據庫。
該指導方案適用于Oracle9i數據庫，因為有些腳本在9i中才可以運行。
檢查方式均為以sysdba身份登錄數據庫以后在SQLPLUS中執行命令腳本（每小節的“檢查方法”部分有詳細的命令腳本）。
登陸數據庫的命令：
sqlplus “sys/password as sysdba”
一．內存性能評估
在內存性能評估的時候，我們使用內存性能指數（MPI, Memory Performance Index），下表列出了MPI中的各項指數，這個評分系統并不意味著對內存的使用和分配的全方位評估，而只是代表一個晴雨表，反映當前系統內存的使用和分配狀況。
MPI指數
分類
所需等級
最高分
緩沖區命中率（Buffer Cache）
>98%
30
數據字典命中率（Dictionary Cache）
>98%
30
庫緩存命中率（Library Cache）
>98%
30
內存中的排序（Sort in Memory）
>98%
30
空閑的數據緩沖區比例
10-25%
30
使用最多的前10個SQL占用的內存
<5%
60
是否已經調整使用最多的前25個SQL
是
30
是否嘗試固定高速緩存中經常使用的對象
是
10
MPI指數
總分
250
1． 緩沖區命中率
顯示了對于數據總讀取量而言，非磁盤讀取（緩沖區命中）的百分比。當然，十分高的命中率并不代表數據庫性能一定優良，也有可能是糟糕的SQL引起了大量的緩沖區讀操作，只有在已經調整過首要的查詢之后，這個命中率才能更好地反映數據庫性能。
檢查方法：
select (1 - (sum(decode(name, 'physical reads', value, 0)) /
?????? (sum(decode(name, 'db block gets', value, 0)) +
?????? sum(decode(name, 'consistent gets', value, 0))))) * 100
?????? "Hit Ratio"
?? from v$sysstat;
評估準則：
等級
分數
<90%
0
90-94%
10
95-98%
20
>98%
30
2． 數據字典命中率
顯示了對數據字典和其它對象的內存讀操作的百分比。
檢查方法：
select (1 - (sum(getmisses) / sum(gets))) * 100 "Hit Ratio"
?? from v$rowcache;
評估準則：
等級
分數
<85%
0
86-92%
10
92-98%
20
>98%
30
3． 庫緩存命中率
顯示了對SQL和PL/SQL對象的內存讀操作的百分比。同樣注意，很高的命中率并不總是反映數據庫性能優秀。
檢查方法：
select sum(pins) / (sum(pins) + sum(reloads)) * 100 "Hit Ratio"
?? from v$librarycache;
評估準則：
等級
分數
<90%
0
90-94%
10
94-98%
20
>98%
30
4． 內存中的排序
根據初始化參數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE的值，用戶的排序操作可能在內存中執行，也可能在臨時表空間中執行。這個檢查用以顯示在內存中排序占總排序的百分比。
檢查方法：
select a.value "Disk Sorts",
?????? b.value "Memory Sorts",
?????? round((100 * b.value) /
???????????? decode((a.value + b.value), 0, 1, (a.value + b.value)),
???????????? 2) "Pct Memory Sorts"
?? from v$sysstat a, v$sysstat b
where a.name = 'sorts (disk)'
?? and b.name = 'sorts (memory)';
評估準則：
等級
分數
<90%
0
90-94%
10
94-98%
20
>98%
30
5． 空閑的數據緩沖區比例
空閑的記錄數除以X$BH表中的記錄總數（即所分配的數據塊緩沖區的總數）得到的空閑緩沖區百分比。同樣注意，擁有眾多空閑緩沖區的數據庫不一定是最佳環境，因為可能是緩沖區設置過大，浪費內存。
檢查方法：
select decode(state,
?????????????? 0,
?????????????? 'FREE',
?????????????? 1,
?????????????? decode(lrba_seq, 0, 'AVAILABLE', 'BEING USED'),
?????????????? 3,
?????????????? 'BEING USED',
?????????????? state) "Block Status",
?????? count(*)
?? from x$bh
group by decode(state,
???????????????? 0,
???????????????? 'FREE',
???????????????? 1,
???????????????? decode(lrba_seq, 0, 'AVAILABLE', 'BEING USED'),
???????????????? 3,
???????????????? 'BEING USED',
???????????????? state);
評估準則：
等級
分數
<5%
0
5-19%
30
20-25%
20
>25%
0
6． 最浪費內存的前10個語句占全部內存讀取量的比例
通常一個沒有優化系統中，10個最常用的SQL語句的訪問量會占到整個系統中內存讀操作的50%以上。這些SQL是最需要進行優化的部分，也是優化工作中優先級很高的部分。
檢查方法：
select sum(pct_bufgets)
?? from (select rank() over(order by buffer_gets desc) as rank_bufgets,
?????????????? to_char(100 * ratio_to_report(buffer_gets) over(), '999.99') pct_bufgets
?????????? from v$sqlarea)
where rank_bufgets < 11;
評估準則：
等級
分數
<5%
60
5-19%
50
20-25%
30
>25%
0
7． 調整前25個最浪費內存的語句
在沒有調整的情況下，絕大多數系統中，訪問量占前25位的語句的內存讀操作將占用整個系統所有內存讀操作的75%，對這部分語句進行調整是至關重要的。這部分腳本用于獲得訪問量占前25位的SQL語句。
檢查方法：
set serveroutput on size 1000000
declare
?? top25 number;
?? text1 varchar2(4000);
?? x???? number;
?? len1?? number;
?? cursor c1 is
???? select buffer_gets, substr(sql_text, 1, 4000)
?????? from v$sqlarea
???? order by buffer_gets desc;
begin
?? dbms_output.put_line('Gets' || '???? ' || 'Text');
?? dbms_output.put_line('--------' || ' ' || '---------------');
?? open c1;
?? for i in 1 .. 25 loop
???? fetch c1
?????? into top25, text1;
???? dbms_output.put_line(rpad(to_char(top25), 9) || ' ' ||
???????????????????????? substr(text1, 1, 66));
???? len1 := length(text1);
???? x???? := 66;
???? while len1 > x - 1 loop
?????? dbms_output.put_line('"???????? ' || substr(text1, x, 66));
?????? x := x + 66;
???? end loop;
?? end loop;
end;
/
評估準則：
本部分沒有評估準則，需要開發人員或者DBA去確認在這25個SQL中屬于應用系統的語句是否都已經作過調優。
8． 固定緩存對象
嘗試在內存中固定（pin）經常使用的對象，包括表，存儲過程等。
檢索需要在共享池中要求大于100K連續空間的對象：
select *
?? from v$db_object_cache
where sharable_mem > 100000
?? and type in ('PACKAGE', 'PACKAGE BODY', 'PROCEDURE', 'FUNCTION');
考察返回的結果，確認是否需要pin到共享池中，返回結果中的KEPT字段如果是YES，那么表示該對象已經固定在了共享池中，為NO，則表示還沒有固定。
如果需要固定，使用下面的語句：
exec dbms_shared_pool.keep('SYS.STANDARD');????????????
數據庫默認安裝的時候沒有創建dbms_shared_pool包，所以需要先創建該包。
cd $ORACLE_HOME/rdbms/admin
sqlplus “/ as sysdba”
@dbmspool.sql
如果我們要固定表，那么可以在創建表的時候或者修改表屬性時使用CACHE關鍵字，將表放置到Buffer Cache的LRU列表的MRU端。通常我們需要對于較小的但是頻繁使用的表進行這種操作。
alter table table_name cache;
我們也可以將需要頻繁使用的表放置到另外一個獨立的Buffer Cache中，比如KEEP池。這種操作可以使這些表的數據不至于很快被清除出Default Buffer Cache。
alter table table_name storage (buffer pool keep);
評估準則：
本部分沒有評估準則，需要開發人員或者DBA在系統分析以后謹慎執行。
二 存儲性能評估 在存儲性能評估的時候，我們使用磁盤性能指數（DPI, Disk Performance Index），下表列出了DPI中的各項指數，這個評分系統并不意味著對磁盤的使用和分配的全方位評估，而只是代表一個晴雨表，反映當前磁盤的使用和分配上是否存在需要改進或者注意的地方。 DPI指數 分類 所需等級 最高分 調整表和索引 是 30 表的行連接問題 無 30 分離關鍵的Oracle文件 是 30 回滾段的平衡??30 臨時段的平衡??30 使用最多的前10個SQL的磁盤使用率 <5 60 是否已經調整使用磁盤最多的前25個SQL 是 40 DPI指數 總分 250 1． 調整表和索引 由于表和索引的數據塊通常是被同時讀取的，所以應該盡量將表和其相關聯的索引放置在不同的磁盤上，以便減少文件的I/O沖突。 檢查方法： select i.index_name, t.table_name, t.tablespace_name
? from user_tables t, user_indexes i
?where t.table_name = i.table_name
?? and t.tablespace_name = i.tablespace_name; 返回結果是創建在相同表空間中的表和相關聯的索引。建議創建新的表空間用于專門存放索引，并將當前的索引rebuild到新創建的表空間中。 alter index idx_name rebuild tablespace ts_name; 評估準則： 等級 分數 表和索引放在同一磁盤上 0 存儲使用了磁盤陣列，沒有進一步調整 20 存儲使用了磁盤陣列，對于RAID類型已經作過調整 30 表和索引已經規劃在不同磁盤上 30 2． 表的行鏈接問題 當更新一張表，而數據塊中又沒有足夠的剩余空間來容納所作的修改時，就會發生“行鏈接”現象，該記錄被鏈接到另外一個有足夠空間的數據塊中，也就是一條記錄跨越了多個數據塊，這樣在讀取該記錄的時候就會消耗更多的I/O，當數據庫中有大量的“行鏈接”現象存在時，數據庫的整體性能就會下降。 檢查方法： sqlplus /nolog connect app_user/password SQL> @$ORACLE_HOME/rdbms/admin/utlchain.sql SQL> analyze table <table_name> list chained rows; SQL> select count(*) chained_rows, table_name
? from chained_rows
?group by table_name; 如果沒有返回任何行，則表示沒有“行鏈接”現象。否則將按照已經分析過的表顯示每張表中有多少記錄出現了“行鏈接”現象。 “行鏈接”現象的產生跟PCTFREE參數的設置不當有關系。PCTFREE值默認為10%，如果系統中存在大量行鏈接，表示這個參數指定的塊保留空間過小，不足以容納塊中所有記錄的更新操作。此時應該增大相應表的PCTFREE值。 評估準則： 等級 分數 存在行鏈接現象 0 不存在行鏈接現象 30 3． 分離關鍵的Oracle文件 無論是出于安全性的考慮還是性能的考慮，都建議將關鍵的Oracle文件分布在可用的獨立磁盤上。 首先在錯誤出現之后，用來被恢復的數據文件和用來恢復的控制文件，重作日志文件，歸檔日志文件應該分離存放。如果有可能，將下列各個關鍵文件分布在不同的磁盤上。 系統表空間（SYSTEM），臨時表空間（TEMP），回滾表空間（UNDO），聯機重作日志文件（REDO）和歸檔日志文件（ARCH），經常訪問的用戶表空間，經常訪問的用戶索引表空間，操作系統盤，$ORACL_EBASE中的關鍵Oracle軟件文件。 至少聯機重作日志文件（REDO）和歸檔日志文件（ARCH）應該跟其它文件存放在不同的磁盤上，并且由于日志文件的大部分時間為只寫屬性，所以需要考慮RAID5在寫方面的弱勢，盡量不要將日志文件存放在RAID5的陣列組上。 檢查方法： select file_name, tablespace_name, bytes
? from dba_data_files
union all
select file_name, tablespace_name, bytes
? from dba_temp_files
union all
select name file_name, NULL, NULL
? from v$controlfile
union all
select member file_name, to_char(a.group#) tablespace_name, b.bytes bytes
? from v$logfile a, v$log b
?where a.group# = b.group#
union all (select value file_name, NULL, NULL
???????????? from v$parameter
??????????? where name like 'log_archive_dest_%'
????????????? and value is not null
?????????? minus
?????????? select value file_name, NULL, NULL
???????????? from v$parameter
??????????? where name like 'log_archive_dest_state%'); 返回數據庫中所有關鍵文件存儲的位置，由DBA和SA考察返回的結果，確認已經對于關鍵文件的存儲位置作過符合實際情況的調整。 評估準則： 等級 分數 沒有調整，全部在單個磁盤上 0 沒有調整，全部在RAID上 20 已經調整 30 4． 回滾段的平衡 在Oracle 9i和Oracle9i之前如果沒有使用回滾段自動管理，那么對于回滾段的性能仍然是需要監控并且調整的。 檢查是否使用了回滾段自動管理： select name, value from v$parameter where name like '%undo_%'; 如果返回結果中undo_management的值是AUTO，則表示使用了回滾段自動管理，同時undo_tablespace值顯示了自動管理使用的回滾表空間，undo_retention值顯示了在回滾表空間中保留回滾數據的時限，以秒為單位。 注意：如果undo_management的值是AUTO但是undo_tablespace沒有設置相應的值，那么就會使用SYSTEM表空間中的SYSTEM回滾段，這個是絕對應該避免的現象。 如果沒有使用回滾段自動管理，那么需要監控用戶使用回滾段的頻度，原則上認為不應該有超過1個用戶同時使用1個回滾段。 檢查方法： select a.name,
?????? b.extents,
?????? b.rssize,
?????? b.xacts,
?????? b.waits,
?????? b.gets,
?????? optsize,
?????? status
? from v$rollname a, v$rollstat b
?where a.usn = b.usn; 檢查輸出結果，對于所有回滾段而言，如果xacts（活動事務）和waits（段頭等待）經常超出1，那么就表明需要增加回滾段數目，以避免可能出現的爭用。 增加回滾段的方法： create rollback segment rs_name tablespace RBS storage(initial 1M next 2M);
alter rollback segment rs_name online; 如果使用了回滾段自動管理，那么可以從v$undostat, v$rollstat, dba_undo_extents等視圖中查詢當前回滾段的使用和分配情況。 評估準則： 等級 分數 有回滾段等待現象 0 無回滾段等待現象 30 使用了回滾段自動管理 30 5． 臨時段的平衡 當初始化參數中定義的SORT_AREA_SIZE大小無法滿足排序要求的空間，就會使用臨時表空間中的臨時段進行排序，磁盤排序比內存排序要慢100-10000倍，所以盡量減少磁盤排序是性能調整工作的一個重要部分。 可能引起排序的操作有create index, distinct, order by, group by等。 檢查方法： select name, value from v$sysstat where name like '%sorts%'; 返回結果中的sorts (memory)表示內存排序，而sorts (disk)則表示磁盤排序，如果存在大量的磁盤排序，則表明我們需要增加SORT_AREA_SIZE或者HASH_AREA_SIZE等排序區的大小，或者需要檢查目前系統中消耗大量磁盤的SQL是否已經經過調整（檢查前25位消耗磁盤的SQL在后面部分將提到）。 檢查使用磁盤排序的會話信息，可以定位執行了大量磁盤排序的會話。 檢查方法： select b.name, a.sid, a.value
? from v$sesstat a, v$statname b
?where a.STATISTIC# = b.STATISTIC#
?? and b.name = 'sorts (disk)'
?? and a.value > 0
?order by a.value desc; 如果有可能我們應該將臨時表空間中的多個臨時數據文件分布在不同的磁盤上，以減少排序時可能會產生的磁盤沖突。 在Oracle9i中，我們可以設置PGA_AGGREGATE_SIZE初始化參數來指定所有會話將使用的PGA大小，同時也必須設置WORKAREA_SIZE_POLICY參數為AUTO。其它詳細信息見內存性能評估中“4。內存中的排序”部分。 評估準則： 等級 分數 對于存在的磁盤排序沒有評估 0 已經就存在的磁盤排序進行過調整 30 6． 最浪費磁盤讀操作的前10個語句占所有語句的比例 通常一個沒有優化系統中，10個最常用的SQL語句的訪問量會占到整個系統中磁盤讀操作的50%以上。這些SQL是最需要進行優化的部分，也是優化工作中優先級很高的部分。通常我們的優化目標是將這些SQL的磁盤讀操作百分比降低到5-19%。 檢查方法： select sum(pct_bufgets)
? from (select rank() over(order by disk_reads desc) as rank_bufgets,
?????????????? to_char(100 * ratio_to_report(disk_reads) over(), '999.99') pct_bufgets
????????? from v$sqlarea)
?where rank_bufgets < 11; 評估準則： 等級 分數 <5% 60 5-19% 50 20-25% 30 >25% 0 7． 調整前25個最浪費磁盤讀操作的語句 在沒有調整的情況下，絕大多數系統中，訪問量占前25位的語句的磁盤讀操作將占用整個系統所有磁盤讀操作的75%，對這部分語句進行調整是至關重要的。這部分腳本用于獲得訪問量占前25位的SQL語句。輸出結果中的Exec表示該SQL被執行的次數。 檢查方法： set serveroutput on size 1000000
declare
? execution number;
? top25???? number;
? text1???? varchar2(4000);
? x???????? number;
? len1????? number;
? cursor c1 is
??? select executions, disk_reads, substr(sql_text, 1, 4000)
????? from v$sqlarea
???? order by disk_reads desc;
begin
? dbms_output.put_line('Exec' || '? ' || 'Reads' || '????? ' || 'Text');
? dbms_output.put_line('-----' || ' ' || '--------' || ' ' ||
?????????????????????? '-------------');
? open c1;
? for i in 1 .. 25 loop
??? fetch c1
????? into execution, top25, text1;
??? dbms_output.put_line(rpad(to_char(execution), 5) || ' ' ||
???????????????????????? rpad(to_char(top25), 8) || ' ' ||
???????????????????????? substr(text1, 1, 66));
??? len1 := length(text1);
??? x??? := 66;
??? while len1 > x - 1 loop
????? dbms_output.put_line('-????????????? ' || substr(text1, x, 66));
????? x := x + 66;
??? end loop;
? end loop;
end;
/ 評估準則： 本部分沒有具體的評估準則，需要開發人員或者DBA去確認在這25個SQL中屬于應用系統的語句是否都已經作過調優。 8． 其它存儲相關的調整 1)????? 字典管理表空間中的Extent總數不超過4096 檢查方法： select a.tablespace_name, sum(a.extents)
? from dba_segments a, dba_tablespaces b
?where a.tablespace_name = b.tablespace_name
?? and b.extent_management = 'DICTIONARY'
?group by a.tablespace_name
?order by sum(a.extents); 檢查輸出結果，如果顯示某個表空間中的extents總數超過了4096，那么需要擴大這個表空間的extent大小，過多的extent對于DMT的空間管理有負面影響。 2)????? 本地管理表空間中單個Segement的Extent數不超過1024 檢查方法： select segment_name, segment_type, extents, bytes, b.tablespace_name
? from dba_segments a, dba_tablespaces b
?where a.tablespace_name = b.tablespace_name
?? and b.extent_management = 'LOCAL'
?? and a.extents > 1024; 檢查輸出結果，返回的記錄都是單個段的區間大于1024的對象，對于這些對象，應該創建一個單獨的具有更大extent大小的表空間，然后將這些對象move到新的表空間中去。 3)????? 檢查字典管理表空間的PCTINCREASE值是否是0 為了表空間中的所有extent大小相同，建議表空間中的所有段都不要設置獨立的storage參數。對于表空間的pctincrease參數，建議設置為0，同時應該設置minextents參數，保證初始分配足夠的空間給新創建的對象。 對于LMT表空間，storage參數中的pctincrease和next參數均無效，建議設置適當的uniform參數管理表空間的extent分配。 4)????? 考慮使用分區來避免磁盤爭用 分區表在管理的方便性和性能的提高上都有較強的實用性，甚至可以認為分區是提高與大型表有關的性能的最佳方法。通過訪問一個表或者索引的較小片段，而不是訪問整個表或索引，分區可以很好地提高效率。如果一個表或者索引的分區位于不同的磁盤上，就更可以大大增加數據吞吐量，獲得很好的數據庫性能。 對于分區的使用，暫時不在本文的敘述范圍內，請參閱其它的分區文檔。 5)????? 對于分區表的非分區鍵索引是否是全局分區索引 由于分區表的數據量通常比較巨大，所以如果在分區表的非分區鍵上創建索引，那么建議創建為全局分區索引，這樣能夠更好地提高性能。注意：如果截斷了一個分區的數據或者刪除了一個分區，那么必須rebuild這個分區表中的全部全局索引，否則這些全局索引將處于invalid狀態，導致使用到這些索引的SQL語句失敗。
該指導方案適用于Oracle9i數據庫，因為有些腳本在9i中才可以運行。
檢查方式均為以sysdba身份登錄數據庫以后在SQLPLUS中執行命令腳本（每小節的“檢查方法”部分有詳細的命令腳本）。
登陸數據庫的命令：
sqlplus “sys/password as sysdba”
一．內存性能評估
在內存性能評估的時候，我們使用內存性能指數（MPI, Memory Performance Index），下表列出了MPI中的各項指數，這個評分系統并不意味著對內存的使用和分配的全方位評估，而只是代表一個晴雨表，反映當前系統內存的使用和分配狀況。
MPI指數
分類
所需等級
最高分
緩沖區命中率（Buffer Cache）
>98%
30
數據字典命中率（Dictionary Cache）
>98%
30
庫緩存命中率（Library Cache）
>98%
30
內存中的排序（Sort in Memory）
>98%
30
空閑的數據緩沖區比例
10-25%
30
使用最多的前10個SQL占用的內存
<5%
60
是否已經調整使用最多的前25個SQL
是
30
是否嘗試固定高速緩存中經常使用的對象
是
10
MPI指數
總分
250
1． 緩沖區命中率
顯示了對于數據總讀取量而言，非磁盤讀取（緩沖區命中）的百分比。當然，十分高的命中率并不代表數據庫性能一定優良，也有可能是糟糕的SQL引起了大量的緩沖區讀操作，只有在已經調整過首要的查詢之后，這個命中率才能更好地反映數據庫性能。
檢查方法：
select (1 - (sum(decode(name, 'physical reads', value, 0)) /
?????? (sum(decode(name, 'db block gets', value, 0)) +
?????? sum(decode(name, 'consistent gets', value, 0))))) * 100
?????? "Hit Ratio"
?? from v$sysstat;
評估準則：
等級
分數
<90%
0
90-94%
10
95-98%
20
>98%
30
2． 數據字典命中率
顯示了對數據字典和其它對象的內存讀操作的百分比。
檢查方法：
select (1 - (sum(getmisses) / sum(gets))) * 100 "Hit Ratio"
?? from v$rowcache;
評估準則：
等級
分數
<85%
0
86-92%
10
92-98%
20
>98%
30
3． 庫緩存命中率
顯示了對SQL和PL/SQL對象的內存讀操作的百分比。同樣注意，很高的命中率并不總是反映數據庫性能優秀。
檢查方法：
select sum(pins) / (sum(pins) + sum(reloads)) * 100 "Hit Ratio"
?? from v$librarycache;
評估準則：
等級
分數
<90%
0
90-94%
10
94-98%
20
>98%
30
4． 內存中的排序
根據初始化參數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE的值，用戶的排序操作可能在內存中執行，也可能在臨時表空間中執行。這個檢查用以顯示在內存中排序占總排序的百分比。
檢查方法：
select a.value "Disk Sorts",
?????? b.value "Memory Sorts",
?????? round((100 * b.value) /
???????????? decode((a.value + b.value), 0, 1, (a.value + b.value)),
???????????? 2) "Pct Memory Sorts"
?? from v$sysstat a, v$sysstat b
where a.name = 'sorts (disk)'
?? and b.name = 'sorts (memory)';
評估準則：
等級
分數
<90%
0
90-94%
10
94-98%
20
>98%
30
5． 空閑的數據緩沖區比例
空閑的記錄數除以X$BH表中的記錄總數（即所分配的數據塊緩沖區的總數）得到的空閑緩沖區百分比。同樣注意，擁有眾多空閑緩沖區的數據庫不一定是最佳環境，因為可能是緩沖區設置過大，浪費內存。
檢查方法：
select decode(state,
?????????????? 0,
?????????????? 'FREE',
?????????????? 1,
?????????????? decode(lrba_seq, 0, 'AVAILABLE', 'BEING USED'),
?????????????? 3,
?????????????? 'BEING USED',
?????????????? state) "Block Status",
?????? count(*)
?? from x$bh
group by decode(state,
???????????????? 0,
???????????????? 'FREE',
???????????????? 1,
???????????????? decode(lrba_seq, 0, 'AVAILABLE', 'BEING USED'),
???????????????? 3,
???????????????? 'BEING USED',
???????????????? state);
評估準則：
等級
分數
<5%
0
5-19%
30
20-25%
20
>25%
0
6． 最浪費內存的前10個語句占全部內存讀取量的比例
通常一個沒有優化系統中，10個最常用的SQL語句的訪問量會占到整個系統中內存讀操作的50%以上。這些SQL是最需要進行優化的部分，也是優化工作中優先級很高的部分。
檢查方法：
select sum(pct_bufgets)
?? from (select rank() over(order by buffer_gets desc) as rank_bufgets,
?????????????? to_char(100 * ratio_to_report(buffer_gets) over(), '999.99') pct_bufgets
?????????? from v$sqlarea)
where rank_bufgets < 11;
評估準則：
等級
分數
<5%
60
5-19%
50
20-25%
30
>25%
0
7． 調整前25個最浪費內存的語句
在沒有調整的情況下，絕大多數系統中，訪問量占前25位的語句的內存讀操作將占用整個系統所有內存讀操作的75%，對這部分語句進行調整是至關重要的。這部分腳本用于獲得訪問量占前25位的SQL語句。
檢查方法：
set serveroutput on size 1000000
declare
?? top25 number;
?? text1 varchar2(4000);
?? x???? number;
?? len1?? number;
?? cursor c1 is
???? select buffer_gets, substr(sql_text, 1, 4000)
?????? from v$sqlarea
???? order by buffer_gets desc;
begin
?? dbms_output.put_line('Gets' || '???? ' || 'Text');
?? dbms_output.put_line('--------' || ' ' || '---------------');
?? open c1;
?? for i in 1 .. 25 loop
???? fetch c1
?????? into top25, text1;
???? dbms_output.put_line(rpad(to_char(top25), 9) || ' ' ||
???????????????????????? substr(text1, 1, 66));
???? len1 := length(text1);
???? x???? := 66;
???? while len1 > x - 1 loop
?????? dbms_output.put_line('"???????? ' || substr(text1, x, 66));
?????? x := x + 66;
???? end loop;
?? end loop;
end;
/
評估準則：
本部分沒有評估準則，需要開發人員或者DBA去確認在這25個SQL中屬于應用系統的語句是否都已經作過調優。
8． 固定緩存對象
嘗試在內存中固定（pin）經常使用的對象，包括表，存儲過程等。
檢索需要在共享池中要求大于100K連續空間的對象：
select *
?? from v$db_object_cache
where sharable_mem > 100000
?? and type in ('PACKAGE', 'PACKAGE BODY', 'PROCEDURE', 'FUNCTION');
考察返回的結果，確認是否需要pin到共享池中，返回結果中的KEPT字段如果是YES，那么表示該對象已經固定在了共享池中，為NO，則表示還沒有固定。
如果需要固定，使用下面的語句：
exec dbms_shared_pool.keep('SYS.STANDARD');????????????
數據庫默認安裝的時候沒有創建dbms_shared_pool包，所以需要先創建該包。
cd $ORACLE_HOME/rdbms/admin
sqlplus “/ as sysdba”
@dbmspool.sql
如果我們要固定表，那么可以在創建表的時候或者修改表屬性時使用CACHE關鍵字，將表放置到Buffer Cache的LRU列表的MRU端。通常我們需要對于較小的但是頻繁使用的表進行這種操作。
alter table table_name cache;
我們也可以將需要頻繁使用的表放置到另外一個獨立的Buffer Cache中，比如KEEP池。這種操作可以使這些表的數據不至于很快被清除出Default Buffer Cache。
alter table table_name storage (buffer pool keep);
評估準則：
本部分沒有評估準則，需要開發人員或者DBA在系統分析以后謹慎執行。
二 存儲性能評估 在存儲性能評估的時候，我們使用磁盤性能指數（DPI, Disk Performance Index），下表列出了DPI中的各項指數，這個評分系統并不意味著對磁盤的使用和分配的全方位評估，而只是代表一個晴雨表，反映當前磁盤的使用和分配上是否存在需要改進或者注意的地方。 DPI指數 分類 所需等級 最高分 調整表和索引 是 30 表的行連接問題 無 30 分離關鍵的Oracle文件 是 30 回滾段的平衡??30 臨時段的平衡??30 使用最多的前10個SQL的磁盤使用率 <5 60 是否已經調整使用磁盤最多的前25個SQL 是 40 DPI指數 總分 250 1． 調整表和索引 由于表和索引的數據塊通常是被同時讀取的，所以應該盡量將表和其相關聯的索引放置在不同的磁盤上，以便減少文件的I/O沖突。 檢查方法： select i.index_name, t.table_name, t.tablespace_name
? from user_tables t, user_indexes i
?where t.table_name = i.table_name
?? and t.tablespace_name = i.tablespace_name; 返回結果是創建在相同表空間中的表和相關聯的索引。建議創建新的表空間用于專門存放索引，并將當前的索引rebuild到新創建的表空間中。 alter index idx_name rebuild tablespace ts_name; 評估準則： 等級 分數 表和索引放在同一磁盤上 0 存儲使用了磁盤陣列，沒有進一步調整 20 存儲使用了磁盤陣列，對于RAID類型已經作過調整 30 表和索引已經規劃在不同磁盤上 30 2． 表的行鏈接問題 當更新一張表，而數據塊中又沒有足夠的剩余空間來容納所作的修改時，就會發生“行鏈接”現象，該記錄被鏈接到另外一個有足夠空間的數據塊中，也就是一條記錄跨越了多個數據塊，這樣在讀取該記錄的時候就會消耗更多的I/O，當數據庫中有大量的“行鏈接”現象存在時，數據庫的整體性能就會下降。 檢查方法： sqlplus /nolog connect app_user/password SQL> @$ORACLE_HOME/rdbms/admin/utlchain.sql SQL> analyze table <table_name> list chained rows; SQL> select count(*) chained_rows, table_name
? from chained_rows
?group by table_name; 如果沒有返回任何行，則表示沒有“行鏈接”現象。否則將按照已經分析過的表顯示每張表中有多少記錄出現了“行鏈接”現象。 “行鏈接”現象的產生跟PCTFREE參數的設置不當有關系。PCTFREE值默認為10%，如果系統中存在大量行鏈接，表示這個參數指定的塊保留空間過小，不足以容納塊中所有記錄的更新操作。此時應該增大相應表的PCTFREE值。 評估準則： 等級 分數 存在行鏈接現象 0 不存在行鏈接現象 30 3． 分離關鍵的Oracle文件 無論是出于安全性的考慮還是性能的考慮，都建議將關鍵的Oracle文件分布在可用的獨立磁盤上。 首先在錯誤出現之后，用來被恢復的數據文件和用來恢復的控制文件，重作日志文件，歸檔日志文件應該分離存放。如果有可能，將下列各個關鍵文件分布在不同的磁盤上。 系統表空間（SYSTEM），臨時表空間（TEMP），回滾表空間（UNDO），聯機重作日志文件（REDO）和歸檔日志文件（ARCH），經常訪問的用戶表空間，經常訪問的用戶索引表空間，操作系統盤，$ORACL_EBASE中的關鍵Oracle軟件文件。 至少聯機重作日志文件（REDO）和歸檔日志文件（ARCH）應該跟其它文件存放在不同的磁盤上，并且由于日志文件的大部分時間為只寫屬性，所以需要考慮RAID5在寫方面的弱勢，盡量不要將日志文件存放在RAID5的陣列組上。 檢查方法： select file_name, tablespace_name, bytes
? from dba_data_files
union all
select file_name, tablespace_name, bytes
? from dba_temp_files
union all
select name file_name, NULL, NULL
? from v$controlfile
union all
select member file_name, to_char(a.group#) tablespace_name, b.bytes bytes
? from v$logfile a, v$log b
?where a.group# = b.group#
union all (select value file_name, NULL, NULL
???????????? from v$parameter
??????????? where name like 'log_archive_dest_%'
????????????? and value is not null
?????????? minus
?????????? select value file_name, NULL, NULL
???????????? from v$parameter
??????????? where name like 'log_archive_dest_state%'); 返回數據庫中所有關鍵文件存儲的位置，由DBA和SA考察返回的結果，確認已經對于關鍵文件的存儲位置作過符合實際情況的調整。 評估準則： 等級 分數 沒有調整，全部在單個磁盤上 0 沒有調整，全部在RAID上 20 已經調整 30 4． 回滾段的平衡 在Oracle 9i和Oracle9i之前如果沒有使用回滾段自動管理，那么對于回滾段的性能仍然是需要監控并且調整的。 檢查是否使用了回滾段自動管理： select name, value from v$parameter where name like '%undo_%'; 如果返回結果中undo_management的值是AUTO，則表示使用了回滾段自動管理，同時undo_tablespace值顯示了自動管理使用的回滾表空間，undo_retention值顯示了在回滾表空間中保留回滾數據的時限，以秒為單位。 注意：如果undo_management的值是AUTO但是undo_tablespace沒有設置相應的值，那么就會使用SYSTEM表空間中的SYSTEM回滾段，這個是絕對應該避免的現象。 如果沒有使用回滾段自動管理，那么需要監控用戶使用回滾段的頻度，原則上認為不應該有超過1個用戶同時使用1個回滾段。 檢查方法： select a.name,
?????? b.extents,
?????? b.rssize,
?????? b.xacts,
?????? b.waits,
?????? b.gets,
?????? optsize,
?????? status
? from v$rollname a, v$rollstat b
?where a.usn = b.usn; 檢查輸出結果，對于所有回滾段而言，如果xacts（活動事務）和waits（段頭等待）經常超出1，那么就表明需要增加回滾段數目，以避免可能出現的爭用。 增加回滾段的方法： create rollback segment rs_name tablespace RBS storage(initial 1M next 2M);
alter rollback segment rs_name online; 如果使用了回滾段自動管理，那么可以從v$undostat, v$rollstat, dba_undo_extents等視圖中查詢當前回滾段的使用和分配情況。 評估準則： 等級 分數 有回滾段等待現象 0 無回滾段等待現象 30 使用了回滾段自動管理 30 5． 臨時段的平衡 當初始化參數中定義的SORT_AREA_SIZE大小無法滿足排序要求的空間，就會使用臨時表空間中的臨時段進行排序，磁盤排序比內存排序要慢100-10000倍，所以盡量減少磁盤排序是性能調整工作的一個重要部分。 可能引起排序的操作有create index, distinct, order by, group by等。 檢查方法： select name, value from v$sysstat where name like '%sorts%'; 返回結果中的sorts (memory)表示內存排序，而sorts (disk)則表示磁盤排序，如果存在大量的磁盤排序，則表明我們需要增加SORT_AREA_SIZE或者HASH_AREA_SIZE等排序區的大小，或者需要檢查目前系統中消耗大量磁盤的SQL是否已經經過調整（檢查前25位消耗磁盤的SQL在后面部分將提到）。 檢查使用磁盤排序的會話信息，可以定位執行了大量磁盤排序的會話。 檢查方法： select b.name, a.sid, a.value
? from v$sesstat a, v$statname b
?where a.STATISTIC# = b.STATISTIC#
?? and b.name = 'sorts (disk)'
?? and a.value > 0
?order by a.value desc; 如果有可能我們應該將臨時表空間中的多個臨時數據文件分布在不同的磁盤上，以減少排序時可能會產生的磁盤沖突。 在Oracle9i中，我們可以設置PGA_AGGREGATE_SIZE初始化參數來指定所有會話將使用的PGA大小，同時也必須設置WORKAREA_SIZE_POLICY參數為AUTO。其它詳細信息見內存性能評估中“4。內存中的排序”部分。 評估準則： 等級 分數 對于存在的磁盤排序沒有評估 0 已經就存在的磁盤排序進行過調整 30 6． 最浪費磁盤讀操作的前10個語句占所有語句的比例 通常一個沒有優化系統中，10個最常用的SQL語句的訪問量會占到整個系統中磁盤讀操作的50%以上。這些SQL是最需要進行優化的部分，也是優化工作中優先級很高的部分。通常我們的優化目標是將這些SQL的磁盤讀操作百分比降低到5-19%。 檢查方法： select sum(pct_bufgets)
? from (select rank() over(order by disk_reads desc) as rank_bufgets,
?????????????? to_char(100 * ratio_to_report(disk_reads) over(), '999.99') pct_bufgets
????????? from v$sqlarea)
?where rank_bufgets < 11; 評估準則： 等級 分數 <5% 60 5-19% 50 20-25% 30 >25% 0 7． 調整前25個最浪費磁盤讀操作的語句 在沒有調整的情況下，絕大多數系統中，訪問量占前25位的語句的磁盤讀操作將占用整個系統所有磁盤讀操作的75%，對這部分語句進行調整是至關重要的。這部分腳本用于獲得訪問量占前25位的SQL語句。輸出結果中的Exec表示該SQL被執行的次數。 檢查方法： set serveroutput on size 1000000
declare
? execution number;
? top25???? number;
? text1???? varchar2(4000);
? x???????? number;
? len1????? number;
? cursor c1 is
??? select executions, disk_reads, substr(sql_text, 1, 4000)
????? from v$sqlarea
???? order by disk_reads desc;
begin
? dbms_output.put_line('Exec' || '? ' || 'Reads' || '????? ' || 'Text');
? dbms_output.put_line('-----' || ' ' || '--------' || ' ' ||
?????????????????????? '-------------');
? open c1;
? for i in 1 .. 25 loop
??? fetch c1
????? into execution, top25, text1;
??? dbms_output.put_line(rpad(to_char(execution), 5) || ' ' ||
???????????????????????? rpad(to_char(top25), 8) || ' ' ||
???????????????????????? substr(text1, 1, 66));
??? len1 := length(text1);
??? x??? := 66;
??? while len1 > x - 1 loop
????? dbms_output.put_line('-????????????? ' || substr(text1, x, 66));
????? x := x + 66;
??? end loop;
? end loop;
end;
/ 評估準則： 本部分沒有具體的評估準則，需要開發人員或者DBA去確認在這25個SQL中屬于應用系統的語句是否都已經作過調優。 8． 其它存儲相關的調整 1)????? 字典管理表空間中的Extent總數不超過4096 檢查方法： select a.tablespace_name, sum(a.extents)
? from dba_segments a, dba_tablespaces b
?where a.tablespace_name = b.tablespace_name
?? and b.extent_management = 'DICTIONARY'
?group by a.tablespace_name
?order by sum(a.extents); 檢查輸出結果，如果顯示某個表空間中的extents總數超過了4096，那么需要擴大這個表空間的extent大小，過多的extent對于DMT的空間管理有負面影響。 2)????? 本地管理表空間中單個Segement的Extent數不超過1024 檢查方法： select segment_name, segment_type, extents, bytes, b.tablespace_name
? from dba_segments a, dba_tablespaces b
?where a.tablespace_name = b.tablespace_name
?? and b.extent_management = 'LOCAL'
?? and a.extents > 1024; 檢查輸出結果，返回的記錄都是單個段的區間大于1024的對象，對于這些對象，應該創建一個單獨的具有更大extent大小的表空間，然后將這些對象move到新的表空間中去。 3)????? 檢查字典管理表空間的PCTINCREASE值是否是0 為了表空間中的所有extent大小相同，建議表空間中的所有段都不要設置獨立的storage參數。對于表空間的pctincrease參數，建議設置為0，同時應該設置minextents參數，保證初始分配足夠的空間給新創建的對象。 對于LMT表空間，storage參數中的pctincrease和next參數均無效，建議設置適當的uniform參數管理表空間的extent分配。 4)????? 考慮使用分區來避免磁盤爭用 分區表在管理的方便性和性能的提高上都有較強的實用性，甚至可以認為分區是提高與大型表有關的性能的最佳方法。通過訪問一個表或者索引的較小片段，而不是訪問整個表或索引，分區可以很好地提高效率。如果一個表或者索引的分區位于不同的磁盤上，就更可以大大增加數據吞吐量，獲得很好的數據庫性能。 對于分區的使用，暫時不在本文的敘述范圍內，請參閱其它的分區文檔。 5)????? 對于分區表的非分區鍵索引是否是全局分區索引 由于分區表的數據量通常比較巨大，所以如果在分區表的非分區鍵上創建索引，那么建議創建為全局分區索引，這樣能夠更好地提高性能。注意：如果截斷了一個分區的數據或者刪除了一個分區，那么必須rebuild這個分區表中的全部全局索引，否則這些全局索引將處于invalid狀態，導致使用到這些索引的SQL語句失敗。
轉載于:https://blog.51cto.com/kastal/149180
總結
以上是生活随笔為你收集整理的数据库性能检查指导方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 天后的绯闻男友（天后的绯闻）
- 下一篇： 卫嬿婉（说一说卫嬿婉的简介）