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" <Glenn.Travis_at_sas.com>@fatcity.com on 01/21/2003 08:53:56 AM

Please respond to ORACLE-L_at_fatcity.com

Sent by: root_at_fatcity.com

To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> 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: Glenn.Travis_at_sas.com

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: ListGuru_at_fatcity.com (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: Reginald.W.Bailey_at_jpmorgan.com

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: ListGuru_at_fatcity.com (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).