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
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.
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 !