Oracle delete數(shù)據(jù)后的釋放表空間問題的解決
我們都知道數(shù)據(jù)表的龐大導而致其查詢速度的降低是水到渠成的,所以我們只有將相關(guān)的數(shù)據(jù)表的數(shù)據(jù)相應(yīng)的移走,但是如果使用Oracle delete之后,相關(guān)的數(shù)據(jù)刪除了,但是速度沒有多大改善,憂悶了。
使用備份表再drop掉原表。的確可以解決問題。但是較麻煩,今天請教了一個Oracle高手,解決了問題。 由于Oracle delete操作是不釋放表空間的,要想提高查詢速度則必須釋放表空間。
對Oracle 9i而言,釋放表空間則需要重新分析表。
- analyze table itemLog compute statistics;
再進行select ,感覺的確快了很多。
另一種方法:使用exp將表導出,drop 掉表,再imp回去。
先做個簡要筆記
今天,幫同事導數(shù)據(jù),從開發(fā)環(huán)境導到測試環(huán)境中,發(fā)現(xiàn)一個查詢變的很慢。查看執(zhí)行計劃,發(fā)現(xiàn)居然用了全表掃描(表中大約300w條記錄),為啥不用索引呢,查看索引狀態(tài),一切正常。暈。
肯定是索引的問題,先分析一下表再說。
- analyze table ysgl_compile_reqsub compute statistics for all indexes;
正常了。
一個論壇上的帖子:
Analyze table對Oracle性能的提升
大家來討論一下這個優(yōu)化課題
我自己碰到的一個實際情況:
一個sql語句執(zhí)行要1個小時,有時候還出不了結(jié)果,但分析sql涉及的表后,然后重新執(zhí)行3分鐘搞定!
真的有這樣驚人的差異?
世事無絕對,有時候你可能發(fā)現(xiàn)會變慢
了解了CBO和RBO你就知道區(qū)別了
annlyze表會增加CBO執(zhí)行的性能?不一定的。
我就碰到一個語句分析后要執(zhí)行30多分鐘,刪除分析后,只要30秒。
很多情況下不一定的,***是自己從執(zhí)行計劃判斷
以上的相關(guān)內(nèi)容就是對Oracle delete數(shù)據(jù)后的釋放表空間問題的介紹,望你能有所收獲。
【編輯推薦】