SQL Anywhere database replication

Author

Server sizing?

TPS

2006-02-25, 9:41 am

If I am setting up a replication system that will replicate to several 1000
users what requirements should I have for the server that houses the
consolidated database?

We will use version : Sybase Adaptive Server Anywhere Database Engine
Version 8.0.2.4XXX

The messages will be sent out from this server via file protocal.

I was thinking a moderate single use server with maximum memory. (4 gig)

How important is the CPU??
Are fast disk drives relevent??

Thanks
TPS

Joshua Savill

2006-02-25, 9:41 am

If this is a new replicating environment, I recommend using a supported
version of SQL Anywhere. Currently our lowest supported version is ASA
8.0.3, but I would recommend looking at ASA 9.0.2 as a starting point.

The CPU and disk drives are dependent on the demand from your application.
It is also dependent on the number of users, the number of database
transactions, intensity of queries.

--
Joshua Savill
iAnywhere Solutions - Product Support Analyst

"TPS" <ts@scientexlc.com> wrote in message news:43fba728$1@foru
ms-2-dub...
> If I am setting up a replication system that will replicate to several
> 1000 users what requirements should I have for the server that houses the
> consolidated database?
>
> We will use version : Sybase Adaptive Server Anywhere Database Engine
> Version 8.0.2.4XXX
>
> The messages will be sent out from this server via file protocal.
>
> I was thinking a moderate single use server with maximum memory. (4 gig)
>
> How important is the CPU??
> Are fast disk drives relevent??
>
> Thanks
> TPS
>

TPS

2006-02-25, 9:41 am

The reason we do not use version 8.0.3 is due to a very large power++
application that we have. The datawindow control used by power++ does not
support version 8.0.3. Until I have the time to port this application to
datawindow.net (12 month task) I am stuck using 8.0.2.

Version 9.0.2 will not happen due to the cost of upgrades. It is not
feasable to upgrade 1500+ licences every major release. My guess we will
have a 50/50 shot on upgrading to version 10.X.X.

The server that the consolidated database will have no applications except
the sybase database server running on it. This is soley used to direct data
to the production users (remotes). The application that uses the database
will not connect to the server that will distibute the messages.

Thus my guesses for server requirements are:

Memory - Very important to be able to efficiently process many messages.
CPU - Important to process the incoming transactions.
Disk speed - Not important since most of the messages will be processed to
and from a FTP server residing on a different machine.

Does this seem reasonable??

Thanks
TPS

"Joshua Savill" < nospam_jsavill@ianyw
here.com> wrote in message
news:43fcd052$1@foru
ms-1-dub...
> If this is a new replicating environment, I recommend using a supported
> version of SQL Anywhere. Currently our lowest supported version is ASA
> 8.0.3, but I would recommend looking at ASA 9.0.2 as a starting point.
>
> The CPU and disk drives are dependent on the demand from your application.
> It is also dependent on the number of users, the number of database
> transactions, intensity of queries.
>
> --
> Joshua Savill
> iAnywhere Solutions - Product Support Analyst
>
> "TPS" <ts@scientexlc.com> wrote in message news:43fba728$1@foru
ms-2-dub...
>
>

Reg Domaratzki $iAnywhere Solutions$

2006-02-25, 9:41 am

As always, your mileage may vary, and the best way to answer this question
is to run some tests with YOUR data.

I would have put Disk Speed as more important than CPU. When messages are
being applied to the database during replication the database and
transaction log are going to be hammered. If you're applying messages with
multiple threads at the consolidated, you could be maxing out disk speed
before CPU, particularly since it's very basic SQL (insert, update, delete)
being applied to the database while messages are being applied, so the
engine isn't eating up CPU trying to figure out the best way to execute the
SQL.

An important thing not mentioned is the physical setup of the consolidated
database. In a perfect world, you would have your database file,
transaction log, mirror transaction log (please tell me your going to have a
mirror transaction log for your consolidated database) and the TEMP
directory that ASA uses all on different physical hard drives. Writing to
the database file and the transaction log(s) happens at the same time a lot,
so having those spread out over different hard drivers allows each set of
hard drives to work on a single request, instead of a single hard drive
working on a few requests. The paranoid amongst the group will also put the
drives hosting the db and transaction logs on different disk controllers, so
that a bad disk controller won't chew up all three drives at the same time.
The ultra paranoid amongst the group will have those disk controllers be
from different manufacturers, so a bug in the disk controller won't eat up
all three drives. I always like to start my planning by being
ultra-paranoid, figuring out that the cost is astronomical, and then
stepping back to a point where the cost/paranoia ratio is reasonable.

