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 D&E 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).
