Oracle AutoUpgrade with source and Target Database on different servers

AutoUpgrade utility can be used on upgrading databases from 12c R2 release (12.2 + DBJAN2019RU and newer) and it has Analyze, Fixup, Deploy and Upgrade processing modes. 

Before you proceed make sure you meet following requirements.

• create config file
• Source Database should be running in original oracle home
• The Database server should be registered in DNS
• JAVA8 required for Autoupgrade to run. Oracle 12c R2 (12.2.0.1) or newer oracle homes have a java version by default.
• If you run AutoUpgrade in batch or script mode use “noconsole” parameter

From Oracle 19c (10.3) autoupgrade.jar file exists by default, for earlier releases you must download latest autoupgrade.jar file from Oracle support.

There are four AutoUpgrade modes and each mode performs different steps

•  Analyze Mode: Setup, Pre-checks.
• Fixups Mode: Setup, Pre-checks, and Pre-fixups.
• Deploy Mode: Setup, Guaranteed Restore Point, Pre-upgrade, Pre-checks, Pre-fixups, Drain,      Database Upgrade, Post-checks, Post-fixups, and Post-upgrade.
• Upgrade Mode: Setup, Database Upgrade, Post-checks, and Post-fixups.

Analyze Mode: This mode runs few checks to see weather database is ready for upgrade. In this mode it only reads data from database to analyze and does not perform any changes.

You can run this step on source database before you setup target.

Run below command to start AutoUpgrade Analyze

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode analyze

Make sure you analyze output files for errors and run fixup on Source database server. You should see SID.html and SID_preupgrade.log files

Note that this mode also generates status files such as status.json, progress.json which can be located under cfgtoollogs/upgrade/auto/status.

Status.json – This file contains High level status of upgrade.
Progress.json – This file has contains status of progress of all upgrades

In case if target database is not on the same server then you must set the source home path in the configuration file, so that Autoupgrade analyze can run on source oracle home.

For example,
upgrade1.source_home=/home/oracle/product/12.2.0.1/dbhome_1 # Source ORACLE_HOME Path
upgrade1.target_home=/home/oracle/product/19.0.0.0/dbhome_1 # Target ORACLE_HOME Path

Fixups Mode : This mode performs all required automated fix up that are required before you start an upgrade. In this mode it creates guaranteed restore point.

Run below command on source Database server to run fixups.

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode fixups

Deploy Mode: This mode performs all required actions for an upgrade, which include analyze, fixups, upgrade and post upgrade steps. You will use this mode when source and target Oracle Home’s are on the same server. This mode also creates guaranteed restore point.

Run below command on source Database server to run fixups.

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode Deploy

Move the database from source to Target Database server and perform Upgrade mode.

Upgrade Mode: You will run this Autoupgrade mode when you are moving database to Target server or don’t have source Oracle home access. This mode is used only when you are moving to new server. But note that this mode doesn’t create guaranteed restore point and it doesn’t perform the post upgrade steps.

Before you perform upgrade make sure you copy the during_upgrade_pfile_dbname.ora from source to target Oracle Home with default name init<SID>.ora. You can also create the spfile using during_upgrade_pfile_dbname.ora which can be found under temp directory.

SQL> create spfile from pfile=' /home/oracle/autoupgrade/au21/TESTDB/temp/during_upgrade_pfile_testdb.ora';

On Target database server start the database in upgrade mode and run below command to upgrade

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode upgrade

After upgrade make sure you perform post upgrade steps manually

· Copy network files sql.net ora, listener,ora, tnsnames.ora files..etc
· Restart of database in case of RAC
· Remove guaranteed restore point

Thanks & Regards,
https://oracleracexpert.com, Oracle ACE

Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class

When launching Database configuration assistant (DBCA) you may encounter this error. The “java.lang.NoClassDefFoundError” error encounter when it could not initialize class “sun.awt.X11.XToolkit”. 

This normally occur when launching Graphic user interface (GUI)

No protocol specified

Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11.XToolkit

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:264)

at java.awt.Toolkit$2.run(Toolkit.java:860)

at java.awt.Toolkit$2.run(Toolkit.java:855)

at java.security.AccessController.doPrivileged(Native Method)

at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)

at com.jgoodies.looks.LookUtils.isLowResolution(LookUtils.java:484)

