 |
|
EnterpriseDB: Space Management
Oracle Tips by
Burleson
|
Space
management is the concern of ensuring that critical databases do not
run out of disk space. Even as disks have gotten cheaper,
databases have gotten larger. At most of the jobs I have had,
space usage was always a concern.
EnterpriseDB Advanced Server stores data differently than Oracle.
Oracle physically stores data in data structures called data files.
Many objects may be stored in a single data file. Those data
files are tied to a tablespace. A database may have many
tablespaces and a tablespace may have many data files. All of
these tablespaces may reside in the same OS file directory or they may
be spread across many disks and different directories.
In
EnterpriseDB, data is stored by directories. A tablespace
(except for the defaults, only available in Unix/Linux) is tied to a
directory. Objects within the tablespace are stored as files.
That means that only Unix-like operating systems can spread their data
across multiple disks unless it is on a SAN.
You can
argue pros and cons
for both implementations. I prefer to think of them not as right
or wrong but as different. The tablespace limitation in
EnterpriseDB is a design choice and is tied to an OS feature.
Oracle chose to implement tablespaces differently and that
implementation is not OS dependant.
Regardless of that implementation, there is still a need to monitor
space usage. The DBA Management Server gives you visibility of
space usage via the dashboard on the home page. You will need to
know the space available on your disk system to understand free space
and space used. The difference being that OEM provides that in a
single view.
In
addition, understanding the physical layout will help you understand
how it impacts space maintenance. If you are using RMAN, you
will need to switch to an OS based backup utility or to the
export-type backup available with Developer Studio. My
recommendation would be to use an intelligent backup utility so that
you can automate the backups and only backup that which has changed.
The nice
thing about the implementation in EnterpriseDB is that, because each
object is a file in the OS, you have very fine-grained details about
object usage.
If you
are already using an OS based backup utility, there will be little
change in the way you backup. Change the directories and you are
done (for the most part, each tool is different).
Oracle
DBAs will not need to spend a lot of time getting up to speed on
EnterpriseDB space management. Space management is a fairly
basic concept and anyone who can manage space for an Oracle database
can do so for an EnterpriseDB database.
Database Creation
It should be obvious by now that database creation in EnterpriseDB is
quite a bit different from database creation in Oracle.
EnterpriseDB provides three layers of object definitions, Cluster -->
Database --> Schema while Oracle only provides two, Database -->
Schema. Again, this is a difference, not a right or wrong.
There are pros and cons to both.
In EnterpriseDB, once a cluster is created, you may have many
databases. Each database may have many schemas. Databases
in EnterpriseDB are largely independent although some system
functionality works at the cluster level. In Oracle, you have a
single database that may contain many schemas.
EnterpriseDB allows you to have multiple clusters per server.
Like Oracle, in EnterpriseDB you can configure several clusters
(instances) per server.
What the above is leading to is that EnterpriseDB is configured at the
Cluster layer and Oracle is configured at the instance layer.
The files in a server installation of EnterpriseDB will determine the
configuration of all databases within that installation. Where
you store your data, how memory is configured, security, etc is all
defined for the cluster.
A server installation in Oracle contains the binaries only.
Where you store your data, how your memory is configured, security,
etc is all determined per instance. Each database in Oracle may
have its own configuration.
The repercussion of that is that the creation of a database in Oracle
is a much more complex affair than creating a database in
EnterpriseDB. That complexity gives you a much finer degree of
control for each instance created. The complexity of installing
multiple instances of Oracle is reduced by using the Database
Configuration Assistant (DBCA), which is a graphical tool that walks
the user through the steps necessary to create a basic database.
Creation of databases should not be an undue burden on DBAs switching
to EnterpriseDB. There will be a learning curve on learning how
to best configure an EnterpriseDB database. Fortunately, because
EnterpriseDB is based on PostgreSQL, there are many resources to get
information about optimal configurations. The EnterpriseDB
support team is also available to help configure and troubleshoot.
This
is an excerpt from the book "EnterpriseDB:
The Definitive Reference" by Rampant TechPress.
|
