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

名站网址导航为大家提供关于数据库教程相关的教程网站知识。

SQL Server误区30日谈第12天 TempDB的网站网站文件数和需要和CPU数目保
误区 #12:TempDB的网站网站文件数和需要和CPU数目保持一致,错误,哎，由于上述误区是微软“官方”的建议，并且还有大量博文坚持这个观点，这个误区已经是老生常谈。,但让人困惑的是SQL CAT团队给出的建议就是1：1，但这个建议是源自扩展方面的原理来说,而不是一个通用法则。因为他们所面对的大型客户数据量站点服务器和IO子系统都是大部分人没有机会遇到的。,每个实例仅仅允许有一个TempDb,但需要用到TempDB的地方却有很多，所以TempDB很容易成为性能瓶颈，我想大家数人都了解这一点，而大多数人所不了解的应该是在什么情况下才需要额外的TempDB文,当您看到PAGELATCh类型的阻塞时，说明遇到内存中分配位图的争用问题了。而看到PAGEIOLATCh，说明遇到I/O子系统层面的争用问题了。对于闩锁（Latch）您可以将其看作和普通锁是一种东西，,MVP Glenn Berry 有一篇博文里有查看sys.dm_os_wait_stats的DMV。这篇博文中可以查到您的站点服务器造成阻塞最多的原因是什么。假如如果您发现是PAGELATCh型等待，您可以使,假如如果您遇到闩锁争用，可以通过跟踪标记1118或是多建一个TempDB网站网站文件来缓和这个状况(原理可以在知识库KB 328551查到),我已经写了一篇关于为什么追踪标记1118依然被需要的长博文，链接：Mi,在SQL SERVER 2000时代，TempDB的网站网站文件数需要和CPU核数保持1：1的关系，在SQL SERVER 2005和2008版本这条建议也适用，但由于SQL SERVER 2005 后的网站seo优化,[题外话：在SQL PASS 2011我的好朋友Bob Ward,也是SQL CSS最牛的人。给出了一个新的公式:假如如果CPU核数小于等于8，使其比例保持在1:1,而假如如果CPU核数大于8，使用8个网站网站文件，,不过这也不能一概而论。上周我遇到一个问题，一个客户的TempDB负载大到需要32个CPU配上64个TempDB网站网站文件才能减轻闩锁争用。这是否意味着这是一个最佳实践呢？当然不是。,那您或许有疑问，为什么1:1的比例不好呢，那是因为太多的TempDB有可能引起另一个性能问题。假如如果您的一条查询中某些操作办法（比如排序）需要使用大量的内存，但内存不够时，就需要将这些内容分配到TempDB,那为什么循环分配机制对于TempDB存在大量网站网站文件时产生性能问题呢？有如下几种可能:,所以这个选择让您进亦忧，退亦忧。到底多少TempDB网站网站文件才是合适的呢？我也不能给您具体答案，但是基于我多年咨询经验以及出席各种大会的经验，我可以给您一个指导方针---当为了解决闩锁争用时为TempDB,希望上面的指导方针对您有帮助。,PS:回应一些评论：TempDB的网站网站文件没有必要分布在多个存储器之间。假如如果您看到PAGELATCh类型的等待，即使您进行了分布也不会改善性能，而假如如果PAGEIOLATCh型的等待，或许您需要多个存储器，

误区 #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(译者

对于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

嗯，又揭示了一个误区。

关于数据库教程相关的教程网站知识今天我们就说到这里了，希望可以帮到大家。