Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
ACALVETT
Starting Member
34 Posts |
 Posted - 2005-10-10 : 10:47:32
|
| Hiya,Our weekly DBCC picked up a consistency error on a table (see end of post). After the dbcc's, all the indexes were rebuilt and this seems to of cured the problem. I`m however concerned that its occured and want to understand the problem better and am looking for any general advice.The last time i had this type of error it use to occur every few weeks and turned out to related to KB834628.I`m running SQL 2000 SP3, build 911 on Windows 2003 RTM active active cluster. 7gb ram dual proc with PAE in boot.ini and AWE enabled for SQL.ALso i've now set dbcc's to run daily. All help appreciated! Ta[Microsoft][ODBC SQL Server Driver][SQL Server]Object ID 322360463, index ID 0: Page (1:544817) could not be processed. See other errors for details.[Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID 322360463, index ID 0, page (1:544817), row 17. Test (columnOffsets->offTbl [varColumnNumber] <= (nextRec - pRec)) failed. Values are 30821 and 324.[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation errors and 2 consistency errors in table 'S_WFR_STP_ARG' (object ID 3 |
|
|
paulrandal
Yak with Vast SQL Skills
899 Posts |
Posted - 2005-10-11 : 13:52:05
|
| That's an impressively wrong offset into a record.When you say you used to get this before, was it with the exact same symptoms? I take it you applied the PAE hotfix? How long ago was that?Does this table have a clustered index? Looks like it doesn't have any non-clustered indexes from the lack of non-clustered index extra-row errors I'd expect to see if a base table page is not processed.As an aside, why do you rebuild all the indexes as part of your maintenance job?ThanksPaul RandalDev Lead, Microsoft SQL Server Storage Engine(Legalese: This posting is provided "AS IS" with no warranties, and confers no rights.) |
 |
|
|
ACALVETT
Starting Member
34 Posts |
Posted - 2005-10-12 : 05:38:57
|
| I can't say with my hand on heart that its exactly the same as it was almost 10 months ago. Also it was on one of our overseas clusters, not this one. PAE hotfix was applied when it first came out (Its now applied by default because its been rolled into a security hotfix and its our policy to apply those immediately).It has a clustered index and 2 non-clustered.On the aside we take the approach that if we can rebuild our indexes on a weekly basis we do so that the statistics are kept up to date and index fragmentation is kept to a minimum. We do this on all our systems that users don't use in the small hours or where the rebuilds are processed quickly enough for the users not to notice the impact of a brief table lock. It is a sledge hammer to crack a nut approach but it works well for us. :D On our larger systems (of which there are a few) we take a different approach. Use indexdefrag, update stats etc as appropriate and we analyse the fragmentation use showcontig to determine benefit etc etc.Thanks for the reply.Andrew |
|
|
|
paulrandal
Yak with Vast SQL Skills
899 Posts |
Posted - 2005-10-13 : 12:45:17
|
| Fair enough on the aside - glad to see you're taking the intelligent approach on the larger systems.I'm surprised that the CHECKDB output din't contain errors about the non-clustered indexes having too many rows.Are there any signs of h/w problems in the Windows event logs or SQL errorlogs?The error is basically saying that the variable length column offset array is corrupt. It contains a list of pointers into the record to the start of each variable length column. As you can see, 30821 is not a valid in-record offset. It doesn't seem to be any special binary or hex pattern so I can't say what may be causing it.My advice is to open a case with PSS and let them help you diagnose it.When you do the rebuild of the clustered index, does the rowcount (select count(*) - not the persisted one in metadata) remain the same?ThanksPaul RandalDev Lead, Microsoft SQL Server Storage Engine(Legalese: This posting is provided "AS IS" with no warranties, and confers no rights.) |
|
|
|
ACALVETT
Starting Member
34 Posts |
Posted - 2005-10-14 : 09:32:56
|
| Thanks Paul, will do some more monitoring and trouble shooting at our end and then raise a call.No signs of h/w problems.select count(*) remains the same.CheersAndrew |
|
|
|
|
|
|
|
|
Consistency Erros.