問：我們當前的 raid 很快就填滿了，因此需要將一些 sql server 2005 資料庫移到其他位置。新陣列已準備就緒，並且我一直在為移動資料庫作準備。我剛剛發現其中乙個資料庫是事務複製發布伺服器，我知道這表示我不能移動該資料庫。我應怎樣做？
答：對您來說有乙個好訊息 － 只有 sql server 2000（和更早版本）具有以下侷限性：限制在未重新初始化事務複製或直接更改各種系統表的情況下移動發布資料庫。
對於 sql server 2005 和 sql server 2008，有乙個記錄下來的過程，您可以按照它移動資料庫，而不必對事務複製執行任何操作，但要求資料庫保持連線到同一 sql server 例項。移動時必須停機一段時間，因為當資料庫檔案仍處於聯機狀態時無法將其移動。過程如下：
首先，使用下面的**使資料庫離線。如果有使用者連線到資料庫，則需要先斷開這些使用者的連線，此過程才能成功：
複製**
alter database mydatabasename set offline;
接著，將資料檔案複製到新位置。使用複製而不是移動，可在發生任何錯誤時進行快速回滾（否則，必須執行還原）。然後，使用以下**告知 sql server 每個檔案的新位置：
複製**
alter database mydatabasenamemodify file
(name = n'logicalfilename',
filename = n'pathname/filename');
物理上覆制了所有檔案並更新了 sql server 中的檔案位置後，使用以下**使資料庫恢復聯機狀態：
複製**
alter database mydatabasename set online;
問：我在理解一些效能優化相關概念時存在疑問。我幾次讀到需要防止「頁鎖存」問題。我不知道「頁」或「鎖存」是什麼意思，或者說為什麼頁鎖存甚至是乙個問題。您能解釋所有這些疑問嗎？
答：sql server 資料庫中的所有資料都儲存在資料檔案中。在內部，這些檔案組織成大小為 8 kb 的資料塊序列，稱為頁。頁是 sql server 可以管理的基本儲存和 i/o 單位。頁通常位於磁碟上的資料檔案中，並且在處理任何查詢之前，需要 sql server 的快取（稱為緩衝池）來進行讀取。
sql server 使用各種頁來儲存不同型別的關係資料（例如，表中的行、非群集索引中的行或者文字/lob 資料）。還有一些頁儲存 sql server 組織和訪問儲存關係資料的頁所需的內部資料結構部分。
鎖存 是一種輕量級內部機制，sql server 使用它來同步對快取內的某個頁的訪問。您需要注意兩種型別的頁鎖存 － 常規頁鎖存 和頁 i/o 鎖存。如果 sql server 執行緒必須等待獲取其中乙個鎖存，則表示出現效能問題。
當 sql server 正等待從磁碟中讀取資料檔案的某部分時，則可能會導致頁 i/o 鎖存等待。如果頁 i/o 鎖存持續很長時間，則通常表明底層磁碟子系統出現效能問題（即，該子系統過載）。
當 sql server 中的多個執行緒嘗試訪問記憶體中的相同 8 kb 資料檔案頁時，就存在對該頁訪問權的爭用，這可能會導致頁鎖存等待。最常見的這種情況涉及大量使用 tempdb 資料庫中的臨時小物件。
問：我剛剛發現了資料庫快照。現在，我考慮將它們用作完全恢復模式和日誌備份的替代方法。我將大約每小時建立一次快照，這樣當出現錯誤時，我可以拉回損壞的資料。這似乎是一種更省事且更快的還原方法。您認為進行這種更改會產生任何問題嗎？
答：會產生問題，資料庫快照不是全面的災難恢復策略的實用或可行替代方法。在從災難完全恢復方面，資料庫快照不具備與事務日誌備份相同的功能。資料庫快照不包含資料庫中所有頁的副本，它只包含自第一次建立資料庫後更改過的頁的副本。這意味著，如果資料庫有任何損壞，則沒有底層資料庫的資料庫快照將沒有任何用處。它只是資料庫中不同頁的集合，不能用於恢復。
您可以通過資料庫快照拉回不小心從資料庫中刪除的資料，但前提是資料庫本身仍可用。例如，如果從資料庫中刪除的表仍存在於快照中，則可以使用快照重新建立該錶。
也就是因為潛在的效能問題，建立太多資料庫快照（作為每乙個半小時的事務日誌備份的替代方法）不是乙個好主意。在可以交換資料庫頁之前（請參閱「關閉頁鎖存」部分中的答案說明），必須先將頁同步地複製到尚未包含該頁版本的所有現有資料庫快照中。隨著建立的資料庫快照越來越多，要生成的頁副本也越來越多，從而導致效能下降。
不要建立太多資料庫快照的另乙個原因是每個資料庫快照將包含資料庫頁更改前的副本。每個副本將隨著資料庫中更改的內容增多而增大。這可能會導致磁碟空間問題和效能問題。
資料庫快照不是為了替代頻繁日誌備份而設計的。您可以在*** database snapshot performance considerations under i/o-intensive workloads
中閱讀關於資料庫快照的效能影響的更深入研究。
此外，如果您要使用完全恢復模式和事務日誌備份，則很明顯您對最多能夠恢復到災難點和/或使用時間點還原感興趣。（有關恢復到災難點和時間點還原的說明，請分別參閱我於 2009 年 7 月和 2009 年 11 月發布的文章「了解 sql server 備份
」和「sql server：利用備份進行災難恢復
」。）問：我被要求為資料庫設定資料庫映象，但我擔心資料庫映象不能幫助解決我們的問題。我們的 san 存在一些損壞問題，因此打算通過資料庫映象防止我們受到損壞。損壞不會自動傳送到映象嗎？資料庫映象如何幫助我們解決此問題？
答：這是乙個會引起大量混淆的問題。任何提供冗餘資料庫副本的技術看起來似乎都容易受到從主體傳播到映象資料庫（以使用資料庫映象術語）的損壞的影響，但實際上這種情況不會發生。
問題的關鍵在於理解映象資料庫的維護方式。如果底層同步機制將完整資料庫頁從主體複製到映象資料庫，則損壞肯定會傳播到映象。然後，主體中損壞的頁將被放置在映象中。
但是，資料庫映象專門避免了這種情況，因為它不將乙個資料庫中的資料庫頁複製到另乙個資料庫。資料庫映象過程是將事務日誌記錄從主體資料庫複製到映象來完成的。事務日誌記錄說明對資料庫頁所做的物理更改，它們不包含實際頁本身。（有關事務日誌記錄、日誌記錄和恢復的完整說明，請參閱我於 2009 年 2 月發布的文章：「了解 sql server 中的日誌記錄和恢復功能
。」）即使資料庫頁被主體資料庫的底層 i/o 子系統損壞，該損壞也不可能直接傳播到映象資料庫。可能出現的最壞情況是如果 sql server 未檢測到頁面損壞（由於未啟用頁面校驗和），將使用已損壞的列值來計算儲存在資料庫中的值。生成的不正確結果將傳播到映象資料庫，從而產生二級損壞效果。如前所述，如果啟用了頁面校驗和，則從磁碟中讀取頁面時，這種損壞仍將檢測不到，從而不會出現二級損壞。
此行為還說明了為什麼對主體資料庫執行一致性檢查不會生成關於映象資料庫的一致性狀態的任何資訊，反之亦然。它們是通過傳送對資料庫而不是實際資料庫頁的物理更改的說明來保持同步的兩個不同資料庫。
paul s. randal是 sqlskills.com
的總裁、microsoft 區域總監和 sql server 的 mvp。從 1999 年到 2007 年，他一直在 microsoft 的 sql server 儲存引擎團隊工作。他曾編寫過 dbcc checkdb/repair for sql server 2005，並在 sql server 2008 的開發過程中負責核心儲存引擎部分的工作。randal 是災難恢復、高可用性和資料庫維護方面的專家，經常在全球出席一些會議。您可以訪問他的部落格 sqlskills.com/blogs/paul
，也可以通過 twitter (twitter.com/paulrandal) 了解他。
資料庫效能優化
資料庫設計 實現sql server資料庫的優化，首先要有乙個好的資料庫設計方案。在實際工作中，許多sql server方案往往是由於資料庫設計得不好導致效能很差。實現良好的資料庫設計必須考慮這些問題 1.邏輯資料庫規範化問題 一般來說，邏輯資料庫設計會滿足規範化的前3級標準 第1規範 沒有重複的組...
資料庫效能優化
1 系統設計 1 縱向 橫向分割表，減少表的尺寸 縱向 欄位多。按業務主題分割。根據頁大小。橫向 資料多。按條件分割表。eg 按年儲存表，歷史資料表和當期資料更新表。2 將資料處理交給db，編寫儲存過程 1 減少網路的開銷 2 儲存過程是編譯 優化過，速度快。3 唯讀查詢操作優化方法 1 資料量小的...
資料庫效能優化
最近要寫一些關於企業級應用的優化內容的東西，就先從資料庫優化入手吧，在這裡先記錄一下。作為一名有資料庫教育背景的工作人員，我著重從db的角度介紹一下，我認為的db優化方式。首先，撇開經濟商業用處不談，db效能優化的原則主要是，通過盡可能少的磁碟訪問獲得所需的資料。一般而言，資料的是優化可以從三方面分...