Showing posts with label drive. Show all posts
Showing posts with label drive. Show all posts

Monday, March 26, 2012

Recovery from crash

Greetings,

I had a hard-drive failure this week and lost my root drive, with
operating system and SQL Server 2000.

Fortunately my data was on another volume and still exists.

I know about sp_attach_db, but looking at BOL, it says that sp_attach_db
only works with databases that were previously detached with
sp_detach_db.

How do I reattach my existing mdf and ldf files?

-- Rick

P.S. I know that the dbs are not corrupt because when the hard drive
failed SQL Server was offline.Guinness Mann (GMann@.dublin.com) writes:
> I had a hard-drive failure this week and lost my root drive, with
> operating system and SQL Server 2000.
> Fortunately my data was on another volume and still exists.
> I know about sp_attach_db, but looking at BOL, it says that sp_attach_db
> only works with databases that were previously detached with
> sp_detach_db.
> How do I reattach my existing mdf and ldf files?
> P.S. I know that the dbs are not corrupt because when the hard drive
> failed SQL Server was offline.

I would first try with sp_attach_db. If SQL Server was shut down cleanly,
I would expect the database files to be available.

If that fails, I would try sp_attach_single_file_db.

If that fails, there is an undocumented and unsupported method, that
I am not telling about in a newsgroup, because that methods is just
simply far too dangerous. I have no problem sharing it by mail. But
please try sp_detach_db first.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||In article <Xns93F5E2EFD74Yazorman@.127.0.0.1>, sommar@.algonet.se says...
> > I know about sp_attach_db, but looking at BOL, it says that sp_attach_db
> > only works with databases that were previously detached with
> > sp_detach_db.
> I would first try with sp_attach_db. If SQL Server was shut down cleanly,
> I would expect the database files to be available.

sp_attach_db worked great, Erland. Thank you.

-- Rick

Recovery from a database Image

Hello,
First...this isn't a production recover issue.
I have a image of my hard drive that includes all my sql server databases
"in the raw". I suffered a hard disk crash and have reinstalled SQL Server
etc...How can I get these databases back. I tried just copying the two data
files from the "Data" directory off my backup onto the new SQL Server
install...but no cigar.
Surely there is a way to do this.
Regards,
Paul Reed
Jackson-Reed, Inc. www.jacksonreed.com
You can try to attach each database using sp_attach_db (or the Enterprise
Manager attach). This might not work if the databases weren't cleanly
detached, though. See the Books Online for more information.
Hope this helps.
Dan Guzman
SQL Server MVP
"paul" <paul@.discussions.microsoft.com> wrote in message
news:6515DCCF-A02E-4ACD-B59A-C22BB63D087B@.microsoft.com...
> Hello,
> First...this isn't a production recover issue.
> I have a image of my hard drive that includes all my sql server databases
> "in the raw". I suffered a hard disk crash and have reinstalled SQL Server
> etc...How can I get these databases back. I tried just copying the two
> data
> files from the "Data" directory off my backup onto the new SQL Server
> install...but no cigar.
> Surely there is a way to do this.
> Regards,
> Paul Reed
> --
> Jackson-Reed, Inc. www.jacksonreed.com
|||You might also
1. Open a call to MS PSS, maybe they have some magic ( but I doubt you'll be
able to recover.) Try them anyway, only $250
2. When you get past all of this, set up a good database maintenance plan to
backup and maintain your databases..
Good luck friend!
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"paul" <paul@.discussions.microsoft.com> wrote in message
news:6515DCCF-A02E-4ACD-B59A-C22BB63D087B@.microsoft.com...
> Hello,
> First...this isn't a production recover issue.
> I have a image of my hard drive that includes all my sql server databases
> "in the raw". I suffered a hard disk crash and have reinstalled SQL Server
> etc...How can I get these databases back. I tried just copying the two
data
> files from the "Data" directory off my backup onto the new SQL Server
> install...but no cigar.
> Surely there is a way to do this.
> Regards,
> Paul Reed
> --
> Jackson-Reed, Inc. www.jacksonreed.com

Recovery from a database Image

Hello,
First...this isn't a production recover issue.
I have a image of my hard drive that includes all my sql server databases
"in the raw". I suffered a hard disk crash and have reinstalled SQL Server
etc...How can I get these databases back. I tried just copying the two data
files from the "Data" directory off my backup onto the new SQL Server
install...but no cigar.
Surely there is a way to do this.
Regards,
Paul Reed
--
---
Jackson-Reed, Inc. www.jacksonreed.comYou can try to attach each database using sp_attach_db (or the Enterprise
Manager attach). This might not work if the databases weren't cleanly
detached, though. See the Books Online for more information.
Hope this helps.
Dan Guzman
SQL Server MVP
"paul" <paul@.discussions.microsoft.com> wrote in message
news:6515DCCF-A02E-4ACD-B59A-C22BB63D087B@.microsoft.com...
> Hello,
> First...this isn't a production recover issue.
> I have a image of my hard drive that includes all my sql server databases
> "in the raw". I suffered a hard disk crash and have reinstalled SQL Server
> etc...How can I get these databases back. I tried just copying the two
> data
> files from the "Data" directory off my backup onto the new SQL Server
> install...but no cigar.
> Surely there is a way to do this.
> Regards,
> Paul Reed
> --
> ---
> Jackson-Reed, Inc. www.jacksonreed.com|||You might also
1. Open a call to MS PSS, maybe they have some magic ( but I doubt you'll be
able to recover.) Try them anyway, only $250
2. When you get past all of this, set up a good database maintenance plan to
backup and maintain your databases..
Good luck friend!
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"paul" <paul@.discussions.microsoft.com> wrote in message
news:6515DCCF-A02E-4ACD-B59A-C22BB63D087B@.microsoft.com...
> Hello,
> First...this isn't a production recover issue.
> I have a image of my hard drive that includes all my sql server databases
> "in the raw". I suffered a hard disk crash and have reinstalled SQL Server
> etc...How can I get these databases back. I tried just copying the two
data
> files from the "Data" directory off my backup onto the new SQL Server
> install...but no cigar.
> Surely there is a way to do this.
> Regards,
> Paul Reed
> --
> ---
> Jackson-Reed, Inc. www.jacksonreed.com

Recovery from a database Image

