OPatch 12.2.0.1.37+ führt neue Funktion zum Löschen inaktiver Patches ein

spaHinterlasse einen Kommentar

Mit der OPatch Version 12.2.0.1.37 führt Oracle eine neue Funktion zum Löschen inaktiver Patches im Verzeichnis ORACLE_HOME/.patch_storage ein.

Was steckt genau dahinter?

OPatch sichert die Historie des Patchens im Verzeichnis „.patch_storage“. Im Laufe der Zeit werden immer mehr Patches installiert und angewendet. Somit wird immer mehr Platz im Verzeichnis „.patch_storage“ belegt. Dies führt zwangsläufig dazu, dass die Patching Aktivitäten immer längere Laufzeiten haben.

Mit der oben genannten OPatch Version wurden nun aus meiner Sicht eine sehr wichtige Funktion eingeführt, die erlaubt die Patch Historie übersichtlich zu halten und die Performance des Patchens deutlich zu verbessern.

Die Funktionen im Einzelnen:

Auflisten inaktiver Patches

  • ORACLE_HOME/OPatch/opatch util ListOrderedInactivePatches

Beispiel:

opatch util ListOrderedInactivePatches

Oracle Interim Patch Installer version 12.2.0.1.37

Copyright (c) 2023, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/19.0.0.0/dbhome_1

Central Inventory : /u01/app/oraInventory

   from           : /u01/app/oracle/product/19.0.0.0/dbhome_1/oraInst.loc

OPatch version    : 12.2.0.1.37

OUI version       : 12.2.0.7.0

Invoking utility "listorderedinactivepatches"

List Inactive patches option provided

The oracle home has the following inactive patch(es) and their respective overlay patches:

-Inactive RU/CPU 32218454, installed on: Wed Mar 24 17:38:40 CET 2021, with overlays: 32301133

-Inactive RU/CPU 32545013, installed on: Fri Apr 23 11:27:36 CEST 2021, with no overlays

-Inactive RU/CPU 32904851, installed on: Tue Oct 12 11:03:38 CEST 2021, with no overlays

-Inactive RU/CPU 29517242, installed on: Thu Apr 18 09:21:17 CEST 2019, with no overlays

-Inactive RU/CPU 33192793, installed on: Tue Nov 09 11:22:44 CET 2021, with no overlays

-Inactive RU/CPU 32067171, installed on: Wed Mar 24 17:40:15 CET 2021, with no overlays

-Inactive RU/CPU 32222571, installed on: Wed Mar 24 17:37:53 CET 2021, with no overlays

-Inactive RU/CPU 32876380, installed on: Tue Oct 12 11:12:35 CEST 2021, with no overlays

-Inactive RU/CPU 33192694, installed on: Tue Nov 09 11:39:50 CET 2021, with no overlays

-Inactive RU/CPU 33815596, installed on: Wed May 11 14:23:08 CEST 2022, with no overlays

Total: 10 inactive RU/CPU patch(es) and 1 inactive overlay patch(es).

Löschen inaktiver Patches

  • ORACLE_HOME/OPatch/opatch util deleteinactivepatches

Empfehlung:

Das Löschen inaktiver Patches muss vor dem eigentlichen Patching durchgeführt werden.

Fazit:

Durch Einführung dieser neuen Funktion ist die Laufzeit des eigentlichen Patchvorgangs auch bei zukünftigen Aktionen konstant schnell.

Werbung

Setup a new out-of-place ORACLE_HOME

spaHinterlasse einen Kommentar

For all who want to start in a new project with an „out-of-place“ Installation I describe here how easy it is to setup a new ORACLE_HOME from scratch.

It is also the recommendation for all activities as Patching with an Release Update (RU) etc..

Last but not least we know from the daily work that often Developers came up and ask to install a OneOff Patch because it fixes an important Bug and they would like to test if the OneOff will fix the problem before doing it in a Production environment.

Okay, let’s start. (The base Software Download will not described)

I explained this while doing it on a Exadata Machine and therefore you see the „dcli“ command which is part of a Exadata Setup.

# Setup new DB Home in a Exadata environment
# dcli is used to do it on all Cluster Nodes
# Installation from Base is recommended

