This is a very interesting error happened in one of my clients’ databases. Their database has been running for at least 12 years without a single problem. They run DBCC CheckDB regularly to ensure the database is in healthy state until few days ago their DBA ran DBCC CHECKTABLE with data_purity and get
Msg 2570, Level 16, State 3, Line 1 Page (1:118), slot 0 in object ID 245575913, index ID 0, partition ID 72057594039042048, alloc unit ID 72057594043432960 (type "In-row data"). Column "Value" value is out of range for data type "numeric". Update column to a legal value.
Finally, they found this article, , http://support.microsoft.com/kb/923247. — Many things can cause this kind of error. In this blog post, I am going to demo how I repeat and fix this error — for fun.
use master create database Test1; -- create a new database for testing go use Test1 go create table t1(Value numeric(5,1)) go insert into t1 values(0) insert into t1 values(0) -- create a table and put 2 zeros go select * from t1 select distinct Value from t1 --Ensure the data are correct. /* Value --------------------------------------- 0.0 0.0 (2 row(s) affected) Value --------------------------------------- 0.0 (1 row(s) affected) */go dbcc checkdb -- no problem go -- Now let's find out where the data located dbcc traceon(3604) go dbcc ind(test1, t1,0) -- page 118 on my machine go dbcc page (test1, 1, 118, 1) go /* Slot 0, Offset 0x60, Length 12, DumpStyle BYTE Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 12 Memory Dump @0x000000001424A060 0000000000000000: 10000900 01000000 00010000 ........... Slot 1, Offset 0x6c, Length 12, DumpStyle BYTE Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 12 Memory Dump @0x000000001424A06C 0000000000000000: 10000900 01000000 00010000 ........... */
Now we have 2 rows on the page 118. each record has 12 bytes. Look at the body above, there are 3 segments of numbers for each records. The segment in the middle contains the numeric number. We notice that it’s 0x01000000 in which it presents the value of the field with the byte next to it. The first byte in this case is presented as sign. Now let’s do some modification to that byte. I am going to change it from 0x01 to 0x00 to see what will happen
dbcc writepage(test1, 1, 118, 100, 1, 0x00) go ---the data is changed, if I run select, no error returned select Value from t1 /* Value --------------------------------------- 0.0 0.0 (2 row(s) affected) */---What if I run distinct, will SQL Server identify them as 2 numbers or 1 number/ select distinct Value from t1 /* Value --------------------------------------- 0.0 0.0 (2 row(s) affected) */-- interesting enough, SQL Server thinks they are 2 numbers. go --what if I run a search? SQL thinks -0 is less than zero select Value from t1 where Value = 0 select Value from t1 where Value < 0 /* Value --------------------------------------- 0.0 (1 row(s) affected) Value --------------------------------------- 0.0 (1 row(s) affected) */go
DBCC CheckDB will give you the error at the beginning of the article. Using REPAIR_REBUILD option can’t fix the problem. We can’t afford to use with data loss option to fix the data. We come up with the solution to update -0s to +0s.
update t1 set Value = 0 where ABS(value) = 0 and ABS(value)!= Value
After the update statement, DBCC CheckDB no longer reports errors. This database was created in the version prior to SQL Server 2005. It was upgraded when a new major version was on the market. According to the article, The data purity check was disabled while upgrading. that’s why DBAs did not figure out this problem in last few years. If you have the database upgraded from earlier version of SQL Server, I would highly recommend you to run DBCC CheckDB with Data_Purity.
