Each of the Support Tools’ native commands can be run as they would be if executed in a standalone installation or through the ‘tfactl’ shell (aka TFA Shell). As previously mentioned, TFA Shell simplifies execution of the tools by providing centralized access to each of the tools through a single interface. In this section we will provide instruction on how each of the tools can be executed through TFA Shell.
Note: The scope of this section is to explain and provide examples of the execution of each of the tools via TFA Shell. Documentation of the tools themselves is provided within each of the tools’
respective MOS Notes and/or Users Guides.
Before jumping into each of the tools we must first understand the TFA Shell context. When in the shell it is possible to set a context that can either be a ‘database name’, ‘ASM’, or ‘CRS’. Once a context is set then any commands that understand context such as oratop, tail, grep, vi and
alertsummary will use that context to determine the correct resource target.
The context can be set as follows (example shows setting the context to CRS):
#tfactl
tfactl> database CRS ç sets the context Set db to CRS
The TFA Shell instructions for each of the tools below will indicate if a context is necessary for the tool to execute.
ORAchk and EXAchk
ORAchk and EXAchk execution through TFA Shell is identical to what would be performed outside of TFA Shell. As usual, ORAchk is intended for use on non-engineered systems and EXAchk is intended for use on engineered systems. This includes all functionality of ORAchk including passing of arguments to ORAchk as well as running the ORAchk daemon. To execute ORAchk from TFA Shell perform the following:
#tfactl
tfactl> orachk
For advanced usage of ORAchk please see the ORAchk users guide which can be found in Doc ID:
1268927.1. Note that no context is required for running ORAchk and EXAchk.
Output for ORAchk and EXAchk will be redirected to their respective directory in the TFA repository
$ORACLE_BASE/tfa/repository/suptools/<node name>/orachk/<user name> or
$ORACLE_BASE/tfa/repository/suptools/<node name>/exachk/<user name>. The user name is controlled by the user who is running ORAchk from within TFA, typically “oracle” or root. Running tfactl diagcollect will automatically collect this data.
OSWatcher
It is considered a best practice to run OSWatcher proactively at all times on your system in order to provide better first failure diagnostics in case of problems. Therefore OSWatcher is installed and run by default whenever TFA 12.1.2.3.0 or higher is installed.
OSWatcher runs as a daemon on the OS which makes this tool slightly different than the others. You will notice this in the status column of “tfactl toolstatus” where it will either read RUNNING or NOT RUNNING as opposed to DEPLOYED. One of the complexities of OSWatcher since its inception is keeping it up and running at all times (including after a system reboot). Running OSWatcher from TFA allows TFA to control the state and to monitor the status of OSWatcher which will ensure it is always running (unless explicitly stopped by an administrator) when TFA is running (again, TFA runs out of init so it should always be running).
Note: If OSWatcher is already running on the system where TFA 12.1.2.3.0 or above is installed, the existing OSWatcher installation WILL NOT be modified. It is highly
recommended that if you are already running OSWatcher on a system with TFA 12.1.2.3.0 or above that you shutdown the existing OSWatcher daemon and use the version of OSWatcher that is deployed with TFA.
To check the status of OSWatcher as well as the other tools from within TFA perform the following:
#/tfactl
tfactl> toolstatus
To start the OSWatcher daemon perform the following:
#tfactl
tfactl> start oswbb
To stop the OSWatcher daemon perform the following:
#tfactl
tfactl> stop oswbb
TFA Shell also provides easy access into the OSWatcher Analyzer. If you are unfamiliar with
OSWatcher Analyzer, it allows for aggregation, summarization and graphing of OSWatcher data over a given time interval. This is a great feature that will save time when reviewing OSWatcher data. To access the OSWatcher Analyzer in interactive mode execute the following:
#tfactl
tfactl> oswbb
The OSWatcher Analayzer also has numerous command line options to modify execution behavior (including non-interactive execution). These command line options may be passed into OSWatcher Analyser from TFA Shell by providing the desired switches along with the oswbb command, for example “oswbb –NO_NETSTAT” would exclude netstat data from being analyzed. All of the available command line options can be found in Doc ID: 461053.1 If you need additional information on OSWatcher or OSWatcher Analyzer, please refer to Doc ID: 301137.1
OSWatcher output when managed from within the TFA framework will be redirected to
$ORACLE_BASE/tfa/repository/suptools/<node name>/oswbb/<user name>. Running tfactl diagcollect will automatically collect OSWatcher data whether OSWatcher is being managed from within TFA or not.
Procwatcher
Procwatcher is much like OSWatcher in the fact that it runs as a daemon, therefore in the status column of “tfactl toolstatus” where it will either read RUNNING or NOT RUNNING opposed to DEPLOYED. Procwatcher will NOT be RUNNING by default upon deployment of TFA 12.1.2.3.0 or above, it must manually be deployed or started as follows as the Database Software owner (e.g.
oracle):
#tfactl
tfactl> prw deploy
#tfactl
tfactl> prw start
Procwatcher deployment involves registering Procwatcher in the Oracle clusterware if present. Once registered in the Oracle clusterware it is managed by the clusterware in terms of starting, stopping and checking status. Procwatcher is also started on all nodes by default once it has been deployed and is kept running by the clusterware in case of nodes being rebooted or evicted from the cluster. Once Procwatcher has been deployed it can be stopped and started as needed.
To stop procwatcher execute:
#tfactl
tfactl> prw stop
To check the status of Procwatcher from within TFA perform the following:
#tfactl
tfactl> toolstatus
It is a common requirement to modify the Procwatcher parameters to meet the needs for a particular Service Request.
This parameter file location is:
$GI_BASE/tfa/repository/suptools/prw/prwinit.ora when TFA is installed as part of Grid Infrastructure or
$TFA_BASE/repository/suptools/prw/prwinit.ora for other installation types.
Once the file has been modified restart Procwatcher via TFA as shown above to allow the changes take effect.
As with all other tools that have been integrated into TFA Shell, it is possible to pass arguments into a Procwatcher command. For example to see the parameters of Procwatcher from TFA Shell you would execute “prw param” or for help you would execute “prw help”. Additional information on Procwatcher can be found in Doc ID: 459694.1.
Procwatcher output is redirected to $ORACLE_BASE/tfa/repository/suptools/prw/<user name>.
oratop
The oratop tool requires a database context to allow the tool to connect to the desired database. To launch oratop in interactive mode execute:
#tfactl
tfactl> database RDB11204 or db RDB11204 RDB11204 tfactl> oratop
To launch oratop in non-interactive mode for 10 iterations (default 5 second interval), execute:
#tfactl
tfactl> database RDB11204 RDB11204 tfactl> oratop –bn 10
When running oratop in non-interactive mode the output is redirected to :-
$GI_BASE/tfa/repository/suptools/<node name>/oratop/<user name>
when TFA is installed as part of Grid Infrastructure or
$TFA_BASE/ repository/suptools/<node name>/oratop/<user name>
for other installation types.
For additional oratop information and command line options please see the oratop Users Guide which can be found in Doc ID: 1500864.1.
SQLT
SQLT may be deployed and executed via TFA Shell. Given the nature of the utility, it does require a database context to be set within TFA Shell. To install SQLT via TFA Shell, simply execute the following as the Databsae software owner (e.g. oracle):
#tfactl
tfactl> database RDB11204 or db RDB11204 RDB11204 tfactl> sqlt install
Once SQLT has been deployed, you can identify TOP SQLs to run through SQLT by executing:
#tfactl
tfactl> database RDB11204 RDB11204 tfactl> sqlt getid
And finally you can run a given SQL through SQLT using one of the methods documented in Doc ID: 215187.1 as follows (example below uses the xtract method):
#tfactl
tfactl> database RDB11204
RDB11204 tfactl> sqlt xtract <SQL ID>|<Hash Value>
DARDA
The Diagnostic Assistant (DA) tool can be invoked from TFA Shell by executing:
#tfactl
tfactl> darda
Remote Diagnostic Agent (RDA) is invoked from a DA menu. For use cases and options for
DARDA, please see Doc ID: 210804.1. All the standard functionality of DA and RDA are available when run via TFA shell.
DBGLEVEL
The dbglevel tool can be used to set up a tracing profile that sets ytrace levels for multiple modules in one command. This tool should be used at the request of Oracle Support.
alertsummary, ls, pstack, grep, summary, vi, tail, param, changes, ps and grep
The above tools are all very much similar in nature as they all provide interfaces to summarize and view diagnostic files, and data for ease of navigation. The advantage of using these tools as opposed to standard OS utilities is the fact that TFA knows exactly where a given file resides or process is running which allows for users to perform analysis without having to navigate through the
filesystem(s) to do so. For execution of these tools (with perhaps alertsummary being the exception) it is generally recommended that the TFA Shell context is set to a ‘database’, ‘ASM’, or ‘CRS’, otherwise the utility will operate on ALL available contexts.
To summarize ALL alert logs on a given system, you can use the alertsummary utility without a context being set:
#tfactl
tfactl> database ç clears any database context tfactl> alertsummary
To limit the scope of the summary to a given database, set the context to that database:
#tfactl
tfactl> database RDB11204 ç sets a database context RDB11204 tfactl> alertsummary
For the vi, tail, ls and grep tools, if a context is NOT set the tool executes on all files. For example if a user wanted to review the LMD trace file for ALL database instances and ASM, one would execute:
#tfactl
tfactl> database tfactl> vi lmd
One can limit the scope by providing the exact filename (if known) or by setting the context to the database, ASM or CRS.
For the pstack tool if a context is NOT set the tool executes for all processes matching the specified pattern. For example if a user wanted to see pstack of all lmd0 processes for ALL database instances and ASM, from all nodes one would execute:
#tfactl
tfactl> database tfactl> pstack
Again one can limit the scope by providing the exact filename (if known) or by setting the context to the database, ASM or CRS.
The changes, param and ps tools currently do not support context setting.
Help is provided for each of the tools by specifying <tool> -h within TFA Shell.