




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡(jiǎn)介
Oracle性能優(yōu)化基本方法包括一下幾個(gè)步驟,包括:1) 設(shè)立合理的Oracle性能優(yōu)化目標(biāo)。2) 測(cè)量并記錄當(dāng)前的Oracle性能。3) 確定當(dāng)前Oracle性能瓶頸(Oracle等待什么、哪些SQL語(yǔ)句是該等待事件的成分)。4) 把等待事件記入跟蹤文件。5) 確定當(dāng)前的OS瓶頸。6) 優(yōu)化所需的成分(應(yīng)用程序、數(shù)據(jù)庫(kù)、I/O、爭(zhēng)用、OS等)。7) 跟蹤并實(shí)施更改控制過程。8) 測(cè)量并記錄當(dāng)前性能9) 重復(fù)步驟3到7,直到滿足優(yōu)化目標(biāo)下面來 詳述。1?設(shè)立合理的Oracle性能優(yōu)化目標(biāo)重點(diǎn):關(guān)于設(shè)立目標(biāo)的最重要的一點(diǎn)是它們必須是可量化和可達(dá)到的。方法:目標(biāo)必須是當(dāng)前性能和所需性能的的陳述形式的語(yǔ)句。2?測(cè)量并記錄當(dāng)前Oracle性能重點(diǎn):1) 需要在峰值活動(dòng)時(shí)間獲得當(dāng)前系統(tǒng)性能快照2) 關(guān)鍵是要在出現(xiàn)性能問題的時(shí)間段內(nèi)采集信息3) 必須在合理的時(shí)間段上采集,一般在峰值期間照幾個(gè)為期15分鐘的快照3?確定當(dāng)前Oracle性能瓶頸重點(diǎn):從Oracle等待接口v$system_event、v$session_event和v$session_wait中獲得等待事件,進(jìn)而找出影響性能的對(duì)象和sql語(yǔ)句。方法如下:1)首先,利用v$system_event視圖執(zhí)行下面的查詢查看數(shù)據(jù)庫(kù)中某些常見的等待事件:select*fromv$system_eventwhereeventin('bufferbusywaits','dbfilesequentialread','dbfilescatteredread','enqueue','freebufferwaits','latchfree',
'logfileparallelwrite','logfilesync');2) 接著,利用下面對(duì)v$session_event和v$session視圖進(jìn)行的查詢,研究具有對(duì)上面顯示的內(nèi)容有貢獻(xiàn)的等待事件的會(huì)話:selectse.sid,s.username,se.event,se.total_waits,se.time_waited,se.average_waitfromv$sessions,v$session_eventsewheres.sid=se.sidandse.eventnotlike'SQL*Net%'ands.status='ACTIVE'ands.usernameisnotnull;3) 使用下面查詢找到與所連接的會(huì)話有關(guān)的當(dāng)前等待事件。這些信息是動(dòng)態(tài)的,為了查看一個(gè)會(huì)話的等待最多的事件是什么,需要多次執(zhí)行此查詢。selectsw.sid,s.username,sw.event,sw.wait_time,sw.state,sw.seconds_in_waitSEC_IN_WAITfromv$sessions,v$session_waitswwheres.sid=sw.sidandsw.eventnotlike'SQL*Net%'ands.usernameisnotnullorderbysw.wait_timedesc;4) 查詢會(huì)話等待事件的詳細(xì)信息selectsid,event,p1text,p1,p2text,p2,p3text,p3fromv$session_waitwheresidbetween&1and&2andeventnotlike'%SQL%'andeventnotlike'%rdbms%';5) 利用Pl、P2的信息,找出等待事件的相關(guān)的段selectowner,segment_name,segment_type,tablespace_namefromdba_extentswherefile_id=&fileid_inand&blockid_inbetweenblock_idandblock_id+blocks-1;6) 獲得操作該段的sql語(yǔ)句:selectsid,getsqltxt(sql_hash_value,sql_address)2.fromv$session2.fromv$session3.wheresid=&sid_in;getsqltxt函數(shù)getsqltxt函數(shù)createorreplacefunctionGetSQLtxt(hashaddr_ininv$sqltext.hash_value%type,addr_ininv$sqltext.address%type)returnvarchar2istemp_sqltxtvarchar2(32767);cursorsqlpiece_curisselectpiece,sql_textfromv$sqltextwherehash_value=hashaddr_inandaddress=addr_inorderbypiece;beginforsqlpiece_recinsqlpiece_curlooptemp_sqltxt:=temp_sqltxtIIsqlpiece_rec.sql_text;endloop;returntemp_sqltxt;endGetSQLtxt;至此已經(jīng)找到影響性能的對(duì)象和sql語(yǔ)句,可以有針對(duì)性地優(yōu)化4.把等待事件記入跟蹤文件
重點(diǎn):如果在跟蹤系統(tǒng)上的等待事件時(shí),由于某種原因遇到了麻煩,則可以將這些等待事件記入一個(gè)跟蹤文件。方法如下:1) 對(duì)于當(dāng)前會(huì)話:altersessionsettimed_statistics=true;altersessionsetmax_dump_file_size=unlimited;altersessionsetevents'10046tracenamecontextforever,level12!?;2) 執(zhí)行應(yīng)用程序,然后在USER_DUMP_DEST指出的目錄中找到跟蹤文件。3) 查看文件中以詞WAIT開始的所有行。4) 對(duì)于其它的會(huì)話5) 確定會(huì)話的進(jìn)程ID(SPID)。下面的查詢識(shí)別出名稱以A開始的所有用戶的會(huì)話進(jìn)程ID:selectS.Username,P?SpidfromV$SESSIONS,V$PROCESSPwhereS.PADDR=P.ADDRandS.Usernamelike'A%';6) 以sysdba進(jìn)入sqlplus執(zhí)行altersessionset timed_statistics=true;altersessionset max_dump_file_size=unlimited;oradebugsetospidoradebugunlimitoradebugevent10046tracenamecontextforever,levelX/*WhereX=(1,4,8,12)*/7) 跟蹤某個(gè)時(shí)間間隔得會(huì)話應(yīng)用程序。8) 在USER_DUMP_DEST的值指出的目錄中利用SPID查看跟蹤文件9) 查看文件中以詞WAIT開始的所有行。5?確定當(dāng)前OS瓶頸1)WindowsNT上的監(jiān)控使用控制面板-〉管理工具-〉性能即可2)UNIX上的監(jiān)控使用通用性的工具,包括sar、iostat、cpustat、mpstat、netstat、top、osview等。Oracle性能優(yōu)化所需的成分(應(yīng)用程序、數(shù)據(jù)庫(kù)、I/O、爭(zhēng)用、OS等)。
跟蹤并實(shí)施更改控制過程。8?測(cè)量并記錄當(dāng)前Oracle性能9.重復(fù)步驟3到7,直到滿足優(yōu)化目標(biāo)幾個(gè)簡(jiǎn)單的步驟大幅提高Oracle性能--我優(yōu)化數(shù)據(jù)庫(kù)的三板斧數(shù)據(jù)庫(kù)優(yōu)化的討論可以說是一個(gè)永恒的主題。資深的Oracle優(yōu)化人員通常會(huì)要求提出性能問題的人對(duì)數(shù)據(jù)庫(kù)做一個(gè)statspack,貼出數(shù)據(jù)庫(kù)配置等等。還有的人認(rèn)為要抓出執(zhí)行最慢的語(yǔ)句來進(jìn)行優(yōu)化。但實(shí)際情況是,提出疑問的人很可能根本不懂執(zhí)行計(jì)劃,更不要說statspack了。而我認(rèn)為,數(shù)據(jù)庫(kù)優(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ù)庫(kù)配置、數(shù)據(jù)結(jié)構(gòu)上來下手,首先讓數(shù)據(jù)庫(kù)有一個(gè)良好的配置,然后再考慮具體優(yōu)化某些過慢的語(yǔ)句。我在給我的用戶系統(tǒng)進(jìn)行優(yōu)化的過程中,總結(jié)了一些基本的,簡(jiǎn)單易行的辦法來優(yōu)化數(shù)據(jù)庫(kù),算是我的三板斧,呵呵。不過請(qǐng)注意,這些不一定普遍使用,甚至有的會(huì)有副作用,但是對(duì)OLTP系統(tǒng)、基于成本的數(shù)據(jù)庫(kù)往往行之有效,不妨試試。(注:附件是Burleson寫的用來報(bào)告數(shù)據(jù)庫(kù)性能等信息的腳本,本文用到)一.設(shè)置合適的SGA常常有人抱怨服務(wù)器硬件很好,但是Oracle就是很慢。很可能是內(nèi)存分配不合理造成的。假設(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來直接分配。假設(shè)內(nèi)存有1G,Oracle的SGA可以考慮分配500M:共享池分配100M到150M,數(shù)據(jù)緩沖區(qū)分配300M到400M。內(nèi)存2G,SGA可以考慮分配1.2G,共享池300M到500M,剩下的給數(shù)據(jù)塊緩沖區(qū)。內(nèi)存2G以上:共享池300M到500M就足夠啦,再多也沒有太大幫助;(Biti_rainy有專述)數(shù)據(jù)緩沖區(qū)是盡可能的大,但是一定要注意兩個(gè)問題:一是要給操作系統(tǒng)和其他應(yīng)用留夠內(nèi)存,二是對(duì)于32位的操作系統(tǒng),Oracle的SGA有1.75G的限制。有的32位操作系統(tǒng)上可以突破這個(gè)限制,方法還請(qǐng)看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ì)使查詢速度大幅提升。分析表命令可以用ANALYZETABLE分析索引可以用ANALYZEINDEX命令。對(duì)于少于100萬(wàn)的表,可以考慮分析整個(gè)表,對(duì)于很大的表,可以按百分比來分析,但是百分比不能過低,否則生成的統(tǒng)計(jì)信息可能不準(zhǔn)確??梢酝ㄟ^DBA_TABLES的LAST_ANALYZED列來查看表是否經(jīng)過分析或分析時(shí)間,索引可以通過DBA_INDEXES的LAST_ANALYZED列。下面通過例子來說明分析前后的速度對(duì)比。(表CASE_GA_AJZLZ大約有35萬(wàn)數(shù)據(jù),有主鍵)首先在SQLPLUS中打開自動(dòng)查詢執(zhí)行計(jì)劃功能。(第一次要執(zhí)行\(zhòng)RDBMS\ADMIN\utlxplan.sql來創(chuàng)建PLAN_TABLE這個(gè)表)SQL>SETAUTOTRACEONSQL>SETTIMINGON通過SETAUTOTRACEON來查看語(yǔ)句的執(zhí)行計(jì)劃,通過SETTIMINGON來查看語(yǔ)句運(yùn)行時(shí)間。SQL>selectcount(*)fromCASE_GA_AJZLZ;COUNT(*)346639已用時(shí)間:00:00:21.38ExecutionPlan0SELECTSTATEMENTOptimizer=CHOOSE0SORT(AGGREGATE)1TABLEACCESS(FULL)OF'CASE_GA_AJZLZ'請(qǐng)注意上面分析中的TABLEACCESS(FULL),這說明該語(yǔ)句執(zhí)行了全表掃描。而且查詢使用了21.38秒。這時(shí)表還沒有經(jīng)過分析。下面我們來對(duì)該表進(jìn)行分析:SQL>analyzetableCASE_GA_AJZLZcomputestatistics;表已分析。已用時(shí)間:00:05:357.63然后再來查詢:SQL>selectcount(*)fromCASE_GA_AJZLZ;COUNT(*)346639已用時(shí)間:00:00:00.71ExecutionPlan0SELECTSTATEMENTOptimizer=FIRST_ROWS(Cost=351Card=1)0SORT(AGGREGATE)1INDEX(FASTFULLSCAN)OF'PK_AJZLZ'(UNIQUE)(Cost=351Card=346351)請(qǐng)注意,這次時(shí)間僅僅用了0.71秒!這要?dú)w功于INDEX(FASTFULLSCAN)。通過分析表,查詢使用了PK_AJZLZ索引,磁盤I/O大幅減少,速度也大幅提升!下面的實(shí)用語(yǔ)句可以用來生成分析某個(gè)用戶的所有表和索引,假設(shè)用戶是GAXZUSR:SQL>setpagesize0SQL>spoold:\analyze_tables.sql;SQL>select'analyzetable'||owner||'.'||table_name||'computestatistics;'fromdba_tableswhereowner='GAXZUSR';SQL>spooloffSQL>spoolspoold:\analyze_indexes.sql;SQL>select'analyzeindex'||owner||'.'||index_name||'computestatistics;'fromdba_indexeswhereowner='GAXZUSR';SQL>spooloffSQL>@d:\analyze_tables.sqlSQL>@d:\analyze_indexes.sql解釋:上面的語(yǔ)句生成了兩個(gè)sql文件,分別分析全部的GAXZUSR的表和索引。如果需要按照百分比來分析表,可以修改一下腳本。通過上面的步驟,我們就完成了對(duì)表和索引的分析,可以測(cè)試一下速度的改進(jìn)啦。建議定期運(yùn)行上面的語(yǔ)句,尤其是數(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。對(duì)于OLTP系統(tǒng),可以改成FIRST_ROWS,來要求查詢盡快返回結(jié)果。這樣即使不用分析,在一般情況下也可以提高查詢性能。但是表和索引經(jīng)過分析后有助于找到最合適的執(zhí)行計(jì)劃。三.設(shè)置cursor_sharing=FORCE或SIMILAR這種方法是8i才開始有的,oracle805不支持。通過設(shè)置該參數(shù),可以強(qiáng)制共享只有文字不同的語(yǔ)句解釋計(jì)劃。例如下面兩條語(yǔ)句可以共享:SQL>SELECT*FROMMYTABLEWHERENAME='tom'SQL>SELECT*FROMMYTABLEWHERENAME='turner'這個(gè)方法可以大幅降低緩沖區(qū)利用率低的問題,避免語(yǔ)句重新解釋。通過這個(gè)功能,可以很大程度上解決硬解析帶來的性能下降的問題。個(gè)人感覺可根據(jù)系統(tǒng)的實(shí)際情況,決定是否將該參數(shù)改成FORCE。該參數(shù)默認(rèn)是exact。不過一定要注意,修改之前,必須先給ORACLE打補(bǔ)丁,否則改之后oracle會(huì)占用100%的CPU,無法使用。對(duì)于ORACLE9i,可以設(shè)置成SIMILAR,這個(gè)設(shè)置綜合了FORCE和EXACT的優(yōu)點(diǎn)。不過請(qǐng)慎用這個(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)然是在好不過了??梢院?jiǎn)單的通過ALTERTABLEtablenameCACHE來實(shí)現(xiàn),在ORACLE8i之后可以使用ALTERTABLEtableSTORAGE(BUFFER_POOLKEEP)。一般來說,可以考慮把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)整一下腳本。對(duì)于索引,可以通過ALTERINDEXindexnameSTORAGE(BUFFER_POOLKEEP)來釘在KEEP池中。將表定在KEEP池中需要做一些準(zhǔn)備工作。對(duì)于ORACLE9i需要設(shè)置DB_KEEP_CACHE_SIZE,對(duì)于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ù)后,就可以把常用對(duì)象永久釘在內(nèi)存里。五?設(shè)置optimizer_max_permutations對(duì)于多表連接查詢,如果采用基于成本優(yōu)化(CBO),ORACLE會(huì)計(jì)算出很多種運(yùn)行方案,從中選擇出最優(yōu)方案。這個(gè)參數(shù)就是設(shè)置oracle究竟從多少種方案來選擇最優(yōu)。如果設(shè)置太大,那么計(jì)算最優(yōu)方案過程也是時(shí)間比較長(zhǎng)的。Oracle805和8i默認(rèn)是80000,8建議改成2000。對(duì)于9i,已經(jīng)默認(rèn)是2000了。六.調(diào)整排序參數(shù)SORT_AREA_SIZE:默認(rèn)的用來排序的SORT_AREA_SIZE大小是32K,通常顯得有點(diǎn)小,一般可以考慮設(shè)置成1M(1048576)。這個(gè)參數(shù)不能設(shè)置過大,因?yàn)槊總€(gè)連接都要分配同樣的排序內(nèi)存。SORT_MULTIBLOCK_READ_COUNT:增大這個(gè)參數(shù)可以提高臨時(shí)表空間排序性能,該參數(shù)默認(rèn)是2,可以改成32來對(duì)比一下排序查詢時(shí)間變化。注意,這個(gè)參數(shù)的最大值與平臺(tái)有關(guān)系。七?調(diào)整其它幾個(gè)關(guān)鍵的性能參數(shù)很多人認(rèn)為使用oracle數(shù)據(jù)庫(kù),系統(tǒng)的默認(rèn)參數(shù)就是最好的,其實(shí)不是這樣,很多參數(shù)都需要調(diào)整,而且調(diào)整前后性能大不一樣。log_buffer日志緩沖區(qū)大小默認(rèn)設(shè)置32k太小了,建議設(shè)置成512K或者1M。log_buffer=524288optimizer_index_caching這個(gè)參數(shù)可以設(shè)置索引的緩沖度,范圍是0到100,默認(rèn)是0,可以考慮設(shè)置成90optimizer_index_cost_adj這個(gè)參數(shù)是一個(gè)百分比,表明索引掃描與全表掃描的代價(jià)范圍是1到1000。默認(rèn)=100表名索引掃描與全表掃描代價(jià)一樣。將這個(gè)參數(shù)設(shè)小表名索引代價(jià)要小于全表掃描,這樣就使得使用CBO進(jìn)行成本計(jì)算時(shí)更傾向于使用索引掃描。建議把這個(gè)參數(shù)設(shè)置成30到50。八?改變聯(lián)機(jī)日志文件大小(一般用于oracle805)Oracle805的聯(lián)機(jī)日志文件默認(rèn)只有1M大小,這實(shí)在是太小了,通過查看數(shù)據(jù)庫(kù)的日志,很可能發(fā)現(xiàn)“checkpointnotcomplete”之類的錯(cuò)誤提示。這會(huì)導(dǎo)致系統(tǒng)穩(wěn)定性,同樣也降低了數(shù)據(jù)庫(kù)性能。建議修改成10M。修改方法是刪除一個(gè)組、添加一個(gè)組,直到3個(gè)組都換成新的大小。說明:這個(gè)操作需要實(shí)施人員具有較多的數(shù)據(jù)庫(kù)知識(shí),如果不太了解,最好不要試驗(yàn)。九.改變數(shù)據(jù)塊大小(一般用于oracle805)Oracle805默認(rèn)的塊(DB_BLOCK_SIZE)大小是2K,太小了,因?yàn)閴K小,所以請(qǐng)求同樣的數(shù)據(jù)量的時(shí)候,讀的次數(shù)就要增多,導(dǎo)致性能低下。當(dāng)然如果服務(wù)器性能比較好,還是升級(jí)Oracle更好,如果服務(wù)器配置比較差,建議改成8K。但是數(shù)據(jù)塊不能直接修改,唯一的辦法就是將數(shù)據(jù)導(dǎo)出,重新創(chuàng)建數(shù)據(jù)庫(kù),然后將數(shù)據(jù)導(dǎo)入。說明:這個(gè)操作需要實(shí)施人員具有較多的數(shù)據(jù)庫(kù)知識(shí),如果不太了解,最好不要試驗(yàn)。十.設(shè)置合適的表存儲(chǔ)參數(shù)對(duì)于有很多并發(fā)寫入用戶的系統(tǒng)來說,如果系統(tǒng)沒有經(jīng)過調(diào)整,經(jīng)常會(huì)有數(shù)據(jù)等待現(xiàn)象。這是因?yàn)?i之前的表設(shè)置的默認(rèn)的自由隊(duì)列freelists為1,這樣就可能造成數(shù)據(jù)等待。通過查看v$waitstat,如果發(fā)現(xiàn)datablock或者freelist類的count次數(shù)很大,則說明等待情況嚴(yán)重,需要增加freelists。這個(gè)參數(shù)在8i、9i中可以動(dòng)態(tài)修改(需要打補(bǔ)丁,否則會(huì)有ORA-1O62O:Operationnotallowedonthissegment)在ORACLE8O5中,只能通過重新創(chuàng)建表來修改。SQL>select*fromv$waitstat;CLASSCOUNTTIMEdatablock11922013342456sortblock00saveundoblock00segmentheader10freelist00如果測(cè)算經(jīng)常有10個(gè)并發(fā)的寫用戶,可以把表的freelists改成10。例如下面的腳本可以把GAXZUSR用戶的所有表重新設(shè)置FREELISTS的語(yǔ)句寫在D:\FREELISTS.SQL里:SQL>SETPAGESIZE0SQL>SPOOLD:\FREELISTS.SQLSQL>SELECT'ALTERTABLE'||TABLE_NAME||'STORAGE(FREELISTS10);'FROMDBA_TABLESWHEREOWNER='GAXZUSR';SQL>SPOOLOFF檢查D:\FREELISTS.SQL,沒有錯(cuò)誤后運(yùn)行修改FREELISTS:SQL>@D:\FREELISTS.SQL十一.重新組織表結(jié)構(gòu)(1)按照主鍵重新排序。數(shù)據(jù)庫(kù)運(yùn)行了一段時(shí)間后,可能會(huì)有很多數(shù)據(jù),而這些數(shù)據(jù)又可能是經(jīng)常按照某個(gè)字段來選取區(qū)段數(shù)據(jù)。如果我們能夠把主鍵按照順序重新來組織一下表,那么用主鍵進(jìn)行的查詢就會(huì)明顯快很多,主要是因?yàn)榻?jīng)過排序后,相似的編號(hào)都放在同一個(gè)數(shù)據(jù)塊里,ORACLE在進(jìn)行主鍵范圍查找的時(shí)候,就會(huì)大大減少物理塊度讀取數(shù)量。在對(duì)表和索引分析之后,可以通過DBA_INDEXES的CLUSTERING_FACTOR列來判斷表是否需要重新排序。如果該字段的值與表的BLOCK數(shù)量差不多,則不需要重新排序,如果和表的行數(shù)差不多,則應(yīng)該考慮重新組織一下了。下面的例子示意性說明怎樣對(duì)表CASE_GA_AJZLZ按照主鍵PK_AJZLZ進(jìn)行重新排序:<1>將表CASE_GA_AJZLZ的索引、外間約束引用等找出來備用。SETPAGESIZE0SETLINESIZE300SPOOLDISABLE_CONSTRAINTS.SQLSELECT'ALTERTABLE'||TABLE_NAME||'DISABLECONSTRAINT'||CONSTRAINT_NAME||';'FROMUSER_CONSTRAINTSWHERECONSTRAINT_TYPE='R'ANDR_CONSTRAINT_NAME='PK_AJZLZ';SPOOLOFFSPOOLCREATE_CONSTRAINTS.SQLSELECT'ALTERTABLE'||TABLE_NAME||'ADDCONSTRAINT'||CONSTRAINT_NAME||'FOREIGNKEY(CASEID)REFERENCESCASE_GA_AJZLZ(CASEID);'FROMUSER_CONSTRAINTSWHERECONSTRAINT_TYPE='R'ANDR_CONSTRAINT_NAME='PK_AJZLZ';SPOOLOFFSPOOLCREATE_INDEX.SQLSELECT'CREATEINDEX'||INDEX_NAME||'ON'||TABLE_NAME||'('||COLUMN_NAME||')TABLESPACEINDX;'FROMUSER_IND_COLUMNSWHERETABLE_NAME='CASE_GA_AJZLZ'ANDINDEX_NAME<>'PK_AJZLZ';<2>創(chuàng)建新的表CASE_GA_AJZLZ_NEW:SQL>CREATETABLECASE_GA_AJZLZ_NEWASSELECT/*+INDEX(CASE_GA_AJZLZPK_AJZLZ)*/*FROMCASE_GA_AJZLZ;注意,上面的注釋(紅顏色部分)表名按照PK_AJZLZ排序來重新組織表。<3>禁用CASE_GA_AJZLZ的夕卜間約束,將表CASE_GA_AJZLZTRUNCATE,然后冊(cè)U除之<4>將表CASE_GA_AJZLZ_NEW更名為CASE_GA_AJZLZSQL>ALTERTABLECASE_GA_AJZLZ_NEWRENAMETOCASE_GA_AJZLZ;<5>創(chuàng)建CASE_GA_AJZLZ的所有索引、主鍵約束等。SQL>ALTE
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。
最新文檔
- GB/T 45231-2025智能床
- 全新合伙人合同:創(chuàng)始股東權(quán)利與義務(wù)
- 雙方戒煙合同責(zé)任書
- 船舶所有權(quán)變更合同
- 合同離婚改革:軍人家庭權(quán)益保障
- 5電磁鐵(教學(xué)設(shè)計(jì))-2024-2025學(xué)年六年級(jí)上冊(cè)科學(xué)教科版
- 項(xiàng)目融資及還款合同書范例
- 住宅租賃安全責(zé)任合同條款
- 知識(shí)產(chǎn)權(quán)保護(hù)及商業(yè)秘密合同范本
- 租賃合同模板范本:貨物運(yùn)輸設(shè)備
- 2024-2025年第二學(xué)期學(xué)校教導(dǎo)處工作計(jì)劃(二)
- 2025年蘇州衛(wèi)生職業(yè)技術(shù)學(xué)院高職單招職業(yè)技能測(cè)試近5年??及鎱⒖碱}庫(kù)含答案解析
- 二零二五年度博物館場(chǎng)地租賃與文物保護(hù)合作協(xié)議3篇
- 2025年春新人教版歷史七年級(jí)下冊(cè)全冊(cè)課件
- 2024年鐘山職業(yè)技術(shù)學(xué)院高職單招語(yǔ)文歷年參考題庫(kù)含答案解析
- 駱駝祥子-(一)-劇本
- 魏晉南北朝時(shí)期中外文化的交流
- 漁業(yè)行業(yè)智能化海洋牧場(chǎng)養(yǎng)殖方案
- 《工程勘察設(shè)計(jì)收費(fèi)標(biāo)準(zhǔn)》(2002年修訂本)
- 《債權(quán)法教學(xué)》課件
- 太傻天書(完整版)
評(píng)論
0/150
提交評(píng)論