Friday, 20 February 2026

OS upgrade on OCI Oracle DB system in Base Database service using OCI console


OS upgrade on OCI Oracle DB system in Base Database service using OCI console

 

Pre check


1) Before applying, run a "Precheck" to ensure prerequisites are met and ensure that no 3rd party modules/softwares are no installed

2) Back up the database in the DB system prior to attempting an OS update.

3) Do not remove packages from a DB system. However, you might have to remove custom RPMs (packages that were installed after the system was provisioned) for the update to complete successfully.

4) Oracle recommends that you test any updates thoroughly on a non-production system before updating a production system.

5) The image used to launch a DB system is updated regularly with the necessary updates. After you launch a DB system, you are responsible for applying the required OS security updates published through the Oracle public YUM server.

5) To apply OS updates, the virtual cloud network (VCN) in the DB system must be configured to allow access to the YUM repository. For more information, see VCN and Subnets.

Steps

  1. On the DB Systems list page, select the DB system that you want to work with. If you need help finding the list page or the DB system, see List the DB Systems.
  2. On the details page, select the Updates (OS) tab to view the list of available OS upgrades for the DB system.
  3. From the Actions menu for the upgrade you are interested in, select one of the following actions:
    • View details: View the details about this upgrade.
    • Precheck: Check for any prerequisites to ensure that the upgrade can be successfully applied.
    • Apply update: Applies the selected upgrade. Oracle recommends that you run the precheck operation for an upgrade before applying it.


Please refer below doc


https://docs.oracle.com/en/cloud/paas/base-database/update-dbcli/#articletitle

https://docs.oracle.com/en/cloud/paas/base-database/upgrade-dbs/#GUID-5B5D2ED6-5865-489E-BA20-A9E492C7CA12
 

Thursday, 19 February 2026

how to fix opc user expiry issue in base database service for oracle@Azure

Environment: It is oracle@Azure and base database service provisioned 


if OPC user password has been expired and you need to follow below step to fix this issue.


In Step 1, I'm sharing Oracle Doc to login into your instance in rescue mode. Once you login into rescue mode. Then need to execute other command to fix password expiration issue in Step 2 and Step 3.


Step 1

=====

Video Form

=======

1) OCI Compute - How To Reset Forgotten Root Password Using Serial Console For Oracle Linux 7, 8, and 9 [Video] KB101078


URL : fa-etmi-saasfaprod1.fa.ocs.oraclecloud.com/fscmUI/redwood/myknowledge/content/container/main/article?answerId=2940603


Oracle Document

============

OCI: How To Reset Forgotten Root Password Using Serial Console For Oracle Linux 6, 7, 8, and 9 Instances (Doc ID 2489923.1)

URL - mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=196232300826152&id=2489923.1&_afrWindowMode=0&_adf.ctrl-state=uu8heermb_841


Above video is for password reset. Though, you don't need to do password reset. Just eecute below command in Step 2 to fix opc user expiration issue.


Step 2

=====

Once you're login into rescue mode then execute below commands.

# chage -l opc (Check the status of password expiration.)


If it's expired then set it to never

# chage -m 0 -M 99999 -I -1 -E -1 opc

# chage -l opc


Output should like below output once it set to never expire password.

Last password change : 

Password expires : never

Password inactive : never

Account expires : never

Minimum number of days between password change : 0

Maximum number of days between password change : 99999

Number of days of warning before password expires : 7


Step 3

====

If it's OL 8 then run below command as mentioned in Oracle doc step 1. Check if SELinux is enabled then run below SELinux command.


Force an SELinux relable.

bash-4.4# touch /.autorelabel

bash-4.4#

When ready, resume normal bootup.


bash-4.4# sync

bash-4.4#

bash-4.4# sync

bash-4.4#

bash-4.4# exec /usr/sbin/init


A> Reboot the broken node from the OCI console (Not Stop And Start)

B> The serial console will show you the boot process.

C> Interrupt the boot process when prompted "Press any key"

D> Enter the Grub menu, 'e' to edit , select the like starting with "kernel", 'e' to edit , add "init=/bin/bash" at the end of the line:

++ Scroll down to the last line, which starts with initrdefi.

++ Press the left arrow key to get to the end of the long, wrapped line that starts with linuxefi.

++ Press the space bar then add init=/bin/bash to the end of the line

++ Press Crtl-x to start the instance.

** Important **

