IDS 7.31 FD3
Solaris 8


I know this statement is a bit vague, but if I have the choice to use Enterprise Replication or not, should I go for it ? IE. does 7.31 have serious issues with ER ? Is it difficult to maintain ?


** background **

I am asking this because we are completely redesigning our system, and would like to split up the business units into separate entities, sharing tables between each other. ER would be the best in terms of performance & downtime of individual business units, but what are the cons ?

I understand the theory behind ER, and what it is capable of.
I don't have practical experience with ER, and a couple of questions come to mind:

1. What happens if I loose integrity on a table ?
2. What happens if I disable ER for some reason ?
3. Is this efficient on a system that has many inserts (very busy) ?


Maybe you can give me some tips / suggestions .......




Dirk Moolman
Database and Unix Administrator
MXGROUP


"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
-Albert Einstein


sending to informix-list

Dirk

It depends .... !!
I'm using ER on 7.31 from Dynix/ptx to Solaris in a Primary Secondary
configuration. I've not used update anywhere. The most important thing to
consider is log space. You MUST have enough logical logs to hold 24 hours
(IBM recommendation, I suggest nearer 36 hours, or as long as it takes to
replace any downed kit) worth of transactions on each server. This will
enable you to take servers out of the loop for planned/unplanned downtime or
to enable you to disable ER. In these cases the servers will resync when you
start IDS up again or enable ER.
ER updates are extracted by log snooping so there is minimal additional
overhead on the sending server, however the updates need to be applied to
the receiver as normal inserts/amends so there will be additional processing
there, however this should be offset against the fact you are taking the
original transactions away from the target in the first place.
Are you going to use a Primary/Target configusration or update anywhere?
If, for any reason, you lose updates on a table you will need sql scripts to
identify these and update manually.

Come back offline with a bit more detail and I will see what else comes to
mind along with some monitoring tips.
Have you read the Informix ER Manual? It does rather concertrate on the
graphical setup tools but the first couple of chapters on the theory are
good and the syntax appendicies are essential.

Keith

-----Original Message-----
From: Dirk Moolman [mailtoirkM (AT) mxgroup (DOT) co.za]
Sent: Wednesday, September 17, 2003 12:03
To: informix-list (AT) iiug (DOT) org
Subject: ER ... yes / no ?



IDS 7.31 FD3
Solaris 8


I know this statement is a bit vague, but if I have the choice to use
Enterprise Replication or not, should I go for it ? IE. does 7.31 have
serious issues with ER ? Is it difficult to maintain ?


** background **

I am asking this because we are completely redesigning our system, and
would like to split up the business units into separate entities, sharing
tables between each other. ER would be the best in terms of performance &
downtime of individual business units, but what are the cons ?

I understand the theory behind ER, and what it is capable of.
I don't have practical experience with ER, and a couple of questions come to
mind:

1. What happens if I loose integrity on a table ?
2. What happens if I disable ER for some reason ?
3. Is this efficient on a system that has many inserts (very busy) ?


Maybe you can give me some tips / suggestions .......




Dirk Moolman
Database and Unix Administrator
MXGROUP


"Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former."
-Albert Einstein


sending to informix-list

************************************************** ********************************
This message is sent in strict confidence for the addressee only. It may
contain legally privileged information. The contents are not to be disclosed
to anyone other than the addressee. Unauthorised recipients are requested
to preserve this confidentiality and to advise the sender immediately of any
error in transmission.
This footnote also confirms that this email message has been swept for the
presence of computer viruses, however we cannot guarantee that this message
is free from such problems.
************************************************** ********************************
sending to informix-list

Dirk Moolman wrote:

This sounds like a very bad idea. ER in 9.30 is OK, especially good in 9.40
where you can mix in HDR, but unless your company is a f***ing huge
multinational, your probably going to be better off with a decent server
and everything in one database.

--
"C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule"
- Coluche

"Dirk Moolman" <DirkM (AT) mxgroup (DOT) co.za> wrote



getting
around some undocumented features. After we set ours up initially, we
ended up locking up the production database for 2 hours when we
exceeded some mis-configured thresholds. After the first 2 months, it
ran flawlessly.
You'd have to give me more info on 'sharing tables' Couldn't just
connect remotely and get the same result?

instance b, and pretty darn quick. Replication does not save you from
that. If the machine containing instance a goes offline, then b can
carry on for awhile depending on
how much log space you've allocated. We have 36-48 hours worth of
logs on each server. We've run 3 Disaster Recovery trials where the
primary server has been shut down for 24 hours and we've run off the
backup.

not, depending on how you "disable" it.

from primary to backup. YMMV, becuase your idea of busy may be
different than mine.

Upgrade to at least 9.3.