at com.jgoodies.looks.LookUtils.<clinit>(LookUtils.java:249)

at com.jgoodies.looks.plastic.PlasticLookAndFeel.<clinit>(PlasticLookAndFeel.java:135)

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:348)

at javax.swing.SwingUtilities.loadSystemClass(SwingUtilities.java:1879)

at javax.swing.UIManager.setLookAndFeel(UIManager.java:582)

at oracle.install.commons.util.Application.startup(Application.java:976)

at oracle.install.commons.flow.FlowApplication.startup(FlowApplication.java:181)

at oracle.install.commons.flow.FlowApplication.startup(FlowApplication.java:198)

at oracle.assistants.common.base.driver.AssistantApplication.startup(AssistantApplication.java:336)

at oracle.assistants.dbca.driver.DBConfigurator.startup(DBConfigurator.java:378)
at oracle.assistants.dbca.driver.DBConfigurator.main(DBConfigurator.java:513)

The main causes of the issue is
1. The DISPLAY variable is NOT set or value is not correct.
2. X Windows is not installed
3. Oracle user not added to ACL (Access Control List)

If launching from server make sure you have any X Windows software installed and install org-x11-apps.x86_64 package

If you are launching from a local workstation, make sure you have XGraphics software such as Exceed, VLC…etc tools installed. Then You can set DISPLAY by using below command

CSH
$ setenv DISPLAY <IP Address of workstation or server>:0

SSH or KSH
$ export DISPLAY=<IP Address of workstation or server>:0

In Some cases, users may face issue when installing Oracle software on Ubuntu or Linux environment.

>>> Could not execute auto check for display colors using command /usr/bin/xdpyinfo. Check if the DISPLAY variable is set. Failed <<<<

Some requirement checks failed. You must fulfill these requirements before

continuing with the installation,

Continue? (y/n) [n] Y

>>> Ignoring required pre-requisite failures. Continuing...
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2019-08-01_12-17-01PM. Please wait ....oracle$:~$ No protocol specified
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11.XToolkit

In this scenario, verify weather JDK installed on the system or not using below command
$ java -version

If not installed then installing required JDK will resolve the issue. If the problem persists, then run below command by logging as root

$ xhost +

Switch back to Oracle user and run the installation.

Thanks,

https://oracleracexpert.com, Oracle ACE Pro

Upgrade Oracle Database using AutoUpgrade Utility

Autoupgrade is used to upgrade one or more databases using command line. Using the tool, you can run pre-upgrade tasks that will provide the fixups, all recommended fixups must be executed before upgrading the database and finish the upgrade by running the post-upgrade tasks. By using this utility you can upgrade hundreds of databases with one command.

It is always recommending that you run AutoUpgrade in Analyze mode before running in Fixup mode. Note that fixup mode can make changes to the source database. The Autoupgrade includes automatic retry and fallback, schedule upgrades and modify or remove the initialization parameters which are deprecated.

AutoUpgrade utility can be used on upgrading databases from 12c R2 release (12.2 + DBJAN2019RU and newer)

You need to download AutoUpgrade utility for Databases 12c R2 and 18c. From 19.3 (19c) and later the autoupgrade.jar file exists by default.

Oracle home must contain JAVA to use AutoUpgrade Tool. Always download latest AutoUpgrade.jar file

Create a sample config.txt file for database ugrade

upgrade1.sid=TESTDB                       # ORACLE_SID of source DB
upgrade1.run_utlrp=no                       # Optional. To run utlrp after upgrade select YES
upgrade1.timezone_upg=no                # Optional. To run the timezone upgrade select YES
upgrade1.start_time=now                    # Optional Use “NOW” or specify future upgrade time and date [+XhYm (X hours, Y minutes) | dd/mm/yyyy hh:mm:ss]      
upgrade1.upgrade_node=localhost    # Optional. Default is 'localhost'
upgrade1.target_version=19               # Only required if target database version is 12.2

upgrade1.log_dir= /home/oracle/cfgtoollogs/autoupgrade/TESTDB # Log dir path for the upgrade job

upgrade1.source_home=/home/oracle/product/12.2.0.1/dbhome_1  # Source ORACLE_HOME Path 
upgrade1.target_home=/home/oracle/product/19.0.0.0/dbhome_1   # Target ORACLE_HOME Path 

