Gunther Oracle APEX und Datenbank Wiki

Oracle 12c R1

Erstellt: April 2015, überarbeitet April 2016

Bis auf den entscheidenden Unterschied, das mit der Release 2 der 12c, der Installer des Clustes aus einem kopierten Software Home aufgerufen wird, passen die folgenden Punkte auch noch gut zu einer Relase R2 Cluster installation, siehe auch ⇒ Anmerkungen zu einer Installation vom Oracle Real Application Cluster 12c R2 auf Oracle Linux x64 7.3.

Bzgl. Upgrade der Umgebung siehe Oracle Clusterware 12c R1 auf Oracle 12c R2 mit minimaler Downtime upgraden - Rolling Upgrade auf 12c R2 Cluster.

Die Größenanfordungen für die Managemnt DB scheint aber höher geworden zu sein ( min. mehr als 28GB!), soll dann dies mit auf die Voting Disks sollten diese also recht groß ausgelegt werden! Besser ist das dann wohl für diesen Bereich eine eigene Diskgroup mit ca. 50GB einzuplanen.

Als Betriebssystem wird Oracle Linux 7.2 eingesetzt.

Die Anbindung der Lun's für die Cluster Platten erfolgt über das iSCSI Protokoll.

D.h. die Test Umgebung wird unter VMware mit drei Maschinen abgebildet, zwei DB Knoten mit je 6 GB RAM / 2CPU und einen iSCSI Target mit 2GB RAM / 2CPU für die shared Disks (alle unter Oracle Linux 7).

Zusätzlich kommt als DNS und Zeitserver ein Raspberry PI mit PowerDNS mit 512BM RAM zum Einsatz.

Die Grid Software benötigt 6,9GB an Plattenplatz.

Für den Interconnect können ab Oracle 11g 11.2.0.2 auch zwei Netzwerk Interfaces verwendet werden, dann kann das Bonding der Netzwerkkarten auf den Interconnect Interface in einer produktiven Umgebung entfallen. Diese HAIP Feature soll unter anderen in dieser Testinstallation untersucht werden.

Die Empfehlung von Oracle ist es auch zwei unterschiedliche Netzwerke und Netzwerkmasken für diese Interfaces zu verwenden.

Netto sind für das OCR Volume mit dem Grid Infrastructure Management Repository (4.5 GB + 300 MB Voting files + 400 MB OCR) bis 5 Knoten ca. 5.2 GB notwendig, für jeden weiteren Knoten müssen weitere 500 MB eingeplant werden.

In dieser Installation sollen die Oracle Clusterware files (OCR und Voting files) und das Grid Infrastructure Management Repository redundant über die Oracle Software gespiegelt werden, dazu sind bei „external redundancy“ zum Beispiel drei Platten a ~5.2 GB bzw. 6 GB notwendig.

Siehe Table 7-5 Oracle Clusterware Minimum Storage Space Required by Redundancy Type in der Dokumentation.

Auch liegt per Default die Cluster Management Datenbank auf diesen Platten! Das ist deutlich mehr als in der Version 11g, dort waren 2GB mehr als ausreichend und könnten bei Upgrade zu Problemen führen!

Nach einer 12.2.0.2 Installation wird automatisch eine Datenbank „MGMTDB“ mit auf dem ersten Knoten angelegt.

Die Datendateien liegen dabei mit auf den VOT Platten.

In dieser Datenbank liegen auch die Cluster Health Monitor (CHM) Daten , die noch zuvor in der Version 11g in einer Berkley Datenbank lagen siehe auch Oracle Real Application Cluster Resource “ora.crf” – Der Cluster Health Monitor - 11g

Mehr zu der Oracle Grid Infrastructure Management Repository (GIMR) siehe ⇒ Oracle Clusterware 12c - Grid Infrastructure Management Repository (GIMR)

1. Bereitstellen der notwendigen Software
2. Storage bereitstellen
3. DNS Server konfigurieren
4. Zwei Linux Server installieren und Betriebssystem für den Oracle RAC Betrieb optimieren
5. Oracle Clusterware Software unter dem User „grid“ installieren
6. Oracle Datenbank Software unter dem User „oracle“ installieren
7. Datenbank GPIDB aufsetzen
8. Aktuellen Patch Level „rolling“ (im laufenden Betrieb) einspielen

Über das Support Portal die Zertifizierung überprüfen:

• Oracle Database 12.1.0.2.0 is certified on Linux x86-64 Oracle Linux 7 !
• Oracle Clusterware 12.1.0.2.0 is certified on Linux x86-64 Oracle Linux 7

Damit steht einer Oracle RAC Installation auf Linux 7 in der Version 12c R1 nicht mehr im Wege.

Software über https://edelivery.oracle.com/ herunterladen.

• V46095-01_1of2 .zip - database Part 1
  • MD5 080435A40BD4C8DFF6399B231A808E9A
• V46095-01_2of2 .zip - database Part 2
  • MD5 30F20EF9437442B8282CE3984546C982

• V46096-01_1of2.zip - Grid Part 1
  • MD5 D793C2BA5DB9008B79077BFF8D27A219
• V46096-01_1of2.zip - Grid Part 2
  • MD5 0E18A9ABB80427BAF18F85865B1ECD5D

Siehe Support Dokument ⇒ Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets (Doc ID 1454618.1)

Patch 19954978: GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.2.2 (JAN2015) für Linux x86

• p19954978_121020_Linux-x86-64.zip 872.9 MB (915338678 bytes)
  • MD5 05C9874AD19DE97328B3F4EAF91C3885

Java Patch Set

• Oracle Recommended Patches – „Oracle JavaVM Component Database PSU“ (OJVM PSU) Patches (Doc ID 1929745.1)

ACFS Patch für Linux 7

• Patch: 18321597 (Patch 18321597: ACFS SUPPORT FOR RHEL7 AND OL7 )

Patch 6880880: OPatch patch of version 12.1.0.1.6 for Oracle software releases 12.1.0.x (JAN 2015)

• p6880880_121010_Linux-x86-64.zip 49.8 MB (52216311 bytes)
  • MD5 12B0BD2668874C86F26694EAEFA02CD4

Siehe folgende Note um ORAchk zu laden:

• ORAchk - Health Checks for the Oracle Stack (Doc ID 1268927.2)

Download unter :

• http://www.oracle.com/technetwork/database/options/clustering/downloads/cvu-download-homepage-099973.html

