Oracle RAC 12.1 Summary Deployment and Admin

If you need a good overview and introduction in Oracle 12.1 RAC take a look to the following document.

RAC-12.1-Deployment-Admin

 

 

 

 

 

Advertisements

reinstall tfactl after GI Upgrade 12.1.0.2

tfactl

Recently I finished a Grid Upgrade from 11.2.0.4 to 12.1.0.2 + PSU JUL 2016. So far so good during a check I saw that the old tfactl tool under Software Release 11.2.0.4 where up and running.

That could not be okay.  So I start an Uninstall and Setup for Release 12.1.0.2.

What steps has to be done?

Check the actual tfactl installation


 /u01/app/grid/tfa/bin/tfactl print config

Start the unistall on both nodes


[root@db03 bin]# ./tfactl uninstall
TFA will be Uninstalled on Node db03: 

Removing TFA from db03 only
Please remove TFA locally on any other configured nodes

Notifying Other Nodes about TFA Uninstall...
Sleeping for 10 seconds...

Stopping TFA Support Tools...
Stopping TFA in db03...
Shutting down TFA
oracle-tfa stop/waiting
. . . . . 
Killing TFA running with pid 159597
. . . 
Successfully shutdown TFA..

Deleting TFA support files on db03:
Removing /u01/app/oracle/tfa/db03/database...
Removing /u01/app/oracle/tfa/db03/log...
Removing /u01/app/oracle/tfa/db03/output...
Removing /u01/app/oracle/tfa/db03...
Removing /u01/app/oracle/tfa...
Removing /etc/rc.d/rc0.d/K17init.tfa
Removing /etc/rc.d/rc1.d/K17init.tfa
Removing /etc/rc.d/rc2.d/K17init.tfa
Removing /etc/rc.d/rc4.d/K17init.tfa
Removing /etc/rc.d/rc6.d/K17init.tfa
Removing /etc/init.d/init.tfa...
Removing /u01/app/11.2.0.4/grid/bin/tfactl...
Removing /u01/app/11.2.0.4/grid/tfa/bin...
Removing /u01/app/11.2.0.4/grid/tfa/db03...

The same on the other node

The new tfactl Setup


[root@db03 install]# ./tfa_setup -silent -crshome /u01/app/12.1.0.2/grid
TFA Installation Log will be written to File : /tmp/tfa_install_63022_2016_10_18-14_30_43.log
Starting TFA installation

Using JAVA_HOME : /u01/app/12.1.0.2/grid/jdk/jre
Running Auto Setup for TFA as user root...
Installing TFA now...

TFA Will be Installed on db03...
TFA will scan the following Directories
++++++++++++++++++++++++++++++++++++++++++++
.-------------------------------------------------------.
| db03 |
+--------------------------------------------+----------+
| Trace Directory | Resource |
+--------------------------------------------+----------+
| /u01/app/12.1.0.2/grid/OPatch/crs/log | CRS |
| /u01/app/12.1.0.2/grid/cfgtoollogs | CFGTOOLS |
| /u01/app/12.1.0.2/grid/crf/db/db03 | CRS |
| /u01/app/12.1.0.2/grid/crs/log | CRS |
| /u01/app/12.1.0.2/grid/cv/log | CRS |
| /u01/app/12.1.0.2/grid/evm/admin/log | CRS |
| /u01/app/12.1.0.2/grid/evm/admin/logger | CRS |
| /u01/app/12.1.0.2/grid/evm/log | CRS |
| /u01/app/12.1.0.2/grid/install | INSTALL |
| /u01/app/12.1.0.2/grid/log | CRS |
| /u01/app/12.1.0.2/grid/network/log | CRS |
| /u01/app/12.1.0.2/grid/oc4j/j2ee/home/log | DBWLM |
| /u01/app/12.1.0.2/grid/opmn/logs | CRS |
| /u01/app/12.1.0.2/grid/racg/log | CRS |
| /u01/app/12.1.0.2/grid/rdbms/log | ASM |
| /u01/app/12.1.0.2/grid/scheduler/log | CRS |
| /u01/app/12.1.0.2/grid/srvm/log | CRS |
| /u01/app/oraInventory/ContentsXML | INSTALL |
| /u01/app/oraInventory/logs | INSTALL |
| /u01/app/oracle/crsdata/db03/acfs | ACFS |
| /u01/app/oracle/crsdata/db03/core | CRS |
| /u01/app/oracle/crsdata/db03/crsconfig | CRS |
| /u01/app/oracle/crsdata/db03/crsdiag | CRS |
| /u01/app/oracle/crsdata/db03/cvu | CRS |
| /u01/app/oracle/crsdata/db03/evm | CRS |
| /u01/app/oracle/crsdata/db03/output | CRS |
| /u01/app/oracle/crsdata/db03/trace | CRS |
'--------------------------------------------+----------'