Hello,
First...this isn't a production recover issue.
I have a image of my hard drive that includes all my sql server databases
"in the raw". I suffered a hard disk crash and have reinstalled SQL Server
etc...How can I get these databases back. I tried just copying the two data
files from the "Data" directory off my backup onto the new SQL Server
install...but no cigar.
Surely there is a way to do this.
Regards,
Paul Reed
--
---
Jackson-Reed, Inc. www.jacksonreed.comYou can try to attach each database using sp_attach_db (or the Enterprise
Manager attach). This might not work if the databases weren't cleanly
detached, though. See the Books Online for more information.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"paul" <paul@.discussions.microsoft.com> wrote in message
news:6515DCCF-A02E-4ACD-B59A-C22BB63D087B@.microsoft.com...
> Hello,
> First...this isn't a production recover issue.
> I have a image of my hard drive that includes all my sql server databases
> "in the raw". I suffered a hard disk crash and have reinstalled SQL Server
> etc...How can I get these databases back. I tried just copying the two
> data
> files from the "Data" directory off my backup onto the new SQL Server
> install...but no cigar.
> Surely there is a way to do this.
> Regards,
> Paul Reed
> --
> ---
> Jackson-Reed, Inc. www.jacksonreed.com|||You might also
1. Open a call to MS PSS, maybe they have some magic ( but I doubt you'll be
able to recover.) Try them anyway, only $250
2. When you get past all of this, set up a good database maintenance plan to
backup and maintain your databases..
Good luck friend!
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"paul" <paul@.discussions.microsoft.com> wrote in message
news:6515DCCF-A02E-4ACD-B59A-C22BB63D087B@.microsoft.com...
> Hello,
> First...this isn't a production recover issue.
> I have a image of my hard drive that includes all my sql server databases
> "in the raw". I suffered a hard disk crash and have reinstalled SQL Server
> etc...How can I get these databases back. I tried just copying the two
data
> files from the "Data" directory off my backup onto the new SQL Server
> install...but no cigar.
> Surely there is a way to do this.
> Regards,
> Paul Reed
> --
> ---
> Jackson-Reed, Inc. www.jacksonreed.comsql

Recovery

Dear Guys...
Let's assume I have a Database Name "Production" and I have two Harddisk C
and D. In C drive I have production.mdf file and in D Drive I have
production.ldf. After a month C drive has been corrupted but D drive is
still live so now I am in a position to recover whole data or not through
production.LDF file?
Thanks
NOOR
Only if you have a backup of the database. Then you make a backup of the
current transaction log, and then restore the database and the transaction
log in order.
Jacco Schalkwijk
SQL Server MVP
"Noor" <noor@.ngsol.com> wrote in message
news:eirYAKpYEHA.4004@.TK2MSFTNGP10.phx.gbl...
> Dear Guys...
> Let's assume I have a Database Name "Production" and I have two Harddisk C
> and D. In C drive I have production.mdf file and in D Drive I have
> production.ldf. After a month C drive has been corrupted but D drive is
> still live so now I am in a position to recover whole data or not through
> production.LDF file?
> Thanks
> NOOR
>
|||Hi,
With LDF file you can not recover the database. LDF file contains only
active transactions.
In the otherway if you have the MDF file you can try recovering the
database using sp_attach_single_file_db (see books online).
In your case only way to recover the database is using the last full
database backup. After that you can apply the transaction log backups,
provided if you have taken transaction log backup.
Thanks
Hari
MCDBA
"Noor" <noor@.ngsol.com> wrote in message
news:eirYAKpYEHA.4004@.TK2MSFTNGP10.phx.gbl...
> Dear Guys...
> Let's assume I have a Database Name "Production" and I have two Harddisk C
> and D. In C drive I have production.mdf file and in D Drive I have
> production.ldf. After a month C drive has been corrupted but D drive is
> still live so now I am in a position to recover whole data or not through
> production.LDF file?
> Thanks
> NOOR
>

Recovering using the log file

I have a situation where the server and data files were located on the C:
drive, and the log files on the F: drive.
The C: drive crashed, total loss. But I still have full backups for the
databases and also their log files.
Is there a way of recovering my DBs to the point of failure using the
backups and log files?
Everything I see in the BOL refer to use a log backup. I don't have log
backups, just the log files themselves.
ThanksIf the database is in full recovery mode, and no-one has truncated the log,
you can do:
BACKUP LOG dbname TO ... WITH NO_TRUNCATE
If the database is in simple recovery mode, then SQL Server will truncate
the log at each checkpoint. This means that the information you need is no
longer available in the transaction log files.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Dallara" <someone@.microsoft.com> wrote in message
news:OPpd5co%23DHA.3232@.TK2MSFTNGP10.phx.gbl...
> I have a situation where the server and data files were located on the C:
> drive, and the log files on the F: drive.
> The C: drive crashed, total loss. But I still have full backups for the
> databases and also their log files.
> Is there a way of recovering my DBs to the point of failure using the
> backups and log files?
> Everything I see in the BOL refer to use a log backup. I don't have log
> backups, just the log files themselves.
> Thanks
>|||They were in full recovery.
Thanks for yr help, but the point you missed here is that the DBs are gone,
the server is gone as well.
So "BACKUP LOG dbname TO ... WITH NO_TRUNCATE" doesn't work as "dbname"
doesn't exist.
I've set up a new server, and I want to recreate the databases using the
full backups and log files that I have.
I know how to recover the DBs to the point of their full backup. I'm
wondering if there's a way of recover them to the point of failure using
their log files.
>"Tibor Karaszi" wrote in message
>If the database is in full recovery mode, and no-one has truncated the log,
>you can do:
>BACKUP LOG dbname TO ... WITH NO_TRUNCATE
>If the database is in simple recovery mode, then SQL Server will truncate
>the log at each checkpoint. This means that the information you need is no
>longer available in the transaction log files.
> Tibor Karaszi, SQL Server MVP
>
C:|||OK, so the SQL Server install in itself is toast...
The concept to save this is to have your new installation with a working SQL
Server, create a database with the same name and same file layout as the old
one. Stop that SQL Server, delete the mdf, ndf and ldf files. Then copy over
the ldf file from the broken install. Start SQL Server. Database is now
suspect (the mdf and ndf files are missing). You now do
BACKUP LOG dbname TO DISK = 'C:\...' WITH NO_TRUNCATE
Then restore the db backup and that log backups.
Above assumes that you indeed have all log records available in the ldf
file, since the db backup was taken.
There's a KB on the subject, I don't have the number, but it shouldn't be
hard to find with a little bit of searching...
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Dallara" <someone@.microsoft.com> wrote in message
news:OcVlVay%23DHA.1212@.TK2MSFTNGP12.phx.gbl...
> They were in full recovery.
> Thanks for yr help, but the point you missed here is that the DBs are
gone,
> the server is gone as well.
> So "BACKUP LOG dbname TO ... WITH NO_TRUNCATE" doesn't work as "dbname"
> doesn't exist.
> I've set up a new server, and I want to recreate the databases using the
> full backups and log files that I have.
> I know how to recover the DBs to the point of their full backup. I'm
> wondering if there's a way of recover them to the point of failure using
> their log files.
>
>
log,
no
> C:
the
log
>

Recovering using the log file