Die „LINUX x86-64 ⇒ Download Linux (x86-64) (December 2013)“ ist tatsächlich die aktuelle Version auch für 12c, es kommt zum Schluss eine Version „12.1.0.1.0“ zum Vorschein…

Siehe auch http://www.hhutzler.de/blog/cluvfy/#impact-of-latest-cluvfy-version

Für das Oracle RAC Cluster werden zwei Linux Server aufgesetzt und die Basis Konfiguration für eine solche Umgebung auf den Servern durchgeführt.

Ein Server für eine RAC Umgebung besitzt mindestens zwei Netzwerk Karten.

Ein Oracle Real Application Cluster benötigt pro Host mindestens 4 IP Adressen:

• Die physikalische IP Adressen - fest auf das Interface konfiguriert
• Die VIP Adresse - IP Adresse wird vom Cluster verwaltet und auf das öffentliche Interface der Maschine im laufenden Cluster Betrieb gebunden
• Eine SCAN IP Adresse - Wird später für den SCAN Listener verwendet
• Eine IP Adresse auf einem privaten Netz für die Cluster Kommunikation

Um den Interconnect auch Ausfallsicher ohne komplexes Network Bonding zu gestalten, können bis zur vier Interfaces für den privaten Interconnect hinterlegt werden, diese sollen sogar in unterschiedlichen Netzen liegen, siehe auch:

• ⇒ RAC Grid Infrastructure Redundant Interconnect
• ⇒ 5.3 Private Interconnect Redundant Network

Die IP Adressen müssen alle über eine Namensauflösung vom den DB Knoten aufgelöst werden, ein Eintrag in die Host Datei ist dabei NICHT ausreichend.

Die Interfaces Name müssen auf allen DB Knoten gleich lauten! Daher die neue Linux 7 Namensgebung auch wieder dekonfiguriert.

Nach der Grundinstallation der Server ist vorerst nur per Ping auf die physikalische und die Interconnect IP Adresse(n) ansprechbar, die anderen Adressen werden erst zusammen mit der Cluster Software aktiv.

Übersicht:

Mit diesen Informationen wird ein entsprechenden Nameserver in der Umgebung aufgebaut, zum Beispiel mit dem DNS Server „PowerDNS“ siehe Raspberry PI als DNS Applicance für PowerDNS oder PowerDNS 4.x - Ein Alternative für BIND - Mit einer Oracle Datenbank als Backend verwenden

Überprüfen, ob das alles auch richtig per DNS aufgelöst wird:

#Domain abfragen mit:
host -l pipperr.local | sort
 
ns1.pipperr.local has address 192.168.178.100
pipperr.local name server ns1.pipperr.local.
 
racdb01-haip.pipperr.local has address 10.1.1.191
racdb01-priv.pipperr.local has address 10.1.1.190
racdb01-vip.pipperr.local has address 10.10.10.192
racdb01.pipperr.local has address 10.10.10.190
 
racdb02-haip.pipperr.local has address 10.1.1.195
racdb02-priv.pipperr.local has address 10.1.1.194
racdb02-vip.pipperr.local has address 10.10.10.196
racdb02.pipperr.local has address 10.10.10.194
 
scanracdb.pipperr.local has address 10.10.10.200
scanracdb.pipperr.local has address 10.10.10.210

Alternativ lässt sich auch die Aufgabe des DNS Service für die Cluster relevanten Anfragen an einen eigenen Dienst im RAC, den GNS, delegieren.

Nur die Domain wird im „großen“ DNS hinterlegt, für diese wird dann der GNS als nächster zu fragende DNS Server hinterlegt.

Siehe auch im Detail:

• https://martincarstenbach.wordpress.com/2011/11/17/simplified-gns-setup-for-rac-11-2-0-2-and-newer/
• www.youtube.com/watch?v=qqUJFNByYp0
• https://docs.oracle.com/database/121/CWLIN/networks.htm#CWLIN214
• Node DNS and DHCP Setup Example for Grid Infrastructure GNS (Doc ID 946452.1)

Beide Server müssen dabei möglichst identisch aufgesetzt werden.

• ⇒ Ein Oracle Linux 7 Basis System als Grundlagen für eine Oracle Clusterware und Datenbank Installation vorbereiten

Ist der erste Server soweit wie beschrieben aufgesetzt, kann die Maschine geklont und der Klone als zweite RAC Umgebung angepasst werden.

Danach kann der SSH Key der User oracle, grid und root unter den Maschinen verteilt werden.

siehe SSH Key's austauschen

als root, grid, oracle User

#generate key on every node
ssh-keygen -t rsa
#self
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh racdb01
#key on 2
ssh racdb02 ssh-keygen -t rsa
# Copy public key from one node to the other
#2 to 1 
ssh  racdb02 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
#1 to 2
ssh racdb02
ssh racdb01 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
#self
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh racdb02

Testen auf JEDEM Knoten mit:

ssh -o NumberOfPasswordPrompts=0 -o StrictHostKeyChecking=no -l $USER racdb01 "echo check ssh connect"
ssh -o NumberOfPasswordPrompts=0 -o StrictHostKeyChecking=no -l $USER racdb02 "echo check ssh connect"

Für den Betrieb des Clusters werden gemeinsame Platten benötigt.

Für diesen Test werden die Lun's als iSCSI Ziele realisiert. Für die Vorbereitung des Storage Servers siehe auch:

• ⇒ iSCSI Target für das Bereitstellen von Cluster Platten in VMWare unter Linux 7

User: root

yum install oracleasm-support

User: root

Damit der Grid User UND der Oracle User auf die Platten zugreifen, die Gruppe asmadmin gewählt!

oracleasm configure -i
 
Default user to own the driver interface []: grid
Default group to own the driver interface []: asmadmin  
Scan for Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration: done

Ist Multipatching im Einsatz muss nun des Scan bei start der ASM Library auf die Multipath Pfade eingeschränkt werden:

vi /etc/sysconfig/oracleasm
 
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER="dm"
 
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE="sd"

siehe auch http://www.oracle.com/technetwork/topics/linux/multipath-097959.html

Als user root!

oracleasm init

User: root

Vorgeschlagener Scheduler von Oracle „Deadline disk I/O scheduler“

#prüfen ob bereits ok
cat /sys/block/${ASM_DISK}/queue/scheduler
noop [deadline] cfq
 
#setzen bei Bedarf über Script mit:
 
echo deadline > /sys/block/${ASM_DISK}/queue/scheduler

