iReplay™ Applications & Workflow

Overview

iReplay can be used to assess the impact of possible changes to your database environment, including (but not limited to):

  • Patches or Release Changes to your Database Software (e.g. Sybase ASE 12.5 to 15.x migration, DB2 9.7 to 10.1, Informix 11.x to 12.1, etc)
  • Modifications to database structure, such as schema or index space
  • Patches or Release Changes to your underlying Operating System (e.g., Solaris 8 to Solaris 10)
  • Modifications or config changes to your underlying OS.
  • Complete changes of OS, such as Solaris to Linux
  • Troubleshooting. (Complex problems, such as Database deadlock, timeout issues, can be accurately reproduced, and resolutions validated empirically with iReplay)
  • Other changes, such as underlying hardware, changes to Storage Systems, etc

In every case, the testing process will follow the same overall outline:

  • Capture a lossless record of the original SQL load.
  • Pre-process the captured file to prepare it for accurate replay, while collecting source-side performance metrics.
  • Prepare the Target Database Server to ensure the replicated load will run correctly.
  • Replay the SQL load against a target data server. Collect target-side performance metrics.
  • Analyze. Run reports to view detailed comparisons at the run level, session level, or transaction level

Capturing the Production SQL Load

iReplay starts with a high-integrity capture, using passive network listening, of the production SQL load. While there are several different methods to achieve this result, in each case, the result is a raw record of the SQL traffic, exactly as transmitted on your network. All variations in the manner of transmission, including those that would result from differing client libraries, are preserved intact. Extended runs of hours or even a full day or more can be captured and replicated. Note that the capture files can be large (tens of Gigabytes are common), so allocate disk space accordingly. The following capture options are available:

  • Local Capture. The iReplay capture process is an intelligent module that may be installed directly on the production host, with minimal operating impact. Overhead is typically <1% to 3% -- and the process intelligently transfers captured files in small segments, reassembling them at the iReplay server. This eliminates the need to maintain large capture files on the source database host, end minimizes the effort to transfer the capture files to the iReplay Server
  • Capture via Network Tap(Linux Platform). Network taps or optical splitters can be deployed to run the capture process to a separate host, eliminating even the small amount of overhead incurred when running the capture process locally. When network taps are deployed, the capture host is can (network and physical location permitting) be the same host used for pre-processing and replay operations.
  • Capture via Network Tap(Dedicated Capture Appliance). For the highest volume applications, a deep capture and stream-to-storage appliance, may be desirable. Using either a software capture iCapture-ng (from Exact Solutions) or using third party capture devices, a high throughput (10 gig capture) can be accomplished. In this scenario, no changes or software need be added either to the source or target database servers.

Pre-Processing the Captured SQL record.

The pre-processing step allows the iReplay user to define Replay parameters such as target IP Address & Port number, replay compression, Inter Session Sync and Replay start point. Once the parameters are defined, pre-processing creates and updated version of the captured file, that will run against the target machine exactly as if the traffic had originated from the original client libraries. During preprocessing, iReplay also generates a baseline performance record for every SQL statement, which becomes the "before picture" for later use in comparison reporting. Options available during pre-processing include:

  • Set Compression Rate. This option allows the user to adjust to playback rate, by adjusting the interval time between queries. For capacity planning applications, intervals between queries can be reduced in successive runs to identify break points.
  • Select Inter Session Synchronization mode. This parameter indicates whether multiple Client Sessions are inter-dependent. This indicates whether inter session Requests &/or Responses are dependent and need to be ordered. Depending on the test objectives, inter-session sync can be enabled or disabled. For functional testing, iReplay can maintain inter-session dependencies accurately.
  • Select Start Point and End Point for the replay run. Start Points could be configured as Database Backup Point (For e.g. a DB2 online backup) or a Point in Time. iReplay will automatically detect Open Transactions (uncommitted) across the Replay Start Point and have these transactions replayed as well.
  • Session Level Filtering based on Application Names, User Names or Client IP Addresses are also possible.

Preparing the Target Database Server

To ensure a successful test run and valid comparison results, the test or target database will need to be restored to the same state that existed in the source database server at the time the capture began. The test database should also be isolated, as any other activities occurring on the test database during a replicated run may affect the integrity of the results. Your Exact Solutions project manager can discuss other preparations that may be required for your Database Server.

Replay the SQL load

Once the capture record has been processed, and the target database prepared, the Database Replay can be run from the iReplay Server Box. During the replay process, iReplay will also generate a performance record for every SQL transaction, creating the "after" picture for use in comparison reporting, along with a Real Time snapshot of the Replay statistics.

Generate Reports

iReplay can accurately correlate performance data between any source and target SQL request, allowing it to provide detailed a/b comparisons between any two iReplay runs. This can be a baseline comparison between initial source and target runs, or a comparison between subsequent target runs following optimization efforts or other changes. To facilitate detailed reporting, iReplay captures & summarizes a complete set of SQL-level performance measurements, using the same metrics available in iWatch. The reporting allows performance comparisons at the run level, session level, or individual transaction level, with robust filtering options to narrow the results. Trend and summary-level data may also be compared, so users can measure changes such as table utilization, error rates, and more.

 

Next Section : iReplay Analytics & Reporting