AutoUpgrade with source and Target Database on same server

• Run below command to start AutoUpgrade Analyze

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode analyze
AutoUpgrade utility launched with default options
Processing config file ...
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
1 databases will be analyzed
Type 'help' to list console commands
upg> Job 100 completed
------------------- Final Summary --------------------
Number of databases [ 1 ]
Jobs finished [1]
Jobs failed [0]
Jobs pending [0]
------------------- JOBS FINISHED SUCCESSFULLY --------------------
Job 100 for TESTDB

All the logs are under the job id . Pls review all the logs for any errors and information.

You can see the warnings and errors in html file.

 

• Run below command to start deployment of upgrade on same server

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode deploy

AutoUpgrade utility launched with default options

Processing config file ...

+--------------------------------+

| Starting AutoUpgrade execution |

+--------------------------------+

1 databases will be processed

Type 'help' to list console commands

upg>

upg> lsj

+----+-------+---------+---------+-------+--------------+--------+---------------+

|Job#|DB_NAME| STAGE|OPERATION| STATUS| START_TIME| UPDATED| MESSAGE|

+----+-------+---------+---------+-------+--------------+--------+---------------+

| 102| TESTDB|DBUPGRADE|EXECUTING|RUNNING|21/05/12 15:03|15:35:22|95% Upgraded |

+----+-------+---------+---------+-------+--------------+--------+---------------+

Total jobs 1

Once upgrade is completed verify upg_summary.log for any errors

/u01/home/oracle:DBA>cat upg_summary.log

Oracle Database Release 19 Post-Upgrade Status Utility 04-30-2021 11:07:0

Database Name: TESTDB

Component Current Full Elapsed Time

Name Status Version HH:MM:SS

Oracle Server UPGRADED 19.10.0.0.0 00:09:54

JServer JAVA Virtual Machine VALID 19.10.0.0.0 00:01:12

Oracle XDK UPGRADED 19.10.0.0.0 00:00:38

Oracle Database Java Packages UPGRADED 19.10.0.0.0 00:00:05

Oracle Text UPGRADED 19.10.0.0.0 00:00:23

Oracle Workspace Manager UPGRADED 19.10.0.0.0 00:00:22

Oracle Real Application Clusters OPTION OFF 19.10.0.0.0 00:00:00

Oracle XML Database UPGRADED 19.10.0.0.0 00:00:51

Oracle Multimedia UPGRADED 19.10.0.0.0 00:01:47

Datapatch 00:01:41

Final Actions 00:01:44

Post Upgrade 00:00:16

Total Upgrade Time: 00:17:31

Database time zone version is 26. It is older than current release time

          zone version 32. Time zone upgrade is needed using the DBMS_DST package.

          Grand Total Upgrade Time: [0d:0h:20m:20s]

If you select upgrade1.timezone_upg=YES then Time zone will be upgraded as part of the Database upgrade. 

AutoUpgrade Stages

AutoUpgrade utility go through series of steps called stages but the actions performed during every stage defined by the “processing mode”. For AutoUpgrade we have Analyze, Fixups, Deploy, and Upgrade processing modes.

AutoUpgrade has the following stages: 

• SETUP: The initial stage in which it starts the job.
• PREUPGRADE: The stage in which it performs readiness for upgrade such as sufficient space
• PRECHECKS: The stage in which it performs pre-checks on source Oracle home to meet requirements for upgrade.
• GRP: Backup database using guaranteed restore point (GRP) before upgrade, this option only available in Enterprise Edition only
• PREFIXUPS: The stage in which it performs preupgrade fixups before upgrade
• DRAIN: The stage during which it shuts down the database to release resources.
• DBUPGRADE: The stage in which it performs the actual upgrade.
• POSTCHECKS: The stage in which it performs post upgrade checks on the target Oracle home before executing any postupgrade fixups.
• POSTFIXUPS: The stage in which it performs processing of postupgrade fixups, timezone upgrade is part of this step.
• POSTUPGRADE: The stage in which in copies or merges the required files from to the target Oracle home for ex:- listener, tns files

There are 2 operational modes during Autoupgrade, i.e. PREPARING and EXECUTING

