Search Results import_awr




Overview
Explore in AI Chat

Overview

DBMS_WORKLOAD_CAPTURE is a SYS-owned Oracle Database Real Application Testing (RAT) package that records the complete workload directed at an Oracle Database instance so that it can later be replayed and analyzed. Within an Oracle E-Business Suite 12.1.1 or 12.2.2 deployment, this package provides the capture half of the database replay methodology that EBS DBAs use to validate upgrades, consolidation, patching, and instance migrations against a faithful reproduction of production activity. The package captures all user requests issued to the database after START_CAPTURE is invoked, storing the recorded calls in a specified directory on the database server. Any user request subsequently processed by a successful capture is written to disk, and workload filters may be applied so that only a subset of activity is recorded. Background process activity, including work from SMON, PMON, MMON, and jobs scheduled through DBMS_SCHEDULER or DBMS_JOB, is never captured regardless of how filters are defined, because those activities are expected to occur automatically on an appropriately configured replay system. The counterpart replay package, DBMS_WORKLOAD_REPLAY, consumes the capture produced here.

Key Procedures and Functions

The package exposes sixteen documented procedures and functions organized around the capture lifecycle:

  • START_CAPTURE — Initiates a database-wide workload capture into a named directory, optionally for a specified duration. If no duration is supplied the capture continues until FINISH_CAPTURE is executed. By default, instances started with STARTUP RESTRICT are unrestricted upon a successful start; the auto_unrestrict parameter can suppress that behavior.
  • FINISH_CAPTURE — Terminates an in-progress capture, ensuring no new workload is recorded.
  • GET_CAPTURE_INFO — Returns metadata about a completed or in-progress capture.
  • DELETE_CAPTURE_INFO — Removes capture metadata from the repository.
  • REPORT — Generates a report describing capture results and characteristics.
  • ADD_FILTER / DELETE_FILTER — Define and remove workload filters that restrict which user requests are captured. With no filters defined, all user requests are captured.
  • EXPORT_AWR / IMPORT_AWR — Move AWR data associated with a capture to or from the staging area.
  • EXPORT_PERFORMANCE_DATA / IMPORT_PERFORMANCE_DATA — Move captured performance data across the database boundary.
  • EXPORT_UC_GRAPH / IMPORT_UC_GRAPH / USER_CALLS_GRAPH — Produce and transfer user-call graphs summarizing the captured workload.
  • GET_CAPTURE_PATH — Returns the operating system path of the capture directory.
  • GET_PERF_DATA_EXPORT_STATUS — Reports the status of a performance data export.

Tables Accessed

The documented ETRM metadata lists only XMLAGG as a referenced object accessible through APPS synonyms. XMLAGG is an aggregate function used in the internal SQL that assembles report and performance data output, rather than an application table. The substantive capture repository tables reside in the SYS schema and are maintained internally by the package; custom EBS code should not query them directly.

Usage Notes

DBMS_WORKLOAD_CAPTURE is invoked directly from SQL*Plus or a database session by the DBA, not from an EBS form or concurrent program. It is executed at the database tier before an upgrade, platform migration, or major configuration change, followed by replay of the resulting capture on the target system. The user search term "IMPRASTUION AWR" indicates interest in the IMPORT_AWR procedure, which imports AWR data tied to a capture so that performance baselines travel with the workload. Executing capture during scheduled EBS downtime deserves care: to obtain a well-defined replay starting point, no sessions with in-flight transactions should exist when START_CAPTURE runs, since such transactions will not replay correctly. Three other packages reference DBMS_WORKLOAD_CAPTURE, confirming its role as a shared infrastructure dependency.