誤區 #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),對于這兩種方式如何用,請看:
- 對于SQL Server 2008,BOL入口ALTER DATABASE Compatibility Level
- 對于SQL Server 2005,BOL入口sp_dbcmptlevel (Transact-SQL).
兼容模式對于數據庫的實際版本毫無影響,數據庫的實際版本會隨著對于數據庫的升級而升級,這個升級會阻止更新版本的數據庫恢復或附加到之前的數據庫,因為之前版本的實例無法理解新版本數據庫的版本。如果想看詳細內容,請看我的一篇博文:Search Engine QA #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
嗯,又揭示了一個誤區。
您可能感興趣的文章:- SQL Server誤區30日談 第29天 有關堆碎片的誤區
- SQL Server誤區30日談 第28天 有關大容量事務日志恢復模式的誤區
- SQL Server誤區30日談 第27天 使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
- SQL Server誤區30日談 第26天 SQL Server中存在真正的“事務嵌套”
- SQL Server誤區30日談 第25天 有關填充因子的誤區
- SQL Server誤區30日談 第24天 26個有關還原(Restore)的誤區
- SQL Server誤區30日談 第23天 有關鎖升級的誤區
- SQL Server誤區30日談 第22天 資源調控器可以調控IO
- SQL Server誤區30日談 第21天 數據損壞可以通過重啟SQL Server來修復
- SQL Server誤區30日談 第20天 破壞日志備份鏈之后,需要一個完整備份來重新開始日志鏈
- SQL Server誤區30日談 第19天 Truncate表的操作不會被記錄到日志
- SQL Server誤區30日談 第18天 有關FileStream的存儲,垃圾回收以及其它
- SQL Server誤區30日談 第17天 有關頁校驗和的誤區
- SQL Server誤區30日談 第16天 數據的損壞和修復
- SQL Server誤區30日談 第15天 CheckPoint只會將已提交的事務寫入磁盤
- SQL Server誤區30日談 第14天 清除日志后會將相關的LSN填零初始化
- SQL Server誤區30日談 第12天 TempDB的文件數和需要和CPU數目保持一致
- SQL Server誤區30日談 第11天 鏡像在檢測到故障后瞬間就能故障轉移
- SQL Server誤區30日談 第10天 數據庫鏡像在故障發生后 馬上就能發現
- SQL Server誤區30日談 第9天 數據庫文件收縮不會影響性能
- SQL Server誤區30日談 第8天 有關對索引進行在線操作的誤區
- SQL Server誤區30日談 第7天 一個實例多個鏡像和日志傳送延遲
- SQL Server誤區30日談 第6天 有關NULL位圖的三個誤區
- SQL Server誤區30日談 第5天 AWE在64位SQL SERVER中必須開啟
- SQL Server誤區30日談 第4天 DDL觸發器就是INSTEAD OF觸發器
- SQL Server誤區30日談 第3天 即時文件初始化特性可以在SQL Server中開啟和關閉
- SQL Server誤區30日談 第2天 DBCC CHECKDB會導致阻塞
- SQL Server誤區30日談 第1天 正在運行的事務在服務器故障轉移后繼續執行
- SQL Server誤區30日談 第30天 有關備份的30個誤區