零超出数据类型SQL_VARIANT的范围?

时间:2015-04-14 08:47:23

标签: sql sql-server tsql

SQL服务器上的自动维护作业,其中包括检查所有数据库的完整性(通过为每个数据库发出命令DBCC CHECKDB (blabla) WITH all_errormsgs, no_infomsgs, data_purity),抛出以下错误消息(几百次):< / p>

Msg 2570, Level 16, State 3, Line 1
Page (1:235), slot 22 in object ID 643585431, index ID 1, partition ID 323652991516672, alloc unit ID 42178014806016 (type "In-row data"). Column "Value" value is out of range for data type "sql_variant".  Update column to a legal value.

经过一些取证工作后,我发现它会在所有具有值为0的列的行上抛出消息。当有另一个值而不是0时,不会抛出任何错误消息。我不知道该特定值如何超出数据类型sql_variant的范围。

此数据库是商业产品的一部分,我没有设计输入,维护工作是安装服务器的公司必须的。我最感兴趣的是为了知道数据库辅助检查如何将值0视为超出范围,以查看它是否可修复。所有错误都被捕获并发送到总部,因此必须由一些可怜的灵魂进行评论和回应,因此能够避免这种无意义的错误会很好。

服务器操作系统是Windows Server 2012 Standard,Microsoft SQL Server版本是11.0.5058.0。

1 个答案:

答案 0 :(得分:0)

有点像DBCC CHECKDB中的虚假错误,但我无法相信MSSQL工程师会在没有理由的情况下将其放入。

当我跑到下面时:

-- test database
CREATE DATABASE test
GO
USE test
GO
-- test-table
CREATE TABLE t_variant ( row_id int IDENTITY(1, 1) PRIMARY KEY,  variant1 sql_variant NULL, variant2 sql_variant NOT NULL)

INSERT t_variant (variant1, variant2) VALUES (1, 2), (NULL, 3), (NULL, 0), (0, 0)

SELECT * FROM t_variant
GO
-- see how things look 'on disk'
SELECT TOP 100 * FROM sys.partitions WHERE object_id = object_id('t_variant')
SELECT TOP 100 * FROM sys.allocation_units u JOIN sys.partitions p ON p.partition_id = u.container_id AND p.object_id = object_id('t_variant')

GO

USE tempdb
GO
DBCC CHECKDB (test) WITH all_errormsgs, no_infomsgs, data_purity

我似乎正在复制你描述的情况,但CHECKDB没有给出任何警告/错误。

-- having a look on the lowest level
DBCC TRACEON (3604) -- otherwise not output, just for this connection
DBCC IND ('test', t_variant, -1) -- shows the pages involved, I have 2 of them but from the error you have I'd focus on PageType 1 (data) only
DBCC PAGE ('test', 1, 515, 1) -- (= db_name, PageFID, PagePID, print-option-1)

-- the output is rather chinese but shows me the different slots (records) and their 'hex' information. I'm guessing that when you do
-- DBCC PAGE ('blahblah', 1, 235, 1) you may find some zero's there that DBCC CHECKDB thinks shouldn't be there... 

出于好奇,当您将值更新为其他内容然后返回0时会发生什么? [假设你有一个可以测试它的环境]