♠️Alireza Kamrani♠️
07/04/2024
Introduction:
To assist you with developing a long-term plan for your database patching and upgrades, Oracle provides this list of changes, deprecations and desupports across multiple releases.
This document is updated regularly to reflect information Oracle can provide about releases as they happen, so that you can plan for changes in releases that you plan to move to at a later date.
For example, if you are upgrading to Oracle Database 19c, it can be helpful for your long-term planning to be aware of features that have been desupported in a later release, or for which there is a deprecation notice in a later release. In addition, it can be helpful to be aware that security protocols or default parameter settings have changed in a later release, so that you can begin your preparations for that change in your current release well before you want to upgrade to a release where those deprecations or desupports are in effect.
In this post I have presented some of the features that have changed in version 23ai:
About Read-Only Oracle Homes
With Oracle Database 23ai, an Oracle home is available in read/write mode by default. However, you can choose to configure an Oracle home in read-only mode after you have performed a software-only Oracle Database installation.
A read-only Oracle Home simplifies provisioning by implementing separation of installation and configuration.
In a read-only Oracle home, all the configuration data and log files reside outside of the read-only Oracle home.
Apart from the traditional ORACLE_BASE andORACLE_HOME directories, the following directories contain files that used to be in ORACLE_HOME:
- ORACLE_BASE_HOME
- ORACLE_BASE_CONFIG
Note:This feature does not affect how database administrators monitor, diagnose, and tune their system performance.
SYSDATE and SYSTIMESTAMP Reflect PDB Time Zone
Starting with Oracle Database 23ai, SYSDATE and SYSTIMESTAMP can be managed separately for each database, following the individual database time zone setting.
To increase the applicability and transparency of multitenant for even more consolidations of independent databases, pluggable databases (PDBs) can now be managed individually for databases in container databases (CDBs).
All user-visible operations and internal functions (for example, Oracle Scheduler or Oracle Flashback technology) adhere to this setting.
In previous releases, the SYSDATE and SYSTIMESTAMP settings were centrally managed, following the operating system level of the database host.
With this update, Oracle Multitenant enables an Oracle Database to consolidate multiple pluggable databases as self-contained databases, improving resource utilization and database management.
If you do not change your initialization parameters after the upgrade, then the default remains, and all pluggable databases inherit the system time from the operating system.
Oracle Spatial GeoRaster JPEG Compression on 4-band Raster Blocks
Starting with Oracle Database 23ai, JPEG compression on Oracle Spatial GeoRaster object can only be applied on 1-band and 3-band raster blocks.
If you have any GeoRaster objects that have 4-band raster blocks, then you must reblock the objects to 1-band or 3-band raster blocks before applying the JPEG compression. If you have any GeoRaster objects that have JPEG compression on 4-band raster blocks in previous releases, then you must reblock them to 1-band or 3-band raster blocks before upgrading to Oracle Database 23ai.
BIGFILE Is the Default for SYSAUX, SYSTEM, and USER Tablespaces
Starting with Oracle Database 23ai, newly created databases use BIGFILE as the default for the SYSTEM, SYSAUX, and USER tablespaces.
A bigfile tablespace is a tablespace with a single, but large datafile.
Traditional small file tablespaces (smallfile), in contrast, typically contain multiple datafiles, but the files cannot be as large.
Making SYSAUX, SYSTEM and USER tablespaces bigfile tablespaces by default will benefit large databases by reducing the number of datafiles, thereby simplifying datafile, tablespace and overall global database management for users.
So be careful to have a specific maintenance plan for these big tablespaces in recovery scenario or maintenance.
Terminal Release of Stored Outlines
Oracle Database 23ai is the terminal release of stored outlines. Migrate all stored outlines to SQL plan baselines.
Stored outlines were deprecated in Oracle Database 11g. Oracle is preparing to discontinue further support for stored outlines. Alternative functionality is provided using SQL Plan Management baselines, which provide numerous enhancements.
SQL/JSON Function JSON_VALUE With a Boolean JSON Value
Starting with Oracle Database 23ai, the data type BOOLEAN is added to Oracle SQL. This feature extends SQL/JSON operators to allow returning a BOOLEANvalue or accepting one as input.
After you update the COMPATIBLE parameter to23.0.0.0, SQL/JSON path-expression item methodsboolean() and booleanOnly() now return a SQL BOOLEAN value. This means that, in a query that has json_value semantics, a value produced by the item method is of type BOOLEAN by default: the value is handled as if it were controlled by a json_valueRETURNING clause of type BOOLEAN.
In earlier releases, these methods returned a VARCHAR2(20) value 'true' or 'false'. If you need to obtain a VARCHAR2 value (for compatibility reasons, for example), then you can wrap the value with SQL function to_char.
Migrate from Non-AES Algorithms in FIPS Before Upgrade
If you use Transparent Data Encryption (TDE), then you must migrate your source database to AES encryption before starting your upgrade to Oracle Database 23ai.
In Oracle Database 23ai, when you use Transparent Data Encryption (TDE) configured for the Federal Information Processing Standard (FIPS), only Advanced Encryption Standard (AES) ciphers AES-128, AES-192, and AES-256 are allowed. If your source Oracle Database is configured for the FIPS mode, and it is using any other algorithms to encrypt a column or a tablespace, then the column and tablespace must be rekeyed using AES before upgrade.
If you upgrade your source database and it is using desupported algorithms for encryption, then the upgraded database will either fail to start up, or encrypted tablespaces will not be available, because the database cannot decrypt tablespace keys. In that case, Oracle recommends that you downgrade your database, upgrade your encryption keys to the supported AES ciphers, and then restart the upgrade.
Overview of JSON-Relational Duality Views
Duality views combine the advantages of using JSON documents with those of the relational model, while avoiding the limitations of each. JSON-relational duality underpins collections of documents with relational storage: active, updatable, hierarchical documents are based on a foundation of normalized relations.
- A single JSON document can represent an application object directly, capturing the hierarchical relations among its components. A JSON document is standalone: self-contained and self-describing — no outside references, no need to consult an outside schema. There's no decomposition, which means that JSON is schema-flexible: you can easily add and remove fields, and change their type, as required by application changes.
However, relationships among documentsare not represented by the documents themselves; the application must code relationships separately, as part of its logic. In particular, values that are part of one document cannot be shared by others. This leads to data duplication across different documents (whether of the same kind or different kinds), which in turn can introduce inconsistencies when documents are updated. - The relational model decomposes application objects ("business objects") into normalized tables, which are explicitly related but whose content is otherwise independent. This independence allows for flexible and efficient data combination(joining) that is rigorously correct and reliable.
This avoids inconsistencies and other problems with data duplication, but it burdens application developers with defining a mapping between their application objects and relational tables. Application changes can require schema changes to tables, which can hinder agile development. As a result, developers often prefer to work with document-centric applications.
A JSON-relational duality view exposes data stored in relational database tables as JSON documents. The documents are materialized — generated on demand, not stored as such. Duality views give your data both a conceptual and an operational duality: it's organized both relationally and hierarchically. You can base different duality views on data that's stored in one or more of the same tables, providing different JSON hierarchies over the same, shared data.
This means that applications can access (create, query, modify) the same data as a set of JSON documents or as a set of related tables and columns, and both approaches can be employed at the same time.
More info:
Document-Identifier Field Names for Duality Views Requirements
Starting with Oracle Database 23ai, release update 23.4, when you are using duality views, the document-identifier field name must be _id.
The name _id is the required (and only) document identifier that you can use for duality views. Duality views that do not use the _id identifier field will fail. This restriction applies with Oracle Database 23ai (23.4) and later updates.
Sincerely,
Alireza Kamrani
07/04/2024
No comments:
Post a Comment