In meiner Umgebung bereits von der ASM Lib so vorbelegt und damit ok.

Zuerst die Software auf dem ersten Host auspacken und mit dem Cluster Verification Utility das Betriebssystem und die Konfiguration der Umgebung überprüfen.

Testen ob „unzip“ zur Verfügung steht und bei Bedarf als root mit „yum install zip unzip“ nachinstallieren.

User grid

Verzeichnis „/home/grid/install/grid2 auf dem ersten Knoten anlegen und dort die Clusterware Software mit md5sum prüfen (Ergebnis genau prüfen um Download Fehler zu vermeiden!) und auspacken:

mkdir /home/grid/install/grid
 
#Software Pakete V46096-01_1of2.zip und V46096-01_2of2.zip
 
md5sum V46096-01_1of2.zip
d793c2ba5db9008b79077bff8d27a219  V46096-01_1of2.zip
 
md5sum V46096-01_2of2.zip
0e18a9abb80427baf18f85865b1ecd5d  V46096-01_2of2.zip
 
 
unzip V46096-01_1of2.zip
unzip V46096-01_2of2.zip
 
# die Software wird in das Verzeichnis „grid“ ausgepackt

Das unbedingt unter dem OS User „grid“ durchführen!

Auf dem Installationsmedium liegt das cvuqdisk RPM für das Cluster Verification Utility, ohne das Packet kann clufy nicht die gesharten Platten erkennen.

User:root

Hier wieder als root user anmelden und auf BEIDEN Knoten installieren!

su -
 
cd /home/grid/install/grid/rpm
 
CVUQDISK_GRP=oinstall; export CVUQDISK_GRP
 
yum install –nogpgcheck  cvuqdisk-1.0.9-1.rpm
 
#Install on second node
 
scp cvuqdisk-1.0.9-1.rpm root@racdb02:/tmp
ssh racdb02
 
CVUQDISK_GRP=oinstall; export CVUQDISK_GRP
yum install –nogpgcheck  /tmp/cvuqdisk-1.0.9-1.rpm
rm /tmp/cvuqdisk-1.0.9-1.rpm
exit
 
 
#prüfen ob auch wirklich installiert:
yum list  | grep cvuqdisk

Mit dem „Cluster Verification Utility“ wird die Umgebung genauestens überprüfen, es dürfen keinerlei Fehler, egal wie nebensächlich die Fehler scheinen, übrig bleiben.

Können diese Testes erfolgreich und positiv abgeschlossen werden, kann meist die Software dann problemlos und ohne große Mühe installiert werden!

User grid

cd cd /home/grid/install/grid
 
./runcluvfy.sh comp nodereach -n racdb01,racdb02 -verbose
 
Verifying node reachability
 
Checking node reachability...
 
Check: Node reachability from node "racdb01"
  Destination Node                      Reachable?
  ------------------------------------  ------------------------
  racdb01                               yes
  racdb02                               yes
Result: Node reachability check passed from node "racdb01"
 
 
Verification of node reachability was successful.

cd /home/grid/install/grid
 
./runcluvfy.sh comp nodecon -n racdb01,racdb02 -verbose

Dieser Test funktioniert in der aktuellen Version nicht wie geplant, für diesen Test muss die separat erhältliche Download Version verwendet werden. Test mit der Version im Gird Install Verzeichnis:

cd /home/grid/install/grid
 
./runcluvfy.sh comp ssa -n  racdb01,racdb02 -verbose
 
No shared storage found
 
 
Shared storage check failed on nodes "racdb01,racdb02"
 
Verification of shared storage accessibility was unsuccessful on all the specified nodes.
 
#Test mit Device Angabe ergibt den Fehler:
 
 
./runcluvfy.sh comp ssa -n  racdb01,racdb02 -verbose -s /dev/oracleasm/disks/DATA01
 
Verifying shared storage accessibility
 
Checking shared storage accessibility...
 
ERROR:  /dev/oracleasm/disks/DATA01
PRVG-11502 : Path "/dev/sdb1" of type "Disk" is not suitable for usage as RAC database file for release "12.1". Supported storage types are "NFS, ASM Disk Group, OCFS2, VXFS, ACFS".
 
 
Shared storage check failed on nodes "racdb01,racdb02"
 
Verification of shared storage accessibility was unsuccessful on all the specified nodes.
 
#test der Platten als root
 
blkid | grep asm
/dev/sdb1: LABEL="DATA01" TYPE="oracleasm"
 
 
oracleasm listdisks
DATA01

Mit der eigenständig heruntergeladenen clufy Version kann aber der Test erfolgreich durchgeführt werden!

Hard- und Software Voraussetzungen prüfen lassen:

cd /home/grid/install/grid
 
./runcluvfy.sh stage -post hwos -n racdb01,racdb02 -verbose

Voraussetzungen für die gesamte Installation prüfen:

cd /home/grid/install/grid
 
./runcluvfy.sh stage -pre crsinst  -n racdb01,racdb02 -verbose

Problem:

PRVE-0426 : The size of in-memory file system mounted as /dev/shm is "2101248k" megabytes which is less than the required size of "2048" megabytes on node ""

Kann ignoriert werden ⇒ see Support Note „The size of in-memory file system mounted at /dev/shm is „24576“ megabytes which does not matccd ..h the size in /etc/fstab as „0“ megabytes (Doc ID 1918620.1)“

User: grid

Darauf achten das das X Forwarding auch funktioniert!

Testen mit:

# vom Rechner mit der X Oberfläche auf den DB Knoten zugreifen
ssh -X racdb01
 
#Display setzen oder XAuth konfigurieren
# testen mit:
/usr/bin/xdpyinfo
 
#Muss die Parameter des Remote X zeigen

cd /home/grid/install/grid
./runInstaller

Problem:

[INS-30515] Insufficient space available in the selected disks. ⇒ VOTING Platten zu klein gewählt! ⇒ d.h. für die Version 12c ca. ~ 6GB pro Lun einplanen.

Ablauf:

