Re: vacation backup
From: Giacomo (anonymous_at_msnewsgroups.com)
Date: 08/13/04
- Next message: Jacco Schalkwijk: "Re: Large Transaction Log Backup after Database Backup"
- Previous message: SteveB: "Re: Large Transaction Log Backup after Database Backup"
- In reply to: Hari Prasad: "Re: vacation backup"
- Next in thread: Hari Prasad: "Re: vacation backup"
- Reply: Hari Prasad: "Re: vacation backup"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 13 Aug 2004 05:36:51 -0400
Hari,
I was working on something else when we were talking with MS. I believe it
was a DBCC Traceon(818,-1) used to uncover the FSN AND LSN for each
transaction log. I'll get back to you on that.
The first transaction log synchronized to the original backup and led us to
believe this was a valid TRN file. Moreover, it threw us because the size
of the log made it look important and since there was an overlap of LSN's,
the one we needed to run wouldn't. Apparently the first transaction log
contained an incomplete transaction log and when the log backup was repeated
the following Monday, it maintained the transactions listed in the first
log. I might add here that a diagonostic had been run during the the time
when the first transaction log was running and from the look of things it
did not finish before the transaction log (.TRN) had completed. This is the
only thing we can pin down as to the strangeness of the FSN and LSN of the
first transaction log.
Once we knew this, it was simply a matter of running the scripts for each
day against the 10 day old backup.
" restore log data_151 file='path\filename' with norecovery "
with the last script using STOPAT, using the with recovery.
The problem was then determining the correct STOPAT. Microsoft recommended
using Lumigent's product to search and undo the problem transactions.
Lumigent's product works best if the original mdf and ldf were saved, but in
this case the consulting company automatically backed up the database which
rendered repairing with the original ldf and mdf method impossible. I
should also add here that we thought getting the ldf and mdf from the backup
was the same thing, but Lumigent informed us that the backup does not
preserve the integrity they need to perform their operations when it is
created from a backup. Lumigent's software gave us the exact times of the
destructive transactions, required us to NOT run the STOPAT but to simply
restore the database to the current state we left off at. Restoring the
transaction logs was important in this case because the ldf and mdf were not
available.
If we had the Lumigent product prior to the destruction, we could have done
all this live. As it was, without it, we had to shut down production. In
the future, should a situation like this recur, I fully expect we can use
the Lumigent product to clean up the database without taking the database
offline.
To recap the above, with production down, we locked up access to the
database and ran the recovery(s) and then the Lumigent fix which wrote a
script to reverse all the destruction. We ran the script and were finally
back online in good shape.
Giac
"Hari Prasad" <hari_prasad_k@hotmail.com> wrote in message
news:eOvJRkOgEHA.2764@TK2MSFTNGP11.phx.gbl...
> Thats good. Could you please explain in detail with the detailed steps you
> performed to rectify the issue.
>
> Thanks
> Hari
> MCDBA
>
> "Giacomo" <anonymous@msnewsgroups.com> wrote in message
> news:ebGYKIMgEHA.644@tk2msftngp13.phx.gbl...
>> It got fixed. The LSN for the first transaction backup had bad numbers
> for
>> the 31st. On the 2nd of Aug, the same numbers were there but the
>> sequence
>> was correct whereas for the 31st, oddly it wasn't. It took an incident
>> at
>> Microsoft to solve.
>> Thanks, Hari Prasad
>> "Hari Prasad" <hari_prasad_k@hotmail.com> wrote in message
>> news:OuI%23dYFgEHA.3676@TK2MSFTNGP12.phx.gbl...
>> > Hi,
>> >
>> > In your case the restore is giving you the issue. So I fell that UNDO
>> > file
>> > wont help you.
>> > Are you doing the trasnaction log restore in the exact sequence in
>> > which
>> > backup is taken.
>> >
>> > Hope you are doing these activities on a new database by keeping the
>> > original database safe?
>> >
>> > Thanks
>> > Hari
>> > MCDBA
>> >
>> >
>> > "thejamie" <thejamie@discussions.microsoft.com> wrote in message
>> > news:D162C7CD-D62C-4A5B-A324-BC780DD60D70@microsoft.com...
>> >> Thanks for the reply.
>> >> No errors during. Error after is similar to:
>> >>
>> >> Incorrect Recovery Path... we tinkered and tried running with Query
>> >> Analyzer and received a similar error. Everyone has gone to sleep,
> will
>> > know
>> >> more when we try again in another hour or so. The database also seems
> to
>> >> lock into the loading mode frequently. I haven't figured out what
>> >> that
>> >> is
>> >> about but we keep rebooting to get the database back online. I
>> >> suspect
>> > that
>> >> because of the Sunday gap during which a reindexing was run, there is
>> > trouble
>> >> getting the log for Monday to restore as the next in sequence after
>> >> Saturday's log. We tried re-running the indexing to see if the
>> > transaction
>> >> log would then function from that point on but that appears to be a
>> > problem
>> >> as well.
>> >>
>> >> Is there a way to use the UNDO file in the readonly mode that could
> check
>> >> for transactions that the next log file in the series would be
> expecting
>> > to
>> >> have been run?
>> >>
>> >>
>> >> "Hari Prasad" wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > Are you getting any errors during the log restore? Normally
> transaction
>> > log
>> >> > backup taken after reindexing will take longer to restore.
>> >> >
>> >> > Thanks
>> >> > Hari
>> >> > MCDBA
>> >> >
>> >> >
>> >> > "Giacomo" <anonymous@msnewsgroups.com> wrote in message
>> >> > news:OXWbS6DgEHA.396@TK2MSFTNGP12.phx.gbl...
>> >> > > No one did backup for 10 days and a table was deleted. Trying to
>> > restore
>> >> > > from the last full backup from 10 days ago. Backup itself works
>> >> > > as
>> > does
>> >> > the
>> >> > > first transaction log. We specify "restore log xyz
>> >> > > file='filename'
>> > with
>> >> > > norecovery" and the first goes fine. This one is one day prior to
>> > Sunday
>> >> > > when no transaction log was run, but the database was reindexed as
> a
>> > job
>> >> > > under the agent. Attempts to "restore log xyz file='nextfilename'
>> > with
>> >> > > norecovery" are unsuccessful. Entire company is sitting on their
>> > hands.
>> >> > > Desperate.
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >
>> >
>>
>>
>
>
- Next message: Jacco Schalkwijk: "Re: Large Transaction Log Backup after Database Backup"
- Previous message: SteveB: "Re: Large Transaction Log Backup after Database Backup"
- In reply to: Hari Prasad: "Re: vacation backup"
- Next in thread: Hari Prasad: "Re: vacation backup"
- Reply: Hari Prasad: "Re: vacation backup"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
