Whether you plan using IDS mirroring or not it is recommended it is set. The Admin Ref advises not to if not used. Can make admin later in life easier

PHYSDBS

Separate dbspace on it’s own partition

ALARMPROGRAM use this as a mechanism to notify you of problems via email or pager

LOGSIZE & LOGFILES

Make sure that LOGSIZE * LOGFILES * (LTHWM / 100) is greater than your greatest possible combined open transaction load during peak update periods (allow for periodic bulk loads/updates/deletes, remember updates need 2x the log space). LOGSIZE is the maximum amount of data you can afford to do without if there is a catastrophic crash and you have to rebuild on a back up machine

On Solaris and HPUX this is a MUST! Solaris is aggressive and HPUX downright predatory about aging long running processes!

LRUS & CLEANERS

Set them the same for OLTP systems to minimize Chunk writes calculate based on estimated # concurrently active (not connected) user connections: #users / 4 or the max value (32bit-128, 64bit-256). IBM’s Dan Wood recommends just maxing LRUs out all the time – little cost - much benefit NUMAIOVPS – if no KAIO or COOKED chunks use 1* #chunks plus 2-4. With KAIO & all RAW chunks you’ll need 4-8, start with 6. Replaced by VPCLASS aio CHKPTINTVL – how many transactions can you afford to have to recreate? If the answer is none then apps MUST log their own transactions so they can be replayed unless all your transactions are instantaneous! Otherwise, this is the timeframe from which you can reasonably recover if everything that happened during that time was not committed and had to rollback.

how many transactions can you afford to have to recreate? If the answer is none then apps MUST log their own transactions so they can be replayed unless all your transactions are instantaneous! Otherwise, this is the timeframe from which you can reasonably recover if everything that happened during that time was not committed and had to rollback.