Oracle Distributed Systems

Multiple Schema Versus Multiple Databases

Most designers and database administrators associate one schema with one application. (By schema, I mean an Oracle database account that owns the database objects that an application uses.) Whenever a new schema is introduced, the designers and DBAs must choose between giving the schema its own database or placing it with other schema in an existing database. A number of factors affect this decision

The Single Database with Multiple Schema

Quite often,it makes sense to let schema and applications share a database instance. The two primary advantages of this approach are lower administrative overhead and lower hardware costs. Every Oracle database instance carries a certain amount of overhead: disk space must be allocated to system, temporary, and rollback tablespaces; and memory must be allocated to the SGA (System Global Area). In addition, a DBA must manage users, SQL*Net configuration, database links, and so on. If you can minimize this overhead, by all means do so.

If the schemas share data, then you may realize additional benefits. For example, an inventory application that shares a VENDORS table with an accounts payable application can access the table without depending on the availability of two databases. The administrative work is simplified because no database links are required, and application code is simplified because no error trapping need exist to handle the unavailability of the VENDORS table.

Even if applications do not share data, you should consider placing different schema in the same database if you can answer “Yes” to all questions in Table 1.1.

Table 1-1. Conditions for Locating Application Schema in the Same Database Instance

Requirement	Yes	No
Are most users in the same location or using the same access path?
Do the applications have the same administrative support staff?
Do the applications have compatible availability requirements?
Do the applications have compatible database and OS version requirements and upgrade paths?
Are the applications reasonably similar in functionality and load characteristics?
Do the applications have the same usage level (e.g., QA, development, production, maintenance, etc.)?

As a general rule, it is more economical to house schemas in a single database instance than to devote an instance to every application that comes down the pike. Don’t create additional instances without good reason.

Database Instances Devoted to a Single Application

If you answered “No” to any of the conditions in Table 1.1, then your schemas probably belong in separate database instances, even if they share data.