IGL 7.1.1 - can we host multiple DB instances on the same server?

[AndyCheek]

As everyone these days we are always looking for ways to (reasonably) keep costs down and our AWS RDS Oracle database servers are probably the most expensive part of the IGL infrastructure.

Is there, therefore, any way at all that we could host multiple DB instances on the same RDS server, obviously with different and distinct schema names? Has anyone done this or even considered it?

[MHelmy]

Nothing will stop from doing so, but I don't think it is a good idea. You will end up with multiple IGL instances all sharing the same database resources (SGA/PGA/CPUs/IO) which is always a bad idea. Imagine running a collector/review on your Dev/UAT environment affecting overall performance and resources on your production environment or vice versa? Also consider that you are probably running the same processes during the same timeframes of the day (collections are overnight for all environments) which again puts more load on all servers during the same timeframes.

From experience, I currently work with another customer that have different database instances all on the same physical Oracle server. They are currently suffering from what I just explained now. Even though SGA/PGA can be strictly separated between different instances, they still share CPUs/IO which can cause severe performance bottle necks.

[AndyCheek]

Thanks Mostafa. I get the concern over potential impact on production but we would never consider that approach for our live system - that would remain separate. The question was really about our test environments where a) the data set is much smaller (identities, access, etc.) and b) the end users are much fewer (only our developers & testers).

If this is technically feasible and we can replace two RDS servers that cost us x each with one larger one that costs less than 2x then we would almost certainly want to look at it.

Is there anything already documented that would detail the configuration changes we would need to make - or highlight the DB-specific variables that would be affected?

[MHelmy]

Got it, that would make a little more sense. There are mainly two things that would need to be created here to accommodate two applications to use the same database under different schemas:

1. A separate set of Oracle users for each environment (AVUSER/AVDWUSER/ACMDB).
2. A separate set of tablespaces for each environment (Listed in the database setup and management guide under "Create the Required Objects”).

Now that you will definitely not be using default names for the database accounts and tablespaces for each environment, you will also need to modify the Aveksa_System.cfg file reference the correct names. If I recall correctly, the install guide mentions the steps required per application server. Try search for something like "Changing Database Tablespace Names” or "Changing Database User Names”.

Since we are talking about test environments here, I would much rather you have your DBAs backup the databases > setup the new users/tablespaces > completely reinstall your test environments provided the correct names upfront from the installer > patch it up to the level they are > have the DBAs restore that backup into the new schemas. I believe that should be easier than trying to find every single place the old names are referenced in your existing installation and trying to update that.

[MHelmy]

I should also mention that what I said here is completely theoretical (or more like experimental). I don't see why this would not work, but you would never know until you actually try it out