Let’s Talk Database Replay- Part I

Database Replay is a feature in EM12c that a lot of folks are unfamiliar with, but once they learn about it, well, now then they figure out how valuable it really is.  Where the ADDM Comparison Report comes in really handy when you want to see what changed, think about how much more value there is if you could test out what a change in parameters, patches, or in code would do to a database and THEN use the ADDM Comparision Report to view the “What if’s”?  This is where Database Replay really enhances the comparison report feature.

along with the ADDM Comparison, you also have the ability to replay with ASH Analytics, SQL Analyzer and Replay’s own Comparison Report.

Now you can generate the workload capture reports via the DBMS_WORKLOAD_CAPTURE.GET_CAPTURE_INFO package, but as this is EM12c Goth Girl’s blog you’re visiting, so we’re going to discuss using Enterprise Manager 12c to produce and execute the Database Replay.

Accessing Database Replay in EM12c

Database Replay is under the Performance drop down once you log into a target database.

Once you enter the wizard, you see the steps that need to be completed to perform a successful database replay:

1. Capture Production Workload
2. Prepare Test Database
3. Prepare for Replay
4. Replay Workload on Test Database

Capture Production Workload

This is broken down into three parts:

You’ll need to click on the icon at the very right to configure the first “configurable” step, Capture Workload.  The first step is to ensure you understand the requirements to export and store the data that will be required to run the replay.

After verifying that you have the disk space and the location to restore to, acknowledge both and click on Next.

Now you can choose what to exclude from your replay.  Keep in mind, the more you exclude, the less space and replay demands will be required.

The default looks like this:

But for our post, I’m going to trim it down…a LOT. 🙂

I’m going to keep the “Do not restart the database…” and then change the filter mode to “Inclusion” and just use the DBSNMP user schema.

This is all I want to capture and click on Next.

I now need to decide what database directory to use for my export and have the option to rename the database replay or use the default naming convention.  For this post, I’m just going to leave it with the default name.

Now it’s time to schedule the workload export.  This is done via the EM Job Service, so the job will show up in Cloud Control’s Job Activity page.

The default for the job is to run immediately, but as you can see in the example for this post, I’ve scheduled it for later, (meaning you can also schedule a replay to be performed after hours, (when users are less likely to be accessing the database.)   You also can set a Capture Duration limit, which means the process will rollback if it exceeds this time.  The default for the credentials used are the Preferred Host Credentials, so try to have these set up vs. creating new ones, an option I’m not crazy about having here in the wizard, but understand why it does exist.

If you don’t have the credentials set up beforehand, you will receive the following error upon proceeding:

Once you do have the credentials set, you’re able to proceed and go to the next step in the wizard.

For Part II, we’ll proceed into the next step of preparing the test database to refresh and receive the workload to replay!

Have a great Thursday and for those folks that I don’t see at RMOUG Training Days 2015 conference next week, the horror you must feel right now! 🙂