export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_2
mkdir -p ${ORACLE_HOME}
unzip -q /tmp/LINUX.X64_193000_db_home.zip -d ${ORACLE_HOME}
unzip -q -o /tmp/patches/opatch/12.2.0.1.33/p6880880_190000_Linux-x86-64.zip -d ${ORACLE_HOME}
dcli -g ~/dbs_group -l root "mkdir -p ${ORACLE_HOME} && chown -R oracle:oinstall ${ORACLE_HOME}"
 
# provide GRID RU System Combo Patch (including OJVM)

mkdir -p /u01/patches/RU19.15
unzip -q -o /tmp/patches/grid/RU19.15/p33859214_190000_Linux-x86-64.zip -d /u01/patches/RU19.15
chown -R oracle:oinstall /u01/patches/RU19.15
 
# Apply RU
# Ignore Error "INS-32013"
su oracle -c "${ORACLE_HOME}/runInstaller -silent -applyRU /u01/patches/RU19.15/33859214/33803476"
  
# If required - Apply OJVM
su - oracle
export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_2
${ORACLE_HOME}/oui/bin/runInstaller -silent -attachHome ORACLE_HOME=${ORACLE_HOME} ORACLE_HOME_NAME="OraDB19Home2"
${ORACLE_HOME}/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph /u01/patches/RU19.15/33859214/33808367
${ORACLE_HOME}/OPatch/opatch apply /u01/patches/RU19.15/33859214/33808367
${ORACLE_HOME}/OPatch/opatch lspatches
${ORACLE_HOME}/oui/bin/runInstaller -silent -detachHome ORACLE_HOME=${ORACLE_HOME} ORACLE_HOME_NAME="OraDB19Home2"
  
# Deploy and register new home
su - oracle
export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_2
export CLUSTER_NODES="$(`grep ^crs_home /etc/oracle/olr.loc | cut -d= -f2`/bin/olsnodes | sed -e 'H;${x;s/\n/,/g;s/^,//;p;};d')"
  
${ORACLE_HOME}/runInstaller -ignorePrereq -waitforcompletion -silent \
     -responseFile ${ORACLE_HOME}/install/response/db_install.rsp \
     oracle.install.option=INSTALL_DB_SWONLY \
     ORACLE_HOSTNAME=`hostname`  \
     UNIX_GROUP_NAME=oinstall\
     INVENTORY_LOCATION=/u01/app/oraInventory \
     SELECTED_LANGUAGES=en \
     ORACLE_HOME=${ORACLE_HOME} \
     ORACLE_BASE=/u01/app/oracle \
     oracle.install.db.InstallEdition=EE \
     oracle.install.db.OSDBA_GROUP=dba \
     oracle.install.db.OSOPER_GROUP=dba \
     oracle.install.db.OSBACKUPDBA_GROUP=dba \
     oracle.install.db.OSDGDBA_GROUP=dba \
     oracle.install.db.OSKMDBA_GROUP=dba \
     oracle.install.db.OSRACDBA_GROUP=dba \
     oracle.install.db.rootconfig.executeRootScript=false \
     oracle.install.db.CLUSTER_NODES=${CLUSTER_NODES} \
     SECURITY_UPDATES_VIA_MYORACLESUPPORT=false \
     DECLINE_SECURITY_UPDATES=true
  
# Execute root.sh
/u01/app/oracle/product/19.0.0.0/dbhome_2/root.sh
 
# enable Unified Auditing makes sense because it is the default since 19c
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk uniaud_on ioracle
# check if enabled
dcli -g ~/dbs_group -l oracle "ar -t $ORACLE_HOME/rdbms/lib/libknlopt.a | grep -q kzaiang && echo UnifiedAudit on || echo UnifiedAudit off"
 
# enable Oracle read only home in 19c also a recommendation
$ORACLE_HOME/bin/roohctl -enable
#  check if enabled
dcli -g ~/dbs_group -l oracle "cat $ORACLE_HOME/install/orabasetab | grep -q 'Y:$' && echo ROOH on || echo ROOH off"
 
# Prepare tnsnames.ora & sqlnet.ora as needed in your Setup
 
# For RAC please check if enabled - return value should be "kcsm.o"
ar -t $ORACLE_HOME/rdbms/lib/libknlopt.a|grep kcsm.o
#  check if enabled
dcli -g ~/dbs_group -l oracle "ar -t $ORACLE_HOME/rdbms/lib/libknlopt.a | grep -q kcsm.o && echo RAC on || echo RAC off"
 
# Check RDS Interconnect Protocol
$ORACLE_HOME/bin/skgxpinfo -v
#  check if enabled
dcli -g ~/dbs_group -l oracle "$ORACLE_HOME/bin/skgxpinfo -v"

You can test the Out-of-place Installation a few times if you are not familiar with the procedure.

As this task is needed more and more it is a duty for every DBA to deal with it.

Have fun … 🤞

faster patching with „opatch archive“

spaHinterlasse einen Kommentar

Since OPatch Version: 12.2.0.1.26 the new feature „archive“ is available.

The actually opatch Version is 12.2.0.1.33 which you should install before starting any activity.

What is my problem?

If you have an old Oracle Setup and you have patched for a longer time „inplace“ the patching activity will be running slower and slower. For this reason Oracle implemented the „archive“ option.

How does „archive“ work

su – oracle

cd $ORACLE_HOME

ORACLE_HOME „/u01/app/oracle/product/19.0.0.0/dbhome_1“

cd /u01/app/oracle/product/19.0.0.0/dbhome_1/.patch_storage

I do this on one of our Exadata Systems and the result is

du -sh $ORACLE_HOME/.patch_storage

12G     /u01/app/oracle/product/19.0.0.0/dbhome_1/.patch_storage

So the Patch Storage directory is indeed 12G. This explains why the patching runs up to

50 minutes which is really slow

Now it is time to use „opatch archive“

opatch „archive“ works in such a case that „inactive“ patches in the inventory will be archived.

Let’s have a look

opatch lsinv -inactive | grep description

ARU platform description:: Linux x86-64

Patch description:  „OJVM RELEASE UPDATE: 19.16.0.0.220719 (34086870)“

Patch description:  „OCW RELEASE UPDATE 19.16.0.0.0 (34160635)“

Patch description:  „Database Release Update : 19.16.0.0.220719 (34133642)“

The recommendation is to hold the last patch active but the rest of the history can be archived.

So RU 19.16 will be available for the reason that you need to do a rollback.

Patch description:  „OJVM RELEASE UPDATE: 19.15.0.0.220419 (33808367)“

Patch description:  „OCW RELEASE UPDATE 19.15.0.0.0 (33815596)“

Patch description:  „Database Release Update : 19.15.0.0.220419 (33806152)“

Patch description:  „OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694)“

Patch description:  „OCW RELEASE UPDATE 19.13.0.0.0 (33208123)“

Patch description:  „Database Release Update : 19.13.0.0.211019 (33192793)“

Patch description:  „MERGE ON DATABASE RU 19.9.0.0.0 OF 31408636 31991705 32017301“

Patch description:  „OJVM RELEASE UPDATE: 19.9.0.0.201020 (31668882)“

Patch description:  „Database Release Update : 19.9.0.0.201020 (31771877)“

Patch description:  „OCW RELEASE UPDATE 19.9.0.0.0 (31772784)“

Patch description:  „OCW RELEASE UPDATE 19.3.0.0.0 (29585399)“

Patch description:  „Database Release Update : 19.3.0.0.190416 (29517242)“

Start the Archive by

opatch util archive -patches 29517242,29585399, (and so on with all patches you want to archive.) -archive_dir /u01/app/19c/opatch_archives_before

There must be NO blank between the patch numbers, only a comma according to My Oracle Support.

After the archive was done the .patch_storage directory is only 2,4 G large and patching works faster.

This is also described in the Doc-ID 2867312.1 on My Oracle Support.

Important the archiving make more or less sense if you do Inplace patching, because out-of-place patching works all the time on a newly created Oracle Home which does not a long patch history. Please keep this in mind.

Yes I repeat it again Oracle recommends to do the Setup of Software as „Out-of-place“ Installation.

So for future projects take a look to the documentation and do always a Setup „out-of-place“.

