For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!
Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.
IMO, Prod & Test databases should be configured EXACTLY the same.
IMO, it is not wise to install Prod & Test databases on the same physical system.
Other than that I agree with you.
I'm not a fan of running test and production databases on the same physical server in the first place...
If your primary goal is to minimize the impact of the test database on the production database, two virtual machines are likely to be the way to go. That assumes that you are going to allocate fixed amounts of RAM and of CPU to each virtual machine rather than allowing the virtual machines to grow and shrink as demand changes. That helps insulate prod from load in test. But it has the downside that when test is idle, prod will only be able to use, say, half the physical resources on the server. If you allow prod to grab more resources when test is idle, which tends to lead to better utilization of the available hardware, prod performance will necessarily be affected negatively when someone starts running queries on test. You can try to balance the trade-offs by, say, letting prod have at least half of the resources and grow to 3/4 of the resources and letting test have at least a quarter of the resources and grow to half of the resources.
Of course, even with two virtual machines that have fixed sizes, it's still possible for test to affect prod. If you've got a bunch of queries running in test that are using a ton of the available I/O bandwidth, for example, you're going to impact the I/O bandwidth available to the prod database.
Justin
Thank you for your responses SB and Justin.
Although you marked the thread ANSWERED you have raised several red flags.
We must to install 2 databases (10.2.0.1 and 10.2.0.5) : Test and production. Both OLTP and no more than 200 Gb each one. Obviusly Prod environment will be configured in archive log, and test in noarchive log.
Why?
1. Why 'must' you use such ancient database versions?
2. Why must you use two DIFFERENT versions? What possible justification can you have for that? Just use 10.2.0.5 for both. Using two versions is just asking for trouble. Those versions will have different bugs, different functionality and any 'fix' you do on DEV may not work the same on PROD.
3. Why is it 'obvious' that DEV will be in noarchive mode? You will be using that version for pre-production rollout and testing. It needs to be as identical as PROD as possible to minimize any surprises.
In order to get the most reliable configuration what option do you recommend? Install Solaris 10 OS, next install the Oracle Software and the 2 databases. or Install Solaris 10 OS, virtualization software, create two virtual machines, two oracle SW installations and finally each database in each VM ??
Why Solaris? If you use virtualization why not use Oracle Enterprise Linux?
I would like to get a configuration where the production environment performance cannot be affected by the test environment. What do you think ??
I would like to get a configuration where the production environment performance cannot be affected by the test environment.
What do you think ??
I think that your goal is NOT possible if both are on the same physical server. BAD, BAD, BAD idea.
I also don't think it is possible to give you good advice on a 'solution' without knowing what skill sets you have available.
If none of the staff has any experience with virtualization you should NOT be using that option at this stage of things. VM is not just another software layer; it is another level of complexity. Not to mention the fact that you didn't even mention what you even mean by 'virtualization'. Do you mean Oracle's VirtualBox? Oracle's VM Manager and Servers? Citrix? I can't imagine using ANY of those for a one machine environment; where is the backup/recovery going to come from?
The best advice I can give is to stop what you have begun and write Business and Functional Requirements documents that address the full software development lifecycle including: security, backup/recovery, installation, support, maintenance, performance and scalability.
Then you will be in a better position to know in what direction the 'correct' solution lies.
Thanks for your reply,
1. WE must anciente versions due to old applications?
2. Why must you use two DIFFERENT versions? You are right but to migrate to 10.2.0.5 depends of one applications pass the scheduled test in 10.2.0.5. If it pass we will have only one version, as you said: 10.2.0.5
3. Why is it 'obvious' that DEV will be in noarchive mode? It is only a DEV database and in the company we used without noarchive mode.
Thank you for your responses. ;-)
I still don't understand two of those answers:
You first said your PROD version is 10.2.0.5 so are you saying that 'one application' is NOT in production yet?
How are you going to test it in 10.2.0.5 if the only DB you have that is 10.2.0.5 is PROD? You aren't doing your testing in PROD are you?
Yes - I understand that a DEV database is often used without noarchive mode. But that is ONLY when there is a TEST or QA database to use for pre-production rollout testing. That 'pre-production' DB should be identical to PROD including archive logging.
So my point was that if you only have DEV and PROD you should make them as identical as possible.
At any rate you have the solution you were looking for.
Let me add that I agree with rp0428. A preproduction environment or a performance testing environment or a production simulation environment must also be using archivelog mod as in production. This allows you to capture (a) the additional I/O (b) the volume of archivelog generation -- which you need to estimate disk space and backup requirements.
Similarly, both environments should be running the same patch level 10.2.0.5 or 11.2.0.3 / 11.2.0.4
Hemant K Chitale
723000Jul 27 2010 — edited Jul 27 2010