Hello there!
Where to turn if not to this group when one is in dire need and all
other resources have been tried? =)
But ok - now for the serious part. Our maintenance plan failed to
execute yesterday, a certain table 'memberContacts' couldn't be
reindexed and was left inaccesible!!! :(
Ok, so currently 'memberContacts' has about 800 000 rows, not that much
really. The failure is related to indexex, and if we look at the table
using 'sp_helpIndex' - we get the following (where I suppose that the
autogenerated '== ?' and '?8 ' seems like bad moves) :
---
== ? clustered, hypothetical, auto create located on PRIMARY
ContactDate, ReturnDate, OfficeID
hind_18203215_10A_3A nonclustered, hypothetical, auto create located on
PRIMARY OfficeID, ContactDate
hind_18203215_10A_4A nonclustered, hypothetical, auto create located on
PRIMARY OfficeID, ReturnDate
hind_18203215_10A_9A nonclustered, hypothetical, auto create located on
PRIMARY OfficeID, TempLockedByAdminUser
hind_18203215_3A_10A nonclustered, hypothetical, auto create located on
PRIMARY ContactDate, OfficeID
hind_18203215_3A_4A nonclustered, hypothetical, auto create located on
PRIMARY ContactDate, ReturnDate
hind_18203215_3A_4A_10A nonclustered, hypothetical, auto create
located on PRIMARY ContactDate, ReturnDate, OfficeID
hind_18203215_3A_4A_9A nonclustered, hypothetical, auto create
located on PRIMARY ContactDate, ReturnDate, TempLockedByAdminUser
hind_18203215_3A_9A nonclustered, hypothetical, auto create located on
PRIMARY ContactDate, TempLockedByAdminUser
hind_18203215_4A_10A nonclustered, hypothetical, auto create located on
PRIMARY ReturnDate, OfficeID
hind_18203215_4A_3A nonclustered, hypothetical, auto create located on
PRIMARY ReturnDate, ContactDate
hind_18203215_4A_9A nonclustered, hypothetical, auto create located on
PRIMARY ReturnDate, TempLockedByAdminUser
hind_18203215_9A_10A nonclustered, hypothetical, auto create located on
PRIMARY TempLockedByAdminUser, OfficeID
hind_18203215_9A_4A nonclustered, hypothetical, auto create located on
PRIMARY TempLockedByAdminUser, ReturnDate
hind_c_18203215_10A clustered, hypothetical, auto create located on
PRIMARY OfficeID
hind_c_18203215_3A clustered, hypothetical, auto create located on
PRIMARY ContactDate
hind_c_18203215_4A clustered, hypothetical, auto create located on
PRIMARY ReturnDate
hind_c_18203215_9A clustered, hypothetical, auto create located on
PRIMARY TempLockedByAdminUser
IX_ContactDate nonclustered located on PRIMARY ContactDate
IX_MemberID nonclustered located on PRIMARY MemberID
IX_ReturnDate nonclustered located on PRIMARY ReturnDate
IX_TempLockedByAdminUser nonclustered located on PRIMARY
TempLockedByAdminUser
?8 clustered, hypothetical, auto create located on PRIMARY
ContactDate, ReturnDate
MemberContacts1 clustered located on PRIMARY
TempLockedByAdminUser, ReturnDate
PK_MemberContacts nonclustered, unique, primary key located on PRIMARY
MemberContactID
---
Now removing the badly named autogenerated indexes probably should solve
the problem. But since these are named quite inproperly the can't be
deleted. And any 'selects' or other attempts to view the table resulst
in :
---
ODBC: Msg 0, Level 19, State 1
SqlDumpExceptionHandler: Process 57 generated fatal exception c0000005
EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.
Connection Broken
---
So how do I go about removing the bad indexes?
MANY MANY MANY THANX (and a very merry x-mas to you all)
Regards,
JohanJust found the answer - in article
http://support.microsoft.com/default.aspx?
scid=http://support.microsoft.com:80/support/kb/articles/Q293/1/77.ASP&N
oWebContent=1
But since this only recognizes the problem with 'hind%'-indexes you'll
have to adjust statement to include (for example) '== '. This problems
seems to have been a well known fact for sql7 and "known" for sql2000.
After scanning this newsgroup it seems that I'm not the only one
experiencing this problem, and it seems to have risen to "fame" with
sp3a...
2 words - "fuck" & "microsoft"...
Peace,
Johan
In article <MPG.1a479cba5768a7ea989680@.news.internet5.net>, johan@.fap.se
says...
> Hello there!
> Where to turn if not to this group when one is in dire need and all
> other resources have been tried? =)
> But ok - now for the serious part. Our maintenance plan failed to
> execute yesterday, a certain table 'memberContacts' couldn't be
> reindexed and was left inaccesible!!! :(
> Ok, so currently 'memberContacts' has about 800 000 rows, not that much
> really. The failure is related to indexex, and if we look at the table
> using 'sp_helpIndex' - we get the following (where I suppose that the
> autogenerated '== ?' and '?8 ' seems like bad moves) :
> ---
> == ? clustered, hypothetical, auto create located on PRIMARY
> ContactDate, ReturnDate, OfficeID
> hind_18203215_10A_3A nonclustered, hypothetical, auto create located on
> PRIMARY OfficeID, ContactDate
> hind_18203215_10A_4A nonclustered, hypothetical, auto create located on
> PRIMARY OfficeID, ReturnDate
> hind_18203215_10A_9A nonclustered, hypothetical, auto create located on
> PRIMARY OfficeID, TempLockedByAdminUser
> hind_18203215_3A_10A nonclustered, hypothetical, auto create located on
> PRIMARY ContactDate, OfficeID
> hind_18203215_3A_4A nonclustered, hypothetical, auto create located on
> PRIMARY ContactDate, ReturnDate
> hind_18203215_3A_4A_10A nonclustered, hypothetical, auto create
> located on PRIMARY ContactDate, ReturnDate, OfficeID
> hind_18203215_3A_4A_9A nonclustered, hypothetical, auto create
> located on PRIMARY ContactDate, ReturnDate, TempLockedByAdminUser
> hind_18203215_3A_9A nonclustered, hypothetical, auto create located on
> PRIMARY ContactDate, TempLockedByAdminUser
> hind_18203215_4A_10A nonclustered, hypothetical, auto create located on
> PRIMARY ReturnDate, OfficeID
> hind_18203215_4A_3A nonclustered, hypothetical, auto create located on
> PRIMARY ReturnDate, ContactDate
> hind_18203215_4A_9A nonclustered, hypothetical, auto create located on
> PRIMARY ReturnDate, TempLockedByAdminUser
> hind_18203215_9A_10A nonclustered, hypothetical, auto create located on
> PRIMARY TempLockedByAdminUser, OfficeID
> hind_18203215_9A_4A nonclustered, hypothetical, auto create located on
> PRIMARY TempLockedByAdminUser, ReturnDate
> hind_c_18203215_10A clustered, hypothetical, auto create located on
> PRIMARY OfficeID
> hind_c_18203215_3A clustered, hypothetical, auto create located on
> PRIMARY ContactDate
> hind_c_18203215_4A clustered, hypothetical, auto create located on
> PRIMARY ReturnDate
> hind_c_18203215_9A clustered, hypothetical, auto create located on
Friday, March 9, 2012
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment