Capacity Planning and Architecture - Expert Oracle RAC Performance Diagnostics and Tuning - page 27

Analysis of trend data from both the tables indicate that they are constant with no increase until June 4th, after
which the growth is assumed, indicated by PROJECTED . The “ QUALITY ” column indicates an assumed future value.
Using these growth trends, a projection is to be derived at to size the tables, indexes, and the database as a whole
for future growth. These values also help drive the size of storage and distribution of data across spindles. Using the
procedure DBMS_SPACE.CREATE_TABLE_COST , the estimated table size can be calculated:

DECLARE
ub NUMBER;
ab NUMBER;
BEGIN
DBMS_SPACE.CREATE_TABLE_COST('USERS',63,195006890,10,ub,ab);
DBMS_OUTPUT.PUT_LINE('Used Bytes = ' || TO_CHAR(ub));
DBMS_OUTPUT.PUT_LINE('Allocated Bytes = ' || TO_CHAR(ab));
END;
/
Used Bytes = 14522695680 (108GB)
Allocated Bytes = 14562623488 (108GB)

PL/SQL procedure successfully completed.

From the preceding output, with the current utilization, the table size should be set at 108 GB. This is probably
a rough guess looking at the current workload conditions. However, if consulting with the business analysts of the
organization a more realistic growth scenario could be determined after taking into account any future acquisitions,
new marketing promotions, and so forth, that would drive additional business and growth of data. Once we have the
storage size, user growth pattern, current workload of the system/servers, and so forth, the next step is to look at the
sizing these servers for tomorrows need.

Architecture
Each application managed by each business unit in an enterprise is deployed on one database. This is because the
database is designed and tuned to fit the application behavior, and such behavior may cause unfavorable results when
other applications are run against them. Above this, for machine critical applications, the databases are configured
on independent hardware platforms, isolating them from other databases within the enterprise. These multiple
databases for each type of application managed and maintained by the various business units in isolation from other
business units cause islands of data and databases. Such configurations results in several problems such as

• Underutilization of database resources

• High cost of database management

• High cost of information management

• Limited scalability and flexibility

In other words, there are no options to distribute workload based on availability of resources.
Oracle database basic architecture is centered around one server that will contain the memory structure
containing data and user operations and the physical storage where data is persisted for future use. Such a
configuration with one instance and one database is considered a single-instance configuration of the Oracle database.
On the other hand, a more scalable version of the database would be many servers containing instances that access the
same copy of the physical database and share data between instances via the cluster interconnect called a clustered
database configuration. In this section, after a brief comparison, we discuss the Oracle RAC architecture.