Oracle 12c: An (Almost) One-size Fits All Database
November 18, 2016

Oracle 12c: An (Almost) One-size Fits All Database

James Lui | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User

Overall Satisfaction with Oracle Database 12c

Our first implementations of 12c are new installations that are certified with the release. That path makes any initial use simpler and the most capable of leveraging an out-of-the-box standard deployment template using the most common required features (such as stand-alone non-multitenant installs of Enterprise Edition 64-bit with AL32UTF8 character sets.) Then we began upgrading the existing 11gR2 in-house custom applications to 12c (12.1.0.2) leveraging the supplied DBUA (database Upgrade Assistant) utility allowing preservation of all of the existing filesystem layouts and automatic handling of depreciated configuration settings. The DBUA also automatically upgrades any existing table-related and PL/SQL objects to use the 12c data dictionary (which is basically a superset of 11gR2). Finally on a much slower path, we deal with analyzing un-certified applications, or older databases (such as 9.2/9i or even 8.1.7.4/8i databases) to determine whether application retirement is imminent and upgrade is impractical given the lifecycle timeline available. Of course, in each case we consider the lifecycle span of an application to see if 12c's extended support period benefits or has no effect on prospective changes to the application. Also, we need to consider which OS platforms each legacy database resides upon and whether it too, will have a supported path to 12c.

For most of my managed systems, support for bugfixes, security and troubleshooting takes precedence over justifying new features provided in 12c. In the long-term though, multi-tenancy offers the possibility of scaling back our licensing costs by combining similar databases into consolidated containers, and more flexible cloning and provisioning with the pluggable database features.
As for performance, most users will find everything that worked in 11g, works fine in 12c, with the addition of other add-on licensed options, such as In-Memory and TimesTen, allowing future expansion and scalability beyond where 11g ended.
  • Ease of upgrading from recent versions (10g/11g) to enable extended support application lifecycles. This is really critical to most installations, since user re-testing will be minimized, and existing administrative skills are leveraged in the new version without a steep learning curve.
  • 12c is a very stable release. Ever since participation in the early Beta cycles, we emphasized to Oracle, our need to not revisit extended bugfix cycles attempting to get an early release version to work in production environments experienced in many previous releases.
  • 12c's internal automatic performance management features have improved over 11g, with less re-adjustments constantly occurring allowing the database to adapt to changing demand requirements (such as OLTP during the day, but heavy OLAP at night) and not having to worry about the overhead of enabling features such as AMM (automatic memory management) or ASM (the storage-related equivalent) and watching the database tend to fight with itself trying to optimize the settings.
  • 12c is a feature-laden installation. The footprint of the software (Oracle Home) alone is about 4+GB, without any data storage added, which translates, as most new products seem to emphasize, into you're getting everything in one box. While the initial Oracle Universal Installer experience can be as simple as choosing one of 2 pre-defined database templates and clicking through 5 [Next] buttons, the jump to choosing the 3rd option (an Advanced Installation) goes from those 5 screens to over 35, which may overwhelm a new user wanting to just install a database to support a purchased application. I'd personally like to see Oracle ship pre-configured templates with its own applications to give new installers an option of choosing an application-optimized version template to further speed up the initial setup process.
  • 12c's version of listener technology is no longer compatible (nor can it be forced to be compatible) with 9i or lower legacy databases. An 8i or 9i client cannot connect to a 12c database listener. So for those with legacy interconnectivity challenges, you end up installing an edge-of-end-of-life 10g database as a go-between, just to bridge the old technology to the new ones. There should have been an option to support either a limited down-grade compatible configuration, or for a secondary light client installation that could at least support database links between the versions to provide a migration path other than multiple jumps to keep connectivity with older applications. Other database companies have always supported this, even if just to a limited extent (because it does expose security risks in the process.)
  • 12c isn't the end-of the-road version by any stretch of the imagination. If you've studied Oracle's most recent roadmap planning within the last 5 years, new releases are being timed for every 2 years, with major jumps and major technology uplifts in the process. Compared with the periods when we could run 8i for almost 10 years, without considering upgrades, that timeline has been cut by 80% shorter.
  • As a 30+-year installed Oracle database customer, the original licenses, including required increases in CPU counts, have provided the requisite reliability, stability, scalability, and performance demanded of any such product. As you will always note from Oracle, buying once and bigger, will probably cost you less than buying often and more frequently (your contract terms tend to change with each change in packaging.) As a public utility, a five-9's product is the minimum consideration for anything running on our infrastructure which delivers to our customers. Oracle has delivered on that requirement, and keeps the water flowing every day. That's our primary ROI for any investment we make.
  • Because we are also on a very long and perpetually challenging budget cycle, the freedom other commercial organizations have to "Sell more, then Buy more," doesn't apply to our organization. While we'd like to standardize every database on 12c, cost limitations of upgrading many other applications to a certified combination level, prevents us from moving ahead with that objective. In that regard, sometimes staying on 11gR2 (which has a 2 year shorter lifespan at present), is a required strategic decision, which means we are back to managing multiple technology versions, with the associated challenges. Some of those old applications sitting on a 100MB 8i Oracle Home, would experience a 2000% increase in storage footprint if migrated to an equivalent 12c version (thus consolidation and retirement are always factors considered with such legacy upgrades.)
  • DBA's who have experience only with 12c and future releases are less likely to have any experience working with non-GUI managed environments (ones without Oracle Cloud Control, Database Express, ApEx, and such) and Oracle's policy on documentation and software cutoffs for "retired/end-of-support" releases can be frustrating. Your organization has a merger with another one that happens to run older applications on older releases (such as 9i or 10g.) They're on a different OS platform. Your task is to re-host, migrate, then consolidate the applications. Good luck finding the installers and patches for an old release. This is one of those "Hey, the document is on a floppy disk. Anyone still have a floppy drive around to read it?" challenges that tends to surface long after the solutions stop being delivered.
We generally choose Oracle 12c whenever the requirements include reliability, scalability, and interconnectivity with existing applications. Most application upgrades are re-hosted in Oracle, if on Oracle. If the application supplier prefers, or has exclusive experience with a different technology, and we still prefer that particular application, it doesn't go on Oracle. If it's compatible with 12c, we'll build it on 12c. If not certified yet, we go with 11gR2 (11.2.0.4). While it would be nice to live in a unified architecture shop, it most cases, other than newly formed organizations, it doesn't become or remain practical in the long run to attempt to force uni-vendor approaches (unless, of course, you're Oracle itself, and then you acquire what's needed, and then re-brand it. That works, too.)
Oracle WebCenter Content, Oracle Enterprise Manager Cloud Control, Oracle eBusiness Suite, Oracle PeopleSoft HCM, IBM Cognos, Magento, MySQL
Great platform for any advanced application, that must be scalable, multi-platform, and certainly supporting a multitude of data-related technologies, whether Java, XML, external tables, advanced analytics, or high-availability.

I wouldn't consider Oracle 12c for an appliance application data source (meaning runtime distributions), or even for applications with limited vertical or horizontal customer focus (such as a 100-customer e-Commerce website) simply because it's a 1000lb hammer for a 1lb nail. If I had to choose an Oracle-provided resource in those cases, Oracle MySQL shines as a much easier and lighter footprint data repository, which has superior performance, and some of the most popular performance features, in a low cost-of-entry price point.