SQL Server

誤區 #15:CheckPoint只會將已提交的事務寫入磁碟 錯誤 這個誤區是由於太多人對日誌和恢複系統缺少全面的瞭解而存在已久。CheckPoint會將自上次CheckPoint以來所有在記憶體中改變的頁寫回磁碟(譯者註：也就是髒頁),或是在上一個CheckPoint讀入記憶體的髒頁寫入磁碟。無論事務是否已經提交，其所影響的頁都會在Checkpoint時寫回磁碟。但對於TempDB來說例外，因為TempDB的Checkpoint的事件周期中並不包含將髒頁寫回磁碟的步驟。

這樣還能減少CPU快取命中失效的問題(點擊這個連結來查看CPU的緩衝是如何工作的以及MESI協議)。下面讓我們來揭穿三個有關NULL位元影像的普遍誤區。 誤區 #6a:NULL位元影像並不是任何時候都會用到 正確 就算表中不存在允許NULL的列，NULL位元影像對於資料行來說會一直存在(資料行指的是堆或是叢集索引的葉子節點)。但對於索引行來說（所謂的索引行也就是叢集索引和非叢集索引的非葉子節點以及非叢集索引的葉子節點）NULL位元影像就不是一直有效了。 下面這條語句可以有效證明這一點:

誤區 #13.在SQL Server 2000相容模式下不能使用DMV錯誤 對於相容模式已經存在了很多誤解。80的相容模式的資料庫是否意味著能夠附加或恢複到SQL Server 2000資料庫?當然不是。這隻是意味著一些T-SQL的文法，查詢計劃的行為以及一些其它方面和SQL Server 2000中行為一樣（當然，如果你設定成90相容模式則和SQL Server 2005中一樣）。 在SQL Server 2008中，你可以使用ALTER DATABASE SET

誤區 #21:資料庫損壞可以通過重啟SQL Server或是Windows,或是附加和分離資料庫解決 錯誤 SQL Server中沒有任何一項操作可以修複資料損毀。損壞的頁當然需要通過某種機制進行修複或是恢複-但絕不是通過重啟動SQL Server,Windows亦或是分離附加資料庫。 而實際上，如果你的資料庫的損壞程度無法進行Crash Recovery的話(質疑狀態)，那麼分離附加資料庫將會是你做的最糟糕的決定。這個原理是由於附加資料庫中包含Crash Recovery步驟，如果Crash

理解SQL Server對於記憶體的管理是對於SQL Server問題處理和效能調優的基本，本篇文章講述SQL Server對於記憶體管理的記憶體原理。二級儲存(secondary storage)

誤區 #11:鏡像在檢測到故障後瞬間就能容錯移轉錯誤 資料庫鏡像的容錯移轉既可以自動發起，也可以手動發起。

誤區 #19:Truncate表的操作不會被記錄到日誌 錯誤 在使用者表中的操作都會被記錄到日誌。在SQL Server中唯一不會被記錄到日誌的操作是TempDB中的資料列版本設定。 Truncate

本系列文章是我在sqlskill.com的PAUL的部落格看到的，很多誤區都比較具有典型性和代表性，原文來自T-SQL Tuesday #11: Misconceptions about.... EVERYTHING!!,經過我們團隊的翻譯和整理髮布在AgileSharp和部落格園上。希望對大家有所協助。誤區 #3: 檔案立即初始化特性可以在SQL Server中 a)開啟 和 b)關閉a)是不允許的 b)是允許的 檔案立即初始化是一個在SQL Server

誤區 #9: 資料庫檔案收縮不會影響效能錯誤! 收縮資料庫檔案唯一不影響效能的情況是檔案末尾有剩餘空間的情況下，收縮檔案指定了TruncateOnly選項。 收縮檔案的過程非常影響效能，這個過程需要移動大量資料從而造成大量IO，這個過程會被記錄到日誌從而造成日誌暴漲，相應的，還會佔去大量的CPU資源。 不僅在收縮的過程中影響效能，並且在檔案收縮之後同樣影響應能，收縮產生的大量日誌會被交易記錄傳送，鏡像，複製能操作重複執行。而空間不夠時，檔案還需要填0初始化從而影響效能（

其實我之前已經有文章詳細解釋了頁校正和：How to tell if the IO subsystem is causing corruptions? 誤區 #17:幾個有關頁校正和的誤區坊間流傳的基本是錯誤的 17 a)頁校正和（Page CheckSum）在從SQL Server 2000或7.0升級上來之後自動開啟 其實不是，從舊的執行個體升級上來的資料庫不會自動開啟頁校正和，除非你顯式使用ALTER DATABASE databasename SET PAGE_VERIFY

