Showing posts with label recovering. Show all posts
Showing posts with label recovering. Show all posts

Sunday, March 25, 2012

Dropping a RECOVERING database

Hi,

Is there any way(better) to drop a RECOVERING database?

We tried to change a db from READ ONLY state to READ/WRITE state and this took forever (db is very small 40 MB) and we tried to kill this process and this went to KILLED/ROLLBACK state and blocking other processes.

We tried to even stop the sql server but that didn't work. We had to reboot the windows server. Now that particular database is in 'RECOVERING' state and we want to get rid of it. We've a backup of it.

Any ideas how to drop this database?

Because of this RECOVERING database, SQL Agent is not starting. The Agent error log says, it's waiting on SQL server to complete the recovery.

We've SQL 2005 with service pack1.

Any ideas are highly appreciated.

Thanks,

Siva.

You can stop sqlserver service. Rename the log file. Restart sqlserver service - this will put the database into suspect mode. You should be able to drop the database now.
(do be sure you have a good backup before forcing the deletion outlined above).|||

Thanks........that worked....

Still don't understand why it took so long to change from READ ONLY to READ/WRITE and also why it took so long for rollback as well.

|||Do you still have the errorlogs?

--

Peter Byrne

Microsoft SQL Server Storage Engine

This posting is provided "AS IS" with no warranties, and confers no rights.

wrote in message

news:1acc8880-1e4a-44e2-80d0-1cdb75e87ad6@.discussions.microsoft.com...

> Thanks........that worked....

>

> Still don't understand why it took so long to change from READ ONLY to

> READ/WRITE and also why it took so long for rollback as well.

>

>

>

>

>

>|||

We did see in the error log the STACK DUMP thing and the following message many times:

Process 71:0:0 (0x69c) Worker 0x78FF80E8 appears to be non-yielding on Scheduler 2. Thread creation time: 12804246994487. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 98%. Interval: 7331203 ms.

71 was the process we killed but was unyielding.....

|||Can you post the errorlog and the .mdmp from the stack dump?

--

Peter Byrne

Microsoft SQL Server Storage Engine

This posting is provided "AS IS" with no warranties, and confers no rights.

wrote in message

news:270127c2-61e0-44c0-bda8-fa176b32924f@.discussions.microsoft.com...

> We did see in the error log the STACK DUMP thing and the following

> message many times:

>

>

>

> Process 71:0:0 (0x69c) Worker 0x78FF80E8 appears to be non-yielding on

> Scheduler 2. Thread creation time: 12804246994487. Approx Thread CPU

> Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 98%.

> Interval: 7331203 ms.

>

>

>

> 71 was the process we killed but was unyielding.....

>

>|||

I've 4 .mdmp files each is about 2.5 MB.

I don't know how I can post it here...

Do you need any specific info?

|||Can you please mail one to me directly? The one with the lowest numbered

extension would likely be the best one.

--

Peter Byrne

Microsoft SQL Server Storage Engine

This posting is provided "AS IS" with no warranties, and confers no rights.

wrote in message

news:9aeb4aec-aa39-43b3-9ab2-658e5d06f246@.discussions.microsoft.com...

> I've 4 .mdmp files each is about 2.5 MB.

>

> I don't know how I can post it here...

>

> Do you need any specific info?

>

>

>

>|||

What's your e-mail address?

Is it 9aeb4aec-aa39-43b3-9ab2-658e5d06f246@.discussions.microsoft.com ?

or ?

|||Its peterbyr@. microsoft.com.

--

Peter Byrne

Microsoft SQL Server Storage Engine

This posting is provided "AS IS" with no warranties, and confers no rights.

wrote in message

news:a76af29a-9309-4a90-b52f-b469160de25a@.discussions.microsoft.com...

> What's your e-mail address?

>

>

>

> Is it 9aeb4aec-aa39-43b3-9ab2-658e5d06f246@.discussions.microsoft.com ?

