讓我們回到9i版本出現(xiàn)之前，回顧一下數(shù)據(jù)庫(kù)應(yīng)用和查詢(xún)調(diào)優(yōu)。我看到論壇里越來(lái)越多的帖子在詢(xún)問(wèn)那些冗長(zhǎng)又無(wú)用的任務(wù)存在的意義。在本文中，就讓我們來(lái)看看，哪些所謂的調(diào)優(yōu)是沒(méi)有必要做的。

定期索引重建

大多數(shù)情況下，DBA都在忙于進(jìn)行索引重建。是的，他們可以對(duì)埋在索引樹(shù)中空的索引塊進(jìn)行“大掃除”。但索引會(huì)再次生長(zhǎng)到重建前的大小，另外空指數(shù)塊也將再次分散在索引樹(shù)中，所以我不明白定期執(zhí)行重建索引的意義所在。事實(shí)上，對(duì)于非分區(qū)索引，我認(rèn)為完全沒(méi)有重建的必要，原因如下：

重建索引會(huì)對(duì)表和索引加鎖，直到重建完成會(huì)致使游標(biāo)無(wú)效沒(méi)有實(shí)際用處

是的，有些時(shí)候分區(qū)表上的本地索引需要重建，但這通常是在分區(qū)表進(jìn)行DDL(刪除分區(qū)，添加/分割分區(qū)，交換分區(qū))操作后進(jìn)行的。DDL操作會(huì)使得本地分區(qū)索引不能使用，所以它們才需要被重建。這不是一個(gè)“容量”問(wèn)題造成的，也不是一個(gè)“性能”問(wèn)題造成的，只是因?yàn)樗饕裏o(wú)法使用，將會(huì)干擾到表的訪(fǎng)問(wèn)和生產(chǎn)過(guò)程而已。但令人擔(dān)憂(yōu)的是，即使MOS已經(jīng)撤下了原來(lái)的關(guān)于何時(shí)重建索引的文檔，取而代之的是一個(gè)更負(fù)責(zé)任的版本，也更好的解決了這一問(wèn)題，但DBA決定是否執(zhí)行重建索引時(shí)卻依然依據(jù)過(guò)時(shí)的原則，如根據(jù)b -樹(shù)深度或索引大小來(lái)決定。仍然有很多DBA堅(jiān)定地使用計(jì)劃任務(wù)或DBMS_SCHEDULER在一周或一月內(nèi)進(jìn)行一次索引重建，他們深信這樣能夠提高性能，加快生產(chǎn)過(guò)程。事實(shí)并不是這樣，這只會(huì)在索引重建時(shí)給用戶(hù)的使用帶來(lái)不便。因?yàn)榇蠖鄶?shù)應(yīng)用程序表存在多個(gè)索引，對(duì)于一個(gè)給定的表，重建索引可以花費(fèi)幾個(gè)小時(shí)的時(shí)間，而且整個(gè)過(guò)程中數(shù)據(jù)表都處于鎖定狀態(tài)，生產(chǎn)過(guò)程基本停止。我不認(rèn)為這對(duì)提高性能有任何的幫助。

不斷調(diào)整數(shù)據(jù)庫(kù)參數(shù)

有一些DBA似乎總是不滿(mǎn)意數(shù)據(jù)庫(kù)的性能，他們不斷尋找問(wèn)題所在，而不管該問(wèn)題是否真的對(duì)性能造成了影響。這通常被稱(chēng)為強(qiáng)迫性調(diào)優(yōu)障礙(下文簡(jiǎn)稱(chēng)CTD)CTD造成了一個(gè)循環(huán)，現(xiàn)在調(diào)整這個(gè)，一會(huì)調(diào)整別的，這些調(diào)整僅僅是基于統(tǒng)計(jì)數(shù)據(jù)的微小變化。對(duì)于DBA來(lái)說(shuō)，CTD非常浪費(fèi)時(shí)間。并不是每一個(gè)延遲統(tǒng)計(jì)都需要完美的調(diào)整，這在現(xiàn)實(shí)世界是不可能的。一切都可以歸結(jié)為DBA所認(rèn)為的性能與終端用戶(hù)考慮性能是不同的。在CTD影響下，DBA認(rèn)為一切都是潛在的問(wèn)題，即使這些問(wèn)題并不影響終端用戶(hù)的體驗(yàn)。終端用戶(hù)方面，當(dāng)他們花費(fèi)了比預(yù)期更長(zhǎng)的時(shí)間，他們才會(huì)認(rèn)為性能有問(wèn)題。一旦終端用戶(hù)的問(wèn)題被解決，優(yōu)化就應(yīng)該停止，因?yàn)檫M(jìn)一步調(diào)整并不會(huì)提供任何額外的好處。在生產(chǎn)系統(tǒng)中延遲統(tǒng)計(jì)數(shù)據(jù)并不會(huì)是完美的，多用戶(hù)訪(fǎng)問(wèn)和修改數(shù)據(jù)會(huì)導(dǎo)致并發(fā)等待，無(wú)論多么短，在這方面進(jìn)行調(diào)優(yōu)以期待完美的響應(yīng)時(shí)間是毫無(wú)用處的，CTD，讓DBA轉(zhuǎn)變?yōu)橐粋€(gè)吹毛求疵的人，雖然花費(fèi)大量時(shí)間努力調(diào)整的參數(shù)，卻并沒(méi)有影響實(shí)際的系統(tǒng)性能，老實(shí)說(shuō)，這毫無(wú)用處。