For troubleshooting ssh connectivity issues, if grub asks for password, below values may be provided:

Username: root

Password: grub######


eg

we could successfully change the password of OPC User as below

you should have correct root Password for editing the boot menu.

we append init=bin/bash

it is importatant to remount,rw / then it is possible to set a new password for opc and logon 

[root@vmlhmdbc002 /]# cp /etc/shadow /etc/shadow.0

cp: cannot create regular file '/etc/shadow.0': Read-only file system

[root@vmlhmdbc002 /]# mount -o remount,rw /

[root@vmlhmdbc002 /]# cp /etc/shadow /etc/shadow.0

 

[root@vmlhmdbc002 /]# passwd opc

Changing password for user opc.

New password: 

Retype new password: 

passwd: all authentication tokens updated successfully.

 

[root@vmlhmdbc002 /]# touch /.autorelabel

[root@vmlhmdbc002 /]# sync

[root@vmlhmdbc002 /]# sync

[root@vmlhmdbc002 /]# exec /usr/sbin/init


Test:

ssh -i key_orabasec001.pem opc@vmleasyc002.ocidefault.ocieasyadbba.oraclevcn.com

[opc@vmleasyc002 ~]$ whoami

opc

opc@vmleasyc002 ~]$  chage -l opc

Last password change                                    : Feb 18, 2026

Password expires                                        : never

Password inactive                                       : never

Account expires                                         : never

Minimum number of days between password change          : 0

Maximum number of days between password change          : 99999

Number of days of warning before password expires       : 7

 

Sharing couple of Oracle Docs. Please follow below Oracle docs to attach boot volume to another instance and fix OPC password issue.

Note : Take a backup of impacted node prior to do any activity for safer side.

1) How to Reset the Password on OCI Oracle Linux Instances?

KB114663

URL: fa-etmi-saasfaprod1.fa.ocs.oraclecloud.com/fscmUI/redwood/myknowledge/content/container/main/article?answerId=2408898

2) OPC password expired in OCICKB31429

URL : fa-etmi-saasfaprod1.fa.ocs.oraclecloud.com/fscmUI/redwood/myknowledge/content/container/main/article?answerId=2510982


Wednesday, 18 February 2026

How to check/apply patches in OCI DB System (Base Database/DB System)


 You cannot apply an RU until it is published for your database in the OCI Console. Manual patching is not supported and recommended in Base Database Service

Oracle releases RUs quarterly. For Oracle Base Database (OCI managed), there is a standard qualification lag before an RU appears in the Console; you cannot manually apply it before Oracle publishes it for your db system

Best practices to apply patch to minimize downtime

On production Environment

1) apply patch on GI on standby database if applicable 

2) perform switchover and apply patch on GI on new standby

3) apply patch on db home on standby database

4) perform switchover and apply patch on db home on new standby

5) complete validation


- How to check/apply patches in OCI (Base Database/DB System)

- Use the OCI Console:

- For DB Systems (Grid Infrastructure / Database): docs.oracle.com/en/cloud/paas/base-database/update-dbs/

- For Database homes/databases: docs.oracle.com/en/cloud/paas/base-database/update-db/

- In the Console, navigate to your database or DB system, open the Patching/Updates page,

   review the Available updates, and schedule/apply the RU when the desired version is listed.


Precautions for any patch activity

------------------------------------------------------ 

Patch first in non-production, verify backups/restore, schedule a maintenance window, and review the patch README. Ensure datapatch completes successfully and validate with DBA_REGISTRY_SQLPATCH.

It's strongly recommended to test it non-production environment before implementing on the production database This helps minimize the risk of disruptions, system crashes, and security issues that can arise from untested patches. 


Patch validation

From root user

/opt/oracle/dcs/bin/dbcli describe-component

/opt/oracle/dcs/bin/dbcli   describe-latestpatch

sudo su - grid

$ORACLE_HOME/OPatch/opatch lspatches

$ORACLE_HOME/bin/kfod op=patchlvl

sudo su - oracle

$ORACLE_HOME/OPatch/opatch lspatches

$ORACLE_HOME/bin/kfod op=patchlvl


Output of the following

       - for the CDB:

sqlplus / as sysdba

set markup html on

spool /tmp/CDB.html

show con_name;

show pdbs;

select dbid,name,db_unique_name,open_mode,database_role,switchover_status from v$database;