誤區 #8: 線上索引操作不會使得相關的索引加鎖錯誤！ 線上索引操作並不是想象的那麼美好。 線上索引操作會在操作開始時和操作結束時對資源上短暫的鎖。這有可能導致嚴重的阻塞問題。 線上索引操作開始時,會在被整理的資源上加一個共用的表鎖,這個表鎖在會在新的索引建立時、老索引進行版本掃描時一直持續。

我相信世界總是會向更好的方向發展，今年的維也納新年音樂會沒有往年的明星級指揮，但是它通過迴歸奧地利的本質，以更傳統的彙總法則，讓過往的藝術家們一代代創造的燦爛，在新的指揮手中，迸發出更深邃的音節。在此，也祝大家新年快樂。如同交響樂一樣，構造軟體系統不一定必須某個強大的明星驅動，我們站在曆代ADO.NET的肩膀上，更好地迴歸到SQL Server的核心開發：SQL Server LocalDB 在 ASP.NET中的應用。使用SQL Server LocalDB的優勢：快速部署完整的SQL

問：怎樣才能將XML檔案匯入SQL Server 2000？ 答：將XML檔案匯入SQL Server有若干種方法，這裡提供其中的3種： 大容量裝載COM介面。如果需要將文檔的實體和屬性析取到關係表中，最快的方法就是使用SQL Server 2000 Extensible Markup Language 3.0 Service Pack 1（SQLXML 3.0 SP1）提供的大容量裝載COM介面。大容量狀態COM介面包含在SQLXML 3.0 SP1的免費下載中。

交待：使用的軟硬體環境為Win XP SP2、SQL Server 2000 SP2個人版、普通雙核台式機、1000M區域網路，A機為已使用的伺服器，上面已有資料庫和海量資料，B機為此次新架伺服器，兩機登陸方式均為sql server身分識別驗證模式，其它設定均為預設設定，無特別。A機上另有FTP伺服器，用於程式自動更新。1、在A機上執行Database Backup。2、用A機上備份下來的Database

複製代碼 代碼如下:Create trigger tri_wk_CSVHead_History on wk_CSVHead_History --聲明一個tri_wk_CSVHead_History觸發器， instead of insert ---插入操作被代替執行下面的操作 as begin declare YB cursor --聲明一個遊標 for 　select NoteNO from inserted--這裡的NoteNO要和下面的匹配 　open YB 　　declare

鑒於人手嚴重不足（當時算兩個半人的資源），打消了逐個庫手動去改的念頭。當前的程式結構不允許搞革命的做法，只能搞搞改良，所以準備搞個自動化工具去處理。原型剛開發完，開會的時候以拿出來就遭到營運DBA團隊強烈抵制，具體原因不詳。最後無限延期。這裡把思路分享下。歡迎拍磚。

1. 次序函數與PARTITION BY 複製代碼 代碼如下:--所有資料 SELECT * FROM dbo.student AS a INNER JOIN dbo.ScoreTB AS b ON a.Id = b.stuid WHERE scorename = '語文' ------------------------------------------- --ROW_NUMBER() 的使用 產生列從1開始依次增加 -------------------------------------

視圖是一種常用的資料庫物件，它將查詢的結果以虛擬表的形式儲存在資料中。因為視圖有非常多的優點：1，可以簡化操作，2，可以建立前台和背景緩衝，3，可以合并分割資料，4，最重要的是可以提高安全性，因此在SQL中視圖也佔據著非常重要的地位。在這章的總結中，深刻體會到了，兩種方法：1，企業管理器，2，T-SQL語句來管理檢視，和四種操作：1，增，2,，刪，3，改，4，查。在企業管理器，也是現在的SQL server Management

然而，微軟sql server在處理這類索引時，有個重要的缺陷，那就是把本該編譯成索引seek的操作編成了索引掃描，這可能導致嚴重性能下降 舉個例子來說明問題，假設某個表T有索引 ( cityid, sentdate, userid), 現在有個分頁列表功能，要獲得大於某個多列複合索引V0的若干個記錄的查詢，用最簡單表意的方式寫出來就是 V >= V0, 如果分解開來，就是: cityid > @cityid0 or (cityid = @cityid0 and (sentdate

在設計主鍵的時候往往需要考慮以下幾點： 1.無意義性：此處無意義是從使用者的角度來定義的。這種無意義在一定程度上也會減少資料庫的資訊冗餘。常常有人稱呼主鍵為內部標識，為什麼會這樣稱呼，原因之一在於“內部”，所謂內部從某種程度上來說就是指表記錄，從大的範圍來說就是資料庫，如果你在設計的時候選擇了對使用者來說有意義的資訊來作為主鍵，那麼遲早會面對使用者提出對這塊資訊進行更新的需求，那麼你就違背了它應有的靜態。