㈠ 如何處理sql Server死鎖問題
死鎖，簡而言之，兩個或者多個trans，同時請求對方正在請求的某個對象，導致雙方互相等待。簡單的例子如下：
trans1 trans2
------------------------------------------------------------------------
1.IDBConnection.BeginTransaction 1.IDBConnection.BeginTransaction
2.update table A 2.update table B
3.update table B 3.update table A
4.IDBConnection.Commit 4.IDBConnection.Commit
那麼，很容易看到，如果trans1和trans2，分別到達了step3，那麼trans1會請求對於B的X鎖，trans2會請求對於A的X鎖，而二者的鎖在step2上已經被對方分別持有了。由於得不到鎖，後面的Commit無法執行，這樣雙方開始死鎖。
好，我們看一個簡單的例子，來解釋一下，應該如何解決死鎖問題。
-- Batch #1
CREATE DATABASE deadlocktest
GO
USE deadlocktest
SET NOCOUNT ON
DBCC TRACEON (1222, -1)
-- 在SQL2005中，增加了一個新的dbcc參數，就是1222，原來在2000下，我們知道，可以執行dbcc
--traceon(1204,3605,-1)看到所有的死鎖信息。SqlServer 2005中，對於1204進行了增強，這就是1222。
GO
IF OBJECT_ID ('t1') IS NOT NULL DROP TABLE t1
IF OBJECT_ID ('p1') IS NOT NULL DROP PROC p1
IF OBJECT_ID ('p2') IS NOT NULL DROP PROC p2
GO
CREATE TABLE t1 (c1 int, c2 int, c3 int, c4 char(5000))
GO
DECLARE @x int
SET @x = 1
WHILE (@x <= 1000) BEGIN
INSERT INTO t1 VALUES (@x*2, @x*2, @x*2, @x*2)
SET @x = @x + 1
END
GO
CREATE CLUSTERED INDEX cidx ON t1 (c1)
CREATE NONCLUSTERED INDEX idx1 ON t1 (c2)
GO
CREATE PROC p1 @p1 int AS SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
GO
CREATE PROC p2 @p1 int AS
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1
GO
上述sql創建一個deadlock的示範資料庫，插入了1000條數據，並在表t1上建立了c1列的聚集索引，和c2列的非聚集索引。另外創建了兩個sp，分別是從t1中select數據和update數據。
好，打開一個新的查詢窗口，我們開始執行下面的query：
-- Batch #2
USE deadlocktest
SET NOCOUNT ON
WHILE (1=1) EXEC p2 4
GO
開始執行後，然後我們打開第三個查詢窗口，執行下面的query：
-- Batch #3
USE deadlocktest
SET NOCOUNT ON
CREATE TABLE #t1 (c2 int, c3 int)
GO
WHILE (1=1) BEGIN
INSERT INTO #t1 EXEC p1 4
TRUNCATE TABLE #t1
END
GO
開始執行，哈哈，很快，我們看到了這樣的錯誤信息：
Msg 1205, Level 13, State 51, Procere p1, Line 4
Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
spid54發現了死鎖。
那麼，我們該如何解決它？
在SqlServer 2005中，我們可以這么做：
1.在trans3的窗口中，選擇EXEC p1 4，然後right click，看到了菜單了嗎？選擇Analyse Query in Database Engine Tuning Advisor。
2.注意右面的窗口中，wordload有三個選擇：負載文件、表、查詢語句，因為我們選擇了查詢語句的方式，所以就不需要修改這個radio option了。
3.點左上角的Start Analysis按鈕
4.抽根煙，回來後看結果吧！出現了一個分析結果窗口，其中，在Index Recommendations中，我們發現了一條信息：大意是，在表t1上增加一個非聚集索引索引：t2+t1。
5.在當前窗口的上方菜單上，選擇Action菜單，選擇Apply Recommendations，系統會自動創建這個索引。
重新運行batch #3，呵呵，死鎖沒有了。
這種方式，我們可以解決大部分的Sql Server死鎖問題。那麼，發生這個死鎖的根本原因是什麼呢？為什麼增加一個non clustered index，問題就解決了呢？ 這次，我們分析一下，為什麼會死鎖呢？再回顧一下兩個sp的寫法：
CREATE PROC p1 @p1 int AS
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
GO
CREATE PROC p2 @p1 int AS
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1
GO
很奇怪吧！p1沒有insert，沒有delete，沒有update，只是一個select，p2才是update。這個和我們前面說過的，trans1裡面updata A，update B；trans2裡面upate B，update A，根本不貼邊啊！
那麼，什麼導致了死鎖？
需要從事件日誌中，看sql的死鎖信息：
Spid X is running this query (line 2 of proc [p1], inputbuffer 「… EXEC p1 4 …」):
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
Spid Y is running this query (line 2 of proc [p2], inputbuffer 「EXEC p2 4」):
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
The SELECT is waiting for a Shared KEY lock on index t1.cidx. The UPDATE holds a conflicting X lock.
The UPDATE is waiting for an eXclusive KEY lock on index t1.idx1. The SELECT holds a conflicting S lock.
首先，我們看看p1的執行計劃。怎麼看呢？可以執行set statistics profile on，這句就可以了。下面是p1的執行計劃
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
|--Nested Loops(Inner Join, OUTER REFERENCES:([Uniq1002], [t1].[c1]))
|--Index Seek(OBJECT:([t1].[idx1]), SEEK:([t1].[c2] >= [@p1] AND [t1].[c2] <= [@p1]+(1)) ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[t1].[c1] AND [Uniq1002]=[Uniq1002]) LOOKUP ORDERED FORWARD)
我們看到了一個nested loops，第一行，利用索引t1.c2來進行seek，seek出來的那個rowid，在第二行中，用來通過聚集索引來查找整行的數據。這是什麼？就是bookmark lookup啊！為什麼？因為我們需要的c2、c3不能完全的被索引t1.c1帶出來，所以需要書簽查找。
好，我們接著看p2的執行計劃。
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
|--Clustered Index Update(OBJECT:([t1].[cidx]), OBJECT:([t1].[idx1]), SET:([t1].[c2] = [Expr1004]))
|--Compute Scalar(DEFINE:([Expr1013]=[Expr1013]))
|--Compute Scalar(DEFINE:([Expr1004]=[t1].[c2]+(1), [Expr1013]=CASE WHEN CASE WHEN ...
|--Top(ROWCOUNT est 0)
|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[@p1]) ORDERED FORWARD)
通過聚集索引的seek找到了一行，然後開始更新。這里注意的是，update的時候，它會申請一個針對clustered index的X鎖的。
實際上到這里，我們就明白了為什麼update會對select產生死鎖。update的時候，會申請一個針對clustered index的X鎖，這樣就阻塞住了（注意，不是死鎖！）select裡面最後的那個clustered index seek。死鎖的另一半在哪裡呢？注意我們的select語句，c2存在於索引idx1中，c1是一個聚集索引cidx。問題就在這里！我們在p2中更新了c2這個值，所以sqlserver會自動更新包含c2列的非聚集索引：idx1。而idx1在哪裡？就在我們剛才的select語句中。而對這個索引列的更改，意味著索引集合的某個行或者某些行，需要重新排列，而重新排列，需要一個X鎖。
SO………，問題就這樣被發現了。
總結一下，就是說，某個query使用非聚集索引來select數據，那麼它會在非聚集索引上持有一個S鎖。當有一些select的列不在該索引上，它需要根據rowid找到對應的聚集索引的那行，然後找到其他數據。而此時，第二個的查詢中，update正在聚集索引上忙乎：定位、加鎖、修改等。但因為正在修改的某個列，是另外一個非聚集索引的某個列，所以此時，它需要同時更改那個非聚集索引的信息，這就需要在那個非聚集索引上，加第二個X鎖。select開始等待update的X鎖，update開始等待select的S鎖，死鎖，就這樣發生鳥。
那麼，為什麼我們增加了一個非聚集索引，死鎖就消失鳥？我們看一下，按照上文中自動增加的索引之後的執行計劃：
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
|--Index Seek(OBJECT:([deadlocktest].[dbo].[t1].[_dta_index_t1_7_2073058421__K2_K1_3]), SEEK:([deadlocktest].[dbo].[t1].[c2] >= [@p1] AND [deadlocktest].[dbo].[t1].[c2] <= [@p1]+(1)) ORDERED FORWARD)
哦，對於clustered index的需求沒有了，因為增加的覆蓋索引已經足夠把所有的信息都select出來。就這么簡單。
實際上，在sqlserver 2005中，如果用profiler來抓eventid：1222，那麼會出現一個死鎖的圖，很直觀的說。
下面的方法，有助於將死鎖減至最少（詳細情況，請看SQLServer聯機幫助，搜索：將死鎖減至最少即可。
按同一順序訪問對象。
避免事務中的用戶交互。
保持事務簡短並處於一個批處理中。
使用較低的隔離級別。
使用基於行版本控制的隔離級別。
將 READ_COMMITTED_SNAPSHOT 資料庫選項設置為 ON，使得已提交讀事務使用行版本控制。
使用快照隔離。
使用綁定連接。
㈡ DBA30問之系統DB有哪些,都有什麼作用,需不需要做備份,為什麼,損壞了如何做還原(主要是master庫)
這包括實例范圍的元數據(例如登錄帳戶)、 端點、鏈接伺服器和系統配置設置。此外，master資料庫還記錄了所有其他資料庫的 存在、資料庫文件的位置以及SQLServer 的初始化信息。因此，如果master資料庫 不可用，則SQLServer 無法啟動。在SQLServer中，系統對象不再存儲在master 資料庫中，而是存儲在mssqlsystemresource資料庫中。 master資料庫對系統來說很關鍵，因此總是要保存它的當前副本。創建另一個資料庫， 改變配置值，修改登錄賬戶這樣的操作都會修改master資料庫，所以總是應該在完成 這些操作之後備份master資料庫。master資料庫本身不大，做一次備份很快，建議經 常做master資料庫的備份。 由於master資料庫還記錄啟動伺服器實例所需要的初始化信息，每個其他資料庫的主文 件位置。master資料庫是SQLServer啟動的時候打開的第一個資料庫。SQLServer是從 master資料庫找到的其他資料庫的信息。如果master資料庫存在問題，整個SQLServer 都無法正常啟動。 如果說是master資料庫嚴重損壞，如果有備份直接還原master資料庫即可。如果沒有備 份，則需要重建master資料庫。重建master資料庫將使所有的系統資料庫恢復到原始狀 態。重建master資料庫會刪除並重建msdb資料庫。這將導致丟失所有計劃信息以及備份 和還原歷史記錄。重建master資料庫之後，SQLServer資料庫就好比重新安裝後一樣， 所有用戶信息都會丟失，用戶資料庫需要重新附加，SQLServer任務和計劃都要重建。 因此重建master資料庫是個萬不得已的選擇。 在執行任何語句或系統過程來更改master資料庫中的信息以後,應備份master資料庫. 建議不要再master資料庫中創建用戶對象 導致master資料庫更新並要求備份的操作類型包括: 1,創建或刪除用戶資料庫 2,添加或刪除文件和文件組 3,添加登陸或其他登陸安全相關操作 4,更改伺服器范圍的配置選項或者資料庫配置選項 5,創建或刪除邏輯備份文件 6,配置用於分布式查詢和遠程調用的伺服器,如添加鏈接伺服器或遠程登錄 恢復master資料庫使用的還是RESTORE指令.還原master資料庫後SQLServer實例將自動停止. 關於如何恢復master資料庫,在後面將單獨寫一篇博客. model資料庫 用作在SQLServer實例上創建的所有資料庫的模板。因為每次啟動SQLServer 時都 會創建tempdb，所以model資料庫必須始終存在於 SQLServer系統中。 創建資料庫是model資料庫是SQLSERVER使用的模板.model資料庫里的全部內容都會被復 制到新的資料庫.所以這個資料庫不建議做任何修改.除非是有目的的要建立一些模板. 雖然這個資料庫的內容一般不會發生改變,但是在SQLServer啟動的時候要使用model數 據庫某些設置創建新的tempdb。如果沒有tempdb，SQLServer無法啟動。因此model資料庫 必須存在SQLServer系統中。這個資料庫也要有備份。 還原model資料庫與對用戶資料庫執行完整的資料庫還原相同 tempdb資料庫 tempdb系統資料庫是一個全局資源，可供連接到SQLServer 實例的所有用戶使用，並 可用於保存下列各項： 顯式創建的臨時用戶對象，例如全局或局部臨時表、臨時存儲過程、表變數或游標。 SQLServer資料庫引擎創建的內部對象，例如，用於存儲假離線或排序的中間結果的工作表。 由使用已提交讀（使用行版本控制隔離或快照隔離事務）的資料庫中數據修改事務生成的行版本。 由數據修改事務為實現聯機索引操作、多個活動的結果集(MARS)以及AFTER 觸發器等功能而生 成的行版本。 tempdb中的操作是最小日誌記錄操作。這將使事務產生回滾。每次啟動SQLServer 時都會重新 創建tempdb，從而在系統啟動時總是保持一個干凈的資料庫副本。在斷開聯接時會自動刪除臨時 表和存儲過程，並且在系統關閉後沒有活動連接。因此tempdb中不會有什麼內容從一個SQLServer 會話保存到另一個會話。不允許對tempdb進行備份和還原操作。 資源資料庫(mssqlsystemresource) 資源資料庫是一個隱藏資料庫。可執行系統對象(入系統存儲過程和功能)都保存在這里。創建這個數 據庫是為了快速安全的升級。如果沒有人可以訪問到這個資料庫，也就沒有人可以改變它。簡單的用 新的資源資料庫替換掉舊的資源資料庫，就可以升級到新的，包括新系統對象服務包。不能使用任何 正常方法查看該資料庫。但這個資料庫任然需要磁碟空間。 mssqlsystemresource資料庫從來不做修改，理論上不用備份。 msdb資料庫 由SQLServer代理用於計劃警報和作業,也可以由其他功能(如ServiceBroker 和資料庫郵件)使用 SQLServer將在msdb資料庫中自動維護一份完整的在線備份與還原歷史記錄。這些信息包括執行備份一 方的名稱，備份時間和用來存儲備份的備份設備。SQLServerManagementStudio利用這些信息提出 計劃以還原資料庫並應用事務日誌備份。 默認情況下msdb使用簡單恢復模式。 還原msdb資料庫與對用戶資料庫執行完整的資料庫還原相同
㈢ 如何提高資料庫訪問效率
查詢速度慢的原因很多，常見如下幾種：
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是程序設計的缺陷)
2、I/O吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網路速度慢
6、查詢出的數據量過大（可以採用多次查詢，其他的方法降低數據量）
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化
可以通過如下方法來優化查詢 :
1、把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，以前可以將Tempdb應放在RAID0上，SQL2000不在支持。數據量（尺寸）越大，提高I/O越重要.
2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse)
3、升級硬體
4、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（最好是使用默認值0）。索引應該盡量小，使用位元組數小的列建索引好（參照索引的創建）,不要對有限的幾個值的欄位建單一索引如性別欄位
5、提高網速;
6、擴大伺服器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。運行 Microsoft SQL Server? 2000 時，可考慮將虛擬內存大小設置為計算機中安裝的物理內存的 1.5 倍。如果另外安裝了全文檢索功能，並打算運行 Microsoft 搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的 3 倍。將 SQL Server max server memory 伺服器配置選項配置為物理內存的 1.5 倍（虛擬內存大小設置的一半）。
7、增加伺服器CPU個數;但是必須明白並行處理串列處理更需要資源例如內存。使用並行還是串列程是MsSQL自動評估選擇的。單個任務分解成多個任務，就可以在處理器上運行。例如耽擱查詢的排序、連接、掃描和GROUP BY字句同時執行，SQL SERVER根據系統的負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作UPDATE,INSERT，DELETE還不能並行處理。
8、如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR類型，而是VARCHAR。對於欄位的值很長的建全文索引。
9、DB Server 和APPLication Server 分離；OLTP和OLAP分離
10、分布式分區視圖可用於實現資料庫伺服器聯合體。聯合體是一組分開管理的伺服器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成資料庫伺服器聯合體的機制能夠擴大一組伺服器，以支持大型的多層 Web 站點的處理需要。有關更多信息，參見設計聯合資料庫伺服器。（參照SQL幫助文件'分區視圖'）
a、在實現分區視圖之前，必須先水平分區表
b、在創建成員表後，在每個成員伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員伺服器上運行。系統操作如同每個成員伺服器上都有一個原始表的復本一樣，但其實每個伺服器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日誌 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日誌.對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。 在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
1、 查詢語句的詞法、語法檢查
2、 將語句提交給DBMS的查詢優化器
3、 優化器做代數優化和存取路徑的優化
4、 由預編譯模塊生成查詢規劃
5、 然後在合適的時間提交給系統處理執行
6、 最後將執行結果返回給用戶其次，看一下SQL SERVER的數據存放的結構：一個頁面的大小為8K(8060)位元組，8個頁面為一個盤區，按照B樹存放。
12、Commit和rollback的區別 Rollback:回滾所有的事物。 Commit:提交當前的事物. 沒有必要在動態SQL里寫事物，如果要寫請寫在外面如： begin tran exec(@s) commit trans 或者將動態SQL 寫成函數或者存儲過程。
13、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
14、SQL的注釋申明對執行沒有任何影響
15、盡可能不使用游標，它佔用大量的資源。如果需要row-by-row地執行，盡量採用非游標技術,如：在客戶端循環，用臨時表，Table變數，用子查詢，用Case語句等等。游標可以按照它所支持的提取選項進行分類： 只進 必須按照從第一行到最後一行的順序提取行。FETCH NEXT 是唯一允許的提取操作,也是默認方式。可滾動性 可以在游標中任何地方隨機提取任意行。游標的技術在SQL2000下變得功能很強大，他的目的是支持循環。有四個並發選項 READ_ONLY：不允許通過游標定位更新(Update)，且在組成結果集的行中沒有鎖。 OPTIMISTIC WITH valueS:樂觀並發控制是事務控制理論的一個標准部分。樂觀並發控制用於這樣的情形，即在打開游標及更新行的間隔中，只有很小的機會讓第二個用戶更新某一行。當某個游標以此選項打開時，沒有鎖控制其中的行，這將有助於最大化其處理能力。如果用戶試圖修改某一行，則此行的當前值會與最後一次提取此行時獲取的值進行比較。如果任何值發生改變，則伺服器就會知道其他人已更新了此行，並會返回一個錯誤。如果值是一樣的，伺服器就執行修改。 選擇這個並發選項�OPTIMISTIC WITH ROW VERSIONING:此樂觀並發控制選項基於行版本控制。使用行版本控制，其中的表必須具有某種版本標識符，伺服器可用它來確定該行在讀入游標後是否有所更改。在 SQL Server 中，這個性能由 timestamp 數據類型提供，它是一個二進制數字，表示資料庫中更改的相對順序。每個資料庫都有一個全局當前時間戳值：@@DBTS。每次以任何方式更改帶有 timestamp 列的行時，SQL Server 先在時間戳列中存儲當前的 @@DBTS 值，然後增加 @@DBTS 的值。如果某 個表具有 timestamp 列，則時間戳會被記到行級。伺服器就可以比較某行的當前時間戳值和上次提取時所存儲的時間戳值，從而確定該行是否已更新。伺服器不必比較所有列的值，只需比較 timestamp 列即可。如果應用程序對沒有 timestamp 列的表要求基於行版本控制的樂觀並發，則游標默認為基於數值的樂觀並發控制。 SCROLL LOCKS 這個選項實現悲觀並發控制。在悲觀並發控制中，在把資料庫的行讀入游標結果集時，應用程序將試圖鎖定資料庫行。在使用伺服器游標時，將行讀入游標時會在其上放置一個更新鎖。如果在事務內打開游標，則該事務更新鎖將一直保持到事務被提交或回滾；當提取下一行時，將除去游標鎖。如果在事務外打開游標，則提取下一行時，鎖就被丟棄。因此，每當用戶需要完全的悲觀並發控制時，游標都應在事務內打開。更新鎖將阻止任何其它任務獲取更新鎖或排它鎖，從而阻止其它任務更新該行。然而，更新鎖並不阻止共享鎖，所以它不會阻止其它任務讀取行，除非第二個任務也在要求帶更新鎖的讀取。滾動鎖根據在游標定義的 SELECT 語句中指定的鎖提示，這些游標並發選項可以生成滾動鎖。滾動鎖在提取時在每行上獲取，並保持到下次提取或者游標關閉，以先發生者為准。下次提取時，伺服器為新提取中的行獲取滾動鎖，並釋放上次提取中行的滾動鎖。滾動鎖獨立於事務鎖，並可以保持到一個提交或回滾操作之後。如果提交時關閉游標的選項為關，則 COMMIT 語句並不關閉任何打開的游標，而且滾動鎖被保留到提交之後，以維護對所提取數據的隔離。所獲取滾動鎖的類型取決於游標並發選項和游標 SELECT 語句中的鎖提示。鎖提示 只讀 樂觀數值 樂觀行版本控制 鎖定無提示 未鎖定 未鎖定 未鎖定 更新 NOLOCK 未鎖定 未鎖定 未鎖定 未鎖定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 錯誤 更新 更新 更新 TABLOCKX 錯誤 未鎖定 未鎖定 更新其它 未鎖定 未鎖定 未鎖定 更新 *指定 NOLOCK 提示將使指定了該提示的表在游標內是只讀的。
16、用Profiler來跟蹤查詢，得到查詢所需的時間，找出SQL的問題所在;用索引優化器優化索引
17、注意UNion和UNion all 的區別。UNION all好
18、注意使用DISTINCT，在沒有必要時不要用，它同UNION一樣會使查詢變慢。重復的記錄在查詢里是沒有問題的
19、查詢時不要返回不需要的行、列
20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT來限制查詢消耗的資源。當評估查詢消耗的資源超出限制時，伺服器自動取消查詢,在查詢之前就扼殺掉。SET LOCKTIME設置鎖的時間
21、用select top 100 / 10 Percent 來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行
22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因為他們不走索引全是表掃描。也不要在WHere字句中的列名加函數，如Convert，substring等,如果必須用函數的時候，創建計算列再創建索引來替代.還可以變通寫法：WHERE SUBSTRING(firstname,1,1) = 'm'改為WHERE firstname like 'm%'（索引掃描），一定要將函數和列名分開。並且索引不能建得太多和太大。NOT IN會多次掃描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 來替代，特別是左連接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，現在2000的優化器能夠處理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能優化她，而"<>"等還是不能優化，用不到索引。
23、使用Query Analyzer，查看SQL語句的查詢計劃和評估分析是否是優化的SQL。一般的20%的代碼占據了80%的資源，我們優化的重點是這些慢的地方。
24、如果使用了IN或者OR等時發現查詢沒有走索引，使用顯示申明指定索引：
SELECT * FROM PersonMember (INDEX = IX_Title) WHERE processid IN ('男'，'女')
25、將需要查詢的結果預先計算好放在表中，查詢的時候再SELECT。這在SQL7.0以前是最重要的手段。例如醫院的住院費計算。
26、MIN() 和 MAX()能使用到合適的索引。
27、資料庫有一個原則是代碼離數據越近越好，所以優先選擇Default,依次為Rules,Triggers, Constraint（約束如外健主健CheckUNIQUE……,數據類型的最大長度等等都是約束）,Procere.這樣不僅維護工作小，編寫程序質量高，並且執行的速度快。
28、如果要插入大的二進制值到Image列，使用存儲過程，千萬不要用內嵌INsert來插入(不知JAVA是否)。因為這樣應用程序首先將二進制值轉換成字元串（尺寸是它的兩倍），伺服器受到字元後又將他轉換成二進制值.存儲過程就沒有這些動作: 方法：
Create procere p_insert as insert into table(Fimage) values (@image)
在前台調用這個存儲過程傳入二進制參數，這樣處理速度明顯改善。
29、Between在某些時候比IN速度更快,Between能夠更快地根據索引找到范圍。用查詢優化器可見到差別。
select * from chineseresume where title in ('男','女')
Select * from chineseresume where title between '男' and '女'
是一樣的。由於in會在比較多次，所以有時會慢些。
30、在必要是對全局或者局部臨時表創建索引，有時能夠提高速度，但不是一定會這樣，因為索引也耗費大量的資源。他的創建同是實際表一樣。
31、不要建沒有作用的事物例如產生報表時，浪費資源。只有在必要使用事物時使用它。
32、用OR的字句可以分解成多個查詢，並且通過UNION 連接多個查詢。他們的速度只同是否使用索引有關,如果查詢需要用到聯合索引，用UNION all執行的效率更高.多個OR的字句沒有用到索引，改寫成UNION的形式再試圖與索引匹配。一個關鍵的問題是否用到索引。
33、盡量少用視圖，它的效率低。對視圖操作比直接對表操作慢,可以用stored procere來代替她。特別的是不要用視圖嵌套,嵌套視圖增加了尋找原始資料的難度。我們看視圖的本質：它是存放在伺服器上的被優化好了的已經產生了查詢規劃的SQL。對單個表檢索數據時，不要使用指向多個表的視圖，直接從表檢索或者僅僅包含這個表的視圖上讀，否則增加了不必要的開銷,查詢受到干擾.為了加快視圖的查詢，MsSQL增加了視圖索引的功能。
34、沒有必要時不要用DISTINCT和ORDER BY，這些動作可以改在客戶端執行。它們增加了額外的開銷。這同UNION 和UNION ALL一樣的道理。
select top 20 ad.companyname,comid,position,ad.referenceid,worklocation,
convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescription FROM
jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345',
'JCNAD00333138','JCNAD00303570','JCNAD00303569',
'JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933',
'JCNAD00254567','JCNAD00254585','JCNAD00254608',
'JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618',
'JCNAD00279196','JCNAD00268613') order by postdate desc
35、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減少判斷的次數。
36、當用SELECT INTO時，它會鎖住系統表(sysobjects，sysindexes等等)，阻塞其他的連接的存取。創建臨時表時用顯示申明語句，而不是
select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume
where name = 'XYZ' --commit
在另一個連接中SELECT * from sysobjects可以看到 SELECT INTO 會鎖住系統表，Create table 也會鎖系統表(不管是臨時表還是系統表)。所以千萬不要在事物內使用它！！！這樣的話如果是經常要用的臨時表請使用實表，或者臨時表變數。
37、一般在GROUP BY 個HAVING字句之前就能剔除多餘的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：select 的Where字句選擇所有合適的行，Group By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group By 個Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group BY的目的不包括計算，只是分組，那麼用Distinct更快
38、一次更新多條記錄比分多次更新每次一條快,就是說批處理好
39、少用臨時表，盡量用結果集和Table類性的變數來代替它,Table 類型的變數比臨時表好
40、在SQL2000下，計算欄位是可以索引的，需要滿足的條件如下：
a、計算欄位的表達是確定的
b、不能用在TEXT,Ntext，Image數據類型
c、必須配製如下選項 ANSI_NULLS = ON, ANSI_PADDINGS = ON, …….
41、盡量將數據的處理工作放在伺服器上，減少網路的開銷，如使用存儲過程。存儲過程是編譯好、優化過、並且被組織到一個執行規劃里、且存儲在資料庫中的SQL語句，是控制流語言的集合，速度當然快。反復執行的動態SQL,可以使用臨時存儲過程，該過程（臨時表）被放在Tempdb中。以前由於SQL SERVER對復雜的數學計算不支持，所以不得不將這個工作放在其他的層上而增加網路的開銷。SQL2000支持UDFs,現在支持復雜的數學計算，函數的返回值不要太大，這樣的開銷很大。用戶自定義函數象游標一樣執行的消耗大量的資源，如果返回大的結果採用存儲過程
42、不要在一句話里再三的使用相同的函數，浪費資源,將結果放在變數里再調用更快
43、SELECT COUNT(*)的效率教低，盡量變通他的寫法，而EXISTS快.同時請注意區別： select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的！！！
44、當伺服器的內存夠多時，配製線程數量 = 最大連接數+5，這樣能發揮最大的效率；否則使用 配製線程數量<最大連接數啟用SQL SERVER的線程池來解決,如果還是數量 = 最大連接數+5，嚴重的損害伺服器的性能。
45、按照一定的次序來訪問你的表。如果你先鎖住表A，再鎖住表B，那麼在所有的存儲過程中都要按照這個順序來鎖定它們。如果你（不經意的）某個存儲過程中先鎖定表B，再鎖定表A，這可能就會導致一個死鎖。如果鎖定順序沒有被預先詳細的設計好，死鎖很難被發現
46、通過SQL Server Performance Monitor監視相應硬體的負載 Memory: Page Faults / sec計數器如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。
Process:
1、% DPC Time 指在範例間隔期間處理器用在緩延程序調用(DPC)接收和提供服務的百分比。(DPC 正在運行的為比標准間隔優先權低的間隔)。 由於 DPC 是以特權模式執行的，DPC 時間的百分比為特權時間 百分比的一部分。這些時間單獨計算並且不屬於間隔計算總數的一部 分。這個總數顯示了作為實例時間百分比的平均忙時。
2、%Processor Time計數器 如果該參數值持續超過95%，表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器。
3、% Privileged Time 指非閑置處理器時間用於特權模式的百分比。(特權模式是為操作系統組件和操縱硬體驅動程序而設計的一種處理模式。它允許直接訪問硬體和所有內存。另一種模式為用戶模式，它是一種為應用程序、環境分系統和整數分系統設計的一種有限處理模式。操作系統將應用程序線程轉換成特權模式以訪問操作系統服務)。 特權時間的 % 包括為間斷和 DPC 提供服務的時間。特權時間比率高可能是由於失敗設備產生的大數量的間隔而引起的。這個計數器將平均忙時作為樣本時間的一部分顯示。
4、% User Time表示耗費CPU的資料庫操作，如排序，執行aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡單的表聯接，水平分割大表格等方法來降低該值。 Physical Disk: Curretn Disk Queue Length計數器該值應不超過磁碟數的1.5~2倍。要提高性能，可增加磁碟。 SQLServer:Cache Hit Ratio計數器該值越高越好。如果持續低於80%，應考慮增加內存。 注意該參數值是從SQL Server啟動後，就一直累加記數，所以運行經過一段時間後，該值將不能反映系統當前值。
47、分析select emp_name form employee where salary > 3000 在此語句中若salary是Float類型的，則優化器對其進行優化為Convert(float,3000)，因為3000是個整數，我們應在編程時使用3000.0而不要等運行時讓DBMS進行轉化。同樣字元和整型數據的轉換。
48、查詢的關聯同寫的順序
select a.personMemberID, * from chineseresume a,personmember b where personMemberID
= b.referenceid and a.personMemberID = 'JCNPRH39681' （A = B ,B = '號碼'）
select a.personMemberID, * from chineseresume a,personmember b where a.personMemberID
= b.referenceid and a.personMemberID = 'JCNPRH39681' and b.referenceid = 'JCNPRH39681' （A = B ,B = '號碼'， A = '號碼'）
select a.personMemberID, * from chineseresume a,personmember b where b.referenceid
= 'JCNPRH39681' and a.personMemberID = 'JCNPRH39681' （B = '號碼'， A = '號碼'）
49、
(1)IF 沒有輸入負責人代碼 THEN code1=0 code2=9999 ELSE code1=code2=負責人代碼 END IF 執行SQL語句為: SELECT 負責人名 FROM P2000 WHERE 負責人代碼>=:code1 AND負責人代碼 <=:code2
(2)IF 沒有輸入負責人代碼 THEN SELECT 負責人名 FROM P2000 ELSE code= 負責人代碼 SELECT 負責人代碼 FROM P2000 WHERE 負責人代碼=:code END IF 第一種方法只用了一條SQL語句,第二種方法用了兩條SQL語句。在沒有輸入負責人代碼時,第二種方法顯然比第一種方法執行效率高,因為它沒有限制條件;在輸入了負責人代碼時,第二種方法仍然比第一種方法效率高,不僅是少了一個限制條件,還因相等運算是最快的查詢運算。我們寫程序不要怕麻煩
50、關於JOBCN現在查詢分頁的新方法（如下），用性能優化器分析性能的瓶頸，如果在I/O或者網路的速度上，如下的方法優化切實有效，如果在CPU或者內存上，用現在的方法更好。請區分如下的方法，說明索引越小越好。
begin
DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
insert into @local_variable (ReferenceID)
select top 100000 ReferenceID from chineseresume order by ReferenceID
select * from @local_variable where Fid > 40 and fid <= 60
end
和
begin
DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
insert into @local_variable (ReferenceID)
select top 100000 ReferenceID from chineseresume order by updatedate
select * from @local_variable where Fid > 40 and fid <= 60
end
的不同
begin
create table #temp (FID int identity(1,1),ReferenceID varchar(20))
insert into #temp (ReferenceID)
select top 100000 ReferenceID from chineseresume order by updatedate
select * from #temp where Fid > 40 and fid <= 60 drop table #temp
end
㈣ 資料庫表的版本控制有什麼好的辦法
SVN，所有的SQL語句變動都有記錄
使用RedGate 中的 SQL Source Control，每次變動都會有記錄，跟SQLServer集成在一起的，使用筆記方便，若是學習，網上有破解版本
一款軟體BDB，不需要再自己操心哪些表新增了，欄位變了，存儲過程又變了這些事情，有哪些表需要填充一些初始數據，當然是破解版本的，商業用自己付費。
㈤ 關於SQLServer2008版本控制的問題，最好是用VSS或者SVN控制，有沒有中文版的幫助文檔
vss ok
使用VSS 6與SQL Server 2000集成存儲過程版本控制的設置本篇文章來源於：開發學院 http://e.codepub.com 原文鏈接：http://e.codepub.com/2010/0414/22030.php
微軟已經有比較詳細的介紹，具體見如何使用 Visual Studio .NET 將 SQL Server 2000 存儲過程添加到 Visual SourceSafe。但在搭建的過程中，還是有些關鍵的步驟需要說明一下的：
1、SQL SERVER2000（文檔中描述適用於SQL SERVER2000標准版，其他版本沒有測試過）的服務的登錄用戶需要有對VSS目錄有讀寫許可權。也就是說，如果SQL SERVER和VSS伺服器端安裝在同一Server上，SQL SERVER的服務登錄用戶需要有對本機VSS資料庫目錄有讀寫許可權；如果SQL SERVER和VSS伺服器端安裝在不同的Server上，SQL SERVER的服務登錄用戶需要有對遠程計算機上的VSS資料庫目錄有讀寫許可權
2、安裝VSS 6.0C以上版本（Visual Studio 6.0 Enterprise Edition 自帶光碟中有6.0C，Visual Studio .Net 2003以上帶的是6.0D）
3、將SQL SERVER服務的登錄用戶添加到VSS用戶中（在我設置的過程中，登錄用戶名的長度大於8個，VSS顯示用戶名只有8位，但後面能夠順利登錄VSS，呵呵，不知是否是bug，還是我的VSS問題 ^_^ ）
4、關鍵！！已經在SQL SERVER2000伺服器上安裝了Visual Studio .Net的，需要在「伺服器組件」下重新選擇「VS 6 存儲過程版本控制」，然後「立即更新」。還沒有在SQL SERVER2000伺服器上安裝了Visual Studio .Net的，需要在「伺服器組件」下選擇「VS 6 存儲過程版本控制」，然後「安裝」。更新或安裝完成後，會安裝必須的系統表和系統存儲過程在SQL SERVER上。
5、剩下的問題就比較簡單了，對存儲過程啟用版本控制。在.Net的IDE「工具」->「選項」->「資料庫工具」->「伺服器資源管理器」->「存儲過程」，選中「啟用版本控制」復選框。然後在伺服器資源管理器中，展開「數據連接」及相關的「資料庫引用」。右鍵單擊「存儲過程」文件夾，然後單擊「添加到源代碼管理」。在「啟用源代碼管理」對話框中，鍵入「源代碼管理資料庫位置」。填寫好VSS服務的srcsafe.ini文件位置和放於那個VSS項目下後，在伺服器資源管理器中，展開「存儲過程」文件夾，右鍵單擊存儲過程名稱（或者按Ctrl，同時選擇多個存儲過程，右鍵），然後單擊「添加到源代碼管理」，就能夠把存儲過程添加到VSS中了。
本篇文章來源於：開發學院 http://e.codepub.com 原文鏈接：http://e.codepub.com/2010/0414/22030.php
㈥ 為什麼NATIVE FOR ORACLE查詢速度慢
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是程序設計的缺陷)
2、I/O吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網路速度慢
6、查詢出的數據量過大(可以採用多次查詢，其他的方法降低數據量)
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化 ●可以通過如下方法來優化查詢 :
1)把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，以前可以將Tempdb應放在RAID0上，SQL2000不在支持。數據量(尺寸)越大，提高I/O越重要.
2)縱向、橫向分割表，減少表的尺寸(sp_spaceuse)
3)升級硬體
4)根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當(最好是使用默認值0)。索引應該盡量小，使用位元組數小的列建索引好(參照索引的創建),不要對有限的幾個值的欄位建單一索引如性別欄位
5)提高網速;
6)擴大伺服器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。運行 Microsoft SQL Server? 2000 時，可考慮將虛擬內存大小設置為計算機中安裝的物理內存的 1.5 倍。如果另外安裝了全文檢索功能，並打算運行 Microsoft 搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的 3 倍。將 SQL Server max server memory 伺服器配置選項配置為物理內存的 1.5 倍(虛擬內存大小設置的一半)。
7)增加伺服器CPU個數;但是必須明白並行處理串列處理更需要資源例如內存。使用並行還是串列程是MsSQL自動評估選擇的。單個任務分解成多個任務，就可以在處理器上運行。例如耽擱查詢的排序、連接、掃描和GROUP BY字句同時執行，SQL SERVER根據系統的負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作 UPDATE, INSERT， DELETE還不能並行處理。
8)如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR類型，而是VARCHAR。對於欄位的值很長的建全文索引。
9)DB Server 和APPLication Server 分離;OLTP和OLAP分離
10)分布式分區視圖可用於實現資料庫伺服器聯合體。聯合體是一組分開管理的伺服器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成資料庫伺服器聯合體的機制能夠擴大一組伺服器，以支持大型的多層 Web 站點的處理需要。有關更多信息，參見設計聯合資料庫伺服器。(參照SQL幫助文件'分區視圖')
a、在實現分區視圖之前，必須先水平分區表
b、在創建成員表後，在每個成員伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員伺服器上運行。系統操作如同每個成員伺服器上都有一個原始表的復本一樣，但其實每個伺服器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日誌 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日誌.對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
1) 查詢語句的詞法、語法檢查
2) 將語句提交給DBMS的查詢優化器
3) 優化器做代數優化和存取路徑的優化
4) 由預編譯模塊生成查詢規劃
5) 然後在合適的時間提交給系統處理執行
6) 最後將執行結果返回給用戶其次，看一下SQL SERVER的數據存放的結構：一個頁面的大小為8K(8060)位元組，8個頁面為一個盤區，按照B樹存放。
12、Commit和rollback的區別 Rollback:回滾所有的事務。 Commit:提交當前的事物. 沒有必要在動態SQL里寫事務，如果要寫請寫在外面如： begin tran exec(@s) commit trans 或者將動態SQL 寫成函數或者存儲過程。
13、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
14、SQL的注釋申明對執行沒有任何影響
15、盡可能不使用游標，它佔用大量的資源。如果需要row-by-row地執行，盡量採用非游標技術,如：在客戶端循環，用臨時表，Table變數，用子查詢，用Case語句等等。游標可以按照它所支持的提取選項進行分類： 只進 必須按照從第一行到最後一行的順序提取行。FETCH NEXT 是唯一允許的提取操作,也是默認方式。可滾動性可以在游標中任何地方隨機提取任意行。游標的技術在SQL2000下變得功能很強大，他的目的是支持循環。有四個並發選項 READ_ONLY：不允許通過游標定位更新(Update)，且在組成結果集的行中沒有鎖。 OPTIMISTIC WITH valueS:樂觀並發控制是事務控制理論的一個標准部分。樂觀並發控制用於這樣的情形，即在打開游標及更新行的間隔中，只有很小的機會讓第二個用戶更新某一行。當某個游標以此選項打開時，沒有鎖控制其中的行，這將有助於最大化其處理能力。
如果用戶試圖修改某一行，則此行的當前值會與最後一次提取此行時獲取的值進行比較。如果任何值發生改變，則伺服器就會知道其他人已更新了此行，並會返回一個錯誤。如果值是一樣的，伺服器就執行修改。 選擇這個並發選項 OPTIMISTIC WITH ROW VERSIONING:此樂觀並發控制選項基於行版本控制。使用行版本控制，其中的表必須具有某種版本標識符，伺服器可用它來確定該行在讀入游標後是否有所更改。在 SQL Server 中，這個性能由 timestamp 數據類型提供，它是一個二進制數字，表示資料庫中更改的相對順序。每個資料庫都有一個全局當前時間戳值：@@DBTS。每次以任何方式更改帶有 timestamp 列的行時，SQL Server 先在時間戳列中存儲當前的 @@DBTS 值，然後增加 @@DBTS 的值。如果某 個表具有 timestamp 列，則時間戳會被記到行級。伺服器就可以比較某行的當前時間戳值和上次提取時所存儲的時間戳值，從而確定該行是否已更新。伺服器不必比較所有列的值，只需比較 timestamp 列即可。如果應用程序對沒有 timestamp 列的表要求基於行版本控制的樂觀並發，則游標默認為基於數值的樂觀並發控制。 SCROLL LOCKS 這個選項實現悲觀並發控制。在悲觀並發控制中，在把資料庫的行讀入游標結果集時，應用程序將試圖鎖定資料庫行。在使用伺服器游標時，將行讀入游標時會在其上放置一個更新鎖。如果在事務內打開游標，則該事務更新鎖將一直保持到事務被提交或回滾;當提取下一行時，將除去游標鎖。如果在事務外打開游標，則提取下一行時，鎖就被丟棄。因此，每當用戶需要完全的悲觀並發控制時，游標都應在事務內打開。更新鎖將阻止任何其它任務獲取更新鎖或排它鎖，從而阻止其它任務更新該行。然而，更新鎖並不阻止共享鎖，所以它不會阻止其它任務讀取行，除非第二個任務也在要求帶更新鎖的讀取。滾動鎖根據在游標定義的 SELECT 語句中指定的鎖提示，這些游標並發選項可以生成滾動鎖。滾動鎖在提取時在每行上獲取，並保持到下次提取或者游標關閉，以先發生者為准。下次提取時，伺服器為新提取中的行獲取滾動鎖，並釋放上次提取中行的滾動鎖。滾動鎖獨立於事務鎖，並可以保持到一個提交或回滾操作之後。如果提交時關閉游標的選項為關，則 COMMIT 語句並不關閉任何打開的游標，而且滾動鎖被保留到提交之後，以維護對所提取數據的隔離。所獲取滾動鎖的類型取決於游標並發選項和游標 SELECT 語句中的鎖提示。
16、用Profiler來跟蹤查詢，得到查詢所需的時間，找出SQL的問題所在;用索引優化器優化索引
17、注意UNion和UNion all 的區別。UNION all好
18、注意使用DISTINCT，在沒有必要時不要用，它同UNION一樣會使查詢變慢。重復的記錄在查詢里是沒有問題的
19、查詢時不要返回不需要的行、列
20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT來限制查詢消耗的資源。當評估查詢消耗的資源超出限制時，伺服器自動取消查詢,在查詢之前就扼殺掉。SET LOCKTIME設置鎖的時間
21、用select top
100
/
10
Percent 來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行
22、在SQL2000以前，一般不要用如下的字句: "IS
NULL", "<>", "!=", "!>", "!<", "NOT", "NOT
EXISTS", "NOT
IN", "NOT
LIKE", and "LIKE
'%500'"，因為他們不走索引全是表掃描。也不要在WHere字句中的列名加函數，如Convert，substring等,如果必須用函數的時候，創建計算列再創建索引來替代.還可以變通寫法：WHERE
SUBSTRING(firstname,1,1) =
'm'改為WHERE firstname like
'm%'(索引掃描)，一定要將函數和列名分開。並且索引不能建得太多和太大。NOT IN會多次掃描表，使用EXISTS、NOT
EXISTS ，IN , LEFT
OUTER
JOIN 來替代，特別是左連接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，現在2000的優化器能夠處理了。相同的是IS NULL，「NOT", "NOT
EXISTS", "NOT
IN"能優化她，而」<>」等還是不能優化，用不到索引。
23、使用Query Analyzer，查看SQL語句的查詢計劃和評估分析是否是優化的SQL。一般的20%的代碼占據了80%的資源，我們優化的重點是這些慢的地方。
24、如果使用了IN或者OR等時發現查詢沒有走索引，使用顯示申明指定索引： SELECT
*
FROM PersonMember (INDEX
= IX_Title) WHERE processid IN (『男'，『女')
25、將需要查詢的結果預先計算好放在表中，查詢的時候再SELECT。這在SQL7.0以前是最重要的手段。例如醫院的住院費計算。
26、MIN() 和 MAX()能使用到合適的索引。
27、資料庫有一個原則是代碼離數據越近越好，所以優先選擇Default,依次為Rules,Triggers, Constraint(約束如外健主健CheckUNIQUE……,數據類型的最大長度等等都是約束),Procere.這樣不僅維護工作小，編寫程序質量高，並且執行的速度快。
28、如果要插入大的二進制值到Image列，使用存儲過程，千萬不要用內嵌INsert來插入(不知JAVA是否)。因為這樣應用程序首先將二進制值轉換成字元串(尺寸是它的兩倍)，伺服器受到字元後又將他轉換成二進制值.存儲過程就沒有這些動作: 方法：Create
procere p_insert as
insert
into
table(Fimage) values (@image), 在前台調用這個存儲過程傳入二進制參數，這樣處理速度明顯改善。
29、Between在某些時候比IN速度更快,Between能夠更快地根據索引找到范圍。用查詢優化器可見到差別。 select
*
from chineseresume where title in ('男','女') Select
*
from chineseresume where
between
'男'
and
'女' 是一樣的。由於in會在比較多次，所以有時會慢些。
30、在必要是對全局或者局部臨時表創建索引，有時能夠提高速度，但不是一定會這樣，因為索引也耗費大量的資源。他的創建同是實際表一樣。
31、不要建沒有作用的事物例如產生報表時，浪費資源。只有在必要使用事物時使用它。
32、用OR的字句可以分解成多個查詢，並且通過UNION 連接多個查詢。他們的速度只同是否使用索引有關,如果查詢需要用到聯合索引，用UNION all執行的效率更高.多個OR的字句沒有用到索引，改寫成UNION的形式再試圖與索引匹配。一個關鍵的問題是否用到索引。
33、盡量少用視圖，它的效率低。對視圖操作比直接對表操作慢,可以用stored procere來代替她。特別的是不要用視圖嵌套,嵌套視圖增加了尋找原始資料的難度。我們看視圖的本質：它是存放在伺服器上的被優化好了的已經產生了查詢規劃的SQL。對單個表檢索數據時，不要使用指向多個表的視圖，直接從表檢索或者僅僅包含這個表的視圖上讀，否則增加了不必要的開銷,查詢受到干擾.為了加快視圖的查詢，MsSQL增加了視圖索引的功能。
34、沒有必要時不要用DISTINCT和ORDER BY，這些動作可以改在客戶端執行。它們增加了額外的開銷。這同UNION 和UNION ALL一樣的道理。 SELECT
top
20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescription FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345','JCNAD00333138','JCNAD00303570', 'JCNAD00303569','JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933','JCNAD00254567', 'JCNAD00254585','JCNAD00254608','JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618', 'JCNAD00279196','JCNAD00268613') order
by postdate desc
35、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減少判斷的次數。
36、當用SELECT INTO時，它會鎖住系統表(sysobjects，sysindexes等等)，阻塞其他的連接的存取。創建臨時表時用顯示申明語句，而不是select INTO. drop
table t_lxh begin
tran
select
*
into t_lxh from chineseresume where name =
'XYZ'
--commit 在另一個連接中SELECT * from sysobjects可以看到 SELECT INTO 會鎖住系統表，Create table 也會鎖系統表(不管是臨時表還是系統表)。所以千萬不要在事物內使用它!!!這樣的話如果是經常要用的臨時表請使用實表，或者臨時表變數。
37、一般在GROUP BY 個HAVING字句之前就能剔除多餘的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：select 的Where字句選擇所有合適的行，Group By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group By 個Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group BY的目的不包括計算，只是分組，那麼用Distinct更快
38、一次更新多條記錄比分多次更新每次一條快,就是說批處理好
39、少用臨時表，盡量用結果集和Table類性的變數來代替它,Table 類型的變數比臨時表好
40、在SQL2000下，計算欄位是可以索引的，需要滿足的條件如下：
a、計算欄位的表達是確定的
b、不能用在TEXT,Ntext，Image數據類型
c、必須配製如下選項 ANSI_NULLS =
ON, ANSI_PADDINGS =
ON, …….
41、盡量將數據的處理工作放在伺服器上，減少網路的開銷，如使用存儲過程。存儲過程是編譯好、優化過、並且被組織到一個執行規劃里、且存儲在資料庫中的SQL語句，是控制流語言的集合，速度當然快。反復執行的動態SQL,可以使用臨時存儲過程，該過程(臨時表)被放在Tempdb中。以前由於SQL SERVER對復雜的數學計算不支持，所以不得不將這個工作放在其他的層上而增加網路的開銷。SQL2000支持UDFs,現在支持復雜的數學計算，函數的返回值不要太大，這樣的開銷很大。用戶自定義函數象游標一樣執行的消耗大量的資源，如果返回大的結果採用存儲過程
42、不要在一句話里再三的使用相同的函數，浪費資源,將結果放在變數里再調用更快
43、SELECT
COUNT(*)的效率教低，盡量變通他的寫法，而EXISTS快.同時請注意區別： select
count(Field of
null) from
Table 和 select
count(Field of
NOT
null) from
Table 的返回值是不同的!!!
44、當伺服器的內存夠多時，配製線程數量 = 最大連接數+5，這樣能發揮最大的效率;否則使用 配製線程數量<最大連接數啟用SQL SERVER的線程池來解決,如果還是數量 = 最大連接數+5，嚴重的損害伺服器的性能。
45、按照一定的次序來訪問你的表。如果你先鎖住表A，再鎖住表B，那麼在所有的存儲過程中都要按照這個順序來鎖定它們。如果你(不經意的)某個存儲過程中先鎖定表B，再鎖定表A，這可能就會導致一個死鎖。如果鎖定順序沒有被預先詳細的設計好，死鎖很難被發現
46、通過SQL Server Performance Monitor監視相應硬體的負載 Memory: Page Faults / sec計數器如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。 Process:
1、% DPC Time 指在範例間隔期間處理器用在緩延程序調用(DPC)接收和提供服務的百分比。(DPC 正在運行的為比標准間隔優先權低的間隔)。 由於 DPC 是以特權模式執行的，DPC 時間的百分比為特權時間 百分比的一部分。這些時間單獨計算並且不屬於間隔計算總數的一部 分。這個總數顯示了作為實例時間百分比的平均忙時。
2、%Processor Time計數器如果該參數值持續超過95%，表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器。
3、% Privileged Time 指非閑置處理器時間用於特權模式的百分比。(特權模式是為操作系統組件和操縱硬體驅動程序而設計的一種處理模式。它允許直接訪問硬體和所有內存。另一種模式為用戶模式，它是一種為應用程序、環境分系統和整數分系統設計的一種有限處理模式。操作系統將應用程序線程轉換成特權模式以訪問操作系統服務)。 特權時間的 % 包括為間斷和 DPC 提供服務的時間。特權時間比率高可能是由於失敗設備產生的大數量的間隔而引起的。這個計數器將平均忙時作為樣本時間的一部分顯示。
4、%
User Time表示耗費CPU的資料庫操作，如排序，執行aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡單的表聯接，水平分割大表格等方法來降低該值。 Physical Disk: Curretn Disk Queue Length計數器該值應不超過磁碟數的1.5~2倍。要提高性能，可增加磁碟。 SQLServer:Cache Hit Ratio計數器該值越高越好。如果持續低於80%，應考慮增加內存。 注意該參數值是從SQL Server啟動後，就一直累加記數，所以運行經過一段時間後，該值將不能反映系統當前值。
47、分析select emp_name form employee where salary >
3000 在此語句中若salary是Float類型的，則優化器對其進行優化為Convert(float,3000)，因為3000是個整數，我們應在編程時使用3000.0而不要等運行時讓DBMS進行轉化。同樣字元和整型數據的轉換。
48、查詢的關聯同寫的順序 select a.personMemberID, *
from chineseresume a,personmember b where personMemberID = b.referenceid and a.personMemberID =
'JCNPRH39681' (A = B ,B = 『號碼') select a.personMemberID, * from chineseresume a,personmember b where a.personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' and b.referenceid = 'JCNPRH39681' (A = B ,B = 『號碼'， A = 『號碼') select a.personMemberID, * from chineseresume a,personmember b where b.referenceid = 'JCNPRH39681' and a.personMemberID = 'JCNPRH39681' (B = 『號碼'， A = 『號碼')
㈦ SQL sever是什麼
SQL Server是微軟公司開發的一個關系資料庫管理系統，以Transact_SQL作為它的資料庫查詢和編程語言。T－SQL是結構化查詢語言SQL的一種，支持ANSI SQL－92標准。
SQL Server 採用二級安全驗證、登錄驗證及資料庫用戶帳號和角色的許可驗證。SQL Server 支持兩種身份驗證模式：Windows NT身份驗證和SQL Server 身份驗證。7.0版支持多種類型的角色，"角色"概念的引入方便了許可權的管理，也使許可權的分配更加靈活。
SQL Server為公共的管理功能提供了預定義的伺服器和資料庫角色，可以很容易為某一特定用戶授予一組選擇好的許可許可權。 SQL Server可以在不同的操作平台上運行，支持多種不同類型的網路協議如TCP/IP、IPX/SPX、Apple Talk等。SQL Server在伺服器端的軟體運行平台是Windows NT、Windows9x，在客戶端可以是Windows3.x、Windows NT、Windows9x,也可以採用其它廠商開發的系統如Unix、Apple Macintosh等。
微軟的SQL Server是一項完美的客戶/伺服器系統。SQL Server需要安裝在Windows NT的平台上，而Windows NT可以支持Intel 386，Power PC，MIPS，Alpha PC和RISC等平台，它使SQL Server具備足夠的威力和功能。
這里所有的文章所採用的資料庫應用程序都是基於SQL Server之上的，採用ODBC及標準的SQL查詢，可以非常簡單的移植到任何一個支持ODBC的資料庫之上，如：Oracle，Informix，Db2和Access，在閱讀有關ASP資料庫編程技術之前，要確認你至少熟悉一種資料庫管理系統，並可以使用標準的SQL查詢語言操作資料庫。
SQL Server提供伺服器端的軟體，這部分需要安裝在NT Server上，SQL Server的用戶端則可以安裝在許多用戶端PC系統中，Windows可以讓用戶端進行資料庫的建立，維護及存取等操作，SQL Server可以最多定義32767個資料庫，每個資料庫中，可以定義20億個表格，每個表格可以有250個欄位，每個表格的數據個數並沒有限制，每一個表格可以定義250個索引，其中有一個可以是Clustered索引。
SQL Server所使用的資料庫查詢語言稱為Transact-SQL，它是SQL Server的核心，Transact-SQL強化了原有的SQL關鍵字以進行數據的存取，儲存及處理等功能，Transact-SQL擴充了流程式控制制指定，可以使你方便的編寫功能強大的存儲過程，他們存放在伺服器端，並預先編譯過，執行速度非常塊，觸發是一種特殊的存儲過程，用來確保SQL Server資料庫引用的完整性，你可以建立插入，刪除和更新觸發以控制相關的表格中對數據列的插入，刪除和更新，你還可以使用規則（Rule），預設（default）以及限制（Constraints），來協助將新的數值套用到表格中去！
SQL SERVER的特點與評價
上手容易
話分兩頭，如果您的企業至今還未購置資料庫，其中一個主要的原因可能就是認為它不好上手，那麼，從SQLServer開始吧。畢竟，大多數的中小企業日常的數據應用是建立在Windows平台上的。由於SQLServer與Windows界面風格完全一致，且有許多"向導(Wizard)"幫助，因此易於安裝和學習，有關SQLServer的資料、培訓隨處可得，並且目前國內具有MCDBA認證的工程師不在少數。
從另一個角度來講，學習SQLServer是掌握其他平台及大型數據，如Oracle,Sybase,DB/2的基礎。因為這些大型資料庫對於設備、平台、人員知識的要求往往較高，而並不是每個人都具備這樣的條件，且有機會去接觸它們。但有了SQLServer的基礎，再去學習和使用它們就容易多了。IT行業的實踐經驗充分證明了這一點。
兼容性良好
由於今天Windows操作系統佔領著主導地的位，選擇SQLServer一定會在兼容性方面取得一些優勢。另外，SQLServer2000除了具有擴展性，可靠性以外，還具有可以迅速開發新的網際網路系統的功能。尤其是它可以直接存貯XML數據，可以將搜索結果以XML格式輸出等特點，有利於構建了異構系統的互操作性，奠定了面向互聯網的企業應用和服務的基石。這些特點在.NET戰略中發揮著重要的作用。
電子商務
在使用由MicrosoftSQLServer2000關系資料庫引擎的情況下，XML數據可在關系表中進行存儲，而查詢則能以XML格式將有關結果返回。此外，XML支持還簡化了後端系統集成，並實現了跨防火牆的無縫數據傳輸。你還可以使用HypertextTransferProtocol（超文本傳輸協議，HTTP）來訪問SQLServer2000，以實現面向SQLServer2000資料庫的安全Web連接和無須額外編程的聯機分析處理（OLAP）多維數據集。
數據倉庫
MicrosoftSQLServer2000非常明顯的改進就是增加了OLAP(聯機分析處理)功能,這可以讓很多中小企業用戶也可以使用數據倉庫的一些特性進行分析。OLAP可以通過多維存儲技術對大型、復雜數據集執行快速、高級的分析工作。數據挖掘功能能夠揭示出隱藏在大量數據中的傾向及趨勢，它允許組織或機構最大
限度的從數據中獲取價值。通過對現有數據進行有效分析，這一功能可以對未來的趨勢進行預測。
增強的在線商務
MicrosoftSQLServer2000簡化了管理、優化工作，並且增強了迅速、成功的部署在線商務應用程序所需的可靠性和伸縮性。其中，用以提高可靠性的特性包括日誌傳送、在線備份和故障切換群集。在伸縮性方面的改進包括對多達32顆CPU和64GBRAM的支持。通過自動優化和改進後的管理特性--諸如數據文件尺寸的自動管理、基於向導的資料庫拷貝、自動內存管理和簡化的故障切換群集安裝與管理，在線商務應用程序能夠被迅速部署並有效管理。
利於構築"敏捷性商務"
所謂"敏捷性商務"就是能夠打破內部和外部的商業界限，對迅速改變的環境做出快速反應。。微軟已經與關鍵的合作夥伴建立起了戰略關系，創造出了能夠與許多供應商的產品實現整合的解決方案，因而企業用戶並不需要做出"要麼完全接受，要麼全部不要"的承諾。在部署解決方案的過程中，企業用戶不一定要拆除原有的設備從頭。敏捷商務讓企業用戶能夠充分利用現有的系統，自主決定所需的硬體和軟體解決方案以及由誰來提供，伸縮自如、游刃有餘。
SQL是英文Structured Query Language的縮寫，意思為結構化查詢語言。SQL語言的主要功能就是同各種資料庫建立聯系，進行溝通。按照ANSI(美國國家標准協會)的規定，SQL被作為關系型資料庫管理系統的標准語言。SQL語句可以用來執行各種各樣的操作，例如更新資料庫中的數據，從資料庫中提取數據等。目前，絕大多數流行的關系型資料庫管理系統，如Oracle, Sybase, Microsoft SQL Server, Access等都採用了SQL語言標准。雖然很多資料庫都對SQL語句進行了再開發和擴展，但是包括Select, Insert, Update, Delete, Create,以及Drop在內的標準的SQL命令仍然可以被用來完成幾乎所有的資料庫操作。
SQL Server
SQL Server 是一個關系資料庫管理系統。它最初是由Microsoft Sybase 和Ashton-Tate三家公司共同開發的，於1988 年推出了第一個OS/2 版本。在Windows NT 推出後，Microsoft與Sybase 在SQL Server 的開發上就分道揚鑣了，Microsoft 將SQL Server 移植到Windows NT系統上，專注於開發推廣SQL Server 的Windows NT 版本。Sybase 則較專注於SQL Server在UNIX 操作系統上的應用。
SQL Server 2000 是Microsoft 公司推出的SQL Server 資料庫管理系統，該版本繼承了SQL Server 7.0 版本的優點，同時又比它增加了許多更先進的功能。具有使用方便可伸縮性好與相關軟體集成程度高等優點，可跨越從運行Microsoft Windows 98 的膝上型電腦到運行Microsoft Windows 2000 的大型多處理器的伺服器等多種平台使用。
SQL Server 2005？
SQL Server 2005 是一個全面的資料庫平台，使用集成的商業智能 (BI) 工具提供了企業級的數據管理。SQL Server 2005 資料庫引擎為關系型數據和結構化數據提供了更安全可靠的存儲功能，使您可以構建和管理用於業務的高可用和高性能的數據應用程序。
SQL Server 2005 數據引擎是本企業數據管理解決方案的核心。此外 SQL Server 2005 結合了分析、報表、集成和通知功能。這使您的企業可以構建和部署經濟有效的 BI 解決方案，幫助您的團隊通過記分卡、Dashboard、Web services 和移動設備將數據應用推向業務的各個領域。
與 Microsoft Visual Studio、Microsoft Office System 以及新的開發工具包（包括 Business Intelligence Development Studio）的緊密集成使 SQL Server 2005 與眾不同。無論您是開發人員、資料庫管理員、信息工作者還是決策者，SQL Server 2005 都可以為您提供創新的解決方案，幫助您從數據中更多地獲益。
[編輯本段]微軟SQL Server 2008
SQL Server 2008是一個重大的產品版本，它推出了許多新的特性和關鍵的改進，使得它成為至今為止的最強大和最全面的SQL Server版本。這篇文章詳細介紹了Microsoft SQL Server 2008中的新的特性、優點和功能……
微軟的這個數據平台滿足這些數據爆炸和下一代數據驅動應用程序的需求，支持數據平台願景：關鍵任務企業數據平台、動態開發、關系數據和商業智能。
Microsoft數據平台願景
SQL Server的願景
許多因素致使產生了信息存儲爆炸。有了新的信息類型，例如圖片和視頻的數字化，和從RFID標簽獲得的感測器信息，公司的數字信息的數量在急劇增長。遵守規范和全球化的發展要求信息存儲的安全性和在任何時候都可用。同時，磁碟存儲的成本顯著地降低了，使得公司投資的每一美元可以存儲更多的數據。用戶必須快速的在大量的數據中找到相關的信息。此外，他們想在任何設備上使用這個信息，並且計劃每天使用，例如Microsoft Office系統應用程序。對數據爆炸和用戶期望值的增加的管理為公司製造了許多挑戰。
Microsoft® 數據平台願景提供了一個解決方案來滿足這些需求，這個解決方案就是公司可以使用存儲和管理許多數據類型，包括XML、e-mail、時間/日歷、文件、文檔、地理等等，同時提供一個豐富的服務集合來與數據交互作用：搜索、查詢、數據分析、報表、數據整合，和強大的同步功能。用戶可以訪問從創建到存檔於任何設備的信息，從桌面到移動設備的信息
SQL Server 2008新功能
這個平台有以下特點：
· 可信任的——使得公司可以以很高的安全性、可靠性和可擴展性來運行他們最關鍵任務的應用程序。
· 高效的——使得公司可以降低開發和管理他們的數據基礎設施的時間和成本。
· 智能的——提供了一個全面的平台，可以在你的用戶需要的時候給他發送觀察和信息。
一、可信任的
（一）保護你的信息
在過去的SQL Server 2005的基礎之上，SQL Server 2008做了以下方面的增強來擴展它的安全性：
* 簡單的數據加密
SQL Server 2008可以對整個資料庫、數據文件和日誌文件進行加密，而不需要改動應用程序。進行加密使公司可以滿足遵守規范和及其關注數據隱私的要求。簡單的數據加密的好處包括使用任何范圍或模糊查詢搜索加密的數據、加強數據安全性以防止未授權的用戶訪問、還有數據加密。這些可以在不改變已有的應用程序的情況下進行。
* 外鍵管理
SQL Server 2008為加密和密鑰管理提供了一個全面的解決方案。為了滿足不斷發展的對數據中心的信息的更強安全性的需求，公司投資給供應商來管理公司內的安全密鑰。 SQL Server 2008通過支持第三方密鑰管理和硬體安全模塊(HSM)產品為這個需求提供了很好的支持。
* 增強了審查
SQL Server 2008使你可以審查你的數據的操作，從而提高了遵從性和安全性。審查不只包括對數據修改的所有信息，還包括關於什麼時候對數據進行讀取的信息。SQL Server 2008具有像伺服器中加強的審查的配置和管理這樣的功能，這使得公司可以滿足各種規范需求。SQL Server 2008還可以定義每一個資料庫的審查規范，所以審查配置可以為每一個資料庫作單獨的制定。為指定對象作審查配置使審查的執行性能更好，配置的靈活性也更高。
（二）確保業務可持續性
* 改進了資料庫鏡像
SQL Server 2008基於SQL Server 2005，並提供了更可靠的加強了資料庫鏡像的平台。新的特性包括：
· 頁面自動修復。SQL Server 2008通過請求獲得一個從鏡像合作機器上得到的出錯頁面的重新拷貝，使主要的和鏡像的計算機可以透明的修復數據頁面上的823和824錯誤。
· 提高了性能。SQL Server 2008壓縮了輸出的日誌流，以便使資料庫鏡像所要求的網路帶寬達到最小。
㈧ 為什麼sqlserver 行大小有8060限制
SQL SERVER 2005之後的版本並沒有你說的8060限制。
你可以自已測試下面的SQL語句：
select'1'aslsunion
select'1'aslsunion
--中間請再復制，一共8000行左右
select'1'aslsunion
select'1'asls
提示的是，行數太多，你的伺服器的硬體不一定吃得消，會出現假死。
上面的語句，8千行左右，本人在在當前主流的伺服器級別的計算機上，SQL 2008 R2 64位 版本下，1分鍾左右可以得到結果。
㈨ 如何處理SQL Server死鎖問題
1)
預防死鎖。
這是一種較簡單和直觀的事先預防的方法。方法是通過設置某些限制條件，去破壞產生死鎖的四個必要條件中的一個或者幾個，來預防發生死鎖。預防死鎖是一種較易實現的方法，已被廣泛使用。但是由於所施加的限制條件往往太嚴格，可能會導致系統資源利用率和系統吞吐量降低。
2)
避免死鎖。
該方法同樣是屬於事先預防的策略，但它並不須事先採取各種限制措施去破壞產生死鎖的的四個必要條件，而是在資源的動態分配過程中，用某種方法去防止系統進入不安全狀態，從而避免發生死鎖。
3)檢測死鎖。
這種方法並不須事先採取任何限制性措施，也不必檢查系統是否已經進入不安全區，此方法允許系統在運行過程中發生死鎖。但可通過系統所設置的檢測機構，及時地檢測出死鎖的發生，並精確地確定與死鎖有關的進程和資源，然後採取適當措施，從系統中將已發生的死鎖清除掉。
4)解除死鎖。
這是與檢測死鎖相配套的一種措施。當檢測到系統中已發生死鎖時，須將進程從死鎖狀態中解脫出來。常用的實施方法是撤銷或掛起一些進程，以便回收一些資源，再將這些資源分配給已處於阻塞狀態的進程，使之轉為就緒狀態，以繼續運行。死鎖的檢測和解除措施，有可能使系統獲得較好的資源利用率和吞吐量，但在實現上難度也最大。
由上面4中處理死鎖的辦法看，其中檢測死鎖和解除死鎖是Lock
Monitor的事，作為DBA或資料庫開發人員，處理死鎖要放在預防和避免死鎖上。
預防死鎖
預防死鎖就是破壞四個必要條件中的某一個和幾個，使其不能形成死鎖。有如下幾種辦法
1)破壞互斥條件
破壞互斥條件有比較嚴格的限制,在SQL
Server中，如果業務邏輯上允許臟讀，則可以通過將隔離等級改為未提交讀或使用索引提示。這樣使得讀取不用加S鎖，從而避免了和其它查詢所加的與S鎖不兼容的鎖互斥，進而減少了死鎖出現的概率。
2)破壞請求和等待條件
這點由於事務存在原子性，是不可破壞的，因為解決辦法是盡量的減少事務的長度，事務內執行的越快越好。這也可以減少死鎖出現的概率。
3)破壞不剝奪條件
由於事務的原子性和一致性，不剝奪條件同樣不可破壞。但我們可以通過增加資源和減少資源佔用兩個角度來考慮。
增加資源：比如說通過建立非聚集索引，使得有了額外的資源，查詢很多時候就不再索要鎖基本表，轉而鎖非聚集索引，如果索引能夠「覆蓋(Cover)」查詢，那更好不過。因此索引Include列不僅僅減少書簽查找來提高性能，還能減少死鎖。增加資源還可以通過SQL
Server
2005之後的行版本控制進行，但這種方式並不推薦，在此不再詳細討論。
減少資源佔用:比如說查詢時，能用select
col1,col2這種方式，就不要用select
*
.這有可能帶來不必要的書簽查找
㈩ 如何查看SQLSERVER中某個查詢用了多少TempDB空間
您好，很高興為您解答。
在SQL Server中，TempDB主要負責供下述三類情況使用：
內部使用（排序、hash join、work table等)
外部使用（臨時表，表變數等）
行版本控制（樂觀並發控制）
而對於內部使用，一些比較復雜的查詢中由於涉及到了大量的並行、排序等操作時就需要大量的內存空間，每一個查詢在開始時都會由SQL Server預估需要多少內存，在具體的執行過程中，如果授予的內存不足，則需要將多出來的部分由TempDB處理，這也就是所謂的Spill to TempDB。
通過下述語句可以觀察到某個查詢對TempDB造成了多少讀寫：
DECLARE@readBIGINT,
@writeBIGINT
;
SELECT@read=SUM(num_of_bytes_read),
@write=SUM(num_of_bytes_written)
FROMtempdb.sys.database_filesASDBF
JOINsys.dm_io_virtual_file_stats(2,NULL)ASFS
ONFS.file_id=DBF.file_id
WHEREDBF.type_desc='ROWS'
--這里放入需要測量的語句
SELECTtempdb_read_MB=(SUM(num_of_bytes_read)-@read)/1024./1024.,
tempdb_write_MB=(SUM(num_of_bytes_written)-@write)/1024./1024.,
internal_use_MB=
(
SELECTinternal_objects_alloc_page_count/128.0
FROMsys.dm_db_task_space_usage
WHEREsession_id=@@SPID
)
FROMtempdb.sys.database_filesASDBF
JOINsys.dm_io_virtual_file_stats(2,NULL)ASFS
ONFS.file_id=DBF.file_id
WHEREDBF.type_desc='ROWS'
如若滿意，請點擊右側【採納答案】，如若還有問題，請點擊【追問】
希望我的回答對您有所幫助，望採納！
~O(∩_∩)O~