表空間有數據字典和本地托國兩種管理模式如果采用數據字典來維護的話發生在數據庫的段上並關系到盤區分配的操作(如擴展一個表)將會導致對數據字典的操作如果有很多帶有盤區的表被操作時數據字典將會成這些操作的瓶頸資源可見如果采用數據字典來維護表空間的話那麼數據庫要花的代價就會很大
為了解決這個問題改善表空間的管理性能Oracle數據庫又推出了一種全新的表空間管理模式即本地托管的管理模式如果把表空間設置為本地托管則這些盤區管理操作都回被重新分配到數據文件的位圖塊上如此的話數據庫的每個標空間都只包含自己的盤區信息可以使用快速散列進程訪問技術來訪問相關系悉尼而不是使用比較慢的基於表的查詢訪問最關鍵的是此時如果有很多帶有很多盤區的表被操作時數據字典將不會成為其性能的瓶頸可見在同等條件下本地托管的性能要比數據字典維護模式的性能要高
一本地托管模式的兩個特性
本地托管模式除了在管理上跟數據字典模式有一定的差異外還提供了兩個比較有特色的選項分別為自動分配與統一分配選項這連個選項主要用來控制將盤區分配到段中的視線方式如把這個方式設置為自動分配的話Oracle數據庫系統會采用一個內部的算法(這個算法數據庫管理員不用了解)在段的大小發生調整時(如段大小增大時)自動增加盤區的大小也就是說使用自動分配選項的話當表空間中的段增大時數據庫系統會根據一定的規則來確定合適的下一個盤區的尺寸這個算法的主要原理就是以盤區數量和擴展比例來作為系數並結合其他的一些參數來進行模擬計算自動分配盤區大小的優勢是很明顯的因為在剛開始部署數據庫系統的時候由於各方面原因的限制要設置一個合理的盤區大小具有一定的困難而現在采用了自動分配的話如果剛開始盤區尺寸設置的太小則數據庫會隨著後續需求的表換而自動增加表的下一盤區尺寸從而可以減少表具有的全部盤區數量這在很大程度上可以提高數據庫的性能另外采用自動分配選項的話還可以保證段的數量不會超出其可以控制的范圍因為數據庫會自動根據實際情況來進行調整
而如果采用統一的盤區管理策略則表空間中的所有盤區都使用在創建表空間時指定的相等大小進行分配而不會考慮到其他因素如不會考慮在段創建語句中設定的存儲子句也不會隨著一些應用情況的改變而調整盤區尺寸的大小顯然如果采用統一分配策略的話那麼在表空間規劃的時候就需要為其設置一個合理的盤區尺寸
那麼有人會說既然統一分配這麼麻煩不會自動調節那就都用自動分配策略好了其實不能夠這麼絕對可以說兩個管理選項各有各的優點自動分配的有點就是即時在表空間建立時沒有設置合理的盤區尺寸那麼在後續數據庫也會根據一定的規則進行自我調整而采用統一分配的好處就是以後若移動或者刪除段時可以更好的重用表空間中的空閒盤區由此產生碎片會很少因為他們都是采用統一的大小筆者的建議是如果一開始根據數據庫管理的經驗可以確定合適的表空間盤區尺寸的那麼最好采用統一的盤區管理策略相反如果不能夠確定的同時刪除段的情況也發生不多時則可以采用自動分配選項以提高數據庫的性能
二將表空間從字典托管模式升級為本地托管模式
如果原有的表空間是字典托管模式的那麼可以在不重新建立表空間的情況下升級到本地托管模式這也就意味著原有表空間中的數據不會丟失如對於SYSTEM系統表空間數據庫系統提供了一個表空間管理模式轉換的應用程序(TableSpace_Migrate_TO_Local)通過這個應用程序可以在不格式化System表空間的情況下將表空間的管理模式從數據字典托管模式升級到本地托管模式
不過像上面這種托管模式的轉換方式其具有一定的局限性如采用這種轉換模式時盤曲映射參數就會移入到表空間的數據文件中必須為表空間中的每個段制定相關的存儲子句此時本地管理模式的兩個管理特性(自動分配策略與盤區尺寸管理策略)就無法使用從而也就無法有效的減少磁盤碎片提高數據庫的性能所以采取這種升級模式的話企業不會從升級中獲得策略方面的改善而且數據庫性能的改善效果也會打折扣
為此筆者推薦的方法是采取比徹底的升級方式即先把需要轉換的表空間中的段導出來進行備份;然後刪除原先的表空間並重新建立(此時把表空間的托管方式設置為本地托管);最後再把原先的段導進去這雖然需要刪除原先大表空間在操作上具有一定的風險但是這種轉換方式卻可以帶來比較高的性能另外為了讓這個方法萬無一失數據庫管理員在進行操作時最好能夠先檢查一下這個段的大小這有利於在後續的操作中減少錯誤的發生另外雖然可以通過種種方式把表空間的管理模式從數據字典托管方式升級到本地托管模式但是最好還是在開始部署數據庫系統的時候就決定好要采用哪種托管模式畢竟在後續進行調整會增加一定的工作量與操作風險而且也會增加數據碎片影響數據庫的性能
三對System表空間轉換模式的限制
在Oracle數據庫中表空間大致分為兩類分別為系統表空間(System表空間)與非系統表空間由於System表空間中存儲著數據庫運行的基本參數為此對其進行表空間升級的話就需要注意一些限制條件只有這些限制條件全部滿足的情況下數據庫管理員才能夠將系統表空間的托管方式從數據字典托管模式轉換為本地托管模式這些限制條件如下(以下只是一些典型的限制條件而不包括全部)
如必須以受限制的模式啟動數據庫數據庫正常啟動時默認情況下不適受限制模式如果要把System表空間模式轉換為本地托管模式的話那麼必須重新啟動數據庫系統並在啟動的時候選擇受限制模式只有在這個模式下才能夠利用上面談到過的TableSpace_Migrate_TO_Local應用程序來進行托管模式的轉換其次數據庫中所有用戶的默認臨時表空間必須是不同於System的表空間其實在數據庫部署的時候筆者多次強調過System表空間的獨立性在建立用戶的時候不要把用戶的默認臨時表空間設置為System表空間這個建議在這個地方就起到作用了另外還必須將計劃進行讀/寫轉換的所有表空間遷移到本地托管的表空間等等
四在升級過程中的注意事項
無論采用數據庫應用程序來進行升級還是通過重建數據表空間來進行升級筆者強烈建議各位數據庫管理員在進行表空間升級之前最好要對數據庫先進性完全備份的工作因為無論采用哪種升級方式都會有一定的風險這就好像動手術一樣無論大小都會有風險就像以前新聞所報道的一個接骨的手術都會導致人死亡所以在升級之前先對數據庫進行完全備份那麼即使升級失敗的情況下也可以利用備份文件把數據庫還原到最新的點
另外在表空間管理模式升級的過程中需要暫時中斷用戶的連接這個中斷的時間需要多長很難估計因為很難保證在升級的過程中不會出現一些意外情況為此在數據庫表空間升級過程中為了保證用戶仍然的日常應用最好選擇在用戶使用人數比較少的時候如果是一般的企業那麼可以選擇晚上或者雙休日來進行表空間的格式轉換以減少數據庫系統的當機時間
最後從目前的大部分應用來看本地托管模式無論從性能上或者從安全上都要比數據字典托管模式要來得強為此數據庫工程師如果不能夠確定該采用哪種模式好的情況下筆者建議在部署數據庫系統的時候就可以選擇采用本地托管模式以免除後續升級的麻煩撇開性能等方面的考慮只從功能上來說兩個托管模式是沒有多少區別的他們的差異只體現在對表空間的管理方法與數據庫的性能上即數據庫底層管理方面的內容而對於數據庫的應用層面沒有影響
From:http://tw.wingwit.com/Article/program/Oracle/201311/17499.html
