Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

John Huang’s Blog

John Huang, Microsoft Certified Master in SQL Server, SQL Server MVP, is an independent SQL Server consultant in Vancouver BC, Canada. He started using SQL Server for his projects in year 1994. He has architected and implemented many SQL and BI applications serving different industrial areas. He loves talking about SQL Server and discussing SQL Server technologies with others. He blogs at http://www.sqlnotes.info.

SQL Server +0 and -0

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.

http://www.sqlnotes.info

Share/Bookmark

Comments

Leave a comment on the original post [www.sqlnotes.info, opens in a new window]

Loading comments...