There are 4 state messages

• RUNNING – AutoUpgrade is still running
• FINISHED - AutoUpgrade is successfully completed
• ERROR – AutoUpgrade has some Errors
• ABORTED - AutoUpgrade aborted response to user request.

Refer useful oracle support notes

• Database Server Upgrade/Downgrade Compatibility Matrix (Doc ID 551141.1)
• Using AutoUpgrade for Oracle Database Upgrades

Thanks & Regards,
https://oracleracexpert.com, Oracle ACE

Create, Drop, Alter Blockchain tables in Oracle 21c

Blockchain tables are designed to allow insert operations only, updates and any modifications are not allowed, and delete operations are restricted. The rows are organized into chains by storing previous row’s hash values in the current row and chain of rows is verifiable by all participants. The blockchain tables concept introduced in Oracle 21c and can be backported to 19c using a patch 32431413, but COMPATIBLE parameter must be set to 19.10.0 or late

Create and Drop Blockchain table

When creating block chain you can specify retention period for Blockchain table using “NO DROP” Clause in the CREATE BLOCKCHAIN TABLE statement to specify retention period and to specify retention period for rows use “NO DELETE” Clause .

Ex:- In below example creates Blockchain_T1 table the table can be dropped until 10 days and rows can be deleted until 15 days that they were inserted.

SQL> CREATE BLOCKCHAIN TABLE Blockchain_T1 (Col1 NUMBER, Col2 VARCHAR2(48), Col3 DATE)
NO DROP UNTIL 10 DAYS IDLE
NO DELETE UNTIL 15 DAYS AFTER INSERT
HASHING USING "SHA2_512" VERSION "v1";

Table level clauses

• NO DROP – The table cannot be dropped. 

• NO DROP UNTIL x DAYS IDLE – Table cannot be dropped when the table is IDLE and no new rows created for specified X number of days or retention period

Where X is the number of days.

Row level clauses

• NO DELETE or NO DELETE LOCKED – The Rows cannot be deleted.

• NO DELETE UNTIL x DAYS AFTER INSERT – the rows cannot be deleted until x number of days they were inserted, the retention setting can be changed using ALTER TABLE command.

• NO DELETE UNTIL x DAYS AFTER INSERT LOCKED – the rows cannot be deleted until x number of days they were inserted , also retention setting cannot be changed until x number of days

Create partition on Blockchain table

In below example creates Blockchain_T1 table with partitions. The table cannot be dropped until 10 days and rows cannot be deleted until 15 days that they were inserted.

SQL> CREATE BLOCKCHAIN TABLE Blockchain_T1 (Col1 NUMBER, Col2 VARCHAR2(48), Col3 DATE)
NO DROP UNTIL 10 DAYS IDLE
NO DELETE UNTIL 15 DAYS AFTER INSERT
HASHING USING "SHA2_512" VERSION "v1"
PARTITION BY RANGE(Col3)
(PARTITION p1 VALUES LESS THAN (TO_DATE('01-31-2022','mm-dd-yyyy')),
PARTITION p2 VALUES LESS THAN (TO_DATE('02-28-2022','mm-dd-yyyy')),
PARTITION p3 VALUES LESS THAN (TO_DATE('03-31-2022','mm-dd-yyyy'))
);

You can query USER_TAB_COLS for Blockchain Table details

SQL> SELECT internal_column_id as colid
column_name
data_type,
data_length,
FROM user_tab_cols
WHERE table_name = 'BLOCKCHAIN_T1'
ORDER BY colid;

COLID COLUMN_NAME DATA_TYPE DATA_LENGTH
---------- ------------------------ ------------------------------ -----------

1 Col1 NUMBER 22
2 Col2_ VARCHAR2(48) 48
3 Col3T DATE 7
4 ORABCTAB_INST_ID$ NUMBER 22
5 ORABCTAB_CHAIN_ID$ NUMBER 22
6 ORABCTAB_SEQ_NUM$ NUMBER 22
7 ORABCTAB_CREATION_TIME$ TIMESTAMP(6) WITH TIME ZONE 13
8 ORABCTAB_USER_NUMBER$ NUMBER 22
9 ORABCTAB_HASH$ RAW 2000
10 ORABCTAB_SIGNATURE$ RAW 2000
11 ORABCTAB_SIGNATURE_ALG$ NUMBER 22
12 ORABCTAB_SIGNATURE_CERT$ RAW 16
13 ORABCTAB_SPARE$ RAW 2000

