Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Disaster Recovery - General Advice

3 posts in Replication Last posting was on 2010-06-22 08:16:24.0Z
Tim Murfitt Posted on 2010-06-21 10:46:29.0Z
Reply-To: "Tim Murfitt" <tim@tmurfitt.co.uk>
From: "Tim Murfitt" <tim@tmurfitt.co.uk>
Newsgroups: Advantage.Replication
Subject: Disaster Recovery - General Advice
Date: Mon, 21 Jun 2010 11:46:29 +0100
Lines: 61
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
NNTP-Posting-Host: 82.70.207.190
Message-ID: <4c1f4263@solutions.advantagedatabase.com>
X-Trace: 21 Jun 2010 04:43:47 -0700, 82.70.207.190
Path: solutions.advantagedatabase.com!82.70.207.190
Xref: solutions.advantagedatabase.com Advantage.Replication:392
Article PK: 1134245

Hi

I am a fairly experienced developer with Advantage but have not used
Replication before and am looking for some advice.

I am looking to develop a bespoke application for a company controlling 500
security guards at approximately 200 customer sites on a 24/7 basis 365 days
the year. The applications primary role is to monitor regular welfare
checks from the guards (they have to ring in every hour during the night) .
The company has two control centres split roughly 50/50 that are managed
independently but need to be able to cover each other if either site goes
down (for whatever reason). Although managed on a day to day basis
independently there is an overall group reporting requirement. This
reporting requirement is desireable but not critical. All data is unique
(or can be designed to be unique) across both control centres so it is
possible to run as one or two databases. The data would contain an index
field containing the Centre No so it can be readily filtered. There are
roughly 5 users on each site but during the night there are only two at each
site. The automated phone call logging systems (integrated with database)
have to take upto 200 calls on the hour (within a 20 minute window). The
phone call logging system rather than the database is the biggest capacity
constraint and the most likely point of failure. The data will be regularly
backed up using the adsbackup utility.

As i see it i have two options (both using two way replication).

Option A. Two databases (10 users each) and two phone call loggers with
each site replicating its data to the other. In the event of a disaster the
calls would be diverted and the application would handle both sites. Two
way recovery would ensure that the disaster site would catch up with all
updates once it comes back on line.

Option B: One database (15 users) containing all data stored at Site A with
Site B users connected to A via terminal services. The database would be
replicated to Site B (5 user licence). All calls would be logged via Site
A. In the event of a disaster calls would be diverted to Site B and the
back up call logger and the database application would be run from there.
When Site A recovers the data would be replicated back to Site A.


I am thinking that Option A is the preferred one not least because it give
mes more flexibility with problematic call loggers and I dont as a general
rule have to Terminal Service across sites. Does anyone have any experience
or opinions they can share?



One additional question. Assuming everything is running correctly am I
correct in assumming that an update made at Site A is pretty much
instanteously replicated to Site B.



Thanks in advance


Tim Murfitt


Mark Wilkins Posted on 2010-06-21 22:40:41.0Z
From: "Mark Wilkins" <mark@no.email>
Newsgroups: Advantage.Replication
References: <4c1f4263@solutions.advantagedatabase.com>
Subject: Re: Disaster Recovery - General Advice
Date: Mon, 21 Jun 2010 16:40:41 -0600
Lines: 74
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
NNTP-Posting-Host: 10.24.38.228
Message-ID: <4c1fe9c3@solutions.advantagedatabase.com>
X-Trace: 21 Jun 2010 16:37:55 -0700, 10.24.38.228
Path: solutions.advantagedatabase.com!10.24.38.228
Xref: solutions.advantagedatabase.com Advantage.Replication:393
Article PK: 1134246


"Tim Murfitt" <tim@tmurfitt.co.uk> wrote in message
news:4c1f4263@solutions.advantagedatabase.com...
>
> As i see it i have two options (both using two way replication).
>
> Option A. Two databases (10 users each) and two phone call loggers with
> each site replicating its data to the other. In the event of a disaster
> the calls would be diverted and the application would handle both sites.
> Two way recovery would ensure that the disaster site would catch up with
> all updates once it comes back on line.
>
> Option B: One database (15 users) containing all data stored at Site A
> with Site B users connected to A via terminal services. The database
> would be replicated to Site B (5 user licence). All calls would be logged
> via Site A. In the event of a disaster calls would be diverted to Site B
> and the back up call logger and the database application would be run from
> there. When Site A recovers the data would be replicated back to Site A.
>
>
> I am thinking that Option A is the preferred one not least because it give
> mes more flexibility with problematic call loggers and I dont as a general
> rule have to Terminal Service across sites. Does anyone have any
> experience or opinions they can share?
>

This is a good question ... I like one solution better and then I like the
other better after thinking more. Back and forth.

In general, though, Option A "feels" like the better solution. It may
provide better performance in general for the users since they would
typically be accessing a server that is physically closer to the workstation
(without using terminal services). And one (I think) significant benefit is
that if the network connection is lost between the two sites, they can both
keep operating without problems. The replication data would just stay in the
queue until connectivity was restored. Option B would be a problem if
connectivity was lost between the two sites ... although I suppose site B
could then simply be routed to use database B in that situation.

Option B has a simplicity factor that is conceptually appealing. If I
understand correctly, the data really would only be replicating in one
direction at any one time. Two replication would be set up, but since the
users would only be connected to one site at a time, that site would always
be the one with the known valid data. On the other hand, it sounds like
replication conflicts won't be a problem. If I understand correctly, each
site's data is completely independent. If true, then conflicts should not be
an issue.

