all indexes lost

I have recently had a a database where all indexes (over 300) have been lost
for no apparent reason. - in addition to this some primary keys were also
lost.
a review of the t-log archives shows no sign of DDL statements being
executed and the only conclusion i can come to is that rows from sysindexes
have been lost.
the indexes were lost during normal working hours, no reindexes or defrags
were taking place and the objects were lost in a matter of seconds.
we also suspected a user may have downloaded some sort of optimisation tool
and tried to "optimise" the database without knowledge, however no-one with
those permissions was logged in at the time.
has anyone else experienced this or can they point me at a KB articleshadowswiss wrote:
> I have recently had a a database where all indexes (over 300) have
> been lost for no apparent reason. - in addition to this some primary
> keys were also lost.
> a review of the t-log archives shows no sign of DDL statements being
> executed and the only conclusion i can come to is that rows from
> sysindexes have been lost.
> the indexes were lost during normal working hours, no reindexes or
> defrags were taking place and the objects were lost in a matter of
> seconds.
> we also suspected a user may have downloaded some sort of
> optimisation tool and tried to "optimise" the database without
> knowledge, however no-one with those permissions was logged in at the
> time.
> has anyone else experienced this or can they point me at a KB article
If someone ran the index tuning wizard, they could have instructed it to
kill old indexes infavor of the recommended list of new indexes. I doubt
this option would have killed any constraints, unless they were just
being enforces using indexes as opposed to the declarative approach.
I've personally never seen this reported before as a bug in SQL Server.
This type of problem is normally someone executing some T-SQL to to
this. I would immediately secure the SQL Server by removing all users
from the admin group that really don't require admin rights and changing
existing passwords for those admins that require those rights.
Although, I would expect to see these drop statements in the t-log. I
assume you are using a 3rd-party log reader to review the t-logs.
Have you checked database integrity using DBCC CHECKDB to see if any
errors are reported?
David Gugick
Quest Software
www.imceda.com
www.quest.com