推薦：SQL Server 2005查看文件及文件組的語句
SQL Server 2005查看文件及文件組的語句: 具體示例如下： 以下為引用的內容： 　SELECT df.[name], df.physical_name, df.[size], df.grow

SQL Server 2008已經(jīng)發(fā)布，我們可以看到它在各方面都有了顯著的進步，這些讓人側目之處和失望之處都有可能極大地影響大型企業(yè)的采購意向。

微軟SQL Server 2008的開發(fā)代號是Katmai，這個名字來源于阿拉斯加半島東端阿拉斯加州北部阿留申山區(qū)的一座活火山，對數(shù)據(jù)庫而言，可能并不是個最好的比喻（嘿嘿，目前為止，Katmai火山還沒有在我頭上爆發(fā)過）。低調的Katmai看起來似乎是Yukon的一個好的接班人，而Yukon是SQL Server 2005的開發(fā)代號。

在基于對SQL Server 2005徹底的、面向企業(yè)的改進之后，Katmai為大規(guī)模部署帶來了非常引人注目的特性，比如數(shù)據(jù)庫引擎中的數(shù)據(jù)及備份壓縮、稀疏列、壓縮與過濾索引，這些功能都是為了節(jié)省存儲空間，環(huán)保、綠色；另外，別忘了還有Change Data Capture，其在表中捕捉生成數(shù)據(jù)的差別，以便更新數(shù)據(jù)倉庫。

這些都只不過是冰山一角（喔，不是冰山是火山），還有許多其他的新特性，如基于策略的管理——這是針對中小企業(yè)和大型企業(yè)的，不僅這些，SQL Server 2008的各個方面都讓人留下了深刻的印象。

更多的數(shù)據(jù)，更少的存儲空間

一般來說，數(shù)據(jù)庫中有兩種類型的壓縮：行壓縮與頁壓縮。實際上，它們以不同的方法壓縮數(shù)據(jù)，因此，很有必要理解兩者的優(yōu)勢所在及它們的工作方式。行壓縮是真正的壓縮，為什么數(shù)據(jù)庫引擎會刪除列尾未使用的空間呢？當然這是為了節(jié)省空間。這正是SQL Server在vardecimal壓縮中使用的同一技術，微軟只不過把它擴展到其他數(shù)據(jù)類型上了。

而頁壓縮使用的是眾所皆知的字典壓縮，它把每頁中的數(shù)據(jù)標準化之后并保留一個查找指針。這也是Oracle Database 11g所使用的技術，只不過Oracle稱之為Oracle高級壓縮。在此，我們無須對兩種壓縮方式了解過多，但必須知道SQL Server的頁壓縮包括了更低級的行壓縮，換句話來說，如果你打開了頁壓縮，就自動打開了行壓縮。

在SQL Server 2008中，微軟已經(jīng)包含了幾個存儲過程，以方便你在開始壓縮之前，就可以估計使用哪種壓縮方法之后，兩者的節(jié)省水平，以及解壓數(shù)據(jù)庫之后，數(shù)據(jù)將會擴展到多大。這是一個非常重要且體貼的功能，因為你不僅需要了解是否值得花時間壓縮，而且還要知道磁盤是否處理得了還原后未壓縮的數(shù)據(jù)。但要緊記的是，這些存儲過程是基于小范圍的統(tǒng)計上的隨機數(shù)據(jù)采樣，如果碰巧遇到一個數(shù)據(jù)上的采樣失誤，那么就會得到錯誤的估計結果。

另外，微軟實現(xiàn)壓縮的方法，節(jié)約的不僅僅是存儲資源，數(shù)據(jù)還可以在內存中保持壓縮狀態(tài)，只在讀取時才解壓，這意味著你可以把更多的數(shù)據(jù)頁裝入內存中，由此減少磁盤讀取次數(shù)，而CPU用于解壓的時間，也遠遠少于磁盤尋道的時間。

稀疏列允許你存儲空值而無須占用物理空間，如果在一張“巨大”的表中，列有許多空值，可能會浪費大量的磁盤空間來跟蹤這些空值。而把空值存儲在稀疏列中則不會占用任何空間，存儲需求也會隨之降低。

在使用稀疏列時要非常留意一點，它們與壓縮不兼容，坦白地說，這是微軟的一大失誤。希望本著為用戶著想的原則，在某個Service Pack中就能更正這個問題，而不是要等到下個版本。同時，如果你在表中也定義了稀疏列，那么也不要指望會壓縮表中的數(shù)據(jù)，真是不知道微軟是怎么搞的，這些本不應該出現(xiàn)在正式產品中的。如果非要說稀疏列與壓縮他倆是一對完美的組合，那“如花”可能也配得上金城武了。