DOAG Datenbank 2022 / Engineered Systems

spaHinterlasse einen Kommentar

Ein Schwerpunkt der „DOAG Datenbank 2022“, vom 30.5.2022 -31.5.2022 in Düsseldorf ist auch diesmal wieder mit einem separaten Stream das Thema „Engineered Systems“.

Am 30.5.2022 um 16:15 Uhr im Raum Amsterdam 3, diskutieren wir alle Fragen rund um die „Engineered Systems“.

Wir (Frank Schneede & ich) freuen uns auf ein spannende Diskussion.

Security Alert CVE-2021-44228 Exadata on-premises

spaHinterlasse einen Kommentar

First patches for Oracle on-premises products are now available.

If you use the Systems Utilities like AHF & tfactl you need to download and install the following Patch.

Engineered Systems Utilities (Trace File Analyzer) [Product ID 10655]MOS patch 30166242

Please check also in daily manner the actual MOS Doc ID and search for your installed product if additional Patches are available.

Apache Log4j Security Alert CVE-2021-44228 Products and Versions (Doc ID 2827611.1)

Engineered Systems Arbeitsgruppe trifft Exadata Product Management

spaHinterlasse einen Kommentar

Nächste Woche startet die DOAG Konferenz 2021.

Auch in diesem Jahr wird die DOAG Engineered Systems Arbeitsgruppe sich über aktuelle Themen mit dem Exadata & ODA Product Management austauschen können.

Am Mittwoch, dem 17.11.2021 um 18:00 Uhr haben Kunden und Konferenzteilnehmer die Möglichkeit Fragen direkt ans Product Management zu stellen.

Vom Oracle Product Management sind dabei:

  • Gavin Parish
  • Carlos Ortiz
  • Paul Tsien

Wir freuen uns auf eine interessante und spannende Diskussion.

Wir sehen uns nächste Woche :-)

Exadata X9M angekündigt

spaHinterlasse einen Kommentar

Oracle Exadata Database Machine X9M

Die Exadata X9M Core Plattform basiert auf einer Scale-Out-Architektur, die die neuesten Intel CPUs, Intel® Optane™ Persistent Memory (PMem) und RDMA over Converged Ethernet (RoCE) kombiniert, um bis zu 27,6 Mio. IOPS und eine Latenz von unter 19 Mikrosekunden für OLTP Anwendungen liefert.

Zur Beschleunigung von Analytic Anwendungen liefert jedes X9M Rack einen Durchsatz beim Scannen von über 1 TB/s und bietet bis zu 576 CPUs in intelligenten Speicherservern zur Verarbeitung von Low-Level-SQL-Abfragen.

Ebenfalls neu ist die ZDLRA Appliance X9M

Die Recovery Appliance wurde speziell für den Schutz von Oracle-Datenbanken entwickelt und verfügt über einmalige Funktionen zur Wiederherstellung von Datenbanken ohne Datenverlust und zur automatischen Validierung von Backups.

Darüber hinaus stellt Oracle neue Cyber Vault Funktionen für die zuverlässige Wiederherstellung nach Ransomware Angriffen vor. Die neue Version der Recovery Appliance erhöht die Speicherkapazität um 30 Prozent. Der Einstiegspreis wurde um 50 Prozent gesenkt.

Zu den neuen Funktionen gehört auch die Synchronisation zwischen mehreren Recovery Appliances, um die Kontinuität von Backup und Recovery bei ungeplanten und geplanten Ausfällen zu gewährleisten. Darüber hinaus werden Optionen für die langfristige Backup-Aufbewahrung unterstützt.

Die Exadata X9M – Data Sheets – mit allen Details finden Sie hier

https://www.oracle.com/engineered-systems/exadata/database-machine/

Oracle Database World—Europe, Middle East, Africa

Hier stellt Oracle alle Neuigkeiten auch die X9M im Detail vor

https://www.oracle.com/de/database/database-world/event/

Agenda der DOAG 2021 Konferenz + Ausstellung 

Die Exadata X9M und viele Neuigkeiten werden natürlich auch auf der DOAG Konferenz 2021 vorgestellt

https://shop.doag.org/kua-agenda/