Inhaltsverzeichnis
Installation Oracle 19c mit der ASM Option unter Oracle Linux 8.4 mit Einsatz des Oracle ASM Filter Treibers
Aufgabe
Installiert werden soll ein Oracle 19c System mit ASM Disks unter einem Oracle Linux 8.4. Statt der ASMLib soll der Oracle ASM Filter Driver zum Einsatz kommen.
Für die ASM Umgebung wird eine „Standalone Grid Infrastuktur“ unter dem User Grid aufgesetzt, die DB soll unter dem User Oracle laufen!
Da die 19.3 Basis Software noch nicht für Oracle 8 zertifiziert ist, muss diese min. auf 19.6 gepatched werden (aktuell 09.2021, 19.12) und zwar VOR der eigentlichen Installation!
Vorbereitung
Download der notwendigen Software
- Linux 8 über https://edelivery.oracle.com/
- Oracle Datenbank 19c über https://www.oracle.com/de/database/technologies/oracle19c-linux-downloads.html
- Datenbank ( LINUX.X64_193000_db_home.zip )
- ASM Umgebung ( LINUX.X64_193000_grid_home.zip)
- Oracle Patch für Grid und Datenbank unter folgender Support Node Oracle Database 19c Proactive Patch Information(2521164.1) + OPatch 6880880 Patch https://updates.oracle.com/ARULink/PatchDetails/process_form?patch_num=6880880 in der Version 19
Absprache mit der Projektleitung:
- Welche Datenbank Edition soll eingesetzt werden (Lizenz!)
- Welcher Zeichensatz wird benötigt?
- Welche Größe der ASM Luns macht am meisten Sinn (eher kleiner plannen ( wie 200/500GB) , max 2TB pro Lun möglich!)
Ablauf der Installation:
- Linux System Grundinstallation durchführen
- Storage/Platten für ASM einbinden
- Grid Software auspacken
- Grid Software patchen
- Vor der eigentlichen Installation Konfiguration des Oracle ASM Filter Driver
- Oracle ASM Umgebung installieren
- Oracle Datenbank Software installieren (Basis Software + Patch!)
- Datenbank aufsetzen
- System optimieren
Die Fallstricke:
- Auf den richtigen Kernel des Linux achten ⇒ UEK 5.4.17 kernels oder höher für den Oracle AFD Filter!
- Falls Oracle asmlib installiert, diese wieder deinstallieren und rebooten
- Falls Platten zuvor mit asmlib initialisiert wurden, diese wieder mit dd zurücksetzen und neu partitionieren, falls leer!
- Patch vor Installation in das Grid Home einspielen
- Link anlegen auf die von Oracle gewünschte Verzeichnisstruktur (/u01/app/19.0.0/grid auf GE HOME setzen!)
- Eine ASM Platte mit <DISKGROUPNAME>1 anlegen! Der Installer sucht sich dann später genau diese Bezeichnung!
- Nach dem initialisieren der ASM Platten (nach dem root.sh Skript!) prüfen das auch grid noch in das DIAG Home im Grid Home/log schreiben darf, da root da als erstes hineinschreibt und dann die ASM Instance ein Problem hat!
- Zwischen initialisieren der Platten und der eigentlichen Installation nicht booten, da die Kernel Treiber erst mit der Installation „richtig“ aktiv werden und danach die Platten nicht nochmal erkannt werden und nicht so recht neu gelabelt werden können!
- Genau die Rechte auf das Oracle Base überprüfen, die oinstall Gruppe muss Schreiben können in /opt/oracle, da die ASM Initialisierung einen Ordner /opt/oracle/admin/pfile als grid user anlegen will!
- Den Namen der ersten ASM DB DISK Gruppe so vergeben das das zuvor erstellt Disklabel mit 1 am Ende gefunden wird ( in meinen Beispiel REDO definiert, Installer hat nach REDO1 gesucht, dieses Label muss für die ASM Platte existieren!
Linux System in Grundinstallation aufsetzen
Minimales Sizing:
- 8GB Ram (ein erster Test mit 6GB war deutlich zu wenig!)
- 40GB für das Root Filessstem und die Oracle Homes
- ASM Platten je nach Bedarf für die Datenbank(en)
Ablauf:
Mit der Oracle Linux DVD das Grundsystem als „Database Server“ aufsetzen, Englisch als Sprache wählen!
- Netzwerkkarten einrichten
- Yum Repository einrichten
- Kernel Version prüfen
- SE Linux ausschalten
- OS update einspielen
- Notwendige Linux Pakete einspielen
- Hugepages einrichten
- Firewall Einstellungen prüfen
- NTP prüfen/aktivieren
- Kernel Settings überpürfen/anpassen
- TempFs überprüfen
- Oracle für ASM und Oracle Home einrichten
- Oracle Verzeichnisse anlegen
- sudo für die Administration der verschiedenen User einrichten
siehe dazu im Detail ⇒ Ein Oracle Linux 8 Basis System als Grundlagen für eine Oracle Clusterware und Datenbank Installation vorbereiten
Kernel für AFD überprüfen
Für den Oracle AFD Treiber unter Oracle Linux 8 wird benötigt ⇒ UEK 5.4.17 kernels oder höher ab 19.10.210119 (Base Bug 30590023)
Siehe dazu ⇒ ACFS Support On OS Platforms (Certification Matrix). (Doc ID 1369107.1) ⇒Abschnitt ACFS and AFD 19c Supported Platforms
Prüfen und bei Bedarf aktualsieren mit:
cat /etc/oracle-release Oracle Linux Server release 8.4 uname -r 4.18.0-305.12.1.el8_4.x86_64 # zu niedrig! dnf install kernel-uek.x86_64 dnf update # welcher Kernel booted als default grubby --default-kernel /boot/vmlinuz-5.4.17-2102.204.4.4.el8uek.x86_64 reboot
Siehe auch ⇒ https://docs.oracle.com/en/learn/oracle-linux-kernels/#check-available-kernels
Die ASM Platten im System einbinden
Platten in der neuen Umgebung zur Verfügung stellen
Je nach Hardware, siehe auch als Beispiel für einen Storage Anbindung ⇒ IBM DS3500 Storage im Einsatz mit SAS Karten für ein Oracle RAC 11g Cluster oder für einen ersten Test mit VMWare eine „normale“ Platte bzw. iSCSI Target für das Bereitstellen von Cluster Platten in VMWare unter Linux 7 zu der Maschine hinzufügen.
- Das richtige neue Device suchen bzw. online einbinden, dazu im laufenden Betrieb den SCSI Bus neu nach der neuen Platten scannen lassen:
ls /sys/class/scsi_host host0 host1 host2 #für alle 3 Controller echo "- - -" > /sys/class/scsi_host/host0/scan echo "- - -" > /sys/class/scsi_host/host1/scan echo "- - -" > /sys/class/scsi_host/host2/scan #var log messages überwachen , am besten in einer zweiten Session tail -f /var/log/messages .. Dec 28 23:46:45 gpidb12casm01 kernel: sd 2:0:1:0: [sdb] Attached SCSI disk ..
- Kandidaten anzeigen lassen
lsblk -o TYPE,MAJ:MIN,WWN,HCTL,NAME,SIZE | grep disk blkid | grep oracle | sort fdisk -l | grep Disk
Platten für ASM partitionieren
Partitionieren:
fdisk /dev/sdb ( "n", "p", "1", "Return", "Return", "p" and "w". )
Platten sehr groß > 2TB
In Oracle ASM sollten Platten nicht zu groß sein, besser mehrere kleine einbinden, falls es sich aber nicht vermeiden lässt gibt es ein Problem mit fdisk:
The size of this disk is 3 TiB (3221225472000 bytes). DOS partition table format cannot be used on drives for volumes larger than 2199023255040 bytes for 512-byte sectors. Use GUID partition table format (GPT).
⇒ mit gparted lösen ⇒ http://www.whiteboardcoder.com/2019/02/formatting-disks-over-2-tib-with-parted.html
Oder mit gdisk:
dnf install gdisk gdisk /dev/sdd
Am ende macht das aber dann doch keinen rechten Sinn ⇒
CREATE diskgroup DATA01 EXTERNAL REDUNDANCY disk 'AFD:DWHDATA1' * ERROR at line 1: ORA-15018: diskgroup cannot be created ORA-15099: disk 'AFD:DWHDATA1' IS larger than maximum SIZE OF 2097152 MBs
Mit compatible 19 läßt sich das umgehen:
CREATE diskgroup DATA01 EXTERNAL REDUNDANCY disk 'AFD:DWHDATA1' ATTRIBUTE 'compatible.asm' = '19.0', 'compatible.rdbms' = '19.0';
Prüfen ob nicht oraclesam auf dem System zuvor bereits installiert wurde
Prüfen ob oracleasm geladen ist mit:
lsmod | grep ora oracleasm 69632 1 # Packete anzeigen dnf list oracleasm* #Packate entfernen rpm -e oracleasm-support rpm -e oracleasmlib # Im Kernel aber noch geladen!! lsmod | grep ora oracleasm 69632 1 #Aus dem Kernel werfen rmmod oracleasm rmmod: ERROR: Module oracleasm is in use # neu starten da nicht möglich! reboot
Zur Deinstallation siehe auch ⇒ https://docs.oracle.com/en/database/oracle/oracle-database/19/cwlin/deinstalling-oracle-asmlib-on-oracle-grid-infrastructure.html#GUID-AAC3291D-BEAF-4567-A0A0-CA834C1A73EA
Wird das nicht durchgeführt ⇒
Problem bei der Installation : [INS-41223] ASM Filter Driver is not supported on this platform.
Action - To proceed, do not specify or select the Oracle ASM Filter Driver option. Additional Information: - AFD-9202: AFD can not be installed/loaded because ASMLib is installed.
Oracle User für ASM und Oracle Home einrichten
Die Oracle Datenbank Software wird unter dem User oracle, die ASM Instance unter dem User grid installiert.
Beide User sind ja bereits in der Basis Installation eingerichtet worden.
Lokales SSH aktivieren
Nun wird geprüft ob das Anmelden mit ssh möglich ist, ein SSH Key wird erzeugt und das login über localhost auf der lokalen Maschine per SSH ohne Password (mit Key) wird eingerichtet.
Hintergrund:
Neue Check Werkzeuge von Oracle melden sich lokal an der Maschine per SSH an, das muss ohne Password möglich sein.
ssh oracle@localhost ssh-keygen -t rsa -N '' -q -f ~/.ssh/id_rsa cd .ssh cat id_rsa.pub >> authorized_keys #nun sollte das ohne passwort klappen! ssh oracle@localhost
Gleiches für den User „grid“ einrichten.
Oracle Verzeichnisse anlegen/prüfen
Inventory
Das Inventory liegt dann unter „/opt/oraInventory“ und gehört der user „grid“ und der Gruppe „oinstall“.
Als user root:
mkdir /opt/oraInventory chown grid:oinstall /opt/oraInventory chmod 777 /opt/oraInventory chmod o-w /opt/oraInventory
Grid
Die ASM Software wird unter „/opt/19c/grid“ installiert.
Als User root:
mkdir -p /opt/19c/grid chown -R grid:oinstall /opt/19c/grid chmod -R 775 /opt/19c/grid
Um Fehler mit asmcmd zu vermeiden:
mkdir -p /u01/app/19.0.0/ chown -R grid:oinstall /u01/app/19.0.0/ ln -s /opt/19c/grid/ /u01/app/19.0.0/grid
Datenbank
Die Oracle Software wird nach /opt/oracle/product/19/dbhome_1 installiert.
Daher muss der Oracle User auf /opt/oracle die vollen Rechte besitzen
Als root (falls nicht schon bereits angelegt:
mkdir -p /opt/oracle chown -R oracle:oinstall /opt/oracle chmod -R 775 /opt/oracle chmod g+w /opt/oracle/
Für die ASM Installation notwendige Rechte vergeben! Ansonsten „[INS-20802] Automatic Storage Management Configuration Assistant failed.“ bei der Installation!
mkdir -p /opt/oracle/admin chown -R grid:oinstall /opt/oracle/admin chmod g+w /opt/oracle/admin/
Als user Oracle
mkdir -p /opt/oracle/product/19/dbhome_1
Oracle 19c ASM Software bereitstellen
User grid
Im ersten Schritt wird nur die Software ausgepackt und der Patch eingespielt, damit wir das asmcmd Tool verwenden können.
Software auf die Maschine kopieren und auspacken
Als User Grid anmelden und die Software in ein Install Verzeichnis kopieren, MD5 Hash prüfen und auspacken:
mkdir /opt/oracle/install #damit das auch der oracle user später nützen kann chmod g+w /opt/oracle/install #prüfen und auspacken cd /opt/oracle/install #Datei in das Install Verzeichnis kopieren cp /install/LINUX.X64_193000_grid_home.zip . #Checksumme prüfen und mit dem zuvor gemerkten Wert vom Dowload vergleichen sha256sum LINUX.X64_193000_grid_home.zip d668002664d9399cf61eb03c0d1e3687121fc890b1ddd50b35dcbe13c5307d2e LINUX.X64_193000_grid_home.zip #auspacken und zip löschen unzip LINUX.X64_193000_grid_home.zip -d /opt/19c/grid/ rm LINUX.X64_193000_grid_home.zip
Patch VOR der Installation
User grid
Patch in das Software Home VOR der eigentlichen Installation einspielen, siehe dazu auch „How to Apply a Grid Infrastructure Patch Before Grid Infrastructure Configuration (before root.sh or rootupgrade.sh or gridsetup.bat) is Executed (Doc ID 1410202.1)“
Patch herunterladen und Checksum prüfen: (Stand 09.2021)
GI RELEASE UPDATE 19.12.0.0.0 (Patch) p32895426_190000_Linux-x86-64.zip 2.4 GB (2596558871 bytes) SHA-1 E33CC770FC068849350D202E151EA97D32583E0A SHA-256 07C81F2248E22976BA2E6E85FF8AC2C955741339A1D892D63945C6B8A3AE9468 p6880880_190000_Linux-x86-64.zip SHA-1 AE626A866627ABB09ED69F41F0ABDE6010C07951 SHA-256 32299586B3442F8AA161D86CC63DBE2F6253B5B2DABEDB263725552B0B7D8B32 115M (120998448 bytes)
Im ersten Schritt OPatch überschreiben, d.h. altes OPatch Verzeichnis stehen lassen und mit Y überschreiben!
Als User grid
cd /opt/oracle/install unzip -d /opt/19c/grid p6880880_190000_Linux-x86-64.zip Archive: p6880880_190000_Linux-x86-64.zip replace /opt/19c/grid/OPatch/README.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: A ...
Nun „apply Release Updates and Non-RU patches“ in einem Schritt:
unzip p32895426_190000_Linux-x86-64.zip cd /opt/19c/grid /opt/19c/grid/gridSetup.sh -applyRU /install/DWHSW/32895426 -applyOneOffs /install/DWHSW/32895426 Preparing the home to patch... Applying the patch /install/DWHSW/32895426... Successfully applied the patch. Applying the patch /install/DWHSW/32895426... Successfully applied the patch. The log can be found at: /tmp/GridSetupActions2021-09-15_02-09-56PM/installerPatchActions_2021-09-15_02-09-56PM.log Launching Oracle Grid Infrastructure Setup Wizard...
Nun kann in einer zweiten Session als Root vor dem ASM Dialog des Installers asmcmd geprüft und die Platten eingerichtet werden!
asmcmd Tool prüfen
Als user root in zweiter Session:
export ORACLE_HOME=/opt/19c/grid export ORACLE_BASE=/tmp cd /opt/19c/grid/bin ./asmcmd >exit # falls Fehler Link nicht gesetzt!!
Default Pfad /u01/app/19.0.0/grid verlinken
Da wenn ein anderer Pfad als u01 verwendet wird ist VOR der Installation noch der Pfad in den Skripten falsch!
Problem:
/opt/19c/grid/bin/kfod: line 22: /u01/app/19.0.0/grid/bin/kfod.bin: No such file or directory
Lösung:
Besser alternativ Link unter „/u01/app/19.0.0/grid“ auf „/opt/19c/grid“ anlegen!
mkdir -p /u01/app/19.0.0/ chown -R grid:oinstall /u01/app/19.0.0/ ln -s /opt/19c/grid/ /u01/app/19.0.0/grid
Oracle ASM Platten mit dem Oracle ASM Filter Driver (Oracle ASMFD) einrichten
Die Treiber für den Oracle ASMFD Filter Driver sind nicht im Oracle Linux Kernel integriert und müssen zuvor über die Software Installation geladen werden.
Der Vorteil der Oracle ASMFD Trieber:
- ASM Platten sind vor dem überschreiben mit anderen Tools geschützt!
Ablauf:
- Grid Software im Grid home ist auspacken/patchen, aber noch nicht installieren!
- Platten im System mit asmcmd einbinden
Platten in ASM einrichten
als User root
Die Platten werden mit „asmcmd“ initalisiert, es wird dann eine Datei unter /dev/oracleafd/disks/ mit dem Label Name angelegt.
su root export ORACLE_HOME=/opt/19c/grid/ export ORACLE_BASE=/tmp cd /opt/19c/grid/bin #Check ob der AFD Treiber zum aktuellen Linux passt! ./afddriverstate supported AFD-9200: Supported #Prüfen ob bereits Label bzgl. ASM existieren blkid | grep oracle | sort /dev/sdb1: LABEL="DWHREDO" TYPE="oracleasm" PARTUUID="0f5ed98b-01" #falls ja, hift nur formatieren, falls die Platte noch leer ist! dd if=/dev/zero of=/dev/sdb bs=1M count=10 #neu mit fdisk patition anlegen #Platte lablen ./asmcmd afd_label REDO1 /dev/sdb1 # disk /dev/sdb1 is already provisioned for ASM #falls dieser Fehler kommt, erneut bennenen, ./asmcmd afd_label REDO1 /dev/sdb1 --migrate testen #falls es nicht klappt, Platte komplett zurücksetzen und neu anlegen! ./asmcmd afd_lslbl /dev/sdb1 -------------------------------------------------------------------------------- Label Duplicate Path ================================================================================ REDO1 /dev/sdb # legt dann eine Datei an: ls -la /dev/oracleafd/disks/ REDO1 cat /dev/oracleafd/disks/REDO1 512:20969472:root:disk:/dev/sdb1
siehe auch „How to configure and Create a Disk group using ASMFD (Doc ID 2053045.1)“
Platte wird nicht erkannt ist aber konfiguriert
Treten im Ablauf der Installation Problem auf, wie ein Reboot vor der eigentlichen Installation kann es passieren das eine Platte plötzich danach nicht erkannt wird.
#Als user Grid asmcmd ASMCMD>afd_lsdsk # Platte fehlt! #Als user root # platte mit --migrate wieder erneut initaliseren export ORACLE_HOME=/opt/19c/grid/ export ORACLE_BASE=/tmp cd /opt/19c/grid/bin # Platte wäre bereits initalisiert ./asmcmd afd_label DWHARCH /dev/sde1 ASMCMD-9521: AFD is already configured #Plattelabel wird auch erkannt ./asmcmd afd_lslbl .. DWHARCH Y /dev/sde DWHARCH Y /dev/sde1 .. #Platte neu einlesen lassen ./asmcmd afd_label DWHARCH /dev/sde1 --migrate # Als user Grid testen asmcmd # Platte wird erkannt: ASMCMD>afd_lsdsk DWHARCH ENABLED /dev/sde1
siehe auch ASMCMD-9521: AFD is already configured when try to label the missing disks (Doc ID 2483397.1)
Problem Kernel Modul
Nach einem Reboot VOR der eigentlichen Installation sind die Platten plötzlich wieder „weg“ …
Das Kernelmodul ist nicht geladen!
lsmod | grep ora
Die Prüfung ob der Kernel Treiber kompatibel ist, zeigt einen nicht suportenden Kernel an:
[root@svmlworadbp1 bin]# ./afddriverstate supported AFD-9462: The /opt/19c/grid//usm/install/Oracle/EL8/x86_64/4.18.0-240/4.18.0-240-x86_64/bin/oracleacfs-4.18.0-240.10.1.el8_3.x86_64.rpm RPM is not compatible with kernel kernel-core-4.18.0-305.12.1.el8_4.x86_64. AFD-9466: *********************** SYMBOLS SUMMARY *********************** AFD-9465: Kernel: 'kernel-core-4.18.0-305.12.1.el8_4.x86_64', RPM: '/opt/19c/grid//usm/install/Oracle/EL8/x86_64/4.18.0-240/4.18.0-240-x86_64/bin/oracleacfs-4.18.0-240.10.1.el8_3.x86_64.rpm'
Siehe dazu ACFS Support On OS Platforms (Certification Matrix). (Doc ID 1369107.1) = >Abschnitt ACFS and AFD 19c Supported Platforms
⇒ UEK 5.4.17 kernels oder höher ab 19.10.210119 (Base Bug 30590023)
prüfen:
cat /etc/oracle-release Oracle Linux Server release 8.4 uname -r 4.18.0-305.12.1.el8_4.x86_64 dnf install kernel-uek.x86_64 dnf update grubby --default-kernel /boot/vmlinuz-5.4.17-2102.204.4.4.el8uek.x86_64 reboot
https://docs.oracle.com/en/learn/oracle-linux-kernels/#check-available-kernels
ASM Installation starten
Für die ASM Instance wird ein Teil der Cluster Software (Quasi ein Standalone RAC nur für ASM) installiert.
Installer aufrufen:
cd /opt/19c/grid/ #./gridSetup.sh #inkl Patch! ./gridSetup.sh -applyRU /install/DWHSW/32895426 -applyOneOffs /install/DWHSW/32895426
Problem mit 19.3 auf einem Linux 8 - erst ab 19.6 ist das supported!
[INS-08101] Unexpected error while executing the action at state: 'supportedOSCheck'
⇒19c Database/client Installation fails with Error:[INS-08101] Unexpected error while executing the action at state:'clientSupportedOSCheck' (Doc ID 2584365.1)
Eigentliche Installation
Zuvor prüfen ob unter /opt/19c/grid/log auch alles noch dem Grid user gehöhrt!!! als root:
cd /opt/19c/grid/log/ chown -R grid:oinstall *
Ablauf:
- Select Install Option - Install and Configure Oracle Grid Infrastructure for a Standalone Server - Next
- Create ASM Disk Group
- Eine Platte auswählen, Redundancy auf „External“ setzen, Name der Gruppe vergeben wie später gewünscht
- „Configure Oracle ASM Filter Driver“ anhaken
- Next
- Specify ASM Password - Passwörter vergeben - Next
- Specify Management Options - Nichts anwählen - Next
- Privileged Operating System Groups - Default belassen (asmadmin, oinstall) - Next
- Specify Installation Location - Pfade anpassen - Oracle Base /opt/oracle und Software Location „/opt/12.1.0.2/grid“ - Next
- Bestätigen das Oracle Home nicht in der Base liegt
- Next
- Create Inventory - Inventory Directory „/opt/oraInventory“ - Next
- Root script execution configuration - Nichts auswählen - Next
- Perform Prerequisite Checks
- Swap Anmerkung mit Hacken „Ignore ALL“ ignorieren
- Summary - Response File sicheren mit „Save Response File“ - Install
- Install Product - Installation wird durchgeführt - Dauer ca. 4-6 Minuten
- Ecexute Configuration scripts
- Als Root User die aufgeführen Skripte der reihe nach ausführen
- /opt/oraInventory/orainstRoot.sh - Setzt Rechte im Inventory
- /opt/19c/grid/root.sh - Setzt Rechte und legt das eigentliche One Node Cluster an
- prüfen ob auf /opt/19c/grid/log/diag/asm grid noch Eigentümer ist!
- Mit „OK“ die Durchführung der Skripte bestätigen
- Zum Abschluss wird noch die Konfiguration der Umgebung vom Installer abgeschlossen ca. 5-7 Minuten
- Finish - Installation abgeschlossen - Close
Nacharbeiten
User Umgebung setzen
Nach der Installation die User Umgebung, Oracle Home, SID etc. setzen.
Je nach Bedarf statisch in der .bashrc oder mit eigenen Skripten wie Arbeitsumgebung setzen und Einrichten unter Windows und Linux.
Umgebung prüfen
Cluster Umgebung:
crsctl status resource -t
ASM Instance überprüfen:
#Umgebung setzen (ORACLE_HOME und ORACLE_SID!) sqlplus / as sysasm select * from v$asm_disk;
DIAG Home ASM Instance setzen
Diag Home der ASM setzen:
show parameter diagnostic_dest alter system set diagnostic_dest='/opt/oracle/diag' scope=both sid='*'; select * from v$diag_info;
Audit Directory der ASM Instance setzen
Diag Home der ASM setzen:
# Anlegen # als user grid mkdir /opt/oracle/admin/+ASM/adump show parameter audit_file_dest alter system set audit_file_dest='/opt/oracle/admin/+ASM/adump' scope=spfile sid='*';
Compatible Parameter für die ASM Platten setzen
Wenn klar ist das keine ältern DB Versionen und NUR Oracle 19 mit den ASM Platten arbeiten soll,kann der Compatible Wert auf 19 gesetzt werden um auch alle Features zu nützen.
als Grid user mit sqlplus / as sysasm:
ALTER DISKGROUP DATA01 SET ATTRIBUTE 'compatible.asm'='19.0.0.0.0'; ALTER DISKGROUP DATA01 SET ATTRIBUTE 'compatible.rdbms'='19.0.0.0.0';
Neustart testen
Nach der Installation das System neu starten um zu prüfen ob auch alles automatisch richtig gestartet wird.
Neue Platten einbinden
Sind die ASM Diskgroup so langsam voll können online einfach neue Platten eingebunden werden.
Lun an die Maschine hängen und von der Maschine erkennen lassen:
ls /sys/class/scsi_host host0 host1 host2 #für alle 3 Controller echo "- - -" > /sys/class/scsi_host/host0/scan echo "- - -" > /sys/class/scsi_host/host1/scan echo "- - -" > /sys/class/scsi_host/host2/scan #var log messages überwachen , am besten in einer zweiten Session tail -f /var/log/messages
Überprüfen ob die Platte erkannt wird:
lsblk -o TYPE,MAJ:MIN,WWN,HCTL,NAME,SIZE | grep disk blkid | grep oracle | sort fdisk -l | grep Disk
Platte vorbereiten und labeln
Die Platte formatieren und als Candidate Disk einbinden
Als Root User:
fdisk /dev/sdj # Primäre Partition einrichten mit ( "n", "p", "1", "Return", "Return", "p" and "w". )
Platte mit dem ASM Filter einbinden
export ORACLE_HOME=/opt/19c/grid/ #Wichtig! nicht vergessen sonst werden Rechte falsch im DIAG Home gesetzt und es gibt böse Folgefehler! export ORACLE_BASE=/tmp cd /opt/19c/grid/bin ls -la /dev/sdj1 ./asmcmd afd_label DWHDATA05 /dev/sdj1 # Wird die Platte auch angezeigt: ls -la /dev/oracleafd/disks/
Platte einer ASM Diskgroup hinzufügen
Platte als User Grid der ASM Diskgroup hinzufügen:
Prüfen ob Platten erkannt werden:
# Grid ASM Umgebung setzen asmcmd ASMCMD> afd_lsdsk -------------------------------------------------------------------------------- Label Filtering Path ================================================================================ ..... DWHDATA05 ENABLED /dev/sdj1 .. exit
Platte einbinden
sqlplus / AS sysasm ALTER diskgroup DATA01 ADD disk 'AFD:DWHDATA05';
Anzeigen:
ASMCMD> lsdg
Eigentliche Datenbank aufsetzen
Nach dem Aufsetzen der eigentlichen ASM Umgebung kann die DB Software kopiert und gepatchet werden.
Software auf die Maschine kopieren und auspacken
Als User oracle anmelden und die Software in das Install Verzeichnis kopieren, MD5 Hash prüfen und auspacken:
cd /opt/oracle/install sha256sum LINUX.X64_193000_db_home.zip ba8329c757133da313ed3b6d7f86c5ac42cd9970a28bf2e6233f3235233aa8d8 LINUX.X64_193000_db_home.zip #auspacken und zip löschen unzip -d /opt/oracle/product/19/dbhome_1 LINUX.X64_193000_db_home.zip rm LINUX.X64_193000_db_home.zip
Patch VOR der Installation
User oracle
Patch in das Software Home VOR der eigentlichen Installation einspielen, siehe dazu auch „How to Apply a Grid Infrastructure Patch Before Grid Infrastructure Configuration (before root.sh or rootupgrade.sh or gridsetup.bat) is Executed (Doc ID 1410202.1)“
Patch herunterladen und Checksum prüfen (hier für die DB den gleichen Patch wie für das Grid Home!): (Stand 09.2021)
GI RELEASE UPDATE 19.12.0.0.0 (Patch) p32895426_190000_Linux-x86-64.zip 2.4 GB (2596558871 bytes) SHA-1 E33CC770FC068849350D202E151EA97D32583E0A SHA-256 07C81F2248E22976BA2E6E85FF8AC2C955741339A1D892D63945C6B8A3AE9468 p6880880_190000_Linux-x86-64.zip SHA-1 AE626A866627ABB09ED69F41F0ABDE6010C07951 SHA-256 32299586B3442F8AA161D86CC63DBE2F6253B5B2DABEDB263725552B0B7D8B32 115M (120998448 bytes)
Im ersten Schritt OPatch überschreiben, d.h. altes OPatch Verzeichnis stehen lassen und mit Y überschreiben!
Als User oracle
cd /opt/oracle/install unzip -d /opt/oracle/product/19/dbhome_1 p6880880_190000_Linux-x86-64.zip Archive: p6880880_190000_Linux-x86-64.zip replace /opt/19c/grid/OPatch/README.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: A ...
Nun „apply Release Updates and Non-RU patches“ in einem Schritt:
unzip p32895426_190000_Linux-x86-64.zip cd /opt/oracle/product/19/dbhome_1 ./runInstaller -applyRU /install/DWHSW/32895426 -applyOneOffs /install/DWHSW/32895426 Preparing the home to patch... Applying the patch /install/DWHSW/32895426... Successfully applied the patch. Applying the patch /install/DWHSW/32895426... Successfully applied the patch. The log can be found at: /tmp/GridSetupActions2021-09-15_02-09-56PM/installerPatchActions_2021-09-15_02-09-56PM.log Launching Oracle Grid Infrastructure Setup Wizard...
Datenbank Software konfigurieren
Installer starten
cd /opt/oracle/product/19/dbhome_1 ./runInstaller
Im ersten Schritt wird nur die Datenbank Software installiert, die Installation der Software erfolgt für die Enterprise Edition, Ablauf ist der gewohnte Standard ohne besondere Einstellungen.
- Select Installation Option - „Setup software only“ anwählen - Next
- Grid Installation Options - „Single instance database installation“ - Next
- Select Product Languages - Default - Next
- Select Database Edition - Default - Enterprise - Next
- Specify Installation Location
- Oracle Base: /opt/oracle
- Software location: /opt/oracle/product/19/dbhome_1
- Next
- Privileged Operating System groups - default bis auf Real application Custer Group auf asmadmin - next
- Root Script execution configuration - default - Next
- Prerequisite Checks- Ignore Swap mit „Ignore All“ - Next
- Summary - „Save Responce File“ für die Dokumentation - Install
- Install Product - Installation läuft - ca 5 Minuten
- Über Details gibt es mehr Informationen
- Root Skripte ausführen
- Finish - mit „Close“ beenden
Oracle User Umgebung setzen
Nach der Installation die Oracle User Umgebung, Oracle Home, SID etc. setzen.
Je nach Bedarf statisch in der .bashrc oder mit eigenen Skripten wie Arbeitsumgebung setzen und Einrichten unter Windows und Linux.
19c Datenbank mit dem dbca Wizard anlegen
Mit dem „dbca“ Wizard eine Default Datenbank unter Verwendung der ASM Platte anlegen.
Vorbereitung: (als user grid!)
- Schreibrechte auf dem Oracle Base für die oinstall Gruppe auf /opt/oracle/cfgtoollogs als grid user vergeben
chmod g+w /opt/oracle/cfgtoollogs
- Auf das Admin Verzeichniss Gruppe und Rechte anpassen:
chown grid:dba /opt/oracle/admin chmod g+w /opt/oracle/admin
- Auf das Admin Verzeichniss Gruppe und Rechte anpassen:
chown grid:dba /opt/oracle/diag chmod g+w /opt/oracle/diag
- Auf das Checkpoints Verzeichnis die Rechte setzen
chmod g+w /opt/oracle/checkpoints/
Als User oracle:
#Umgebung setzen ORACLE_HOME der Datenbank, keine SID dbca &
- Database Operation - Create Database - Next
- Creation Mode
- DB Name angeben
- Storage Option wählen
- Zeichensatz und Password vergeben
- Create as Container abwählen
- Next
- Prequisite checks
- Summary - Finish
- Progress Page
- Finish - Text beachten! - Close
In einer produktiven Umgebung sollte man wohl den Detail Dialog durchgehen um zu viele spätere Anpassungen zu vermeiden. Bei dieser Methode wird die Datenbank aus einen Default Backup geklont und enthält alle Optionen. Das entspricht ja nicht immer den verfügbaren Lizenz-Szenario.
Datenbank bei Bedarf anpassen
Logon Version einstellen
Je nach dem wie alt die Clients in der Umgebung sind, sich über das geänderte Login Verhalten der 19c Gedanken machen und entsprechend einstellen ⇒ Oracle 12c R2 - Password Handing - ORA-1017 Invalid Username or Password after upgrade.
Profile Einstellung
Prüfen auf Firmenstandard und wenn möglich Ablauf von Passwörtern ausschalten:
ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 50 PASSWORD_LIFE_TIME UNLIMITED;
Parameter bei Bedarf anpassen
als sys
# # Zur Vermeidung von Bugs mit Tabellen deren Segment erst beim ersten INSERT erzeugt werden # TRUE sinnvoll z.b. bei SAP Datenbanken die sehr viele Tabellen/Indexes leer anlegen und diese leeren Tabellen werden nie/sehr selten benötigen # ALTER system SET DEFERRED_SEGMENT_CREATION=FALSE scope=BOTH sid='*'; # #Zurückstellen auf "alten" Wert =>https://mikedietrichde.com/2018/09/11/oracle-12-2-and-higher-set-_cursor_obsolete_threshold-to-old-DEFAULT/ # ALTER SYSTEM SET "_cursor_obsolete_threshold"=1024 scope=spfile sid='*'; # # MOS How TO Disable SQL Plan Directive (SPD) (Doc ID 2209560.1) wenn optimizer_adaptive_statistics=FALSE! # ALTER SYSTEM SET "_sql_plan_directive_mgmt_control"=0 scope=spfile sid='*';
Eine 11g Datenbank auf 19c in diese Umgebung umziehen
DD prüfen
Zuvor prüfen ob das DD der Datenbank ok ist ⇒ hcheck.sql - Script to Check for Known Problems in Oracle8i, Oracle9i, Oracle10g, Oracle 11g and Oracle 12c and Above (Doc ID 136697.1)
DD Statistiken erneuern
Prüfen wann die Statistiken zuletzt erzeugt wurden:
SELECT to_char(MAX(end_time),'dd.mm.yyyy hh24:mi') last_time,operation FROM dba_optstat_operations GROUP BY operation /
Bei Bedarf erneuerern!
PreUpgrade
Im ersten Schritt muss auf der 11g Umgebung das PrUpgade Script duchgeführt werden, die dazu notwendige aktuelleste Version findet sich hier ⇒ MOS Note: 884522.1 (How to Download and Run Oracle’s Database Pre-Upgrade Utility)
Zuvor immer das Backup der bestehenden Datenbank sicherstellen!
Darauf achten das keine „alten“ ungültigen SYS Objekte in der Datenbank mehr vorliegen! Test mit ⇒ https://github.com/gpipperr/OraPowerShell/blob/master/Ora_SQLPlus_SQLcL_sql_scripts/invalid.sql
Prüfen ob wirklich die 11g DB in der Version 11.2.0.4 vorliegt!
PreUpgrade Skript
Download von der MOS Node 884522.1 und entpacken:
su - oracle mkdir upgrade19cScript cd upgrade19cScript/ unzip /tmp/preupgrade_19_cbuild_11_lf.zip Archive: /tmp/preupgrade_19_cbuild_11_lf.zip inflating: preupgrade_package.sql inflating: preupgrade_driver.sql inflating: dbms_registry_extended.sql inflating: parameters.properties inflating: preupgrade_messages.properties inflating: components.properties inflating: preupgrade.jar
Aufruf Mit $Earlier_release_Oracle_home/jdk/bin/java -jar $New_release_Oracle_home /rdbms/admin/preupgrade.jar [FILE|TERMINAL] [TEXT|XML] [DIR output_dir]
# DB Umgebung altes DB Home setzen # Oracle SID der zuprüfenden Datenbank setzen cd upgrade19cScript/ $ORACLE_HOME/jdk/bin/java -jar .preupgrade.jar TERMINAL TEXT
Die erzeugten Aussgaben im preupgrade.log sorgfältig lesen und möglichst befolgen!
Zusätzlich werden die PreUpgrade und PostUpgrade SQL Scripte erzeugt.
Das preupgrade_fixups.sql MUSS zuvor in der alten DB Umgebung auf der zu migrierenden Datenbank aufgerufen werden!
PreCheck Script ausführen
PreUpgrade Script auf in der „alten“ DB Umgebung als sys ausführen
sqlplus / AS sysdba @preupgrade_fixups.sql
Anweisungen befolgen wie DB Statistik neu anlegen!
EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;
Hidden obsolete Parameter reseten, Bespiel:
ALTER SYSTEM RESET "_some_hidden_parameter" scope = spfile;
Streams Konfiguration bei Bedarf entfernen ( z.B. falls früher eine Standby konfig im Einsatz)
EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION
Siehe ⇒ https://docs.oracle.com/database/121/STREP/best_gen.htm#STREP514
Besonderers darauf achten das in Passwörter der DB user die NUR in der Version 10g vorliegen, neu gesetzt werden!
SELECT password_versions,username FROM dba_users WHERE password_versions LIKE '%10G%';
Nach dem Upgrade können sich die User mit NUR 10g PWD nicht mehr an der DB 19c anmelden!
Siehe auch ⇒ https://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/using-preupgrade-information-tool-for-oracle-database.html#GUID-C4941221-8DC4-4DF8-A773-9F8B3FECF7D0 und https://mikedietrichde.com/2019/03/18/oracle-19c-preupgrade-jar-and-preupgrade-checks/
Der eigentliche DB Upgrade mit autoupgrade.jar
In dieser Umgebung kann aus einem Backup das ganze nicht migriert werden, da DB Version noch 11.2.3, mit DataPump die Daten in eine neue DB Übernehmen.
DB aus RMAN zuvor wiederherstellen für ein Upgrade
Siehe vom Prinzip ⇒ Windows 2019 Oracle Datenbank Umgebung vorbereiten - 19c installieren - Datenbank 12c nach 19c migrieren und Umstellen auf Oracle 19c - Upgrade einer Oracle Single Instance Datenbank 18c auf Oracle 19c unter MS Server 2019
Auto Upgrade verwenden
Für jeden Upgrade die neueste Version herunterladen!
Für 19c Umgebung dringend empfohlen siehe „MOS AutoUpgrade Tool (Doc ID 2485457.1)„.
Grober Ablauf:
- Config file erstellen
- Analyse durchführen (führt auch die PreChecks durch)
- Precheck prüfen
- Fixup durchführen
- Upgrade durchführen
Alternativ - Über DB Link die Datenbank per Import upgraden
Da die zu migrierende DB eine 11.2.3 DB Version ist, bleibt nur der Import per DataPump, am besten über DB Link, das mehr als 1TB an Daten zu übertagen sind.
Über einen DB Link aus dem Zielsystem das Quellsystem abfragen und dort die Daten einfügen:
|-------| |-----| | PROD | <==== DB Link | TST | |-------| |-----| source destination
Der Export erfolgt von der „source database“ in die „destination database“, d.h. der DB Link wird in der „destination database“ angelegt!.
Ablauf:
- SOURCE DB ⇒ User für den Export der Daten anlegen ( oder wie in meinen Fall den SYSTEM user verwenden)
- DESTINATION DB ⇒ DB Directory anlegen
- DESTINATION DB ⇒ DB Link auf die SourceDB anlegen
- DESTINATION DB ⇒ Tabellespace Definition erzeugen
- DESTINATION DB ⇒ Object Grants / User / Rollen erzeugen
- DESTINATION DB ⇒ Tablespaces anlegen in der destination DB TST
- DESTINATION DB ⇒ Full import über DB Link starten, über den lokal angemeldeten User
- DESTINATION DB ⇒ Grants nochmal nachziehen und recompile
Vorbereitung Datenbank Umgebung
- DB Optimieren
- Archive Log Mode aus für den Import ausschalten
sqlplus / AS sysdba shutdown IMMEDIATE startup mount ALTER DATABASE noarchivelog; ALTER DATABASE OPEN; archvie log list
- DB Files Anzahl bei Bedarf einstellen (Default nur 200!)
sqlplus / AS sysdba ALTER system SET db_files=1024 scope=spfile; startup force
Sicherstellen das die TNSNAMES.ora im DB home einen ALIAS auf die zu exportierende DB enthält für den DB Link.
Soll nur eine globale TNSNAMES.ora verwendet werden, auf diese einen Link setzen:
ln -s /opt/19c/grid/network/admin/tnsnames.ora /opt/oracle/product/19/dbhome_1/network/admin/tnsnames.ora ln -s /opt/19c/grid/network/admin/sqlnet.ora /opt/oracle/product/19/dbhome_1/network/admin/sqlnet.ora
DB Link vorbereiten
DB Directory und Link auf der DESTINATION DB TST:
-- DB Directory CREATE OR REPLACE directory import_dir AS '/opt/oracle/import/GPIDB'; -- DB Link CREATE DATABASE link DP_TRANSFER CONNECT TO system IDENTIFIED BY hugo1oguh USING 'gpi_db1'; -- pürfen ob es auch die richtige DB ist: SELECT global_name FROM global_name@DP_TRANSFER;
SQL aus der Quelle auslesen für das Vorbreiten von der gleichen Tablespace / User / Rollen Struktur
Tablespace SQL / user / roles und Grants holen:
impdp "'/ as sysdba'" directory=import_dir network_link=DP_TRANSFER sqlfile=tablespaces_gpidb.sql content=metadata_only include=TABLESPACE full=Y impdp "'/ as sysdba'" directory=import_dir network_link=DP_TRANSFER sqlfile=users_gpidb.sql content=metadata_only include=USER full=Y impdp "'/ as sysdba'" directory=import_dir network_link=DP_TRANSFER sqlfile=roles_gpidb.sql content=metadata_only include=ROLE full=Y impdp "'/ as sysdba'" directory=import_dir network_link=DP_TRANSFER sqlfile=object_grants_gpidb.sql content=metadata_only include=OBJECT_GRANT full=Y
Vor dem eigentlichen Import die Tablespaces vorbereiten ( gleich wie Prod, in meine Fall werden mehr als 1TB übertragen und es muss entsprechend viel Platz vorgehalten werden!), User und Rollen anlegen.
D.h. sorgfältig die erzeugen Scripte prüfen/anpassen und Tablespaces / User / Rollen in der „destination“ DB als SYS anlegen.
Tablesspace anlegen
Script tablespaces_gpidb.sql öffnen und prüfen ob alle Pfade zur aktuellen Umgebung passen und keine Altlasten aus der Produktion mit falschen Pfad/Name vorliegen
Starten:
#Alle Verzeichnis pfade ausgeben # sollten alle in der Art '+DATA01/dwh_data010.dbf auf die richtige ASM Disk Group zeigen grep / tablespaces_DWH.sql # Undo Tablespace auskommentieren # Undo exisitert bereits! # wenn alles ok Tablespaces anlegen sqlplus / as sysdba spool create_tablesspace_20_11_2021.log @tablespaces_DWH.sql spool off exit #alles auf Fehler im Log prüfen #bestehenden Undo Tablespace auf Größe der Produktion anpassen sqlplus / as sysdba alter TABLESPACE "UNDOTBS1" add DATAFILE '+DATA01/GPIDB/undotbs02.dbf' SIZE 4G AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED; ALTER DATABASE DATAFILE '+DATA01/GPIDB/undotbs01.dbf' RESIZE 4G; ALTER DATABASE DATAFILE '+DATA01/GPIDB/undotbs01.dbf' AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED;
rollen und User anlegen
# DEFAULT Rollen aus des roles_gpidb.sql entfernen sqlplus / AS sysdba @roles_GPIDB.sql #User überprüfen / ALTER vom sys USER entfernen etc. sqlplus / AS sysdba @users_GPIDB.sql
Eigentlichen Import durchführen
Full import durchführen in der DESTINATION DB, dabei alte Example Schemas aus der Source DB ausschließen:
vi import_gpidb.ctl LOGFILE=impdp_28-09-2021_10_45_gpidb.log network_link=DP_TRANSFER JOB_NAME=IMP_GPIDB_V1 FLASHBACK_SCN=340709435498 EXCLUDE=SCHEMA:"IN ('SH','HR')" EXCLUDE=USER:"IN ('SH','HR')" FULL=Y
Importieren:
$ORACLE_HOME/bin/impdp "'/ as SYSDBA'" parfile=import_gpidb.ctl
Nacharbeiten
-- Object Grant Script laufen lassen das zuvor im impdp aus dem Metadaten der Source DB erzeugt wurde @object_grants_gpidb.sql -- auf ungültige Objecte prüfen -- alte veraltete User wieder entfernen DROP USER OLAPSYS cascade; DROP USER MDDATA cascade; DROP USER SCOTT cascade; -- synonyme die auf nichts zeigen entfernen @invalid_synoyms.sql -- alles ungültige neu übersetuen @?/rdbms/admin/utlrp -- Directories prüfen und bei Bedarf anpassen @directory
Die Scripte finden Sie in meiner Script Library OraPowerShell
Einschränkungen - ORA-31679:
Es können keine Tabelle mit LONG Spalten übertragen werden! Fehler:
ORA-31679: TABLE DATA object "GPI"."VERY_OLD_TABLE" has long COLUMNS, AND longs can NOT be loaded/unloaded USING a network link
Diese Tabelle muss nun einzeln aus der Quelle extrahiert werden ….
* Archive Log Mode für den normalen Betrieb wieder einschalten
sqlplus / AS sysdba shutdown IMMEDIATE startup mount ALTER DATABASE archivelog; shutdown IMMEDIATE exit srvctl START DATABASE -s DWH sqlplus / AS sysdba archive log list ALTER system switch logfile; # 10mal # dann prüfen (alert.log/SQL) das alles schön geswitcht hat!
ASM Umgebung - Datenbank patchen
Opatch gleich zu Beginn in beiden Umgebungen tauschen!
ASM Umgebung
Patch Patch 33182768 - GI Release Update 19.13.0.0.211019 (Noveber 2021), aktuellen Patch siehe ⇒ Oracle Database 19c Proactive Patch Information(2521164.1).
Ablauf:
- Patch herunterladen , auspacken (als Grid Owner!) und z.B. unter /opt/oracle/install bereitstellen
- Opatch austauschen( Opatch im GI Home)
# als user root mv /opt/19c/grid/OPatch /opt/19c/grid/OPatch_OLD cd /opt/oracle/install/patch unzip p6880880_190000_Linux-x86-64.zip -d /opt/19c/grid chown -R grid:oinstall /opt/19c/grid/OPatch /opt/19c/grid/OPatch/opatch version
- Patch mit OPatch prüfen als User Grid
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/oracle/install/patch/33182768/33192793 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/oracle/install/patch/33182768/33208123 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/oracle/install/patch/33182768/33208107 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/oracle/install/patch/33182768/33239955 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/oracle/install/patch/33182768/32585572
- OPatch System Space Check vorbereiten
#Datei /tmp/patch_list_gihome.txt anlegen mit vi /tmp/patch_list_gihome.txt /opt/oracle/install/33182768/33192793 /opt/oracle/install/33182768/33208123 /opt/oracle/install/33182768/33208107 /opt/oracle/install/33182768/33239955 /opt/oracle/install/33182768/32585572 /opt/19c/grid/OPatch/opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_gihome.txt
- Datenbank
srvctl stop database -d GPIDB # pürfen das aus den beteiligten Oracle Homes nichts mehr läuft/zugreift das nicht von Oracle ist wie ein Tomcat der sich das Java aus dem Oracle Home läuft. ps uafx | grep java
- Grid Home als „root“ mit root patchen
export PATH=$PATH:/opt/19c/grid/OPatch cd /opt/oracle/install/33182768/ opatchauto apply /opt/oracle/install/33182768 -oh /opt/19c/grid # bei Fehlern , Fehler fixen und neu starten mit # opatchauto resume
- Als User „grid“ testen ob alles wieder oben ist:
crsctl status resource -t
Zur Überwachung in einer zweiten Session mit adrci ein Tail auf das Cluster Log starten (über das Oracle Home ! nicht das Grid Home verwenden!)
# Oracle DB Home setzen damit keine Libs aus dem grid home verwendet werden! adrci adrci>show homes adrci>set home diag/crs/racdb01/crs adrci>show alert -tail -f
Datenbank Umgebung
ADRCI von oben zuvor stoppen!
- Opatch austauschen als user Oracle:
# User Oracle cd $ORACLE_HOME mv OPatch/ OPatch_orig unzip -q /install/p6880880_19000_Linux-x86-64.zip cd OPatch ./opatch version OPatch Version: 12.2.0.1.27
- Datenbank aus dem Oracle Home stoppen
srvctl stop database -d GPIDB # prüfen das nichts aus dem Oracle Home der DB läuft ps -uafx | grep oracle
- Patch in das Home einspielen
unzip p33192793_190000_Linux-x86-64.zip cd 33192793 /opt/oracle/product/19c/dbhome_1/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ # wenn alles gut: /opt/oracle/product/19c/dbhome_1/OPatch/opatch apply
- Data Patch in die DB einspielen
#sqlplus / as sysdba # #SQL> startup #SQL> exit # alternativ srvctl start database -d GPIDB cd $ORACLE_HOME/OPatch ./datapatch -verbose
- Datenbank neu übersetzen
sqlplus / as sysdba @?/rdbms/admin/utlrp.sql
- Applikationen prüfen / neu starten etc.