At OOW this year, Oracle announced Database 18c. Technically this is a refresh to 12.2.0.1, and at one point was going to be released as 12.2.0.2, but Oracle is using the new release to change how releases are both named and managed. This change in the release cycle puts Oracle in alignment with the rest of the industry that uses the year of the release as the version number.
There is more to this than just the change to the name though. This is about moving to continuous development cycle, putting new features into the hands of the DBA and developers sooner than ever before! Continuous delivery, also known as Agile development, allows software features to be delivered more efficiently than the traditional model where monolithic releases include hundreds of changes on each release. Smaller, more rapidly released means more features available sooner, as well and few changes to the software. Not only are new features available quicker, but also the effort required to test new releases should be less, due to the smaller number of changes made to the software.
Looking at the history of database release dates, we see rapid releases early on, but as the product grew more mature, the effort to develop and test the technologies appeared to have slowed down the schedule to a release about every 5 years for the last two releases, and about every 2-3 years in between releases for the older versions.
1979 Version 2
1983 Version 3
1984 Version 4
1985 Version 5
1988 Version 6
1997 Version 7
1997 Verision 8
1998 Version 8i
2001 Version 9i
2003 Verison 10g
2007 Version 11g
2013 Version 12c
The latest three major releases, 10g, 11g and 12c had many years in between the releases, not only delays the availability of newly developed features but also introducing many changes into the release. These new features like RAC, RAT, Advanced Compression, Multitenant, In-Memory and more, all provide both the database administrator and developer more tools to create innovative application on top of a secure and efficient database infrastructure. The later releases also made hundreds of changes to the database technology, making the effort required to test application after an upgrade daunting for many clients.
Oracle’s change to annual releases addresses both the delay in getting new features out, as well as the amount of changes introduced. This should enable developers and DBAs to rapidly adopt the new Releases, enabling new and innovative solutions.
The new release method also changes how patches are released, introducing some new terminology to the DBA. The Release is the major number, and should be released annually going forward. This is where the majority of new features are introduced to the database.
The next tier, is the Release Update, known as an RU. The RU replaces the older Bundled Patch (BP), and should be released on a quarterly basis. The RU includes function fixes, security fixes, optimizer changes, functional enhancements and emergency patches. RUs should be released for about two years after the initial release date of the database. Most development environments should patch at the RU level.
The next tier, is the Release Update Revision (RUR), and is intended to extend the functional life of an RU. The RUR focuses on security and regression patches only and would not normally change other aspects of the database. It is initially to be released quarterly and as needed. RURs have a limited life, and would normally be expected to be used to support Production patching, until the production environment can be patched to the latest RU for the major Release version.
While this sounds complex, it has an advantage or allowing both the DBA and the developer to quickly identify the database release, removing the complexity of the current PSU confusion. A sample version matrix may look like the following image, that shows three RUs, with 18.1 have two RURs, 18.2 a single RUR and 18.3 with no released RURs yet. Moving between RUs and RURs is a simple patch exercise, and is not considered an database upgrade. A DBA should be able to simply patch from 18.1.1 to 18.6.
While the relatively short life of a Release may worry some DBAs, the smaller number of changes between releases should mean that upgrades between releases would be simpler than in the past, growing the toolbox that both DBAs and developers use to solve problems faster. Oracle also mentioned that some Releases will have extended support available, allowing for a significantly longer lifespan of the database. While 18c is not expected to have this support, a future version will.