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