Which Edition of Oracle RDBMS is Right for My Business?

Which Edition of Oracle RDBMS is Right for My Business?

Do I really need Oracle Enterprise Edition? Do I need Oracle Enterprise Edition in order to have a standby database? What version of Oracle do I need?  

We get questions like these a lot. Oracle’s editions and features can be a bit overwhelming. This post shares some key information that I hope will make your choice easier.

To keep this post to a manageable length, this post deals only with Oracle Version 12c and Version 19c, and excludes Oracle cloud offerings. A future post will cover those feature sets. 

Oracle Standard Vs. Enterprise

For each version covered below, I took the feature set from Oracle’s licensing documentation and listed those things that are available only in the Enterprise Edition of Oracle, and not in any of the Standard Editions.

But before we look at the specific features available in each version, let’s explore two important categories of features:

Data Guard

One of the more frequently used options in Enterprise Edition is Data Guard. A set of Data Guard features is listed in the first table for each edition below. These are used to implement high availability; that is, having a standby database available that is kept up to date with your primary production database in case your primary database goes down.

If Data Guard related features are the only set of “Enterprise-only” features that you need, then you may still be able to use Oracle’s Standard Edition. Here’s why:

DBvisit Standby, an alternative to Oracle’s Data Guard, provides an active standby database using any version of Oracle. You will still need to license the database software on both the primary and the standby server, but both can be much less expensive Standard Edition licenses. 

Oracle Security

Oracle has a number of important security options. 

The advanced security option is an extra cost option that is only available with Enterprise Edition.  This includes transparent data encryption, data redaction, data masking and subsetting (very helpful for development environments), and other security options. To adequately secure sensitive data at the database level, we advise that you use advanced security, and thus Oracle Enterprise Edition. 

With that said, if you are not using advanced security, and the only Enterprise-only option you need is Data Guard, then we recommend taking a good look at Dbvisit.

Oracle Version 12c Features

Below are the features that are only available in Enterprise Edition for Oracle 12c. If you need anything on this list, then you need Oracle Enterprise Edition. Period! 

Category Feature
Data Warehousing and Business Intelligence Advanced Index Compression
Data Warehousing and Business Intelligence Automatic Data Optimization
Data Warehousing and Business Intelligence Basic Table Compression
Data Warehousing and Business Intelligence Bitmapped index, bitmapped join index, and bitmap plan conversions
Data Warehousing and Business Intelligence Deferred Segment Creation
Data Warehousing and Business Intelligence Exadata Flash Cache Compression
Data Warehousing and Business Intelligence Heat Map
Data Warehousing and Business Intelligence Hybrid Columnar Compression
Data Warehousing and Business Intelligence Hybrid Columnar Compression Row-Level Locking
Data Warehousing and Business Intelligence In-memory Parallel Execution
Data Warehousing and Business Intelligence Oracle Advanced Compression
Data Warehousing and Business Intelligence Oracle OLAP
Data Warehousing and Business Intelligence Oracle Partitioning
Data Warehousing and Business Intelligence Parallel capture and apply via XStream
Data Warehousing and Business Intelligence Parallel Data Pump Export/Import
Data Warehousing and Business Intelligence Parallel index build/scans
Data Warehousing and Business Intelligence Parallel query/DML
Data Warehousing and Business Intelligence Parallel Statement Queuing
Data Warehousing and Business Intelligence Parallel statistics gathering
Data Warehousing and Business Intelligence Prefix Compression (also called Key Compression)
Data Warehousing and Business Intelligence Summary management—Materialized View Query Rewrite
Data Warehousing and Business Intelligence Transportable tablespaces, including cross-platform and full transportable export and import
High Availability Application Continuity
High Availability Automatic Block Repair
High Availability Block change tracking for fast incremental backup
High Availability Block-level media recovery
High Availability Cross-platform Backup and Recovery
High Availability Duplexed backup sets
High Availability Fast-start fault recovery
High Availability Flashback Database
High Availability Flashback Table
High Availability Flashback Transaction
High Availability Flashback Transaction Query
High Availability Global Data Services
High Availability Lost Write Protection
High Availability Online Datafile Move
High Availability Online index rebuild
High Availability Online index-organized table organization
High Availability Online table redefinition
High Availability Oracle Active Data Guard
High Availability Oracle Data Guard—Far Sync Standby
High Availability Oracle Data Guard—Real-Time Cascading Standbys
High Availability Oracle Data Guard—Redo Apply
High Availability Oracle Data Guard—Snapshot Standby
High Availability Oracle Data Guard—SQL Apply
High Availability Parallel backup and recovery
High Availability Recovering tables and table partitions from RMAN backups
High Availability Rolling Upgrade Using Active Data Guard
High Availability Rolling Upgrades—Patch Set, Database, and Operating System
High Availability Tablespace point-in-time recovery
High Availability Transaction Guard
High Availability Trial recovery
High Availability Unused block compression in backups
Integration Advanced Replication
Integration Messaging Gateway
Integration Sharded Queues
Manageability Database Resource Manager
Manageability Oracle Cloud Management Pack for Oracle Database
Manageability Oracle Data Masking and Subsetting Pack
Manageability Oracle Database Lifecycle Management Pack for Oracle Database
Manageability Oracle Diagnostics Pack
Manageability Oracle Fleet Patching and Provisioning

(formerly Rapid Home Provisioning)

Manageability Oracle Real Application Testing
Manageability Oracle Tuning Pack
Manageability SQL Plan Management
Manageability SQL Tuning Sets
Networking Infiniband Support
Networking Network Compression
Networking Oracle Connection Manager
Performance Adaptive Execution Plans
Performance Attribute Clustering
Performance Client Side Query Cache
Performance Concurrent Execution of UNION and UNION ALL Branches
Performance Database Smart Flash Cache
Performance Fault Tolerant In-Memory Column Store
Performance In-Memory Aggregation
Performance In-Memory Column Store
Performance PL/SQL Function Result Cache
Performance Query Results Cache
Performance Support for Oracle Exadata Storage Server Software
Performance TimesTen Application-Tier Database Cache
Performance Zone Maps
Scalability Oracle NoSQL Database Basic Edition
Scalability Quality of Service Management
Security Enterprise User Security
Security Fine-grained Auditing
Security Oracle Advanced Security
Security Oracle Database Vault
Security Oracle Label Security
Security Privilege Analysis
Security Real Application Security
Security Redaction
Security Transparent Sensitive Data Protection
Security Virtual Private Database
Snapshots and Cloning Storage Snapshot Optimization
Spacial Multimaster replication of SDO_GEOMETRY objects
Spacial Parallel spatial index builds
Spacial Partitioned spatial indexes

Now we’ll look at features that are only available in certain versions of Oracle 12c Standard Edition, or that are limited in Standard Edition. The “Notes” column explains the limitations.

Category Feature SE1 SE/SE2 EE Notes
Data Warehousing and Business Intelligence Oracle Machine Learning (formerly Advanced Analytics) N Y N Included with SE2 and EE

Not included with SE1 and SE

OML4R (Oracle R Enterprise) Server is limited to operation on Oracle Linux 6 or higher

High Availability Optimization for Flashback Data Archive N Y N Basic Flashback Data Archive is in all editions. Optimization for Flashback Data Archive requires EE and the Oracle Advanced Compression option.
Integration Basic Replication Y Y N SE/SE1/SE2: read-only, updateable materialized view
Integration Oracle Streams Y Y N SE/SE1/SE2: no capture from redo
Manageability Instance Caging N Y N Included with SE2 and EE

Not included with SE1 and SE

Spacial Oracle Spatial N Y N Included with SE2 and EE

Not included with SE1 and SE

Spacial RDF Graph N Y N Included with SE2 and EE

Not included with SE1 and SE

If you need any of the above features, then you may need Oracle Enterprise Edition, depending on the specifics as listed in the notes.

That’s it!

Your DBA team should be able to tell you if you need/use these Enterprise-only features. 

If you don’t need any of these features, then potentially you can save many thousands of dollars by using the Standard Edition instead. 

Oracle version 19c Features

OK, that’s it for 12c. Oracle 19c is essentially the same but with a somewhat different, more “evolved” set of options. The considerations mentioned above remain valid. 

First, let’s look at the 19c features that definitely require Enterprise Edition:

Category Feature
High Availability Application Continuity
High Availability Oracle Sharding
High Availability Oracle RAC One Node
High Availability Oracle Data Guard—Redo Apply
High Availability Oracle Data Guard—Far Sync Standby
High Availability Oracle Data Guard—SQL Apply
High Availability Oracle Data Guard—Snapshot Standby
High Availability Oracle Data Guard—Real-Time Cascading Standbys
High Availability Oracle Active Data Guard
High Availability Rolling Upgrades—Patch Set, Database, and Operating System
High Availability Rolling Upgrade Using Active Data Guard
High Availability Online index rebuild
High Availability Online table organization
High Availability Online table redefinition
High Availability Duplexed backup sets
High Availability Block change tracking for fast incremental backup
High Availability Unused block compression in backups
High Availability Block-level media recovery
High Availability Lost Write Protection
High Availability Automatic Block Repair
High Availability Parallel backup and recovery
High Availability Tablespace point-in-time recovery
High Availability Trial recovery
High Availability Fast-start fault recovery
High Availability Flashback Table
High Availability Flashback Database
High Availability Flashback Transaction
High Availability Flashback Transaction Query
High Availability Optimization for Flashback Data Archive
High Availability Online Datafile Move
High Availability Transaction Guard
High Availability Cross-platform Backup and Recovery
High Availability Global Data Services
High Availability Recovering tables and table partitions from RMAN backups
Integration Messaging Gateway
Integration Sharded Queues
Manageability Oracle Cloud Management Pack for Oracle Database
Manageability Oracle Data Masking and Subsetting Pack
Manageability Oracle Database Lifecycle Management Pack for Oracle Database
Manageability Oracle Diagnostics Pack
Manageability Oracle Tuning Pack
Manageability Oracle Real Application Testing
Manageability Database Resource Manager
Manageability SQL Tuning Sets
Manageability Oracle Fleet Patching and Provisioning (formerly Rapid Home Provisioning)
Networking Infiniband Support
Networking Oracle Connection Manager
Networking Network Compression
Performance Client Side Query Cache
Performance Query Results Cache
Performance PL/SQL Function Result Cache
Performance Oracle TimesTen Application-Tier Database Cache
Performance Database Smart Flash Cache
Performance Adaptive Execution Plans
Performance Concurrent Execution of UNION and UNION ALL Branches
Performance Oracle Database In-Memory
Performance In-Memory Column Store
Performance In-Memory Aggregation
Performance Attribute Clustering
Scalability Oracle Real Application Clusters (Oracle RAC)
Scalability Oracle NoSQL Database Basic Edition
Security Column-Level Encryption
Security Tablespace Encryption
Security Oracle Advanced Security
Security Oracle Database Vault
Security Oracle Label Security
Security Enterprise User Security
Security Centrally Managed Users
Security Fine-grained Auditing
Security Privilege Analysis
Security Real Application Security
Security Redaction
Security Transparent Sensitive Data Protection
Security Virtual Private Database
Snapshots and Cloning Storage Snapshot Optimization
Spatial and Graph Data Parallel spatial index builds
Spatial and Graph Data Multimaster replication of SDO_GEOMETRY objects
Spatial and Graph Data Partitioned spatial indexes
VLDB, Data Warehousing, and Business Intelligence Oracle Partitioning
VLDB, Data Warehousing, and Business Intelligence Oracle On-Line Analytical Processing (OLAP)
VLDB, Data Warehousing, and Business Intelligence Oracle Advanced Compression
VLDB, Data Warehousing, and Business Intelligence Advanced Index Compression
VLDB, Data Warehousing, and Business Intelligence Prefix Compression (also called Key Compression)
VLDB, Data Warehousing, and Business Intelligence Hybrid Columnar Compression
VLDB, Data Warehousing, and Business Intelligence Hybrid Columnar Compression Row-Level Locking
VLDB, Data Warehousing, and Business Intelligence Heat Map
VLDB, Data Warehousing, and Business Intelligence Automatic Data Optimization
VLDB, Data Warehousing, and Business Intelligence Basic Table Compression
VLDB, Data Warehousing, and Business Intelligence Deferred Segment Creation
VLDB, Data Warehousing, and Business Intelligence Bitmapped index, bitmapped join index, and bitmap plan conversions
VLDB, Data Warehousing, and Business Intelligence Parallel query/DML
VLDB, Data Warehousing, and Business Intelligence Parallel statistics gathering
VLDB, Data Warehousing, and Business Intelligence Parallel index build/scans
VLDB, Data Warehousing, and Business Intelligence Parallel Data Pump Export/Import
VLDB, Data Warehousing, and Business Intelligence In-memory Parallel Execution
VLDB, Data Warehousing, and Business Intelligence Parallel Statement Queuing
VLDB, Data Warehousing, and Business Intelligence Parallel capture and apply via XStream
VLDB, Data Warehousing, and Business Intelligence Transportable tablespaces, including cross-platform and full transportable export and import
VLDB, Data Warehousing, and Business Intelligence Summary management—Materialized View Query Rewrite