select comp_id, comp_name, version, status, schema from dba_registry order by status;

select * from dba_registry_sqlpatch order by action_time;

select * from dba_objects where status='INVALID';

select * from v$option order by parameter;

select * from pdb_plug_in_violations;

select message from pdb_plug_in_violations where type like '%ERR%' and status <> 'RESOLVED';

col action_time for a28

col action for a10

col version for a8

col comments for a30

col status for a10

set line 999 pages 999

select patch_id, patch_type,source_version, target_version, status, Action,Action_time from dba_registry_sqlpatch order by action_time;

 

set pages 999

set pagesize 999

 select i.instance_name,

       i.version "Inst Version",

       to_char(h.action_time, 'DD-MON-YYYY HH24:MI:SS') as when,

       h.action,

       h.namespace,

       h.version "Patch Version",

       h.id,

       h.comments,

       h.bundle_series

from   sys.registry$history h,

       v$instance i

order  by h.action_time; 

       spool off

       

       - for the PDB:

       set markup html on

       spool /tmp/PDB.html

       show con_name;

       select comp_id, comp_name, version, status, schema from dba_registry order by status;

       select * from dba_registry_sqlpatch order by action_time;

       select * from dba_objects where status='INVALID';

       select * from v$option;

       spool off




Thursday, 12 February 2026

password has been expired and need to fix this issue in OCI db system for Base Database Service

if  password has been expired and need to fix this issue.

In Step 1, Please login into your instance in rescue mode. Once you login into rescue mode. Then need to execute other command to fix password expiration issue in Step 2 ans Step 3.

Step 1

=====

Video Form

=======

1) OCI Compute - How To Reset Forgotten Root Password Using Serial Console For Oracle Linux 7, 8, and 9 [Video] KB101078

URL : fa-etmi-saasfaprod1.fa.ocs.oraclecloud.com/fscmUI/redwood/myknowledge/content/container/main/article?answerId=2940603


Oracle Document

============

OCI: How To Reset Forgotten Root Password Using Serial Console For Oracle Linux 6, 7, 8, and 9 Instances (Doc ID 2489923.1)

URL - https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=196232300826152&id=2489923.1&_afrWindowMode=0&_adf.ctrl-state=uu8heermb_841


Above video is for password reset. Though, you don't need to do password reset. Just execute below command in Step 2 to fix opc user expiration issue.

Step 2

=====

Once you're login into rescue mode then execute below commands.

# chage -l opc (Check the status of password expiration.)

If it's expired then set it to never

# chage -m 0 -M 99999 -I -1 -E -1 opc

# chage -l opc

Output should like below output once it set to never expire password.

Last password change : 

Password expires : never

Password inactive : never

Account expires : never

Minimum number of days between password change : 0

Maximum number of days between password change : 99999

Number of days of warning before password expires : 7


Step 3

====

If it's OL 8 then run below command as mentioned in Oracle doc step 1. Check if SELinux is enabled then run below SELinux command.

Force an SELinux relable.

bash-4.4# touch /.autorelabel

bash-4.4#

When ready, resume normal bootup.

bash-4.4# sync

bash-4.4#

bash-4.4# sync

bash-4.4#

bash-4.4# exec /usr/sbin/init


Friday, 6 February 2026

bug in DB RU 19.29 and 19.30 (January 2026)


Bug in DB RU 19.29 and 19.30 (January 2026)

Users is experiencing difficulties in downloading the Database Release Update 19.30.0.0.260120 (Patch 38632161) shortly after release.it is known issue and will be available shortly

 Oracle has temporarily withdrawn to download DB RU 19.29 and 19.30 (January 2026) from website

 both 19.29 and 19.30 are currently impacted by a critical bug (Bug 34352668), specifically affecting RAC (Real Application Cluster) environments. due to this bug ,database block and redo log corruption noticed after rolling updates to 19.29 (e.g., RU 19.28 to 19.29) on RAC databases. 

So it is encouraged to apply 19.30 if possible when it is available for download .

New 19.30 DB RU with the proper fix will be released shortly

It is also advised to postpone direct updates to 19.29 till new DB RU release 19.30 published

As a mitigation, set the hidden parameter “_gcs_recoverable_asserts” on any one RAC instance. 

If Oracle Data Guard is in use, apply this setting on both the primary and standby databases.


