I've just finished adding all the FAQ Updates I have and fixing
my email address everywhere (thanks June Hunt!).

http://smooth1.my-bulldog.com/pages/...q/informix.htm

Questions

1. Can someone review "How do I setup Enterprise Replication (ER)?"

http://smooth1.my-bulldog.com/pages/...aq08c.htm#8.82

2. Can someone review "How do I handle a long transaction?"

http://smooth1.my-bulldog.com/pages/...aq08c.htm#8.83

I've added an onarchive way to clear the logs but I'm not sure the
command is correct. NOTE: I've mentioned onarchive went in 9.30
but this may help someone so I left it in.

"you will need to catalog the new tape via the CATALOG option in
onarchive" I don't know what the command is for this!

3. Can someone review "How do I configure DD_HASHMAX and DD_HASHSIZE?"

http://smooth1.my-bulldog.com/pages/...aq06e.htm#6.61

I am not sure what algorithm is used for the hashing and the
script to calculate sizes a) might be wrong b) does not indicate
which values you should use from the output of the script!

4. Can someone review "Should I use striping".

a) Andrew Hamm takes a strong position!
b) Maybe Andrew wants to put in an updated version?

HELP!

For the most part the ER section looks fine. Some corrections....

Since 9.4, we can configure ER to use an ER only port, which can be
used to override the trusted server rule just a bit. Check the PAM
documentation for information on how to create an ER only port.

NOOOOO Do not put the shm interface with an ER group. The purpose of
a group is to identify the ports that can be considered equivalent
means of getting to the system. A shared memory interface is not
equivelant to a TCP interface because the TCP interface can be remote.

If you are going to combine ER with HDR, then the two servers need to
be part of the same group. This has an added advantage with v10
because if you put a pair of HDR servers under a single group and
INFORMIXSERVER is set to the group, then we ensure that you only
connect to the primary node.

For the most part the ER section looks fine. Some corrections....

Since 9.4, we can configure ER to use an ER only port, which can be
used to override the trusted server rule just a bit. Check the PAM
documentation for information on how to create an ER only port.

NOOOOO Do not put the shm interface with an ER group. The purpose of
a group is to identify the ports that can be considered equivalent
means of getting to the system. A shared memory interface is not
equivelant to a TCP interface because the TCP interface can be remote.

If you are going to combine ER with HDR, then the two servers need to
be part of the same group. This has an added advantage with v10
because if you put a pair of HDR servers under a single group and
INFORMIXSERVER is set to the group, then we ensure that you only
connect to the primary node.

David,
I'm qute willing to help with "What exactly is a long transaction" but
it needs a complete rewrite. It currently recommends using "onarchive"
and I'm not sure if that is still distributed. I don't even know if
informix would recommend clearing a long transaction in that way. It
also doesn't take any account of newer advances with dynamic allocation
of logs etc.

As to your comments on LTXHWM/LTXEHWM there is no reason that I know of
to set theses to anything lower than 50/60. As I understand it the
setting of 60 for EHWM allows for one rollback record for each pair of
insert/update records.

I would also disagree strongly on the sizing of logical logs.
Practical experience has shown that restores using onbar with certain
backup storage managers is better with a few large logs. It seems the
time taken to search tapes for each log can be prohibitive. That said
it is also significant not to make logs to big from the aspect of
restore point granularity, especially when using ONTAPE(no PIT
restore).
Generally I suspect we could write a complete Informix handbook on the
configuration of logs etc for the wide variety of potential disaster
recovery scenarios. And now we have Table level PIT restore. And that
changes lots of things.

regards

Malcolm

mweallans@panacea.co.uk wrote:
> David,
> I'm qute willing to help with "What exactly is a long transaction" but
> it needs a complete rewrite. It currently recommends using "onarchive"
> and I'm not sure if that is still distributed. I don't even know if
> informix would recommend clearing a long transaction in that way. It
> also doesn't take any account of newer advances with dynamic allocation
> of logs etc.

I agree. I am not sure I would follow any of the advice in this section
of the FAQ although it's probably not all bad. If a transaction has
become "long" it has essentially failed but it has left the database
engine in a state where no-one else can perform any transactions since
the next logical log is not available. My solution would be to add
another logical log somewhere to the system, preferably in the chunk
containing my other logical logs (I would leave space for this
eventuality) and roll back the long transaction. Of course there is
dynamic allocation of logs now as you say so this may not even be
required on newer systems.

If you absolutely have to run the transaction and can't rewrite it then
you either need more logical logs or you need to perform the transaction
with logging turned off. This last option brings up a whole host of
other issues with backups, rolling back, inability to use transactions
at all, HDR etc.

Ben.