Real Application Testing: Database Capture FAQ (Doc ID 1920275.1)
In this Document
Purpose
Questions and Answers
How is the Capture feature implemented?
What is the expected Capture overhead?
How can I calculated the space required for database capture?
What is the best duration for a capture?
What kind of storage is recommended for capture directory?
Should I do a capture when the IO is slow or database has a performance problem?
What happens to database capture when capture directory is full in the middle of the capture? Will it impact the application?
Is ACFS file system supported for database capture?
Can I capture on ASM File system?
Do we capture workload from dbms_jobs or scheduler job?
Can I capture on Data Guard or standby database?
Do I need to restart the database to start the capture?
Where are the capture files written to?
Do database capture any passwords?
Is database capture RAC aware?
Is a shared file system required to perform database capture on a RAC system?
Are idle sessions captured when DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE is performed?
What capture side patches are available?
Does the Capture functionality support XML Types?
Can the Capture Directory be Specified on ACFS?
Can the Replay Directory be on ASM?
Can an ACFS Directory be specified as the Replay Directory?
References
APPLIES TO:
Oracle Database Cloud Exadata Service - Version N/A and later Oracle Database Cloud Service - Version N/A and later Oracle Database - Enterprise Edition - Version 9.2.0.8 and later Oracle Database Cloud Schema Service - Version N/A and later Oracle Database Backup Service - Version N/A and later Information in this document applies to any platform. Real Application Testing Database Capture
PURPOSE
The purpose of this FAQ is to provide answers to commonly asked questions. Many of the answers are based upon real world customer experience.
The first step in using Database Replay is to capture a production workload. Capturing a workload involves recording all requests made by external clients to the Oracle Database.
When workload capture is enabled, all external client requests directed to Oracle Database are tracked and stored on the file system in binary files called capture files. The location where the capture files will be stored can be specified. Once workload capture begins, all external database calls are written to the capture files. The capture files contain all relevant information about the client request, such as SQL text, bind values, and transaction information. Background activities and database scheduler jobs are not captured. The capture files are platform independent and can be transported to another system for replay.
QUESTIONS AND ANSWERS
How is the Capture feature implemented?
The Capture feature is implemented as a light weight trace on the user process and writes session specific information to a single .rec file per session using buffered writes.
How can I calculated the space required for database capture?
Space required for capture can be approximated using:
2 * Bytes received via SQL*Net from client (from AWR).
The AWR report tracks the total in-coming network traffic under “bytes received via SQL*Net from client". By using an AWR report covering the period of a similar workload that ran before, you can get a good estimate for the on-going workload capture. For example: suppose we are planning a workload capture from 9am to 11am this Friday, the AWR report for last Friday of the same duration might give us a good estimate.
In the example below the space required can be calculated as 2*367,991,283 = 735,982,566 bytes
Another way to estimate the space is to perform a capture of a small proportion of the workload (e.g. 10 min) and extrapolate that estimate based upon the captured size. For examples of space usage, see the attached database capture document.
What is the best duration for a capture?
No one size fits everybody. In very general and broad terms, the smaller the capture, the easier it is to perform replay. Large captures take relatively more time to perform both the replay (and the analysis of it) and will require more resources. Generally you should target one or more of the following for a capture: a peak workload / one complete business cycle / some workload of interest. Only capture the workload of interest, one should exclude all internal users like sys, system, XDB etc. and unwanted users (like DBSNMP) from the capture as well as any monitoring tools. You can use Database capture filters to exclude or include the information you want. Technically, Database Capture imposes no limitations in terms of the capture duration.
Should I do a capture when the IO is slow or database has a performance problem?
No. You must not perform a capture if the Oracle database is already starved for CPU or processes are waiting quite a bit on run queue for CPU. Performance issues should be resolved before capturing otherwise the capture overhead may trigger further degradation for the live users and may also result in poor capture/replay comparison data.
Do we capture workload from dbms_jobs or scheduler job?
Database Capture does not capture workload from dbms_jobs or scheduler jobs. They are excluded from capture. The assumption is that in the test database where the replay is done, these jobs will be already setup.
Do I need to restart the database to start the capture?
In general, the answer is no, one does not need to restart the database to do a capture. In the real world however, most production environments will not allow you to restart the database simply for this purpose. You can still get an adequate capture and replay without restarting.
If the database is not restarted before the capture begins, transactions that are in progress, or have yet to be committed, will not be fully captured in the workload. Ongoing transactions will thus not be replayed properly since only the part of the transaction whose calls were captured will be replayed resulting in undesired data divergence when the workload is replayed. Any subsequent transactions with dependencies on the incomplete transactions may also generate errors during replay. You need to keep this in mind when preforming replay analysis.
TIP: For batch jobs ensure that capture is started before the batch job starts and ended after the batch job ends to ensure that the complete batch job is captured. For OLTP workloads, capture can be started any time since transactions tend to be short in duration and thus are less affected by such issues.
Is a shared file system required to perform database capture on a RAC system?
No, for the purpose of database capture a shared file system is not mandatory but recommended.
If you do not have a shared file system, as an alternative, you can set up capture directory paths that resolve to separate physical directories on each instance. In this case, remember that prior to preprocessing the workload capture you will need to collate the captured files created in each of these directories into a single directory.
