The ISSUG Infobase contains archived postings from our on-line discussion forums. Nothing here may be quoted without the written permission of the author(s) of the original postings. The Infobase is organised into 12 sections concerning different topics.
FAQ content: Ram Malladi
Part 4: Encyclopedia (Host and CSE)
4.1)
CE Performance
4.2) When to have multiple
CSEs?
Gary Stockton
Dated : 14 April, 1997 at 14:07
Subject: CE Performance
We are curious to find out if anyone 'out there' has had cause to partition any of the CE tables, particularly the DASC and DOBJ tables. Our problem is in trying to find a suitable key, without doing anything to the structure of the table. We would preferably like a key that enables both tables to be partitioned efficiently (that, with DB2, must be an oxymoron!)
If you have
had any experience with this (good or bad), or any comments of a general
nature pertaining to CE performance and partitioning, please drop me a
line!
====
Darius Panahy
Dated : 14 April, 1997 at 15:49
Subject: Re: CE Performance
The key that we would like to have used is object id, but it used to be the case that some IEF programs directly updated the obj id and therefore this couldn't be used.
I don't know if this has been fixed in the later releases of Composer.
Regards
Darius Panahy
Information Engineering Technology Ltd
4.2) When to have multiple CSEs?
Chris Uttley
Dated : 05 May, 1997 at 14:00
Subject: Reasons for Multiple CSE's
Our shop is debating splitting our single ORACLE CSE into multiple CSEs.
I am wondering if anyone else has gone through this analysis.
We are a Component Based Development environment using COMPOSER 3.
Currently our only reason for considering a second CSE is the size of the current CSE. We are concerned about backup and recovery times.
1. At what
point is a single CSE no longer effective?
2. What are the advantages and disadvantages of multiple CSEs?
I would appreciate comments from others with experience or ideas in this area.
Chris Uttley
MCM Technology
========
Hurriyet
Gendj
Dated : 05 May, 1997 at 20:02
Subject: Re: Reasons for Multiple CSE's
It depends on the size of your current CSE server and the variance in
the working practices of different project teams using the CSE. For example
if you are experiencing CPU bottlenecks and it is not feasible to upgrade
your current server, then you might want to introduce another server,
offloading some tasks (ie. projects, models) to that server. Another example
is where you have multiple sites/projects wishing to perform backups at
different sites, have different object cache, md.ini (eg. maxinstance)
requirements. In this case it may be a good idea to allocate a separate
CSE for each site/project. As you would know, having multiple CSE's is
not like having multiple Host Ency's, ie. you can link CSE's, exchange
models between CSE's without losing ancestry (extract/apply).
Advantages:
- Independent development environment for each site/project team as I
mentioned above.
- Also it offers scalibility, ie. if you can not physically upgrade a
server, you can always add another node to your multiple CSE network.
Disadvantages:
- We tend to mention 'possible administrational overhead' as a disadvantage,
ie. 'one more CSE to look after/think about'. Some other examples could
be:
- Software (DBMS, OS) upgrades (this should not apply to Composer because
as long as you do not convert the models to the new schema, you can exchange
models between two CSE's at separate schema levels).
- Identifying ency administrators for each CSE. Having said this, this
should not be a problem if the initial planning is carefully done and
procedures are defined. We have customers who have successfully implemented
multiple CSE's. I am sure they will also respond to your query.
Please let me know should you require more information.
Best regards, Hurriyet
(European Technology Marketing Group)