I need to create UAT and production environment. The client has only one hp-ux B.11.31 ia64 server with 8GB memory and storage is SAN.
My ideas are:
1. To have two database, one for production and one for UAT.
2. Two schema's in a single database one schema for production and one shcema for UAT. Schemas contain Database objects needed to run the application.
Please suggest me a better solution among the above or any other solution which won't hamper performance and other issues in the future.
Please suggest me a plan to support UAT and Production environments in the same sever.
If it were me, I'd have separate databases, even if that means running two separate databases on one server. The risks and complexities of having them both in the same database are simply too great for my comfort level.
I find it hard to believe that after spending the money for an HP server and SAN, they can only afford 8gb of memory. I've got that much in my laptop ...
The only solution that does not "hamper performance" is to put UAT on its own server.
(11g and earlier) If stuck with a single server, I would build separate instances. Testing in UAT includes testing the scripts that deploy changes to production. You can't do that very easily if schemas are named differently.
The multitenant feature of Oracle Database 12c changes my answer above: As I understand the feature, you can have multiple Pluggable Databases that contain the same schemas, and the Resource Manager can manage workload to prevent the UAT PDB from taking all the resources from the production PDB. However, if you can't make the case for a second server for UAT then you might not be able to make the case for extra-cost options like multitenant, either?
Memory is 16GB . Its was mistakenly written 8GB in my question.
Can i go for two databases if have more memory as 16GB?
You probably could do it even with 8gb. It's just that more is better.
As Brian said, the only solution that will not impact performance is to put the two databases on separate servers. OK, you don't have the hardware available. So the question becomes one of 'does the impact on performance rise to such a level as to cause an operational problem for the business?'
Only your organization can answer that, and probably only after implementing the solution and seeing the actual result.
But in any event, putting any form of a "database" that is other than production into a production database is a disaster looking for an opportunity to happen.
Aside from seconding what the others said, I'll add that I'm running the configuration you stated in the original post. It is stupid and not my decision (and partly a second machine is awaiting fixin').
I arbitrarily decided to run the test instance noarchivelog and with about half the SGA of the production instance. Works ok for my situation, YMMV. There are many more schemata on test, and it is much larger than prod. The key is to be able to rebuild any of the schemata from exports, which for me is necessary anyways due to app requirements. It's rare for any of them to be exactly like prod - development and uat are necessarily going to be ahead of prod, various other users special requirements tend to fall behind or be subsets.
If your company is too cheap to do it right, they need to sign off on any resulting operational deficiencies. This includes the periodic disaster of wrong db. It is up to you to set things up to minimize those - change screen colors and prompts, make difficult username/passwords that slow people down and make them think, whatever it takes. It's never enough, so the real secret is to be able to recover quickly.
Even if you have separate instances, you will probably be running them from the same Oracle home - this means that any Oracle upgrades/patches you apply on that home will affect both instances. This may be an issue if you were planning to test upgrades/patches in UAT before deploying to production, unless you also plan to have separate Oracle homes. If you don't need the extra safety net of testing upgrades/patches before deploying to production (or if you have a development machine), then this may be a workable solution. Long term, it would probably be best if they were in separate servers.