===== Installation einer Oracle Real Application Cluster 18c Umgebung auf Oracle Linux x64 7.5 über 2 Rechenzentren =====
**November 2018**
**Aufgabe:**
Installation einer Oracle 18c Real Application Cluster Umgebung über zwei Brandabschnitte unter Oracle Linux 7, als Datenbank muss aber immer noch Oracle 11g R2 11.2.0.4 oder eine 12.1 zum Einsatz kommen, da 12.2 oder höher nicht freigegeben ist.
=== Übersicht über den generellen Aufbau der Umgebung ===
{{ :dba:18c:oracle_18c_cluster_ueber_zwei_rechenzentren_uebersicht.png?600 |Übersicht Real Application Cluster 18c über zwei Rechenzentren}}
Als Betriebssystem wird Oracle Linux **7.5** eingesetzt.
Das Cluster wird über 2 Rechenzentren verteilt aufgebaut.
Siehe im Detail dazu auch => [[dba:asm_platten_verteilen|Oracle 12c - Oracle ASM Disk Groups über zwei Storages verteilen - Ein Oracle Cluster für zwei Brandabschnitte aufsetzen]] und [[linux:nfs_share_vot_files_oracle_rac|NFS für einen VOT File einem 12c Oracle Real Applikation Clusters unter Linux 7 verwenden]]
D.h. alle ASM Platten sind gespiegelt in zwei Storage Systemen angelegt, für die OCR/VOT ASM Diskgroup wird allerdings noch eine weitere Storage Location benötigt. Dies kann auch über einen NFS Mount erfolgen.
Die meisten Schritte sind noch sehr ähnlich zur Installation einer 12c r1 Umgebung siehe => [[dba:install_rac_linux_12c|Anmerkungen zu Installation des Oracle Real Application Cluster 12c R1 auf einem Oracle Linux 7]]. Wie aber bereits bei der [[dba:install_rac_linux_12c_r2|12c R2 Installation ]] wird nun aber die Software nur noch als Image ausgelieft und in das gewünschte Oracle Home entpackt. Aus dem Home wird die eigentliche Installation aufgerufen.
Auf die Mangement DB der 18c achten, in meinen Fall lege ich die mit auf die +DATA Platte, sonst wird eine sehr große VOT Platte benötigt!
----
===Vorbereitung OS ====
Wie immer zuvor sehr sorgfältig alle Abhängigkeiten einer Cluster Installation zur System Umgebung prüfen!
Kein noch so kleiner Fehler darf hier vorliegen, jeder Fehler rächt sich bitter beim Versuch der Installation und beim späteren Betrieb der Umgebung.
Die wichtigsten Punkte:
* Netzwerk
* Namensauflösung
* Zeitdienst
* Shared Storage
Mit 7.5 steht für die ganzen benötigten Abhängigkeiten ein RPM zur Verfügung, oracle-database-preinstall-18c.x86_64
Zuerst wird dieses RPM installiert und dann alles nochmal im Detail geprüft:
# oracle-database-preinstall-18c.x86_64 : Sets the system for Oracle Database single instance and Real Application # Cluster
yum install oracle-database-preinstall-18c.x86_64
# Mit dem OJVM Patch gibt es ein Problem falls kein Perl auf der Maschine installiert ist
yum install perl
Gruppen überprüfen:
# check the groups
vi /etc/group
oinstall:x:54321:oracle
dba:x:54322:oracle
oper:x:54323:oracle
backupdba:x:54324:oracle
dgdba:x:54325:oracle
kmdba:x:54326:oracle
racdba:x:54330:oracle
Falls was fehlt mit "groupadd -g" hinzufügen!
groupadd -g 54331 asmadmin
# User oracle und Grid anlegen bzw prüfen
id oracle
uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),54322(dba),54323(oper),54324(backupdba),54325(dgdba),54326(kmdba),54330(racdba),54327(asmdba)
ok !
id grid
uid=54322(grid) gid=54321(oinstall) groups=54321(oinstall),54330(racdba),54329(asmadmin),54327(asmdba)
# Bei Bedarf anlegen
useradd -u 54321 -g oinstall -G dba,oper,backupdba,dgdba,kmdba,racdba oracle
useradd -u 54322 -g oinstall -G dba,oper,backupdba,racdba grid
usermod -a -G asmadmin oracle
usermod -a -G asmadmin grid
# password auf beiden Knoten setzen als root
passwd oracle
passwd grid
Folgende Liste durcharbeiten => [[linux:linux_7_system_grundeinstellungen_oracle_datenbank_rac|Ein Oracle Linux 7 Basis System als Grundlagen für eine Oracle Clusterware und Datenbank Installation vorbereiten]]
== SSH Konfiguration oracle, root und grid user ===
Für die Vereinfachung der Wartung und als Vorbereitung für die Installation zwischen den Knoten SSH Key einrichten, siehe auch [[windows:putty_pscp_ssh_key_connect#ssh_key_s_bzw_ssh_key_struktur_auf_dem_linux_system_erzeugen|SSH Keys verteilen]]
# für root/grid/oracle
# on racdb01
cd
#generate key on every node
ssh-keygen -t rsa
ssh racdb02 ssh-keygen -t rsa
# Copy public key from one node to the other
ssh racdb02 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh racdb01 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh racdb02
ssh racdb01 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh racdb02
ssh racdb02 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# auf die localen Knoten auch per localhost ohne Password anmelden
ssh localhost
Darauf achten, das auch auf den lokalen Knoten ein Connect über den Servernamen / Localhost möglich ist.
----
====Storage bereitstellen====
Für den Betrieb des Clusters werden je ein Satz Platten aus jeden Rechenzentrum benötigt.
=== Oracle ASM vobereiten ===
== ASM Library installieren ==
**User: root**
yum install oracleasm-support
== ASM konfigurieren auf allen Knoten ==
**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 Multipathing 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
== ASM starten ==
**Als user root!**
oracleasm init
=== FC Umgebung auslesen und Platten identifizieren ====
Es werden zwei Storages in unterschiedlichen RZ Umgebungen an jeden Server angebunden, Jedes Storage stellt 15 Platten zur Verfügung. D.h. auf dem Server müssten 30 Devices sichtbar sein.
=> Infos:
* https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-s20-storage.html
* https://www.dell.com/support/article/de/de/debsdt1/sln312308/anleitung-zur-konfiguration-von-multipfad-ger%C3%A4ten-auf-enterprise-linux-6x-f%C3%BCr-dell-compellent-storage?lang=de
Später hat sich herausgestellt, das mit den UUID's der FC Platten von diesem DELL Storage es sich leider NICHT erkennen läßt aus welchen Storage heraus die Platten zur Verfügung gestellt werden!
Die ganze UUID's müssen sorgfältig abgeglichen werden!
Von anderen Storage Systemen war ich es gewohnt, das sich die ersten Digits der UUID sich aus der Storage Konfiguration ergeben und damit ganz einfach klar ist von welchen Storage die Platten stammen.
Nachträglich scannen ob neue Platten hinzugekommen sind => https://www.learnitguide.net/2016/02/scan-newly-added-fc-luns-and-scsi-disks.html
== Multipath installieren==
yum install sysfsutils
yum install device-mapper-multipath
mpathconf --enable --with_multipathd y
==FC Konfiguration auslesen ==
HBA Karten auf dem Server auslesen
lspci | grep Fibre
65:00.0 Fibre Channel: QLogic Corp. ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter (rev 01)
b3:00.0 Fibre Channel: QLogic Corp. ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter (rev 01)
HBA ports :
ls -l /sys/class/fc_host
total 0
lrwxrwxrwx 1 root root 0 Oct 30 13:52 host1 -> ../../devices/pci0000:64/0000:64:00.0/0000:65:00.0/host1/fc_host/host1
lrwxrwxrwx 1 root root 0 Oct 30 13:52 host16 -> ../../devices/pci0000:b2/0000:b2:00.0/0000:b3:00.0/host16/fc_host/host16
Status des Ports:
[root@racdb01 ~]# more /sys/class/fc_host/host16/port_state
Online
[root@racdb01 ~]# more /sys/class/fc_host/host1/port_state
Online
WWN nummber der Ports:
[root@racdb01 ~]# more /sys/class/fc_host/host1/port_name
0x21000024ff1d542b
[root@racdb01 ~]# more /sys/class/fc_host/host16/port_name
0x21000024ff1d53f9
Einfacher mit systools
systool -c fc_host -v | grep port_name
== Zugeordnete Devices suchen im OS ==
Alle Devices:
cat /proc/scsi/scsi
# von welchen Host kommen die Platten
cat /proc/scsi/scsi | grep Host
..
Host: scsi1 Channel: 00 Id: 03 Lun: 12
Host: scsi1 Channel: 00 Id: 03 Lun: 13
Host: scsi1 Channel: 00 Id: 03 Lun: 14
Host: scsi1 Channel: 00 Id: 03 Lun: 31
...
Host: scsi16 Channel: 00 Id: 03 Lun: 12
Host: scsi16 Channel: 00 Id: 03 Lun: 13
Host: scsi16 Channel: 00 Id: 03 Lun: 14
Host: scsi16 Channel: 00 Id: 03 Lun: 31
...
#Zählen ob von beiden Storage auch alles gesehen werden kann (noch dopplet):
cat /proc/scsi/scsi | grep Host | grep scsi16 | wc -l
64
cat /proc/scsi/scsi | grep Host | grep "scsi1 " | wc -l
64
# => von beiden Storage Systemen scheinen alle Platten dazu sein
Welches Device ist aber nun was? Wir sehen die Platten über jeden Channel doppelt
ls -ld /sys/block/sd*/device
..
lrwxrwxrwx 1 root root 0 Nov 1 2018 /sys/block/sdaa/device -> ../../../1:0:1:10
lrwxrwxrwx 1 root root 0 Nov 1 2018 /sys/block/sdab/device -> ../../../1:0:1:11
lrwxrwxrwx 1 root root 0 Nov 1 2018 /sys/block/sdac/device -> ../../../1:0:1:12
..
lrwxrwxrwx 1 root root 0 Nov 1 2018 /sys/block/sdbj/device -> ../../../16:0:0:0
lrwxrwxrwx 1 root root 0 Nov 1 2018 /sys/block/sdbk/device -> ../../../16:0:0:1
# durchzählen
ls -ld /sys/block/sd*/device | grep "/1:" | wc -l
60
ls -ld /sys/block/sd*/device | grep "/16:" | wc -l
60
# das sind die 15 Platten, werden je zweimal über jeden Controller gesehen
Nun kann über Information aus Schritt 1 /proc/scsi/scsi ( **Host: scsi1 Channel: 00 Id: 03 Lun: 12** ) das dazugehörige Device gefunden werden (ls -ld /sys/block/sd*/device | grep "/1:0:3:12" => /sys/block/sdbg/device -> ../../../**1:0:3:12**)=> **/dev/sdbg** ist gemapped auf **scsi1 Channel: 00 Id: 03 Lun: 12**.
Alternativ
lsscsi -l | grep sdbg
[1:0:3:12] disk DELL MD38xxf 0825 /dev/sdbg
#Rückwärtz
udevadm info --query=path --name /dev/sdbg
/devices/pci0000:64/0000:64:00.0/0000:65:00.0/host1/rport-1:0-7/target1:0:3/1:0:3:12/block/sdbg
Einfacher mit:
(sg ist ds SCSI Device zur Anbindung der Lun)
sg_map -x | grep "1 0 3 12"
/dev/sg61 1 0 3 12 0 /dev/sdbg
sg_scan -i | grep -A 1 sg61
/dev/sg61: scsi1 channel=0 id=3 lun=12
DELL MD38xxf 0825 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
Wie mappt das aber nun zusammen:
ls -la /dev/disk/by-id/ | grep sdbg
lrwxrwxrwx 1 root root 10 Nov 1 10:13 scsi-3600a098000df9e25000002fc5bda1944 -> ../../sdbg
lrwxrwxrwx 1 root root 10 Nov 1 10:13 wwn-0x600a098000df9e25000002fc5bda1944 -> ../../sdbg
ls -lR /dev/disk | grep sdbg
lrwxrwxrwx 1 root root 10 Nov 1 10:13 scsi-3600a098000df9e25000002fc5bda1944 -> ../../sdbg
lrwxrwxrwx 1 root root 10 Nov 1 10:13 wwn-0x600a098000df9e25000002fc5bda1944 -> ../../sdbg
lrwxrwxrwx 1 root root 10 Nov 1 10:13 pci-0000:65:00.0-fc-0x201300a098df9e3a-lun-12 -> ../../sdbg
einfacher mit :
multipath -l | grep mpath | wc -l
=> SCSI WWID ist a098000df9e25000002fc5bda1944
durchzählen:
ls -la /dev/disk/by-id/ | grep wwn-0x600a098000df9 | wc -l
30
..
multipath -l
mpatht (3600a098000df9e490000037a5bda1fe3) dm-21 DELL ,MD38xxf
size=300G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| |- 1:0:1:12 sdac 65:192 active undef unknown
| `- 16:0:1:12 sdck 69:128 active undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- 1:0:3:12 sdbg 67:160 active undef unknown
`- 16:0:3:12 sddo 71:96 active undef unknown
Minor/Mayor device ID ermitteln, später kann hier wieder das ASM Device identifiziert werden
ls -lb | grep /dev/dm-21
brw-rw---- 1 root disk 249, 21 Nov 1 13:11 dm-21
=== Oracle ASM Platten initialiseren ===
Mit den Informationen von oben können wir nun die Platten den Luns zuorden und die ASM Luns entsprechend anlegen.
==Platten partitionieren und Partitionstabelle in das OS neu einlesen ==
Tritt die Meldung bei "fdisk" "The kernel still uses the old table." auf, kann mit "kpartx" nachgeholfen werden um den Boot zu vermeiden.
Auf Knoten 1 als root
# neue primäre Partition über die ganze Platte anlegen
fdisk /dev/dm-2
#In each case, the sequence of answers is
"n", "p", "1", "Return", "Return", "p" and "w".
WARNING: Re-reading the partition table failed with error 22: Invalid argument.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.
kpartx -l /dev/dm-2
mpatha1 : 0 41940992 /dev/dm-2 2048
kpartx -a -v /dev/dm-2
add map mpatha1 (249:32): 0 41940992 linear /dev/dm-2 2048
Hier die Ausgabe "mpatha1" merken, das bezieht sich auf der Mapper Device unter "/dev/mapper/" => das neue Device heißt => dev/mapper/mpatha**1**
==ASM Header auf die Platten schreiben==
Auf Knoten 1 als root:
#Plattenkopf als ASM Platte markieren
oracleasm createdisk OCR01_S1 /dev/mapper/mpatha1
Writing disk header: done
Instantiating disk: done
# Platten überprüfen
oracleasm listdisks
Auf Knoten 2 die Platten erkennen lassen:
# Partitonstabelle neu einlesen
partprobe
#Platten erkennen lassen
oracleasm scandisks
oracleasm listdisks
# check mit
oracleasm querydisk -p OCR01_S1
Disk "OCR01_S1" is a valid ASM disk
/dev/mapper/mpathp1: LABEL="OCR01_S1" TYPE="oracleasm"
Das nun für die anderen 29 Platten durchführen.
Ablauf um das zügig umzusetzen:
* Alle Platten vom ersten Knoten aus partitonieren mit fdisk
* Reboot beider Server
* Liste mit den LUN UUIDs aus dem beiden Storage in Excel erstellen
* Auf Server 1 über /dev/disk/by-id nach den ID's grappen und DM Device für die erste Partition merken
ls -la | grep 600a098000df9e490000037c5bda2026
lrwxrwxrwx 1 root root 11 Nov 1 19:17 dm-uuid-mpath-3600a098000df9e490000037c5bda2026 -> ../../dm-26
lrwxrwxrwx 1 root root 11 Nov 1 19:17 dm-uuid-part1-mpath-3600a098000df9e490000037c5bda2026 -> ../../dm-52
* ASM Disk lablen mit oracleasm mit einer deutlichen Nameskonvention!
oracleasm createdisk REDO01_S2 /dev/dm-52
* Server neu booten und nach dem Boot prüfen ob alle Platten erkannt werden und auch wirklich über das Mapper Device angebunden wurden!
echo "ASM Disk Mappings"
echo "----------------------------------------------------"
for f in `oracleasm listdisks`
do
dp=`oracleasm querydisk -p $f | head -2 | grep /dev | awk -F: '{print $1}'`
echo "$f: $dp"
done
..
DATA01_S_S1: /dev/mapper/mpathj1
DATA01_S_S2: /dev/mapper/mpathy1
..
#Falsch!!
DATA06_S_S2: /dev/sdk
ASMLib darf die Platten nur über die dm Devices finden! Hier muss ich noch eine herausfinden warum das nur bei einer Platte so angezeigt wird, die "sd" devices sind eigentlich per Konfig vom Scan beim Booten ausgeschloßen
=== Linux I/O Scheduler für Oracle setzen ===
**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.
----
====Installation der Oracle Cluster Software ====
* ListenpunktDownload der Cluster Software von https://www.oracle.com/technetwork/database/enterprise-edition/downloads/oracle18c-linux-180000-5022980.html zum Beispiel nach "/opt/oracle/install/18c_clusterware/LINUX.X64_180000_grid_home.zip"
Prüfen des Hash:
# LINUX.X64_180000_grid_home.zip (5,382,265,496 bytes)
# (sha256sum - 122c1a780fe0c399818064021e3d797ed4c6b3bb68ceb2e102430fa370054cd1)
cd /opt/oracle/install/18c_clusterware/
sha256sum LINUX.X64_180000_grid_home.zip
122c1a780fe0c399818064021e3d797ed4c6b3bb68ceb2e102430fa370054cd1 LINUX.X64_180000_grid_home.zip
=== Auspacken der Software im gewünschten Oracle Home /opt/18.3.0.0/grid ===
**als User grid, auf beiden Knoten!**
cd /opt/18.3.0.0/grid
unzip -q /opt/oracle/install/18c_clusterware/LINUX.X64_180000_grid_home.zip
=== CVU RPM===
CVU RPM liegt jetzt unter $ORACLE_HOME/cv/rpm !
Hier wieder als root user anmelden und auf BEIDEN Knoten installieren!
su -
cd /opt/18.3.0.0/grid/cv/rpm
CVUQDISK_GRP=oinstall; export CVUQDISK_GRP
yum reinstall –nogpgcheck cvuqdisk-1.0.10-1.rpm
#prüfen ob auch wirklich installiert:
yum list | grep cvuqdisk
#Install on second node
scp cvuqdisk-1.0.10-1.rpm root@racdb02:/tmp
ssh racdb02
CVUQDISK_GRP=oinstall; export CVUQDISK_GRP
yum install –nogpgcheck /tmp/cvuqdisk-1.0.10-1.rpm
rm /tmp/cvuqdisk-1.0.10-1.rpm
#prüfen ob auch wirklich installiert:
yum list | grep cvuqdisk
exit
----
=== Aufruf Installer===
Unter dem User: **Grid**
Vor 12c R2 wurde die Software erst mit dem Installer in das Oracle Home installiert.
Jetzt enthält der Download für Linux der 18c das komplette Oracle Home zum Auspacken im Zielverzeichns.
Aus diesem Verzeichnis wird dann der Installer gestartet.
Da ja auf dem Cluster Knoten keine graphische Oberfläche installiert ist, wird per XForwarding gearbeitet.
D.h. im ersten Schritt auf dem client mit "xhost +" den Zugriff freigeben, dann am DB Server anmeldung und die DISPLAY Variable richtig setzen!
Auf dem Client abfragen
echo $DISPLAY
:1.0
ssh racnode1
who am i
gri pts/0 2018-11-01 19:21 (x.x.1.2)
# oder
pinky
Login Name TTY Idle When Where
grid pts/1 2018-11-01 19:57 x.x.1.2
export DISPLAY=x.x.1.2:1.0
#testen mit xdpyinfo ob das klappen kann
xdpyinfo
Name of display .....
#OK! dann kann es loßgehen!
cd /opt/18.3.0.0/grid
./gridSetup.sh
Ablauf:
^Schritt^Bemerkung^
|1|Configure Oracle Grid Infrastructure for a New Cluster => Next|
|2|Configure an Oracle Standalone Cluster => Next|
|3|Cluster Name => "racdbCluster" + Scan Listener DNS Name => "scanracdb.pipperr.local" + Scan Port => 1521" - Kein GNS|
|4|Cluster Node Information" - Zweiten Knoten hinzufügen (racdb02.pipperr.de - racdb02-vip.pipperr.de )|
|5|Netzwerk Interfaces zuordnen, wie Interconnect Interfaces als "ASM & Private", Interface mit der VIP IP als "public"|
|6|"Configure ASM using block devices" |
|7|"Do yuu want to create separate Automatic Storage Management (ASM) disk group for the Grid Infrastructure ... GMIR .." => YES |
|8|ASM Platte für OCR/VOT anlegen, dazu den Discovery Patch anpassen auf "/dev/oracleasm/disks/*" , drei Failgroups definiern (Storage1,Storage2,NTFS01), drei VOT Platten auswählen für "Normal Redundancy" auswählen (NTFS Platte in echt wird später hinzugefügt, jetzt eine Platte für diesen Zweck erstmal ausleihen) und den DISK Namen in "VOTPRD" ändern {{:dba:18c:step8-definevot-diskgroup.png?400|Define Vot 18c}}|
|9|ASM Platte für GMIR anlegen, Disks auswählen und den DISK Namen in "DATA" ändern , zweiFailgroups definiern (Storage1,Storage2), Normal Redundancy und von jeden Storage eine Platte auswählen {{:dba:18c:step9-definedata-diskgroup.png?400 |}}|
|10|ASM Passwörter setzen |
|11|Kein IPMI verwenden |
|12|Oracle Enterprise Manager ausswählen falls vorhanden, in meine Fall nichts auswählen |
|13|Gruppen auswählen , asmadmin, oinstall, racdba|
|14|Oracle Base => "/opt/oracle" auswählen, Grid Home ist ja bereits auf /opt/18.3.0.0/grid" gesetzt|
|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, nach ca. 4 Minuten, Root Script Hinweis beachten! 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!{{ :dba:18c:step19-root_scripts_oracle_18c_cluster_installation.png?400 | Oracle 18c Cluster Installation - root Script Step 18 }} |
| |Konfigurations-Assistenten laufen durch, je nach System kann das etwas dauern, in dieser VM Umgebung ~ 10minuten|
|20|Abschluss der Installation, Fenster mit Close schließen |
Mit der 18c kann tatsächlich ein vollständiges Cluster mit nur einem Knoten aufgebaut werden!
Wird das root Script nicht auf dem zweiten Knoten ausgeführt, wird nur der 1 Knoten initalisert,
Danach kann ein weitere Knoten über den Installer hinzugefügt werden (software muss aber vorab auf den zweiten Knoten auch kopiert worden sein!) siehe => https://docs.oracle.com/en/database/oracle/oracle-database/18/cwadd/adding-and-deleting-cluster-nodes.html#GUID-2AE1FEE2-7A45-40E5-97CD-CF6DD91A4E8B
Auf dem Knoten 1 wird /gridSetup.sh neu gestartet und die Option "Hinzufügen eines weitere Knoten" ausgeführt, anweisungen befolgen, dann viel Geduld, bis zum root Script hat es fast 20 Minuten gedaurt... dann root Script auf dem neuen Knoten ausführen
----
=== Umgebung und Logfiles des Clusters prüfen ===
Im Anschluss die Umgebung überprüfen:
export ORACLE_HOME=/opt/18.3.0.0/grid.1/grid
cd $ORACLE_HOME/bin
./crsctl check cluster
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
crsctl status resource -t
./crs_stat gibt es in 18c nicht mehr .. schade war eine schöne Übersicht, selber was bauen .. :-(
==Logfiles mit adrci prüfen==
export ADR_BASE=/ort/oracle
export ORACLE_HOME=/opt/18.3.0.0/grid.1/grid
$ORACLE_HOME/bin/adrci
adrci
adrci> show alert
..
3: diag/crs/racdb01/crs
...
Please select option: 3
#Logs auf Auffälligkeiten Prüfen
----
==== Umgebungsskript ====
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 => [[dba:arbeits_umgebung| Arbeitsumgebung setzen und Einrichten unter Windows und Linux]]
Ich verwende dazu folgendes Script [[https://github.com/gpipperr/OraPowerShell/blob/master/Ora_Bash_env_DB_backup/.profile|.profile]] und folgende [[https://github.com/gpipperr/OraPowerShell/blob/master/Ora_Bash_env_DB_backup/.bash_profile|.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 [[https://github.com/gpipperr/OraPowerShell/tree/master/Ora_SQLPlus_SQLcL_sql_scripts| Gunther SQL Scripte]] dorthin kopieren
* Auf den anderen Knoten verteilenssh 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.){{:dba:rac:rac_12c_set_enviroment_01.png|Umgebung mit eigenen Script einstellen}}
Auf beiden Knoten einrichten!
Kleiner Bug, Oracle BASE pürfen und falls falsch hart im Script kodieren!
----
====Listener====
**User: grid**
Der Oracle Listener läuft im Cluster, diesen prüfen und optimieren.
== SQLNET.EXPIRE_TIME ==
Auf JEDEM knoten die Datei "sqlnet.ora" anpassen:
#User Grid
vi $ORACLE_HOME/network/admin/sqlnet.ora
# Parameter for the listner, check after 30min if connection is still alive
SQLNET.EXPIRE_TIME = 30
== Scan Listener überprüfen ==
srvctl config scan
== Security ==
Siehe auch:
* http://externaltable.blogspot.de/2014/01/clusterware-12c-and-restricted-service.html
----
===Reboot Test ====
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
crsctl status resource -t
----
==== Trace File Analyser aktualiseren und Umgebung prüfen ====
Auf beiden Knoten die veraltete Version (kommt mit der 18c Installation mit) deinstallieren und die aktuellste Version von TFA Collector - TFA with Database Support Tools Bundle (Doc ID 1513912.1)“ in ein eigenes Home installieren.
Auf beiden Knoten als root:
/opt/18.3.0.0/grid/bin/tfactl uninstall
#fehlendes packet schon mal nachinstallieren
yum install perl-Data-Dumper.x86_64
Für die neue Installation siehe hier => [[dba:oracle_rac_12c_tfa_trace_file_analyser|Oracle 12c RAC Umgebung mit Oracle Trace File Analyzer (TFA) überprüfen]]
== orachk Dämon deaktiveren ==
Überprüfen ob der Dämon für orachk aktiviert ist (Gefahr besteht das die Logs die Platten auffüllen!):
cd /opt/oracle/tfa/bin
./tfactl orachk -d status
./tfactl orachk -d info
./tfactl orachk -d nextautorun
Falls zuwenig Plattenplatz besser deaktiveren:
./tfactl run orachk -autostop
..
orachk daemon successfully stopped
..
Bei Bedarf später wieder einschalten.
=== tfactl User aktiveren ===
mit "tfactl access lsuser"
# User freischalten als root auf beiden Knoten
./tfactl access enable
./tfactl access add -user oracle
./tfactl access add -user grid
Überprüfen mit :
# als user grid
/opt/oracle/tfa/bin
./tfactl analyze -last 2d
=== Mit OraCheck das Cluster prüfen ===
Auf knote 1 als root:
./tfactl orachk -nordbms
Auswertung analysieren und wichtige Punkte fixen wie (vm.min_free_kbytes = 524288 usw.)!
----
==== Letzten Patch Level in das Cluster einspielen ===
Aktuell ( November 2018) ist das die 18.3.1.0 ( Patch 28660077: GI RELEASE UPDATE REVISION 18.3.1.0.0)
OPatch 12.2.0.1.14 for DB 18.x releases (JUL 2018) (Patch)
p6880880_180000_Linux-x86-64.zip 94.6 MB (99183505 bytes)
SHA-1 220336657AA6AF87FDFD6CDC9595BC3611725DD3
SHA-256 D7ACAFF936FC090D62B12B476790BC346FC6E2A6AB59D3F29149043AB2E0748F
GI RELEASE UPDATE REVISION 18.3.1.0.0 (Patch)
p28660077_180000_Linux-x86-64.zip 1.8 GB (1879542796 bytes)
SHA-1 C464A2746BE46101B947273A57C471D86D0DB434
SHA-256 DC1F9BE8A044541BC54F0E185A69E5A0C117737CD1E83493CEB4B7C3A64A221B
Generller Ablauf:
* Download der Patche ( z.b. nach /opt/oracle/install/18c_patch/)
* Checksum sorgfältig prüfen, sha245sum
sha256sum *
2a5ccf03ebb309268e121ca860e5ea5251f9dcea42799fcb1e2c0eba12060276 p28502229_180000_Linux-x86-64.zip
dc1f9be8a044541bc54f0e185a69e5a0c117737cd1e83493ceb4b7c3a64a221b p28660077_180000_Linux-x86-64.zip
d7acaff936fc090d62b12b476790bc346fc6e2a6ab59d3f29149043ab2e0748f p6880880_180000_Linux-x86-64.zip
* Patche auf zweiten Knoten zur Verfügung stellen
* OPatch auf allen Knoten aktualiseren (Verzeichnis OPatch mit p6880880_180000_Linux-x86-64.zip austauschen)
# User root
# Sicherheitskopie
mv /opt/18.3.0.0/grid/OPatch/ /opt/18.3.0.0/grid/OPatch_old/
mkdir /opt/18.3.0.0/grid/OPatch
chown grid:oinstall /opt/18.3.0.0/grid/OPatch
#User Grid
unzip p6880880_180000_Linux-x86-64.zip -d /opt/18.3.0.0/grid
/opt/18.3.0.0/grid/OPatch/opatch version
OPatch Version: 12.2.0.1.14
* Grid und OJVM Patch auspacken auf beiden Knoten
unzip p28502229_180000_Linux-x86-64.zip
* Grid Patch installieren Node 1
#User grid
# ------- Validieren der Umgebung
/opt/18.3.0.0/grid/OPatch/opatch lsinventory -detail -oh /opt/18.3.0.0/grid
# ------- auf Konflikte prüfen
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/oracle/install/18c_patch/28660077/28507480
..
Prereq "checkConflictAgainstOHWithDetail" passed.
OPatch succeeded.
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/oracle/install/18c_patch/28660077/28090553
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/oracle/install/18c_patch/28660077/28090557
# ------- Plattenplatz prüfen
vi /opt/oracle/install/18c_patch/patch_list_gihome.txt
/opt/oracle/install/18c_patch/28660077/28507480
/opt/oracle/install/18c_patch/28660077/28090553
/opt/oracle/install/18c_patch/28660077/28090557
$ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseFile /opt/oracle/install/18c_patch/patch_list_gihome.txt
..
Prereq "checkSystemSpace" passed.
..
# ---- der eigentliche Patch als root!
# User root
export PATH=$PATH:/opt/18.3.0.0/grid/OPatch
opatchauto apply /opt/oracle/install/18c_patch/28660077
# 9 Minuten später ist das durch
# Nun das gleiche auf dem zweiten Knoten!
# 14 Minuten später ...
----
==== ASM Platten einrichten ====
**Als User Grid**
Die "DATA" Platte für die Datenbank wurde bereits mit dem initialen Setup angelegt.
Weitere Platten mit:
#Grid umgebung einrichten
asmca &
# Dauert etwas das es startet, etwas Geduld von nöten
=== Compatible Mode prüfen, auf min 11.2 einstellen ===
Um später einfach wieder eine Failgroup weider einbinden zu können, müssen die compatible Parameter min auf 11.2 stehen! Ansonsten müssen die Platten alle per Hand wieder hinzugefügt werden.
Falls noch 10g als DB im Einsatz ist, nicht ändern!
select group_number, name, compatibility, database_compatibility from v$asm_diskgroup;
Cluster sollte auf 18.0.0.0.0 stehen!
siehe auch =>[[dba:asm_platten_verteilen##fehler_behandlung_in_einer_asm_umgebung_mit_fail_groups_ueber_zwei_storage_systeme|Fehler Behandlung in einer ASM Umgebung mit Fail Groups über zwei Storage Systeme]]
=== Repair Timer setzen===
Die REPAIR_TIMER Spalte von V$ASM_DISK zeigt die Zeit an, bis eine Disk im Offline Status gedroppt wird.
Der Wert kann zum Beispiel mit "ALTER DISKGROUP ACFS SET ATTRIBUTE 'disk_repair_time'='24h'" gesetzt werden.
Default erhöhen:
disk_repair_time => 36h
failgroup_repair_time => 72h
--abfragen:
select g.name as group_name
, a.name
, a.value
, a.SYSTEM_CREATED
from V$ASM_ATTRIBUTE a
inner join v$asm_diskgroup g on (g.group_number=a.group_number)
where g.name like upper ('&&DG_NAME')
and a.name like lower ('%repair%')
order by a.name
, g.name
/
--setzen:
ALTER DISKGROUP DATA01 SET ATTRIBUTE 'disk_repair_time'='36h';
ALTER DISKGROUP DATA01 SET ATTRIBUTE 'failgroup_repair_time'='72h';
----
==== Oracle Cluster Registry spiegeln====
Weitere Locations hinzufügen
Als User root:
#Alles überprüfen
$GRID_HOME/bin/ocrcheck
# Min. zweite Location zur Sicherheit hinzufügen
$GRID_HOME/bin/ocrconfig -add +REDOA
$GRID_HOME/bin/ocrconfig -add +REDOB
----
==== ACFS Cluster einrichten====
Nach dem wir nun das Cluster auf den letzten Stand gehoben haben, kann das ACFS File System eingerichtet werden.
=== Voraussetzungen prüfen ===
Test ob alles supported ist:
Als user root auf beiden Knoten testen:
/opt/18.3.0.0/grid/bin/acfsdriverstate version
ACFS-9325: Driver OS kernel version = 4.1.12-112.16.4.el7uek.x86_64.
ACFS-9326: Driver build number = 180522.
ACFS-9212: Driver build version = 18.1.0.0 ()..
ACFS-9547: Driver available build number = 180522.
ACFS-9548: Driver available build version = 18.1.0.0 ()..
Als user grid auf beiden Knoten testen:
# Oracle Umgebung setzen - user grid
acfsdriverstate supported
ACFS-9200: Supported
Wenn auf beiden Knoten "acfsdriverstate supported => ACFS-9200: Supported", kann es weitergehen.
=== ASM Disk einrichten ==
# Umgebung auf die ASM Instance setzen
# IN meiner Umgebung mit setdb 1
sqlplus / AS sysasm
CREATE diskgroup ACFS NORMAL REDUNDANCY
failgroup storage1 disk '/dev/oracleasm/disks/DATA08_S_S1'
failgroup storage2 disk '/dev/oracleasm/disks/DATA08_S_S2';
ALTER diskgroup ACFS
ADD failgroup storage1 disk '/dev/oracleasm/disks/DATA09_S_S1'
failgroup storage2 disk '/dev/oracleasm/disks/DATA09_S_S2';
ALTER diskgroup ACFS
ADD failgroup storage1 disk '/dev/oracleasm/disks/DATA10_S_S1'
failgroup storage2 disk '/dev/oracleasm/disks/DATA10_S_S2';
ALTER diskgroup ACFS
ADD failgroup storage1 disk '/dev/oracleasm/disks/DATA11_S_S1'
failgroup storage2 disk '/dev/oracleasm/disks/DATA11_S_S2';
# 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;
=== ACFS Filesystem auf Knoten racdb01 einrichten===
==Ein ASM Volume in einer ASM Disk Gruppe anlegen==
Als User mit SYSASM Rechten über asmcmd anmelden:
Compatible setzen
ASMCMD>setattr -G ACFS compatible.asm 18.0
Volumen anlegen:
#Anlegen
ASMCMD> volcreate -G ACFS -s 900G volbackup01;
==Volume Namen ermitteln==
#Anzeigen lassen:
ASMCMD> volinfo -G ACFS volbackup01
Diskgroup Name: ACFS
Volume Name: VOLBACKUP01
Volume Device: /dev/asm/volbackup01-181
State: ENABLED
Size (MB): 921600
Resize Unit (MB): 512
Redundancy: MIRROR
Stripe Columns: 8
Stripe Width (K): 1024
Usage:
Mountpath:
exit
su
Auf den Namen des Volume Device achten!
==Filesystem auf dem Volume anlegen==
Als root:
/sbin/mkfs -t acfs /dev/asm/volbackup01-181
mkfs.acfs: version = 18.0.0.0.0
mkfs.acfs: on-disk version = 46.0
mkfs.acfs: volume = /dev/asm/volbackup01-181
mkfs.acfs: volume size = 966367641600 ( 900.00 GB )
mkfs.acfs: Format complete.
==Filesystem registrieren==
Als root
#auf beiden Knoten!
mkdir /opt/oracle/acfs
chown -R grid:oinstall /opt/oracle/acfs
chmod g+w /opt/oracle/acfs
#Nur auf knote 1
/sbin/acfsutil registry -a /dev/asm/volbackup01-181 /opt/oracle/acfs
acfsutil registry: mount point /opt/oracle/acfs successfully added to Oracle Registry
==Filesystem mounten==
Als root:
auf beiden Knoten!
/bin/mount -t acfs /dev/asm/volbackup01-181 /opt/oracle/acfs
chown -R grid:dba /opt/oracle/acfs
#All oracle stuff on the system schould use it
chmod 777 /opt/oracle/acfs
==Fileystem prüfen==
Als Grid User:
cd /opt/oracle/acfs/
touch test.txt
== Beide RAC Knoten neu starten==
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:
su
acfsutil info fs
/opt/oracle/acfs/
ACFS Version: 18.0.0.0.0
on-disk version: 47.0
compatible.advm: 18.0.0.0.0
ACFS compatibility: 18.0.0.0.0
...
total size: 966367641600 ( 900.00 GB )
total free: 963942346752 ( 897.74 GB )
...
....
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 ...."
* Oracle ACFS diagnostic Befehle sind "acfsutil meta" und "acfsutil tune"
----
----
==== Datenbank Installation Oracle Database 12c Release 1 SE2 (12.1.0.2.0) ====
Leider kann noch keine Version 12c R2 oder 18c eingesetzt, die Applikation benötigt noch Oracle Database 12c Release 1 (12.1.0.2.0).
Download von https://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html über den Abschnit 12.1.0.2.0) - Standard Edition (SE2) in meinen Fall.
* Zips herunterladen,z.b. nach /opt/oracle/install/12c_database und pürfen
cd /opt/oracle/install/12c_database
cksum *
3212055109 1673591558 linuxamd64_12102_database_se2_1of2.zip
1546119024 1015358809 linuxamd64_12102_database_se2_2of2.zip
* unzip im gleichen Verzeichnis
unzip linuxamd64_12102_database_se2_1of2.zip
unzip linuxamd64_12102_database_se2_2of2.zip
* Rechte auf den User Oracle setzen chown -R oracle:oinstall *
* Als user Oracle anmelden , WForwarding wie bereits gewohnt einrichten und Installer starten
cd cd /opt/oracle/install/12c_database/database
./runInstaller
Ablauf:
* Screen 1 - Hacken "I wish .." abwählen
* Screen 2 - Auswahl "Install database software only" auswählen
* Screen 3 - Auswahl RAC stehen lassen
* Screen 4 - Node Names überprüfen, alle markieren
* Screen 5 - Produktsprache Englisch und Deutsch wählen
* Screen 6 - In meine Fall benötige ich eine Standard Edition , einzige Auswahlmöglichkeit
* Screen 7 - Oracle Base "/opt/oracle" und Oracle Home "/opt/oracle/product/12.1.0.2/dbhome_1" einstellen
* Screen 8 - Gruppenrechte so belassen
* Screen 9 - Prerequisit Checks duchführen => Problem mit dem Cluster Checks! in 18c sind einige Tools nicht mehr dabei! - daher erstmal alles ingnoriert
* Screen 10 - Save Responce File und starten der Installation
* Screen 11 - Installation läuft
* Screen 11 - Root Script auf beiden Knoten im Oracle Home ausführen!
* Screen 12 - Finish!
=== DB Patch einspielen ===
Aktuell ist der Patch (Patch 28259833 - Database Patch Set Update 12.1.0.2.181016) November 2018.
DATABASE PATCH SET UPDATE 12.1.0.2.181016 (Patch)
p28259833_121020_Linux-x86-64.zip 683.9 MB (717152493 bytes)
SHA-256 B7DD20A7FD3DB638693523BFB936BCF251D2E46F026DF6C4B0AD5C074FBEFCC2
SHA-1 167AED36BD52DF6BD22055A65AC76C2DCB3D3072
OPatch 12.2.0.1.14 for DB 12.2 releases (JUL 2018) (Patch)
p6880880_122010_Linux-x86-64.zip 94.6 MB (99183505 bytes)
SHA-1 220336657AA6AF87FDFD6CDC9595BC3611725DD3
SHA-256 D7ACAFF936FC090D62B12B476790BC346FC6E2A6AB59D3F29149043AB2E0748F
OJVM PATCH SET UPDATE 12.1.0.2.181016 (Patch)
p28440711_121020_Linux-x86-64.zip 98.9 MB (103745864 bytes)
SHA-1 8BC825836CE72187AB8C00A7A02DCDBCBA6D9817
SHA-256 F27F1B7C0C9C62B04DE4981F2525048918EB639265AA1328ABC3F6E8B50068F7
Mit dem OJVM Patch gibt es ein Problem falls kein Perl auf der Maschine installiert ist, Perl mit "yum install perl" zuvor installieren!
Genereller Ablauf:
* Download der Patche ( z.b. nach /opt/oracle/install/12c_patch/)
* Checksum sorgfältig prüfen, sha245sum
b7dd20a7fd3db638693523bfb936bcf251d2e46f026df6c4b0ad5c074fbefcc2 p28259833_121020_Linux-x86-64.zip
f27f1b7c0c9c62b04de4981f2525048918eb639265aa1328abc3f6e8b50068f7 p28440711_121020_Linux-x86-64.zip
d7acaff936fc090d62b12b476790bc346fc6e2a6ab59d3f29149043ab2e0748f p6880880_122010_Linux-x86-64.zip
* OPatch auf allen Knoten aktualiseren (Verzeichnis OPatch mit p6880880_180000_Linux-x86-64.zip austauschen)
# User root
# Sicherheitskopie
mv /opt/oracle/product/12.1.0.2/dbhome_1/OPatch/ /opt/oracle/product/12.1.0.2/dbhome_1/OPatch_old
mkdir /opt/oracle/product/12.1.0.2/dbhome_1/OPatch
chown oracle:oinstall /opt/oracle/product/12.1.0.2/dbhome_1/OPatch
chown -R oracle:oinstall /opt/oracle/install/12c_patch
#User oracle
cd /opt/oracle/install/12c_patch
unzip p6880880_122010_Linux-x86-64.zip -d /opt/oracle/product/12.1.0.2/dbhome_1
/opt/oracle/product/12.1.0.2/dbhome_1/OPatch/opatch version
OPatch Version: 12.2.0.1.14
* Grid und OJVM Patch auspacken auf beiden Knoten
unzip p28259833_121020_Linux-x86-64.zip
unzip p28440711_121020_Linux-x86-64.zip
* DB Patch überprüfen
export ORACLE_HOME=/opt/oracle/product/12.1.0.2/dbhome_1
cd /opt/oracle/install/12c_patch/28259833
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
..
Invoking prereq "checkconflictagainstohwithdetail"
Prereq "checkConflictAgainstOHWithDetail" passed.
OPatch succeeded.
* Patch einspielen auf jeden Knoten
#User Oracle
export ORACLE_HOME=/opt/oracle/product/12.1.0.2/dbhome_1
cd /opt/oracle/install/12c_patch/28259833
$ORACLE_HOME/OPatch/opatch apply
#Problem
OPatch found the word "error" in the stderr of the make command.
Please look at this stderr. You can re-run this make command.
Stderr output:
chmod: changing permissions of ‘/opt/oracle/product/12.1.0.2/dbhome_1/bin/extjobO’: Operation not permitted
make: [iextjob] Error 1 (ignored)
Composite patch 28259833 successfully applied.
OPatch Session completed with warnings.
Log file location: /opt/oracle/product/12.1.0.2/dbhome_1/cfgtoollogs/opatch/opatch2018-11-03_17-57-19PM_1.log
OPatch completed with warnings.
ls -la /opt/oracle/product/12.1.0.2/dbhome_1/bin/extjobO
ls -la /opt/oracle/product/12.1.0.2/dbhome_1/bin/extjobO
-rwsr-x--- 1 root oinstall 1630640 Nov 2 17:29 /opt/oracle/product/12.1.0.2/dbhome_1/bin/extjobO
ls -la /opt/oracle/product/12.1.0.2/dbhome_1/bin/extjob
-rwxr-xr-x 1 oracle oinstall 1630680 Nov 3 17:58 /opt/oracle/product/12.1.0.2/dbhome_1/bin/extjob
# hmm, wie sollen die Rechte wohl richtig stehen? Feature ist hier nicht im Einsatz,
# Das wäre nun eine Support Anfrage wert
* Oracle JavaVM Component auf jeden Knoten einspielen
#User Oracle
cd /opt/oracle/install/12c_patch/28440711
export ORACLE_HOME=/opt/oracle/product/12.1.0.2/dbhome_1
$ORACLE_HOME/OPatch/opatch apply
#Problem:
Patching component oracle.dbjava.ic, 12.1.0.2.0...
Make failed to invoke "/usr/bin/make -f ins_rdbms.mk javavm_refresh patchset_opt_all ioracle ORACLE_HOME=/opt/oracle/product/12.1.0.2/dbhome_1"....'make: perl: Command not found
make: *** [javavm_refresh] Error 127
# Mit N abbrechen
L#ösung : Perl auf der Maschine installieren
#Root
yum install perl
#oracle
#nochmal patchen!
Damit ist die Datenbank Software installiert, als nächstes kann dann die Datenbank nach Kundenvorgaben aufgesetzt werden.
----
==== Datenbank installieren ====
** Als DB Owner Oracle **
Folgendes Setup soll eingehalten werden:
* Zeichensatz : AL32UTF8
* Datendateien auf : DATA
* RedoLog Gruppe A : REDO01
* Redolog Gruppe B : REDO02
Local und Remote Listener Parameter in der DB hinterlegen
DB mit meine Wizard angelegt siehe https://github.com/gpipperr/OraPowerShell/tree/master/Ora_Bash_create_database
=== DB Patchen ===
Nach Anlegen der DB diese erstmal patchen! siehe => https://mikedietrichde.com/2018/04/19/do-you-have-to-execute-datapatch-when-you-create-a-new-database/
# als user root
# Gruppen Rechte richtig setzen!
# Problem mkdir ... sqlpatch.pm line 611
#
/opt/oracle/cfgtoollogs/sqlpatch
chmod g+w .
# als user oracle
# set Oracle Home
$ORACLE_HOME/OPatch/datapatch -verbose
=== ASM Platten für die DB hinzufügen ===
Da will man einmal mit einer graphischen Oberfläche schnell mal arbeiten:
asmca &
Problem: [DBT-30003] The size of the disks selected is not the same as to allow for an equal number of 4mb au size blocks
Siehe auch 12c ASM: Unable To Add New Disks With Dissimilar Size To 12.1.0.2 ASM Diskgroups (Normal or High Redundancy) Due To ORA-15410 (New 12c ASM Enhancement Validation/Constraint) (Doc ID 1938950.1)
Grr, die SAN Platten sind nicht 100% gleich groß , d.h. es muss die Größe expliziet angegeben werden.
Nun erstmal die 8 Luns analysieren wie große die angeblich sind.
Wird die Größe über Oracle ASM abgefragt, sind alle bis auf eine 307199MB groß, eine hat 307200MB ... grr
Mit Größenangabe anlegen:
CREATE diskgroup RECO01 NORMAL REDUNDANCY
failgroup storage1 disk '/dev/oracleasm/disks/DATA04_S_S1' SIZE 307199M
failgroup storage2 disk '/dev/oracleasm/disks/DATA04_S_S2' SIZE 307199M ;
=== DB Console - Oracle Database Express aktiveren===
siehe auch => [[dba:oracle_12c_database_express|Die Oracle 12c Datenbank mit Oracle Database Express administrieren]]
Dispatcher für jeden Knoten einrichten:
sqlplus / as sysdba
ALTER system SET dispatchers='(PROTOCOL=TCP) (SERVICE=GPIDB1XDB)' scope=BOTH sid='GPIDB1';
ALTER system SET dispatchers='(PROTOCOL=TCP) (SERVICE=GPIDB2XDB)' scope=BOTH sid='GPIDB2';
-- SSL Port freischalten
- prüfen ob bereits eingestellt:
SELECT dbms_xdb_config.gethttpsport () FROM dual;
-- einstellen
EXEC dbms_xdb_config.sethttpsport (5500);
exit
# DB Durchstarten
srvctl stop database -d GPIDB
srvctl start database -d GPIDB
== Problem - Unable to establish SSL connection. ==
Folgendes Problem tratt in einer Cluster Umgebung auf:
**Unable to establish SSL connection.**
wget https://localhost:5500/em
--2018-11-05 15:30:17-- https://localhost:5500/em
Resolving localhost...
Connecting to localhost|localhost|:5500... connected.
Unable to establish SSL connection.
Ursache:
Listener prüfen:
# Umgebung auf Grid setzen
lsnrctl status | grep HTTP
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=racdb01.pipperr.local)(PORT=5500))(Security=(my_wallet_directory=/opt/oracle/product/12.1.0.2/dbhome_1/admin/ISORCL7/xdb_wallet))(Presentation=HTTP)(Session=RAW))
Das Cluster läuft unter dem User grid, die SSL Wallet gehört dem User oracle!
cd /opt/oracle/product/12.1.0.2/dbhome_1/admin/ISORCL7/xdb_wallet
ls -la
-rw------- 1 oracle asmadmin 3880 Nov 4 17:26 cwallet.sso
-rw------- 1 oracle asmadmin 3835 Nov 4 17:26 ewallet.p12
# => grid darf hier nix lesen , ist aber in der gruppe asmadmin
chmod g+r *
ls -la
-rw-r----- 1 oracle asmadmin 3880 Nov 4 17:26 cwallet.sso
-rw-r----- 1 oracle asmadmin 3835 Nov 4 17:26 ewallet.p12
# Auf beiden knoten!!
Sind die Rechte richtige vergeben, klappt es sofort!
Nun kann über die URL** https://mydbServer:5500/em** auf Database Express zugegriffen werden.
=== Service für die Datenbank einrichten ===
Damit wir es später in der Wartung einfacher haben, sollte sich die Applikation NUR über einen Service Namen anmelden!
srvctl add service -d GPIDB -s GPOIPPRD -r GPIDB1,GPIDB2 -P NONE -B THROUGHPUT -j LONG
srvctl start service -d GPIDB -s GPOIPPRD
srvctl status service -d GPIDB
----
==== Quellen ====
Storage Fragen:
* http://fibrevillage.com/storage/8-check-and-list-luns-attached-to-hba-in-rhel6
* https://www.thegeekdiary.com/how-to-identifymatch-lun-presented-from-san-with-underlying-os-disk/
* https://www.thegeekdiary.com/how-to-identify-the-hba-cardsports-and-wwn-in-rheloel/
Orginal Doku
* https://docs.oracle.com/en/database/oracle/oracle-database/18/install-and-upgrade.html
Netzwerk Überlegungen => https://www.oracle.com/technetwork/products/clusterware/overview/interconnect-vlan-06072012-1657506.pdf