Installing TFA on db03:
HOST: db03 TFA_HOME: /u01/app/12.1.0.2/grid/tfa/db03/tfa_home
.-----------------------------------------------------------------------------.
| Host | Status of TFA | PID | Port | Version | Build ID |
+----------+---------------+-------+------+------------+----------------------+
| db03 | RUNNING | 63460 | 5000 | 12.1.2.7.0 | 12127020160304140533 |
'----------+---------------+-------+------+------------+----------------------'

Running Inventory in All Nodes...
Enabling Access for Non-root Users on db03...

Adding default users to TFA Access list...
Summary of TFA Installation:
.--------------------------------------------------------------------.
| db03 |
+---------------------+----------------------------------------------+
| Parameter | Value |
+---------------------+----------------------------------------------+
| Install location | /u01/app/12.1.0.2/grid/tfa/db03/tfa_home |
| Repository location | /u01/app/oracle/tfa/repository |
| Repository usage | 0 MB out of 10240 MB |
'---------------------+----------------------------------------------'


Installing oratop extension..
TFA is successfully installed...
And also the same on the other node.

Last but not least check the new Setup on both Nodes


Check the status and configuration
tfactl print status 
tfactl print config


That's it. :-)
 
It is very easy and done in a few minutes.
tfactl is a helpful tool not only for Oracle Support 
take a few minutes and go through the following 
My Oracle Support Note: 1513912.1




 

OOW 2016 dritter Tag

oow_tag3

Tag drei auf der OpenWorld. Man hat das Gefühl, es werden von Tag zu Tag mehr Teilnehmer.

Der erste Vortrag kommt von Markus (Michalewicz). Er präsentiert die neuen Features von RAC 12.2. So wie man Ihn kennt sehr detailliert, daher spare ich mir tiefe Details, denn er kommt im November zur DOAG Konferenz 2016.

Hier ein paar Topics:

  • Better Scaleout
  • Singleton Services
  • more Availability mit dem Health Framework
  • new Node Eviction „Mode“
  • News im Bereich Flexcluster
  • und vieles mehr

Das nächste Highlight war die Keynote von Larry Ellison. Es wurde ausführlich das Thema Oracle in the Cloud und eine genaue Gegenüberstellung von Amazon Cloud Technologie und Oracle Cloud Technologie präsentiert.

Danach habe ich mir den Vortrag  „Deep Dive Oracle Database 12.2 Sharding“ angehört. Hier plant Facebook mit Oracle 12.2 einen POC. Die Technologie und Möglichkeiten finde ich sehr interessant. Mal sehen wie schnell sich dies durchsetzt (und verfügbar sein wird). Es werden auf jeden Fall alle bekannten Technologien vom RDBMS wie Partitioning, RMAN etc. Sharding supporten. Klar ist aber das man ein komplett neues Design der Anwendung vornehmen muss.

Zum guten Schluss „Next Generation Recovery Manager“

Einige neue Features in 12.2:

  • Enhancement for Table Recovery
  • Enhancements for Multitenant Databases
  • RMAN Duplicate using Encrypted Backups
  • RMAN & Data Guard
    • Introduction for Far Sync
    • Duplicate from an Physical Standby for regular Databases
  • Support for Oracle Sharding
  • Backup & Recovery of Sparse Databases
  • Flashback Enhancements
    • Support for Pluggable Databases
    • Support for Normal Restore Points
    • Support for Guaranteed Restore Points

 

Mögliche Tippfehler bitte ich zu entschuldigen

 

 

