I have previously written about TFA, OSWatcher et all for Oracle 12.1. Since then, a lot of things have happened and I had an update for 12.2 on my to-do list for far too long. Experience teaches me that references to support notes and official documentation get out of date rather quickly, so as always, if you find anything that changed please let me know via the comments section and I’ll update the post.
This is going to be a 3 part mini-series to save you having to go over 42 pages of text … In this first part I’m going to have a look at single instance Oracle. In part 2 I’ll have a look at Oracle Restart environments, and finally in part 3 I’ll finish the series by looking at a 12.2 RAC system.
The environment
I am using a small VM to install Oracle 12.2.0.1.0 (initially) on Oracle Linux 7.4 with kernel UEK4. As always, my EE database binaries go into /u01/app/oracle/product/12.2.0.1/dbhome_1.
The installation/testing (and reporting) of my findings are following this approach:
- Install the O/S
- Install Oracle 12.2.0.1.0 EE
- Create an EE database (not shown here)
- Patch binaries and database to 12.2.0.1.180116
- Upgrade TFA to 12.2.1.3.1 as downloaded from My Oracle Support DOC ID 1513912.1
These were the current versions at the time of writing.
Install Oracle 12.2.0.1.0
The first step after the O/S is provisioned is to install the Oracle software, obviously. I have noticed that TFA is part of the Oracle binaries. Towards the end of the installation process, you are prompted to execute root.sh, as normal. On my system, root.sh had the following contents:
1 #!/bin/sh
2 unset WAS_ROOTMACRO_CALL_MADE
3 . /u01/app/oracle/product/12.2.0.1/dbhome_1/install/utl/rootmacro.sh "$@"
4 . /u01/app/oracle/product/12.2.0.1/dbhome_1/install/utl/rootinstall.sh
5 /u01/app/oracle/product/12.2.0.1/dbhome_1/suptools/tfa/release/tfa_home/install/roottfa.sh
6 /u01/app/oracle/product/12.2.0.1/dbhome_1/install/root_schagent.sh
7
8 #
9 # Root Actions related to network
10 #
11 /u01/app/oracle/product/12.2.0.1/dbhome_1/network/install/sqlnet/setowner.sh
12
13 #
14 # Invoke standalone rootadd_rdbms.sh
15 #
16 /u01/app/oracle/product/12.2.0.1/dbhome_1/rdbms/install/rootadd_rdbms.sh
17
18 /u01/app/oracle/product/12.2.0.1/dbhome_1/rdbms/install/rootadd_filemap.sh
After a few variables are set/defined by sourcing in files created during the installation, roottfa.sh is called (see line 5). It allows you to configure TFA to run as a background (daemon) process. I decided to go with that option after consulting chapter 4 in the 12.2 Autonomous Health Framework documentation and reading about the advantages of using TFA as a daemon. This may or may not be the right way to run TFA for you, the documentation is really good and helps you decide. Here is the transcript of my root.sh execution:
[root@server5 ~]# /u01/app/oracle/product/12.2.0.1/dbhome_1/root.sh
Performing root user operation.
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /u01/app/oracle/product/12.2.0.1/dbhome_1
Enter the full pathname of the local bin directory: [/usr/local/bin]:
Copying dbhome to /usr/local/bin ...
Copying oraenv to /usr/local/bin ...
Copying coraenv to /usr/local/bin ...
Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Do you want to setup Oracle Trace File Analyzer (TFA) now ? yes|[no] :
yes
Installing Oracle Trace File Analyzer (TFA).
Log File: /u01/app/oracle/product/12.2.0.1/dbhome_1/install/root_server5_2018-01-22_17-21-41-005116657.log
Finished installing Oracle Trace File Analyzer (TFA)
Once that message is shown, TFA is configured and controlled via a systemd unit file:
[root@server5 ~]# systemctl cat oracle-tfa # /etc/systemd/system/oracle-tfa.service # Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. # # Oracle TFA startup # [Unit] Description=Oracle Trace File Analyzer After=syslog.target [Service] ExecStart=/etc/init.d/init.tfa run >/dev/null 2>&1 </dev/null Type=simple Restart=always [Install] WantedBy=multi-user.target graphical.target
The service is enabled and running.
After the completion of roottfa.sh, TFA resides in $ORACLE_BASE/tfa and its subdirectories. This is documented in the 12.2 Autonomous Health Framework chapter 4.2.3 and has an interesting implication: if you set your environment using oraenv, you might find that you get errors invoking tfactl, such as these on my VM. I have used a “minimum install” for my operating system and quite specifically didn’t add any additional perl modules in my kickstart file. Now, when invoking tfactl after having set my environment using oraenv, I find that there are missing perl modules in my system’s perl installation:
[oracle@server5 ~]$ . oraenv ORACLE_SID = [NCDB] ? NCDB The Oracle base remains unchanged with value /u01/app/oracle [oracle@server5 ~]$ tfactl status Can't locate Digest/MD5.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 . /u01/app/oracle/tfa/server5/tfa_home/bin /u01/app/oracle/tfa/server5/tfa_home/bin/common /u01/app/oracle/tfa/server5/tfa_home/bin/modules /u01/app/oracle/tfa/server5/tfa_home/bin/common/exceptions) at /u01/app/oracle/tfa/server5/tfa_home/bin/common/tfactlshare.pm line 7628. BEGIN failed--compilation aborted at /u01/app/oracle/tfa/server5/tfa_home/bin/common/tfactlshare.pm line 7628. Compilation failed in require at /u01/app/oracle/tfa/server5/tfa_home/bin/tfactl.pl line 223. BEGIN failed--compilation aborted at /u01/app/oracle/tfa/server5/tfa_home/bin/tfactl.pl line 223.
The output has been changed for readability (originally I was missing Data::Dumper as well). After studying the documentation (still section 4.2.3 in the aforementioned document), it turns out to be a user mistake. As I said before, after TFA is configured using roottfa.sh as part of the root.sh script execution, it runs in daemon mode and crucially, is available from $ORACLE_BASE/tfa. I found that location being referred to in /etc/init.d/init.tfa as well. When I simply typed “tfactl” into my terminal window, I invoked a different “tfactl”. There is a lot more to be said about this, and I will try and do so in a different post.
NB: the same section 4.2.3 in the documentation states that even should you not run TFA in daemon mode, you can still make use of “user mode TFA” in $ORACLE_HOME, although there are certain restrictions. I haven’t pursued that route.
Anyway, after switching to the location where TFA is actually installed ($ORACLE_BASE/tfa), all is well. It seems that running roottfa.sh creates a new “Oracle” perl:
[root@server5 ~]# find /u01/app/oracle/tfa -name perl /u01/app/oracle/tfa/server5/tfa_home/perl /u01/app/oracle/tfa/server5/tfa_home/perl/bin/perl
I found Digest::MD5 and Data::Dumper in /u01/app/oracle/tfa/server5/tfa_home/perl/lib/5.22.0/x86_64-linux-thread-multi.
So let’s try and get the status of the current installation from $ORACLE_BASE/tfa:
[oracle@server5 ~]$ /u01/app/oracle/tfa/bin/tfactl status Access Denied: Only TFA Admin can run this command
Nearly there: the perl modules are no longer reported to be missing, the “Oracle” perl installation appears to be used now. But what about this error message? I read in section 4.2.4 “Securing Access to Oracle Trace File Analyzer” (still referring to the Autonomous Health Framework manual) that access to TFA is restricted. However, the RDBMS owner should have been granted access automatically.
Using the commands shown in the manual I checked permissions and it turns out that the oracle user is configured to have access to TFA.
[root@server5 ~]# /u01/app/oracle/tfa/bin/tfactl access lsusers .---------------------------------. | TFA Users in server5 | +-----------+-----------+---------+ | User Name | User Type | Status | +-----------+-----------+---------+ | oracle | USER | Allowed | '-----------+-----------+---------'
In fact, I can query TFA’s status using the “print status” command as oracle (/u01/app/oracle/tfa/bin/tfactl print status). I compared the output of “tfactl -help” between oracle and root, and there are more options available when running as root. This might explain the above error.
What is the status now?
TFA is now set up and working, but using the base release:
[root@server5 ~]# /u01/app/oracle/tfa/bin/tfactl status .------------------------------------------------------------------------------------------------. | Host | Status of TFA | PID | Port | Version | Build ID | Inventory Status | +---------+---------------+-------+-------+------------+----------------------+------------------+ | server5 | RUNNING | 18786 | 41482 | 12.2.1.0.0 | 12210020161122170355 | COMPLETE | '---------+---------------+-------+-------+------------+----------------------+------------------'
It should probably be patched to something more recent. I’ll try that in 2 ways: first by applying the January 2018 RU to see if the version changes. Since the standard deployment doesn’t come with OSWatcher which I’m particularly interested in, I’ll download and apply TFA 12.2.1.3.1 next. As with all patching, I need to make sure that I have working backups which I’m comfortable restoring should anything go badly wrong.
Status after applying the January RU
A combination of opatch/datapatch later, my system is on the latest RU patchlevel:
[oracle@server5 OPatch]$ opatch lspatches 27105253;Database Release Update : 12.2.0.1.180116 (27105253) OPatch succeeded.
However, this did not have an effect on the version of TFA in $ORACLE_BASE:
[root@server5 ~]# systemctl restart oracle-tfa [root@server5 ~]# /u01/app/oracle/tfa/bin/tfactl status .------------------------------------------------------------------------------------------------. | Host | Status of TFA | PID | Port | Version | Build ID | Inventory Status | +---------+---------------+-------+-------+------------+----------------------+------------------+ | server5 | RUNNING | 24042 | 37226 | 12.2.1.0.0 | 12210020161122170355 | COMPLETE | '---------+---------------+-------+-------+------------+----------------------+------------------'
Not quite what I expected after reading the docs: the installation of the latest RU should have updated TFA as well. But maybe I got something wrong on my end. The RU readme did not have any reference to TFA that I could find.
Yet it doesn’t matter: I wanted to have all the great support tools anyway (and they aren’t shipped with “stock TFA”), so it was time to install the latest version from MOS.
Upgrading TFA using 12.2.1.3.1 (MOS)
The patch is quite simple and well documented. If TFA is up and running in daemon mode as in my example, the patching tool will recognise that fact and patch the installation in-place. After a couple of minutes on my VM, I have a new version:
[root@server5 stage]# /u01/app/oracle/tfa/bin/tfactl status .------------------------------------------------------------------------------------------------. | Host | Status of TFA | PID | Port | Version | Build ID | Inventory Status | +---------+---------------+-------+-------+------------+----------------------+------------------+ | server5 | RUNNING | 28105 | 39100 | 12.2.1.3.1 | 12213120171215143839 | COMPLETE | '---------+---------------+-------+-------+------------+----------------------+------------------'
The MOS version comes with lots of useful tools as well:
[oracle@server5 stage]$ /u01/app/oracle/tfa/bin/tfactl toolstatus .------------------------------------------------------------------. | TOOLS STATUS - HOST : server5 | +----------------------+--------------+--------------+-------------+ | Tool Type | Tool | Version | Status | +----------------------+--------------+--------------+-------------+ | Development Tools | orachk | 12.2.0.1.3 | DEPLOYED | | | oratop | 14.1.2 | DEPLOYED | +----------------------+--------------+--------------+-------------+ | Support Tools Bundle | darda | 2.10.0.R6036 | DEPLOYED | | | oswbb | 8.1.2 | RUNNING | | | prw | 12.1.13.11.4 | NOT RUNNING | +----------------------+--------------+--------------+-------------+ | TFA Utilities | alertsummary | 12.2.1.1.0 | DEPLOYED | | | calog | 12.2.0.1.0 | DEPLOYED | | | changes | 12.2.1.1.0 | DEPLOYED | | | dbglevel | 12.2.1.1.0 | DEPLOYED | | | events | 12.2.1.1.0 | DEPLOYED | | | grep | 12.2.1.1.0 | DEPLOYED | | | history | 12.2.1.1.0 | DEPLOYED | | | ls | 12.2.1.1.0 | DEPLOYED | | | managelogs | 12.2.1.1.0 | DEPLOYED | | | menu | 12.2.1.1.0 | DEPLOYED | | | param | 12.2.1.1.0 | DEPLOYED | | | ps | 12.2.1.1.0 | DEPLOYED | | | pstack | 12.2.1.1.0 | DEPLOYED | | | summary | 12.2.1.1.0 | DEPLOYED | | | tail | 12.2.1.1.0 | DEPLOYED | | | triage | 12.2.1.1.0 | DEPLOYED | | | vi | 12.2.1.1.0 | DEPLOYED | '----------------------+--------------+--------------+-------------' Note :- DEPLOYED : Installed and Available - To be configured or run interactively. NOT RUNNING : Configured and Available - Currently turned off interactively. RUNNING : Configured and Available. [oracle@server5 stage]$
Since I care a lot about OSWatcher, I was very pleased to see it running.
[oracle@server5 stage]$ ps -ef | grep -i osw oracle 28344 1 0 10:58 ? 00:00:00 /bin/sh ./OSWatcher.sh 30 48 NONE /u01/app/oracle/tfa/repository/suptools/server5/oswbb/oracle/archive oracle 28934 28344 0 10:58 ? 00:00:00 /bin/sh ./OSWatcherFM.sh 48 /u01/app/oracle/tfa/repository/suptools/server5/oswbb/oracle/archive oracle 30662 27252 0 11:01 pts/4 00:00:00 grep --color=auto -i osw [oracle@server5 stage]$
Kindly refer to the documentation for more information about TFA. It’s quite a collection of tools, and it helps you in so many ways…
Martins Blog 