SQL Server誤區30日談 第13天 在SQL Server 2000兼容形式下不克不及應用DMV。本站提示廣大學習愛好者：（SQL Server誤區30日談 第13天 在SQL Server 2000兼容形式下不克不及應用DMV）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server誤區30日談 第13天 在SQL Server 2000兼容形式下不克不及應用DMV正文
誤區 #13.在SQL Server 2000兼容形式下不克不及應用DMV
毛病
關於兼容形式曾經存在了許多誤會。80的兼容形式的數據庫能否意味著可以或許附加或恢復到SQL Server 2000數據庫?固然不是。這只是意味著一些T-SQL的語法，查詢籌劃的行動和一些其它方面和SQL Server 2000中行動一樣（固然，假如你設置成90兼容形式則和SQL Server 2005中一樣）。
在SQL Server 2008中，你可使用ALTER DATABASE SET COMPATIBILITY_LEVEL敕令來轉變兼容形式,關於SQL Server 2008之前的版本，則應用體系存儲進程sp_dbcmptlevel(譯者注：好比sp_dbcmptlevel @dbname='AdventureWorks',@new_cmptlevel=100)，關於這兩種方法若何用，請看:
兼容形式關於數據庫的現實版本毫無影響,數據庫的現實版本會跟著關於數據庫的進級而進級，這個進級會阻攔更新版本的數據庫恢復或附加到之前的數據庫,由於之前版本的實例沒法懂得新版本數據庫的版本。假如想看具體內容，請看我的一篇博文:Search Engine Q&A #13: Difference between database version and database compatibility level.還有假如當你附加新版數據庫到老版本實例時所碰到的毛病信息:Msg 602, Level 21, State 50, Line 1。
在SQL Server 2005中設置為80兼容形式，貌似DMV就不克不及用了，運轉上面代碼創立測試數據庫:
CREATE DATABASE DMVTest;
GO
USE DMVTest;
GO
CREATE TABLE t1 (c1 INT);
CREATE CLUSTERED INDEX t1c1 on t1 (c1);
INSERT INTO t1 VALUES (1);
GO
EXEC sp_dbcmptlevel DMVTest, 80;
GO
SELECT * FROM sys.dm_db_index_physical_stats (
DB_ID ('DMVTest'), -- database ID
OBJECT_ID ('t1'), -- object ID <<<<<< Note I'm using 1-part naming
NULL, -- index ID
NULL, -- partition ID
'DETAILED'); -- scan mode
GO
你會獲得以下報錯信息:
新聞 102，級別 15，狀況 1，第 3 行
'(' 鄰近有語法毛病。
看上去這足以證實80兼容形式不支撐DMV。但其實其實不是那樣。
編者:寫到這裡以後，我忽然認識到我墮入了一個悖論。DMV在80兼容形式下是完整支撐的，但不支撐的是在80兼容形式下挪用函數作為DMV的參數。
上面是一個可以在80兼容形式下應用函數作為DMV參數的技能，不能不說是神來之筆。那就是在一個90以上兼容形式的數據庫下額定挪用80兼容形式下的數據庫，看上面代碼:
USE master
SELECT * FROM sys.dm_db_index_physical_stats (
DB_ID ('DMVTest'), -- database ID
OBJECT_ID ('DMVTest..t1'), -- object ID <<<<<< Note I'm using 3-part naming here now
NULL, -- index ID
NULL, -- partition ID
'DETAILED'); -- scan mode
GO
固然DMVTest數據庫任務在80兼容形式下，但上述代碼仍然可用。
然則有一點值得留意的是,你必定要包管Object參數的准確,假如你僅僅讓第二個參數照樣OBJECT_ID ('t1'), 那末這個函數會測驗考試在Master數據庫中找表t1,正常來講這就會前往NULL，這就招致適才誰人DMV以NULL作為參數，從而前往了一切DMVTest表下的索引狀況.而假如Master表中也有一個DMV，那就更不幸了，你將獲得毛病的信息。
還有，sys.dm_db_index_physical_stats其實不算是一個真實的DMV，而是一個在後台處置年夜量信息後前往相干信息的DMF，是以假如你以NULL作為參數前往一切的索引信息的話，那價值會異常昂揚，你可以看我比來的博文Inside sys.dm_db_index_physical_stats，這篇文章會對細節和價值停止具體的說明。
還有一種在80兼容形式下應用DMV的方法是不再DMV中以函數作為參數，而是傳變量出來，代碼以下:
DECLARE @databaseID INT;
DECLARE @objectID INT;
SELECT @databaseID = DB_ID ('DMVTest');
SELECT @objectID = OBJECT_ID ('t1');
SELECT * FROM sys.dm_db_index_physical_stats (
@dbid, -- database ID
@objid, -- object ID
NULL, -- index ID
NULL, -- partition ID
'DETAILED'); -- scan mode
GO
嗯，又提醒了一個誤區。
