以下的文章主要是介紹Oracle delete數(shù)據(jù)后的釋放表空間問(wèn)題以Oracle 9i為實(shí)例。以下就是對(duì)相關(guān)內(nèi)容的具體介紹，以下就是Oracle delete的相關(guān)內(nèi)容的具體介紹，望你瀏覽完以下的內(nèi)容會(huì)有所收獲。

數(shù)據(jù)表的龐大導(dǎo)致查詢(xún)速度降低是必然的，所以常常將數(shù)據(jù)表的數(shù)據(jù)移走，但是使用delete后，數(shù)據(jù)是刪除了，但是速度沒(méi)有多大改善，憂悶了。使用備份表再drop掉原表。的確可以解決問(wèn)題。但是較麻煩，今天請(qǐng)教了一個(gè)Oracle高手，解決了問(wèn)題。 由于delete操作是不釋放表空間的，要想提高查詢(xún)速度則必須釋放表空間。

對(duì)Oracle 9i而言，釋放表空間則需要重新分析表。

analyze table itemLog compute statistics; 

再進(jìn)行select ,感覺(jué)的確快了很多。

另一種方法：

使用exp將表導(dǎo)出，drop 掉表，再imp回去。先做個(gè)簡(jiǎn)要筆記今天，幫同事導(dǎo)數(shù)據(jù)，從開(kāi)發(fā)環(huán)境導(dǎo)到測(cè)試環(huán)境中，發(fā)現(xiàn)一個(gè)查詢(xún)變的很慢。查看執(zhí)行計(jì)劃，發(fā)現(xiàn)居然用了全表掃描（表中大約300w條記錄），為啥不用索引呢，查看索引狀態(tài)，一切正常。

肯定是索引的問(wèn)題，先分析一下表再說(shuō)。

analyze table ysgl_compile_reqsub 
compute statistics for all indexes; 

正常了。

一個(gè)論壇上的帖子：

Analyze table對(duì)Oracle性能的提升，大家來(lái)討論一下這個(gè)優(yōu)化課題我自己碰到的一個(gè)實(shí)際情況：

一個(gè)sql語(yǔ)句執(zhí)行要1個(gè)小時(shí)，有時(shí)候還出不了結(jié)果，但分析sql涉及的表后，然后重新執(zhí)行3分鐘搞定！真的有這樣驚人的差異？世事無(wú)絕對(duì)，有時(shí)候你可能發(fā)現(xiàn)會(huì)變慢，了解了CBO和RBO你就知道區(qū)別了。

annlyze表會(huì)增加CBO執(zhí)行的性能？不一定的。我就碰到一個(gè)語(yǔ)句分析后要執(zhí)行30多分鐘，刪除分析后，只要30秒。很多情況下不一定的，最好是自己從執(zhí)行計(jì)劃判斷。

以上的相關(guān)內(nèi)容就是對(duì)Oracle delete數(shù)據(jù)后的釋放表空間問(wèn)題以O(shè)racle 9i為實(shí)例開(kāi)做以詳細(xì)解析，望你能有所收獲。

【編輯推薦】

1. Oracle約束的添加可以用六種方法解決
2. Oracle join用法的具體介紹
3. Oracle遞歸查詢(xún)中用相關(guān)的子句來(lái)進(jìn)行遞歸查詢(xún)
4. 查看Oracle當(dāng)前連接數(shù)用SQL語(yǔ)句的實(shí)際操作
5. Oracle SQL執(zhí)行緩慢的原因分析