We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Course Of The Month
10 days, 8 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Production database on development Server
Posted on 2010-11-18
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?
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
6
3
3- +2
19 Comments
Active today
It's a horrible idea.
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.
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.
Active 2 days ago
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.
Active today
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.
Active today
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
Active today
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 -
Active 2 days ago
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
Active today
>>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.
Active today
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
Featured Post
We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Truncate is a DDL Command where as Delete is a DML Command.
Both will delete data from table, but what is the difference between these below statements
truncate table <table_name> ??
delete from <table_name> ??
The first command cannot be …
Introduction
A previously published article on Experts Exchange ("Joins in Oracle", http://www.experts-exchange.com/Database/Oracle/A_8249-Joins-in-Oracle.html) makes a statement about "Oracle proprietary" joins and mixes the join syntax with gen…
This video explains at a high level about the four available data types in Oracle and how dates can be manipulated by the user to get data into and out of the database.
This video shows how to configure and send email from and Oracle database using both UTL_SMTP and UTL_MAIL, as well as comparing UTL_SMTP to a manual SMTP conversation with a mail server.
Suggested Courses
Earn Certification
HTML5 Specialist - Certification
Free withPremium
Course of the Month10 days, 8 hours left to enroll
Earn Certification
Certified Information Systems Auditor (CISA)
$99.00$89.10
628 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.