Schritt	Bemerkung	Screenshot
1	Install Option: „Install and Configure“
2	Configure a Standard Cluster
3	Advanced Installation
4	Product Language - English
5	Cluster Name ⇒ „racdbCluster“ + Scan Listener DNS Name ⇒ „scanracdb.pipperr.local“ + Scan Port ⇒ 1521„ - Kein GNS
6	Zweiten Knoten hinzufügen (racdb02.pipperr.de - racdb02-vip.pipperr.de )
7	Netzwerk Interfaces zuordnen
8	Use ASM for Standard Storage
9	ASM Platte für OCR/VOT anlegen, dazu den Discovery Patch anpassen auf “/dev/oracleasm/disk/*„ , die drei VOT Platten auswählen und den DISK Namen in „VOT“ ändern
10	ASM Passwörter setzen
11	Kein IPMI verwenden
12	Oracle Enterprise Manager ausswählen falls vorhanden
13	Gruppen auswählen
14	Oracle Base ⇒ “/opt/oracle„ und Grid Home ⇒ “/opt/12.1.0.2/grid„
15	Directory für das Oracle Inventory auswählen ⇒ “/opt/oraInventory„
16	Automatische Konfiguration - abgewählt da breits alles vorbereitet
17	Überprüfen der Umgebung - Ergebnisse bewerten und Schalter für Ignore All setzen, wenn soweit ok und weiteren Warnhinweis mit „Yes“ bestätigen
18	Summary - Response File speichern
19	Installation läuft, Root Script Hinweis beachten und die Scripte je erst auf 1 und 2 ausführen. Nicht parallel! Erst die aus dem OraInventory auf 1 und dann auf 2, dann root.sh auf 1, das kann ca 5. bis 10 Minuten dauern bis je nach Leistungsfähigkeit der Umgebung. Folgende Meldung zeigt den Erfolg an: „2015/03/22 14:37:54 CLSRSC-325: Configure Oracle Grid Infrastructure for a Cluster … succeeded“, danach auf Knoten 2 starten. Das eigentliche Cluster wird mit diesem Schritt angelegt, schläft das fehl, kann nicht weiter installiert werden bis der Fehler behoben ist!
	Konfigurations-Assistenten laufen durch, je nach System kann das etwas dauern, in dieser VM Umgebung ~ 10minuten
	Fehler Meldung mit dem Oracle Cluster Verification Utility ⇒ Kann erstmal ignoriert werden, wir hatte ja schon zuvor Fehler mit dem Tool bzgl. Erkennen der ASM Platten und NTP
20	Abschluss der Installation, Fehler vom Schritt zuvor mit YES bestätigen und Fenster mit Close schließen

Anmerkungen

Schritt Überprüfung

Bei der Überprüfung der Umgebung im Schritt 17 konnten folgende Ergebnisse nicht nachvollzogen werden:

• Checks whether /dev/shm is mounted correctly as temporary file system
  • ⇒ mit df - h überprüft ist da
• This test verifies the Single Client Access Name configuration
  • ⇒ 3 Wird vom Test Verlangt, in einem zwei Knoten Cluster
• This task verifies cluster time synchronization on clusters that use Network Time Protocol (NTP)
  • ⇒ ntp läuft!
• This is a prerequisite check to verify that the specified devices meet the requirements for ASM
  • ⇒ Platten ok, test mit andere Clufy Version erfolgreich
• This is a prerequisite condition to test whether sufficient total swap space is available on the system
  • ⇒ OK für ein Test System
• This is a prerequisite condition to test whether the system has at least 4GB (4194304.0KB) of total physical memory
  • ⇒ ok für ein testsystem

Schritt root.sh

Da root.sh einen Fehler ausgibt (sh: /bin/netstat: No such file or directory ) ist doch die Installation der Linux 6 Tools zu empfehlen (yum install net-tools)!

Probleme bei der ersten Installation:

Das Root Script auf dem ersten Knoten bricht mit folgendem Fehler ab:

...
ASM created and started successfully.

Disk Group VOT mounted successfully.

2015/03/15 16:58:46 CLSRSC-12: The ASM resource ora.asm did not start

2015/03/15 16:58:47 CLSRSC-258: Failed to configure and start ASM

Died at /opt/12.1.0.2/grid/crs/install/crsinstall.pm line 2017.
The command '/opt/12.1.0.2/grid/perl/bin/perl -I/opt/12.1.0.2/grid/perl/lib -I/opt/12.1.0.2/grid/crs/install /opt/12.1.0.2/grid/crs/install/rootcrs.pl ' execution failed

Alert log der ASM Instance geprüft, nichts auffälliges (unter $ORACLE_BASE/diag ).

Nochmals versuchen, dazu zuvor wieder deconfigurieren mit dem Perl aus dem Oracle Home!:

cd /opt/12.1.0.2/grid/crs/install/
 
/opt/12.1.0.2/grid/perl/bin/perl rootcrs.pl -verbose -deconfig -force

Wird das Perl aus dem OS verwendet, trifft man auf den folgenden Bug „rootcrs.pl/roothas.pl Fails With „Can't locate Env.pm“ (Doc ID 1925577.1)“

Im ersten Schritt vermutet, dass die ASM Instance nicht schnell genug startet, Leistung der VM Maschinen erhöht (6GB RAM + 2 CPU) und nochmals installiert, jetzt lief die Installation erfolgreich durch!

Troubleshooting :

• http://www.hhutzler.de/blog/troubleshooting-clusterware-startup-problems/
• http://www.hhutzler.de/blog/troubleshooting-clusterware-startup-problems-dtrace/

Im Anschluss die Umgebung überprüfen:

export ORACLE_HOME=/opt/12.1.0.2/grid/
 
./crsctl check cluster
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
 
cd $ORACLE_HOME/bin
./crs_stat -t -v

export  ADR_BASE=/opt/oracle
export ORACLE_HOME=/opt/12.1.0.2/grid
$ORACLE_HOME/bin/adrci
 
 
adrci
adrci> show alert
 
..
3: diag/crs/racdb01/crs
...
 
Please select option: 3
 
#Logs auf Auffälligkeiten Prüfen

see:

• 12.1.0.2 Oracle Clusterware Diagnostic and Alert Log Moved to ADR (Doc ID 1915729.1)

Kontrolle:

$ORACLE_HOME/bin/crsctl get css logfilesize
CRS-4676: Successful get logfilesize 52428800 for Cluster Synchronization Services.

Vergrößern (auf beiden Knoten durchführen!): User: root

su -
 
export ORACLE_HOME=/opt/12.1.0.2/grid
$ORACLE_HOME/bin/crsctl set css logfilesize 157286400
CRS-4686: Successful set logfilesize 157286400 for Cluster Synchronization Services.

Nach der Grid Installation die Umgebung mit „ORAchk“ überprüfen, siehe Support Node „ORAchk - Health Checks for the Oracle Stack (Doc ID 1268927.2)“

Ablauf im Detail siehe Oracle 12c RAC Umgebung mit ORAchk überprüfen

Die bei diesen Test erzeugten Berichte auswerten und die Probleme beheben.

Je nach Geschmack empfiehlt es sich ein Script unter den User grid zu setzen, das die Umgebung einstellt und einen schnellen Zugriff auf oft benötigte Dateien ermöglicht.

Wie ⇒ Arbeitsumgebung setzen und Einrichten unter Windows und Linux

Ich verwende dazu folgendes Script .profile und folgende .bash_profile

• Script “.profile„ nach “~/„ Home des Grid Users kopieren
• den Aufruf in die “.bash_profile„ eintragen bzw. “.bash_profile„ ersetzen
• Verzeichnis ~/sql anlegen und zum Beispiel die SQL Script von Gunther SQL Scripte dorthin kopieren
• Auf den anderen Knoten verteilen

  ssh racdb02 mkdir ~/sql 
  scp .bash_profile .profile racdb02:$PWD/
  scp *.* racdb02:$PWD/

• neu anmelden bzw. mit “. .bash_profile„ Umgebung neu sourcen/einlesen
• Setup wird automatisch durchgeführt, damit muss die Nummer des aktuellen Knoten (für den ersten Knoten die 1 angegeben werden!)
• Mit „setdb“ kann nun die vorgefunden Umgebung gesetzt werden (ORACLE_SID/ORALCE_HOME/Pfade etc.)

Auf beiden Knoten einrichten!

User: grid

Der Oracle Listener läuft im Cluster, diesen prüfen und optimieren.

Auf JEDEM knoten die Datei „sqlnet.ora“ anpassen:

vi $ORACLE_HOME/network/admin/sqlnet.ora
 
# Parameter for the listner, check after 30min if connection is still alive
SQLNET.EXPIRE_TIME = 30

srvctl config scan

Siehe auch:

• http://externaltable.blogspot.de/2014/01/clusterware-12c-and-restricted-service.html

Test ob nach einem Boot das Cluster sauber startet und alles soweit funktioniert.

#ersten Knoten stoppen
reboot
 
#30s warten
 
#zweiten Knoten stoppen
reboot

Mal eine kurze Pause einlegen, ca. 2-5 Minuten warten, damit das Cluster Zeit hat alles zu starten.

Prüfen:

#Umgebung setzen setdb
 
#prüfen (mit alten Werkzeug .-) )
crs_stat -t -v

User: grid

Vor der Datenbank Installation die ASM Disk Groups anlegen:

Im ersten Schritt werden in dieser Umgebung je nur eine ASM Platte per Disk Group hinzugefügt, die andere Platten werden je nach Bedarf erst im laufenden Betrieb hinzugefügt.

#umgebung auf das Grid Home  setzen 
#in meiner Umgebung mit setdb 1
 
asmca &

Auf den Reiter „Disk Groups“ wechseln und die Disk Group „REDOA“ anlegen

• 
• 
  • Für die Redo Platten verbleibt die ASM Stripe Size auf 1MB (kann über die „Advanced Options“ eingestellt werden)

# Umgebung auf die ASM Instance setzen
# IN meiner Umgebung mit setdb 1
 
sqlplus / AS sysasm
 
CREATE diskgroup redob  external redundancy disk '/dev/oracleasm/disks/red02' attribute 'au_size'='1m' ;
CREATE diskgroup DATA   external redundancy disk '/dev/oracleasm/disks/data01' attribute 'au_size'='4m' ;
CREATE diskgroup fra    external redundancy disk '/dev/oracleasm/disks/data02' attribute 'au_size'='1m' ;
 
# auf zweiten Knoten an der ASM Instance anmelden und die Platte dort auch mounten
 
ssh racdb02
# Umgebung auf die ASM Instance setzen
# IN meiner Umgebung mit setdb 1
sqlplus / AS sysasm
 
ALTER diskgroup REDOB  mount;
ALTER diskgroup FRA mount
ALTER diskgroup DATA mount
 
#prüfen ob die Platte im Rac Sichtbar ist:
 
crs_stat -t
 
Name           TYPE           Target    State     Host
------------------------------------------------------------
ora.REDOB.dg   ora....up.type ONLINE    ONLINE    racdb01
 
#OK!

siehe 12c Doku - Using the CREATE DISKGROUP SQL Statement

asmcmd
 
 
ASMCMD> lsdg
 
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  EXTERN  N         512   4096  4194304     20476    20360                0           20360              0             N  DATA/
....
 
ASMCMD> iostat
Group_Name  Dsk_Name    Reads      Writes
VOT         VOT_0000    133532160  86607872
 
...

User:root

#Platten anzeigen
lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdc           8:32   0   20G  0 disk
└─sdc1        8:33   0   20G  0 part
 
#prüfen ob die Platte noch frei ist
 
oracleasm  querydisk -v /dev/sdc1
Device "/dev/sdc1" is not marked as an ASM disk
 
#ASM Disk anlegen
 
oracleasm createdisk ACFS01 /dev/sdc1
Writing disk header: done
Instantiating disk: done
 
#auf jedem knoten erkennen lassen
oracleasm scandisks; oracleasm listdisks
ssh racdb02 oracleasm scandisks; oracleasm listdisks

User:grid

# Umgebung auf die ASM Instance setzen
# IN meiner Umgebung mit setdb 1
 
sqlplus / AS sysasm
 
CREATE diskgroup ACFS  external redundancy disk '/dev/oracleasm/disks/ACFS01';
 
# auf zweiten Knoten an der ASM Instance anmelden und die Platte dort auch mounten
 
ssh racdb02
# Umgebung auf die ASM Instance setzen
# IN meiner Umgebung mit setdb 1
sqlplus / AS sysasm
 
ALTER diskgroup ACFS  mount;

Zertifzierung prüfen

siehe ⇒ Node „ACFS Support On OS Platforms (Certification Matrix). (Doc ID 1369107.1)“

Daraus folgt zur Zeit 03.2015:

• Für Linux 7 ⇒ 12.1.0.2.1 + Patch: 18321597 (Patch 18321597: ACFS SUPPORT FOR RHEL7 AND OL7 )

Update - April 2016 - Patch ist nun bereits im PSU für Januar 2016 enthalten,daher hier gleich diesen einspielen!

Für die Installation muss auch OPatch auf jeden Knoten aktualisiert werden.

Beide Archive unter den User Grid auf den ersten Knoten herunterladen, zum Beispiel nach /home/grid/install/patch

Patch herunterladen und prüfen

cd /home/grid/install/patch
 
md5sum p18321597_121021forACFS_Linux-x86-64.zip
bc62e74c58ab36018f5bfb4835921287  p18321597_121021forACFS_Linux-x86-64.zip
 
#=> Mit Wert vom Support Portal vergleichen MD5	BC62E74C58AB36018F5BFB4835921287 OK!
 
 
md5sum p6880880_121010_Linux-x86-64.zip
 
12b0bd2668874c86f26694eaefa02cd4  p6880880_121010_Linux-x86-64.zip

Installieren

#
# auf jedem Knoten OPatch  aktualisieren und den Patch einspielen!
#
 
# Zuvor als root Schreibrechte der oinstall Gruppe testen!
#
# falls keine Rechte Schreibrecht für die oinstall Gruppe auf das Grid Home Verzeichnis einrichten!
 
#als Root 
chmod g+w $ORACLE_HOME
ssh racdb02 chmod g+w $ORACLE_HOME
 
 
#als grid User
# Grid Oracle Home setzen
 
$ORACLE_HOME/OPatch/opatch version
OPatch Version: 12.1.0.1.3
 
 
cd /home/grid/install/patch
 
mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_old
unzip p6880880_121010_Linux-x86-64.zip -d $ORACLE_HOME
 
$ORACLE_HOME/OPatch/opatch version
OPatch Version: 12.1.0.1.6
 
 
ssh racdb02 mkdir -p /home/grid/install/patch
scp p6880880_121010_Linux-x86-64.zip racdb02:/home/grid/install/patch
ssh racdb02
 
#nun gleiche Schritte wie auf Node 1 um OPatch auszutauschen
mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_old
unzip p6880880_121010_Linux-x86-64.zip -d $ORACLE_HOME
$ORACLE_HOME/OPatch/opatch version
 
#
#Patch aber auch gleich wieder löschen!
rm p6880880_121010_Linux-x86-64.zip

Für das Auto Einspielen vom ACFS Patch die Antwort Datei auf Knoten 1 erstellen:

cd /home/grid/install/patch
 
##########################################
#OCM Configuration anlegen
 
$ORACLE_HOME/OPatch/ocm/bin/emocmrsp
 
OCM Installation Response Generator 10.3.7.0.0 - Production
Copyright (c) 2005, 2012, Oracle and/or its affiliates.  All rights reserved.
 
Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:
 
You have not provided an email address for notification of security issues.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]:  Y
The OCM configuration response file (ocm.rsp) was successfully created.
 
#########################################
#Datei ocm.rsp wurde nun unter /home/grid/install/patch angelegt

Patch als Grid User auspacken und als root User auf JEDEN Knoten einspielen.

Erst auf Knote 1 und dann die gleichen Schritte auf dem Knoten 2!

cd /home/grid/install/patch
 
#Patch auspacken als Grid User
unzip p18321597_121021forACFS_Linux-x86-64.zip -d ./acfs_patch/
 
#Auf den zweiten Knoten kopieren und dort auch auspacken
scp p18321597_121021forACFS_Linux-x86-64.zip racdb02:/home/grid/install/patch
scp ocm.rsp racdb02:/home/grid/install/patch
ssh racdb02 
unzip /home/grid/install/patch/p18321597_121021forACFS_Linux-x86-64.zip -d /home/grid/install/patch/acfs_patch/
 
 
#Erste Auf Knoten 1
##########################################
#Als user root automatisch im Cluster installieren
export ORACLE_HOME=/opt/12.1.0.2/grid
export PATH=$PATH:$ORACLE_HOME/OPatch
 
opatchauto apply /home/grid/install/patch/acfs_patch/18321597 -ocmrf /home/grid/install/patch/ocm.rsp
 
 
#Cluster auf dem lokalen Knoten wird gestoppt und gepatched OHNE weitere Rückfragen!
 
OPatch Automation Tool
Copyright (c)2014, Oracle Corporation. All rights reserved.
 
OPatchauto Version : 12.1.0.1.6
OUI Version        : 12.1.0.2.0
Running from       : /opt/12.1.0.2/grid
 
opatchauto log file: /opt/12.1.0.2/grid/cfgtoollogs/opatchauto/18321597/opatch_gi_2015-03-28_18-32-25_deploy.log
 
Parameter Validation: Successful
 
Configuration Validation: Successful
 
Patch Location: /home/grid/install/patch/acfs_patch/18321597
Grid Infrastructure Patch(es): 18321597
It does not contain any DB patch
 
Patch Validation: Successful
Grid Infrastructure home:
/opt/12.1.0.2/grid
 
 
Performing prepatch operations on CRS Home... Successful
 
Applying patch(es) to "/opt/12.1.0.2/grid" ...
Patch "/home/grid/install/patch/acfs_patch/18321597/18321597" successfully applied to "/opt/12.1.0.2/grid".
 
Performing postpatch operations on CRS Home... Successful
 
Apply Summary:
Following patch(es) are successfully installed:
GI Home: /opt/12.1.0.2/grid: 18321597
 
opatchauto succeeded.
 
#Nun auch auf Knoten 2
#
# gleicher Ablauf wie zuvor!
export ORACLE_HOME=/opt/12.1.0.2/grid
export PATH=$PATH:$ORACLE_HOME/OPatch
opatchauto apply /home/grid/install/patch/acfs_patch/18321597 -ocmrf /home/grid/install/patch/ocm.rsp

Überprüfen auf jeden Knoten:

#
# User grid
# 
$ORACLE_HOME/OPatch/opatch lsinventory
 
 
#+ACFS Testen:
 
#Als Grid
acfsdriverstate supported
ACFS-9200: Supported
 
#Als Root User!
 
[root@racdb01 ~]# /opt/12.1.0.2/grid/bin/acfsdriverstate version
ACFS-9325:     Driver OS kernel version = 3.8.13-35.3.1.el7uek.x86_64(x86_64).
ACFS-9326:     Driver Oracle version = RELEASE.

Wieder aufräumen und auf beiden Knoten die Patche löschen, die ocm.rsp aber stehen lassen!

cd /home/grid/install/patch
rm -rf acfs_patch/ p18321597_121021forACFS_Linux-x86-64.zip p6880880_121010_Linux-x86-64.zip

Ist der Treiber installiert kann das weitere Einrichten kerfolgen: Siehe dazu auch ⇒ Das Oracle ACFS Filesystem auf einer ASM Umgebung für 11g verwenden

Als User mit SYSASM Rechten über asmcmd anmelden:

#Anlegen
ASMCMD> volcreate -G ACFS -s 15G voldiag1

Möglicher Fehler:

ORA-15032: not all alterations performed
ORA-15221: ASM operation requires compatible.asm of 11.2.0.0.0 or higher (DBD ERROR: OCIStmtExecute)

Lösung: ompatible.asm höher stetzen und es erneut versuchen:

ASMCMD>setattr  -G ACFS compatible.asm 12.1 
ASMCMD> volcreate -G ACFS -s 15G voldiag1

#Anzeigen lassen:
ASMCMD> volinfo -G ACFS voldiag1
Diskgroup Name: ACFS
 
         Volume Name: VOLDIAG1
         Volume Device: /dev/asm/voldiag1-442
         State: ENABLED
         Size (MB): 15360
         Resize Unit (MB): 64
         Redundancy: UNPROT
         Stripe Columns: 8
         Stripe Width (K): 1024
         Usage:
         Mountpath:

Auf den Namen des Volume Device achten!

Als root:

/sbin/mkfs -t acfs /dev/asm/voldiag1-442
 
mkfs.acfs: version                   = 12.1.0.2.0
mkfs.acfs: on-disk version           = 39.0
mkfs.acfs: volume                    = /dev/asm/voldiag1-442
mkfs.acfs: volume size               = 16106127360  (  15.00 GB )
mkfs.acfs: Format complete.

Als root:

/sbin/acfsutil registry -a /dev/asm/voldiag1-442 /opt/oracle/diag_acfs
 
acfsutil registry: mount point /opt/oracle/diag_acfs successfully added to Oracle Registry

Als root:

/bin/mount -t acfs /dev/asm/voldiag1-442 /opt/oracle/diag_acfs
 
chown -R grid:dba /u01/app/oracle/diag_acfs
 
#All oracle stuff on the system schould use it
chmod 777 /u01/app/oracle/diag_acfs

Als Grid User:

cd /u01/app/oracle/diag_acfs
 
touch test.txt

Nach dem Anlegen auf Knote 1 ist auch alles bereits auf Knoten 2 verfügbar, evlt. ein 12c Feature? In der letzen 11g Installation musste das FS von Hand gemounted werden.

Beide Server neu starten, um zu prüfen ob das Filesystem danach auch noch automatisch zur Verfügung steht.

Etwas warten bis wirklich alles gestartet ist und dann prüfen:

acfsutil info fs
 
/opt/oracle/diag_acfs
    ACFS Version: 12.1.0.2.0
    on-disk version:       39.0
    flags:        MountPoint,Available
    mount time:   Sat Mar 28 20:35:35 2015
    allocation unit:       4096
    volumes:      1
    total size:   16106127360  (  15.00 GB )
    total free:   15994208256  (  14.89 GB )
    file entry table allocation: 49152
    primary volume: /dev/asm/voldiag1-442
....

Tip :

• Vergrößen mit „acfsutil size +20G /u01/app/oracle/diag_acfs“ falls auf der ASM Diskgroup noch Platz ist bzw. dort neue asm disk hinzufügen.
• Snapshot können von diesem Filesystem erzeugt werden „acfsutil snap create ….“

Die Datenbank Software wird unter dem User „oracle“ installiert, alles Default, keine Starter Datenbank.

mkdir oracle/install
 
cd /home/oracle/install
 
md5sum V46095-01_1of2.zip
080435a40bd4c8dff6399b231a808e9a  V46095-01_1of2-database.zip
#=> Vergleichen mit  Digest Info vom Download Portal MD5 080435A40BD4C8DFF6399B231A808E9A
 
 
md5sum V46095-01_1of2.zip
30f20ef9437442b8282ce3984546c982  V46095-01_2of2-database.zip
#=> Vergleichen mit  Digest Info vom Download Portal MD5 30F20EF9437442B8282CE3984546C982
 
OK!
 
unzip V46095-01_1of2.zip
rm V46095-01_1of2.zip
 
unzip V46095-01_2of2.zip
rm V46095-01_2of2.zip
 
cd database
 
./runInstaller

Der Installer starte, Screen durchgehen, im ersten Schritt aber NUR die DB Software instalieren

• Screen 1 - Hacken entfernen für E-Mail - next - Dialog bestätigen
• Screen 2 - „Install database Software only“ auswählen - next
• Screen 3 - „Oracle Real Application Cluster database installation“ auswählen - next
• Screen 4 - Prüfen das alle Cluster Knoten ausgewählt sind - next
• Screen 5 - Sprache Englisch auswählen - next
• Screen 6 - Nur die Enterprise Edition kann mit 12.1.0.2 installiert werden - next
• Screen 7 - Oracle Base = “/opt/oracle„ und Software Location = “/opt/oracle/product/12.1.0.2/dbhome_1„ - next
• Screen 8 - Gruppen auf Default belassen - next
• Screen 9 - Prerequisit Checks laufen - Bekannte Checks wie bei der Grid Installation können ignoriert werden - Ignore All Hacken setzen - next - Dialog bestätigen
• Screen 10 - Übersichtseite , Pfade sorgfältig prüfen und Response File speichern - Install auswählen
• Screen 11 - Install Screen zeigt Fortschritt an, Details über „Details“ ~ 5-15minuten je nach Umgebung
• Screen 11 - Root Script „root.sh“ im neuen $ORACLE_HOME laufen lassen - Auf JEDEN Knoten!
• Screen 12 - Rein DB Software Installation ist damit beendet

Interessanter weise ließen sich keine Feature der EE einzeln an oder abwählen ⇒ hier ist dann auch alles installiert .-).

Ähnlich wie zuvor unter den Grid User die Umgebung setzen, dazu als Root die .bash_profile und .profile vom Grid User zum Oracle User kopieren und die Rechte dem Oracle User vergeben.

Auf beiden Knoten!

#als root
cp /home/grid/.bash_profile /home/oracle
cp /home/grid/.profile /home/oracle
chown oracle:oinstall /home/oracle/.bash_profile /home/oracle/.profile

Als Oracle User neu einlogen und Frage nach dem Cluster Knoten beantworten.

SQL Verzeichniss ~/sql anlegen und die SQL Script dort hinein kopieren

Kann plötzlich der DB Link TNS Name nicht mehr in einer Cluster Umgebung aufgelöst werden, kann es daran liegen das zwar im Cluster erst in der Grid tnsnames gesucht wird und dann im Oracle Home der Datenbank, gelegentlich aber wieder um andersherum, je nach dem in welchen Context die DB wohl ursprünglich gestartet wurde.

Setzte daher die TNS_ADMIN für die Arbeitsumgebung auf die Grid Umgebung und verlinke aus der Oracle DB Home Umgebung auf diese tnsnames.ora und sqlnet.ora in der Grid Umgebung.

Dann gibt es nur eine Datei und wo was gepflegt werden muss, ist gelöst!

Verlinken:

#user Oracle
cd $ORACLE_HOME/network/admin
 
ln -s /opt/12.1.0.2/grid/network/admin/tnsnames.ora tnsnames.ora
ln -s /opt/12.1.0.2/grid/network/admin/sqlnet.ora sqlnet.ora

Die wichtigsten Informationen beim Aufsetzen der Datenbank sind:

• Zeichensatz
• Blockgröße

Alles andere lässt sich problemlos, zum Teil sogar online, später noch anpassen.

Limit Einstellungen des DB Prozesses pürfen:

ps uafx | grep smon
cat /proc/<pid of the smon proces>/limits | grep process

Hintergrund:

DB läuft im Scope des Clusters und erbt von dort auch die Limits, reichen diese nicht aus kann es zu diesem Fehler beim Amelden über den Listener kommen: „ORA-12518: TNS:listener could not hand off client connection“ (meist in System mit sehr hohen current Session Anzahlen) (siehe auch ⇒“ The processes and resources started by CRS (Grid Infrastructure) do not inherit the ulimit setting for „max user processes“ from /etc/security/limits.conf setting (Doc ID 1594606.1)„ ).

• Statspack falls keine Diagnostic/Tuning Pack Lizenz vorliegt

• Audit Log auf eigenen Tablespace auslagern

• Error Log Trigger siehe Erstellen eines Protokolls zur Überwachung von fehlerhaften SQL Statements in der Datenbank

Mit Swing Bench die Umgebung überprüfen: Oracle Lasttest mit SwingBench

Nach der Installation sollte dann auch gleich der aktuelles Security Patch eingespielt werden

Siehe die Seite ⇒ http://www.oracle.com/technetwork/topics/security/alerts-086861.html , den letzten verfügbaren Patch auswählen (in unseren Fall April 2015) und für die Cluster Umgebung und die Datenbank den Patch (GI PSU) auf dem Support Portal suchen. (alternativ siehe auch die „Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets (Doc ID 1454618.1)“ )

Im Zuge des Patches wird auch die Java Virtuell Maschine der Datenbank, des Clusters mit gepatched.

Dieser OJVM PSU läßt sich allerdings NUR mit einer kompletten Downtime der gesamten Cluster Umgebung einspielen!

Einspielt damit zuerst wie immer der letzte OPatch Patch auf jeden Knoten (Clusterware Home und DB Home!) und dann der GI PSU für April 2015 „Combo OJVM PSU 12.1.0.2.3 and GI PSU 12.1.0.2.3 Patch 20834538“ im Auto Mode für alle Homes des Clusters.

Ablauf:

• Download des Patch 20834538: COMBO OF OJVM COMPONENT 12.1.0.2.3 DB PSU + GI PSU 12.1.0.2.3 (APR2015) (p20834538_121020_Linux-x86-64.zip)
  • Überprüfen des MD5 Hashes ⇒ 716111E6AA71693B4DFE02FEC346E1A8 um Download Fehler auszuschließen
• Download des Patch 6880880: OPatch patch of version 12.1.0.1.7 for Oracle software releases 12.1.0.x (APR 2015)
  • Überprüfen des MD5 Hashes ⇒ 664BEF9A8B1FD4364EEFEA2C7343F754
• OPatch in allen Oracle Homes auf allen Knoten ersetzen
• ocm response file anlegen

  export ORACLE_HOME=<my_oracle_home_path>
  $ORACLE_HOME/OPatch/ocm/bin/emocmrsp  -no_banner -output <specify_the_location>/file.rsp

• Alle Datenbank stoppen mit srvctl

  <ORACLE_HOME>/bin/srvctl stop database –d <db-unique-name>

• ACFS Filessystem unmounten
• Auf den Knoten 1 als root den GI PSU einspielen

  opatchauto apply <UNZIPPED_PATCH_LOCATION>/20834538 -ocmrf <ocm response file> -nonrolling

• Auf den Knoten 2 als root den GI PSU einspielen

  opatchauto apply <UNZIPPED_PATCH_LOCATION>/20834538 -ocmrf <ocm response file> -nonrolling

• Da ACFS im Einsatz ist, die Knoten neu starten um die Treiber neu zu laden
• Prüfen ob alle Datenbank wieder gestartet wurden, bei Bedarf neu starten
• Änderungen am internen Code der Datenbanken in die Datenbanken laden mit datapatch (in meine Fall noch Single Tenant )

  cd $ORACLE_HOME/OPatch
  ./datapatch -verbose

Für die Wartung und Kontrolle proaktiv den TFA von Oracle Support in Betrieb nehmen.

Siehe:

• Oracle 12c RAC Umgebung mit Oracle Trace File Analyzer (TFA) überprüfen

Bei einer Neuinstallation lohnt es sich natürlich gleich VOR der DB Installation alle Patche einzuspielen.

Hier soll aber getestet werden wie später im laufenden Betrieb der quartalsweise PSU Patch in das System mit minimaler Downtime eingespielt werden kann, d.h. so lange wie möglich soll einer der beiden Knoten für die Anwendung zur Verfügung stehen.

Nach dem Abschluss der Patch Aktion prüfen ob die Oracle Binaries auch wirklich alle gleich sind:

opatch lsinv -all_nodes
....
Binary & Checksum Information
==============================
.....

Quellen:

• http://en.wikibooks.org/wiki/RAC_Attack_-_Oracle_Cluster_Database_at_Home/Patching_Grid_and_Database_Software

• Database Installation Guide 12c - https://docs.oracle.com/database/121/LADBI/toc.htm

Übersicht:

• http://www.oracle.com/technetwork/products/clusterware/overview/oracle-clusterware-12c-overview-1969750.pdf

Opatch:

• http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/opatch/index.html

Weitere Informationen zum Thema:

• https://www.redhat.com/en/files/resources/en-rhel-deploy-oracle-rac-database-12c-rhel-7.pdf