Benutzer-Werkzeuge

Webseiten-Werkzeuge


Action disabled: index
dba:install_rac_linux_12c_r2

Anmerkungen zu einer Installation vom Oracle Real Application Cluster 12c R2 auf Oracle Linux x64 7.4

Aufgaben: Installation einer Oracle 12c R2 Real Application Cluster Umgebung unter Oracle Linux 7, Datenbank Oracle 11g R2 11.2.0.4

Die meisten Schritte sind noch sehr ähnlich zur Installation einer 12c r1 Umgebung siehe ⇒ Anmerkungen zu Installation des Oracle Real Application Cluster 12c R1 auf einem Oracle Linux 7.

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.

Im folgenden daher hier ein paar Anmerkungen zu den Unterschieden.


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

siehe dazu im Detail Ein Oracle Linux 7 Basis System als Grundlagen für eine Oracle Clusterware und Datenbank Installation vorbereiten

Gruppen überprüfen:

# check the groups
vi /etc/groups
 
 
oinstall:x:54321:
dba:x:54322:oracle
oper:x:54323:oracle
backupdba:x:54324:oracle
dgdba:x:54325:oracle
kmdba:x:54326:oracle
racdba:x:54330:oracle,grid
asmadmin:x:54329:grid
asmdba:x:54327:oracle,grid
asmoper:x:54328:
 
 
Falls was fehlt mit "groupadd -g" hinzufügen
 
 
# 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)
id grid
uid=54322(grid) gid=54321(oinstall) groups=54321(oinstall),54330(racdba),54329(asmadmin),54327(asmdba)
 
 
 
useradd -u 54321 -g oinstall -G dba,oper,backupdba,dgdba,kmdba,asmdba,asmoper,asmadmin,racdba oracle
useradd -u 54321 -g oinstall -G dba,oper,backupdba,asmdba,asmadmin,racdba grid
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 SSH Keys verteilen

# für root/grid/oracle
# on db01
cd
 
#generate key on every node
 
 
ssh-keygen -t rsa
ssh db02 ssh-keygen -t rsa
 
# Copy public key from one node to the other
ssh db02 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh db01 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh db02
ssh db01 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh db02
ssh db02 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.


Installation der Oracle Cluster Software

CVU RPM

CVU RPM liegt jetzt unter $ORACLE_HOME/cv/rpm !

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

su -
 
cd /u01/app/12.2.0/grid/cv/rpm 
 
CVUQDISK_GRP=oinstall; export CVUQDISK_GRP
 
yum install –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

Storage Anforderungen der R2 beachten - GMIR Datenbank auf den VOT Disks

In meiner Umgebung sind 5 VOT Disk im Einsatz mit „High Redundancy“ da später evlt. ein Spiegel über zwei RZ in Gespräch ist. Jede VOT Disk ist 10G groß.

Das ist dann zu klein um noch die Managmenet DB dre 12'er Installtion aufzunehmen.

Daher für diese gleich auch die DATA Diskgroup mit dem Installer angelegt, und dort die DB abgelegt.

Bzgl. GMIR siehe hier Grid Infrastructure Management Repository und Oracle Grid Infrastructure Management Repository (GIMR) siehe ⇒ Oracle Clusterware 12c - Grid Infrastructure Management Repository (GIMR)

Bzgl. Speicherplatz siehe hier 8.1.2 Oracle Clusterware Storage Space Requirements

D.h. ⇒

  • Space Required for DATA Disk Group containing Oracle Clusterware Files (OCR and Voting Files) ⇒ 1GB
  • Space Required for MGMT Disk Group containing the GIMR and Oracle Clusterware Backup Files ⇒ 28 GB

Bei mir hat aber der Installer beim Versuch alle 5 * VOT a 10GB zusammen zufassen (mit external Redundancy)! immer noch behauptet diese 50GB wären zu klein!

Evtl. sollten wir bei einer nächsten Installation für diese GMIR Kram gleich einen 100GB großen eigenen Bereich einplanen, hier jetz auf DATA gelegt, sollte daher auch passen.

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 das komplette Oracle Home zum Auspacken im Zielverzeichns.

Aus diesem Verzeichnis wird dann der Installer gestartet.