表重組

隨著表容量越來(lái)越大，查詢(xún)?cè)L問(wèn)數(shù)據(jù)需要更長(zhǎng)的時(shí)間才能完成，特別是在查詢(xún)需要遍歷全表才能獲取所需數(shù)據(jù)的情況下。仍有一些DBA堅(jiān)信重組表數(shù)據(jù)會(huì)對(duì)提高性能有很大的幫助。其中一個(gè)重組思想就是對(duì)表數(shù)據(jù)進(jìn)行排序，改善集群因子。是的，計(jì)算索引的聚集因子基于表元素“位置”與排序索引鍵的相對(duì)關(guān)系，但“改善”某一個(gè)索引的聚集因子通常會(huì)對(duì)表中其他索引的聚集因子造成不良影響。另一個(gè)問(wèn)題是，這些表屬于堆機(jī)構(gòu)，并未存在實(shí)際的數(shù)據(jù)順序，你可以在表中任何空數(shù)據(jù)塊上插入數(shù)據(jù)。數(shù)據(jù)的有序性只會(huì)持續(xù)到第一個(gè)插入之后，此后表數(shù)據(jù)的索引再次分散。多年以前，供應(yīng)商認(rèn)為對(duì)數(shù)據(jù)排序是提高性能最好的方式，并“建議”其產(chǎn)品定期維護(hù)這個(gè)美妙的順序。這個(gè)想法的問(wèn)題在于，表數(shù)據(jù)可以按照一個(gè)索引進(jìn)行排序，當(dāng)終端用戶(hù)處理數(shù)據(jù)數(shù)據(jù)時(shí)，它們又逐漸回歸到其未排序時(shí)的狀態(tài)。像CTD一樣，這成為一個(gè)永無(wú)止境的循環(huán)，“排序，排序，排序，排序，排序”，人們認(rèn)為這樣會(huì)有好處。實(shí)際上卻不能，因?yàn)槊看螖?shù)據(jù)排序時(shí)，生產(chǎn)系統(tǒng)呈現(xiàn)為不可用狀態(tài)。如果終端用戶(hù)不能工作，排序后的查詢(xún)即使再快也沒(méi)有任何用處。不幸的是，一旦DBA被這種排序蒙蔽，他們就難以意識(shí)到這些排序流程給用戶(hù)帶來(lái)的不便。終端用戶(hù)需要工作，而不是一直等待DBA完成數(shù)據(jù)排序，在一段時(shí)間后再返回一個(gè)未排序結(jié)果。DBA應(yīng)該努力創(chuàng)建有意義和持久性改變來(lái)提高性能;查詢(xún)調(diào)優(yōu)，計(jì)劃穩(wěn)定和索引分析才是有意義的方式，他們能夠帶來(lái)實(shí)實(shí)在在的好處，且持續(xù)時(shí)間也遠(yuǎn)遠(yuǎn)超過(guò)了創(chuàng)建它們時(shí)所消耗的時(shí)間。

DBA浪費(fèi)時(shí)間的例子還不僅于此，在此就不再一一列舉。知道該做什么和能做些什么是一個(gè)偉大DBA的標(biāo)志。再次閱讀本文介紹的這些要點(diǎn)，應(yīng)該能夠引導(dǎo)你完成有意義的調(diào)優(yōu)任務(wù)，這些任務(wù)的效果持久，且不需要持續(xù)的關(guān)注或重復(fù)執(zhí)行。當(dāng)然，沒(méi)有任何東西是完美的，特別是你的數(shù)據(jù)庫(kù)，所以不要為了追求完美而讓你無(wú)休止的忙碌于調(diào)優(yōu)工作中。有很多真正需要DBA來(lái)完成的日常工作。不要陷入細(xì)節(jié)中無(wú)法自拔，它并不值得你付出努力。