11.07.2015 Views

Oracle Database 11 g - Online Public Access Catalog

Oracle Database 11 g - Online Public Access Catalog

Oracle Database 11 g - Online Public Access Catalog

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

44 CHAPTER 1 ■ INSTALLING, UPGRADING, AND MANAGING CHANGE• Mode: By default, a workload replay is performed in synchronization mode. If you thinkthe workload is primarily composed of independent transactions, you must disablesynchronization mode explicitly, because data divergence during the replay under thesecircumstances isn’t something to worry about.• Connection Time Scale: You can use the connect_time_scale parameter to calibrate thetime between the workload capture and the session connect time during the replay. Usethis parameter to adjust the number of concurrent users higher or lower during theworkload replay.• Replay Speed: To correct for longer time for completion of user calls during the workloadreplay, use the think_time_auto_correct parameter. The think_time_auto_correctparameter helps you adjust the concurrency level during the workload replay. To correctfor elapsed time between user calls during the replay, use the think_time_scale parameter.If the replay is progressing slower than the data capture, by default the think timecomponent of the replay will be automatically reduced (think_time_auto_correct is setto true by default).Use the prepare_replay procedure to prepare the workload for the replay on the test system,including setting the replay options discussed earlier, as shown here:SQL> dbms_workload_replay.prepare_replay (replay_name =>'replay1',replay_dir => 'test_dir', synchronization= FALSE);Only the synchronization parameter needs explanation. By setting the synchronizationparameter to the value of false (the default value is true), you’re saying that the commit orderin the workload capture may or may not be preserved during the replay. You can do this in asituation where there are numerous independent transactions that don’t have to follow acertain commit order.Once you’ve completed all the requirements for the workload replay, it’s time to start theworkload relay. Use the start_replay procedure to do this, as shown here. After making sureyou have started at least one wrc replay client, issue the following command to replay the workload:SQL> exec dbms_workload_replay.start_replay();The start_replay procedure doesn’t require any parameters. You can cancel the replayoperation using the cancel_replay procedure, if you want, as shown here:SQL> exec dbms_workload_replay.cancel_replay();.The cancel_replay procedure directs all replay clients (wrc) to stop submitting workloadfrom the captured sessions.At the end of the workload replay, all AWR snapshots that correspond to the replay timeperiod are automatically exported. If the export of the snapshots fails for some reason, you canmanually export them by executing the export_awr procedure. You can then import thesesnapshots into the AWR schema owned by the user sys by executing the import_awr procedure.Analyzing Workload Capture and ReplayOnce you replay the workloads on the test system, you must analyze the data replay by generatinga workload replay report. To measure the data and performance differences between the

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!