D.h. die Datei „linuxx64_12201_grid_home.zip“ wird direkt in das spätere Oracle Home des Clusters entpacket, in diesem Fall nach „/u01/app/12.2.0.1/grid“ :

cd /u01/app/12.2.0.1/grid
unzip -q /u01/app/oracle/install/linuxx64_12201_grid_home.zip

Aus diesem Verzeichnis wird dann auch der Installer gestartet:

cd /u01/app/12.2.0.1/grid
 
./gridSetup.sh

Ablauf:

SchrittBemerkung
1Configure Oracle Grid Infrastructure for a New Cluster
2Configure a Standard Cluster
3Product Language - English
4Cluster Name ⇒ „racdbCluster“ + Scan Listener DNS Name ⇒ „scanracdb.pipperr.local“ + Scan Port ⇒ 1521„ - Kein GNS
6Cluster Node Information“ - Zweiten Knoten hinzufügen (racdb02.pipperr.de - racdb02-vip.pipperr.de )
7Netzwerk Interfaces zuordnen
8„Configure ASM using block devices“
9„..want to create sepeate Automatic Storage Management (ASM) disk group for the Grid Infrastructure …“ ⇒ YES
10ASM Platte für OCR/VOT anlegen, dazu den Discovery Patch anpassen auf „/dev/oracleasm/disk/*“ , die fünf VOT Platten auswählen und den DISK Namen in „VOT“ ändern
10ASM Platte für GMIR anlegen, Disks auswählen und den DISK Namen in „DATA“ ändern
11ASM Passwörter setzen
12Kein IPMI verwenden
13Oracle Enterprise Manager ausswählen falls vorhanden
14Gruppen auswählen
15Oracle Base ⇒ „/opt/oracle“ und Grid Home ⇒ „/opt/12.1.0.2/grid“
16Directory für das Oracle Inventory auswählen ⇒ „/opt/oraInventory“
16Automatische 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
18Summary - Response File speichern
19Installation 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
20Abschluss der Installation, Fenster mit Close schließen

Umgebung und Logfiles des Clusters prüfen

Im Anschluss die Umgebung überprüfen:

export ORACLE_HOME=/u01/app/12.2.0.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
 
 
 
./crs_stat -t -v
Logfiles mit adrci prüfen
export  ADR_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/12.2.0.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

see:

  • 12.1.0.2 Oracle Clusterware Diagnostic and Alert Log Moved to ADR (Doc ID 1915729.1)
Problem PRVF-7573 : Sufficient swap size is not available on node "racdb01" [Required = 15.2881GB (1.6030712E7KB) ; Found = 4GB (4194300.0KB)]

Die Maschinen sind nicht so groß, da sollten eigentlich die 4GB Swap mehr als ausreichen.

Wie läßt sich nun aber diese Fehlermeldung im Log vermeiden?

Ignorieren oder den Swap vergrößen ist eine Möglichkeit, nicht sehr schön (siehe CRS-10051:CVU Found Following Errors With Clusterware Setup PRVF-7573 : Sufficient Swap (Doc ID 1946303.1))

Der Check wird durchgefürt von der „Clusterware resource ora.cvu“

Status und Einstellungen:

#Status
crsctl stat res ora.cvu -t
 
#Einstellungen
crsctl stat res ora.cvu -p

Versuche als nächstes ob die Paramter für den clufy Check sich einstellen lassen um die Meldung loßzubekommen, füllt nur das Logfile auf und verwirrt …

Log File Größe vergrößern

Kontrolle als root

export ORACLE_HOME=/u01/app/12.2.0.1/grid
$ORACLE_HOME/bin/crsctl get tracefileopts css
Get CSSD: Trace File Options: filesize=52428800,numsegments=10

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

su -
 
export ORACLE_HOME=/opt/12.1.0.2/grid
$ORACLE_HOME/bin/crsctl set tracefileopts css -filesize 157286400

Oracle Umgebung mit ORAchk überprüfen

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.


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 ⇒ 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.)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:

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

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 (mit alten Werkzeug .-) )
crs_stat -t -v

 12c - Scheller Check mit alten Tools crs_stat -t -v .-)


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

Patch für das Cluster einspielen

Aktuell Jan 2018 verwendet: Patch 27100009: GI JAN 2018 RELEASE UPDATE 12.2.0.1.180116

Am besten vor dem weiteren Anlegen von Oracle Homes, bei mir zuvor erst die 11g Umgebung angelegt, dann hat aber OPatch einige Probleme.

Opatch aktualisieren

Wie immer zuerst Opatch aktualisieren ⇒ OPatch patch of version 12.2.0.1.12 for Oracle software releases 12.1.0.x (installer) and 12.2.0.x (JAN 2018)

#auf dem Grid home als root
chmod g+w grid
 
# Als user grid
#Patch nach kopiert
/u01/app/oracle/install/12.2.0.1_patch/p6880880_122010_Linux-x86-64.zip
 
cd $ORACLE_HOME
mv OPatch/ OPatch_orig
 
unzip -q /u01/app/oracle/install/12.2.0.1_patch/p6880880_122010_Linux-x86-64.zip
 
cd OPatch
 
./opatch version
OPatch Version: 12.2.0.1.12
opatch auto

als Root User!

# Knoten 1
 
export PATH=$PATH:/u01/app/12.2.0.1/grid/OPatch
 
/u01/app/12.2.0.1/grid/OPatch/opatchauto apply /u01/app/oracle/install/12.2.0.1_patch/27100009
 
 
# Knoten 2
 
export PATH=$PATH:/u01/app/12.2.0.1/grid/OPatch
 
/u01/app/12.2.0.1/grid/OPatch/opatchauto apply /u01/app/oracle/install/12.2.0.1_patch/27100009

Problem - im 11g Oracle Home wird das falsche Java erkannt

Lösung: das JRE im 11g Home ist zu alt, bei Check der DB Homes des clustes wird anscheinend etwas mit dem Opatch des Oracle Homes aufgerufen, in dem Fall mit dem 11g Home und dort ist das java zu alt…

OPATCHAUTO-72050: System instance creation failed.
OPATCHAUTO-72050: Failed while retrieving system information.
OPATCHAUTO-72050: Please check log file for more details.
 
OPatchauto session completed at Sun Apr 15 23:20:12 2018
Time taken to complete the session 1 minute, 8 seconds
 
Topology creation failed.
 
 
2018-04-15 23:20:11,792 FINE  [1] com.oracle.glcm.patch.auto.db.product.driver.crs.AbstractCrsProductDriver - Checking whether Oracle Home "/u01/app/oracle/product/11.2.0.4/dbhome_1" is shared or not.
 
 
2018-04-15 23:20:12,000 INFO  [53] oracle.dbsysmodel.driver.sdk.util.OsysUtility$ReaderThread -
2018-04-15 23:20:12,000 INFO  [53] oracle.dbsysmodel.driver.sdk.util.OsysUtility$ReaderThread - Unsupported Java version 1.6.
2018-04-15 23:20:12,000 INFO  [53] oracle.dbsysmodel.driver.sdk.util.OsysUtility$ReaderThread - Java version should be 1.7 or higher.
2018-04-15 23:20:12,000 INFO  [53] oracle.dbsysmodel.driver.sdk.util.OsysUtility$ReaderThread -
2018-04-15 23:20:12,000 INFO  [53] oracle.dbsysmodel.driver.sdk.util.OsysUtility$ReaderThread - No valid java found for patching.opatchauto cannot proceed!
 
2018-04-15 23:20:12,003 INFO  [1] oracle.dbsysmodel.driver.sdk.util.OsysUtility - Error message :::
2018-04-15 23:20:12,004 INFO  [1] oracle.dbsysmodel.driver.sdk.util.OsysUtility - Output message :::
2018-04-15 23:20:12,004 SEVERE [1] com.oracle.glcm.patch.auto.db.integration.model.productsupport.topology.TopologyCreator - Not able to retrieve system instance details :: IOException during persisting of HostData
 
2018-04-15 23:20:12,004 SEVERE [1] com.oracle.glcm.patch.auto.db.integration.model.productsupport.topology.TopologyCreator - Failure reason::null

Debug:

test der Java Version im 11.2 Home

[root@ dbhome_1]# ./OPatch/jre/bin/java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04, mixed mode)

Hier könnte eine der Ursachen liegen,

Links setzen auf beiden Konoten!

cd /u01/app/oracle/product/11.2.0.4/dbhome_1/OPatch
 
mv jre/ jre_orig
 
ln -s /u01/app/12.2.0.1/grid/OPatch/jre/ jre

Erneut testen ….


ACFS

Zuerst prüfen ob für den Kernel und das Release weitere Schritte notwendig sind,siehe ACFS Support On OS Platforms (Certification Matrix). (Doc ID 1369107.1)

In meinen Fall, Oracle Linux mit Oracle Kernel 7.3 und Oracle 12c R2 scheinen keine weiteren Patche notwendig zu sein.

Voraussetzungen prüfen

Test ob alles supported ist:

Als user root auf beiden Knoten testen:

/u01/app/12.2.0.1/grid/bin/acfsdriverstate version
ACFS-9325:     Driver OS kernel version = 4.1.12-32.el7uek.x86_64(x86_64).
ACFS-9326:     Driver Oracle version = 171115.
ACFS-9212:     Driver build version = 12.2.0.1 (ACFSRU)..

Als user grid auf beiden Knoten testen:

# Oracle Umgebung setzen
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 external redundancy disk '/dev/oracleasm/disks/DATA_09';
-- testen ob es klappt, dann die anderen Platten
ALTER DISKGROUP ACFS ADD DISK
     '/dev/oracleasm/disks/DATA_10',
     '/dev/oracleasm/disks/DATA_11',   
 ;
 
# 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 12.1 

Volumen anlegen:

#Anlegen
ASMCMD> volcreate -G ACFS -s 650G volbackup01
Volume Namen ermitteln
#Anzeigen lassen:
ASMCMD> volinfo -G ACFS volbackup01
Diskgroup Name: ACFS
 
         Diskgroup Name: ACFS
 
         Volume Name: VOLBACKUP01
         Volume Device: /dev/asm/volbackup01-430
         State: ENABLED
         Size (MB): 665600
         Resize Unit (MB): 512
         Redundancy: UNPROT
         Stripe Columns: 8
         Stripe Width (K): 1024
         Usage:
         Mountpath:
 
exit

Auf den Namen des Volume Device achten!

Filesystem auf dem Volume anlegen

Als root:

/sbin/mkfs -t acfs /dev/asm/volbackup01-430
 
mkfs.acfs: version                   = 12.2.0.1.0
mkfs.acfs: on-disk version           = 39.0
mkfs.acfs: volume                    = /dev/asm/volbackup01-430
mkfs.acfs: volume size               = 697932185600  ( 650.00 GB )
mkfs.acfs: Format complete.
Filesystem registrieren

Als root:

mkdir /u01/app/oracle/acfs
chown grid:oinstall acfs
chmod g+w acfs
 
/sbin/acfsutil registry -a /dev/asm/volbackup01-430 /u01/app/oracle/acfs
 
acfsutil registry: mount point /u01/app/oracle/acfs successfully added to Oracle Registry
Filesystem mounten

Als root:

/bin/mount -t acfs /dev/asm/volbackup01-430 /u01/app/oracle/acfs
 
chown -R grid:dba /u01/app/oracle/acfs
 
#All oracle stuff on the system schould use it
chmod 777 /u01/app/oracle/acfs
Fileystem prüfen

Als Grid User:

cd /u01/app/oracle/acfs
 
touch test.txt
Auf dem zweiten Knoten verwenden

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 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:

acfsutil info fs
 
//u01/app/oracle/acfs
    ACFS Version: 12.2.0.1.0
    on-disk version:       39.0
    compatible.advm:       12.1.0.0.0
    ACFS compatibility:    12.1.0.0.0
    ..
    volumes:      1
    total size:   697932185600  ( 650.00 GB )
    total free:   696467767296  ( 648.64 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 ….“


Installation der Oracle Datenbank Software 11.2.0.4 in einem Oracle 12c R2 Cluster

Da sich der Kunde vor der 12c Datenbank „fürchtet“ wird noch eine 11g R2 DB in diesem Cluster eingesetzt.

Zu empfehlen ist das nicht, da die 11g auch bald aus dem Support läuft.

Ein großes Problem - Installer bleibt mit seltsamen Hinweis Fenster hängen„

Der Oracle Installer für die 11g R2 ist ja auch schon etwas in die Jahre gekommen (JAVA used in 11204 shiphome is „1.5.0_51“ ! ) und hat mit dem Oracle Linux 7.3 so seine Probleme. So läßt sich zum Beispiel ein Dialog nach dem Check der Vorraussetzung nicht mehr bedienen.

Installer hängt bei PreRequisit Check

Zum Glück gibt es hier eine Support Node ⇒ Oracle 11.2.0.4 Installer Appears To Be Hung At Prerequisite Check Page On Oracle Linux 7.3 (Doc ID 2245337.1)

Allerdings ist die Lösung (4* TAB + Return) um im Hintergrund die richtigen „Buttons“ zu drücken zwar ok um diesen Dialog zu überspringen, später ist es aber dann doch ganz abgestützt.

Zum Glück einen Repsonce File angefertigt, und nun mit diesem Responce File die DB Software installiert:

# in das Installationsverzeichnis springen
 
./runInstaller -silent -responseFile /home/oracle/db.rsp -ignorePrereq -ignoreSysPreregs

Die beiden Ingnore Anweisungen werden benötigt um die Dialog nach dem Check der Vorraussetzung zu überspringen, diese passen ja nicht, z.b. ist das Cluster zu neu für den Installer!

Letzten aktuellen Patch für die Datenbank installieren

Vor der Installation der DB nicht vergessen den aktuellen Patch einzuspielen!

Stand April 2018 ⇒ Patch 26925576: DATABASE PATCH SET UPDATE 11.2.0.4.180116 - Last Update 16-Jan-2018 14:55 (2+ months ago) + Patch 6880880: OPatch patch of version 11.2.0.3.18 for Oracle software releases 11.2.0.x (JAN 2018)


Datenbank installieren

Als DB Owner Oracle

Folgendes Setup soll eingehalten werden:

  • Zeichensatz : AL32UTF8
  • Datendateien auf : DATA
  • RedoLog Gruppe A : DATA
  • Redolog Gruppe B : RECO

Local und Remote Listener Parameter in der DB hinterlegen

Orachk Warning:

 WARNING => Local listener init parameter is not set to local node VIP for GPIDB
 WARNING => Remote listener is not set to SCAN name for GPIDB

Überprüfen mit:

SHOW parameter listener

hmm, passt hier irrt oraChk.

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 GPIPRD -s GPIPRDDB -r GPIPRD1,GPIPRD2  -P NONE -B THROUGHPUT -j LONG
srvctl start  service -d GPIPRD -s GPIPRDDB 
srvctl status service -d GPIPRD

Weitere Schritte in dieser Umgebung

Transparent Gateway

Umgebung prüfen mit Oracle Trace File Analyzer

Zuvor den Tracefile Analyser auf die letzte Version updaten über das Support Protal unter FA Collector - TFA with Database Support Tools Bundle (Doc ID 1513912.1)

Update

als root User

Root muss sich per ssh mit Key auf allen Knoten anmelden können!

Laut Doku wird eine alte Version automatisch ersetzt.

Ablauf;

  • Download der Software TFA-LINUX_v18.1.1.zip auf den Server , z.b. nach /u01/app/oracle/install/TFA
  • Auspacken unzip TFA-LINUX_v18.1.1.zip
  • Installer starten mit
     $ ./installTFA-LINUX

    Und das Update wird automatisch durchgeführt :-) .

Doku ⇒ https://docs.oracle.com/cd/E91263_01/TFAUG/tfa-command-reference.htm

Check

# check status als root
[root]# /u01/app/12.2.0.1/grid/bin/tfactl status

# Check starten mit

/u01/app/12.2.0.1/grid/bin/tfactl orachk
 
# Meldungen bzgl. ssh ignoriern und mit n beantworten

siehe auch ⇒ Oracle 12c RAC Umgebung mit Oracle Trace File Analyzer (TFA) überprüfen

Problem : Access Denied: Only TFA Admin can run this command

als root user:

cd /u01/app/12.2.0.1/grid/bin
 
./tfactl access lsuser
 
 
# User freischalten
./tfactl access enable
./tfactl access add -user oracle
./tfactl access add -user grid

Quellen

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
dba/install_rac_linux_12c_r2.txt · Zuletzt geändert: 2018/10/31 21:18 von gpipperr