误区 #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 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
嗯，又揭示了一个误区。
您可能感兴趣的文章: 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个误区
查看更多关于SQLServer误区30日谈第13天在SQLServer2000兼容模式下不能使用DMV的详细内容...