July 15, 2014 at 7:45 am
Hi All,
I recently found (from our weekend maintenance) that one of our vendor databases encountered a corruption notice and am trying to figure out (without going straight to allow_repair_data_loss) what rows have the 'bad' data and what is the actual cause of this error:
I ran this command: dbcc checkdb ('pmdb_cn') WITH DATA_PURITY
Results:
DBCC results for 'POBS'.
Msg 2570, Level 16, State 3, Line 1
Page (1:110113), slot 10 in object ID 2121058592, index ID 1, partition ID 72057594055688192, alloc unit ID 72057594065453056 (type "In-row data"). Column "pobs_name" value is out of range for data type "varchar". Update column to a legal value.
Msg 2570, Level 16, State 3, Line 1
Page (1:110113), slot 14 in object ID 2121058592, index ID 1, partition ID 72057594055688192, alloc unit ID 72057594065453056 (type "In-row data"). Column "pobs_name" value is out of range for data type "varchar". Update column to a legal value.
Msg 2570, Level 16, State 3, Line 1
Page (1:110117), slot 38 in object ID 2121058592, index ID 1, partition ID 72057594055688192, alloc unit ID 72057594065453056 (type "In-row data"). Column "pobs_name" value is out of range for data type "varchar". Update column to a legal value.
Msg 2570, Level 16, State 3, Line 1
Page (1:110117), slot 42 in object ID 2121058592, index ID 1, partition ID 72057594055688192, alloc unit ID 72057594065453056 (type "In-row data"). Column "pobs_name" value is out of range for data type "varchar". Update column to a legal value.
There are 299 rows in 7 pages for object "POBS".
CHECKDB found 0 allocation errors and 4 consistency errors in table 'POBS' (object ID 2121058592).
DBCC results for 'HQDATA'.
There are 0 rows in 0 pages for object "HQDATA".
DBCC results for 'TPROJMAP'.
There are 0 rows in 8 pages for object "TPROJMAP".
DBCC results for 'WRK_LOG_RESULTS'.
There are 0 rows in 0 pages for object "WRK_LOG_RESULTS".
CHECKDB found 0 allocation errors and 4 consistency errors in database 'PMDB_CN'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
The table structure is this:
CREATE TABLE [dbo].[POBS](
[pobs_id] [int] NOT NULL,
[seq_num] [int] NOT NULL,
[pobs_name] [varchar](255) NOT NULL,
[pobs_parent_id] [int] NULL,
[pobs_descr] [varchar](255) NULL,
[pobs_manager] [varchar](255) NULL,
[update_date] [datetime] NULL,
[update_user] [varchar](255) NULL,
[create_date] [datetime] NULL,
[create_user] [varchar](255) NULL,
[delete_session_id] [int] NULL,
[delete_date] [datetime] NULL,
CONSTRAINT [pk_pobs] PRIMARY KEY CLUSTERED
(
[pobs_id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
I'm running on SQL Server 2008 R2 + SP3
When I do a count of the records in Management Studio, I get 303.
DBCC CHECKDB output says 299 rows.
So am I really missing 4 rows? Or is it indicating that there are 4 rows that have invalid data in the particular column? -- which wouldn't make sense as I would've figured the datatype definition wouldn't have allowed the data to be inserted in the first place.
Thanks in advance
July 15, 2014 at 8:35 am
Digging around some more, wanted to share what I found:
Using this link - http://support.microsoft.com/kb/923247
I did a DBCC PAGE on the affected pages and went to the specific slot that reported an issue. Then I was able to find the pobs_id of that row and could do a SELECT against the table and see the 'bad data':
DBCC PAGE ( pmdb_cn , 1 , 110117 , 3 )
Slot 38 Column 3 Offset 0x3c Length 255 Length (physical) 255
pobs_name = INVALID COLUMN VALUE
select * from POBS where pobs_id=6932
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
So it looks like i have 4 rows where the data is unicode (Chinese characters) and cannot fit into this column.
I'm thinking that the datatype of the column should be NVARCHAR not VARCHAR in order to accept these values and be compatible with unicode characters. The db collation is Chinese so i *think* this column should be set to nvarchar..thoughts?
July 15, 2014 at 8:38 am
You need to update the column to legal values, consider altering the column later. But there's no guarantee that that is even a legal unicode string. Somehow invalid values have crept in, who knows what that was or is supposed to be.
btw, repair can't fix data purity errors. You need to manually update the affected rows to valid values.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 15, 2014 at 8:43 am
GilaMonster (7/15/2014)
You need to update the column to legal values, consider altering the column later. But there's no guarantee that that is even a legal unicode string. Somehow invalid values have crept in, who knows what that was or is supposed to be.btw, repair can't fix data purity errors. You need to manually update the affected rows to valid values.
Right, I think the presence of question marks in the data indicate invalid values (hence SQL turning them into question marks), correct? Or values where the original data was a Unicode character that cannot be imported/non-compatible with the database collation..?
I will go back to the application admin to ask for valid values to be entered.
July 15, 2014 at 10:32 am
It's invalid values (not varchar data) that due to some bug somewhere has snuck into the table. That's about all you can say.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply