Log Shipping vs. ASE Replicator vs. Replication Server
susanmills
We have recently looked into buying Replication Server, but
potentially have decided not to move forward.
We are looking into ASE Replicator or Log Shipping instead.
What are your thoughts about both strategies (database is
about 30 GB in size, can afford up to 2 hour down time,
etc.)?
We first got a quote for Replication Server and were under
the impression that since Replication Server only uses one
CPU, you only have to pay for a single CPU license. We just
learned today that since we have a 8 CPU server, we will
have to pay for a 8 CPU license. They gave us a price
breakdown like...
Replication Server License Costs:
1 CPU = $10,000
2 CPU = $20,000
3 CPU = $30,000
etc..
First we are shocked that the CPU costs jump up so
aggresively. Especailly since we have a 8 CPU box.
So with this in mind... Is Log Shipping or ASE Replicator a
realistic option for a Warm Standby solution?
michael...@gmail.com
I wouldn't use ASE replicator for anything like this. However, log
shipping is certainly feasible, especially if a 2 hour downtime is
acceptable.
The setup is pretty straightforward - you have to write some scripts,
but they should be pretty straightforward - and with a 30GB db it is
feasible to do a full resync fairly often if your IO subsystem is
reasonably fast.
Michael
Sherlock, Kevin
do you need an 8-cpu platform to run repserver?
A decent dual-core G3 running Linux RedHat/SUSE could do the job for you at
a greatly reduced price.
Replicator is probably out of the question as it can very quickly reach a
ceiling regarding throughput. Of course this all depends on how much
replication activity is required.
Log shipping can work, and I've seen others on these and other forums tout
it's capabilities. If you are not going down the replication server path,
this would probably be my choice.
<Susan Mills> wrote in message news:487b3b15.77c...@sybase.com...
susanmills
I just learned that the database size is only 1 GB. This
may even be more the reason to use Log Shipping instead of
buying a full license for Replication Server.
Thank you for all your help!
Eugene Korolkov
If everything is
then why Sybase does not provide adequate scripts (like Oracle and MS) and why Rep.Server is the huge product ? Unfortunately "devil is always in details" I think. Regards, Eugeneis pretty straightforward
Mark A. Parsons
Eugene Korolkov wrote:
> then why Sybase does not provide adequate scripts
> (like Oracle and MS)
What would you define as an 'adequate' script?
Over the years I've set up log shipping for at least a dozen different companies.
Each time the requirements were different enough to require a different set of scripts:
- dump to file system vs dump to tape
- dump locally vs dump remotely
- dump to a single stripe vs dump to multiple stripes (fixed # vs variable #)
- dump stripes to same directory vs dump stripes to different directories
- dump using compression vs dump without compression
- old compression method vs new compression method
- error handling requirements
- pre- and post- operational requirements
- regularly scheduled jobs vs threshold-initiated vs a mix of the two
- kick off from crontab vs kick from scheduler software
- automatically load into remote dataserver vs let another script handle the loading
- archiving/deletion rules for 'old' dump files
While the concept in all cases is the same, the implemenation is always a little varied.
----------------
If you wish to use ASE's job scheduler you could take a look at the templates provided for dumping databases and logs.
susanmills
Shipping vs. buying/using Replication Server?
Our RTO is 2 to 3 hours.
There are 12 databases (each 600 MB).
Total database space is 7.2 GB
> Susan M.
michael...@gmail.com
One of the main questions is the level of scripting competence
available. If you have people on staff (or contractors) that have a
good level of shell or perl or ... scripting skills, then building a
log shipping solution should be pretty straightforward - at a guess a
couple of weeks worth of work.
Otherwise you'd probably be better off with rep server, as you can
then turn to Sybase TS in case of problems and get things smoothed
out.
Michael
Michael Peppler
> Michael,
>
> If everything is
>
>>is pretty straightforward
>
>
>
> then why Sybase does not provide adequate scripts
> (like Oracle and MS) and why Rep.Server is the huge product ?
> Unfortunately "devil is always in details" I think.
Sure - but it also depends on what you are trying to achieve.
RepServer is a generic system that can solve a large number of problems,
in particular for multiple-site data availability in large organizations.
It could be considered overkill for a system where one "simply" wants to
be able to revert to a "recent" image of the data in case of a major
problem.
For the record I haven't implemented such a solution in a very long time
(the last time was around 1994 or so :-), but that doesn't mean that it
isn't a valid choice in some situations.
Michael
--
Michael Peppler - Peppler Consulting SaRL
mpep...@peppler.org - http://www.peppler.org
Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com
Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Mark A. Parsons
------------------
Depending on the complexity of your log shipping requirements ... a set of shell scripts can be
written/tested/implemented in a couple days (assuming some basic shell scripting knowledge).
Shell scripting will cost you the time it take to write the script.
If you dump-n-load with standby access then the remote database can be used for read-only access, though you'll need to
kick out users when you wish to load a database/tranaction-log dump file.
If you don't use dump-n-load with standby access then the remote database is not available to you for any sort of work
until you issue an 'online database' command. Once the database has been brought online you've typically broken the
dump-n-load cycle and will not be able to load any more log dump files, ie, you'll have to resync the remote database
beginning with a full database dump.
If you use log shipping you can do something like the following:
dump database, load database
dump log, load log
dump log, load log
dump database, don't bother loading database
dump log, load log
dump log, load log
You'll want to keep intermediate dumps for recovery purposes, but skipping the loading of intermediate db dumps will
save you some time on the remote system.
One downside to log shipping is that database corruption in the primary database will brought over and loaded into the
remote database; this is due to the replication/copying of data at the binary level.
Also, log shipping is an all-or-nothing operation. It's not very easy to dump-n-load *part* of a database or table.
Log shipping: easy to understandy; easy to implement; easy to maintain; cheap to implement; limited functionality other
than moving a binary copy of your data between dataserers
----------------------------
Replication server will cost you a good bit of resources (money, time, hardware) for product licensing, training, and
implementing scripts/tools for monitoring. If you plan to add/drop tables on a regular basis you're looking at the
addtional cost to manage said activities.
Replication server has a moderate learning curve that should not be taken lightly.
Replication server has a *LOT* of capabilities that may come in handy on down the road, eg, partial data replication,
distribution of data to different remote sites, rollup of data from different source databases, replication of data
between different RDBMSs, the ability (via function strings) to manipulate replicated data on the fly, and on and on and on.
Corruption in the primary database will not be propagated to the remote database because replication server passed the
data in transacational (ie, SQL text) form.
Replication server: relatively steep learning curve; more complicated to implement; more complicated to maintain;
expensive to implement; robust functionality
susanmills
Pros vs. Cons of Log Shipping and Replication Server was
extremely helpful. Thank you for doing this. These are all
very good points and all need to be thought through
thouroughly. We will use your advice and will take a
cautious approach.
Thank you! :)
Susan M.
Derek Asirvadem
Personally ? an adequate script is One pair (source/target) of
shell/SQL that does not break and can be used by/with/for ...
> - dump to file system vs dump to tape
> - dump locally vs dump remotely
> - dump to a single stripe vs dump to multiple stripes (fixed # vs variable #)
> - dump stripes to same directory vs dump stripes to different directories
> - dump using compression vs dump without compression
> - old compression method vs new compression method
> - error handling requirements
> - pre- and post- operational requirements
> - regularly scheduled jobs vs threshold-initiated vs a mix of the two
> - kick off from crontab vs kick from scheduler software
> - automatically load into remote dataserver vs let another script
> handle the loading
> - archiving/deletion rules for 'old' dump files
>
> While the concept in all cases is the same, the implemenation is always
> a little varied.
... and the variations are in set up, config, variables, pipes, tees,
of the One pair.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Quality Standards = Zero Maintenance + Zero Surprises
Performance Standards = Predictability + Scaleability
Derek Asirvadem
Most of the issue has been answered. I will address the remaining one ...
> Replication Server License Costs:
>
> 1 CPU = $10,000
> 2 CPU = $20,000
> 3 CPU = $30,000
> etc..
>
> First we are shocked that the CPU costs jump up so
> aggresively. Especailly since we have a 8 CPU box.
That's a misunderstanding or a poor sales explanation job. The
RepServer Agent is cold as a CPU licence; the no of CPU licences
required is whatever is on the sourced box, ie. 8 CPU ASE = 8 CPU
RepServer licence. It does not jump, it is not aggresive, it is just
$10k imes CPUs on your ASE box. Problem was the salesman should have
told you from the outset, not later. Just imagine what it is for cust
who have $50k times 16 CPUs.
Log Shipping is great, and has been around since 4.2. Somepeople put
it down as "luke warm standby", but that is only true since the advent
of RepServer. You do not have to write (test, debug, handle errors)
the scripts your self, we sell it, Unix Bourne shell only, there are
many other partners who do.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright Š 2008 Software Gems Pty Ltd