13 rows selected.

You can query {CDB|DBA|ALL|USER}_BLOCKCHAIN_TABLES views to get information about Blockchain Tables

DROP - The below example drops the table if the table has not modified for retention period defined in the Blockchain creation.

SQL> DROP TABLE Blockchain_T1 PURGE;

It is recommended to use PURGE option when dropping a Blockchain table.

 
Note that Blockchain tables cannot be create the root container and application root container.

 In below example Blockchain_T2 table creation failed as it cannot be created in root container

SQL> CREATE BLOCKCHAIN TABLE Blockchain_T2 (Col4 NUMBER, Col2 VARCHAR2(48), Col3 DATE)
NO DROP UNTIL 10 DAYS IDLE
NO DELETE LOCKED
HASHING USING "SHA2_512" VERSION "v1";

Error report -
ORA-05729: blockchain table cannot be created in root container

ALTER Blockchain Tables : The Blockchain table retention can be modified using ALTER TABLE command

In below example we increased retention for Blockchain_T1 table that it cannot be dropped until table IDLE and no new rows created for 21 days.

SQL> ALTER TABLE Blockchain_T1 NO DROP UNTIL 21 DAYS IDLE;

In below example trying to lower retention for Blockchain_T1 table to 16 and the operation failed as retention value cannot be lowered.

SQL> ALTER TABLE Blockchain_T1 NO DROP UNTIL 16 DAYS IDLE;

Error report -
ORA-05732: retention value cannot be lowered

You can also increase column length but cannot add or drop column in Blockchain tables.
SQL> ALTER TABLE Blockchain_T1 MODIFY (COL2 VARCHAR2(58));

Table BLOCKCHAIN_T1 altered.

ADD column 

SQL> ALTER TABLE Blockchain_T1 ADD (Col4 varchar2(32));

Error report -
ORA-05715: operation not allowed on the blockchain table

DROP column 
SQL> ALTER TABLE Blockchain_T1 DROP column Col2;

Error report -
ORA-05715: operation not allowed on the blockchain table

DDL and DML on Block chain

In below example we are trying to DELETE, TRUNCATE, UPDATE and MOVE the operation not allowed

DELETE Table

SQL> DELETE FROM Blockchain_T1 where Col1 = 1;

Error report -
SQL Error: ORA-05715: operation not allowed on the blockchain table

TRUNCATE Table

SQL> TRUNCATE TABLE Blockchain_T1;

Error report -
ORA-05715: operation not allowed on the blockchain table

UPDATE Table

SQL> UPDATE Blockchain_T1 SET Col2=“Test” WHERE id = 1;

Error report -
SQL Error: ORA-05715: operation not allowed on the blockchain table

DROP TABLE

SQL> DROP TABLE Blockchain_T1;

Error report -
ORA-05723: drop blockchain table BLOCKCHAIN_T1 not allowed

MOVE Table
SQL> ALTER TABLE Blockchain_T1 move tablespace Blockchain_TBS2 ;

Error report -
ORA-05715: operation not allowed on the blockchain table

Pls refer  Restrictions for Blockchain tables for more details.

Thanks & Regards
https://oracleracexpert.com, Oracle ACE

BlockChain Tables in Oracle 21c

Blockchain tables are designed to allow insert operations only, updates and any modifications are not allowed, and delete operations are restricted. The rows are organized into chains by storing previous row’s hash values in the current row and chain of rows is verifiable by all participants.

Oracle 19c introduced Immutable tables concept, that provides protection against unauthorized data modifications. The blockchain tables concept introduced in Oracle 21c and can be backported to 19c using a patch 32431413, but COMPATIBLE parameter must be set to 19.10.0 or late.

These tables are useful to implement Blockchain applications to handle tamper-resistant blockchain transactions with verifiable crypto-secure data management practices. The blockchain tables prevent unauthorized changes or deletion by criminals, hackers and fraud and protect critical company data. Blockchain tables has hidden columns as well and these values are managed by the database.

Blockchain tables and regular tables can be used in queries and transactions, also you can create indexes and partitions.