opatch lsinv doesn’t show Patching level of clusternodes

cluster_patch

 

 

 

We had a strange behaviour while running the „opatch lsinv“ in our Clusterware environment.

The opatch tool doesn’t show at the end the patchlevel and the name of the nodes itself.

It seems that during a lot of patch actions on this cluster that we lost the information inside the inventory.xml file that the CRS is equal true.

After researching of MOS we found a solution for this problem described in Doc-ID 1053393.1.

There ist a possibility to Update a flag CRS=true via the runinstaller in the GRID environment.

So the steps to fix this problem are the following

Our environment is a two node Oracle Enterprise Linux RAC Cluster with GI Software 12.1.0.2.


/u01/app/12.1.0.2/grid/oui/bin/runInstaller 
    -updateNodelist ORACLE_HOME="/u01/app/12.1.0.2/grid" CRS=true

Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB. Actual 24575 MB Passed
The inventory pointer is located at /etc/oraInst.loc

'UpdateNodeList' was successful.

The "opatch lsinv" command show now the correct Patching Level and name of the Cluster nodes.

node1
Patch level status of Cluster nodes :

Patching Level Nodes
-------------- -----
1146027977 node2,node1

--------------------------------------------------------------------------------
node2
Patch level status of Cluster nodes :

Patching Level Nodes
-------------- -----
1146027977 node2,node1

--------------------------------------------------------------------------------
OPatch succeeded.

Additonal information

Check the software Patching level via the following command and compare the output with the „opatch lsinv“ as shown above.

[oracle@node1 ~]$crsctl query crs softwarepatch
Oracle Clusterware patch level on node node1 is [1146027977]

Yes, it is a good idea from time to time to check if both commands have the same output and also to update the opatch tool in your environment.

The latest opatch version can be downloaded via MOS link https://updates.oracle.com/download/6880880.html

 

 

 

Clone ORACLE_HOME before installation of One-Off Patch

clone Kopie

We received a task from the quality department they need to test a new One-Off Patch in the test environment but we should not patch the actual installed version on this machine.

What could be a solution?

Often DBA’s install in this situation the whole Oracle Software stack from scratch and afterwards they patch this environment. But this could be very time consuming if you have to install a few bundle patches and some One-Off Patches.

We solve this problem by cloning the ORACLE_HOME and it works very good.

The environment is a two node RAC Cluster based on ASM with Grid & Oracle 11.2.0.4 software installed.

My Oracle Support: Doc ID 1221705.1 Cloning An Existing Oracle 11g Release 2

the steps are

as root user start a copy

cp -Rp /u01/app/oracle/product/11.2.0.4/dbhome_1 /u01/app/oracle/product/11.2.0.4/dbhome_2
as oracle user set the correct environment and start the Installer

cd $ORACLE_HOME/oui/bin

./runInstaller -detachHome ORACLE_HOME="/u01/app/oracle/product/11.2.0.4/dbhome_2"


cd $ORACLE_HOME/clone/bin

Start the perl script for cloning

perl clone.pl ORACLE_HOME="/u01/app/oracle/product/11.2.0.4/dbhome_2" ORACLE_HOME_NAME="OraDb11g_home3" ORACLE_BASE="/u01/app/oracle" OSDBA_GROUP=oinstall OSOPER_GROUP=oinstall

as root user start the root.sh script

/u01/app/oracle/product/11.2.0.4/dbhome_2/root.sh

final steps

check the log files

create the new diag directories

/u01/app/oracle/product/11.2.0.4/dbhome_2/bin/diagsetup basedir="/u01/app/oracle" oraclehome="/u01/app/oracle/product/11.2.0.4/dbhome_2"

Set the GRID environment and change the listener.ora for. ORACLE_HOME

lsnrctl reload listener

modify the “/etc/oratab”

While using RAC check the linked Oracle options Doc ID 948061.1

cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk rac_on ioracle
make -f ins_rdbms.mk ipc_rds ioracle

Now modify the database home

srvctl modify database -d tdb5o_s1 -o /u01/app/oracle/product/11.2.0.4/dbhome_2

srvctl start database -d tdb5o_s1

