Gunther Oracle APEX und Datenbank Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
=====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:
<code bash>
# 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

</code>


== 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]]

<code bash>
# 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
</code>

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 <fc #800000>root</fc> user anmelden und auf BEIDEN Knoten installieren!
<code bash>

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

</code>

=== 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" :
<code bash>
cd /u01/app/12.2.0.1/grid
unzip -q /u01/app/oracle/install/linuxx64_12201_grid_home.zip
</code>


Aus diesem Verzeichnis wird dann auch der Installer gestartet:
<code bash>
cd /u01/app/12.2.0.1/grid

./gridSetup.sh

</code>


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

</code>


==Logfiles mit adrci prüfen==

<code bash>
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
</code>

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:
<code bash>
#Status
crsctl stat res ora.cvu -t

#Einstellungen
crsctl stat res ora.cvu -p

</code>

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
<code bash>
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
</code>


Vergrößern (auf beiden Knoten durchführen!):
<fc #800000>**User: root**</fc>
<code bash>
su -

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

</code>


----
=== 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 verteilen<code bash>ssh racdb02 mkdir ~/sql 
scp .bash_profile .profile racdb02:$PWD/
scp *.* racdb02:$PWD/</code>
  * 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====

<fc #800000>**User: grid**</fc>

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

== SQLNET.EXPIRE_TIME ==

Auf JEDEM knoten die Datei "sqlnet.ora" anpassen:

<code bash>

vi $ORACLE_HOME/network/admin/sqlnet.ora

# Parameter for the listner, check after 30min if connection is still alive
SQLNET.EXPIRE_TIME = 30

</code>

== Scan Listener überprüfen ==

<code bash>
srvctl config scan
</code>

== 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.

<code bash>
#ersten Knoten stoppen
reboot

#30s warten

#zweiten Knoten stoppen
reboot

</code>

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

Prüfen:
<code bash>
#Umgebung setzen setdb

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

</code>

{{: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:
<code bash>

#Grid umgebung einrichten

asmca &

# Dauert etwas das es startet, etwas Geduld von nöten

</code>



----

==== 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)


<code bash>
#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

</code>

== opatch auto ==

als Root User!

<code bash>

# 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

</code>


**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...

<code bash>

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


</code>

Debug:

test der Java Version im 11.2 Home
<code bash>

[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)


</code>

Hier könnte eine der Ursachen liegen, 

Links setzen auf beiden Konoten!
<code bash>
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
</code>

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:
<code bash>
/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)..
</code>

Als user grid auf beiden Knoten testen:
<code bash>

# Oracle Umgebung setzen
acfsdriverstate supported

=> ACFS-9200: Supported

</code>

Wenn auf beiden Knoten "acfsdriverstate supported => ACFS-9200: Supported", kann es weitergehen.


=== ASM Disk einrichten ==

<code bash>
# 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;

</code>

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

<code bash>
ASMCMD>setattr  -G ACFS compatible.asm 12.1 
</code>

Volumen anlegen:
<code bash>
#Anlegen
ASMCMD> volcreate -G ACFS -s 650G volbackup01

</code>

==Volume Namen ermitteln==

<code bash>
#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
</code>

Auf den Namen des Volume Device achten!

==Filesystem auf dem Volume anlegen==

Als root:
<code bash>
/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.

</code>

==Filesystem registrieren==

Als root:
<code bash>

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

</code>

==Filesystem mounten==
Als root:
<code bash>

/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

</code>

==Fileystem prüfen==

Als Grid User:
<code bash>
cd /u01/app/oracle/acfs

touch test.txt
</code>


== 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:
<code bash>

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 )

 ...

....

</code>

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:

<code bash>
# in das Installationsverzeichnis springen

./runInstaller -silent -responseFile /home/oracle/db.rsp -ignorePrereq -ignoreSysPreregs

</code>

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

</code>

Überprüfen mit:
<code sql>
show parameter listener
</code>

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!

<code bash>

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

</code>




----


==== 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 <code bash> $ ./installTFA-LINUX</code> Und das Update wird automatisch durchgeführt :-) .

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

=== Check ===
<code bash>
# check status als root
[root]# /u01/app/12.2.0.1/grid/bin/tfactl status
</code>


# Check starten mit 

<code bash>

/u01/app/12.2.0.1/grid/bin/tfactl orachk

# Meldungen bzgl. ssh ignoriern und mit n beantworten

</code>

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

<code bash>

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

</code>


----

==== Quellen ====

Weiter Installationsbeschreibungen:

  * https://oracle-base.com/articles/12c/oracle-db-12cr2-rac-installation-on-oracle-linux-7-using-virtualbox