You should also be thinking about your backup and recovery strategy at the
time of system purchase. Do you want to back up to another hard drive on
the same machine, or will you be running the backups from another machine
across the network? Your backups should certainly be going to a different
hard drive than where the db or logs reside.

--
Reg Domaratzki, Sybase iAnywhere Solutions
Sybase Certified Professional - Sybase ASA Developer Version 8
Please reply only to the newsgroup

iAnywhere Developer Community : http://www.ianywhere.com/developer
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
ASA Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere Studio
-> Set filter to "Display ALL platforms IN ALL MONTHS"

"TPS" <ts@scientexlc.com> wrote in message news:43fcd390@forums
-2-dub...
> The reason we do not use version 8.0.3 is due to a very large power++
> application that we have. The datawindow control used by power++ does not
> support version 8.0.3. Until I have the time to port this application to
> datawindow.net (12 month task) I am stuck using 8.0.2.
>
> Version 9.0.2 will not happen due to the cost of upgrades. It is not
> feasable to upgrade 1500+ licences every major release. My guess we will
> have a 50/50 shot on upgrading to version 10.X.X.
>
> The server that the consolidated database will have no applications except
> the sybase database server running on it. This is soley used to direct
data
> to the production users (remotes). The application that uses the database
> will not connect to the server that will distibute the messages.
>
> Thus my guesses for server requirements are:
>
> Memory - Very important to be able to efficiently process many messages.
> CPU - Important to process the incoming transactions.
> Disk speed - Not important since most of the messages will be processed to
> and from a FTP server residing on a different machine.
>
> Does this seem reasonable??
>
> Thanks
> TPS
>
>
> "Joshua Savill" < nospam_jsavill@ianyw
here.com> wrote in message
> news:43fcd052$1@foru
ms-1-dub...
application.[color=darkred]
news:43fba728$1@foru
ms-2-dub...[color=darkred]
the[color=darkred]
gig)[color=darkred]
>
>

Volker Barth

2006-02-28, 8:26 pm

Hi Reg,

just a "remote hook" with one question:

Our production database servers run ASA 8 and 9 on Windows
2003 Server. We generally use RAID-1 devices (each harddisk
with its own disk controller) so that the database file and
log file are mirrored. So far, we do not use a mirrored log.
Backups are of course stored on separate systems (and
tapes).

Comparing a mirrored device to a mirrored log, are there any
advantages/disadvantages in data safety?

TIA

Volker

Reg Domaratzki wrote:
....
> An important thing not mentioned is the physical setup of
> the consolidated database. In a perfect world, you would
> have your database file, transaction log, mirror
> transaction log (please tell me your going to have a
> mirror transaction log for your consolidated database) and
> the TEMP directory that ASA uses all on different physical
> hard drives.
....

Reg Domaratzki $iAnywhere Solutions$

2006-02-28, 8:26 pm

As long as a failure on a single hard drive cannot wipe out your current
transaction log, you're fairly well protected. Using a mirror transaction
log means that the database engine is managing the writes to two separate
files, where as using hardware mirroring is leaving the hardware in charge
of writing both copies. As long as the hardware does not tell the OS that
the write is done before both writes are complete, you should be fine.

--
Reg Domaratzki, Sybase iAnywhere Solutions
Sybase Certified Professional - Sybase ASA Developer Version 8
Please reply only to the newsgroup

iAnywhere Developer Community : http://www.ianywhere.com/developer
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
ASA Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere Studio
-> Set filter to "Display ALL platforms IN ALL MONTHS"

<Volker Barth> wrote in message news:440415d4.669b.1681692777@sybase.com...
> Hi Reg,
>
> just a "remote hook" with one question:
>
> Our production database servers run ASA 8 and 9 on Windows
> 2003 Server. We generally use RAID-1 devices (each harddisk
> with its own disk controller) so that the database file and
> log file are mirrored. So far, we do not use a mirrored log.
> Backups are of course stored on separate systems (and
> tapes).
>
> Comparing a mirrored device to a mirrored log, are there any
> advantages/disadvantages in data safety?
>
> TIA
>
> Volker
>
>
> Reg Domaratzki wrote:
> ...
> ...

Sponsored Links