Recommendation: Oracle has temporarily paused the release of 19.30 and advises against applying 19.29 or 19.30 in RAC environments until a new patched version is available.

This issue does not affect the following:

Single instance RAC databases

Non-RAC databases

Clusterware or ASM instances

To check for lock state consistency across all instances

Please run below command

SQL> select sum(value) from gv$ges_statistics where name like 'number of triggered LSRs%';

Please verify fixes are in-place 

opatch lsinventory -bugs_fixed | egrep '^(34352668|38854064|38884142)'

To mitigate the issue, run the following SQL on any one RAC instance. 

If you use Oracle Data Guard, run these on both the primary and the standby databases.

Note : Downtime is not required 

SQL> ALTER SYSTEM SET "_gcs_recoverable_asserts" = 3 SCOPE = BOTH SID = '*';

SQL> ALTER SYSTEM RESET "_gcs_recoverable_asserts" SCOPE = BOTH SID = '*';


Please verify as below


SELECT

   a.ksppinm AS parameter,

   b.ksppstvl AS value,

   b.ksppstdf AS is_default,

   a.ksppdesc AS description

FROM

   x$ksppi a,

   x$ksppcv b

WHERE a.indx = b.indx AND a.ksppinm = '_gcs_recoverable_asserts';


Please verify fixes are in-place 

opatch lsinventory -bugs_fixed | egrep '^(34352668|38854064|38884142)'


Oracle Database 19c Proactive Patch Information (MOS KM Doc ID 2521164.1) - R19c Database Release Update Revision (Revision)
Critical Patch Update (CPU) Program Jan 2025 Patch Availability Document (DB-only) (MOS KM Doc ID KB160593) - DETAILS
Oracle Database 19c Release Update January 2025 Known Issues (MOS KM Doc ID 19202501.9) - Purpose
Oracle Database 19c Release Update January 2025 Known Issues (MOS KM Doc ID 3113613.1) - Purpose
Critical Patch Update (CPU) Program Apr 2025 Patch Availability Document (DB-only) (MOS KM Doc ID 3070732.1) - 6 Modification History
[OCI]: Primary Note For Oracle Database Cloud Service In OCI (Oracle Cloud Infrastructure) Environment (MOS KM Doc ID KB33189) - Database Patching
Oracle Database 19c Release Update January 2024 Known Issues (MOS KM Doc ID 19202401.9) - Purpose
Oracle Database 19c Release Update January 2024 Known Issues (MOS KM Doc ID 3113605.1) - Purpose

Tuesday, 3 February 2026

DBaaS/DBCS: 19c: January 2026 patches 19.30.0.0.0 -OCI Oracle db system in base database service


DBaaS/DBCS: 19c: January 2026 patches 19.30.0.0.0  -OCI Oracle db system in base database service

There is no announced ETA  for 19c: January 2026 patches 19.30.0.0.0  in OCI Oracle db system in base database service
OCI patch images typically appear about 2–4 weeks after the quarterly release, and any delay/ETA will be posted in the quarter’s Database PAD.

To track availability for OCI Oracle db systems, check the OCI Console Patching page or run dbcli describe-component on the DB system

you can find patching detail below

Oracle Database 19c Proactive Patch Information (MOS KM Doc ID 2521164.1) - R19c Database Release Update Revision (Revision)

Critical Patch Update (CPU) Program Jan 2025 Patch Availability Document (DB-only) (MOS KM Doc ID KB160593) - DETAILS

Oracle Database 19c Release Update January 2025 Known Issues (MOS KM Doc ID 19202501.9) - Purpose

Oracle Database 19c Release Update January 2025 Known Issues (MOS KM Doc ID 3113613.1) - Purpose

Critical Patch Update (CPU) Program Apr 2025 Patch Availability Document (DB-only) (MOS KM Doc ID 3070732.1) - 6 Modification History

[OCI]: Primary Note For Oracle Database Cloud Service In OCI (Oracle Cloud Infrastructure) Environment (MOS KM Doc ID KB33189) - Database Patching

Oracle Database 19c Release Update January 2024 Known Issues (MOS KM Doc ID 19202401.9) - Purpose

Oracle Database 19c Release Update January 2024 Known Issues (MOS KM Doc ID 3113605.1) - Purpose

Friday, 30 January 2026

Steps to fix a lost Transparent Data Encryption (TDE) wallet password in an OCI Base Database Service system



 Steps to fix a lost Transparent Data Encryption (TDE) wallet password in an OCI Base Database Service system


