數據類型爲SQL_VARIANT的數值超出範圍？

Question

一個SQL服務器，除其他任務檢查所有數據庫的完整性（通過發出命令DBCC CHECKDB (blabla) WITH all_errormsgs, no_infomsgs, data_purity每一個數據庫）上的自動maintainence作業時，引發以下錯誤消息（幾百次）：

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。

Answer 1

有種感覺像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會發生什麼？ [假設你有一個可以測試的環境]