Oracle TFA on Exadata: One Command to Collect Every Log That Matters

Posted on by Ahmed Abdel Fattah

When an Exadata system misbehaves, say a node eviction at 2 a.m. or a storage cell throwing errors, the hard part is usually not the fix. It is collecting the right evidence from many servers before the logs rotate away. Oracle Trace File Analyzer (TFA) is built to solve that problem.

What is TFA?

TFA is Oracle’s diagnostic collection and analysis utility. It runs as a lightweight daemon on each database server and does four main jobs:

  • Monitors the Oracle alert logs and other key logs, and raises notifications when it sees significant problems.
  • Collects logs, traces, and system data from every node, trimmed to a time window around the incident.
  • Packages everything into a single bundle you can attach to a Service Request.
  • Analyzes logs across nodes so you can search for errors and see what happened in order.

Today TFA ships as part of the Oracle Autonomous Health Framework (AHF). AHF also includes ORAchk/EXAchk (health checks), Cluster Health Monitor, and other tools. The command-line entry point is tfactl.

How TFA fits with Exadata

Exadata is a good fit for TFA because one incident can span many layers: database instances, Grid Infrastructure, ASM, the OS, the network fabric, and storage cells.

  • TFA is bundled with Grid Infrastructure and with the Exadata software image, so it is often already running on your database servers.
  • It collects database, Clusterware, and ASM logs, plus OS data, from every database node in one pass.
  • Once the storage cells are configured in TFA, the same command can also pull diagnostics from the cells, so you don’t log into each one separately.
  • It works with EXAchk, so health check results and diagnostic collections live in one framework.

How to install it

Because TFA is usually preinstalled on Exadata, first check what you have:

tfactl status
tfactl version

To install or upgrade to the latest AHF (which includes TFA):

  1. Download the AHF installer from My Oracle Support (Oracle’s AHF note, Doc ID 2550798.1, links the current download).
  2. Unzip it on a database server and run the installer as root:
unzip AHF-LINUX_vXX.XX.XX.zip
./ahf_setup
  1. Accept the prompts. The installer detects Grid Infrastructure and can set up TFA across the cluster.
  2. Verify:
tfactl status
tfactl print config

Options change between releases, so follow the AHF documentation for your version. On Exadata, also follow your standard patching procedure, since Oracle often delivers TFA through its own patches.

Configuring TFA to collect from storage cells

By default, a collection covers the database servers. To include the cells, they must be configured in TFA first. This is done with the tfactl cell command.

Step 1: Check the current state

tfactl cell status

This prints the current status of the storage cells, listing each cell as ONLINE or not. For the detailed configuration, including whether an Oracle wallet is used for cell access: 

tfactl cell config

Step 2: Configure the cells if needed

The configure option is meant for cases where cell collections were not set up at installation, were missed because of an upgrade, or were removed by an earlier deconfigure. 

tfactl cell configure

Run it as root on a database server. It may prompt for access details for the cells, depending on your version. To remove the setup, use tfactl cell deconfigure.

Step 3: Collect from the cells

The cells must be configured in TFA before you can collect from them. Then use the -cellnode option: oracle

bash

# All cells, plus the usual database server collection
tfactl diagcollect -cellnode all
# Specific cells only
tfactl diagcollect -cellnode cel01,cel02
# Limit to a time window to keep the bundle small
tfactl diagcollect -cellnode all -since 2h
# Explicitly skip the cells
tfactl diagcollect -nocell

The -nomaxcells option overrides the limit on how many cells are collected. On larger racks you may need it so that no cells are left out.

Step 4: Use cell-aware SRDCs for specific problems

TFA has targeted collection profiles (SRDCs) that combine database, ASM, Clusterware, and cell data:

bash

tfactl diagcollect -srdc crsasmcell -cellnode all
tfactl diagcollect -srdc dbperf -cellnode all

The crsasmcell profile handles cell-related errors such as CRS-1604, CRS-1606, CRS-1613, CRS-1614, CRS-1615 and CRS-1649.

If cell data is missing from your bundle

  • Confirm tfactl cell status shows every cell ONLINE.
  • Confirm tfactl cell config shows the cells as configured.
  • Check tfactl version and tfactl diagcollect -help, since the options come from recent AHF releases.
  • Make sure your time window actually covers the incident.

Key use cases

1. Collect diagnostics for a Service Request

The most common use. Instead of hunting for logs by hand, gather everything from the last few hours:

tfactl diagcollect -since 4h

You get one compressed bundle ready to upload to Oracle Support.

2. Investigate a node eviction or reboot

Collect Clusterware, OS, and database data around the exact time:

tfactl diagcollect -from "Nov/03/2026 02:00:00" -to "Nov/03/2026 03:00:00"

3. Search logs across all nodes

Look for an error across every node’s alert logs without logging into each one:

tfactl analyze -search "ORA-00600" -last 1d

4. Collect for one component only

When you already know the area, narrow the collection and keep the bundle small:

tfactl diagcollect -database mydb -since 2h
tfactl diagcollect -asm -since 2h

5. Investigate storage or I/O problems across compute and cells

For suspected storage problems, a single bundle can cover both sides:

tfactl diagcollect -cellnode all -since 2h

6. Proactive monitoring and automatic collection

TFA watches for significant events and can collect diagnostics automatically when they happen, which helps with problems that disappear before you can log in. You can also set up email notifications:

bash

tfactl set notificationAddress=dba-team@example.com

7. Health checks with EXAchk

Run and schedule EXAchk through AHF to catch configuration drift, missing best practices, and version mismatches before they cause incidents:

tfactl run exachk

Best practices

  • Run TFA as a standing part of your Exadata monitoring, not just during incidents.
  • Verify cell configuration (tfactl cell status) after installs, upgrades, and cell replacements, since upgrades can leave cell collection unconfigured.
  • Always collect with a tight time window: it keeps bundles small and uploads fast.
  • Keep AHF reasonably current, because newer versions improve collections and analysis.
  • Rehearse a diagcollect -cellnode all during a quiet period so the first time isn’t during an outage.

Wrapping up

TFA turns multi-server, multi-layer log gathering into a single command. On Exadata, where an issue can start in a storage cell and surface in a database, adding cell collection to the mix saves real time during an incident.

Note: command options vary by AHF version, so confirm them with tfactl -help and Oracle’s current AHF documentation before using them in production.

Leave a Reply