Zero вне диапазона для типа данных SQL_VARIANT?

Question

Автоматическое ОБСЛУЖИВАНИЕ Работа на сервере SQL, который помимо других задач, проверяет целостность всех баз данных (с помощью команды DBCC CHECKDB (blabla) WITH all_errormsgs, no_infomsgs, data_purity для каждой базы данных), выдает следующее сообщение об ошибке (несколько сот раз):

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 - 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? [при условии, что у вас есть среда, где вы можете проверить это)