壓縮索引還像碼事，至少名符其實，這又是節(jié)省存儲空間的另一個方法。過濾索引可以在索引上放置一個where子句（如某條查詢），以便只有表的一部分被索引。聽上去似乎不太妥當，但在某些情況下你可能就會想要過濾某些索引了，舉個例子來說，在使用稀疏列時，有了過濾索引就無須保持一個包含了主要是空值的索引，你可在稀疏列上放置一條索引，只取那些非空值就行了。這樣做以后，只有那些帶有實際值的行會被索引，而索引的體積也會相應大幅減小。

工作負荷是好，還是差？

Resource Governor是微軟在SQL Server中真正對資源管理的一次嘗試，老實講，根本就比不上Oracle，但仍是一個好的開始。SQL Server 2008允許你在內存和CPU中定義資源限制，但在重負荷工作情況下仍然差強人意。

微軟對此的回應是，Resource Governor不是旨在滿足重負荷工作要求，在這第一個版本中，目標僅是管控工作負荷中的那些資源，以防止它們變成“野”進程。當然了，這仍未解決過度占用磁盤或處理器時間的問題。在SQL Server 2008中，如果一個進程開始占用過多的資源，那么也沒有辦法自動把它挪到一個定義好的Resource Governor中，也就是說，一個進程要么在資源上受Resource Governor管控，要么就不受控。

其實這個特性最大的受益者是OLTP（在線交易或聯(lián)機事務處理）系統(tǒng)，其只會產生一些輕量級的數(shù)據(jù)，如果不想它占用過多服務器資源，可把查詢進程放入它們自己的Resource Governor中，以管控資源使用量，使服務器的大部分功率都用于OLTP負載，賺取真正的“真金白銀”啊。

CDC（Change Data Capture，改變數(shù)據(jù)采集）是一個非常好的功能，我想對那些整日與ETL（取出、轉換、加載）處理“扭打”的數(shù)據(jù)庫管理員來說，它會非常受歡迎。CDC允許SQL Server在定義的列中，捕捉到哪些行列已改變，并把變化的結果放入到一張可被ETL查詢的單獨的表中。好處顯而易見，對哪些行被插入、刪除或更新，就不再需要廣泛地進行查詢了。當前來說，在一張表中發(fā)現(xiàn)這些操作并不容易，經(jīng)常還需要編寫代碼才能找出來。但有了CDC之后，你就可在數(shù)據(jù)庫級別上定義這些審計策略，不用修改程序代碼，一邊看報紙喝茶去啰。

SQL Server 2008還帶來了基于策略的管理（PBM），其是一種可為任何事件定義策略（規(guī)則）的方法，可在服務器超出策略時，要么強制執(zhí)行，要么發(fā)出警報。你幾乎可在策略中定義任何事情，甚至像“表名不能以tbl打頭”這樣的策略也可以強制執(zhí)行；還可以定義如“所有數(shù)據(jù)庫都應每天備份，如果某臺服務器缺少備份，應發(fā)出警報。”PBM正成為SQL Server發(fā)展中一個非常強大的工具，至少我也非常喜歡它。

SQL Server 2008的閃光之處

SQL Server 2008帶來了太多的新功能，片言之間難以表述，筆者甚至都還沒有試一下完全重寫后的SQL Server Reporting Services，或體驗一下SQL Server Integration Services、SQL Server Analysis Services中的全部功能，還有新的數(shù)據(jù)倉庫、交互式Dundas向下搜索報告、IntelliSense（智能感知）、新的活動監(jiān)視器、集成PowerShell等等。

對多數(shù)大型企業(yè)來說，我認為SQL Server 2008最大的亮點在于數(shù)據(jù)壓縮及CDC，因為兩者都會影響到企業(yè)的預算。Resource Governor是一個非常好的功能，但目前它還比較“稚嫩”，局限太多，還未達到微軟期望的水平，相信再經(jīng)過幾個版本，它定會不負眾望。

壓縮及過濾索引這次想必給大家?guī)�來了不一樣的感覺，雖然過濾索引存在上面提到的一些小問題，但如果你把它們用對地方，也能看到所期望的性能提升。另外，在其他工具方面也有了一些重大的改進，但對數(shù)據(jù)庫管理員來說，他們可能要失望了，因為這些改進都是針對開發(fā)人員的。

分享：解析在IIS中為SQL Server 2008配置報表服務
不知道是不是SQL Server 2008的Bug，我在安裝了SQL2008后(選擇了安裝報表服務的)，但是在IIS中根本沒有報表服務的虛擬目錄。只是這么一個問題，其他BI設計器、報表服務等都還算正常。