What’s in It for You

• Preserve your processes: Continue using your existing automation and compliance steps while Exadata Fleet Update manages patching.
• Custom integration points: Insert scripts at deterministic points before and after patch apply.
• Targeted scope: Apply scripts to DB or GI patching, and optionally restrict by major version (12, 19, 23).
• Consistent execution: Ensure scripts run reliably across every node involved in the patch cycle.

How It Works

• Opt-in model: Place a useractions.zip file in /u02/efu/ on the target domU(s).
• Automatic detection: Exadata Fleet Update extracts the zip to /var/opt/oracle/managed/fppua (owned by oracle:oinstall, mode 750) and prevents unsafe concurrent overwrites.
• Execution points: Scripts run sequentially per node/instance at pre-apply and post-apply stages.
• Error handling: Non-zero exit codes fail the job; use exit 0 if you don’t want to block patching.

Key Concepts

• Useractions: Your custom scripts or plugins.
• Action points:
  • DB patching: Pre (before instance restart) and Post (after restart).
  • GI patching: Pre (before CRS prepatch) and Post (after CRS postpatch).
• Target types: db or gi.
• Version scoping: Apply scripts to specific major versions (12, 19, 23).

User Action Input Arguments

To facilitate custom user action script development, Exadata Fleet Update passes the following input arguments to user action scripts. These arguments can be used by the scripts to perform the required actions.

Enabling User Actions

1. Prepare zip: Create /u02/efu/useractions.zip, owned by oracle:oinstall (750).
2. Structure scripts:
   • Place under db/ or gi/ directories.
   • Follow naming convention:

     db/fppua1_pre_apply.sh
     db/fppua1_post_apply.sh
     db/19/fppua1_pre_apply.sh
     gi/fppua2_post_apply.sh

   • Use numeric prefix (nn) for ordering.

Execution Behavior

• Ordering: fppua1_* → fppua2_* → fppua3_* …
• Timeout: 30 minutes per script.
• User contexts:
  • DB scripts run as DB owner (oracle).
  • GI scripts run as CRS user.
• Arguments passed: Environment variables such as RHP_PHASE (PRE/POST), RHP_DBNAME, RHP_VERSION, RHP_EXEC_NODE, and others are provided to your scripts.

Best Practices

• Make scripts idempotent and safe for retries.
• Validate environment variables before execution.
• Log clearly with timestamps, node, and DB identifiers.
• Use exit 0 for non-blocking conditions.
• Keep operations lightweight (under 30 minutes).
• Avoid interactive prompts or external dependencies.
• Test in non-production environments before rollout.

Troubleshooting

• PRGH-1024: Script returned non-zero; fix script or ensure exit 0.
• PRCZ-4001/2103: Command failed to execute as oracle; check ownership/permissions.
• PRGT-496: Useractions ignored due to incorrect permissions.
• No execution: Verify feature flag, zip ownership, size (<10 MB), and structure.
• Timeouts: Split or optimize long-running scripts.

Security and Compliance

• Scripts run with the same privileges as DB (oracle) or GI (CRS user) owners.
• Strict permissions (oracle:oinstall 750) are enforced; misconfigured zips are ignored.
• No new identities or privileged escalations are introduced.
• Review script output for sensitive information before allowing it into job logs.

Summary

Exadata Fleet Update user actions provide a controlled and secure extension mechanism for DB and GI patching on ExaDB-D and ExaDB-C@C. With a lightweight, zip-based approach and strict permission controls, you can seamlessly integrate environment-specific operations into automated, rolling patch cycles without sacrificing compliance, security, or operational standards.