November 30, 2009 at 10:38 pm
Hello all,
I setup log shipping on 2k5 last Wednesday as a "read-only (disconnect users on restore)" configuration between our prod and a secondary server. After a few days a user discovered a data inconsistency through our reporting system. Then a developer discovered the data inconsistencies on SQL when he compared data for two different records on the prod server and there were two or three attributes for the same records that were different on the secondary server.
Has anybody encountered any problems or data inconsistencies like this before with log shipping in 2k5 using the config I stated herein?
The only thing I could think of is the first time I attempted to enable the log shipping pair I messed it up. I tried to manually restore some t-logs on the secondary but it wasn't working so I started all over from scratch and did it again successfully the second time. I thought that maybe I lost some data when I backed up t-logs on the 1st attempt and never restored them all on the 1st attempt. But when I re-inited on the second attempt, would SQL even need those tlogs from the 1st attempt if I hadn't restored all of them?
It all sounds confusing but it's not. I'd be more than happy to explain again or clarify if you need me to.
Thanks in advance for any assistance or explanation to this data inconsistency issue!!! 😀
November 30, 2009 at 11:40 pm
I have encountered this issue in my prod enviornemt, you need to keep and eye on LS using Log Shipping monitor, it will tell you when the last restore happened, whenever i tried to investigate all i could see in error log is, log chain break, all i did was i took a last full fresh backup from prod and restore in standby mode refer follwoing script...
restore database Test from disk = 'E:\DBBackup\TESTDB_200904230300.BAK'
with file = 1,
move 'TESTDB_.mdf' to 'E:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\TESTDB.mdf',
move 'TESTDB.ldf' to 'E:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\TESTDB.ldf',
standby = 'E:\Transaction_Logs\UNDO_TESTDB.DAT'
also dont ever try to do manual log restore... it never helped in my case.
December 1, 2009 at 12:07 am
Ritesh,
Thanks for the info. So you restored a good last full backup from Prod onto the secondary using "stand-by" mode and how did you continue the log ship (LS) process? Did you pause/suspend LS and after the restore was done you unpaused it again? Please clarify as I'd like to attempt this again in our Prod environment soon.
Thanks,
David
December 1, 2009 at 12:31 am
🙂 i should have mentioned this before only, neverthless I disable LS restore jobs and let the LS copy jobs run, after i am done iwth backup restore I enable the LS restore jobs. also ensure that if your last good full backup is 2-3 days older then ensure that you have copied all the transaction log backup files post the last full good backup from primary to secondary server...
December 1, 2009 at 6:27 am
ok thanks for the info!
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply