March 10, 2003 at 2:28 pm
You should check out a third party product by Lumigent called Log Explorer. This can roll back individual transactions. Maybe this product will influence your decision to replicate or log ship.
Ken
March 12, 2003 at 7:30 am
I have this exact scenario and have thoroughly tested it with great success. I prefer to rebuild the production server and reset the failover, mainly because the failover server is still busy servicing the over database servers. Can't help with the replication questions.
quote:
Let's say I have two production servers (SQLA, SQLB) and want to have both Log Ship to a single failover server (SQLFail).If SQLA needs to failover to SQLFail, can SQLB still use SQLFail as it's failover?
Also, once SQLA comes back online, is it advisable to use it as the new failover for the portion of the business that is now running on SQLFail?
In that scenario you would have SQLB log shipping its databases to SQLFail and SQLFail logshipping to SQLA. Is that feasible or am I off my rocker?
John Zacharkan
John Zacharkan
March 12, 2003 at 7:39 am
Yes and no, If you leave your database in read only mode you can use it for reporting/querying. The problem, when log shipping goes to apply the next transaction log it will fail, however your agent retry again at the next schedule interval to reload the tran log file. If you can live with that fine, just remember that your databases will continue to grow out of sync until the tran logs can be applied.
quote:
You can do log shipping and leave the DB in read only mode so it can be queried.All in all replication is very good for real-time synchronisation but you have to consider the recoverability overhead when replication falls down. Log shipping is much easier to manage when you need to recover from failures,
John Zacharkan
John Zacharkan
March 12, 2003 at 7:45 am
If I remeber right from my days at Microsoft, Log shipping was developed as an internal solution by a a couple of DBA's/ developers to handle their bus. needs. How it ended up on the option pack eludes me.
quote:
paulbowman:I'm curious where you got the information that it was developed independently of Microsoft.
Cheers,
Ken
John Zacharkan
John Zacharkan
March 13, 2003 at 5:45 am
To answer Ken Klaft - anecdotally, from a trainer about 3 years ago. Not very verifiable I agree. I defer to zach_john's account as he's nearer the source. In any case the process is inherent in the backup and restore mechanisms which is why it is relatively simple to script your own DIY version. Plus I think the same process was already in use in Oracle contexts (certainly in 7.3.3. according to my Oracle collegues) before SQL 7 release so the concept would have been ambient.
The MS version has "black-boxed" the process a little bit by sucking it into sqlmaint.exe which, to be fair, does serve a useful coordinating role to stop your various maintenance tasks interfering with each other. OTOH it is a barrier in the rare event that LS does start behaving strangly (only ever seen this on one system using BORK LS, to be fair, and we use BORK & 2K flavours on 30-plus production systems without any trouble).
March 14, 2003 at 10:44 am
Is any one using SLS, simple log shipping ?
March 14, 2003 at 11:17 am
What about BITS, it is comparable to the RSYNCH capability that was mentioned ealier. I have not used it yet, would be curious to see if anyone has used it for this.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bits/bits/bits_start_page.asp
Tim C.
//Will write code for food
Tim C //Will code for food
March 16, 2003 at 11:23 am
quote:
We do a *different* kind of replication.We have three sites all connected via T1 lines. We have had the worst time getting the MS replication to work across the WAN to 2 offsite locations. We came up with our own solution. After hiring some consultants, and paying MS to trouble shoot it, they all came back with "it ain't gonna work, stop trying".
We are lucky to have a linux guru on staff at our company. He has set up an RSYNC server on a Red Hat 7.3 box.
For those of you who are not familiar with RSYNC, it works like this...
Linux box mounts drives at all locations.
RSYNC takes a hash of the the mdf file and compares it to a hash of the same file on the destination computer.
it reads from the active database, and writes to a read-only unlocked file at the other two sites.
every 5 minutes or so, it takes a new binary hash of the files and compares them
if the source mdf file differes from the destination mdf, only the bits in the file that are different are transfered.
in other words, we have a 5 gig database. initially that 5 gig database is rsynched over to the other servers. once the initial huge file transfer has taken place, the read-only file gets updated, without having to copy the whole file over again. RSYNC does a byte-by-byte comparrison, and just sends the updated bytes over the wire. This has been a life saver for us.
As an added bonus, when using RSYNC server, go can tell it how much badwidth to use. For example during business hours we say "RSYNC, do your job, but don't use more than 60k per second of our T1".
Now that is smart computing. We get the benefits of using MS SQL, and the benefits of open source software to meet a challenge MS said could not be addressed.
Edited by - kapcreations on 03/14/2003 11:05:06 AM
March 16, 2003 at 11:33 am
My mistake. I reposted someone else comments. But I would like to state that SQL Replication will work over a T1. I have done it several times, with minor problem. Most of the time the problem wasn't with SQL replication but with either the firewall or router settings. Get your money back from the consultants you paid, because they surly did not know what they where doing..
Curtis M. Bragdon
MCSA W2K MCDBA 7.0/2000 MCP NT4/W2K SMS 1.2
A+ i-Net+ Server+ Network+ Certified
March 20, 2003 at 6:35 am
i think, if your load is very large you shoul be use log shipping another use replication
March 20, 2003 at 12:14 pm
It'll work over a 56K line as long as the connection is available at the time of replication.
quote:
But I would like to state that SQL Replication will work over a T1. I
John Zacharkan
John Zacharkan
March 21, 2003 at 5:20 am
I'm using a my own DIY, that is based on the Simple Log shipping found in the 2K resource kit.
I needed a warm standby, already had Std, not Ent version in place, and replication was way to complex when I took into consideration Identity columns, and what to do if the main server actually failed.
The resource kit version is a good place to start.
Andrew
What's the business problem you're trying to solve?
June 24, 2003 at 3:58 pm
If say you are backing up the transaction log and log shipping from the same database surely this will case a problem/conflict
June 24, 2003 at 4:08 pm
quote:
If say you are backing up the transaction log and log shipping from the same database surely this will case a problem/conflict
You can't perform log backups and log shipping at the same time, however you can back up the trasaction logs that log shipping dumps to the directory on either the production or the standby servers.
June 25, 2003 at 8:29 am
Yes you can make transaction log backups and do Log Shipping.
Log Shipping is what you do with all those transaction log backups. As long as the Log Shipped database receives and applies all transaction logs, Log Shipping works.
John Zacharkan
John Zacharkan
Viewing 15 posts - 31 through 45 (of 45 total)
You must be logged in to reply to this topic. Login to reply