Message from discussion Log Shipping - database expansion
Received: by 10.68.213.68 with SMTP id nq4mr4728395pbc.2.1329425648428;
Thu, 16 Feb 2012 12:54:08 -0800 (PST)
From: Richard <rmcgor...@gmail.com>
Subject: Re: Log Shipping - database expansion
Date: Thu, 16 Feb 2012 12:37:34 -0800 (PST)
X-Trace: posting.google.com 1329425645 23699 127.0.0.1 (16 Feb 2012 20:54:05 GMT)
NNTP-Posting-Date: Thu, 16 Feb 2012 20:54:05 +0000 (UTC)
Injection-Info: t30g2000vbx.googlegroups.com; posting-host=184.108.40.206; posting-account=rAAl_QoAAABbVu3aa82N5FQGTTHV_6bl
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; GTB0.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR
3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8),gzip(gfe)
Content-Type: text/plain; charset=ISO-8859-1
On Feb 14, 11:00=A0pm, RJha <resheersh....@gmail.com> wrote:
> Another ways to maintain data consistency at DR sides.
> 1. You can use replication server =A0(able to maintain data copy at
> multiple sites)
Thanks for the reply.
We looked at Rep-Server. In fact, we trialed the product. We had
- cost (priced based on cores on box, not CPU's allocated to
lpar. An lpar
running with one CPU on hardware with eight cores would be
on the 8 cores, not the one CPU).
- it's a complex product. High level of understanding required,
something goes wrong. Seemed like overkill for the challenge we
trying to address.
- we break the transaction chain in a number of databases during
processing. Re-establishing syncronization after that was not a
process, that we felt would require non-trivial shell scripting
> 2. You can also do the data copy at SAN level using SAN technology
> like SRDF in EMC world.
Our sites are 400 miles apart. We were told network latency would
> 3. Automatic in-house build process similar to above discussions
> require extra DBA support and coding expertise in shell/perl/etc..
Can't argue with that. :-) Always good to become more competent
at something like shell scripting. :-)