Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.
Production database on development Server
Can anyone give me some insight into this? Its being suggested to our group that the production database be put on the same server as the development database. This to me sounds like a bad idea but im looking for concreate reasons. Can someone enlighten me?
Asked:
6
3
3- +2
4 Solutions
development is where things are supposed to go wrong. bad queries consumig memory and cpu.
runaway processes filling up file systems - also consuming cpu as well as io resources
if you have shared oracle homes, it means you can't patch/upgrade development without also patching/upgrading production at the same time. - i.e. you can't test prior to production install.
security requirements in development are often less than those of production. Combining them under differing security could result in regulatory violations depending on the industry and country/region/regulatory bodies.
runaway processes filling up file systems - also consuming cpu as well as io resources
if you have shared oracle homes, it means you can't patch/upgrade development without also patching/upgrading production at the same time. - i.e. you can't test prior to production install.
security requirements in development are often less than those of production. Combining them under differing security could result in regulatory violations depending on the industry and country/region/regulatory bodies.
Well here is a couple of things thats springs to my mind.
Performance issues may arise due to shared resources, eg untuned sql statements run in the development system could affect the production system by using a huge amount of I/O,CPU, Memory etc.
Increase risk of human errors by mixing environments (dev and prod). You need to pay close attention to which database you are working in when they are on the same OS. You may want to do an update or shutdown the database in dev but is unfortunately logged in, in the production database.
Seperation of duties, developpers may have full control of the development environment while having no access to Production which is the responsibility of the Operations department. Thats pretty hard to ensure when the databases are on the same server.
Stability. Development usually needs new stuf for testing etc that fine but adding stuff may require a reboot of the serveror restart of databases (especially if they share the binary files).
Performance issues may arise due to shared resources, eg untuned sql statements run in the development system could affect the production system by using a huge amount of I/O,CPU, Memory etc.
Increase risk of human errors by mixing environments (dev and prod). You need to pay close attention to which database you are working in when they are on the same OS. You may want to do an update or shutdown the database in dev but is unfortunately logged in, in the production database.
Seperation of duties, developpers may have full control of the development environment while having no access to Production which is the responsibility of the Operations department. Thats pretty hard to ensure when the databases are on the same server.
Stability. Development usually needs new stuf for testing etc that fine but adding stuff may require a reboot of the serveror restart of databases (especially if they share the binary files).
I agree with slightwv and sdstuber that it sounds like a horribly stupid idea.
Is it possible, though, that someone is misunderstanding/ misinterpreting the suggestion? In particular, if your organization is using some form of virtualization technology, perhaps the suggestion is that the development and production databases be installed in separate VM instances that happen to run (at least by default) on the same physical server? That would mitigate most of the potential downsides-- the development and production databases would both be affected by upgrades/ patches to the VM software, but that is probably no more risky than the existing infrastructure that is probably shared between production and development (i.e. network hardware, SANs, and the like).
Is it possible, though, that someone is misunderstanding/ misinterpreting the suggestion? In particular, if your organization is using some form of virtualization technology, perhaps the suggestion is that the development and production databases be installed in separate VM instances that happen to run (at least by default) on the same physical server? That would mitigate most of the potential downsides-- the development and production databases would both be affected by upgrades/ patches to the VM software, but that is probably no more risky than the existing infrastructure that is probably shared between production and development (i.e. network hardware, SANs, and the like).
the grumphy old men has spoken ;-)
forgot this:
The only pro's i can see is reduced cost up front especially on licenses but in the long run it will cost more having the production suffer from the above mentioned situations than you can save now. But it's not as visible.
forgot this:
The only pro's i can see is reduced cost up front especially on licenses but in the long run it will cost more having the production suffer from the above mentioned situations than you can save now. But it's not as visible.
To add to jocave's comment:
Oracle will only support running Oracle on their VM architecture so unless you are running it, never put a production database on a VM.
Oracle will only support running Oracle on their VM architecture so unless you are running it, never put a production database on a VM.
Oracle supports running their software in a virtual machine. If an issue cannot be reproduced in a non-VM environment, however, Oracle will point you at the VM vendor for support unless that vendor happens to be Oracle, in which case they will troubleshoot the VM as well. Metalink 249212.1 is Oracle's full support position.
I really don't consider 'before you open an SR, reproduce the problem on a physical server' as 'support' but OK.
That's not Oracle's support position, though. Oracle will happily troubleshoot a problem on a non-Oracle VM up to the point where it appears to be caused by the VM, at which point you'll need to bring the VM vendor's support in as well. Support is not going to make you reproduce the problem on a physical server before they start investigating.
It's really no different than using a SAN for storage. Oracle doesn't certify hardware, so your SAN is undoubtedly unsupported. If Oracle troubleshoots a performance problem and gets to the point where they are able to identify that physical I/O on some file(s) takes way too long, it's entirely possible and reasonable that they would instruct you to contact the support organization for your SAN to troubleshoot the problem. On the other hand, if you're using an Exadata storage array, Oracle support will troubleshoot the entire storage stack.
Of course, different support reps will be slower and quicker to point fingers at other components and other support organizations, but that's the nature of support. And different sorts of issues will lend themselves to being called VM issues (or SAN issues or operating system issues or any other potential vendor's issues).
For a pretty good discussion about the practical aspects of Oracle support in a non-Oracle VM (from a non-Oracle blogger)
What the Oracle/ VMWare support statement really means... and why
It's really no different than using a SAN for storage. Oracle doesn't certify hardware, so your SAN is undoubtedly unsupported. If Oracle troubleshoots a performance problem and gets to the point where they are able to identify that physical I/O on some file(s) takes way too long, it's entirely possible and reasonable that they would instruct you to contact the support organization for your SAN to troubleshoot the problem. On the other hand, if you're using an Exadata storage array, Oracle support will troubleshoot the entire storage stack.
Of course, different support reps will be slower and quicker to point fingers at other components and other support organizations, but that's the nature of support. And different sorts of issues will lend themselves to being called VM issues (or SAN issues or operating system issues or any other potential vendor's issues).
For a pretty good discussion about the practical aspects of Oracle support in a non-Oracle VM (from a non-Oracle blogger)
What the Oracle/ VMWare support statement really means... and why
I don't want to hijack this thread and if you are comfortable running Production in a VM that's great and I wish you all the best.
Given the following excerpt from the blog post and Metalink note would cause me to never do it, at 3AM when my database goes down:
"Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware."
Given the following excerpt from the blog post and Metalink note would cause me to never do it, at 3AM when my database goes down:
"Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware."
this thing can be done as i have done it for non critical DB and for very small DB on production but u have to be careful when you export ORACLE_SID= ?
and performance of system - hope you done well because i know this situation when u have less resource available and application demand. Best of Luck -
and performance of system - hope you done well because i know this situation when u have less resource available and application demand. Best of Luck -
even if you don't need the answer anymore, you do have an answer (several of them in fact)
please accept all that are appropriate and close the question
please accept all that are appropriate and close the question
>>not an issue anymore
I'm afraid I have to object to this reason.
You asked a philosophical/theoretical question. Just because you no longer need our responses does not mean we did not answer the question asked.
Please split the points among the valued responses.
I'm afraid I have to object to this reason.
You asked a philosophical/theoretical question. Just because you no longer need our responses does not mean we did not answer the question asked.
Please split the points among the valued responses.
I would suggest an equal split among all participants (participants with more than one post count as one). I apologize if I missed anyone. Please add it if I did.
http:#a34164815
http:#a34164852
http:#a34164994
http:#a34165031
http:#a34187043
http:#a34164815
http:#a34164852
http:#a34164994
http:#a34165031
http:#a34187043
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
Featured Post
An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.
One of a set of tools we're offering as a way of saying thank you for being a part of the community.
Tackle projects and never again get stuck behind a technical roadblock.
Join Now
It's way to easy to 'confuse' the two and accidentally make a mistake that would take out production. A simple ORACLE_SID 'oops' and you are done.
Also, development is supposed to be able to 'evaluate' new versions/products.
How can you start the evaluation of the newest OS? Let alone latest database products.