db2 instances

[Frank Swarbrick]

Given the following situation, I am wondering what advantages and
disadvantages there would be for creating more than one instance.

For testing, we want to have more than one 'version' of a database.
Probably there will be only a single database [structure, that is], although
there could be more. Let's call this database CORE. We'll could have a
single instance with, say, CORE_DEV1, CORE_DEV2, CORE_DEV3, etc. (We'd also
have a separate production instance, on a separate machine, and just call
the database CORE. Or maybe CORE_PROD.)

Anyway, for DEV the other alternative would be to have several instances,
each instance owning one of the DEV databases. EG:
DB2INST1 with CORE_DEV1
DB2INST2 with CORE_DEV2
DB2INST3 with CORE_DEV3

And of course in this case we wouldn't need to have a suffix for each
database. We could just call it CORE on each separate instance.

Of course clients connecting to the databases in the second case would have
to have aliases, such as, well, CORE_DEV1, CORE_DEV2, CORE_DEV3, etc. :-)

When creating the dev databases (and there will probably be more than 3)
will it be easier to 'clone' another one if it has the same instance but a
different name or a different instance but the same name? Or neither? Does
having multiple instances make administrative tasks easier or more
difficult? Or neither? Anything else I should take in to consideration?

I am not the DBA, but the DBA is new to DB2 so I'd like to have some experts
weigh in on the matter.

Thanks!

Frank

[Larry]

I'm not sure I follow what you're proposing, but there are other things
you should consider in deciding whether to have one database per
instance or more than one database per instance.

One is availability and the availability requirements of your
application. If an instance crashes or needs to be recycled
intentionally, all databases in that instance will be affected.

Another is resources (like memory and memory heaps) and control over
resources. There are some parameters that are controllable at the
database level and others that are controllable at the instance level. A
good source of to understand these would be the DB2 Admin Guide:
Performance.

Larry E.

Frank Swarbrick wrote:

Given the following situation, I am wondering what advantages and
disadvantages there would be for creating more than one instance.

For testing, we want to have more than one 'version' of a database.
Probably there will be only a single database [structure, that is], although
there could be more. Let's call this database CORE. We'll could have a
single instance with, say, CORE_DEV1, CORE_DEV2, CORE_DEV3, etc. (We'd also
have a separate production instance, on a separate machine, and just call
the database CORE. Or maybe CORE_PROD.)

Anyway, for DEV the other alternative would be to have several instances,
each instance owning one of the DEV databases. EG:
DB2INST1 with CORE_DEV1
DB2INST2 with CORE_DEV2
DB2INST3 with CORE_DEV3

And of course in this case we wouldn't need to have a suffix for each
database. We could just call it CORE on each separate instance.

Of course clients connecting to the databases in the second case would have
to have aliases, such as, well, CORE_DEV1, CORE_DEV2, CORE_DEV3, etc. :-)

When creating the dev databases (and there will probably be more than 3)
will it be easier to 'clone' another one if it has the same instance but a
different name or a different instance but the same name? Or neither? Does
having multiple instances make administrative tasks easier or more
difficult? Or neither? Anything else I should take in to consideration?

I am not the DBA, but the DBA is new to DB2 so I'd like to have some experts
weigh in on the matter.

Thanks!

Frank

[Mark A]

"Frank Swarbrick" <Fr*************@efirstbank.comwrote in message
news:47******************@efirstbank.com...

Given the following situation, I am wondering what advantages and
disadvantages there would be for creating more than one instance.

For testing, we want to have more than one 'version' of a database.
Probably there will be only a single database [structure, that is],
although
there could be more. Let's call this database CORE. We'll could have a
single instance with, say, CORE_DEV1, CORE_DEV2, CORE_DEV3, etc. (We'd
also
have a separate production instance, on a separate machine, and just call
the database CORE. Or maybe CORE_PROD.)

Anyway, for DEV the other alternative would be to have several instances,
each instance owning one of the DEV databases. EG:
DB2INST1 with CORE_DEV1
DB2INST2 with CORE_DEV2
DB2INST3 with CORE_DEV3

And of course in this case we wouldn't need to have a suffix for each
database. We could just call it CORE on each separate instance.

Of course clients connecting to the databases in the second case would
have
to have aliases, such as, well, CORE_DEV1, CORE_DEV2, CORE_DEV3, etc. :-)

When creating the dev databases (and there will probably be more than 3)
will it be easier to 'clone' another one if it has the same instance but a
different name or a different instance but the same name? Or neither?
Does
having multiple instances make administrative tasks easier or more
difficult? Or neither? Anything else I should take in to consideration?

I am not the DBA, but the DBA is new to DB2 so I'd like to have some
experts
weigh in on the matter.

Thanks!

Frank

If it is not development, I would just have one instance with multiple
databases. If the applications are using the type 4 universal driver, there
will not be alias'. Each connection string will point to a different
database name. If the databases are really the same, but just different
versions/environments, then keep the schema names the same.

If you had a performance test environment where you wanted to exactly mimic
production, then you might want just one database in the instance if that is
how it is in production.