=====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 => [[dba:install_rac_linux_12c|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 [[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]]
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 [[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 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 [[ https://docs.oracle.com/en/database/oracle/oracle-database/18/cwlin/about-gimr.html | Grid Infrastructure Management Repository ]] und Oracle Grid Infrastructure Management Repository (GIMR) siehe => [[dba:oracle_rac_12c_gmir|Oracle Clusterware 12c - Grid Infrastructure Management Repository (GIMR)]]
Bzgl. Speicherplatz siehe hier [[https://docs.oracle.com/en/database/oracle/oracle-database/18/cwlin/oracle-clusterware-storage-space-requirements.html|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:
^Schritt^Bemerkung^
|1|Configure Oracle Grid Infrastructure for a New Cluster|
|2|Configure a Standard Cluster|
|3|Product Language - English|
|4|Cluster Name => "racdbCluster" + Scan Listener DNS Name => "scanracdb.pipperr.local" + Scan Port => 1521" - Kein GNS|
|6|Cluster Node Information" - Zweiten Knoten hinzufügen (racdb02.pipperr.de - racdb02-vip.pipperr.de )|
|7|Netzwerk Interfaces zuordnen|
|8|"Configure ASM using block devices" |
|9|"..want to create sepeate Automatic Storage Management (ASM) disk group for the Grid Infrastructure ..." => YES |
|10|ASM 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 |
|10|ASM Platte für GMIR anlegen, Disks auswählen und den DISK Namen in "DATA" ändern |
|11|ASM Passwörter setzen |
|12|Kein IPMI verwenden |
|13|Oracle Enterprise Manager ausswählen falls vorhanden |
|14|Gruppen auswählen|
|15|Oracle Base => "/opt/oracle" und Grid Home => "/opt/12.1.0.2/grid"|
|16|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|
|20|Abschluss 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 [[dba:oracle_rac_12c_orachk|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 => [[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:
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 (mit alten Werkzeug .-) )
crs_stat -t -v
{{:dba:rac:rac_12c_check_cluster_01.png?400| 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.
{{ :dba:install_11g_db_oracle7_installer_hangs.png?400 |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 ===
Siehe => [[dba:db_link_linux_ms_sql_12c|Oracle 12c RAC Real Application Cluster Datenbank über einen Datenbank Link mit einer MS SQL 2017 Datenbank verbinden - Oracle Database Gateway unter Oracle Linux 7 einsetzen]]
----
==== 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 => [[dba:oracle_rac_12c_tfa_trace_file_analyser|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 ====
Weiter Installationsbeschreibungen:
* https://oracle-base.com/articles/12c/oracle-db-12cr2-rac-installation-on-oracle-linux-7-using-virtualbox