Blockchain tables hidden columns

Column Name	Data Type	Description
ORABCTAB_INST_ID$	NUMBER (22)	Instance ID of the database instance into which the row is inserted.
ORABCTAB_CHAIN_ID$	NUMBER (22)	Chain ID of the chain, in the database instance, into which the row is inserted.  0 through 31 are valid values.
ORABCTAB_SEQ_NUM$	NUMBER(22)	Sequence number of the row on the chain
ORABCTAB_CREATION_TIME$	TIMESTAMP WITH TIME ZONE	Row created time in UTC format
ORABCTAB_USER_NUMBER$	NUMBER (22)	Database User ID who inserted the row.
ORABCTAB_HASH$	RAW(2000)	Hash value of the row
ORABCTAB_SIGNATURE$	RAW(2000)	User signature of the row
ORABCTAB_SIGNATURE_ALG$	NUMBER(22)	Signature algorithm used to produce the user signature of a signed row.
ORABCTAB_SIGNATURE_CERT$	RAW(16)	GUID of the certificate associated with the signature on a signed row.
ORABCTAB_SPARE$	RAW(2000)	Reserved for future use.

Important Guidelines for Blockchain Tables

• In case of Oracle RAC instance, a block chain table contains 32 chains and chain will have unique combination of instance ID and chain ID. It is recommended to create index on the combination of Instance ID, chain ID and sequence number.

• The SHA2-512 hashing algorithm used to handle hash value

• In case Oracle Data Guard, to avoid data loss consider using Maximum availability or Maximum protection mode

• To specify retention period for Blockchain table use “NO DROP” Clause in the CREATE BLOCKCHAIN TABLE statement to specify retention period.

• To specify retention period for rows in Blockchain table use “NO DELETE” Clause in the CREATE BLOCKCHAIN TABLE statement to specify retention period for rows

Restrictions for Blockchain tables

• There are many restrictions when using blockchain tables

• Many datatypes are not supported such as nested table , varray, REF , ROWID, UROWID, LONG, object type, BFILE, XMLType , , , TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE

• Point-in-time recovery or flashback database will undo changes on all database objects including blockchain tables.

• Blockchain Retention policies depends on system time and any changes to systems time must be audited.

• Max number of user column allowed are 980

• Blockchain tables doesn’t allow or support below operations

Column level restrictions

o Adding, dropping, and renaming columns

o Dropping partitions

Row level restrictions

o Update or merge rows

o Defining BEFORE ROW triggers that fire for update operations are not allowed.

Table level restrictions

o Truncate table

o Inserting data using parallel DML

o Sharded tables

o During distributed transactions, Inserting data into a blockchain table using Active Data Guard DML redirection is not supported

o Direct-path loading

o Flashback table

o Cannot convert a regular table to a blockchain table or vice versa.

o XA transactions

Database level restrictions

o Export and Import can be done as regular tables, without the system-generated hidden columns.

o Creating blockchain tables in CDB or application root

o Creating Oracle Label Security (OLS) policies

o Using the DBMS_REDEFINITION package for Online redefinition

o Creating Oracle Virtual Private Database (VPD) policies

o When using Transient Logical Standby and rolling upgrades, the DDL and DML on blockchain tables are not replicated and supported

o when using Logical Standby and Oracle GoldenGate, the DDL and DML on blockchain tables succeed on the primary database but are not replicated to standby databases

o Creating Automatic Data Optimization (ADO) policies

Thanks & Regards

https://oracleracexpert.com, Oracle ACE

DBMS_BLOCKCHAIN_TABLE package in Oracle 21c

You can use DBMS_BLOCKCHAIN_TABLE package for maintenance of blockchain table. Using this package you can perform the below tasks.

• Sing a row that is added into the table
• Verify the integrity of rows and hash column.
• Generate signature and signed digest
• Delete rows in a blockchain table that are beyond retention defined.

Here are the few subprograms (procedures and functions) used with DBMS_BLOCKCHAIN_TABLE package

• DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS By using this procedure you can verify the integrity of rows and hash column. You can also verify the Signatures as well

DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS(
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
low_timestamp IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,
high_timestamp IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,
instance_id IN NUMBER DEFAULT NULL,
chain_id IN NUMBER DEFAULT NULL,
number_of_rows_verified OUT NUMBER,
verify_signature IN BOOLEAN DEFAULT TRUE);