>
>
> One additional question. Assuming everything is running correctly am I
> correct in assumming that an update made at Site A is pretty much
> instanteously replicated to Site B.

The data is replicated asynchronously, so there can be a lag. It depends on
how busy the server is and how fast the connection is from one server to the
other. When a record is updated, it is put into the replication queue and
another thread is scheduled to handle the replication. If you set up
replication on a local network and make updates, the replication will "seem"
instantaneous from a user interface standpoint. In other words, if you
update a record in ARC, and then go click on the refresh button in another
instance of ARC that accesses the destination data, it will almost certainly
refresh with the replicated data immediately.

But it is certainly possible for the source data to build up faster than it
can be replicated. If you have N connections updating data at the source as
fast as is possible on a local network, the replication queue will probably
grow in size because the data being replicated out will be going (in
general) through a single connection.

Mark Wilkins
Advantage R&D


Tim Murfitt Posted on 2010-06-22 08:16:24.0Z
Reply-To: "Tim Murfitt" <tim@tmurfitt.co.uk>
From: "Tim Murfitt" <tim@tmurfitt.co.uk>
Newsgroups: Advantage.Replication
References: <4c1f4263@solutions.advantagedatabase.com> <4c1fe9c3@solutions.advantagedatabase.com>
Subject: Re: Disaster Recovery - General Advice
Date: Tue, 22 Jun 2010 09:16:24 +0100
Lines: 101
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
NNTP-Posting-Host: 82.70.207.190
Message-ID: <4c2070b6@solutions.advantagedatabase.com>
X-Trace: 22 Jun 2010 02:13:42 -0700, 82.70.207.190
Path: solutions.advantagedatabase.com!82.70.207.190
Xref: solutions.advantagedatabase.com Advantage.Replication:394
Article PK: 1134247

Mark

Thank you for your response. Before I started writting the post my
inclination was to go with Option B but as I wrote it I moved to the A
option. It would appear that both should work. For me I think the deciding
factor is that with Option A I can spread the call logger burdern over two
sites. The big factor in my favour is that the data is (or can readily be
designed to be) unique across both sites and I should get minimal
replication conflicts.

Whilst there are some administrative functions which might cause an
occassional short burst of activity on the whole there are not a lot of
updates to replicate. Typically each site would have 300 updates every hour
in a 20 minute window. The broadband connection between the two sites is
reasonable so I am therefore not expecting a large replication queue to
build up.

REgards

Tim

"Mark Wilkins" <mark@no.email> wrote in message
news:4c1fe9c3@solutions.advantagedatabase.com...
>
> "Tim Murfitt" <tim@tmurfitt.co.uk> wrote in message
> news:4c1f4263@solutions.advantagedatabase.com...
>>
>> As i see it i have two options (both using two way replication).
>>
>> Option A. Two databases (10 users each) and two phone call loggers with
>> each site replicating its data to the other. In the event of a disaster
>> the calls would be diverted and the application would handle both sites.
>> Two way recovery would ensure that the disaster site would catch up with
>> all updates once it comes back on line.
>>
>> Option B: One database (15 users) containing all data stored at Site A
>> with Site B users connected to A via terminal services. The database
>> would be replicated to Site B (5 user licence). All calls would be
>> logged via Site A. In the event of a disaster calls would be diverted to
>> Site B and the back up call logger and the database application would be
>> run from there. When Site A recovers the data would be replicated back to
>> Site A.
>>
>>
>> I am thinking that Option A is the preferred one not least because it
>> give mes more flexibility with problematic call loggers and I dont as a
>> general rule have to Terminal Service across sites. Does anyone have any
>> experience or opinions they can share?
>>
>
> This is a good question ... I like one solution better and then I like the
> other better after thinking more. Back and forth.
>
> In general, though, Option A "feels" like the better solution. It may
> provide better performance in general for the users since they would
> typically be accessing a server that is physically closer to the
> workstation (without using terminal services). And one (I think)
> significant benefit is that if the network connection is lost between the
> two sites, they can both keep operating without problems. The replication
> data would just stay in the queue until connectivity was restored. Option
> B would be a problem if connectivity was lost between the two sites ...
> although I suppose site B could then simply be routed to use database B in
> that situation.
>
> Option B has a simplicity factor that is conceptually appealing. If I
> understand correctly, the data really would only be replicating in one
> direction at any one time. Two replication would be set up, but since the
> users would only be connected to one site at a time, that site would
> always be the one with the known valid data. On the other hand, it sounds
> like replication conflicts won't be a problem. If I understand correctly,
> each site's data is completely independent. If true, then conflicts should
> not be an issue.
>
>>
>>
>> One additional question. Assuming everything is running correctly am I
>> correct in assumming that an update made at Site A is pretty much
>> instanteously replicated to Site B.
>
> The data is replicated asynchronously, so there can be a lag. It depends
> on how busy the server is and how fast the connection is from one server
> to the other. When a record is updated, it is put into the replication
> queue and another thread is scheduled to handle the replication. If you
> set up replication on a local network and make updates, the replication
> will "seem" instantaneous from a user interface standpoint. In other
> words, if you update a record in ARC, and then go click on the refresh
> button in another instance of ARC that accesses the destination data, it
> will almost certainly refresh with the replicated data immediately.
>
> But it is certainly possible for the source data to build up faster than
> it can be replicated. If you have N connections updating data at the
> source as fast as is possible on a local network, the replication queue
> will probably grow in size because the data being replicated out will be
> going (in general) through a single connection.
>
> Mark Wilkins
> Advantage R&D
>