If you need any of the above, the you must use Oracle Enterprise Edition 

Now we look at the features that are included in the Oracle 19c Standard edition, but are limited.

Category Feature Notes
Consolidation Oracle Multitenant – # of PDBs The number value in each column indicates the maximum number of pluggable databases (PDBs) that can be created for each offering.

For all offerings, if you are not licensed for Oracle Multitenant, then you may have up to 3 user-created PDBs in a given container database at any time.

Manageability SQL Plan Management SE2: Only one SQL plan baseline per SQL statement is allowed and SQL plan evolution is disabled. Limits on baseline capture methods as well.

The following DBMS_SPM functions and procedures are not allowed: CONFIGURE, LOAD_PLANS_FROM_AWR, LOAD_PLANS_FROM_SQLSET, and all functions and procedures associated with SQL plan evolution.

If you are not using pluggable databases, or if three databases are enough, and if you are not using sophisticated plan management, then you can likely use Standard Edition.

If you know of any other enterprise-only options that are not listed here, or if you think I misstated anything, please comment.  I’d like to hear from you. Also, if you know of other good disaster recovery alternatives, let me know.

If you are not sure about any of this, or you just want to double-check your thought process, leave a comment or give me a call and I will be happy to have a conversation with you about it.

Oracle Active Data Guard Replication Error with Cisco Firewall: Root Cause and Workaround

Oracle Active Data Guard Replication Error with Cisco Firewall: Root Cause and Workaround

One of our customers had issues over the past several months with Oracle Active Data Guard replication to a standby server. The database on the standby server would intermittently fall out of sync with the database on the primary server, and log files were not consistently shipping to the standby server. 

Active Data Guard Replication Error

The Oracle database version was 12.2.0.1 running on Oracle Linux 6. The firewall was a Cisco ASA-5585-SSP-40, and the ASA version is 9.6(4)8. 

TNS tracing showed: CORRUPTION DETECTED: In redo blocks starting at block #…

