RE: New Schema or New Database?
Our DBA group has recently been getting numerous requests for new databases (training, inventory, customer contacts, etc..) from different departments within the company. Our normal procedure is to create a new instance for the database, create the schema, users, etc..., set up backups and turn it over. However, with the volume of requests we are now getting, we are pondering the idea of creating just one instance and giving each database request its own tablespace and schema. (similar to informix and sybase architecture). Glenn, Be careful with this often-quoted truism - an Oracle schema is NOT the same as a database in Sybase, Informix, SQL Server or DB2. (For those who have heard my rant on this before, now is the time to groan and hit the Delete button). A schema is a schema ... the same concept exists in all of the DBs mentioned above. Apart from the problems already highlighted (no independent tuning, no independent upgrades/patches to Oracle, no fine control on some privileges (resource, dba, etc.)), there are also backup and restore problems. If sub-section A calls to say Quick!, it's gone down the tubes, restore last night's backup, think of the complication you'll face when sub-section B says no way. It can be done, but involves a lot more efforts (e.g. restoring to another instance, exporting the schema, then importing it - instead of just a normal restore). If that doesn't put you off (and it doesn't have to), then try it out. Just don't refer to it as being like a database in informix of sybase :-) :-) :-) Ciao Fuzzy :-) -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Grant Allen INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: New Schema or New Database?
Glenn Creating a new database definitely costs more in support. It needs a backup plan, recovery testing, etc. In the past I've examined issues like how much the new application is like existing applications, whether it is likely to need the same upgrade timing, backup schedule (before RMAN). Lately my boss has started asking about how many databases a DBA can manage, so from now on, each schema gets its own database. Gotta get my numbers up! Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Tuesday, January 21, 2003 8:54 AM To: Multiple recipients of list ORACLE-L Our DBA group has recently been getting numerous requests for new databases (training, inventory, customer contacts, etc..) from different departments within the company. Our normal procedure is to create a new instance for the database, create the schema, users, etc..., set up backups and turn it over. However, with the volume of requests we are now getting, we are pondering the idea of creating just one instance and giving each database request its own tablespace and schema. (similar to informix and sybase architecture). My questions for discussion are these; 1) What are the benefits/risks associated with this scenario? Please note that these databases/schemas are unrelated. 2) What questions (for a user questionaire) should we ask regarding their database requirements, which will help us make an informed decision? My concerns are; 1) the inability to tune the instance for one schema/applications performance needs. 2) uptime/availability requirements may differ among the databases. 3) backup/restore scenarios specific to the schema/database (restore just one schema to a point-in-time). We want to be able to save on memory(sga) and processes by combining the databases into one instance as schemas, but don't want to limit the different applications to 'one-size-fits-all' for performance/recovery scenarios. Any advice would be greatly welcomed. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Glenn Travis INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: New Schema or New Database?
Another concern is user rights. When you copy a production database to test, everything in that database is an exact copy of production. If you just import a production schema into a test schema, your users and their roles are not updated. You will have to discuss your concerns with the developers. The benefits may outweigh the costs. Jay [EMAIL PROTECTED] 01/21/03 09:53AM Our DBA group has recently been getting numerous requests for new databases (training, inventory, customer contacts, etc..) from different departments within the company. Our normal procedure is to create a new instance for the database, create the schema, users, etc..., set up backups and turn it over. However, with the volume of requests we are now getting, we are pondering the idea of creating just one instance and giving each database request its own tablespace and schema. (similar to informix and sybase architecture). My questions for discussion are these; 1) What are the benefits/risks associated with this scenario? Please note that these databases/schemas are unrelated. 2) What questions (for a user questionaire) should we ask regarding their database requirements, which will help us make an informed decision? My concerns are; 1) the inability to tune the instance for one schema/applications performance needs. 2) uptime/availability requirements may differ among the databases. 3) backup/restore scenarios specific to the schema/database (restore just one schema to a point-in-time). We want to be able to save on memory(sga) and processes by combining the databases into one instance as schemas, but don't want to limit the different applications to 'one-size-fits-all' for performance/recovery scenarios. Any advice would be greatly welcomed. **DISCLAIMER This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message. The contents do not represent the opinion of DE except to the extent that it relates to their official business. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jay Hostetter INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: New Schema or New Database?
As you said, one advantage of a single instance is the memory and disk space usage. Another disadvantage is when you need to upgrade the database for one application, but not for another. Keith - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Tuesday, January 21, 2003 8:53 AM Our DBA group has recently been getting numerous requests for new databases (training, inventory, customer contacts, etc..) from different departments within the company. Our normal procedure is to create a new instance for the database, create the schema, users, etc..., set up backups and turn it over. However, with the volume of requests we are now getting, we are pondering the idea of creating just one instance and giving each database request its own tablespace and schema. (similar to informix and sybase architecture). My questions for discussion are these; 1) What are the benefits/risks associated with this scenario? Please note that these databases/schemas are unrelated. 2) What questions (for a user questionaire) should we ask regarding their database requirements, which will help us make an informed decision? My concerns are; 1) the inability to tune the instance for one schema/applications performance needs. 2) uptime/availability requirements may differ among the databases. 3) backup/restore scenarios specific to the schema/database (restore just one schema to a point-in-time). We want to be able to save on memory(sga) and processes by combining the databases into one instance as schemas, but don't want to limit the different applications to 'one-size-fits-all' for performance/recovery scenarios. Any advice would be greatly welcomed. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Glenn Travis INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer.
Re: New Schema or New Database?
Glenn: You already know the questions and seem to be pointed to the answers. We put multiple schemas in an instance when there is a similarity. If the schemas belong to the same business unit or department, and they are similar applications, like OLTP, then we can put them in the same instance. If the application is to be used for batch processing, then group it with like applictions. For instance, instances dedicated to training apps, ad hoc querying, customer management, web applications, etc. can be grouped into a single instance if the resource demands are balanced. 1) The risks are directly related to how secure the schema is. Don't give the schema userid DBA privileges and SELECT ANY TABLE privileges and you should be fine. It wouldn't hurt to use Fine Grained Access either. 2) The kind of questions to ask are : describe the application, characterize it as ad hoc, decision support, batch processing, OLTP, OLAP, etc. Insure that the cost-based optimizer is okay to use. Ask how often the database is to be updated with records and how much data they expect to have initially and in 1 year. Ask about a maintenance window for performing backups, etc. Find out the maximum amount of concurrent interactive users they plan on supporting. Find out if the database is accessed via an application/web server or from individual clients. Find out what the recovery needs are and how soon they have to be up in case of a problem: back on-line in two hours, six hours, etc.? Do they need to be able to recover from 24 hours ago, or up to the minute recovery? By answering these questions, you should be able to answer concerns you had. I hope this helps. RWB Glenn Travis [EMAIL PROTECTED]@fatcity.com on 01/21/2003 08:53:56 AM Please respond to [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Our DBA group has recently been getting numerous requests for new databases (training, inventory, customer contacts, etc..) from different departments within the company. Our normal procedure is to create a new instance for the database, create the schema, users, etc..., set up backups and turn it over. However, with the volume of requests we are now getting, we are pondering the idea of creating just one instance and giving each database request its own tablespace and schema. (similar to informix and sybase architecture). My questions for discussion are these; 1) What are the benefits/risks associated with this scenario? Please note that these databases/schemas are unrelated. 2) What questions (for a user questionaire) should we ask regarding their database requirements, which will help us make an informed decision? My concerns are; 1) the inability to tune the instance for one schema/applications performance needs. 2) uptime/availability requirements may differ among the databases. 3) backup/restore scenarios specific to the schema/database (restore just one schema to a point-in-time). We want to be able to save on memory(sga) and processes by combining the databases into one instance as schemas, but don't want to limit the different applications to 'one-size-fits-all' for performance/recovery scenarios. Any advice would be greatly welcomed. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Glenn Travis INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
