On Wed, 8 Jan 1997, Konrad Bauer wrote:

> I know there's no defined max size to the database, nevertheless, quite a few
> users are concerned when their database is several BG in size, and still
> growing. I know of several customers that have a DB of several GB without any
> performance degradation, still there's is a certain uneasiness.

In daily operation, we see no performance problems with the server that
runs lots of little nodes but we see big performance problems with the
other server whose biggest node is large.  As both servers have the same
order of magnitude of database size, the size of nodes and file spaces
seems to make a difference.

But one should not restrict one's attention to daily operation but should
also consider the time for disaster recovery. As you can see from the
recent thread "auditdb hung?" on this very list, it is a common experience
that the attempt to repair a corrupted database with auditdb will take
quite some time during which all data in ADSM is inaccessible - from a few
days up to many weeks.  Probably, the longer time occurs typically with
the larger databases. I consider such incidents the most serious threat to
the data stored in ADSM, and I can imagine scenarios where the
unavailability of a company's data for some weeks may cause considerable
damage.

Unfortunately, it is not known whether the time spent for the auditdb is
dependent on the number of db entries, of nodes, of file spaces, or on the
number of entries per node or per file space. It is also not known what
the reasons for the observed behaviour are, how the time spent in auditdb
depends on the above parameters and why. If all this were known, each
customer could try to adjust his ADSM configuration accordingly, in order
to minimise the expected recovery time. In October 1995, I wrote PMR 4795X
exactly to suggest the analysis of this problem, to no avail.

> Any experiences about AIX in particular? Has anyone split an ADSM because of
> the size of the database?

What does "splitting an ADSM" mean?  More file spaces, more nodes, more
servers, more machines that run servers?  For the first alternatives,
nobody can say whether it solves the problems, for the latter, you run
into new problems, such as sharing automated tape libraries between more
machines.

Best regards,

Helmut Richter

==============================================================
Dr. Helmut Richter                       Leibniz-Rechenzentrum
Tel:   +49-89-289-28785                  Barer Str. 21
Fax:   +49-89-2809460                    D-80333 Muenchen
Email: Helmut.Richter AT lrz-muenchen DOT de    Germany
==============================================================