By the time I got involved, the firewall administrators had already implemented all the recommended firewall changes to disable the following:

    •     SQLNet fixup protocol 
    •     Deep Packet Inspection (DPI
    •     SQLNet packet inspection 
    •     SQL Fixup

The following errors were noted in the primary database alert log:

    •     ORA-16055: FAL request rejected 
    •     ARC6: Standby redo logfile selected for thread 2 sequence 33351 for destination LOG_ARCHIVE_DEST_2 
    •     ARC6: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (12152) 
    •     ARC6: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned 

The following errors were noted in the standby database alert log:

    •     CORRUPTION DETECTED: In redo blocks starting at block #…
    •     RFS[20]: Possible network disconnect with primary database
    •     Error 1017 received logging on to the standby 
    •     FAL[client, USER]: Error 16191 connecting to…
    •     ORA-16191: Primary log shipping client not logged on standby 

The root cause of the problem turned out to be a bug in the Cisco firewall.  For reasons unknown, when the primary and standby database listeners were using port 1521, the firewall would ignore the settings the admins had implemented for the Oracle Data Guard connections and revert to the default settings. As a workaround, we changed to a different port.

If you are experiencing intermittent or hard-to-diagnose database issues in your environment, contact Buda Consulting.

Ensure Redundant Database Coverage, During Covid-19 and Always

Ensure Redundant Database Coverage, During Covid-19 and Always

One of the principles of Buda Consulting’s redundant database coverage is that we always have at least two people who know your databases and your environment. This best practice is especially important at this time.

In normal times, this helps with responsiveness and cuts down on required knowledge transfer when a problem occurs or when an urgent change is necessary.

But the impact that Covid-19 is having on all of us illustrates another, more important reason. 

Fortunately, most people that contract the illness get minor symptoms and recover quickly.  But sadly, those that get very sick, are incapacitated very quickly.  I personally know two people, both relatively young, that died from Covid within 5 days of first showing symptoms. One within two days. The progression of the symptoms is very rapid, incapacitating the virus’ most unfortunate victims very quickly.  Leaving little time to make preparations.

While it may seem like a trivial matter when considering the magnitude of loss that many are suffering, losing your critical data when your business is struggling to adjust to the rapidly changing environment can be debilitating for your business.

If your databases are housing mission-critical data, best practice at this time and always is to have more than one person who has the knowledge and ability to manage your database systems and to respond to any problems that arise.  After your sole DBA gets sick may simply be too late. 

Don’t wait, make sure that at least two people in your organization know how to connect to your databases and are familiar with the environment today.  Or reach out to a trusted redundant database coverage service provider like Buda Consulting and engage someone else to back you up. It has never been more critical to do so.

Stay safe!

An Overlooked Oracle Management Task—Support Identifier Management

An Overlooked Oracle Management Task—Support Identifier Management

One of the most overlooked tasks that can become an issue outside of your RDBMS environment is managing your Oracle customer support identifier (CSIs).  CSIs are added to your support.oracle.com account. They allow you to perform activities from creating a service request or looking up information in a global knowledge database. When a CSI is added to an account for the first time, the person applying automatically becomes the main administrator for the CSI.

While it makes sense that a manager/supervisor would become the administrator for a CSI, this is where things often take a turn for the worse.  This is because a manager/supervisor is less likely to be the one actually creating a service request or assigning accounts to services such as Oracle Enterprise Manager or Oracle Secure Backup Web Services.  Also, what happens when a manager/supervisor retires or leaves their position for a new one?  Often the administrator privilege is not passed to a new employee, which puts your account at risk.  How?  It leaves you unable to make account information changes to your systems or users in Oracle’s CSI Administrator portal.

If there is no one with administrator access, new employees cannot be granted access to your CSI, old employees cannot be removed from a CSI and changes to SR level data cannot be modified.  Allowing old employees access to your CSI also poses a security threat if said user has administrative rights.

Oracle Customer Support Identifier Best Practices

To mitigate these issues, I recommend the following best practices to make sure you do not run into any CSI issues:

      • Make all users of a database administration group CSI administrators – This makes sure your company will always have access to make CSI changes even if any one of the employees leave.
      • Set account expiration dates on your accounts if a user is leaving – This will automatically disable a user’s access to your CSI.
      • Create a service account that only has USER level access to your CSI. This account can be used to connect such services as Oracle’s Enterprise Manager or Oracle Secure Backup Web Services module. A service account allows first- and third-party services to continue to operate even when an employee leaves.

If you are looking for a best-practice approach to on-site or remote DBA services, contact Buda Consulting. Our experienced staff of certified Oracle professionals can address all your DBA requirements.

This post was written by Willie Gray, a member of Buda Consulting’s DBA team.

Does Data Governance Make You Shudder?

At a recent vendor conference, I found myself talking with a varied group of technology professionals. Two were technology generalists, one was a data engineer, one was responsible for transportation technology at a major university (think autonomous vehicles, traffic sensors, etc.), another was responsible for university student and teacher data (lesson plans, research findings, etc.), and one was responsible for his organization’s IT security. 

During the conversation, someone mentioned data governance. Immediately there was a conspicuous and collective sigh around the table.
Our group clearly found the subject intimidating and uncomfortable.

Why does the mere mention of data governance invoke that kind of response? 

One reason is probably that the potential scope of a data governance effort is so wide. It could basically involve every possible task associated with data management. 

Further, the word “governance” emphasizes the importance of taking those tasks seriously, and getting them right. So when you combine “there’s a lot to do” with “and it’s all important,” fear kindles in the hearts of those responsible.

And rightly so: the consequences of poor data governance are significant. They range from regulatory fines and sanctions for failing to adequately protect data or for noncompliance, to the insidious costs of bad data quality, such as missed business opportunities due to poor decision-making or lost customers due to low service levels.

But there are a lot of “big and important” topics in IT, and they don’t all make a diverse group of seasoned professionals wince. I decided to do some research and dig a little deeper into why data governance seems to be outside our collective comfort zone.

One thing that came up right away is that data governance is defined and described in diverse ways. Moreover, the terms used to describe the activities or responsibilities that comprise data governance aren’t defined or used the same way by everyone. Anytime I tried to define a term, I’d find another term that meant the same thing… sometimes, depending on context. In other words, the definitions tend to morph according to where one looks at them from (our viewpoint).

That variability and inconsistency made just framing this blog post difficult—never mind a program that “…includes the people, processes and technologies needed to manage and protect the company’s data assets…” and impacts an organization at strategic, tactical and operational levels. 

Indeed, there’s an axiom in management theory that “You can’t manage what you can’t name.” Further, “You can’t properly manage what you don’t define explicitly.” In other words, how you define a data governance program will significantly impact your ability to manage it successfully.

Given that a key element of data governance is ensuring the consistency of data definitions across an organization, I find it ironic that we don’t have consistent, agreed definition of terms for the components of data governance itself.

Normally when I write about a complex topic, I break it down into a list of subtopics and then decompose each of those—similar to how I would attack a complex software development project or database design endeavor. But all the variability and overlap among terms that I encountered around data governance forced me to change not only my approach to writing this post, but the whole focus of the post. 

Instead of working top-down, I had to work bottom-up. Below I listed some subheadings that are parts of data governance, and then I listed all the tasks or responsibilities that relate to all the subheadings. Your mission—if you choose to accept it—is to take a few minutes to decide under which subheading you would place each task. 

So here are the subheadings that I started with:

  • Data Management (aka Database Management)
  • Data Security
  • Data Stewardship
  • Data Quality
  • Master Data Management
  • Regulatory Compliance (GDPR, PCI, HIPAA)

Here is my list of many (but by no means all) of the critical tasks that need to be completed in order to ensure that your data is relevant, available, secure, and optimized (i.e., “governed”). 

Under which subheading would you put each of these tasks if you were to document your data governance activities?

  • Data Encryption
  • Data Masking
  • Data Access Control
  • High Availability
  • Disaster Recovery
  • Data Lifecycle Management
  • Data Version Tracking
  • Data Custody Tracking and Control
  • Data Provenance Tracking
  • Change Tracking and Management
  • Data Access Auditing
  • Data Update Auditing
  • Data Validation
  • Define Business Rules for Data
  • Meta Data Management and managing consistent data definitions
  • Managing Taxonomies and Naming Conventions

Some of the tasks seem to relate to obvious subheading, such as Meta Data Management and Taxonomies and Naming Conventions being grouped under Master Data Management. Or grouping Data Encryption, Data Masking and Data Access Control under Data Security. 

But you could group Data Access Control under Data Stewardship as well, along with many other tasks. In fact, Data Stewardship is used somewhat interchangeably with Data Governance… sometimes. And which tasks fit under Compliance? Maybe all of them? 

My personal takeaway from all this is that it may be better to look at this particular issue from the bottom up of instead of the top down. When wrapping our minds around data governance, we might want to look at all the relevant lower-level tasks (lower in this hierarchy, not in importance), and think about what is involved in each and what tools can help us implement them.

Don’t get too caught up with definition of terms or with categorizing tasks into subgrouping, as I did for the purposes of discussion. At least when it came to writing this blog post, I found that to be the most intimidating part.

Are you looking for strategic, tactical and/or operational support around a data governance program or related initiative? Contact Buda Consultingand let’s talk about where you are, where you need to be and how we can help.

SQL Server Contained Databases and Oracle Multi-tenant: Advantages Compared

SQL Server Contained Databases and Oracle Multi-tenant: Advantages Compared

Oracle introduced multi-tenant databases in version 12c. SQL Server answered with container databases in version 2012.

These capabilities add efficiencies and reduces deficiencies, but in different ways. Pre-multitenant Oracle required more administration activities for individual databases than SQL Server, but offered more isolation and control for each database. Pre-container SQL Server required less administration activities for individual databases than Oracle, but offered less isolation and control for each database.

Essentially, these new functionalities moved both Oracle and SQL Server to a more satisfying middle ground.

SQL Server Vs. Oracle Multi-tenant

With the new changes:

  • They both allow individual databases to stand alone and be ported from one environment to another more easily.
  • They isolate much of the admin work that needs to be done on the Oracle Software level (patching, configuration, etc.) from the work that is more database-specific (backup/recovery, performance tuning, etc.).
  • They isolate all of the metadata about a particular database within the database itself, as opposed to intermingling the metadata from multiple databases.

Oracle Multi-tenant Advantages

Each approach also touts some specific advantages. For example, Oracle Multi-tenant is said to be “designed for the cloud” because it simplifies database consolidation. A multi-tenant container database can hold multiple pluggable databases, and application code connects to specific pluggable databases. This makes it easier to consolidate multiple databases onto private clouds without changing their applications, yet still control resource prioritization as you had previously.

Another advantage of the Oracle Multi-tenant approach is easier provisioning and cloning. Moving and cloning databases is an everyday admin task that multitenancy can help accelerate. For example, you can quickly copy a database and “plug it in” to a different container. Filesystems that support copy on write allow you to clone pluggable databases almost instantly.

SQL Server Advantages

SQL Server’s contained database feature offers advantages in the area of user authentication. A contained database is isolated from other databases and from the SQL Server instance that hosts it. Support for user authentication at the database level for contained databases reduces a database’s dependency on the logins of the SQL Server instance. You can also have separate firewall rules for contained database users versus users who authenticate at the server level. This user model makes it much easier to move databases between systems, including Microsoft Azure.

In short, the main goal of multitenancy is to facilitate database consolidation, while the main purpose of contained databases is to enable isolation and thus portability. Yet each approach addresses both these concerns.

If you are considering using either or both of these models, or would benefit from guidance on how to use either or both more efficiently or effectively, contact Buda Consulting to schedule a free consultation.