1:服務(wù)器環(huán)境
創(chuàng)新互聯(lián)IDC提供業(yè)務(wù):成都服務(wù)器托管,成都服務(wù)器租用,成都服務(wù)器托管,重慶服務(wù)器租用等四川省內(nèi)主機托管與主機租用業(yè)務(wù);數(shù)據(jù)中心含:雙線機房,BGP機房,電信機房,移動機房,聯(lián)通機房。
操作系統(tǒng):Red Hat Enterprise Linux Server release 5.5 (Tikanga)
CPU:Intel(R) Xeon(R) CPU ? ? ? ? ? E5607 ?@ 2.27GHz ? 8核
內(nèi)存:16G
Mysql:Ver 14.14 Distrib 5.5.21, for Linux (x86_64)
Oracle:Oracle?Database 11g Enterprise Edition Release
詳細(xì)數(shù)據(jù)測試(操作通過存儲過程完成)
數(shù)據(jù)插入
50并發(fā)Mysql插入性能圖示(橫坐標(biāo):當(dāng)前數(shù)據(jù)總量,縱坐標(biāo):每秒執(zhí)行次數(shù)){平均值:4841.98}
50并發(fā)Oracle插入性能圖示(橫坐標(biāo):執(zhí)行時間(秒),縱坐標(biāo):每秒執(zhí)行次數(shù)){平均值:1459.408}
1、調(diào)整數(shù)據(jù)結(jié)構(gòu)的設(shè)計
這一部分在開發(fā)信息系統(tǒng)之前完成,程序員需要考慮是否使用ORACLE數(shù)據(jù)庫的分區(qū)功能,對于經(jīng)常訪問的數(shù)據(jù)庫表是否需要建立索引等。
2、調(diào)整應(yīng)用程序結(jié)構(gòu)設(shè)計
這一部分也是在開發(fā)信息系統(tǒng)之前完成,程序員在這一步需要考慮應(yīng)用程序使用什么樣的體系結(jié)構(gòu),是使用傳統(tǒng)的Client/Server兩層體系結(jié)構(gòu),還是使用Browser/Web/Database的三層體系結(jié)構(gòu)。不同的應(yīng)用程序體系結(jié)構(gòu)要求的數(shù)據(jù)庫資源是不同的。
3、調(diào)整數(shù)據(jù)庫SQL語句
應(yīng)用程序的執(zhí)行最終將歸結(jié)為數(shù)據(jù)庫中的SQL語句執(zhí)行,因此SQL語句的執(zhí)行效率最終決定了ORACLE數(shù)據(jù)庫的性能。ORACLE公司推薦使用ORACLE語句優(yōu)化器(OracleOptimizer)和行鎖管理器(row-levelmanager)來調(diào)整優(yōu)化SQL語句。
4、調(diào)整服務(wù)器內(nèi)存分配
內(nèi)存分配是在信息系統(tǒng)運行過程中優(yōu)化配置的,數(shù)據(jù)庫管理員可以根據(jù)數(shù)據(jù)庫運行狀況調(diào)整數(shù)據(jù)庫系統(tǒng)全局區(qū)(SGA區(qū))的數(shù)據(jù)緩沖區(qū)、日志緩沖區(qū)和共享池的大小;還可以調(diào)整程序全局區(qū)(PGA區(qū))的大小。需要注意的是,SGA區(qū)不是越大越好,SGA區(qū)過大會占用操作系統(tǒng)使用的內(nèi)存而引起虛擬內(nèi)存的頁面交換,這樣反而會降低系統(tǒng)。
5、調(diào)整硬盤I/O
這一步是在信息系統(tǒng)開發(fā)之前完成的。數(shù)據(jù)庫管理員可以將組成同一個表空間的數(shù)據(jù)文件放在不同的硬盤上,做到硬盤之間I/O負(fù)載均衡。
6、調(diào)整操作系統(tǒng)參數(shù)
例如:運行在UNIX操作系統(tǒng)上的ORACLE數(shù)據(jù)庫,可以調(diào)整UNIX數(shù)據(jù)緩沖池的大小,每個進(jìn)程所能使用的內(nèi)存大小等參數(shù)。
實際上,上述數(shù)據(jù)庫優(yōu)化措施之間是相互聯(lián)系的。ORACLE數(shù)據(jù)庫性能惡化表現(xiàn)基本上都是用戶響應(yīng)時間比較長,需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的,有時是多個因素共同造成了性能惡化的結(jié)果,這就需要數(shù)據(jù)庫管理員有比較全面的計算機知識,能夠敏感地察覺到影響數(shù)據(jù)庫性能的主要原因所在。另外,良好的數(shù)據(jù)庫管理工具對于優(yōu)化數(shù)據(jù)庫性能也是很重要的。
一、ORACLE數(shù)據(jù)庫性能優(yōu)化工具
常用的數(shù)據(jù)庫性能優(yōu)化工具有:
ORACLE數(shù)據(jù)庫在線數(shù)據(jù)字典,ORACLE在線數(shù)據(jù)字典能夠反映出ORACLE動態(tài)運行情況,對于調(diào)整數(shù)據(jù)庫性能是很有幫助的。
操作系統(tǒng)工具,例如UNIX操作系統(tǒng)的vmstat,iostat等命令可以查看到系統(tǒng)系統(tǒng)級內(nèi)存和硬盤I/O的使用情況,這些工具對于管理員弄清出系統(tǒng)瓶頸出現(xiàn)在什么地方有時候很有用。
SQL語言跟蹤工具(SQLTRACEFACILITY),SQL語言跟蹤工具可以記錄SQL語句的執(zhí)行情況,管理員可以使用虛擬表來調(diào)整實例,使用SQL語句跟蹤文件調(diào)整應(yīng)用程序性能。SQL語言跟蹤工具將結(jié)果輸出成一個操作系統(tǒng)的文件,管理員可以使用TKPROF工具查看這些文件。
ORACLEEnterpriseManager(OEM),這是一個圖形的用戶管理界面,用戶可以使用它方便地進(jìn)行數(shù)據(jù)庫管理而不必記住復(fù)雜的ORACLE數(shù)據(jù)庫管理的命令。
EXPLAINPLAN——SQL語言優(yōu)化命令,使用這個命令可以幫助程序員寫出高效的SQL語言。
二、ORACLE數(shù)據(jù)庫的系統(tǒng)性能評估
信息系統(tǒng)的類型不同,需要關(guān)注的數(shù)據(jù)庫參數(shù)也是不同的。數(shù)據(jù)庫管理員需要根據(jù)自己的信息系統(tǒng)的類型著重考慮不同的數(shù)據(jù)庫參數(shù)。
1、在線事務(wù)處理信息系統(tǒng)(OLTP),這種類型的信息系統(tǒng)一般需要有大量的Insert、Update操作,典型的系統(tǒng)包括民航機票發(fā)售系統(tǒng)、銀行儲蓄系統(tǒng)等。OLTP系統(tǒng)需要保證數(shù)據(jù)庫的并發(fā)性、可靠性和最終用戶的速度,這類系統(tǒng)使用的ORACLE數(shù)據(jù)庫需要主要考慮下述參數(shù):
數(shù)據(jù)庫回滾段是否足夠?
是否需要建立ORACLE數(shù)據(jù)庫索引、聚集、散列?
系統(tǒng)全局區(qū)(SGA)大小是否足夠?
SQL語句是否高效?
2、數(shù)據(jù)倉庫系統(tǒng)(DataWarehousing),這種信息系統(tǒng)的主要任務(wù)是從ORACLE的海量數(shù)據(jù)中進(jìn)行查詢,得到數(shù)據(jù)之間的某些規(guī)律。數(shù)據(jù)庫管理員需要為這種類型的ORACLE數(shù)據(jù)庫著重考慮下述參數(shù):
是否采用B*-索引或者bitmap索引?
是否采用并行SQL查詢以提高查詢效率?
是否采用PL/SQL函數(shù)編寫存儲過程?
有必要的話,需要建立并行數(shù)據(jù)庫提高數(shù)據(jù)庫的查詢效率
三、SQL語句的調(diào)整原則
SQL語言是一種靈活的語言,相同的功能可以使用不同的語句來實現(xiàn),但是語句的執(zhí)行效率是很不相同的。程序員可以使用EXPLAINPLAN語句來比較各種實現(xiàn)方案,并選出最優(yōu)的實現(xiàn)方案??偟脕碇v,程序員寫SQL語句需要滿足考慮如下規(guī)則:
1、盡量使用索引。試比較下面兩條SQL語句:
語句A:SELECTdname,deptnoFROMdeptWHEREdeptnoNOTIN
(SELECTdeptnoFROMemp);
語句B:SELECTdname,deptnoFROMdeptWHERENOTEXISTS
(SELECTdeptnoFROMempWHEREdept.deptno=emp.deptno);
這兩條查詢語句實現(xiàn)的結(jié)果是相同的,但是執(zhí)行語句A的時候,ORACLE會對整個emp表進(jìn)行掃描,沒有使用建立在emp表上的deptno索引,執(zhí)行語句B的時候,由于在子查詢中使用了聯(lián)合查詢,ORACLE只是對emp表進(jìn)行的部分?jǐn)?shù)據(jù)掃描,并利用了deptno列的索引,所以語句B的效率要比語句A的效率高一些。
2、選擇聯(lián)合查詢的聯(lián)合次序??紤]下面的例子:
SELECTstuffFROMtabaa,tabbb,tabcc
WHEREa.acolbetween:alowand:ahigh
ANDb.bcolbetween:blowand:bhigh
ANDc.ccolbetween:clowand:chigh
ANDa.key1=b.key1
AMDa.key2=c.key2;
這個SQL例子中,程序員首先需要選擇要查詢的主表,因為主表要進(jìn)行整個表數(shù)據(jù)的掃描,所以主表應(yīng)該數(shù)據(jù)量最小,所以例子中表A的acol列的范圍應(yīng)該比表B和表C相應(yīng)列的范圍小。
3、在子查詢中慎重使用IN或者NOTIN語句,使用where(NOT)exists的效果要好的多。
4、慎重使用視圖的聯(lián)合查詢,尤其是比較復(fù)雜的視圖之間的聯(lián)合查詢。一般對視圖的查詢最好都分解為對數(shù)據(jù)表的直接查詢效果要好一些。
5、可以在參數(shù)文件中設(shè)置SHARED_POOL_RESERVED_SIZE參數(shù),這個參數(shù)在SGA共享池中保留一個連續(xù)的內(nèi)存空間,連續(xù)的內(nèi)存空間有益于存放大的SQL程序包。
6、ORACLE公司提供的DBMS_SHARED_POOL程序可以幫助程序員將某些經(jīng)常使用的存儲過程“釘”在SQL區(qū)中而不被換出內(nèi)存,程序員對于經(jīng)常使用并且占用內(nèi)存很多的存儲過程“釘”到內(nèi)存中有利于提高最終用戶的響應(yīng)時間。
四、CPU參數(shù)的調(diào)整
CPU是服務(wù)器的一項重要資源,服務(wù)器良好的工作狀態(tài)是在工作高峰時CPU的使用率在90%以上。如果空閑時間CPU使用率就在90%以上,說明服務(wù)器缺乏CPU資源,如果工作高峰時CPU使用率仍然很低,說明服務(wù)器CPU資源還比較富余。
使用操作相同命令可以看到CPU的使用情況,一般UNIX操作系統(tǒng)的服務(wù)器,可以使用sar_u命令查看CPU的使用率,NT操作系統(tǒng)的服務(wù)器,可以使用NT的性能管理器來查看CPU的使用率。
數(shù)據(jù)庫管理員可以通過查看v$sysstat數(shù)據(jù)字典中“CPUusedbythissession”統(tǒng)計項得知ORACLE數(shù)據(jù)庫使用的CPU時間,查看“OSUserlevelCPUtime”統(tǒng)計項得知操作系統(tǒng)用戶態(tài)下的CPU時間,查看“OSSystemcallCPUtime”統(tǒng)計項得知操作系統(tǒng)系統(tǒng)態(tài)下的CPU時間,操作系統(tǒng)總的CPU時間就是用戶態(tài)和系統(tǒng)態(tài)時間之和,如果ORACLE數(shù)據(jù)庫使用的CPU時間占操作系統(tǒng)總的CPU時間90%以上,說明服務(wù)器CPU基本上被ORACLE數(shù)據(jù)庫使用著,這是合理,反之,說明服務(wù)器CPU被其它程序占用過多,ORACLE數(shù)據(jù)庫無法得到更多的CPU時間。
數(shù)據(jù)庫管理員還可以通過查看v$sesstat數(shù)據(jù)字典來獲得當(dāng)前連接ORACLE數(shù)據(jù)庫各個會話占用的CPU時間,從而得知什么會話耗用服務(wù)器CPU比較多。
出現(xiàn)CPU資源不足的情況是很多的:SQL語句的重解析、低效率的SQL語句、鎖沖突都會引起CPU資源不足。
1、數(shù)據(jù)庫管理員可以執(zhí)行下述語句來查看SQL語句的解析情況:
SELECT*FROMV$SYSSTATWHERENAMEIN
('parsetimecpu','parsetimeelapsed','parsecount(hard)');
這里parsetimecpu是系統(tǒng)服務(wù)時間,parsetimeelapsed是響應(yīng)時間,用戶等待時間,waitetime=parsetimeelapsed_parsetimecpu
由此可以得到用戶SQL語句平均解析等待時間=waitetime/parsecount。這個平均等待時間應(yīng)該接近于0,如果平均解析等待時間過長,數(shù)據(jù)庫管理員可以通過下述語句
SELECTSQL_TEXT,PARSE_CALLS,EXECUTIONSFROMV$SQLAREA
ORDERBYPARSE_CALLS;
來發(fā)現(xiàn)是什么SQL語句解析效率比較低。程序員可以優(yōu)化這些語句,或者增加ORACLE參數(shù)SESSION_CACHED_CURSORS的值。
2、數(shù)據(jù)庫管理員還可以通過下述語句:
SELECTBUFFER_GETS,EXECUTIONS,SQL_TEXTFROMV$SQLAREA;
查看低效率的SQL語句,優(yōu)化這些語句也有助于提高CPU的利用率。
3、數(shù)據(jù)庫管理員可以通過v$system_event數(shù)據(jù)字典中的“l(fā)atchfree”統(tǒng)計項查看ORACLE數(shù)據(jù)庫的沖突情況,如果沒有沖突的話,latchfree查詢出來沒有結(jié)果。如果沖突太大的話,數(shù)據(jù)庫管理員可以降低spin_count參數(shù)值,來消除高的CPU使用率。
五、內(nèi)存參數(shù)的調(diào)整
內(nèi)存參數(shù)的調(diào)整主要是指ORACLE數(shù)據(jù)庫的系統(tǒng)全局區(qū)(SGA)的調(diào)整。SGA主要由三部分構(gòu)成:共享池、數(shù)據(jù)緩沖區(qū)、日志緩沖區(qū)。
1、共享池由兩部分構(gòu)成:共享SQL區(qū)和數(shù)據(jù)字典緩沖區(qū),共享SQL區(qū)是存放用戶SQL命令的區(qū)域,數(shù)據(jù)字典緩沖區(qū)存放數(shù)據(jù)庫運行的動態(tài)信息。數(shù)據(jù)庫管理員通過執(zhí)行下述語句:
select(sum(pins-reloads))/sum(pins)"LibCache"fromv$librarycache;
來查看共享SQL區(qū)的使用率。這個使用率應(yīng)該在90%以上,否則需要增加共享池的大小。數(shù)據(jù)庫管理員還可以執(zhí)行下述語句:
select(sum(gets-getmisses-usage-fixed))/sum(gets)"RowCache"fromv$rowcache;
查看數(shù)據(jù)字典緩沖區(qū)的使用率,這個使用率也應(yīng)該在90%以上,否則需要增加共享池的大小。
2、數(shù)據(jù)緩沖區(qū)。數(shù)據(jù)庫管理員可以通過下述語句:
SELECTname,valueFROMv$sysstatWHEREnameIN('dbblockgets','consistentgets','physicalreads');
來查看數(shù)據(jù)庫數(shù)據(jù)緩沖區(qū)的使用情況。查詢出來的結(jié)果可以計算出來數(shù)據(jù)緩沖區(qū)的使用命中率=1-(physicalreads/(dbblockgets+consistentgets))。
這個命中率應(yīng)該在90%以上,否則需要增加數(shù)據(jù)緩沖區(qū)的大小。
3、日志緩沖區(qū)。數(shù)據(jù)庫管理員可以通過執(zhí)行下述語句:
selectname,valuefromv$sysstatwherenamein('redoentries','redologspacerequests');
查看日志緩沖區(qū)的使用情況。查詢出的結(jié)果可以計算出日志緩沖區(qū)的申請失敗率:
申請失敗率=requests/entries,申請失敗率應(yīng)該接近于0,否則說明日志緩沖區(qū)開設(shè)太小,需要增加ORACLE數(shù)據(jù)庫的日志緩沖區(qū)。
昆明北大青鳥java培訓(xùn)班轉(zhuǎn)載自網(wǎng)絡(luò)如有侵權(quán)請聯(lián)系我們感謝您的關(guān)注謝謝支持
簡單點判斷的話,你top或topas觀察下,cpu和磁盤讀的負(fù)載情況。
然后生成一份業(yè)務(wù)高峰時段的AWR報告,看看top 5等待事件主要是哪些,是不是跟磁盤讀相關(guān)的等待事件(比如全表掃描)
降低IO最有效的方法就是優(yōu)化sql語句,避免大表全表掃描,根據(jù)awr報告中sga各個內(nèi)存組件的使用情況,適當(dāng)調(diào)整buffer cache的值,來減少磁盤IO
oracle AWR報告是你手工生產(chǎn)的,oracle不會存儲你的awr報告。
AWR報告由你手工執(zhí)行awrrpt.sql腳本,然后選取你所需要看的時間點(一般是快照),AWR的報告生產(chǎn)跟oralce快照有關(guān)。 oracle快照一般是一個小時做一次,默認(rèn)保留7天。
1.?推薦一個使用平均值估算表空間的腳本:
--不適用windows
with t1 as (
select ss.run_time,ts.name,
decode((round(su.tablespace_usedsize*dt.block_size/1024/1024,2)),null,0,(round(su.tablespace_usedsize*dt.block_size/1024/1024,2))) used_size_mb
from
dba_hist_tbspc_space_usage su,
(select trunc(BEGIN_INTERVAL_TIME) run_time,max(snap_id) snap_id from dba_hist_snapshot
group by trunc(BEGIN_INTERVAL_TIME) ) ss,
v$tablespace ts,
dba_tablespaces dt
where su.snap_id = ss.snap_id
and su.tablespace_id = ts.ts#
and ts.name NOT LIKE '%TEMP%'
and ts.name NOT LIKE '%UNDO%'
and ts.name = dt.tablespace_name order by 2,1),
t2 as (
select e.run_time,e.name,e.used_size_mb,e.used_size_mb - b.used_size_mb growth
from t1 e, t1 b
where e.name = b.name and e.run_time = b.run_time +1),
t5 as (select a.TABLESPACE_NAME,
? ? ? ? a.FILE_NAME,
? ? ? ? a.FILE_ID,
? ? ? ? a.BYTES,
? ? ? ? a.AUTOEXTENSIBLE,
? ? ? ? a.ONLINE_STATUS,
? ? ? ? a.MAXBYTES,
? ? ? ? case
? ? ? ? ? when a.AUTOEXTENSIBLE = 'YES' and
? ? ? ? ? ? ? ? a.ONLINE_STATUS not in ('OFFLINE', 'SYSOFF') then
? ? ? ? ? ? nvl(a.MAXBYTES, 0)
? ? ? ? ? else
? ? ? ? ? ? nvl(a.BYTES, 0)
? ? ? ? end file_max_size
? ? from dba_data_files a
? ? where a.tablespace_name NOT LIKE '%TEMP%'
? ? and a.tablespace_name NOT LIKE '%UNDO%'
? ? ),
t3 as (
select tsz.tablespace_name,
tsz.alloc_size_mb,ave.avg_growth_per_day_mb,ave.avg_growth_per_day_mb*90 projected_growth_for_3mths_mb
from
(select tablespace_name, round(sum(file_max_size)/1024/1024,2) alloc_size_mb? from t5 group by tablespace_name) tsz,
(select name,decode(round(avg(growth),2),null,0.11,0,0.11, round(avg(growth),2)) avg_growth_per_day_mb from t2 group by name) ave
where tsz.tablespace_name = ave.name),
t6 as (select
d.tablespace_name tablespace_name,
round((d.sumbytes/1024/1024),2) total_g ,
round(decode(f.sumbytes,null,0,f.sumbytes)/1024/1024,2) free,
round(((d.sumbytes-f.sumbytes)/1024/1024),6) size_could_be_used,
round((d.sumbytes-decode(f.sumbytes,null,0,f.sumbytes))*100/d.sumbytes,2) used_pct,
(100-round((d.sumbytes-decode(f.sumbytes,null,0,f.sumbytes))*100/d.sumbytes,2))*round((d.sumbytes/1024/1024),2) real_free
from
(select
? tablespace_name,? sum(bytes) sumbytes
from dba_free_space? group by tablespace_name) f,
(select tablespace_name,? ? ? sum(bytes) sumbytes? ?
? from dba_data_files? ? group by tablespace_name) d
where f.tablespace_name(+) = d.tablespace_name)
select t4.tablespace_name,decode(t3.alloc_size_mb,null,0,t3.alloc_size_mb) alloc_sz_mb,
--t6.real_free/round(decode(avg_growth_per_day_mb,null,365,0,365,(t3.avg_growth_per_day_mb)),2) Days_To_Be_Used,
((100-decode(round(t6.size_could_be_used*100/t3.alloc_size_mb,2),null,0,round(t6.size_could_be_used*100/t3.alloc_size_mb,2)))/100*t3.alloc_size_mb)/avg_growth_per_day_mb? Days_To_Be_Used,
round(t6.size_could_be_used*100/t3.alloc_size_mb,4) used_pct_auto,
t6.used_pct used_pct_real
from t3,t6,
(select a.tablespace_name,
round(a.bytes/1024/1024/1024,2) alloc,
round(c.bytes/1024/1024/1024,2) free
from sys.sm$ts_avail a,
sys.sm$ts_free c
where a.tablespace_name = c.tablespace_name(+)
and a.tablespace_name NOT LIKE '%TEMP%'
and a.tablespace_name NOT LIKE '%UNDO%'
) t4
where t4.tablespace_name = t3.tablespace_name(+)
and t4.tablespace_name = t6.tablespace_name(+)
--and ((100-decode(round(t6.size_could_be_used*100/t3.alloc_size_mb,2),null,0,round(t6.size_could_be_used*100/t3.alloc_size_mb,2)))/100*t3.alloc_size_mb)/avg_growth_per_day_mb =30
and ((100-decode(round(t6.size_could_be_used*100/t3.alloc_size_mb,2),null,0,round(t6.size_could_be_used*100/t3.alloc_size_mb,2)))/100*t3.alloc_size_mb)/avg_growth_per_day_mb=0
order by 1;
2.?通過線性回歸參數(shù)預(yù)測未來使用量(待補充):