你最好買一本專門講ORACLE性能優(yōu)化的書,好好看看\x0d\x0a1、調(diào)整數(shù)據(jù)庫服務(wù)器的性能\x0d\x0aOracle數(shù)據(jù)庫服務(wù)器是整個(gè)系統(tǒng)的核心,它的性能高低直接影響整個(gè)系統(tǒng)的性能,為了調(diào)整Oracle數(shù)據(jù)庫服務(wù)器的性能,主要從以下幾個(gè)方面考慮: \x0d\x0a1.1、調(diào)整操作系統(tǒng)以適合Oracle數(shù)據(jù)庫服務(wù)器運(yùn)行\(zhòng)x0d\x0aOracle數(shù)據(jù)庫服務(wù)器很大程度上依賴于運(yùn)行服務(wù)器的操作系統(tǒng),如果操作系統(tǒng)不能提供最好性能,那么無論如何調(diào)整,Oracle數(shù)據(jù)庫服務(wù)器也無法發(fā)揮其應(yīng)有的性能。 \x0d\x0a1.1.1、為Oracle數(shù)據(jù)庫服務(wù)器規(guī)劃系統(tǒng)資源 \x0d\x0a據(jù)已有計(jì)算機(jī)可用資源, 規(guī)劃分配給Oracle服務(wù)器資源原則是:盡可能使Oracle服務(wù)器使用資源最大化,特別在Client/Server中盡量讓服務(wù)器上所有資源都來運(yùn)行Oracle服務(wù)。 \x0d\x0a1.1.2、調(diào)整計(jì)算機(jī)系統(tǒng)中的內(nèi)存配置 \x0d\x0a多數(shù)操作系統(tǒng)都用虛存來模擬計(jì)算機(jī)上更大的內(nèi)存,它實(shí)際上是硬盤上的一定的磁盤空間。當(dāng)實(shí)際的內(nèi)存空間不能滿足應(yīng)用軟件的要求時(shí),操作系統(tǒng)就將用這部分的磁盤空間對內(nèi)存中的信息進(jìn)行頁面替換,這將引起大量的磁盤I/O操作,使整個(gè)服務(wù)器的性能下降。為了避免過多地使用虛存,應(yīng)加大計(jì)算機(jī)的內(nèi)存。 \x0d\x0a1.1.3、為Oracle數(shù)據(jù)庫服務(wù)器設(shè)置操作系統(tǒng)進(jìn)程優(yōu)先級(jí) \x0d\x0a不要在操作系統(tǒng)中調(diào)整Oracle進(jìn)程的優(yōu)先級(jí),因?yàn)樵贠racle數(shù)據(jù)庫系統(tǒng)中,所有的后臺(tái)和前臺(tái)數(shù)據(jù)庫服務(wù)器進(jìn)程執(zhí)行的是同等重要的工作,需要同等的優(yōu)先級(jí)。所以在安裝時(shí),讓所有的數(shù)據(jù)庫服務(wù)器進(jìn)程都使用缺省的優(yōu)先級(jí)運(yùn)行。 \x0d\x0a1.2、調(diào)整內(nèi)存分配\x0d\x0aOracle數(shù)據(jù)庫服務(wù)器保留3個(gè)基本的內(nèi)存高速緩存,分別對應(yīng)3種不同類型的數(shù)據(jù):庫高速緩存,字典高速緩存和緩沖區(qū)高速緩存。庫高速緩存和字典高速緩存一起構(gòu)成共享池,共享池再加上緩沖區(qū)高速緩存便構(gòu)成了系統(tǒng)全程區(qū)(SGA)。SGA是對數(shù)據(jù)庫數(shù)據(jù)進(jìn)行快速訪問的一個(gè)系統(tǒng)全程區(qū),若SGA本身需要頻繁地進(jìn)行釋放、分配,則不能達(dá)到快速訪問數(shù)據(jù)的目的,因此應(yīng)把SGA放在主存中,不要放在虛擬內(nèi)存中。內(nèi)存的調(diào)整主要是指調(diào)整組成SGA的內(nèi)存結(jié)構(gòu)的大小來提高系統(tǒng)性能,由于Oracle數(shù)據(jù)庫服務(wù)器的內(nèi)存結(jié)構(gòu)需求與應(yīng)用密切相關(guān),所以內(nèi)存結(jié)構(gòu)的調(diào)整應(yīng)在磁盤I/O調(diào)整之前進(jìn)行。 \x0d\x0a1.2.1、庫緩沖區(qū)的調(diào)整 \x0d\x0a庫緩沖區(qū)中包含私用和共享SQL和PL/SQL區(qū),通過比較庫緩沖區(qū)的命中率決定它的大小。要調(diào)整庫緩沖區(qū),必須首先了解該庫緩沖區(qū)的活動(dòng)情況,庫緩沖區(qū)的活動(dòng)統(tǒng)計(jì)信息保留在動(dòng)態(tài)性能表v$librarycache數(shù)據(jù)字典中,可通過查詢該表來了解其活動(dòng)情況,以決定如何調(diào)整。 \x0d\x0a \x0d\x0aSelect sum(pins),sum(reloads) from v$librarycache; \x0d\x0a \x0d\x0aPins列給出SQL語句,PL/SQL塊及被訪問對象定義的總次數(shù);Reloads列給出SQL 和PL/SQL塊的隱式分析或?qū)ο蠖x重裝載時(shí)在庫程序緩沖區(qū)中發(fā)生的錯(cuò)誤。如果sum(pins)/sum(reloads) ≈0,則庫緩沖區(qū)的命中率合適;若sum(pins)/sum(reloads)1, 則需調(diào)整初始化參數(shù) shared_pool_size來重新調(diào)整分配給共享池的內(nèi)存量。 \x0d\x0a1.2.2、數(shù)據(jù)字典緩沖區(qū)的調(diào)整 \x0d\x0a數(shù)據(jù)字典緩沖區(qū)包含了有關(guān)數(shù)據(jù)庫的結(jié)構(gòu)、用戶、實(shí)體信息。數(shù)據(jù)字典的命中率,對系統(tǒng)性能影響極大。數(shù)據(jù)字典緩沖區(qū)的使用情況記錄在動(dòng)態(tài)性能表v$librarycache中,可通過查詢該表來了解其活動(dòng)情況,以決定如何調(diào)整。 \x0d\x0a \x0d\x0aSelect sum(gets),sum(getmisses) from v$rowcache; \x0d\x0a \x0d\x0aGets列是對相應(yīng)項(xiàng)請求次數(shù)的統(tǒng)計(jì);Getmisses 列是引起緩沖區(qū)出錯(cuò)的數(shù)據(jù)的請求次數(shù)。對于頻繁訪問的數(shù)據(jù)字典緩沖區(qū),sum(getmisses)/sum(gets)10%~15%。若大于此百分?jǐn)?shù),則應(yīng)考慮增加數(shù)據(jù)字典緩沖區(qū)的容量,即需調(diào)整初始化參數(shù)shared_pool_size來重新調(diào)整分配給共享池的內(nèi)存量。 \x0d\x0a1.2.3、緩沖區(qū)高速緩存的調(diào)整 \x0d\x0a用戶進(jìn)程所存取的所有數(shù)據(jù)都是經(jīng)過緩沖區(qū)高速緩存來存取,所以該部分的命中率,對性能至關(guān)重要。緩沖區(qū)高速緩存的使用情況記錄在動(dòng)態(tài)性能表v$sysstat中,可通過查詢該表來了解其活動(dòng)情況,以決定如何調(diào)整。 \x0d\x0a \x0d\x0aSelect name,value from v$sysstat where name in ('dbblock gets','consistent gets','physical reads'); \x0d\x0a \x0d\x0adbblock gets和consistent gets的值是請求數(shù)據(jù)緩沖區(qū)中讀的總次數(shù)。physical reads的值是請求數(shù)據(jù)時(shí)引起從盤中讀文件的次數(shù)。從緩沖區(qū)高速緩存中讀的可能性的高低稱為緩沖區(qū)的命中率,計(jì)算公式: \x0d\x0a \x0d\x0aHit Ratio=1-(physical reds/(dbblock gets+consistent gets)) \x0d\x0a \x0d\x0a如果Hit Ratio60%~70%,則應(yīng)增大db_block_buffers的參數(shù)值。db_block_buffers可以調(diào)整分配給緩沖區(qū)高速緩存的內(nèi)存量,即db_block_buffers可設(shè)置分配緩沖區(qū)高速緩存的數(shù)據(jù)塊的個(gè)數(shù)。緩沖區(qū)高速緩存的總字節(jié)數(shù)=db_block_buffers的值*db_block_size的值。db_block_size 的值表示數(shù)據(jù)塊大小的字節(jié)數(shù),可查詢 v$parameter 表: \x0d\x0a \x0d\x0aselect name,value from v$parameter where name='db_block_size'; \x0d\x0a \x0d\x0a在修改了上述數(shù)據(jù)庫的初始化參數(shù)以后,必須先關(guān)閉數(shù)據(jù)庫,在重新啟動(dòng)數(shù)據(jù)庫后才能使新的設(shè)置起作用。
成都創(chuàng)新互聯(lián)公司主營永春網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,重慶APP開發(fā),永春h5小程序開發(fā)搭建,永春網(wǎng)站營銷推廣歡迎永春等地區(qū)企業(yè)咨詢
1、可以縮小到5張表,因?yàn)楹芏喽际菑囊粡埍砝锶〕鰜淼臄?shù)據(jù);
2、不能子查詢因?yàn)槭且@示數(shù)據(jù)子查詢只是查詢條件;
3不能建立索引,因?yàn)檫@樣會(huì)影響表的增刪改,它里面都是導(dǎo)入進(jìn)去的一次增加上千條都有可能;
4、定期結(jié)轉(zhuǎn)是什么意思,表示沒看懂。時(shí)間發(fā)的太長的話就算了;
5、定期結(jié)轉(zhuǎn)的意思就是,將你要建立視圖的幾種表數(shù)據(jù)“轉(zhuǎn)移”到一張新表里面去,不用視圖查詢。數(shù)據(jù)庫全文檢索是RDBMS自帶的擴(kuò)展功能,可以實(shí)現(xiàn)高速查詢。全文檢索建議搜索下關(guān)鍵字,什么lucene之類的就出來了。
1、是這樣的。
2、這個(gè)說不好,我沒這么做過。你手邊應(yīng)該有oralce的全套電子文檔吧。關(guān)鍵是你要找對系統(tǒng)表或者視圖。我記得索引的系統(tǒng)視圖不是這個(gè)。
3、這些與你要做的有關(guān)系嗎?別像沒頭蒼蠅一樣瞎撞了。
4、不用刪表,如果你連基本的語句命令都不懂,那只能看書了。
5、慢的原因有好多,逐步排除吧,等找到真正原因再說。急沒用的。
6、默認(rèn)情況下,是會(huì)建到用戶的默認(rèn)表空間的。
7、這個(gè)看你的維護(hù)需要。最起碼先弄明白你的庫是怎么回事再說吧。就從這些問題看,你根本就是門外漢,連庫是怎么回事都沒弄明白。
幾個(gè)簡單的步驟大幅提高Oracle性能--我優(yōu)化數(shù)據(jù)庫的三板斧。
數(shù)據(jù)庫優(yōu)化的討論可以說是一個(gè)永恒的主題。資深的Oracle優(yōu)化人員通常會(huì)要求提出性能問題的人對數(shù)據(jù)庫做一個(gè)statspack,貼出數(shù)據(jù)庫配置等等。還有的人認(rèn)為要抓出執(zhí)行最慢的語句來進(jìn)行優(yōu)化。但實(shí)際情況是,提出疑問的人很可能根本不懂執(zhí)行計(jì)劃,更不要說statspack了。而我認(rèn)為,數(shù)據(jù)庫優(yōu)化,應(yīng)該首先從大的方面考慮:網(wǎng)絡(luò)、服務(wù)器硬件配置、操作系統(tǒng)配置、Oracle服務(wù)器配置、數(shù)據(jù)結(jié)構(gòu)組織、然后才是具體的調(diào)整。實(shí)際上網(wǎng)絡(luò)、硬件等往往無法決定更換,應(yīng)用程序一般也無法修改,因此應(yīng)該著重從數(shù)據(jù)庫配置、數(shù)據(jù)結(jié)構(gòu)上來下手,首先讓數(shù)據(jù)庫有一個(gè)良好的配置,然后再考慮具體優(yōu)化某些過慢的語句。我在給我的用戶系統(tǒng)進(jìn)行優(yōu)化的過程中,總結(jié)了一些基本的,簡單易行的辦法來優(yōu)化數(shù)據(jù)庫,算是我的三板斧,呵呵。不過請注意,這些不一定普遍使用,甚至有的會(huì)有副作用,但是對OLTP系統(tǒng)、基于成本的數(shù)據(jù)庫往往行之有效,不妨試試。(注:附件是Burleson寫的用來報(bào)告數(shù)據(jù)庫性能等信息的腳本,本文用到)
一.設(shè)置合適的SGA
常常有人抱怨服務(wù)器硬件很好,但是Oracle就是很慢。很可能是內(nèi)存分配不合理造成的。(1)假設(shè)內(nèi)存有512M,這通常是小型應(yīng)用。建議Oracle的SGA大約240M,其中:共享池(SHARED_POOL_SIZE)可以設(shè)置60M到80M,根據(jù)實(shí)際的用戶數(shù)、查詢等來定。數(shù)據(jù)塊緩沖區(qū)可以大致分配120M-150M,8i下需要設(shè)置DB_BLOCK_BUFFERS,DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于數(shù)據(jù)塊緩沖區(qū)大小。9i 下的數(shù)據(jù)緩沖區(qū)可以用db_cache_size來直接分配。
(2)假設(shè)內(nèi)存有1G,Oracle 的SGA可以考慮分配500M:共享池分配100M到150M,數(shù)據(jù)緩沖區(qū)分配300M到400M。
(3)內(nèi)存2G,SGA可以考慮分配1.2G,共享池300M到500M,剩下的給數(shù)據(jù)塊緩沖區(qū)。
(4)內(nèi)存2G以上:共享池300M到500M就足夠啦,再多也沒有太大幫助;(Biti_rainy有專述)數(shù)據(jù)緩沖區(qū)是盡可能的大,但是一定要注意兩個(gè)問題:一是要給操作系統(tǒng)和其他應(yīng)用留夠內(nèi)存,二是對于32位的操作系統(tǒng),Oracle的SGA有1.75G的限制。有的32位操作系統(tǒng)上可以突破這個(gè)限制,方法還請看Biti的大作吧。
二.分析表和索引,更改優(yōu)化模式
Oracle默認(rèn)優(yōu)化模式是CHOOSE,在這種情況下,如果表沒有經(jīng)過分析,經(jīng)常導(dǎo)致查詢使用全表掃描,而不使用索引。這通常導(dǎo)致磁盤I/O太多,而導(dǎo)致查詢很慢。如果沒有使用執(zhí)行計(jì)劃穩(wěn)定性,則應(yīng)該把表和索引都分析一下,這樣可能直接會(huì)使查詢速度大幅提升。分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令。對于少于100萬的表,可以考慮分析整個(gè)表,對于很大的表,可以按百分比來分析,但是百分比不能過低,否則生成的統(tǒng)計(jì)信息可能不準(zhǔn)確??梢酝ㄟ^DBA_TABLES的LAST_ANALYZED列來查看表是否經(jīng)過分析或分析時(shí)間,索引可以通過DBA_INDEXES的LAST_ANALYZED列。
下面通過例子來說明分析前后的速度對比。(表CASE_GA_AJZLZ大約有35萬數(shù)據(jù),有主鍵)首先在SQLPLUS中打開自動(dòng)查詢執(zhí)行計(jì)劃功能。(第一次要執(zhí)行\(zhòng)RDBMS\ADMIN\utlxplan.sql來創(chuàng)建PLAN_TABLE這個(gè)表)
SQL SET AUTOTRACE ON
SQLSET TIMING ON
通過SET AUTOTRACE ON 來查看語句的執(zhí)行計(jì)劃,通過SET TIMING ON 來查看語句運(yùn)行時(shí)間。
SQL seleCT count(*) from CASE_GA_AJZLZ;
COUNT(*)
----------
346639
已用時(shí)間: 00: 00: 21.38
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'CASE_GA_AJZLZ'
……………………
請注意上面分析中的TABLE ACCESS(FULL),這說明該語句執(zhí)行了全表掃描。而且查詢使用了21.38秒。這時(shí)表還沒有經(jīng)過分析。下面我們來對該表進(jìn)行分析:
SQL analyze table CASE_GA_AJZLZ compute statistics;
表已分析。已用時(shí)間: 00: 05: 357.63。然后再來查詢:
SQL select count(*) from CASE_GA_AJZLZ;
COUNT(*)
----------
346639
已用時(shí)間: 00: 00: 00.71
Execution Plan
0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=351 Card=1)
1 0 SORT (AGGREGATE)
2 1 INDEX (FAST FULL SCAN) OF 'PK_AJZLZ' (UNIQUE) (Cost=351
Card=346351)
…………………………
請注意,這次時(shí)間僅僅用了0.71秒!這要?dú)w功于INDEX(FAST FULL SCAN)。通過分析表,查詢使用了PK_AJZLZ索引,磁盤I/O大幅減少,速度也大幅提升!下面的實(shí)用語句可以用來生成分析某個(gè)用戶的所有表和索引,假設(shè)用戶是GAXZUSR:
SQL set pagesize 0
SQL spool d:\analyze_tables.sql;
SQL select 'analyze table '||owner||'.'||table_name||'
compute statistics;' from dba_tables where owner='GAXZUSR';
SQL spool off
SQL spool spool d:\analyze_indexes.sql;
SQL select 'analyze index '||owner||'.'||index_name||'
compute statistics;' from dba_indexes where owner='GAXZUSR';
SQL spool off
SQL @d:\analyze_tables.sql
SQL @d:\analyze_indexes.sql
解釋:上面的語句生成了兩個(gè)sql文件,分別分析全部的GAXZUSR的表和索引。如果需要按照百分比來分析表,可以修改一下腳本。通過上面的步驟,我們就完成了對表和索引的分析,可以測試一下速度的改進(jìn)啦。建議定期運(yùn)行上面的語句,尤其是數(shù)據(jù)經(jīng)過大量更新。
當(dāng)然,也可以通過dbms_stats來分析表和索引,更方便一些。但是我仍然習(xí)慣上面的方法,因?yàn)槌晒εc否會(huì)直接提示出來。
另外,我們可以將優(yōu)化模式進(jìn)行修改。optimizer_mode值可以是RULE、CHOOSE、FIRST_ROWS和ALL_ROWS。對于OLTP系統(tǒng),可以改成FIRST_ROWS,來要求查詢盡快返回結(jié)果。這樣即使不用分析,在一般情況下也可以提高查詢性能。但是表和索引經(jīng)過分析后有助于找到最合適的執(zhí)行計(jì)劃。
三.設(shè)置cursor_sharing=FORCE 或SIMILAR
這種方法是8i才開始有的,oracle805不支持。通過設(shè)置該參數(shù),可以強(qiáng)制共享只有文字不同的語句解釋計(jì)劃。例如下面兩條語句可以共享:
SQL SELECT * FROM MYTABLE WHERE NAME='tom'
SQL SELECT * FROM MYTABLE WHERE NAME='turner'
這個(gè)方法可以大幅降低緩沖區(qū)利用率低的問題,避免語句重新解釋。通過這個(gè)功能,可以很大程度上解決硬解析帶來的性能下降的問題。個(gè)人感覺可根據(jù)系統(tǒng)的實(shí)際情況,決定是否將該參數(shù)改成FORCE。該參數(shù)默認(rèn)是exact。不過一定要注意,修改之前,必須先給ORACLE打補(bǔ)丁,否則改之后oracle會(huì)占用100%的CPU,無法使用。對于ORACLE9i,可以設(shè)置成SIMILAR,這個(gè)設(shè)置綜合了FORCE和EXACT的優(yōu)點(diǎn)。不過請慎用這個(gè)功能,這個(gè)參數(shù)也可能帶來很大的負(fù)面影響!
四.將常用的小表、索引釘在數(shù)據(jù)緩存KEEP池中
內(nèi)存上數(shù)據(jù)讀取速度遠(yuǎn)遠(yuǎn)比硬盤中讀取要快,據(jù)稱,內(nèi)存中數(shù)據(jù)讀的速度是硬盤的14000倍!如果資源比較豐富,把常用的小的、而且經(jīng)常進(jìn)行全表掃描的表給釘內(nèi)存中,當(dāng)然是在好不過了。可以簡單的通過ALTER TABLE tablename CACHE來實(shí)現(xiàn),在ORACLE8i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP)。一般來說,可以考慮把200數(shù)據(jù)塊之內(nèi)的表放在keep池中,當(dāng)然要根據(jù)內(nèi)存大小等因素來定。關(guān)于如何查出那些表或索引符合條件,可以使用本文提供的access.sql和access_report.sql。這兩個(gè)腳本是著名的Oracle專家 Burleson寫的,你也可以在讀懂了情況下根據(jù)實(shí)際情況調(diào)整一下腳本。對于索引,可以通過ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)來釘在KEEP池中。
將表定在KEEP池中需要做一些準(zhǔn)備工作。對于ORACLE9i 需要設(shè)置DB_KEEP_CACHE_SIZE,對于8i,需要設(shè)置buffer_pool_keep。在8i中,還要修改db_block_lru_latches,該參數(shù)默認(rèn)是1,無法使用buffer_pool_keep。該參數(shù)應(yīng)該比2*3*CPU數(shù)量少,但是要大于1,才能設(shè)置DB_KEEP_CACHE_BUFFER。buffer_pool_keep從db_block_buffers中分配,因此也要小于db_block_buffers。設(shè)置好這些參數(shù)后,就可以把常用對象永久釘在內(nèi)存里。
五.設(shè)置optimizer_max_permutations
對于多表連接查詢,如果采用基于成本優(yōu)化(CBO),ORACLE會(huì)計(jì)算出很多種運(yùn)行方案,從中選擇出最優(yōu)方案。這個(gè)參數(shù)就是設(shè)置oracle究竟從多少種方案來選擇最優(yōu)。如果設(shè)置太大,那么計(jì)算最優(yōu)方案過程也是時(shí)間比較長的。Oracle805和8i默認(rèn)是80000,8建議改成2000。對于9i,已經(jīng)默認(rèn)是2000了。
六.調(diào)整排序參數(shù)
(1) SORT_AREA_SIZE:默認(rèn)的用來排序的SORT_AREA_SIZE大小是32K,通常顯得有點(diǎn)小,一般可以考慮設(shè)置成1M(1048576)。這個(gè)參數(shù)不能設(shè)置過大,因?yàn)槊總€(gè)連接都要分配同樣的排序內(nèi)存。
(2) SORT_MULTIBLOCK_READ_COUNT:增大這個(gè)參數(shù)可以提高臨時(shí)表空間排序性能,該參數(shù)默認(rèn)是2,可以改成32來對比一下排序查詢時(shí)間變化。注意,這個(gè)參數(shù)的最大值與平臺(tái)有關(guān)系。