So the setup of the „new“ ORACLE_HOME is ready. Start with the installation of the One-Off Patch in rolling manner. (rolling while it is a RAC environment and the Patch is rolling installable.)

conclusion

As you see it is very easy to setup a second ORACLE_HOME for testing purposes.

If your One-Off Patch also updates the database via SQL Script use Flashback Database to set an guaranteed restore point before starting with the patching task.

After testing the One-Off Patch you do a flashback database and it is the same software level as before installing the patch.

 

tfactl configuration for „repositorydir“

tfactl125

After a system crash Oracle Support asked for a tracefile collection with the option „-all“.

Yes this will be a huge file because the required analysis runs over a few days.

In the default configuration the tfactl repository is under  the Oracle base structure normally „/u01/app/oracle“.

The Filesystem „/u01“ has actually only 20 GB freespace and the collection which has to be done for the cluster generates files of minimum 18 GB.

This means freespace for „/u01“ is very scarce.I need a temporary solution and after a while and reading the tfactl users guide I found a solution.

With the following command „SET REPOSITORYDIR“ it is possible to change the location temporary or permanently.

/u01/app/12.1.0.2/grid/bin/tfactl set repositorydir=/mnt/gi12102_sr

Successfully changed repository

.------------------------------------------------------------.

| Repository Parameter      | Value                          |

+---------------------------+--------------------------------+

| Old Location              | /u01/app/oracle/tfa/repository |

| New Location              | /mnt/gi12102_sr                |

| Current Maximum Size (MB) | 10240                          |

| Current Size (MB)         | 0                              |

| Status                    | OPEN                           |

'---------------------------+--------------------------------'

I started the tfactl and the data collection works fine. Here the comand.

tfactl diagcollect -from "Aug/20/2015 12:00:00" -to "Aug/22/2015 19:00:00"

After the data colection I changed the directory back to the old location.

/u01/app/12.1.0.2/grid/bin/tfactl set repositorydir=/u01/app/oracle/tfa/repository

For more details take a look to MOS note: TFA Collector – Tool for Enhanced Diagnostic Gathering ( Doc ID 1513912.2 )

Trace File Analyzer (TFA) in Oracle Version 12.1.0.2

Der Tracefile Analyzer (TFA) seit Oracle 11.2.0.4 verfügbar und mit 12.1.0.2 mit wirklich tollen Features.

Historie

Oracle bietet eine Vielzahl von Diagnosetools im Umfeld der Clusterware an. Schaut man sich auf den einschlägigen Blogs von Oracle um, so stellt man fest, dass man den vor lauter Bäumen den Wald nicht mehr sieht. Da wären unter anderem:

  • „cluvfy“ Cluster Verification Utility
  • „CHM“  Cluster Health Monitor
  • „RACcheck“ RAC Check
  • „RDA“ Tool Remote Diagnostic Tool
  • „OSWatcher“ OS Watcher
  • „ExaWatcher“ Exa Watcher
  • „TFA“ Trace File Analyzer

Toolübersicht

 

Tool Beschreibung Anmerkung
cluvfy Vor, während und nach der Installation einer Cluster Umgebung. Bestandteil der Grid-Installationssoftware
RACcheck RACcheck Configuration Audit Tool – Name wurde geändert in ORAchk  (Oracle Configuration Audit Tool).raccheck und orachk sind von der Funktion identisch.Empfohlener Einsatz von ORAchk:·        After initial Oracle RAC deployment·        Before planned system maintenance·        After planned system maintenance·        4. At least once every three months MOS note: 1591208.1
RDA Remote Diagnostic Tool. Aktuelle version 8.04Der RDA Output liefert ein umfassendes Bild der Kundenumegbung wie z.B.:

  • Product Problemen
  • Developer Fragen
  • Installation/configuration Problemen
  • ORA-600, ORA-7445, ORA-3113, and ORA-4031 Fehlern
  • Oracle Database Fehlern
  • Oracle Application Server/Fusion Middleware Fragen
  • Performance Problemen
  • Upgrade, Migration Aufgabenstellungen

 

