推薦：怎樣清除SQL Server日志
方法一 一般情況下，SQL數據庫的收縮并不能很大程度上減小數據庫大小，其主要作用是收縮日志大小，應當定期進行此操作以免數據庫日志過大 1、設置數據庫模式為簡單模式：打開SQL企業管理器，在控制臺根目錄中依次點開Microsoft SQL Server--

你知道SQL Server這么龐大的企業級數據庫服務器產品是如何build出來的嗎?

這有些相關的數據：

每個build 的大小在300GB左右。

每個完整的build需要幾十臺高端的服務器運行2.5天。

每個完整的build由幾千個job、10000多個參數組成。

我們每天同時做20個左右的build，每周130個。

位于美國微軟總部雷蒙德和北京的build團隊能夠保證build全天24小時不間斷的順利進行。

從去年至今，我們build team已經成功而準時地完成了數以千計的build。

也許你會問：你們的build怎么這么大?怎么需要這么長的時間?為什么你們每天要做這么多build?

為什么我們的一個build這么大?比如說你的32位中文零售開發版SQL Server的DVD，包括工具和幫助文檔是4GB，那么你可以這樣估算一下：首先加上一些內部的build信息和統計，以及用于debug的Symbol，然后乘以2(retail版，debug 版)，再乘以3(CPU 類型：x86、x64和ia64)，再乘以所有的版本數(企業版、開發版、標準版等)，最后再乘以支持的語言數。不只1個TB 了吧?J 幸好SQL 2008 的setup 團隊采用了consolidated setup模式，這樣在一個語言包中，安裝程序可以判定你的CPU類型并根據你輸入的產品序列號，自動安裝對應的版本。由此我們的build才壓縮到了300GB。

為什么我們的一個build需要這么長時間?Build這么龐大的企業級數據庫服務器產品是一個極其復雜的過程，況且SQL Server的build 系統已經是微軟內最為高效的系統之一。她是圖形化用戶界面并且高度自動化的。歷經60小時，多數build會順利的自動完成并通知相關人員其build的狀態及信息。如果build失敗，其也會提供詳細的錯誤信息用于debug。SQL Server的build 系統不僅如此易用和高效，同時可以靈活的適應某些特殊的需求和build工作流。SQL Server的build 系統是由Windows Workflow Foundation驅動的，其數以千計的job被并行或串行的分發到幾十臺 build機器上并完成。build的過程包括：

將幾十GB的源文件及相關的所需文件和資源同步到build機器上

源代碼靜態分析

編譯所有的可執行文件和測試文件并簽名

生成系統數據庫

優化

本地化

制作安裝文件和安裝包并簽名

索引Symbol和源文件

我們每天做這么多的build正體現了我們如何支持整個SQL Server工程體系和構架：

首先需要聲明的是我們隨時都在為多個產品提供支持，比如當前的SQL Server 2005和即將發布的SQL Server 2008。

在SQL Server 2008的工程體系和構架中，我們將每個需要增加或增強的功能特性做成一個單獨的分支，在這個功能特性開發和測試完成后，其代碼才會合并到SQL Server的主線代碼中。因此根據功能特性的優先級和大小，SQL Server分成了幾十個不同的團隊，每個團隊包括了架構師、項目經理、開發和測試人員，幫助及案例文檔專員，甚至科學家和科研人員。每個分支都需要build來進行及時的測試，因此有了這個我們當前每周需要的build個數——130。當build結束后，Test Execution team和其分支團隊會執行自動測試來確保其代碼的質量符合嚴格的要求和標準。最后當這個功能特性開發和測試完成后，其代碼將會融入到SQL Server的主線代碼中，然后其它各個分支團隊將重新獲取主線代碼并融合其分支的當前代碼，來保證和主線代碼的同步

分享：解決SQL Server數據庫權限沖突的三大妙招
在SQL Server數據庫中，主要是通過角色來繼承相關的權限。但是，這個權限繼承很容易造成權限上的沖突。如現在有個銷售員賬戶SALE1，有一個銷售部門角色DE_SALES。其中銷售部門角色DE_SALES具有查詢所有客戶信息，即CUSTOM表的權限。但是銷售員賬戶SALE1其由