SQL 問答集 備份壓縮、 用戶端重新導向，使用鏡像，及其他資訊
Paul S. Randal
問： 我們打算要將大多數的我們的伺服器升級至 SQL Server 2008，而且其中功能我正在向前搜尋以置於實際執行備份的壓縮。 我知道我可以開啟它預設為每個的伺服器上的所有資料庫，但是我也聽說我可能不想要這麼做。 我不確定我不想有預設，啟用 「 功能好像我了任何遺失的原因。 您可以協助說明，背後我的聽說上的原因嗎？
A ： 答案是我 perennial 我的最愛： 視情況而定了 ！ 我要提供一些背景說明。
要考慮的重點在比例即壓縮備份的壓縮啟用時，會造成每個資料庫備份的比率。 任何由任何演算法壓縮的壓縮比率是由實際的資料壓縮決定的。
尋找 SQL Server 的秘訣嗎？
在 SQL Server 上的提示，請造訪， TechNet Magazine 》 的 SQL Server 祕訣 頁面。
如需其他產品的更多秘訣，造訪， TechNet Magazine 秘訣索引.
隨機資料 (小整數值，執行個體) 會未壓縮很，因此，資料表和資料庫中的索引的內容會判斷，大部分，可達到的壓縮比率。
備份的壓縮可能不會產生高壓縮比率時，這裡要是的一些範例)：
- 資料庫是否啟用透明化的資料加密就壓縮比率會非常低因為資料壓縮是隨機小的值。
- 如果大部分資料庫中的資料在資料行層級加密，就壓縮比率會低，再因為資料行的加密，基本上是 randomizes 資料。
- 資料庫中的大部分的資料表有啟用資料壓縮再壓縮比例低 ； 壓縮已大部分通常是壓縮的資料有小的效果。
在的情況下，壓縮比率不足時問題不是低的比例，但事實上 CPU 資源用來執行未獲得壓縮演算法。 無論您如何可以壓縮的資料區塊，CPU 資源永遠都用來執行壓縮與解壓縮演算法。
這表示您需要檢查以及每個資料庫壓縮在備份之前，先決定要備份的壓縮的資料庫一直在使用中。 否則您可能會可能會浪費 CPU 資源。 這是您的聽說在基礎。
若要摘要，如果大部分的資料庫會有所裨益備份的壓縮，合理啟用在伺服器層級備份的壓縮，並在手動變更一些備份工作，特別是使用 WITH NO_COMPRESSION 選項。 或者，如果大部分的資料庫會不裨益備份的壓縮，合理離開已關閉，在伺服器層級備份的壓縮，並在手動變更一些備份工作，特別是使用 WITH 壓縮選項。
問： 最後一個年份我們升級資料庫將資料庫的鏡像，這樣在失敗發生我們可以容錯移轉至鏡像] 和 [應用程式會繼續。 每一位時，我們已在設計系統，我們學會進行容錯移轉資料庫和所有正常運作。 最後一週有實際的失敗和容錯移轉資料庫，發生不過當所有停止的應用程式交易和應用程式未將它連接容錯移轉伺服器到。 在未來我如何設定 SQL Server 以便在它不會在容錯移轉期間卸除應用程式連線讓交易可以繼續？
A 讓我這細分為兩個部份 — 如何應用程式可以應付容錯移轉，以及管理與資料庫鏡像的用戶端重新導向。
當容錯移轉發生時與 SQL Server 中使用任何可用的高可用性技術時，請失敗的伺服器，用戶端連線已中斷，而且任何 「 執行中 」 的交易都會遺失。 不可能將伺服器之間的 「 執行中 」 交易 (在容錯移轉的情況下或其他)。 根據在高可用性的技術 「 執行中 」 的交易可能會不存在完全在容錯移轉伺服器上或它將會存在的 「 執行中 」 的交易，但將會復原做為程序，將容錯移轉伺服器上的線上資料庫的一部分。
與持續隨附鏡像伺服器，從主要伺服器交易記錄檔記錄的資料庫鏡像，考慮它通常是後者的情況下，任何 「 執行中 」 的交易會復原做為部分將鏡像資料庫線上為新的主體。
因此，有兩件事，應用程式必須能夠容錯移轉到另一個伺服器，可能需要使用伺服器上執行時，會適當地執行：
- 它必須能夠適當地處理被丟棄，伺服器連線，然後再在小型的時間間隔之後重新連線。
- 它必須能夠適當地處理正在中止交易，並再重試連線之後，交易建立與容錯移轉伺服器 (可能使用 mid-tier 的交易管理員)。
只高可用性技術以下，不需要用戶端對特別允許用戶端連線，在容錯移轉後的重新導向是容錯移轉叢集。 用戶端會連線到虛擬伺服器名稱，並會透明地重新導向至任何實體的叢集節點正在使用中。
高可用性的技術，例如記錄傳送和複寫，伺服器的名稱在容錯移轉伺服器是不同，這表示，手動在容錯移轉後的用戶端連線的重新導向所。 可以完成這個手動重新導向，有數種：
- 因此，重新連線嘗試容錯移轉伺服器，您可以插入用戶端硬編碼容錯移轉的伺服器名稱。
- 您可以使用網路負載平衡與 100 / 0-0 / 100 組態會再允許連線到容錯移轉伺服器可以切換。
- 您可以使用一個伺服器名稱的別名或切換項目 DNS 資料表中的項目。
與資料庫對映功能的任何這些選項將運作。 但資料庫鏡像也有內建的用戶端方向的功能。 用戶端的連接字串能夠明確指定名稱的鏡像伺服器，而且，如果主體伺服器無法連絡，鏡像會再自動嘗試。 這個程序稱為明確重新導向)。
如果無法變更用戶端的連接字串，再隱含的重新導向可能可以如果失敗的伺服器現在以鏡像伺服器的方式執行。 將任何連線會被重新自動導向至新的主體 — 但這只能如果鏡像伺服器執行。
SQL Server 2005 白皮書 ＜ 實作應用程式與資料庫鏡像的容錯移轉「 說明這些選項更詳細的說明。
重新 Q 時，我們升級至 SQL Server 2005，我們設計我們的大型資料表進行分割，如此，我們可以利用資料分割的維護和滑動-視窗的機制。 您在 8 月 2008 單元說明這 (」 磁碟分割、 一致性檢查，及其他"). 但我們已經發生的問題。 有時候，同時的應用程式的查詢發生查詢即使不存取相同的磁碟分割時，封鎖在整個資料表。 我聽說 SQL Server 2008 會修正這個問題 — 可以請解釋如何我可以停止這個封鎖？
[圖 1) 檢查在分割資料表上的鎖定
A ： 問題您正在查看由造成一種機制，稱為鎖定擴大規模。 SQL Server 會取得鎖定，查詢是讀取或寫入資料時保護它們的資料。 它可以取得整個資料表、 資料檔案的頁面或個別的資料表 / 索引的資料列上的鎖定，並會佔用一些記憶體的每個鎖定]。
如果查詢會造成太多要取得的鎖定，SQL Server 可以決定取代整個資料表上使用單一鎖定的資料列或資料表中的頁面上的所有鎖定 (閾值，這發生時，大約 5000 位鎖定但確切的演算法且複雜設定)。 這個程序稱為鎖定擴大規模。
在 SQL Server 2005，如果查詢 A 資料表的單一磁碟分割上運作，而且會導致要採取以觸發鎖定擴大規模，不足，無法鎖定再整個資料表會變成鎖定。 這可以防止查詢 B 能夠在相同資料表的不同的磁碟分割上操作。 因此，查詢 B 也會封鎖直到查詢 A 完成，並將其鎖定會被捨棄。
在 SQL Server 2008 中, 已經過改良，鎖定擴大規模機制允許將磁碟分割的層級鎖定擴大規模的資料表。 使用上述範例，這表示因 A 只會鎖定使用 A，而不是整個資料表的單一磁碟分割查詢的查詢，鎖定擴大規模。
查詢 B 將然後可以在另一個磁碟分割上不被封鎖的操作。 查詢 B 可能甚至觸發鎖定擴大規模本身，會再鎖定只在磁碟分割的 B，運作而不是整個資料表的查詢。
可以設定鎖定擴大規模的這個模型，使用下列語法：
ALTER TABLE MyTable SET (LOCK_ESCALATION = AUTO);
GO
這個語法會指示 SQL Server 鎖定管理員，使用磁碟分割的層級鎖定擴大規模，資料表如果未資料分割資料表會分割和規則資料表層級鎖定擴大規模。 預設行為是使用資料表層級鎖定擴大規模。 當設定這個選項中，因為它可能會導致死結，視您查詢的行為時，應採取小心。
例如，如果查詢 A 和 B 兩者都造成鎖定擴大規模上一個的資料表的不同部分，但它們每一個嘗試存取已鎖定的其他查詢磁碟分割的再查詢的其中一個將會中止的死結監視器處理序。
圖會顯示範例查詢，sys.partitions 系統類別目錄檢視 」 (第一組的結果)，並在 sys.dm_os_locks DMV (第二組結果)，來檢查，正在持有鎖定的查詢針對分割的資料表的磁碟分割的層級鎖定擴大規模發生。 在這種情況下，有兩個層級的磁碟分割獨佔鎖定 (HOBT 鎖定在輸出中)，但資料表鎖定，物件鎖定在輸出中不獨佔，讓多個查詢可以存取磁碟分割，即使發生鎖定擴大規模。 請注意這些兩個磁碟分割的鎖定的資源 ID 符合 sys.partitions 從輸出中資料表的前兩個磁碟分割，磁碟分割識別碼。
今年稍早我 blogged 相關的範例指令碼顯示如何 磁碟分割的層級鎖定擴大規模的運作方式並可能的死結 (Deadlock)。 SQL Server 2008 線上叢書 》 中的主題時呼叫 」 鎖定資料庫引擎「 有 SQL Server 2008 中鎖定的所有層面的深入說明。
問： 一我們的伺服器的一些問題與磁碟保留一個的資料庫交易記錄檔並且資料庫成為可疑。 已五週前，從的最新完整備份，並它要花費太長的時間太還原所有記錄檔備份，]。 它不的問題發生時的時間，因此我們重建損毀的交易記錄以避免在停機時間。 在某些的情況下，這可能造成問題。 但是如果執行任何動作時存取資料，然後我認為我們安全。 我們正在執行正確的動作沒有嗎？
A ： 簡單的答案是，我會考慮重建為交易記錄檔時很不可能從備份中復原。 雖然您知道的重建交易記錄檔 (如的讀者是會不，請參閱我的部落格張貼，「 危險性 最後一個 Resorts 人員先嘗試..."事實上資料庫發生可疑表示它無法在復原期間 — 時執行損毀修復或時復原交易。 這表示實際的資料庫中的資料損毀發生的可能。
雖然您無訊息的期間發生的問題，沒有您考慮排程的工作和背景工作嗎？ 維護工作可能已執行的是重建或重新組織成為損毀的記錄檔時，叢集的索引。 背景工作可能執行準刪除清除堆積或叢集的索引中的頁面上。 其中，例如，無法有已變更，如果無法正確地復原，會導致資料庫和可能的資料遺失的損毀的叢集的索引結構。
底線是重建為交易記錄檔應該永遠都是絕對的最後手段在任何嚴重損壞修復案例，因為以龐大可能造成更多的損毀和資料遺失。 在至少，您應該檢查是否存在任何損毀的資料庫上執行完整的 DBCC CHECKDB。
向前移動您應該變更您的備份策略，讓您能夠執行及時還原，以及不需要依靠激烈的量值，例如交易記錄檔重新建立。 在設計備份策略的步驟超出此的資料行的範圍，但我打算涵蓋這個主題，在 「 full-length 功能有時候在未來的年度中。 請保持調整 ！
Paul Randal S。 是管理的 Director SQLskills.com及一個 SQL Server MVP。 SQL Server 儲存引擎小組在 Microsoft 自 1999 年 2007 HeHe 處理。 Paul 撰寫 SQL Server 2005 的 DBCC CHECKDB / 修復並且負責核心的儲存引擎在 SQL Server 2008 開發期間。 Paul 是在嚴重損壞修復、 高的可用性和維護資料庫的專家，也是一般在世界的會議主持人。 在他的部落格 SQLskills.com/blogs/Paul.