I have a situation where the server and data files were located on the C:
drive, and the log files on the F: drive.
The C: drive crashed, total loss. But I still have full backups for the
databases and also their log files.
Is there a way of recovering my DBs to the point of failure using the
backups and log files?
Everything I see in the BOL refer to use a log backup. I don't have log
backups, just the log files themselves.
ThanksIf the database is in full recovery mode, and no-one has truncated the log,
you can do:
BACKUP LOG dbname TO ... WITH NO_TRUNCATE
If the database is in simple recovery mode, then SQL Server will truncate
the log at each checkpoint. This means that the information you need is no
longer available in the transaction log files.
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Dallara" <someone@.microsoft.com> wrote in message
news:OPpd5co%23DHA.3232@.TK2MSFTNGP10.phx.gbl...
> I have a situation where the server and data files were located on the C:
> drive, and the log files on the F: drive.
> The C: drive crashed, total loss. But I still have full backups for the
> databases and also their log files.
> Is there a way of recovering my DBs to the point of failure using the
> backups and log files?
> Everything I see in the BOL refer to use a log backup. I don't have log
> backups, just the log files themselves.
> Thanks
>|||They were in full recovery.
Thanks for yr help, but the point you missed here is that the DBs are gone,
the server is gone as well.
So "BACKUP LOG dbname TO ... WITH NO_TRUNCATE" doesn't work as "dbname"
doesn't exist.
I've set up a new server, and I want to recreate the databases using the
full backups and log files that I have.
I know how to recover the DBs to the point of their full backup. I'm
wondering if there's a way of recover them to the point of failure using
their log files.
>"Tibor Karaszi" wrote in message
>If the database is in full recovery mode, and no-one has truncated the log,
>you can do:
>BACKUP LOG dbname TO ... WITH NO_TRUNCATE
>If the database is in simple recovery mode, then SQL Server will truncate
>the log at each checkpoint. This means that the information you need is no
>longer available in the transaction log files.
> Tibor Karaszi, SQL Server MVP
>
>> "Dallara" wrote in message
> > I have a situation where the server and data files were located on the
C:
> > drive, and the log files on the F: drive.
> > The C: drive crashed, total loss. But I still have full backups for the
> > databases and also their log files.
> >
> > Is there a way of recovering my DBs to the point of failure using the
> > backups and log files?
> > Everything I see in the BOL refer to use a log backup. I don't have log
> > backups, just the log files themselves.
> >
> > Thanks|||OK, so the SQL Server install in itself is toast...
The concept to save this is to have your new installation with a working SQL
Server, create a database with the same name and same file layout as the old
one. Stop that SQL Server, delete the mdf, ndf and ldf files. Then copy over
the ldf file from the broken install. Start SQL Server. Database is now
suspect (the mdf and ndf files are missing). You now do
BACKUP LOG dbname TO DISK = 'C:\...' WITH NO_TRUNCATE
Then restore the db backup and that log backups.
Above assumes that you indeed have all log records available in the ldf
file, since the db backup was taken.
There's a KB on the subject, I don't have the number, but it shouldn't be
hard to find with a little bit of searching...
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Dallara" <someone@.microsoft.com> wrote in message
news:OcVlVay%23DHA.1212@.TK2MSFTNGP12.phx.gbl...
> They were in full recovery.
> Thanks for yr help, but the point you missed here is that the DBs are
gone,
> the server is gone as well.
> So "BACKUP LOG dbname TO ... WITH NO_TRUNCATE" doesn't work as "dbname"
> doesn't exist.
> I've set up a new server, and I want to recreate the databases using the
> full backups and log files that I have.
> I know how to recover the DBs to the point of their full backup. I'm
> wondering if there's a way of recover them to the point of failure using
> their log files.
>
> >"Tibor Karaszi" wrote in message
> >
> >If the database is in full recovery mode, and no-one has truncated the
log,
> >you can do:
> >BACKUP LOG dbname TO ... WITH NO_TRUNCATE
> >
> >If the database is in simple recovery mode, then SQL Server will truncate
> >the log at each checkpoint. This means that the information you need is
no
> >longer available in the transaction log files.
> >
> > Tibor Karaszi, SQL Server MVP
> >
> >
> >> "Dallara" wrote in message
> >>
> > > I have a situation where the server and data files were located on the
> C:
> > > drive, and the log files on the F: drive.
> > > The C: drive crashed, total loss. But I still have full backups for
the
> > > databases and also their log files.
> > >
> > > Is there a way of recovering my DBs to the point of failure using the
> > > backups and log files?
> > > Everything I see in the BOL refer to use a log backup. I don't have
log
> > > backups, just the log files themselves.
> > >
> > > Thanks
>

Friday, March 23, 2012

Recovering SQL 2000 Database without the Log File not in clean disconnected state

We just had a hard drive crash here. We were able to copy off the .mdf file from SQL server 2000 from the drive, but not the .ldf (which was only 720k anyhow).

When I try to attach the mdf to an SQL Server 2000 or 2005 server I get an error saying that the log file doesn't exist.

Does anyone know a way to attach this not-cleanly-closed database file and recover the data? (apparently the person decided that they need-not backup their database :<)

Thanks for any help you can provide!

You may get lucky and be able to attach to a SQL 2005 instance and use the ATTACH_REBUILD_LOG clause...try something like this:

create database <x> on <filespec> for attach_rebuild_log

|||

Thanks. I tried that, but it said the same thing, and the documentation says that you have to have a cleanly shut down database to be able to use that command.

Thanks anyways! Any other ideas?

|||I got the same problem and the sames answers from 2000 and 2005. Any idea will help me too.|||This has to go back to your backups. Do you have full/differential/log backups? What's your disk architecture?|||I posted too fast...didn't get to read that you do not have backups...I have another question...did the entire server go down or only the disk?|||The whole drive failed. I was able to freeze it and get the mdf, but the log file was corrupt.

Hence i have an mdf and no log file that will work, and the idiot that owned the machine didn't do a backup.

Recovering SQL 2000 Database without the Log File not in clean disconnected state

We just had a hard drive crash here. We were able to copy off the .mdf file from SQL server 2000 from the drive, but not the .ldf (which was only 720k anyhow).

When I try to attach the mdf to an SQL Server 2000 or 2005 server I get an error saying that the log file doesn't exist.

Does anyone know a way to attach this not-cleanly-closed database file and recover the data? (apparently the person decided that they need-not backup their database :<)

Thanks for any help you can provide!

You may get lucky and be able to attach to a SQL 2005 instance and use the ATTACH_REBUILD_LOG clause...try something like this:

create database <x> on <filespec> for attach_rebuild_log

|||

Thanks. I tried that, but it said the same thing, and the documentation says that you have to have a cleanly shut down database to be able to use that command.

Thanks anyways! Any other ideas?

|||I got the same problem and the sames answers from 2000 and 2005. Any idea will help me too.|||This has to go back to your backups. Do you have full/differential/log backups? What's your disk architecture?|||I posted too fast...didn't get to read that you do not have backups...I have another question...did the entire server go down or only the disk?|||The whole drive failed. I was able to freeze it and get the mdf, but the log file was corrupt.

Hence i have an mdf and no log file that will work, and the idiot that owned the machine didn't do a backup.

Recovering SQL 2000 Database without the Log File not in clean disconnected state

We just had a hard drive crash here. We were able to copy off the .mdf file from SQL server 2000 from the drive, but not the .ldf (which was only 720k anyhow).

When I try to attach the mdf to an SQL Server 2000 or 2005 server I get an error saying that the log file doesn't exist.

Does anyone know a way to attach this not-cleanly-closed database file and recover the data? (apparently the person decided that they need-not backup their database :<)

Thanks for any help you can provide!

You may get lucky and be able to attach to a SQL 2005 instance and use the ATTACH_REBUILD_LOG clause...try something like this:

create database <x> on <filespec> for attach_rebuild_log

|||

Thanks. I tried that, but it said the same thing, and the documentation says that you have to have a cleanly shut down database to be able to use that command.

Thanks anyways! Any other ideas?

|||I got the same problem and the sames answers from 2000 and 2005. Any idea will help me too.|||This has to go back to your backups. Do you have full/differential/log backups? What's your disk architecture?|||I posted too fast...didn't get to read that you do not have backups...I have another question...did the entire server go down or only the disk?|||The whole drive failed. I was able to freeze it and get the mdf, but the log file was corrupt.

