Synchronous Database Copy
-
We are looking for a solution that allows us to keep a database synchronized copy of a sql database accross 2 SANS. Both copies need to be accessable (One will be read only). We can not use replication due to software restricitions. Any help or suggestions would be appreciated.
Mike
-
Does it need to be 100% synchronous (ie 2 phase commit?)
Unless you can work around the problems with replication (what are they by the way?) I think you're stuck with waiting for Database mirroring in SQL 2005 or looking at 3rd party tools (Im sure that double-take does this but don't know if it's 100% synchronus).
You can also look at hardware SAN - SAN solutions but they're going to cost you big time.
Actually, forget that, the fact that you want both databases available, even if one is read-only means that you're pretty much forced down the replication route.
Someone else may have a different take on this and if so i'd appreciate knowing what it is
-
like Mike says, it depends on your tolerance for differences between the two database....log shipping is free, but your backup database is out of sync by the xminutes you have between logs being switched out;
can you let us know your requirements? and what is the software issue preventing you from using replication?
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible! -
Thanks for the feedback so far. A two stage commit option is not required for this solution but we do need near real time. My software problems is that the vendor of the software holds very tight reigns on the system and the modifications that would be necessary to replicate the database would void our support agreement. Log shipping would be a good option but since the we need the receiving database to be online at all times it is not a valid option. We are open to all hardware and software solutions. SQL 2005 Database mirroring is the closest to being what we need but again the vendor requirements will not allow us to upgrade to 2005, and I have never liked being an early adopter of new software (give it at least till SP1). As a little background the source database is a full client end application that can have very limited downtime. This is currently a 130 GB db and expected to be 300 GB by the end of the year. The copy we want to create would preferably be an exact duplicate and used for ad hoc querry reporting of the data within the system.
Hope that helps.
Mike
-
We had a similar kind of situation with a database software package; the vendor does not want clients to alter the database schema, and the knee jerk reaction was replication alters the schema, so it was a no-no;
What the vendor was really trying to avoid is allowing end clients to add triggers and other database items;
I bet if you looked a bit deeper into your contract, or contacted the vendor, that replication would excluded from the schema changing limitation as far as application modifications;
I think of replication is part of a comprehensive backup strategy; If a software vendor told me i could not create a cluster,not replicate data, not run a backup or otherwise safeguard my data, I think they would add an unacceptable level of liability to their company.
just my two cents.
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply