確實，數據庫的維護常常交給那些專業的數據庫管理員，但是作為一個開發者，你也許偶爾需要暫時從事這個工作。所以，試一試這兩個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值。
然後，讓我們加上兩個登錄用戶：ISUser1和ISUser2作為db_owner的別名，並把數據庫的擁有者改為系統管理員：
EXEC sp_addlogin @loginame = 'ISUser1', @passwd = 'ISUser1',@defdb = 'master'
EXEC sp_addlogin @loginame = 'ISUser2', @passwd = 'ISUser2',@defdb = 'master'
EXEC sp_addalias @loginame = 'ISUser1', @name_in_db = 'dbo'
EXEC sp_changedbowner @loginame = 'sa', @map = 'TRUE'
EXEC sp_helpuser
輸出內容應該顯示出系統管理員作為db_owner、ISUser1作為db_owner的別名。
現在我們用過程sp_changedbowner來指定ISUser2為數據庫新的擁有者。我們將使用該過程的@map參數並把該參數賦值為“否”，這樣把用戶將為別名。
EXEC sp_changedbowner @loginame = 'ISUser2', @map = 'FALSE'
EXEC sp_helpuser
GO
輸出應該顯示出ISUser2現在成為數據庫新的擁有者，ISUser1降為別名。下面，我們應該停止這個數據庫並結束本演示過程。
USE master
GO
DROP DATABASE test
GO
用DBCC INDEXDEFRAG命令來實現維護
對索引進行維護工作是一件冗長費力的工作，不過在SQL Server 2000中，微軟已經引入了一條維護命令DBCC INDEXDEFRAG，它相對SQL Server7.0的DBREINDEX命令來說，有好幾個優點。最主要的優點就是它是一種在線操作，這樣，在該命令運行期間用戶仍可以連續工作。這是因為它不像DBREINDEX那樣在運行時需要鎖定操作所涉及的資源，它還可以降低內容阻塞。
DBCC INDEXDEFRAG操作一小段、一小段的數據，這樣該操作隨時都可以停止下來並跟蹤它已經完成的工作。該操作每隔五分鐘就報告一次估計已完成工作的百分比。
從技術的角度來看，DBCC INDEXDEFRAG從新安排了目標索引所在的當前分配頁上的物理葉。當操作完成後，目標索引的物理順序與它的邏輯順序相對應，因此可以加速索引的掃描速度。
該操作還重新安排分配分配給目標索引的空間中的其它索引頁。SQL Server將會為以一個填充因子為目標、根據索引數據的密度和為該索引分配的空間大小，來為索引緩沖頁上的空間。操作後空下來的頁將會被釋放，這就使得索引變得更加緊湊。
DBCC INDEXDEFRAG也有幾個缺點需要你注意：
如果一個表格中的兩個索引共享一個盤區的同一個空間，而這兩個索引並不相鄰，那麼最好重新建立索引讓它們相鄰。
如果索引中的碎片太多，那麼DBCC INDEXDEFRAG命令執行的速度可能要低於 DBREINDEX命令；但是如果索引中的碎片不太多，那麼DBCC INDEXDEFRAG 應該比DBREINDEX快的多，用DBCC INDEXDEFRAG取代DBREINDEX的好處網上有介紹。
非葉式（nonleaf）索引頁不能重新排序。
DBCC INDEXDEFRAG不能更新統計數字。
