SQL Server误区30日谈 第13天 在SQL Server 2000兼容模式下不能使用DMV_MsSql

误区 #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

    嗯,又揭示了一个误区。

时间: 2024-10-11 12:01:37

SQL Server误区30日谈 第13天 在SQL Server 2000兼容模式下不能使用DMV_MsSql的相关文章

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

SQL Server误区30日谈 第28天 有关大容量事务日志恢复模式的误区_MsSql

误区 #28:有关大容量事务日志恢复模式的几个误区 28 a)常见的DML操作可以被"最小记录日志"    不是.在大容量事务日志恢复模式下只有一小部分批量操作可以被"最小记录日志",这类操作的列表可以在Operations That Can Be Minimally Logged找到.这是适合SQL Server 2008的列表,对于不同的SQL Server版本,请确保查看正确的列表. 28 b)使用大容量事务日志恢复模式不会影响灾难恢复    首先,在上次事务

SQL Server误区30日谈 第30天 有关备份的30个误区_MsSql

误区 #30:有关备份的30个误区全是错的在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由完整恢

SQL Server误区30日谈 第24天 26个有关还原(Restore)的误区_MsSql

本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步.事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. 误区 #24: 26个有关还原(Restore)的误区都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到特定时间

SQL Server误区30日谈 第30天 有关备份的30个误区

误区 #30:有关备份的30个误区 全是错的 在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞 不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由

SQL Server误区30日谈 第6天 有关NULL位图的三个误区_MsSql

这样还能减少CPU缓存命中失效的问题(点击这个链接来查看CPU的缓存是如何工作的以及MESI协议).下面让我们来揭穿三个有关NULL位图的普遍误区. 误区 #6a:NULL位图并不是任何时候都会用到 正确 就算表中不存在允许NULL的列,NULL位图对于数据行来说会一直存在(数据行指的是堆或是聚集索引的叶子节点).但对于索引行来说(所谓的索引行也就是聚集索引和非聚集索引的非叶子节点以及非聚集索引的叶子节点)NULL位图就不是一直有效了. 下面这条语句可以有效的证明这一点: 复制代码 代码如下:

SQL Server误区30日谈 第3天 即时文件初始化特性可以在SQL Server中开启和关闭_MsSql

本系列文章是我在sqlskill.com的PAUL的博客看到的,很多误区都比较具有典型性和代表性,原文来自T-SQL Tuesday #11: Misconceptions about.... EVERYTHING!!,经过我们团队的翻译和整理发布在AgileSharp和博客园上.希望对大家有所帮助. 误区 #3: 即时文件初始化特性可以在SQL Server中 a)开启 和 b)关闭 a)是不允许的  b)是允许的     即时文件初始化是一个在SQL Server 2005以及之上的版本鲜为

SQL Server误区30日谈 第10天 数据库镜像在故障发生后 马上就能发现_MsSql

误区10.数据库镜像在故障发生后,马上就能发现 错误 市面上大肆宣传数据库镜像技术可以在故障发生后,立即检测到错误并进行故障转移. 但事实并不是这样,检测到故障发生的速度要取决于故障的类型. 检测故障发生的最快的情况是,镜像中的主体实例崩溃,从而镜像服务器每秒一次的PING就无法返回值,从而知道主体服务器上不再有这个进程侦听相应的TCP端口,这种情况下,镜像服务器几乎瞬间就能发现故障. 检测到故障发生第二快的情况是主体服务器的操作系统崩溃.此时主体服务器不再响应镜像服务器的PING,从而在镜像服

SQL Server误区30日谈 第5天 AWE在64位SQL SERVER中必须开启_MsSql

误区 #5: AWE在64位SQL SERVER中必须开启 错误!     在坊间流传的有关AWE的设置的各种版本让人非常困惑.比如说如何设置起作用,如何设置不起作用,在32位和64位上是否需要AWE等.   好吧,我来概括一下:     在64位系统(SQL SERVER 2005+版本) AWE是不需要的(即使是ON状态,也毫无影响) 开启"锁定内存页"使得缓冲池中的内存页不会被置换到虚拟内存中(实际上所有的Single Page Allocator分配和Stolen的内存都不会被