兩個SQL Server維護技巧

　　確實數據庫的維護常常交給那些專業的數據庫管理員但是作為一個開發者你也許偶爾需要暫時從事這個工作所以試一試這兩個SQL服務器維護技巧輕松改變數據庫擁有者整理索引碎片誰會想到你甚至可以給那些數據庫管理員教上一兩個新技巧呢？重指定數據庫擁有者
　　當回復或者新建數據庫時你有沒有注意到SQL Server把數據庫的擁有者置為你的NT登錄名？僅僅為了確保不同數據庫間的一致性（更別提安全性因素了）你也許考慮用系統過程sp_changedbowner來把數據庫擁有者改為其它用戶如系統管理員（SA）你也許已經寫了這樣一段腳本用來掃描所有用戶數據庫並把數據庫擁有者重指定為系統管理員
　　
　　系統過程sp_changedbowner有一個參數即@map其缺省值為空（null）該過程可以把數據庫舊有的擁有者的別名重映射為新的數據庫擁有者如系統管理員
　　
　　
　　為了演示該過程讓我們首先建立一個盡可能小的數據庫模型然後運行sp_helpuser指令來看看新創建的用戶名清單
　　
　　
　　CREATE DATABASE test
　　GO
　　USE test
　　GO
　　EXEC sp_helpuser
　　GO
　　
　　這些代碼執行後輸出應該列出數據庫擁有者的清單（db_owner）如果你使用Windows NT認證身份那麼清單中應該有一個NULL的登錄名字和一個SID值
　　
　　然後讓我們加上兩個登錄用戶ISUser和ISUser作為db_owner的別名並把數據庫的擁有者改為系統管理員
　　
　　
　　EXEC sp_addlogin @loginame = ISUser @passwd = ISUser@defdb = master
　　EXEC sp_addlogin @loginame = ISUser @passwd = ISUser@defdb = master
　　EXEC sp_addalias @loginame = ISUser @name_in_db = dbo
　　EXEC sp_changedbowner @loginame = sa @map = TRUE
　　EXEC sp_helpuser
　　
　　輸出內容應該顯示出系統管理員作為db_ownerISUser作為db_owner的別名
　　現在我們用過程sp_changedbowner來指定ISUser為數據庫新的擁有者我們將使用該過程的@map參數並把該參數賦值為否這樣把用戶將為別名
　　
　　
　　EXEC sp_changedbowner @loginame = ISUser @map = FALSE
　　
　　EXEC sp_helpuser
　　GO
　　
　　
　　輸出應該顯示出ISUser現在成為數據庫新的擁有者ISUser降為別名下面我們應該停止這個數據庫並結束本演示過程
　　
　　
　　USE master
　　GO
　　DROP DATABASE test
　　GO
　　
　　
　　用DBCC INDEXDEFRAG命令來實現維護
　　對索引進行維護工作是一件冗長費力的工作不過在SQL Server 中微軟已經引入了一條維護命令DBCC INDEXDEFRAG它相對SQL Server的DBREINDEX命令來說有好幾個優點最主要的優點就是它是一種在線操作這樣在該命令運行期間用戶仍可以連續工作這是因為它不像DBREINDEX那樣在運行時需要鎖定操作所涉及的資源它還可以降低內容阻塞
　　
　　DBCC INDEXDEFRAG操作一小段一小段的數據這樣該操作隨時都可以停止下來並跟蹤它已經完成的工作該操作每隔五分鐘就報告一次估計已完成工作的百分比
　　
　　從技術的角度來看DBCC INDEXDEFRAG從新安排了目標索引所在的當前分配頁上的物理葉當操作完成後目標索引的物理順序與它的邏輯順序相對應因此可以加速索引的掃描速度
　　
　　該操作還重新安排分配分配給目標索引的空間中的其它索引頁SQL Server將會為以一個填充因子為目標根據索引數據的密度和為該索引分配的空間大小來為索引緩沖頁上的空間操作後空下來的頁將會被釋放這就使得索引變得更加緊湊
　　
　　DBCC INDEXDEFRAG也有幾個缺點需要你注意
　　
　　如果一個表格中的兩個索引共享一個盤區的同一個空間而這兩個索引並不相鄰那麼最好重新建立索引讓它們相鄰
　　如果索引中的碎片太多那麼DBCC INDEXDEFRAG命令執行的速度可能要低於 DBREINDEX命令但是如果索引中的碎片不太多那麼DBCC INDEXDEFRAG 應該比DBREINDEX快的多用DBCC INDEXDEFRAG取代DBREINDEX的好處網上有介紹
　　非葉式（nonleaf）索引頁不能重新排序
　　DBCC INDEXDEFRAG不能更新統計數字

From:http://tw.wingwit.com/Article/program/SQLServer/201311/22245.html