 |
|
EnterpriseDB: Oracle Compatibility
Oracle Tips by
Burleson
|
In this
chapter, I am going to discuss some of the areas of potential impact
when trying to maintain compatibility between EnterpriseDB Advanced
Server and Oracle. Obviously, you will have to determine your
version of Oracle. I will assume that you are also either
developing primarily on and for Oracle or that you want to be able to
easily port between Oracle and EnterpriseDB.
If it
seems that I am being negative here, I am not. As of this
writing, EnterpriseDB is a great database and is the most Oracle
compatible database available. It will only become more so over
time. To accurately assess the ability to port an application,
it is important to see where the compatibilities exist and where they
don't. That is what I am trying to do in the chapter.
Before
assuming that a feature is not supported (by trying it and getting an
error or by reading the installed documentation and not seeing it), it
is important to check the online manual and the EnterpriseDB.com user
forums. EnterpriseDB Advanced Server is continuously evolving
and what may have been true when the documentation was written is not
necessarily true now.
In the
same vein as what was true then may not be true now, if you find an
answer to your question on the forum, check the date. If it's
more than a month old, it may be worth it to post a new message
verifying if it is still true.
Do not
forget that the support team is a great resource for verifying
features and providing information on using them. They are
frequently able to provide a work-around for features that are not
currently supported natively.
To
maintain compatibility between any two databases from different
vendors, there are three areas of pain:
*
Administrative – Will your administrative scripts run, is the
administrative interface the same, can you perform the same tasks as
easily between them, etc
* Design
– Will the current design work, are foreign keys declared and
implemented in the same way, are advanced features used the same, etc
* Coding
– Is the SQL syntax compatible, is the procedural language compatible,
is the same feature set supported
Oracle
PL/SQL has been available much longer than EnterpriseDB SPL has.
PL/SQL is currently a much more robust, feature rich language.
SPL however already supports the core set of PL/SQL functionality and
advances are being made regularly.
For SQL
programming, function availability, syntax and data type support is
paramount. EnterpriseDB Advanced Server supports a huge set of
data types and provides a large set of functionality.
Unfortunately, Oracle provides several data types that are not
available in EnterpriseDB and provides whole sets of functionality
that are not easily reproducible in EnterpriseDB.
Administration is not often thought of as a compatibility feature.
I believe that if you need to port between databases, it is important
to understand how those databases will be administered. For
example, administering Oracle 7 is vastly different from administering
Oracle 10g.
Administration
As
discussed in Chapter 6, the DBA Management Server is the EnterpriseDB
database management platform. The comparable tool in Oracle is
Oracle Enterprise Manager (OEM). OEM provides access to most of
the configuration options in Oracle as well as replication and other
add-on features.
While
the DBA Management Server provides excellent visibility of database
performance, actually administering requires knowledge of server
configuration files. There are not that many files.
Chapter 2 provides an overview of most of those files including
security.
Having
said that, administering any database has some common areas of
concern:
* Space
Management
*
Database Creation
* Memory
Management & Performance
*
Availability/Reliability
*
Security
* Client
Management
If you
have to retrain and/or hire DBAs to manage the new database, or if the
management of that database is much more time consuming, much of the
benefit and cost savings go out the window. Moving from Oracle
to EnterpriseDB should not be an undue burden with a little knowledge
and advanced planning.
This
is an excerpt from the book "EnterpriseDB:
The Definitive Reference" by Rampant TechPress. |