Received: by 10.68.213.68 with SMTP id nq4mr4728395pbc.2.1329425648428;
        Thu, 16 Feb 2012 12:54:08 -0800 (PST)
Path: wr5ni33098pbc.0!nntp.google.com!news1.google.com!postnews.google.com!t30g2000vbx.googlegroups.com!not-for-mail
From: Richard <rmcgor...@gmail.com>
Newsgroups: sybase.public.ase.administration
Subject: Re: Log Shipping - database expansion
Date: Thu, 16 Feb 2012 12:37:34 -0800 (PST)
Organization: http://groups.google.com
Lines: 40
Message-ID: <76bac9e5-b61c-4ffb-aa6f-e8df72c95ab7@t30g2000vbx.googlegroups.com>
References: <a7f9530e-a615-4011-818e-f12bf730a78e@l16g2000vbl.googlegroups.com>
 <13805800.30.1328574741644.JavaMail.geo-discussion-forums@prmu37>
 <06294e44-40a4-4148-96e1-67b7410f1ebe@m5g2000yqk.googlegroups.com>
 <8748552.170.1328663687916.JavaMail.geo-discussion-forums@pbcvo7>
 <4d6edf19-dbe8-4e41-b15b-b5a84a66ca72@l16g2000vbl.googlegroups.com> <44e1c21c-b01a-4983-b917-6b5c23aabc01@vd8g2000pbc.googlegroups.com>
NNTP-Posting-Host: 209.226.83.235
Mime-Version: 1.0
X-Trace: posting.google.com 1329425645 23699 127.0.0.1 (16 Feb 2012 20:54:05 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 16 Feb 2012 20:54:05 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: t30g2000vbx.googlegroups.com; posting-host=209.226.83.235; posting-account=rAAl_QoAAABbVu3aa82N5FQGTTHV_6bl
User-Agent: G2/1.0
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
Content-Transfer-Encoding: quoted-printable

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
three issues:
    - 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
priced based
      on the 8 cores, not the one CPU).
    - it's a complex product.  High level of understanding required,
particularly if
      something goes wrong.  Seemed like overkill for the challenge we
were
      trying to address.
    - we break the transaction chain in a number of databases during
our nightly
      processing.  Re-establishing syncronization after that was not a
simple
      process, that we felt would require non-trivial shell scripting
work


> 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
impact
app performance.

> 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. :-)