>

> or ?

>

>sql

Friday, February 24, 2012

drive is corupted

Hi,
the drive with the data file is corupted, however the
drive where the transaction log is located is fine.
What is the best aproach for recovering the db ?
Can I restore the db from the last full db backup and
then backup the curent log and apply to it ?
The only thing that has happened beetween the full db
backup and crash is one transaction log backup.
Any view is apreciated!Mirna,
> What is the best aproach for recovering the db ?
Are you currently dong log backups? What is the recovery model for the database. If it is simple,
then you can only recovery up to the latest database backup. If it is full and you also do log
backup, do a log backup now using the NO_TRUNCATE parameter and then restore the latest database
backup and all subsequent log backups (including this last one).
> Can I restore the db from the last full db backup and
> then backup the curent log and apply to it ?
No, as soon as you restored you lost the stuff in the log file. Always start with performing a log
backup as I explained above.
> The only thing that has happened beetween the full db
> backup and crash is one transaction log backup.
Then it seems that you are in good shape. Do this last log backup and then the restore stuff.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Mirna" <anonymous@.discussions.microsoft.com> wrote in message
news:09c601c3b8d3$d5a16400$a501280a@.phx.gbl...
> Hi,
> the drive with the data file is corupted, however the
> drive where the transaction log is located is fine.
> What is the best aproach for recovering the db ?
> Can I restore the db from the last full db backup and
> then backup the curent log and apply to it ?
> The only thing that has happened beetween the full db
> backup and crash is one transaction log backup.
> Any view is apreciated!|||Thanks Tibor for a quick answer!
The recovery model for the database is full.
mdf file is not accesible as well as the last transaction
log backup( they reside on the same drive and they are not
backed up to a tape before the failure ).
I can not perform the transaction log backup since the
problem is actually OS not the hardware.It looks like that
I will have to go to a last full db backup unless I can
somehow apply the transaction log (ldf file).
In other words I have full db backup of Mydb.BAK and ldf
file of the same db. Since the transaction log backup
was performed once I am wondering if that made the log(ldf)
invalid. I am backing the log as a part of the db
maintenance plan.
Thanks in advance!
>--Original Message--
>Mirna,
>> What is the best aproach for recovering the db ?
>Are you currently dong log backups? What is the recovery
model for the database. If it is simple,
>then you can only recovery up to the latest database
backup. If it is full and you also do log
>backup, do a log backup now using the NO_TRUNCATE
parameter and then restore the latest database
>backup and all subsequent log backups (including this
last one).
>
>> Can I restore the db from the last full db backup and
>> then backup the curent log and apply to it ?
>No, as soon as you restored you lost the stuff in the log
file. Always start with performing a log
>backup as I explained above.
>
>> The only thing that has happened beetween the full db
>> backup and crash is one transaction log backup.
>Then it seems that you are in good shape. Do this last
log backup and then the restore stuff.
>--
>Tibor Karaszi, SQL Server MVP
>Archive at: http://groups.google.com/groups?
oi=djq&as_ugroup=microsoft.public.sqlserver
>
>"Mirna" <anonymous@.discussions.microsoft.com> wrote in
message
>news:09c601c3b8d3$d5a16400$a501280a@.phx.gbl...
>> Hi,
>> the drive with the data file is corupted, however the
>> drive where the transaction log is located is fine.
>> What is the best aproach for recovering the db ?
>> Can I restore the db from the last full db backup and
>> then backup the curent log and apply to it ?
>> The only thing that has happened beetween the full db
>> backup and crash is one transaction log backup.
>> Any view is apreciated!
>
>.
>|||> The recovery model for the database is full.
> mdf file is not accesible as well as the last transaction
> log backup
Ouch. Then you would not be able to use a log backup even if you managed to do one at this point in
time. This is because the log is emptied each time you do a log backup, so now you are in a
situation where you did a log backup and that is lost. You have a "hole" in your sequence of log
records.
If it weren't for that prior log backup is lost, you could actually product this last one log backup
event though the OS install is damaged (or if SQL Server install is damaged). You would "fake"
another database on another SQL Server, slide in that log file (ldf) into that install and then do
the log backup using NO_TRUNCATE on that installation. There's a KB article on that subject. This is
only FYI as this unfortunately won't help you because of that missing prior log backup.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Mirna" <anonymous@.discussions.microsoft.com> wrote in message
news:0ad701c3b8df$3be49600$a401280a@.phx.gbl...
> Thanks Tibor for a quick answer!
> The recovery model for the database is full.
> mdf file is not accesible as well as the last transaction
> log backup( they reside on the same drive and they are not
> backed up to a tape before the failure ).
> I can not perform the transaction log backup since the
> problem is actually OS not the hardware.It looks like that
> I will have to go to a last full db backup unless I can
> somehow apply the transaction log (ldf file).
> In other words I have full db backup of Mydb.BAK and ldf
> file of the same db. Since the transaction log backup
> was performed once I am wondering if that made the log(ldf)
> invalid. I am backing the log as a part of the db
> maintenance plan.
> Thanks in advance!
>
> >--Original Message--
> >Mirna,
> >
> >> What is the best aproach for recovering the db ?
> >
> >Are you currently dong log backups? What is the recovery
> model for the database. If it is simple,
> >then you can only recovery up to the latest database
> backup. If it is full and you also do log
> >backup, do a log backup now using the NO_TRUNCATE
> parameter and then restore the latest database
> >backup and all subsequent log backups (including this
> last one).
> >
> >
> >> Can I restore the db from the last full db backup and
> >> then backup the curent log and apply to it ?
> >
> >No, as soon as you restored you lost the stuff in the log
> file. Always start with performing a log
> >backup as I explained above.
> >
> >
> >> The only thing that has happened beetween the full db
> >> backup and crash is one transaction log backup.
> >
> >Then it seems that you are in good shape. Do this last
> log backup and then the restore stuff.
> >--
> >Tibor Karaszi, SQL Server MVP
> >Archive at: http://groups.google.com/groups?
> oi=djq&as_ugroup=microsoft.public.sqlserver
> >
> >
> >"Mirna" <anonymous@.discussions.microsoft.com> wrote in
> message
> >news:09c601c3b8d3$d5a16400$a501280a@.phx.gbl...
> >> Hi,
> >>
> >> the drive with the data file is corupted, however the
> >> drive where the transaction log is located is fine.
> >>
> >> What is the best aproach for recovering the db ?
> >> Can I restore the db from the last full db backup and
> >> then backup the curent log and apply to it ?
> >> The only thing that has happened beetween the full db
> >> backup and crash is one transaction log backup.
> >>
> >> Any view is apreciated!
> >
> >
> >.
> >|||Thanks Tibor,
I understand what you are saying.. too bad that we will
have to go to a last full db backup. Thank You again!
>--Original Message--
>> The recovery model for the database is full.
>> mdf file is not accesible as well as the last
transaction
>> log backup
>Ouch. Then you would not be able to use a log backup even
if you managed to do one at this point in
>time. This is because the log is emptied each time you do
a log backup, so now you are in a
>situation where you did a log backup and that is lost.
You have a "hole" in your sequence of log
>records.
>If it weren't for that prior log backup is lost, you
could actually product this last one log backup
>event though the OS install is damaged (or if SQL Server
install is damaged). You would "fake"
>another database on another SQL Server, slide in that log
file (ldf) into that install and then do
>the log backup using NO_TRUNCATE on that installation.
There's a KB article on that subject. This is
>only FYI as this unfortunately won't help you because of
that missing prior log backup.
>--
>Tibor Karaszi, SQL Server MVP
>Archive at: http://groups.google.com/groups?
oi=djq&as_ugroup=microsoft.public.sqlserver
>
>"Mirna" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0ad701c3b8df$3be49600$a401280a@.phx.gbl...
>> Thanks Tibor for a quick answer!
>> The recovery model for the database is full.
>> mdf file is not accesible as well as the last
transaction
>> log backup( they reside on the same drive and they are
not
>> backed up to a tape before the failure ).
>> I can not perform the transaction log backup since the
>> problem is actually OS not the hardware.It looks like
that
>> I will have to go to a last full db backup unless I can
>> somehow apply the transaction log (ldf file).
>> In other words I have full db backup of Mydb.BAK and ldf
>> file of the same db. Since the transaction log backup
>> was performed once I am wondering if that made the log
(ldf)
>> invalid. I am backing the log as a part of the db
>> maintenance plan.
>> Thanks in advance!
>>
>> >--Original Message--
>> >Mirna,
>> >
>> >> What is the best aproach for recovering the db ?
>> >
>> >Are you currently dong log backups? What is the
recovery
>> model for the database. If it is simple,
>> >then you can only recovery up to the latest database
>> backup. If it is full and you also do log
>> >backup, do a log backup now using the NO_TRUNCATE
>> parameter and then restore the latest database
>> >backup and all subsequent log backups (including this
>> last one).
>> >
>> >
>> >> Can I restore the db from the last full db backup
and
>> >> then backup the curent log and apply to it ?
>> >
>> >No, as soon as you restored you lost the stuff in the
log
>> file. Always start with performing a log
>> >backup as I explained above.
>> >
>> >
>> >> The only thing that has happened beetween the full db
>> >> backup and crash is one transaction log backup.
>> >
>> >Then it seems that you are in good shape. Do this last
>> log backup and then the restore stuff.
>> >--
>> >Tibor Karaszi, SQL Server MVP
>> >Archive at: http://groups.google.com/groups?
>> oi=djq&as_ugroup=microsoft.public.sqlserver
>> >
>> >
>> >"Mirna" <anonymous@.discussions.microsoft.com> wrote in
>> message
>> >news:09c601c3b8d3$d5a16400$a501280a@.phx.gbl...
>> >> Hi,
>> >>
>> >> the drive with the data file is corupted, however the
>> >> drive where the transaction log is located is fine.
>> >>
>> >> What is the best aproach for recovering the db ?
>> >> Can I restore the db from the last full db backup
and
>> >> then backup the curent log and apply to it ?
>> >> The only thing that has happened beetween the full db
>> >> backup and crash is one transaction log backup.
>> >>
>> >> Any view is apreciated!
>> >
>> >
>> >.
>> >
>
>.
>|||Is there a way that ldf file can be used to recover the
database if the transaction log backup and .mdf file is
lost ? Does Microsoft has any utility that can recover
what has been flushed to mdf file during the transaction
log backup ?
Any view is apreciated
>--Original Message--
>Thanks Tibor,
>I understand what you are saying.. too bad that we will
>have to go to a last full db backup. Thank You again!
>>--Original Message--
>> The recovery model for the database is full.
>> mdf file is not accesible as well as the last
>transaction
>> log backup
>>Ouch. Then you would not be able to use a log backup
even
>if you managed to do one at this point in
>>time. This is because the log is emptied each time you
do
>a log backup, so now you are in a
>>situation where you did a log backup and that is lost.
>You have a "hole" in your sequence of log
>>records.
>>If it weren't for that prior log backup is lost, you
>could actually product this last one log backup
>>event though the OS install is damaged (or if SQL Server
>install is damaged). You would "fake"
>>another database on another SQL Server, slide in that
log
>file (ldf) into that install and then do
>>the log backup using NO_TRUNCATE on that installation.
>There's a KB article on that subject. This is
>>only FYI as this unfortunately won't help you because of
>that missing prior log backup.
>>--
>>Tibor Karaszi, SQL Server MVP
>>Archive at: http://groups.google.com/groups?
>oi=djq&as_ugroup=microsoft.public.sqlserver
>>
>>"Mirna" <anonymous@.discussions.microsoft.com> wrote in
>message
>>news:0ad701c3b8df$3be49600$a401280a@.phx.gbl...
>> Thanks Tibor for a quick answer!
>> The recovery model for the database is full.
>> mdf file is not accesible as well as the last
>transaction
>> log backup( they reside on the same drive and they are
>not
>> backed up to a tape before the failure ).
>> I can not perform the transaction log backup since the
>> problem is actually OS not the hardware.It looks like
>that
>> I will have to go to a last full db backup unless I can
>> somehow apply the transaction log (ldf file).
>> In other words I have full db backup of Mydb.BAK and
ldf
>> file of the same db. Since the transaction log backup
>> was performed once I am wondering if that made the log
>(ldf)
>> invalid. I am backing the log as a part of the db
>> maintenance plan.
>> Thanks in advance!
>>
>> >--Original Message--
>> >Mirna,
>> >
>> >> What is the best aproach for recovering the db ?
>> >
>> >Are you currently dong log backups? What is the
>recovery
>> model for the database. If it is simple,
>> >then you can only recovery up to the latest database
>> backup. If it is full and you also do log
>> >backup, do a log backup now using the NO_TRUNCATE
>> parameter and then restore the latest database
>> >backup and all subsequent log backups (including this
>> last one).
>> >
>> >
>> >> Can I restore the db from the last full db backup
>and
>> >> then backup the curent log and apply to it ?
>> >
>> >No, as soon as you restored you lost the stuff in the
>log
>> file. Always start with performing a log
>> >backup as I explained above.
>> >
>> >
>> >> The only thing that has happened beetween the full
db
>> >> backup and crash is one transaction log backup.
>> >
>> >Then it seems that you are in good shape. Do this last
>> log backup and then the restore stuff.
>> >--
>> >Tibor Karaszi, SQL Server MVP
>> >Archive at: http://groups.google.com/groups?
>> oi=djq&as_ugroup=microsoft.public.sqlserver
>> >
>> >
>> >"Mirna" <anonymous@.discussions.microsoft.com> wrote in
>> message
>> >news:09c601c3b8d3$d5a16400$a501280a@.phx.gbl...
>> >> Hi,
>> >>
>> >> the drive with the data file is corupted, however
the
>> >> drive where the transaction log is located is fine.
>> >>
>> >> What is the best aproach for recovering the db ?
>> >> Can I restore the db from the last full db backup
>and
>> >> then backup the curent log and apply to it ?
>> >> The only thing that has happened beetween the full
db
>> >> backup and crash is one transaction log backup.
>> >>
>> >> Any view is apreciated!
>> >
>> >
>> >.
>> >
>>
>>.
>.
>|||> Is there a way that ldf file can be used to recover the
> database if the transaction log backup and .mdf file is
> lost ?
No. As I described, you have a missing log backup.
> Does Microsoft has any utility that can recover
> what has been flushed to mdf file during the transaction
> log backup ?
This is not how things work ("flushed to mdf file"). Read about transaction log handling and backup
and restore in Books Online.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Mirna" <anonymous@.discussions.microsoft.com> wrote in message
news:b43501c3b8f1$7cf00640$a601280a@.phx.gbl...
> Is there a way that ldf file can be used to recover the
> database if the transaction log backup and .mdf file is
> lost ? Does Microsoft has any utility that can recover
> what has been flushed to mdf file during the transaction
> log backup ?
> Any view is apreciated
> >--Original Message--
> >Thanks Tibor,
> >
> >I understand what you are saying.. too bad that we will
> >have to go to a last full db backup. Thank You again!
> >
> >>--Original Message--
> >> The recovery model for the database is full.
> >> mdf file is not accesible as well as the last
> >transaction
> >> log backup
> >>
> >>Ouch. Then you would not be able to use a log backup
> even
> >if you managed to do one at this point in
> >>time. This is because the log is emptied each time you
> do
> >a log backup, so now you are in a
> >>situation where you did a log backup and that is lost.
> >You have a "hole" in your sequence of log
> >>records.
> >>
> >>If it weren't for that prior log backup is lost, you
> >could actually product this last one log backup
> >>event though the OS install is damaged (or if SQL Server
> >install is damaged). You would "fake"
> >>another database on another SQL Server, slide in that
> log
> >file (ldf) into that install and then do
> >>the log backup using NO_TRUNCATE on that installation.
> >There's a KB article on that subject. This is
> >>only FYI as this unfortunately won't help you because of
> >that missing prior log backup.
> >>
> >>--
> >>Tibor Karaszi, SQL Server MVP
> >>Archive at: http://groups.google.com/groups?
> >oi=djq&as_ugroup=microsoft.public.sqlserver
> >>
> >>
> >>"Mirna" <anonymous@.discussions.microsoft.com> wrote in
> >message
> >>news:0ad701c3b8df$3be49600$a401280a@.phx.gbl...
> >> Thanks Tibor for a quick answer!
> >>
> >> The recovery model for the database is full.
> >> mdf file is not accesible as well as the last
> >transaction
> >> log backup( they reside on the same drive and they are
> >not
> >> backed up to a tape before the failure ).
> >> I can not perform the transaction log backup since the
> >> problem is actually OS not the hardware.It looks like
> >that
> >> I will have to go to a last full db backup unless I can
> >> somehow apply the transaction log (ldf file).
> >> In other words I have full db backup of Mydb.BAK and
> ldf
> >> file of the same db. Since the transaction log backup
> >> was performed once I am wondering if that made the log
> >(ldf)
> >> invalid. I am backing the log as a part of the db
> >> maintenance plan.
> >>
> >> Thanks in advance!
> >>
> >>
> >> >--Original Message--
> >> >Mirna,
> >> >
> >> >> What is the best aproach for recovering the db ?
> >> >
> >> >Are you currently dong log backups? What is the
> >recovery
> >> model for the database. If it is simple,
> >> >then you can only recovery up to the latest database
> >> backup. If it is full and you also do log
> >> >backup, do a log backup now using the NO_TRUNCATE
> >> parameter and then restore the latest database
> >> >backup and all subsequent log backups (including this
> >> last one).
> >> >
> >> >
> >> >> Can I restore the db from the last full db backup
> >and
> >> >> then backup the curent log and apply to it ?
> >> >
> >> >No, as soon as you restored you lost the stuff in the
> >log
> >> file. Always start with performing a log
> >> >backup as I explained above.
> >> >
> >> >
> >> >> The only thing that has happened beetween the full
> db
> >> >> backup and crash is one transaction log backup.
> >> >
> >> >Then it seems that you are in good shape. Do this last
> >> log backup and then the restore stuff.
> >> >--
> >> >Tibor Karaszi, SQL Server MVP
> >> >Archive at: http://groups.google.com/groups?
> >> oi=djq&as_ugroup=microsoft.public.sqlserver
> >> >
> >> >
> >> >"Mirna" <anonymous@.discussions.microsoft.com> wrote in
> >> message
> >> >news:09c601c3b8d3$d5a16400$a501280a@.phx.gbl...
> >> >> Hi,
> >> >>
> >> >> the drive with the data file is corupted, however
> the
> >> >> drive where the transaction log is located is fine.
> >> >>
> >> >> What is the best aproach for recovering the db ?
> >> >> Can I restore the db from the last full db backup
> >and
> >> >> then backup the curent log and apply to it ?
> >> >> The only thing that has happened beetween the full
> db
> >> >> backup and crash is one transaction log backup.
> >> >>
> >> >> Any view is apreciated!
> >> >
> >> >
> >> >.
> >> >
> >>
> >>
> >>.
> >>
> >.
> >