Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Log Shipping - database expansion

Received: by 10.204.153.5 with SMTP id i5mr40218bkw.1.1330056235200;
        Thu, 23 Feb 2012 20:03:55 -0800 (PST)
Path: t13ni63240bkb.0!nntp.google.com!news2.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
From: Antony <albion26....@gmail.com>
Newsgroups: sybase.public.ase.administration
Subject: Re: Log Shipping - database expansion
Date: Thu, 23 Feb 2012 20:03:54 -0800 (PST)
Organization: http://groups.google.com
Lines: 44
Message-ID: <759075.356.1330056234319.JavaMail.geo-discussion-forums@pbgq3>
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> <76bac9e5-b61c-4ffb-aa6f-e8df72c95ab7@t30g2000vbx.googlegroups.com>
NNTP-Posting-Host: 210.48.49.225
Mime-Version: 1.0
X-Trace: posting.google.com 1330056234 14042 127.0.0.1 (24 Feb 2012 04:03:54 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 24 Feb 2012 04:03:54 +0000 (UTC)
In-Reply-To: <76bac9e5-b61c-4ffb-aa6f-e8df72c95ab7@t30g2000vbx.googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=210.48.49.225;
 posting-account=NnXtTwoAAAABgWhO-BeH3pCDvor0eHtW
User-Agent: G2/1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, 17 February 2012 09:37:34 UTC+13, Richard  wrote:
> On Feb 14, 11:00=A0pm, RJha <resheersh....@gmail.com> wrote:
> Thanks for the reply.
>=20
> 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).

As of RS 15.5 Sybase now support sub-capacity licensing - so a 1 core VM on=
 an  8 core host will only cost 1 core license. Logical partitions are also=
 supported I think (e.g. Solaris containers).

>     - it's a complex product.  High level of understanding required,
> particularly if something goes wrong.  Seemed like overkill for the chall=
enge we were trying to address.

Warm standby setup is very simple. It's as complex as you want to make it r=
eally - though you do need to get used to the product, it's nothing like AS=
E :)

>     - we break the transaction chain in a number of databases during
> our nightly processing.  Re-establishing syncronization after that was no=
t a
> simple process, that we felt would require non-trivial shell scripting wo=
rk

Do you know why this happens? Not everything is 100% compatible with replic=
ation (whether viw RepServer or other), but most things should work. If it'=
s just Warm Standby you're using, you can sync with dump/load right? Not th=
at hard, but it is time consuming if the db is large.
>=20
> > 2. You can also do the data copy at SAN level using SAN technology
> > like SRDF in EMC world.
>=20
> Our sites are 400 miles apart.  We were told network latency would
> impact app performance.
>=20

Indeed. You would need to use SRDF/S (synchronous) which hammers your IO th=
roughput. Sybase do not support SRDF/A (asynchronous) as the database may b=
e corrupted if the disk pairs are not in sync when split.