Unavailable table(s) in high availability environment

[login to unmask email]

Unavailable table(s) in high availability environment
Hi,

What techniques do you use to allow an application to continue running in
a high-availability environment when one or more of the referenced tables
becomes unavailable, say for a DASD failure, stopped utility, etc.

Some alternatives that I see are:

- Package switching with SET CURRENT PACKAGESET. The challenges
here though are that every table referenced in the program must be switched
to a backup copy. A lot of duplicate tables if the program references common
tables.

- Let the program check for certain SQL codes and switch to read-only
tables while the problem is resolved. This may not be practical if the
application is a critical application and can't afford to be read-only.

- The above scenarios assume some sort of real-time replication to a
set of mirror tables using something like DPROP. The challenge is once the
mirrored set of tables are in-use, how do the 'real' tables get back in sync.

Thanks for any feedback.

Dave.



Venkatesh Mokshagundam

Re: Unavailable table(s) in high availability environment
(in response to DPetro@AOL.COM)
How about Data-Sharing?

Venkatesh Mokshagundam
Database Administrator
Corporate Systems,
Amarillo, TX 79102
Ph: 806-337-3374
Fax: 806-345-2736

-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Thursday, January 16, 2003 5:09 PM
To: [login to unmask email]
Subject: Unavailable table(s) in high availability environment


Hi,

What techniques do you use to allow an application to continue running
in
a high-availability environment when one or more of the referenced tables
becomes unavailable, say for a DASD failure, stopped utility, etc.

Some alternatives that I see are:

- Package switching with SET CURRENT PACKAGESET. The challenges
here though are that every table referenced in the program must be switched
to a backup copy. A lot of duplicate tables if the program references
common
tables.

- Let the program check for certain SQL codes and switch to
read-only
tables while the problem is resolved. This may not be practical if the
application is a critical application and can't afford to be read-only.

- The above scenarios assume some sort of real-time replication to a
set of mirror tables using something like DPROP. The challenge is once the
mirrored set of tables are in-use, how do the 'real' tables get back in
sync.

Thanks for any feedback.

Dave.








The information contained in this communication,
including attachments, is strictly confidential
and for the intended use of the addressee only;
it may also contain proprietary, price sensitive,
or legally privileged information. Notice is
hereby given that any disclosure, distribution,
dissemination, use, or copying of the information
by anyone other than the intended recipient is
strictly prohibited and may be illegal. If you
have received this communication in error, please
notify the sender immediately by reply e-mail, delete
this communication, and destroy all copies.


Corporate Systems, Inc. has taken reasonable precautions
to ensure that any attachment to this e-mail has been
swept for viruses. We specifically disclaim all liability
and will accept no responsibility for any damage sustained
as a result of software viruses and advise you to carry out
your own virus checks before opening any attachment.