Skip to main content

Oracle Database 18c Released Description

 
 
 

Oracle Database 18c is Oracle 12c Release 2 (12.2.0.2)

In the old terms, Oracle Database 18c is a patchset for Oracle 12.2.(18c = 12.2.0.2)
 
Release Version Numbering Changes
Beginning in 2018, a new numbering schema for the database software is implemented. Instead of a legacy nomenclature such as 12.2.0.2, a three (3) field format consisting of: Year. Update. Revision is used, such as 18.1.0. This allows clear indication of:

•the feature release designation of the database software (the first field)
•the quarterly Update (the second field)
•the quarterly Revision (the third field)


 

18c released as :


•1-Mar-2018 - 18c released in OCI and OCI-C Database services (note: we earlier indicated in error these were released 16-Feb)
•16-Feb-2018 - 18c is released for Exadata and LiveSQL.oracle.com

 Release 12.2: New releases will be annual and the version will be the last two digits of the release year. The release originally planned as 12.2.0.2 will now be release 18, and the release originally planned as 12.2.0.3 will be release 19. Releases 18 and 19 will be treated as under the umbrella of 12.2 for Lifetime Support purposes. The expectation is for Oracle Database 19 to be the last release ("long term support" release) for 12.2.
 
Beginning with the next Database release (originally designated 12.2.0.2) planned for 2018, new feature releases of the database product are being provided annually, and patchsets are no longer being released.
To support both security-related fixes and high-priority non-security fixes to each feature release, quarterly Release Updates (Updates) are being provided each January, April, July and October. Oracle's quarterly Updates contain fixes for the bugs that customers are most likely to encounter:
•Query optimizer bug fixes, which were not allowed in PSU's and BP's from earlier releases are included disabled by default in the Updates.
•Updates include fixes for security vulnerabilities.
•Updates go through extensive testing at Oracle, covering functional, stress, performance, and destructive testing scenarios.
•Applying Updates in a timely manner reduces the likelihood of rediscovery of known issues.
•Updates can be installed with zero down time via RAC rolling.

 For quite some time it’s been known Oracle have moved to a new release model for most products, including the database, with the version number now including the year and the quarter etc. How the version numbers now work is explained in MOS Doc ID 2285040.1. The release schedule for these database versions is shown in MOS Doc ID 742060.1.

The changes described as above are only for Database and Grid Infrastructure release 12.2 and beyond.  Database version 12.1 and 11.2 will continue to use the legacy PSU/BP process and version numbering systems.

Comments

Post a Comment

Popular posts from this blog

19c ORACLE HOME Cloning -Linux/Solaris

  Cloning an Oracle home involves creating a copy of the Oracle home and then configuring it for a new environment. If you are performing multiple Oracle Database installations, then you may want to use cloning to create each Oracle home, because copying files from an existing Oracle Database installation takes less time than creating a new version of them. This method is also useful if the Oracle home that you are cloning has had patches applied to it. When you clone the Oracle home, the new Oracle home has the patch updates which is already applied on oracle home. Steps to clone an Oracle home step 1 : Stop Services Stop all processes related to the Oracle home. Step 2 : Create a ZIP or TAR file with the Oracle home (/u01/app/oracle/product/19.0.0/dbhome_1)    Use ROOT user for ZIP and UNZIP  # zip -r dbhome_1.zip /u01/app/oracle/product/19.0.0/dbhome_1 TAR option: # tar -cvf dbhome_1.tar /u01/app/oracle/product/19.0.0/dbhome_1 Step 3: s cp zip/tar to target s...
Post a Comment
Read more

EBS Standby Role Tranistion using standby database and standby application Tier

 Role Transitions A database can operate in either a primary or standby role - these roles are mutually exclusive. Oracle Data Guard enables you to change these roles dynamically by issuing SQL commands, and supports the following transitions: Switchover Allows the primary database to switch roles with one of its standby databases. There is no data loss during a switchover. After a switchover, each database continues to participate in the Oracle Data Guard configuration with its new role. Failover Changes a standby database to the primary role in response to a primary database failure. The following role transitions are discussed: 6.1 Performing a Switchover 6.2 Performing a Failover 6.3 Performing a Switchback to the Primary Following A Switchover/Failover Each of these three transitions requires some application configuration to be performed. Most of the application configuration step...
1 comment
Read more

EBS R12.2.4 AutoConfig could not successfully execute the following scripts followed by error "txkGenADOPWrapper.pl INSTE8_APPLY 1"

issue:txkGenADOPWrapper.pl    INSTE8_APPLY       1 WARNING: [AutoConfig Error Report] The following report lists errors AutoConfig encountered during each phase of its execution.  Errors are grouped by directory and phase. The report format is:       <filename>  <phase>  <return code where appropriate>   [APPLY PHASE]   AutoConfig could not successfully execute the following scripts:     Directory: /u01/applprod/fs2/FMW_Home/webtier/perl/bin/perl -I /u01/applprod/fs2/FMW_Home/webtier/perl/lib/5.10.0 -I /u01/applprod/fs2/FMW_Home/webtier/perl/lib/site_perl/5.10.0 -I /u01/applprod/fs2/EBSapps/appl/au/12.0.0/perl -I /u01/applprod/fs2/FMW_Home/webtier/ohs/mod_perl/lib/site_perl/5.10.0/x86_64-linux-thread-multi /u01/applprod/fs2/inst/apps/PRODDB_epc-apps12-node41v/admin/install       txkGenADOPWrapper.pl    ...
Post a Comment
Read more