MOS Note: 414966.1, 314422.1
CHM Cluster Health MonitorCluster Health Monitor sammelt OS Statistiken MOS note: 1328466.1
OSWatcher OSWatcher sammelt Statistiken indem Unix Kommandos wie z.B. vmstat, top, ps, iostat, netstat, mpstat, und meminfo laufen.Der Cluster Health Monitor wurde entwickelt um System Metriken und Daten für das Troubleshooting bereitszustellen. Dazu gehören Node Reboots oder System Situationen die ein Cluster zum “Stillstand” bringen.
ExaWatcher ExaWatcher ersetzt den OSWatcher. MOS note: 1617454.1
TFA Tracefile Analyzer Diagnostic Collection Tool zum Sammeln der Clusterware Trace Daten MOS note: 1513912.1

Die Liste der Tools erhebt keinen Anspruch auf Vollständigkeit.  Welches dieser Tools eingesetzt wird hängt unter anderem vom Einsatzzweck ab und teilweise werden mehrere Tools parallel genutzt bzw. konfiguriert. So ist es durchaus sinnvoll in einer Cluster Umgebung neben dem TFA auch das RDA Tool zu installieren. Die Entscheidung trifft jede IT Betriebsorganisation für sich selbst. In diesem Artikel wird nun Folgend der Tracefile Analyzer [TFA] vorgestellt.

TFA Trace File Analyzer

Installiert man die Grid Infrastructure Software in der Version 12.1.0.2, so wird ab sofort automatisch der TFA parallel installiert und konfiguriert. Eine manuelle oder nachgelagerte Installation per Zip-Package ist natürlich auch möglich.

Der TFA sammelt folgende Daten:

  • Betriebssystem
  • Oracle Clusterware
  • Oracle Automatic Storage Management
  • Oracle Database Diagnostic Data

Weitere Funktionen sind das Cluster-weite Sammeln der Daten, so wie das Paketieren der Log Informationen. Des Weiteren ist es möglich Daten zu anonymisieren und User zu verwalten.

Zudem gibt es eine Funktion, die den TFA automatisiert starten kann, sobald z.B. ein Incident auftritt. Dies verhindert den Verlust relevanter Informationen durch Logfile Rotationen.

Mit der TFA Version 12.1.0.2, wurde eine sogenannte „analyze“ Funktion eingebaut, die  den täglichen Administrationsaufwand erheblich erleichtert. So kann nun beispielsweise analysiert werden, welche Fehler in einem bestimmten Zeitraum aufgetreten sind. Auf diesen Punkt soll im späteren Verlauf näher eingegangen werden.

Alles in allem lohnt es sich auch in der Grid Infrastruktur Release 11.2.0.4 den TFA zu installieren, denn die Arbeit für das Sammeln und Verschicken von Logfiles vereinfacht sich erheblich. Der TFA ermöglicht insgesamt deutlich effektiveres und sehr zeitsparendes Vorgehen.

TFA Architektur und Installation

Der TFA basiert auf einer Java virtuellen Maschine, welche auf jedem Host im Cluster läuft. Auf jedem dieser Hosts existiert darüber hinaus  eine Berkley Datenbank (BDB) welche die Metadaten, Verzeichnisse und Dateien speichert, die TFA überwacht. TFA wird seit der Version 11.2.0.4 ausgeliefert und installiert. In der Release 12.1.0.2 wurde der Funktionsumfang deutlich erweitert.

Als Plattform werden Solaris, Linux, AIX und HP-UX unterstützt.

TFA Installation

Die Installation wird bei einem Upgrade der Grid Infrastructure Software auf 11.2.0.4 automatisch vorgenommen. TFA ist darüber hinaus  fester Bestandteil bei jeder 12.1 Grid Infrastruktur Installation.

Daneben besteht die Möglichkeit sich die Software über MOS herunterzuladen und manuell zu installieren.  In diesem Fall werden die heruntergeladenen Dateien bzw. das Zip Archive entpackt. Die weiteren Aufgaben übernimmt der Installer, welcher root Rechte benötigt. Root Rechte sind notwendig, da Systemlogs, sowie ein automatischer Start während der Bootphase eingerichtet werden müssen. Eine „silent“ Installation wie man sie von der Grid oder RDBMS Software kennt ist ebenfalls möglich.

Weiterlesen „Trace File Analyzer (TFA) in Oracle Version 12.1.0.2“