Friday, January 26, 2024

How to find installed patches through SQL in an EBS database

During an EBS upgrade, I had to check whether or not a specific patch, 8796558, still needed to be applied.
Turned out is no longer relevant; it has been rolled up in cummulative patch sets. See listing below.
set lines 200
col patch_name format a30
 
SELECT DISTINCT a.bug_number,e.patch_name, e.patch_type, TRUNC(c.end_date) applied_Date
FROM ad_bugs a, ad_patch_run_bugs b, ad_patch_runs c, ad_patch_drivers d , ad_applied_patches e
WHERE
a.bug_id = b.bug_id AND
b.patch_run_id = c.patch_run_id AND
c.patch_driver_id = d.patch_driver_id AND
d.applied_patch_id = e.applied_patch_id AND
a.bug_number in
('8796558')
ORDER BY 2 DESC;
 
BUG_NUMBER                     PATCH_NAME                     PATCH_TYPE                     APPLIED_DATE
------------------------------ ------------------------------ ------------------------------ ------------
8796558                        22644544                       PATCH-SET                      04-SEP-19  
8796558                        21236633                       PATCH-SET                      27-MAI-16  
8796558                        19030202                       PATCH-SET                      15-DES-15  
8796558                        17774755                       PATCH-SET                      11-OKT-14  
 
22644544 --> Oracle E-Business Suite Release 12.1.3+ Recommended Patch Collection 5 [RPC5]
21236633 --> Oracle E-Business Suite Release 12.1.3+ Recommended Patch Collection 4 [RPC4]
19030202 --> Oracle E-Business Suite Release 12.1.3+ Recommended Patch Collection 2 [RPC2]
17774755 --> Oracle E-Business Suite Release 12.1.3+ Recommended Patch Collection 1 [RPC1]

[DBT-50000] Unable to check available system memory when running dbca

dbca returned the following error upon launch:
[FATAL] [DBT-50000] Unable to check available system memory.
   CAUSE: An exception occured while checking kernel parameter.
*ADDITIONAL INFORMATION:*
Exception details
 - The default location for framework home is not available. It must be specified
Cause:

The TMP and/or TMPDIR directory doesn't exist.

Solution:

Make sure the .bash_profile contains the correct values for the TMP and TMPDIR directories. It must be an accessible and writable directory.

In my case:

mkdir -p /u01/ora19c/tmp
Open .bash_profile, and add the following
OWNER=ora19c;export OWNER
TMP=/u01/$OWNER/tmp;export TMP
TMPDIR=/u01/$OWNER/tmp;export TMPDIR
Launch dbca again. It should now proceed as expected.

This article from IBM pointed me in the right direction.

Doc ID 2534894.1 "How To Change Default TEMP Location When Creating Database By DBCA?" is also onto the same solution, but here oracle show you how to append the -j flag to your dbca command, e.g

 dbca -J-Djava.io.tmpdir=/home/oracle/tmp

Friday, January 12, 2024

Syntax for dropping standby redo logs

In one of my primary databases, I had several old standby redo log files that were forgotten from a previous relocation using Data Guard. They could all be dropped at this point.

set lines 200
col member format a50
select s.group#,s.thread#,s.sequence#,s.archived,s.status,f.member, f.type
from v$standby_log s, v$logfile f
where f.type = 'STANDBY'
and s.group# = f.group#;

    GROUP#    THREAD#  SEQUENCE# ARC STATUS     MEMBER                                             TYPE
---------- ---------- ---------- --- ---------- -------------------------------------------------- -------
         6          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo06.log         STANDBY
         7          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo07.log         STANDBY
         8          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo08.log         STANDBY
         9          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo09.log         STANDBY
        10          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo10.log         STANDBY
        11          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo11.log         STANDBY
Syntax for dropping:
SQL> alter database drop standby logfile group n;
In my case
alter database drop standby logfile group 6;
alter database drop standby logfile group 7;
etc etc.


The official Oracle 19c Alter Database documentation is here

Wednesday, January 3, 2024

Workaround for error adstpall.sh: too few arguments specified when stopping the EBS 12.2 server processes

ebs@ebsserver1.oric.no 35642926]$ $ADMIN_SCRIPTS_HOME/adstpall.sh –skipNM -skipAdmin
 
You are running adstpall.sh version 120.22.12020000.7
 
 
Enter the WebLogic Server password:
adstpall.sh: too few arguments specified.
 
USAGE:  adstpall.sh  [-skipNM] [-skipAdmin] [-nothreading]
        adstpall.sh  -secureapps [-skipNM] [-skipAdmin]
        adstpall.sh -nodbchk [-skipNM] [-skipAdmin]
        adstpall.sh -mode=allnodes
 
 
adstpall.sh: exiting with status 1
Reason: You have copied the text directly from step 5 in the documentation

Turns out the docs use a different dash character than the expected one. The one used in the documentation is most likely copied from MS word or similar, which is interpreted differently than the regular dash character:
  • Incorrect: –skipNM
  • Correct: -skipNM
  • In other words, the documented command below is incorrect:
    $ $ADMIN_SCRIPTS_HOME/adstpall.sh skipNM -skipAdmin
    
    Workaround: execute it with the correct dash
    $ $ADMIN_SCRIPTS_HOME/adstpall.sh -skipNM -skipAdmin
    
    Thanks to Marco DeDecker from Oracle Netherlands for finding and pointing out this error.

    Monday, December 11, 2023

    How to write custom messages to the alert log file

    exec sys.dbms_system.ksdwrt(2,'Your message here')
    
    The first argument can be either

  • 1 -> Write to the trace file
  • 2 -> Write to the database alert log file
  • 3 -> Write to both of the above files
  • Friday, December 8, 2023

    Syntax for applying and removing a patch on the WLS server Home in an EBS 12.2 installation

    The bsu (or "Smart update") utility:
    cd $MW_HOME/utils/bsu
    bsu.sh -version
    Oracle Smart Update. Version: 3.3.0.0
    
    Here's an example on how to install a patch:
    ./bsu.sh -remove -patch_download_dir=$MW_HOME/utils/bsu/cache_dir -patchlist=1LRI -prod_dir=$MW_HOME/wlserver_10.3 -verbose -log=install_1LRI.log
    
    Here's an example on how to remove a patch:
    ./bsu.sh -install -patch_download_dir=$MW_HOME/utils/bsu/cache_dir -patchlist=E7HI -prod_dir=$MW_HOME/wlserver_10.3 -verbose -log=install_E7HI.log
    

    Script sniplet to differentiate between cdb and pdb environment settings in a shell script

    This little sniplet could be used if you find yourself in a situation where you need to differentiate between the cdb environment and the pdb environment on a server using multitenant setup.

    I am setting a commonly used alias for the usage of sqlplus called "sql" depending on the ORACLE_SID being set to the cdb or the pdb.

    It differs slightly since I you can only do a bequath session when connecting to the former, and not the latter:

  • When connecting to the pdb as sysdba, you need to go through the listener, and therefore supply the password.
  • When connecting to the cdb you can do a so called bequeath session and connect directly to the oracle instance through IPC.
    read -p 'Will you be administrating the cdb or the PDB? ' container
    case $container in
            CDB|cdb)
            . $ORACLE_HOME/cdb_settings.env;
            alias sql='sqlplus / as sysdba';;
            PDB1|pdb1)
            . $ORACLE_HOME/pdb1.env;
            alias sql='sqlplus sys@pdb1 as sysdba';;
            *) echo "You must select cdb or pdb1";
             exit 1;;
    esac