Note : Ideally the TDE wallet password is the same as SYS password when you first provision the DB system.


To fix a lost Transparent Data Encryption (TDE) wallet password in an OCI Base Database Service system, Please use the OCI Console to update the password directly

Steps to Fix Lost TDE Wallet Password

----------------------------------------

The option is provided to change the TDE password, when you already know the existing password

Using OCI Console (Recommended)

Go to the Oracle Cloud Infrastructure (OCI) Console.

Navigate to the DB system and select the specific database.

Select Manage passwords from the Actions menu.

Select Update TDE wallet password.

Enter a new password. 


Plan b

If you do not have the old TDE wallet password and auto-login wallet is available

you need to verify existing password and merge the existing keystore into newly created empty wallet

Recovery Steps (if auto-login wallet is available)


Please follow these steps

1) Determine the TDE wallet location on the source

- Login to the source DB host as oracle.

- Find the wallet directory from sqlnet.ora:

  cat $ORACLE_HOME/network/admin/sqlnet.ora | grep ENCRYPTION_WALLET_LOCATION

- On OCI DB Systems the wallet is typically under:

 /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME

- If needed, get db_unique_name:

sqlplus "/ as sysdba"

show parameter db_unique_name


2) Verify candidate passwords against the wallet

 

- Using orapki (prompts for the wallet password):

orapki wallet display -wallet /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/ewallet.p12 -summary

- Or using mkstore (also prompts for the password):

mkstore -wrl /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME -list

- If the password is correct, the wallet contents (master key info) will display. If incorrect, you will get a PKI/“incorrect password” error


3) Merge the existing keystore into newly created empty wallet

>>Create a backup of your current wallet

>> SELECT wrl_type, wrl_parameter, status, wallet_type FROM V$ENCRYPTION_WALLET;

As AUTOLOGIN is Yes, you can merge the wallet, please follow these steps.

a. Create a new empty wallet at some other location than the original wallet.

SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '<New location for wallet>' IDENTIFIED BY <any wallet password>;

b. Merge the existing keystore into newly created empty wallet. Here for the first Keystore there is no need to specify the password as it's Auto-Login.

SQL> ADMINISTER KEY MANAGEMENT MERGE KEYSTORE '<Original Keystore location>' INTO EXISTING KEYSTORE '<Newly created wallet location>' IDENTIFIED BY <Newly created wallet password> WITH BACKUP;

c. Create an Auto-Login wallet for this Merged Keystore.

NOTE: Here the location of the Merged wallet needs to be specified i.e. the location of newly created wallet

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '<Newly created wallet location>' IDENTIFIED BY <Newly created wallet password>;

d. At this point test this newly Merged wallet by modifying the wallet location in sqlnet.ora file to point to this new wallet.

$ cat <Directory>/sqlnet.ora

ENCRYPTION_WALLET_LOCATION=

(SOURCE = (METHOD = FILE)

(METHOD_DATA =

(DIRECTORY = <Merged Wallet location>))) ------ Pointing to newly Merged wallet

SQL> select * from v$encryption_wallet;

e. If the wallet is open and the database is accessible, Copy the wallet files to the default location (after taking a backup of it) and correct the path in sqlnet.ora file.


Reference: Quick TDE Setup and FAQ (Doc ID 1251597.1)

TDE Recovery Scenarios (Doc ID 3011213.1) >> It describes all the different scenarios

Primary Note For Transparent Data Encryption ( TDE ) (Doc ID 1228046.1) 

https://docs.oracle.com/en/database/oracle/oracle-database/21/asoag/managing-keystore-and-tde-master-encryption-key.html


If No Auto-Login Wallet Exists

-------------------------------

If no auto-login wallet file (cwallet.sso) is available for the old wallet, and the password for the ewallet.p12 file is lost/damaged, the encrypted data cannot be accessed, it may not be possible to open the wallet. 

In this scenario, you must restore the ewallet.p12 file from a previous backup to a time when the password was known. 

if the wallet merge steps fail, creating a new OCI Database System (DB System) from an automatic backup is the primary recovery path, provided automatic backups are enabled and the wallet is in AUTOLOGIN status. 

Create a DB System from a Backup

https://docs.oracle.com/en/cloud/paas/base-database/create-dbs-from-backup/index.html#articletitle


Regards

thanks you