HELP! Database lost ALL Data!

Anyone ever heard of this?
I got a complaint form a customer. No one can log on to the application. I
took a look at the database (SQL Server 2000) it was empty. I never saw such
a sight before. Even when we ship the database brand new, it is seeded with
some metadata entries. But this database was completely blank.
The only way I can think this could conceivably happen is for a DTS package
to start a database transfer, drop and recreate all the tables and then
terminate before it begins copying data. But no one will admit to running
any DTS jobs. One of our techs was on their box today, but he swears he just
ran a batch file to copy some filesystem (not database) files.
Either someone is lying, or maybe there's another reason why this could
happen? If you can explain how this might have happened, you'll get one of
our support techs out of a lot of trouble.
Thanks!
- Joe Geretz -Hi,
By default SQL Server will not audit any activity inside database. In this
scenario you could identify the problem by veryfying scripts ran.
One more way is if your recovery model is FULL or BULK_LOGGED you could use
log explorer to read the trasnaction log file.
See the link for the details on Logexplorer.
www.lumigent.com
FYI, If you have the database in FULL recovery plus if you have full
database backup and all trasnaction log backups you
could recover the database using POINT_IN_TIME recovery.
Thanks
Hari
MCDBA
"Joseph Geretz" <jgeretz@.nospam.com> wrote in message
news:eL2gtr4bEHA.3580@.TK2MSFTNGP11.phx.gbl...
> Anyone ever heard of this?
> I got a complaint form a customer. No one can log on to the application. I
> took a look at the database (SQL Server 2000) it was empty. I never saw
such
> a sight before. Even when we ship the database brand new, it is seeded
with
> some metadata entries. But this database was completely blank.
> The only way I can think this could conceivably happen is for a DTS
package
> to start a database transfer, drop and recreate all the tables and then
> terminate before it begins copying data. But no one will admit to running
> any DTS jobs. One of our techs was on their box today, but he swears he
just
> ran a batch file to copy some filesystem (not database) files.
> Either someone is lying, or maybe there's another reason why this could
> happen? If you can explain how this might have happened, you'll get one of
> our support techs out of a lot of trouble.
> Thanks!
> - Joe Geretz -
>|||I believe I've found the cause for the database erasure and I've documented
this in my posting
Use of (local) in DTS. Dangerous!!!? of 7/25/2004.
If you have any further comments on my situation, I'd be most grateful to
hear them.
Thanks!
- Joe Geretz -
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:uSU2Xt5bEHA.996@.TK2MSFTNGP12.phx.gbl...
> Hi,
> By default SQL Server will not audit any activity inside database. In this
> scenario you could identify the problem by veryfying scripts ran.
> One more way is if your recovery model is FULL or BULK_LOGGED you could
use
> log explorer to read the trasnaction log file.
> See the link for the details on Logexplorer.
> www.lumigent.com
> FYI, If you have the database in FULL recovery plus if you have full
> database backup and all trasnaction log backups you
> could recover the database using POINT_IN_TIME recovery.
> Thanks
> Hari
> MCDBA
>
> "Joseph Geretz" <jgeretz@.nospam.com> wrote in message
> news:eL2gtr4bEHA.3580@.TK2MSFTNGP11.phx.gbl...
> > Anyone ever heard of this?
> >
> > I got a complaint form a customer. No one can log on to the application.
I
> > took a look at the database (SQL Server 2000) it was empty. I never saw
> such
> > a sight before. Even when we ship the database brand new, it is seeded
> with
> > some metadata entries. But this database was completely blank.
> >
> > The only way I can think this could conceivably happen is for a DTS
> package
> > to start a database transfer, drop and recreate all the tables and then
> > terminate before it begins copying data. But no one will admit to
running
> > any DTS jobs. One of our techs was on their box today, but he swears he
> just
> > ran a batch file to copy some filesystem (not database) files.
> >
> > Either someone is lying, or maybe there's another reason why this could
> > happen? If you can explain how this might have happened, you'll get one
of
> > our support techs out of a lot of trouble.
> >
> > Thanks!
> >
> > - Joe Geretz -
> >
> >
>