Configuring Oracle Auto Service Request (ASR) on Oracle Exadata: A Complete Walkthrough

Oracle Auto Service Request (ASR) is the built-in mechanism that turns Exadata hardware and software faults into automatically opened Service Requests (SRs) with Oracle Support, no phone calls, no manual ticket creation. When a disk fails at 3 AM, ASR detects it, files the SR, attaches telemetry, and can even initiate parts dispatch.

In this post, I’ll walk through the complete ASR configuration for an Exadata rack, step by step: installing the ASR Manager, registering it, wiring every database server and storage server to send SNMP traps, activating the assets, and validating the end-to-end flow.

The Big Picture: How ASR Works on Exadata

Every Exadata component database servers, storage servers (cells), and their ILOM service processors generates SNMP traps when faults occur. These traps are sent to a single, centralized ASR Manager server, which acts as the alarm dispatcher for the entire rack. The ASR Manager validates each trap against its registered assets and automatically opens an SR in My Oracle Support, complete with diagnostic telemetry.

Fault occurs (disk / PSU / fan / software event)
        |
        v
Server or ILOM generates SNMP trap ----(UDP 162)----> ASR Manager
        |                                                  |
        |                                    Matches trap to a registered asset
        v                                                  v
  (local alerting)                    SR auto-created in MOS + telemetry attached
                                      + optional email notification

Important: ASR is reactive, not a monitoring solution. It won’t replace Enterprise Manager or SNMP-based alerting it simply ensures faults become support tickets automatically.

Part 1: Install and Register the ASR Manager

The ASR Manager is typically a dedicated server, though in smaller environments one compute node can host it. Note that Exadata supports only one active ASR Manager per rack.

Step 1 Install the components

• Service Tools Bundle (STB) required only if the ASR Manager server runs Solaris 10. On Linux-based systems this step is not applicable.
• Oracle ASR package the core asr software, downloaded from My Oracle Support (the ASR download bundle is referenced in Doc ID 1185493.1).

Step 2 Register with Oracle Support

As root on the ASR Manager server (registration requires root to securely store credentials):

# asr register

The interactive wizard prompts you for My Oracle Support credentials and, if required, proxy details. It also lets you choose the activation mode internet connectivity versus disconnected/relay mode.

Step 3 Verify registration and connectivity

# asr show_reg_status
# asr test_connection

show_reg_status confirms the manager is registered against your MOS account (a valid Customer Support Identifier is required). test_connection validates the outbound HTTPS path to Oracle’s servers catching firewall and proxy issues before a real fault occurs. This is a very common cause of “ASR never opens SRs” in production, so don’t skip it.

Part 2: Configure SNMP Trap Destinations on Every Server

Each Exadata database server and storage server must be told to deliver SNMP traps to the ASR Manager.

Database servers (as root, via DBMCLI)

DBMCLI> alter dbserver snmpsubscriber =
         ((host='<ASR Manager>', port=162, community=public, type=ASR, fromip=<eth0 IP>))

Storage servers (as root or celladmin, via CellCLI)

CellCLI> alter cell snmpsubscriber =
         ((host='<ASR Manager>', port=162, community=public, type=ASR))

Key points:

• <ASR Manager> = the ASR Manager hostname or IP address.
• Traps are sent to UDP port 162, and type=ASR tags these subscriptions specifically for auto-SR generation keeping them separate from any general-purpose SNMP monitoring.
• The fromip=<eth0 IP> argument on database servers is required only with Exadata Storage Server version 11.2.2.4.0 or later. On earlier versions, use the same command but omit fromip. It forces the trap’s source IP so the ASR Manager can correctly identify which asset generated it critical on multi-homed or bonded servers.

Preserve existing SNMP registrations

The commands above use =, which overwrites the entire snmpsubscriber attribute. If the server already has SNMP subscribers (Enterprise Manager, a monitoring tool), you will silently wipe them out. Capture the current value first:

CellCLI> list cell attributes snmpsubscriber

Then either include the existing entries in the full list, or use the additive form:

CellCLI> alter cell snmpsubscriber += ((host='<ASR Manager>', port=162, community=public, type=ASR))

Scale it with dcli

This configuration must be applied to every database and storage server. Rather than logging in one by one, use the dcli utility to configure all storage servers listed in a cell_group file simultaneously:

# dcli -g cell_group -l celladmin -n "cellcli -e \
  alter cell snmpsubscriber=((host=<ASR Manager>, \
  port=162, community=public, type=ASR))"

Verify the subscribers

DBMCLI> list dbserver attributes snmpsubscriber
CellCLI> list cell attributes snmpsubscriber

Confirm the ASR Manager entry is present and that no previous subscribers were lost.

Part 3: Activate the ASR Assets

All commands in this section run as root on the ASR Manager server.

1. Activate the ASR Manager host (one-time operation)

# asr activate_asset -i <ASR Manager IP>

This registers the manager server’s own hardware with Oracle, so faults on the manager itself also generate SRs. You only do this once.

2. Activate each server ILOM

# asr activate_asset -i <Asset ILOM IP>

Every database server and storage server has an ILOM (Integrated Lights Out Manager) service processor that reports hardware faults PSU, fan, DIMM, temperature. Run this once per ILOM, substituting the ILOM interface IP address.

3. Activate each database server and storage server

# asr activate_exadata -i <Asset IP> -h <Asset hostname> -l <Asset ILOM IP>

Run this once per server, where:

• <Asset IP> = the database/storage server management network IP
• <Asset hostname> = the server hostname
• <Asset ILOM IP> = the server’s ILOM IP

4. Verify visibility

# asr list_asset

Every server, cell, and ILOM you activated should appear. Anything missing means activation failed or the wrong identifier was used.

5. Approve the assets in My Oracle Support

Activation via the commands above puts the assets into a Pending ASR Activation state. To complete the process, an administrator must approve them in My Oracle Support following MOS Note 1329200.1. This is where Oracle verifies your support entitlement only assets covered by a valid support contract will fully activate. This step is mandatory; without it, ASR silently won’t open SRs.

Part 4: Validate the Configuration

With assets activated, the ASR configuration is complete. Now prove it works test during implementation, not during a real outage.

DBMCLI> alter dbserver validate snmp type=ASR
CellCLI> alter cell validate snmp type=ASR

Each validation command triggers a full end-to-end test: the server sends a test SNMP trap to the ASR Manager, which forwards a validation request to Oracle Support. Two things confirm success:

1. An email is sent indicating that the ASR service inside Oracle Support received the validation request.
2. No Service Request is opened for validation requests this is purely a health check.

You can also check receipt on the ASR Manager side:

# asr list_asset_events

Troubleshooting Tips From the Field

• Test one cell first, validate it end-to-end, then roll out to the rest of the rack don’t configure 18 servers blindly.
• Most common failures: (1) SNMP community mismatch, (2) firewall blocking UDP 162 outbound from servers to the ASR Manager, (3) forgetting the MOS pending-activation approval, (4) fromip incorrect on multi-homed database servers.
• Outbound only: ASR needs outbound HTTPS (port 443) from the ASR Manager to Oracle; no inbound firewall rules are required.
• Changing the ASR Manager host later? You must update the snmpsubscriber on every database and storage server.

Summary

Once validation emails arrive, your Exadata rack is protected: the next failed disk or PSU will generate its own Service Request while you sleep.

Questions or war stories about ASR in your environment? Drop them in the comments.