推薦：看Sql server 2005 找出子表樹
同事在準備新老系統(tǒng)的切換，清空一個表的時候往往發(fā)現(xiàn)這個表的主鍵被另一個表用做外鍵，而系統(tǒng)里有太多層次的引用.所以清起來相當麻煩 用下面這個腳本可以做到找出一個特定表的引用

SQL Server通常都運行在多處理器的服務器上，這一點在現(xiàn)在尤為普遍。原因是多內(nèi)核的處理器越來越普及。那么，在多處理器環(huán)境下，Windows操作系統(tǒng)(事實上是從2000開始的)通常都會將進程任務放在一個隊伍里面，然后讓這些處理任務依次去占有處理器進行計算。

這樣做的好處就是每個計算任務都可以獲得近似于平均的處理資源，盡管無法保證一個處理任務每次都能拿到同一個處理器。這就像嘉年華我們重復排隊參加一個刺激的項目(比如說自由落體，事實上我從來不參加這種項目)，每個人上去一輪，并不能保證每次都能做同一張位置。

不過回到SQL Server上面來，SQL Server可不喜歡這樣的處理機制。

大家可能都知道處理器中有個東西叫片內(nèi)緩存，片內(nèi)緩存有1級、2級、3級之分。

我們假設處理器要計算A、B、C三個任務，處理器先運算A任務，A任務還沒有結束的時候它的游戲時間就結束了，因此處理器在接受B的時候會將計算B所需的數(shù)據(jù)加載到1級片內(nèi)緩存中，而將A任務(我們假設處理器還沒有完成它的計算任務)的數(shù)據(jù)挪到2級片內(nèi)緩存中，或者3級。

當那個A任務回來的計算的時候，處理器會從2級片內(nèi)緩存中恢復計算所需的數(shù)據(jù)，當然這要取決于是不是那些數(shù)據(jù)還在2級緩存中，因為有很多因素可以讓它不在那兒，比如說A任務回來的時候發(fā)現(xiàn)接待它的已經(jīng)不是原來那個處理器了，當然A任務就不能指望面前這個處理器有它的計算數(shù)據(jù)了(當然計算A任務回到同一顆處理器，也可能因為其他任務占用了這個處理器的2級片內(nèi)緩存而導致它原來存入的數(shù)據(jù)被替換掉了)。

如果處理器發(fā)現(xiàn)A任務數(shù)據(jù)還在2級片內(nèi)緩存中，操作系統(tǒng)就認為這次命中了2級緩存，如果不在了，就說這次沒有命中2級緩存。因此我們可以知道操作系統(tǒng)是非常渴望每次都命中2級緩存的，因為這樣就可以節(jié)省不少時間重新從內(nèi)存中將數(shù)據(jù)加載到片內(nèi)緩存中。

大多數(shù)操作系統(tǒng)要面對的任務都不會有太多的計算數(shù)據(jù)，因此這些任務不需要太多關心片內(nèi)緩存的問題。同時多數(shù)低端的服務器也沒有很大的片內(nèi)緩存，因此它們也不太關心這個問題。不過對于運行在有較大片內(nèi)緩存的服務器上的SQL Server來說，這個問題就要嚴肅一些了。

在中高端的PC服務器(為什么說是PC服務器呢，因為Windows現(xiàn)在還可以運行在一些廠商的小型機平臺上，例如HP的SuperDome)中，通常單個處理器的片內(nèi)緩存都在2M-4M，而且這些服務器可以擁有8個甚至更多一些的處理器，同時SQL Server的計算任務都是依賴于大量數(shù)據(jù)的，因此SQL Server的一個任務可不希望它重新拿回處理器的時候發(fā)現(xiàn)自己的數(shù)據(jù)不在了。

為了解決這個問題，SQL Server就有了這個處理器親和度(Processor Affinity)的配置項，啟用這個選項后，SQL Server中的任務就會記著自己原來在那個處理器上工作的，當它們再次有機會回到處理器工作的時候它們會認準回家的路——只用原來的那顆處理器。(事實上這個過程要復雜一些，有興趣的朋友可以進一步了解SQL Server中調(diào)度這個概念)。

分享：解讀動態(tài)SQL語句的編程
動態(tài)SQL語句中的參數(shù)，我們可以通過兩種途徑來為它賦值： 1. 利用參數(shù)編輯器(Parameter Editor)來為參數(shù)賦值 具體方法是：選中TQuery部件，單擊鼠標右鍵，然后從中選擇Define Pa