For ex:-

DECLARE

Rows_Verify NUMBER;
DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS(
schema_name => 'BCUSER',
table_name => 'BLOCKCHAIN_T1',
number_of_rows_verified => Rows_Verify);
DBMS_OUTPUT.PUT_LINE(TO_CHAR(Rows_Verify) || ' rows deleted');
END;
/

• DBMS_BLOCKCHAIN_TABLE.GET_SIGNED_BLOCKCHAIN_DIGEST – By using this procedure you can generate a signature and signed digest.

DBMS_BLOCKCHAIN_TABLE.GET_SIGNED_BLOCKCHAIN_DIGEST(
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
signed_bytes IN OUT BLOB,
signed_rows_indexes OUT ORABCTAB_ROW_ARRAY_T,
schema_certificate_guid OUT RAW,
signature_algo IN NUMBER default SIGN_ALGO_DEFAULT)
RETURN RAW;

• DBMS_BLOCKCHAIN_TABLE.VERIFY_TABLE_BLOCKCHAIN - By using this procedure you can verify the integrity of rows created between specified time period X1 and X2

DBMS_BLOCKCHAIN_TABLE.VERIFY_TABLE_BLOCKCHAIN(

signed_bytes_latest IN BLOB,

signed_bytes_previous IN BLOB,

number_of_rows_verified OUT NUMBER);

• DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWS - By using this procedure you can delete rows that are beyond retention period

For ex:-

DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWS(

schema_name IN VARCHAR2,

table_name IN VARCHAR2,

before_timestamp IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,

number_of_rows_deleted OUT NUMBER);

Ex:- The below example deletes the rows beyond the retention period, you can limit the number of rows deletion by using before_timestamp

DECLARE

Del_Rows NUMBER;

DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWS(

schema_name => 'BCUSER',

table_name => 'BLOCKCHAIN_T1',

before_timestamp => NULL,

number_of_rows_deleted => Del_Rows);

DBMS_OUTPUT.PUT_LINE(TO_CHAR(Del_Rows) || ' rows deleted');

END;

/

• DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_SIGNATURE - By using this procedure you can determine the data format for row content to compute the signature.

DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_SIGNATURE(

schema_name IN VARCHAR2,

table_name IN VARCHAR2,

instance_id IN NUMBER,

chain_id IN NUMBER,

sequence_id IN NUMBER,

data_format IN NUMBER,

row_data IN OUT BLOB);

• DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_HASH - By using this procedure you can determine the data format for row content to compute hash value

DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_HASH(

schema_name IN VARCHAR2,

table_name IN VARCHAR2,

instance_id IN NUMBER,

chain_id IN NUMBER,

sequence_id IN NUMBER,

data_format IN NUMBER,

row_data IN OUT BLOB);

• DBMS_BLOCKCHAIN_TABLE.SIGN_ROW – By using this procedure you can add a signature to an existing row.

DBMS_BLOCKCHAIN_TABLE.SIGN_ROW(

schema_name IN VARCHAR2,

table_name IN VARCHAR2,

instance_id IN NUMBER,

chain_id IN NUMBER,

sequence_id IN NUMBER,

hash IN RAW DEFAULT NULL,

signature IN RAW,

certificate_guid IN RAW,

signature_algo IN NUMBER);

• DBMS_BLOCKCHAIN_TABLE.SIGN_ALGO_RSA_SHA2_512 - – By using this procedure you can validate a signature using specific digital certificate and signature algorithm. Note that Blockchain tables support only DER encoding or X.509 certificates

• Note that DBMS_CRYPTO.HASH function can be used to compute hash value

Blockchain Data byte values:

By using DBMS_TABLE_DATEA package you can get the byte values of row, column

• DBMS_TABLE_DATA.GET_BYTES_FOR_COLUMN - By using this procedure column data in bytes
• DBMS_TABLE_DATA.GET_BYTES_FOR_COLUMNS By using this procedure column data in bytes for set of columns
• DBMS_TABLE_DATA.GET_BYTES_FOR_ROW By using this procedure row data in bytes.

Thanks & Regards
https://oracleracexpert.com, Oracle ACE