After upgrading many databases to Oracle 19c, I have faced an interesting error when I reached to the step of switch my environment variables to 19c binaries and starting the database in upgrade mode:
sqlplus / as sysdba
SQL> startup upgrade;
ORA-00119: invalid specification for system parameter DISPATCHERS
ORA-00109: invalid value for attribute PRESENTATION: oracle.aurora.server.SGiopServer
after checking I found out that currently this is the parameter vaule:
Oracle 21c has been released on-premise as you might already know and the base version is 21.3, the first RU released for 21c is in October CPU 2021. [21.4.0.0.211019]
First observation when you download the RU for 21c is the following statement in Oracle portal (there is NO separate OVJM patch anymore…its combined in one patch in DB RU)
I have downloaded the latest Opatch utility 12.2.0.1.27 and copied it under my Oracle home in $ORACLE_HOME/OPatch/ directory
Oracle has back-ported “Gradual Database Password Rollover” security feature that was initially introduced in Oracle 21c to Oracle 19c with July 2021 RU (Release Update- 19.12) and there is no need to change the compatibility parameter.
This great new feature is very much needed and great addition from Oracle (Thank You Oracle)….if there is a need to change passwords for critical applications/systems this will require application shutdown first then updating the “new” password in multiple places of the application….with this new feature you can change the password without the need of application outage/downtime and there will be NO Locking of the account taking place as both old & new passwords will be authenticated successfully by the database until rollover period is finished.
T Explore it I will create a new profile called “DEFAULT2” with parameter PASSWORD_ROLLOVER_TIME set to 1 day:
SQL> CREATE USER emad1 IDENTIFIED BY EMAD_first_prm221d
PROFILE DEFAULT2
DEFAULT TABLESPACE “USERS”
TEMPORARY TABLESPACE “TEMP”;
SQL> grant create session to emad1 ;
SQL> select username,account_status,profile,authentication_type from dba_users where username=’EMAD1′;
Now, I will change the password to a different value:
SQL> alter user emad1 identified by EMAD_first_prm33zd;
If you query the dba_users view, you find that account_status is now changed from “OPEN” to “OPEN & IN ROLLOVER”
NOTE: What will happen if you change the password again, in this case Only the first password and the third one will authenticate successfully….so if you change the password multiple times only 2 passwords are valid for authentication (the first initial password, and the last password reset).
Another side note…. that maximum number of days allowed for the value of the parameter “PASSWORD_ROLLOVER_TIME” is 60 (which is 60 days), and minimum value is 1 hour.
To forcefully end the rollover period you can execute the following SQL command:
SQL> alter user emad1 expire password rollover period;
Checking SYS.USER$ table, you will see the value of ASTATUS column changed from “32” to “0” , zero is the value after the rollover period is finished. So the value of “32” indicates that the database account is in the “rollover” phase.
This is a quick tip…..if you would like to know the location of your Oracle SQL Developer connections, there is a connection file (in JSON format) located:
in my case the Oracle SQL Developer version is the latest (at the time of writing this blog version 21.2) so you will find system21.2 folder name is referenced in the above path.
Here I am going to illustrate the procedure to patch oracle 19c database in windows enthronement, to apply APRIL 2021 CPU patches (19.11) RU (release update).
Download Windows Database Bundle Patch (19c) 19.11 from Oracle Support website.
Download the latest OPatch utility:
Ensure your run CMD as administrator:
Check your environment variables:
set PATH=%ORACLE_HOME%\perl\bin;%PATH%
set ORACLE_HOME=D:\WINDOWS.X64_193000_db_home
set PERL5LIB=
Stop Distributed Transaction Coordinator:
net stop msdtc
Go to the directory where the patch is downloaded
D:
cd D:\19.11.windows_patch\32409154
Apply the patches using the downloaded Opatch utility and copy it under your $ORACLE_HOME/OPatch directory:
First, to explore blockchain table in 19c release, you will need to apply the latest patches and change compatibility parameter value (which is unusual), the blockchain feature was introduced initially in 21c and back-ported to 19c with 19.10 RU (release update) in January 2021 CPU. Here I am going to explore it after patching the database to 19.11 (April 2021 CPU).
To raise the compatibility parameter:
I have shutdown the database
SQL> shutdown immediate;
Then, edited the init.ora file and changed compatibility parameter value:
SQL> SELECT name, value, description FROM v$parameter WHERE name = ‘compatible’;
Let us explore it:
In pluggable database PDB1
CREATE TABLESPACE ledgertbs;
CREATE USER auditor identified by audit_123 DEFAULT TABLESPACE ledgertbs;
GRANT create session, create table, unlimited tablespace TO auditor;
GRANT execute ON sys.dbms_blockchain_table TO auditor;
Connecting to PDB1 database as user “auditor”:
I will create a blockchain table named AUDITOR.LEDGER_EMP that will maintain a tamper-resistant ledger of current and historical transactions in PDB1. Rows can never be deleted in the AUDITOR.LEDGER_EMP blockchain table. The blockchain table can be dropped only after 3 days of inactivity.
After upgrading an Oracle database from 12cR1 to 19c release, this database using Oracle Spatial component. The developers noticed many of their spatial queries are failing and the following error is thrown:
ORA-29903: error in executing ODCIIndexFetch() routine
What is the cause of this issue ?
check the value of this parameter ” SPATIAL_VECTOR_ACCELERATION ” in your database
SQL> show parameter SPATIAL_VECTOR_ACCELERATION
if its set to “FALSE” , then enable it to “TRUE”
SQL> ALTER SYSTEM SET SPATIAL_VECTOR_ACCELERATION = TRUE;
And this will fix the problem. I was under the impression that ” SPATIAL_VECTOR_ACCELERATION” parameter is “optional” parameter that will improve your queries against GIS data, but it seems starting with Oracle 12cR2 and beyond this parameter should be set to TRUE !