Call (800) 766-1884 for Oracle support & training
Free Oracle Tips

Oracle Consulting Support
Oracle Upgrades
Use New Oracle Features
Oracle Replication Support
Oracle Training
Remote Oracle DBA
System Documentation
Oracle Tips
Oracle Performance

Free Oracle Tips



BC Oracle tuning

Oracle training

Oracle support

Remote Oracle




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.


Oracle performance tuning software 

Oracle performance tuning book


Oracle performance Tuning 10g reference poster
Oracle training in Linux commands
Oracle training Excel
Oracle training & performance tuning books



Copyright © 1996 -  2014 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation. 

Hit Counter