Hence i have an mdf and no log file that will work, and the idiot that owned the machine didn't do a backup.

Recovering from transaction log deletion in 6.5

I was trying to relocate my transaction log to a bigger drive using
sp_movedevice but I made a mistake in the syntax of the second parameter
and put only the path, not the path and the file name.
Now my database is marked as "suspect" and I get an error message in my log
upon database start up saying that the log file cannot be open.

Is there a way to have MS SQL 6.5 "forget" all the logs of this database,
create new ones and restart the database? The logs contained nothing
important, I had truncated them an hour or so before I made my mistake. I
just want to make sure the data are still usable.
When I look at the devices with sp_helpdevice, I can see a log that exist
and is hopefully in pristine condition and the one that doesn't exist
anymore.
I looked in the archives of various newsgroups but couldn't find something
that correspond closely to my situation. I saw something similar but with
MS SQL 7.0
(http://groups.google.com/groups?hl=...om %26rnum%3D4)
using sp_attach_db/sp_detach_db. What would be the equivalent with version
6.5?

Thanks!

Charles

--
Charles-E. Nadeau Ph.D
http://radio.weblogs.com/0111823/[posted and mailed]

Charles Nadeau (charlesnadeau@.hotmail.com) writes:
> I was trying to relocate my transaction log to a bigger drive using
> sp_movedevice but I made a mistake in the syntax of the second parameter
> and put only the path, not the path and the file name. Now my database
> is marked as "suspect" and I get an error message in my log upon
> database start up saying that the log file cannot be open.
> Is there a way to have MS SQL 6.5 "forget" all the logs of this database,
> create new ones and restart the database? The logs contained nothing
> important, I had truncated them an hour or so before I made my mistake. I
> just want to make sure the data are still usable.
> When I look at the devices with sp_helpdevice, I can see a log that exist
> and is hopefully in pristine condition and the one that doesn't exist
> anymore.

Indeed, you should be able to get to the data. I know how to deal with
the situation in SQL2000, but I don't know if those commands work in
6.5. (It's not the same as in the link you posted; sp_attach_db is not
in 6.5.) As the hour is late, I am not going to test, but I'll ask
around with my contacts at Microsoft, to see if they know.

If the mail address is not one you monitor, please send me a mail, since
the answer I get from MS may not be suitable for a public newsgroup. (The
method for SQL2000 is very dangerous if you don't understand what you
are doing.)

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||You can set to emergency mode
http://support.microsoft.com/defaul...kb;en-us;165918

Which should allow you to access the data.

Didn't you take a backup first?

Nigel Rivett
www.nigelrivett.net

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!|||Erland Sommarskog wrote:

> [posted and mailed]
> Charles Nadeau (charlesnadeau@.hotmail.com) writes:
>> I was trying to relocate my transaction log to a bigger drive using
>> sp_movedevice but I made a mistake in the syntax of the second parameter
>> and put only the path, not the path and the file name. Now my database
>> is marked as "suspect" and I get an error message in my log upon
>> database start up saying that the log file cannot be open.
>>
>> Is there a way to have MS SQL 6.5 "forget" all the logs of this database,
>> create new ones and restart the database? The logs contained nothing
>> important, I had truncated them an hour or so before I made my mistake. I
>> just want to make sure the data are still usable.
>> When I look at the devices with sp_helpdevice, I can see a log that exist
>> and is hopefully in pristine condition and the one that doesn't exist
>> anymore.
> Indeed, you should be able to get to the data. I know how to deal with

Just a few more details:
My log files are on the f: drive:

F:\mssql\data>dir
*Volume in drive F has no label.
*Volume Serial Number is 8018-882A

*Directory of F:\mssql\data

18/05/04* 01:40p******* <DIR>********* .
18/05/04* 01:40p******* <DIR>********* ..
24/08/01* 02:14p*************** 26,522 defn_ticket.sql.sql
18/05/04* 01:40p******* <DIR>********* dump
22/09/00* 01:45p**************** 1,384 dump.bat
18/05/04* 01:39p********** 268,435,456 master.mir
10/04/03* 08:12a*********** 42,844,160 Support-Processed.ps
18/05/04* 11:47a********** 268,435,456 ticket.mir
18/05/04* 12:16p******** 1,073,741,824 Ticketlog2.DAT
18/05/04* 12:16p******** 1,073,741,824 Ticket_log.dat
18/05/04* 01:39p************ 8,388,608 Winnie.DAT
18/05/04* 01:39p*********** 25,165,824 Winnie_log.DAT
************* 12 File(s)* 2,760,781,058 bytes
************************* 4,938,989,568 bytes free

The valid log file is Ticketlog2.DAT. Ticket_log.dat is simply a copy of
Ticketlog2.DAT I renamed and put there to try to force SQL Server to read
it.

And here is the output of two commands listing the state of my devices:

select * from sysdevices
go
sp_helpdevice
go

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 16995 ms.
SQL Server Parse and Compile Time:
** cpu time = 0 ms.
low******** high******* status cntrltype name**************************
phyname******************************************* ************************************************** ***************************
mirrorname**************************************** ************************************************** ***************************
stripeset*********************

---- ---- -- --- ----------
--------------------------------------
--------------------------------------
----------

0********** 19********* 16**** 3******** diskettedumpa*****************
a:sqltable.dat************************************ ************************************************** ***************************
(null)******************************************** ************************************************** ***************************
(null)************************

0********** 19********* 16**** 4******** diskettedumpb*****************
b:sqltable.dat************************************ ************************************************** ***************************
(null)******************************************** ************************************************** ***************************
(null)************************

0********** 131071***** 739*** 0******** master************************ C
\MSSQL\DATA\MASTER.DAT**************************** ************************************************** *************************
f:\mssql\data\master.mir************************** ************************************************** ***************************
(null)************************

2130706432* 2130709503* 2***** 0******** MSDBData********************** C
\MSSQL\DATA\MSDB.DAT****************************** ************************************************** *************************
(null)******************************************** ************************************************** ***************************
(null)************************

2113929216* 2113930239* 2***** 0******** MSDBLog*********************** C
\MSSQL\DATA\MSDBLOG.DAT*************************** ************************************************** *************************
(null)******************************************** ************************************************** ***************************
(null)************************

16777216*** 16908287*** 2***** 0******** ticket************************ f
\mssql\data\ticket.mir**************************** ************************************************** *************************
(null)******************************************** ************************************************** ***************************
(null)************************

33554432*** 33832959*** 2***** 0******** Ticket_log******************** f
\mssql\data\ticket_log.dat************************ ************************************************** *************************
(null)******************************************** ************************************************** ***************************
(null)************************

0********** 0********** 16**** 2******** TicketBackUp****************** F
\mssql\BackUp\TicketBackUp.DAT******************** ************************************************** *************************
(null)******************************************** ************************************************** ***************************
(null)************************

83886080*** 84410367*** 2***** 0******** Ticketlog2******************** F
\mssql\data\Ticketlog2.DAT************************ ************************************************** *************************
(null)******************************************** ************************************************** ***************************
(null)************************

50331648*** 50335743*** 2***** 0******** Winnie************************ F
\MSSQL\DATA\Winnie.DAT**************************** ************************************************** *************************
(null)******************************************** ************************************************** ***************************
(null)************************

0********** 0********** 16**** 2******** Winnie_backup***************** f
\MSSQL\BACKUP\Winnie_backup.DAT******************* ************************************************** *************************
(null)******************************************** ************************************************** ***************************
(null)************************

67108864*** 67121151*** 2***** 0******** Winnie_log******************** F
\MSSQL\DATA\Winnie_log.DAT************************ ************************************************** *************************
(null)******************************************** ************************************************** ***************************
(null)************************

(12 row(s) affected)

Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 0 ms.
SQL Server Parse and Compile Time:
** cpu time = 0 ms.
SQL Server Parse and Compile Time:
** cpu time = 70 ms.
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 261 ms.

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 50 ms.

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 0 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 12,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 10 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 16,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 8,* logical reads: 8,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 40 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 4,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 2,* logical reads: 2,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 10 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 4,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 2,* logical reads: 2,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 4,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 2,* logical reads: 2,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 110 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 521 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 20 ms.
Table: sysdevices* scan count 1,* logical reads: 1,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 1,* logical reads: 2,* physical reads: 1,*
read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 10 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 2,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 2,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 10 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 2,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 12,* logical reads: 24,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 10 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 2,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 12,* logical reads: 24,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 8,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 12,* logical reads: 24,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 2,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 12,* logical reads: 24,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 16,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 12,* logical reads: 24,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 16,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 1,* logical reads: 2,* physical reads: 1,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 70 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 12,* logical reads: 24,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 10 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 12,* logical reads: 24,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 12,* logical reads: 24,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 20 ms.
Table: #spdevtab___________0100000002* scan count 0,* logical reads: 0,*
physical reads: 0,* read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: spt_values* scan count 12,* logical reads: 24,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 10 ms.

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 0 ms.
device_name******************* physical_name*********************************
description*************************************** ************************************************** ************************************************** ************************************************** ************************************************** *****
status cntrltype device_number low******** high*******

----------
--------------
----------------------------------------------------------------------------
-- --- ---- ---- ----

TicketBackUp****************** F:\mssql\BackUp\TicketBackUp.DAT**************
disk, dump device******************************************** ************************************************** ************************************************** ************************************************** ********************************************
16**** 2******** 0************ 0********** 0**********

Winnie_backup***************** f:\MSSQL\BACKUP\Winnie_backup.DAT*************
disk, dump device******************************************** ************************************************** ************************************************** ************************************************** ********************************************
16**** 2******** 0************ 0********** 0**********

diskettedumpa***************** a:sqltable.dat********************************
diskette, 1.2 MB, dump device******************************************** ************************************************** ************************************************** ************************************************** ********************************
16**** 3******** 0************ 0********** 19*********

diskettedumpb***************** b:sqltable.dat********************************
diskette, 1.2 MB, dump device******************************************** ************************************************** ************************************************** ************************************************** ********************************
16**** 4******** 0************ 0********** 19*********

MSDBData********************** C:\MSSQL\DATA\MSDB.DAT************************
special, physical disk, 6 MB************************************************ ************************************************** ************************************************** ************************************************** *****************************
2***** 0******** 127********** 2130706432* 2130709503*

MSDBLog*********************** C:\MSSQL\DATA\MSDBLOG.DAT*********************
special, physical disk, 2 MB************************************************ ************************************************** ************************************************** ************************************************** *****************************
2***** 0******** 126********** 2113929216* 2113930239*

ticket************************ f:\mssql\data\ticket.mir**********************
special, physical disk, 256 MB************************************************ ************************************************** ************************************************** ************************************************** ***************************
2***** 0******** 1************ 16777216*** 16908287***

Ticket_log******************** f:\mssql\data\ticket_log.dat******************
special, physical disk, 544 MB************************************************ ************************************************** ************************************************** ************************************************** ***************************
2***** 0******** 2************ 33554432*** 33832959***

Ticketlog2******************** F:\mssql\data\Ticketlog2.DAT******************
special, physical disk, 1024 MB************************************************ ************************************************** ************************************************** ************************************************** **************************
2***** 0******** 5************ 83886080*** 84410367***

Winnie************************ F:\MSSQL\DATA\Winnie.DAT**********************
special, physical disk, 8 MB************************************************ ************************************************** ************************************************** ************************************************** *****************************
2***** 0******** 3************ 50331648*** 50335743***

Winnie_log******************** F:\MSSQL\DATA\Winnie_log.DAT******************
special, physical disk, 24 MB************************************************ ************************************************** ************************************************** ************************************************** ****************************
2***** 0******** 4************ 67108864*** 67121151***

master************************ C:\MSSQL\DATA\MASTER.DAT**********************
special, MIRROR ENABLED, mirrored on 'f:\mssql\data\master.mir', serial
writes, reads mirrored, default disk, physical disk, 256 MB************************************************ ************************************************** **************************
739*** 0******** 0************ 0********** 131071*****

(1 row(s) affected)

Table: sysdevices* scan count 12,* logical reads: 12,* physical reads: 0,*
read ahead reads: 0
Table: #spdevtab___________0100000002* scan count 1,* logical reads: 1,*
physical reads: 0,* read ahead reads: 0
Table: spt_values* scan count 1,* logical reads: 2,* physical reads: 0,*
read ahead reads: 0

SQL Server Execution Times:
** cpu time = 10 ms.* elapsed time = 10 ms.

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 0 ms.

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 20 ms.
SQL Server Parse and Compile Time:
** cpu time = 0 ms.

SQL Server Execution Times:
** cpu time = 0 ms.* elapsed time = 0 ms.

I hope this will shed more lights on my problem. Thanks again for your help!

Charles

> the situation in SQL2000, but I don't know if those commands work in
> 6.5. (It's not the same as in the link you posted; sp_attach_db is not
> in 6.5.) As the hour is late, I am not going to test, but I'll ask
> around with my contacts at Microsoft, to see if they know.
> If the mail address is not one you monitor, please send me a mail, since
> the answer I get from MS may not be suitable for a public newsgroup. (The
> method for SQL2000 is very dangerous if you don't understand what you
> are doing.)

--
Charles-E. Nadeau Ph.D
http://radio.weblogs.com/0111823/|||Nigel Rivett wrote:

> You can set to emergency mode
> http://support.microsoft.com/defaul...kb;en-us;165918

Using this I can backup my data and truncate the log but I don't think it
can take care of the bad information inside sysdevices. I'll take a deeper
look at it later on.

> Which should allow you to access the data.
> Didn't you take a backup first?

I backup the database daily by "dumping" them using bcp (i.e. bcp
Ticket.dbo.Item2Ticket out f:\mssql\data\dump\Item2Ticket.tbl /n /U
username /P password /S WINHKONG ).
This is my last backup:

K:\mssql\data\dump>dir
*Volume in drive K has no label.
*Volume Serial Number is 8018-882A

*Directory of K:\mssql\data\dump

18/05/04* 01:40p******* <DIR>********* .
18/05/04* 01:40p******* <DIR>********* ..
15/10/01* 04:10p*************** 29,022 all db scripts.sql.sql
17/05/04* 04:15p****************** 184 Item2Ticket.tbl
17/05/04* 04:15p*************** 15,895 LastInteraction.tbl
17/05/04* 04:15p*************** 30,647 Mission.tbl
17/05/04* 04:15p****************** 164 RSM.tbl
17/05/04* 04:15p******************* 28 Status.tbl
17/05/04* 04:15p**************** 2,059 TaskItems.tbl
17/05/04* 04:15p******************* 69 Tasks.tbl
17/05/04* 04:15p******************* 24 TaskType.tbl
17/05/04* 04:20p*********** 43,394,880 Ticket.tbl
17/05/04* 04:20p****************** 286 Topics.tbl
17/05/04* 04:20p******************* 60 Types.tbl
17/05/04* 04:20p************** 316,258 Words.tbl
17/05/04* 04:24p*********** 19,785,780 WordsInTicket.tbl
************* 16 File(s)**** 63,575,356 bytes
************************* 4,938,989,568 bytes free

> Nigel Rivett
> www.nigelrivett.net

Thanks for your help, much appreciated!

Charles

> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!

--
Charles-E. Nadeau Ph.D
http://radio.weblogs.com/0111823/|||Have you tried setting to emergency mode?
That should allow you to bcp all the data out and copy to another
database.

Nigel Rivett
www.nigelrivett.net

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!|||Charles Nadeau (charlesnadeau@.hotmail.com) writes:
> Using this I can backup my data and truncate the log but I don't think it
> can take care of the bad information inside sysdevices. I'll take a deeper
> look at it later on.

Once you have gotten the data out, I suggest that you drop the database
and create a new one. You should not continue with the database once it
has been marked suspect.

I assume that you have your scripts on version control, but if not there are
scripting facitilies in Enterprise Manager.

> I backup the database daily by "dumping" them using bcp (i.e. bcp
> Ticket.dbo.Item2Ticket out f:\mssql\data\dump\Item2Ticket.tbl /n /U
> username /P password /S WINHKONG ).
> This is my last backup:

While that saves your data, you don't save metadata and stored procedures
this way. What's wrong with the regular DUMP command.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Erland Sommarskog wrote:

> Charles Nadeau (charlesnadeau@.hotmail.com) writes:
>> Using this I can backup my data and truncate the log but I don't think it
>> can take care of the bad information inside sysdevices. I'll take a
>> deeper look at it later on.
> Once you have gotten the data out, I suggest that you drop the database

This is what I did. Everything was smooth:
I put the database is emergency mode, bcp all the data out of it.
I cheked where my last back-up and the database scripts were.
I droped the database and its devices, then recreated the devices.
I created the database FOR LOAD.
I restored from my latest back-up (I didn't loose any data!).
I set the databse for use not only by dbo.
At this point I panicked a bit because the database was flagged as loading
even after I had put the data back into it. I restarted the server and I
was back in business. I was expecting the whole thing to be longer and more
painfull.
Thanks a lot for your help!

Charles

> and create a new one. You should not continue with the database once it
> has been marked suspect.
> I assume that you have your scripts on version control, but if not there
> are scripting facitilies in Enterprise Manager.
>> I backup the database daily by "dumping" them using bcp (i.e. bcp
>> Ticket.dbo.Item2Ticket out f:\mssql\data\dump\Item2Ticket.tbl /n /U
>> username /P password /S WINHKONG ).
>> This is my last backup:
> While that saves your data, you don't save metadata and stored procedures
> this way. What's wrong with the regular DUMP command.

--
Charles-E. Nadeau Ph.D
http://radio.weblogs.com/0111823/|||Charles Nadeau (charlesnadeau@.hotmail.com) writes:
> This is what I did. Everything was smooth:
> I put the database is emergency mode, bcp all the data out of it.
> I cheked where my last back-up and the database scripts were.
> I droped the database and its devices, then recreated the devices.
> I created the database FOR LOAD.
> I restored from my latest back-up (I didn't loose any data!).
> I set the databse for use not only by dbo.
> At this point I panicked a bit because the database was flagged as
> loading even after I had put the data back into it. I restarted the
> server and I was back in business. I was expecting the whole thing to be
> longer and more painfull.

Glad to hear that it worked out fine!

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Recovering from hard disk crash

SQL 7.0/NT 4.0
The C drive has crashed. The MDF and LDF files are on
Drive D.
Is there any path to recovery?
Thanks,
Don
Hi, Don! As long as the db files are not corrupt, you can try using the sp_attach_db after you reinstall. See BOL for details. HTH. =)
|||Prerequisite:
Copy all the MDF and LDF files (User databases and System databases) to a safe directory,
Installation:
Since the C drive is crashed, you have to Install the Windows NT 4.0 with the same service pack.
After that install SQL 7.0 with same directory structure and the same service pack as before.
Now follow the below steps:-
1. Stop the SQL Server
2. Move the current MDF and LDF files for system databases (Created on the new installation) to a new folder
3. Copy back all the MDF and LDF files to the same old folders ( Files copied in prerequisite step)
4. Start the SQL server and check all the databases are accessible.
The above step will work fine if you have the system files safe.
If the above steps fail then you will have to restore from good backup files.
-- Don wrote: --
SQL 7.0/NT 4.0
The C drive has crashed. The MDF and LDF files are on
Drive D.
Is there any path to recovery?
Thanks,
Don

Recovering from hard disk crash

SQL 7.0/NT 4.0
The C drive has crashed. The MDF and LDF files are on
Drive D.
Is there any path to recovery?
Thanks,
DonHi, Don! As long as the db files are not corrupt, you can try using the sp_a
ttach_db after you reinstall. See BOL for details. HTH. =)|||Prerequisite:
Copy all the MDF and LDF files (User databases and System databases) to a sa
fe directory,
Installation:
Since the C drive is crashed, you have to Install the Windows NT 4.0 with th
e same service pack.
After that install SQL 7.0 with same directory structure and the same servic
e pack as before.
Now follow the below steps:-
1. Stop the SQL Server
2. Move the current MDF and LDF files for system databases (Created on the n
ew installation) to a new folder
3. Copy back all the MDF and LDF files to the same old folders ( Files copie
d in prerequisite step)
4. Start the SQL server and check all the databases are accessible.
The above step will work fine if you have the system files safe.
If the above steps fail then you will have to restore from good backup files
.
-- Don wrote: --
SQL 7.0/NT 4.0
The C drive has crashed. The MDF and LDF files are on
Drive D.
Is there any path to recovery?
Thanks,
Don

Recovering from hard disk crash

SQL 7.0/NT 4.0
The C drive has crashed. The MDF and LDF files are on
Drive D.
Is there any path to recovery?
Thanks,
DonHi, Don! As long as the db files are not corrupt, you can try using the sp_attach_db after you reinstall. See BOL for details. HTH. =)|||Prerequisite
Copy all the MDF and LDF files (User databases and System databases) to a safe directory
Installation
Since the C drive is crashed, you have to Install the Windows NT 4.0 with the same service pack.
After that install SQL 7.0 with same directory structure and the same service pack as before
Now follow the below steps:
1. Stop the SQL Server
2. Move the current MDF and LDF files for system databases (Created on the new installation) to a new folde
3. Copy back all the MDF and LDF files to the same old folders ( Files copied in prerequisite step
4. Start the SQL server and check all the databases are accessible
The above step will work fine if you have the system files safe
If the above steps fail then you will have to restore from good backup files
-- Don wrote: --
SQL 7.0/NT 4.
The C drive has crashed. The MDF and LDF files are on
Drive D
Is there any path to recovery
Thanks
Do

Recovering DB with only the .MDF file

I saw the other thread that is related, but let me give you our circumstances. A drive failed and that drive had the SQL installation and the *.ldf files on it. The MDF files were unscathed.

The drive has been rebuilt and I have reinstalled SQL 2000 SP3A on there (that is what was there before). I have tried attaching the MDF through the GUI and letting it create the log for me. This failed.

I tried sp_attach_single_file_db, but this failed since the db was never dettached.

I tried creating the db again, dettaching it, copying the old (good) MDF file over the newly created one and then attaching (using multiple attach approaches). It knows that the log file and mdf are not matched and won't let me do the attach.

I also found DBCC REBUILD_LOG, but the article in SQL Mag supposes that your instance is still in working order and that there is an entry for the db in sysdatabases. Such is not true in my case.

Can you help? We are trying to get old backup tapes shipped to the site, looking up our Gold Partner contact info, etc., but in the meantime, I am trying to get the data restored even if we lose some transactions.

Thanks for any help!

Here is what worked for me. Thanks for SQL Server Mag for the core pieces of this:

-- LISTING 1: Undocumented DBCC Command REBUILD_LOG

/* Create a new db named the same as the inaccessible one (in this case "Ops") */

EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
GO

BEGIN TRAN

UPDATE master..sysdatabases
SET status = status | 32768
WHERE name = 'Ops'

IF @.@.ROWCOUNT = 1
BEGIN
COMMIT TRAN
RAISERROR('emergency mode set', 0, 1)
END
ELSE
BEGIN
ROLLBACK
RAISERROR('unable to set emergency mode', 16, 1)
END

GO

EXEC sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE
GO

-- 3. Stop SQL Server
-- 4. Replace the newly created Ops.mdf file with the old good one
-- 5. Rename the newly created Ops_log.ldf file
-- 6. Start SQL Server

-- 7. Run the following DBCC command:
DBCC REBUILD_LOG('Ops','E:\Program Files\Microsoft SQL Server\MSSQL\Data\Ops_log.LDF')

-- You should get the message:
-- Warning: The log for database 'Ops' has been rebuilt. Transactional consistency has been lost.

-- DBCC CHECKDB should be run to validate physical consistency. Database options will have to be reset,

-- and extra log files may need to be deleted.
-- DBCC execution completed. If DBCC printed error messages, contact your system administrator.


-- 8. Run data consistancy check
/*Perform physical and logical integrity checks at this point.
Bcp data out if your integrity checks demonstrate that problems exist.
*/
DBCC CHECKDB (Ops)


ALTER DATABASE Ops SET MULTI_USER
GO

-- Set database options and recovery model as desired.
GO

-- Make a backup and start to use the DB again

|||

Note that in SQL Server 2005, all of this can be accomplished using the

CREATE DATABASE FOR ATTACH_REBUILD_LOG command.

All of the same caveats apply: if you attach a database without a log, you stand a good chance of losing data and/or ending up with a corrupt database. If you've got no choice, you've got no choice. That's what backups are for.

|||

dear Mr.BusmasterJones

I know it was a long time since you posted this but can you help me with the same problem but in SQL SERVER 2005

I had a lot of error messages when i TRIED the way you described...
there was an error when I tried the first part and error message was about adding ad hoc is not allowed
then calling the method was rejected too.

Please help me!!!!

I posted this for the same problem http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1976457&SiteID=1

THANKS IN ADVANCE

Recovering DB with only the .MDF file

I saw the other thread that is related, but let me give you our circumstances. A drive failed and that drive had the SQL installation and the *.ldf files on it. The MDF files were unscathed.

The drive has been rebuilt and I have reinstalled SQL 2000 SP3A on there (that is what was there before). I have tried attaching the MDF through the GUI and letting it create the log for me. This failed.

I tried sp_attach_single_file_db, but this failed since the db was never dettached.

I tried creating the db again, dettaching it, copying the old (good) MDF file over the newly created one and then attaching (using multiple attach approaches). It knows that the log file and mdf are not matched and won't let me do the attach.

I also found DBCC REBUILD_LOG, but the article in SQL Mag supposes that your instance is still in working order and that there is an entry for the db in sysdatabases. Such is not true in my case.

Can you help? We are trying to get old backup tapes shipped to the site, looking up our Gold Partner contact info, etc., but in the meantime, I am trying to get the data restored even if we lose some transactions.

Thanks for any help!

Here is what worked for me. Thanks for SQL Server Mag for the core pieces of this:

-- LISTING 1: Undocumented DBCC Command REBUILD_LOG

/* Create a new db named the same as the inaccessible one (in this case "Ops") */

EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
GO

BEGIN TRAN

UPDATE master..sysdatabases
SET status = status | 32768
WHERE name = 'Ops'

IF @.@.ROWCOUNT = 1
BEGIN
COMMIT TRAN
RAISERROR('emergency mode set', 0, 1)
END
ELSE
BEGIN
ROLLBACK
RAISERROR('unable to set emergency mode', 16, 1)
END

GO

EXEC sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE
GO

-- 3. Stop SQL Server
-- 4. Replace the newly created Ops.mdf file with the old good one
-- 5. Rename the newly created Ops_log.ldf file
-- 6. Start SQL Server

-- 7. Run the following DBCC command:
DBCC REBUILD_LOG('Ops','E:\Program Files\Microsoft SQL Server\MSSQL\Data\Ops_log.LDF')

-- You should get the message:
-- Warning: The log for database 'Ops' has been rebuilt. Transactional consistency has been lost.

-- DBCC CHECKDB should be run to validate physical consistency. Database options will have to be reset,

-- and extra log files may need to be deleted.
-- DBCC execution completed. If DBCC printed error messages, contact your system administrator.


-- 8. Run data consistancy check
/*Perform physical and logical integrity checks at this point.
Bcp data out if your integrity checks demonstrate that problems exist.
*/
DBCC CHECKDB (Ops)


ALTER DATABASE Ops SET MULTI_USER
GO

-- Set database options and recovery model as desired.
GO

-- Make a backup and start to use the DB again

|||

Note that in SQL Server 2005, all of this can be accomplished using the

CREATE DATABASE FOR ATTACH_REBUILD_LOG command.

All of the same caveats apply: if you attach a database without a log, you stand a good chance of losing data and/or ending up with a corrupt database. If you've got no choice, you've got no choice. That's what backups are for.

|||

dear Mr.BusmasterJones

I know it was a long time since you posted this but can you help me with the same problem but in SQL SERVER 2005

I had a lot of error messages when i TRIED the way you described...
there was an error when I tried the first part and error message was about adding ad hoc is not allowed
then calling the method was rejected too.

Please help me!!!!

I posted this for the same problem http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1976457&SiteID=1

THANKS IN ADVANCE
sql

Recovering Database. Urgent.

I have a fairly large database (225Gb) on a test server. The OS (NT 4) drive
has died and I will have to reinstall it from scratch. My question is, I
still have the database files (SQL 7) intact is it possible for me to
reinstall everything, recreate the database and then point it at the
original database files?
GavThe "point" part would be sp_attach_db. It is only documented to work if you first did sp_detach_db, but it
might work.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Gavin Metcalfe" <gavin.metcalfe@.btinternet.com> wrote in message news:c8f7u9$ipt$1@.sparta.btinternet.com...
> I have a fairly large database (225Gb) on a test server. The OS (NT 4) drive
> has died and I will have to reinstall it from scratch. My question is, I
> still have the database files (SQL 7) intact is it possible for me to
> reinstall everything, recreate the database and then point it at the
> original database files?
> Gav
>|||Ok, how about if I create a new database, then stop the services and change
the files it has created for the old ones.
Gav
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:#QnWSIYPEHA.1048@.tk2msftngp13.phx.gbl...
> The "point" part would be sp_attach_db. It is only documented to work if
you first did sp_detach_db, but it
> might work.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Gavin Metcalfe" <gavin.metcalfe@.btinternet.com> wrote in message
news:c8f7u9$ipt$1@.sparta.btinternet.com...
> > I have a fairly large database (225Gb) on a test server. The OS (NT 4)
drive
> > has died and I will have to reinstall it from scratch. My question is, I
> > still have the database files (SQL 7) intact is it possible for me to
> > reinstall everything, recreate the database and then point it at the
> > original database files?
> >
> > Gav
> >
> >
>|||Yes, look at sp_attachdb in BOL. Try to get SQL Server to the same patch
level as it was previously before doing this though.
Regards,
William D. Bartholomew
http://blog.bartholomew.id.au/
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!|||Hi,
Yes, you can try that as well. In both the cases you have to create all your
logins , jobs, operators , linked server .....
Another approach which will give back your database server as same as old
stage:-
Once your hard disk drives are accessible, take the copy of MDF and LDF to a
new safe place and do the below steps.
To do this you should have all you system and user databases MDF and LDF
files.
1. Install Windows NT and Service packs. Name computer name as OLD name.
2. Install SQL 7 and install the service pack as old level. Ensure that you
install sql server
with same directory structure.
3. Stop SQL server and SQl sgent service
4. Copy all the MDF and LDF files , Ensure that you copy
the system database files for master, Model, tempdb, msdb databases
5. After the successful copy, start the SQl server
Mostly by doing this steps you can go back to old stage with all the
databases up.
Thanks
Hari
MCDBA
"Gavin Metcalfe" <gavin.metcalfe@.btinternet.com> wrote in message
news:c8f9be$2l9$1@.hercules.btinternet.com...
> Ok, how about if I create a new database, then stop the services and
change
> the files it has created for the old ones.
> Gav
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in
> message news:#QnWSIYPEHA.1048@.tk2msftngp13.phx.gbl...
> > The "point" part would be sp_attach_db. It is only documented to work if
> you first did sp_detach_db, but it
> > might work.
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Gavin Metcalfe" <gavin.metcalfe@.btinternet.com> wrote in message
> news:c8f7u9$ipt$1@.sparta.btinternet.com...
> > > I have a fairly large database (225Gb) on a test server. The OS (NT 4)
> drive
> > > has died and I will have to reinstall it from scratch. My question is,
I
> > > still have the database files (SQL 7) intact is it possible for me to
> > > reinstall everything, recreate the database and then point it at the
> > > original database files?
> > >
> > > Gav
> > >
> > >
> >
> >
>|||Thats is round about what I am planning to do. Database is too large for me
to move somewhere else so I'm going to rename the files to .old to start
with. It is a SAP database so I'm going to reinstall SAP and let it recreate
its standard database and then I'm planning to replace the new files with
the old.
Gav
"Hari" <hari_prasad_k@.hotmail.com> wrote in message
news:#8zreRYPEHA.3264@.tk2msftngp13.phx.gbl...
> Hi,
> Yes, you can try that as well. In both the cases you have to create all
your
> logins , jobs, operators , linked server .....
> Another approach which will give back your database server as same as old
> stage:-
> Once your hard disk drives are accessible, take the copy of MDF and LDF to
a
> new safe place and do the below steps.
> To do this you should have all you system and user databases MDF and LDF
> files.
> 1. Install Windows NT and Service packs. Name computer name as OLD name.
> 2. Install SQL 7 and install the service pack as old level. Ensure that
you
> install sql server
> with same directory structure.
> 3. Stop SQL server and SQl sgent service
> 4. Copy all the MDF and LDF files , Ensure that you copy
> the system database files for master, Model, tempdb, msdb databases
> 5. After the successful copy, start the SQl server
> Mostly by doing this steps you can go back to old stage with all the
> databases up.
> Thanks
> Hari
> MCDBA
>
>
>
> "Gavin Metcalfe" <gavin.metcalfe@.btinternet.com> wrote in message
> news:c8f9be$2l9$1@.hercules.btinternet.com...
> > Ok, how about if I create a new database, then stop the services and
> change
> > the files it has created for the old ones.
> >
> > Gav
> >
> > "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in
> > message news:#QnWSIYPEHA.1048@.tk2msftngp13.phx.gbl...
> > > The "point" part would be sp_attach_db. It is only documented to work
if
> > you first did sp_detach_db, but it
> > > might work.
> > >
> > > --
> > > Tibor Karaszi, SQL Server MVP
> > > http://www.karaszi.com/sqlserver/default.asp
> > > http://www.solidqualitylearning.com/
> > >
> > >
> > > "Gavin Metcalfe" <gavin.metcalfe@.btinternet.com> wrote in message
> > news:c8f7u9$ipt$1@.sparta.btinternet.com...
> > > > I have a fairly large database (225Gb) on a test server. The OS (NT
4)
> > drive
> > > > has died and I will have to reinstall it from scratch. My question
is,
> I
> > > > still have the database files (SQL 7) intact is it possible for me
to
> > > > reinstall everything, recreate the database and then point it at the
> > > > original database files?
> > > >
> > > > Gav
> > > >
> > > >
> > >
> > >
> >
> >
>

Tuesday, March 20, 2012

Recover lost data

Hello!

Hopefully someone can help me that i have lost my data on my D: drive.

driven shown all folder but in side of the folder there is nothing.

i have lost my Doc, xls, Jpeg etc. all files.

please help me what sould i have to do.

thanks

This forum is specific to disaster recovery in SQL Server databases.

The standard answer is that you need to find your most recent backup and restore from it.

|||Don't worry you will get back your data. Try Stellar Phoenix Windows Data Recovery Software a file and parition recovery utility which recovers the lost data from formatted hard drive or data lost occur due to software malfunction, viruses or even sabotage.
Download the demo version of the software from: http://www.stellarinfo.com/partition-recovery.htm Scan your hard drive with it and it will show you the preview of the recovered data. If you are able to see your data through demo version then get the full version to save it.

Recover lost data

Hello!

Hopefully someone can help me that i have lost my data on my D: drive.

driven shown all folder but in side of the folder there is nothing.

i have lost my Doc, xls, Jpeg etc. all files.

please help me what sould i have to do.

thanks

This forum is specific to disaster recovery in SQL Server databases.

The standard answer is that you need to find your most recent backup and restore from it.

|||Don't worry you will get back your data. Try Stellar Phoenix Windows Data Recovery Software a file and parition recovery utility which recovers the lost data from formatted hard drive or data lost occur due to software malfunction, viruses or even sabotage.
Download the demo version of the software from: http://www.stellarinfo.com/partition-recovery.htm Scan your hard drive with it and it will show you the preview of the recovered data. If you are able to see your data through demo version then get the full version to save it.