Lynn Pettis (8/17/2012)
cphite (8/17/2012)
I've been tasked with trying to set up log shipping in a blind scenario... that is, the source server and the target server cannot communicate with one another directly, or even see one another.So we have log shipping enabled on the source side, and we're creating logs, and then getting them over to our DR site via some snap-mirroring magic.
My idea is to restore the databases on the target side in STANDBY mode, and then create a job that basically does the following:
1. Look for new .trn files in a folder.
2. Determine what .trn file is next in the chain based on the LSN number recorded in the .trn file.
3. Restore that log.
4. Look for the next one.
5. Repeat until there are no more logs.
6. Run again later to look for new logs, etc.
My problem is this... I can find the current LSN for a database by using dbcc log ('<Database>') but it's coming across as a hex value; for example 00000bde:000003cc:0001
My question is, how do I convert 00000bde:000003cc:0001 into something like 3035000000068900057? Or vice-versa? CAST and CONVERT don't seem to be working - I keep getting overflow errors.
Barring that; is there a better way to be doing log shipping in this scenario?
First, if your t-log files are date/time stamped in the filename, wouldn't it make sense to process them in that order?
Second, if you need to look at LSN's, check out this: http://msdn.microsoft.com/en-us/library/ms178536(v=sql.100).aspx.
I know how to get the LSN's from the files; my question is how to get the LSN from the database that is currently sitting in standby mode, and convert it into a format that I can use. I can't just process all of the files in order because it's possible that a file may have been created prior to the backup that I'm restoring from. I need to know which file is first in the chain since the restore point.
Also, while it's true that the file names are date/time stamped, it just seems like an LSN would be a much more specific and reliable way to go with an automated process.