Download (Intro) Hello. I am Paul, the virtual instructor for this... Replay e-learning course.

(Intro)
Hello. I am Paul, the virtual instructor for this InfoSphere Optim Query Capture and
Replay e-learning course.
This introductory e-learning course teaches you about InfoSphere Optim Query Capture
and Replay, also called InfoSphere Capture Replay. You will learn how to complete the
basic capture and replay workflow in a DB2 for z/OS environment. This course consists
of three modules:
Module one provides an overview of InfoSphere Capture Replay, its architecture, and the
capture and replay workflow.
Module two focuses on the web console and how to navigate and perform basic housekeeping tasks, such as creating database connections, and setting user privileges to
capture and replay workloads.
Module three walks you through the basic capture and replay workflow in a DB2 for
z/OS query tuning scenario.
The course will take about 45 minutes to complete, and includes two quizzes.
Let’s start with module one.
(Transition to Module 1)
This module will give you an overview of InfoSphere Capture Replay, its architecture,
and the capture and replay process.
(Overview)
InfoSphere Capture Replay provides the capability to capture database workloads in a
production environment and then replay them in a test database environment. This adds
more realistic workload testing to your existing functional, regression and performance
tests.
InfoSphere Capture Replay also provides reports that allow IT teams to accurately
analyze the impact of changes made in the testing environment before these changes are
deployed to the production environment.
Among these changes are:
- Migration to DB2 from another database vendor
- Upgrade of a database or operating system to a new version or fix pack
- Consolidation of database servers
- Database tuning
- Database application update
1
-
Hardware upgrade
(Architecture)
This figure shows a simplified view of the InfoSphere Capture Replay architecture. The
product is made up from the following components:
- S-TAP components that are installed on source and target database servers. All local
and remote database traffic is recorded with minimal overhead. The recorded data
includes SQL statements, order of execution, transaction boundaries, isolation levels, and
performance metrics.
- InfoSphere Capture Replay server component that stores, processes, replays, and
analyzes workloads that have been captured by the S-TAP component.
The capture and replay tasks are done with the InfoSphere Capture Replay web console.
Note that we use the term “source or capture” subsystem to refer to the subsystem on
which the original workload runs. This is typically a subsystem in the production
environment. We also use the term “target or replay” subsystem to refer to the subsystem
on which the captured workload will be replayed. This is typically a subsystem in the
development, test, or pre-production environment.
(Workflow)
InfoSphere Capture Replay provides a simple four-step workflow to help you assess the
impact of changes to your production environment:
First, in the Capture step, you collect a production workload over a specified period of
time.
Second, in the Prepare step, you set up your test environment, create test data, and
transform the captured workload.
Third, in the Replay step, you execute the captured workload in the replay environment to
establish a baseline of key metrics.
Finally, in the Compare and Analyze step, you create a report to compare key metrics in
the replayed workload against the baseline. You can drill into report metrics to analyze
changes and, if necessary, correct a condition or implement changes in the replay
environment, and then replay again.
(Quiz)
You have now completed the InfoSphere Capture Replay overview. Let’s take a short
quiz.
2
In the quiz, click the Submit button to submit your answer, click Next to skip the question
and move to the next one, or click Clear to undo your answer.
After you complete all the questions, the quiz result will be shown. If you don’t pass the
quiz, you can click the Retake Quiz button to take it again. You can also click the Review
Quiz button to see your answers along with the correct answers. Note that after you have
reviewed the quiz, you cannot retake it.
(Transition to module 2)
You have completed module one. Click on it if you want to view it again. Or click
module two to continue with this e-learning course.
(Module 2 – Navigation of Web UI)
In this module you will learn how to:
•
Access and navigate the InfoSphere Capture Replay web console
•
Add connections to your databases
•
Manage capture and replay privileges for your database users
Let’s now go through how to navigate the web console.
During the interactive steps that follow, the data that you enter is not case sensitive unless
indicated. Also, to fill in the required data automatically and move to the next step, click
the forward button in the Play Control bar..
(Going through Sign on UI process)
Let's explore the Task Launcher view.
The Key Capture and Replay Tasks panel provides quick access to the main tasks of the
workload lifecycle.
The Getting Started panel provides shortcuts to common InfoSphere Capture Replay
administrative tasks.
The Learn More panel provides links to useful product specific resources.
(Overview of set up environment)
3
Before we can capture and replay workloads, we need to add database connections that
InfoSphere Capture Replay uses to connect to the capture database and the replay
database.
In this e-learning course, we will follow a scenario to assess the impact of a migration
from DB2 for z/OS version 9 to DB2 for z/OS version 10. In the next exercise we will
use two databases: one is a production subsystem with DB2 for z/OS version 9, and the
other is a test subsystem with DB2 for z/OS version 10.
Let’s walk through the process of adding and testing database connections for these
systems.
(Going through the UI steps to add V9 DB Connection)
You have created the database connection for the DB2 for z/OS version 9 production
subsystem. Now, let’s verify that you know how to create a database connection by
having you create one for the DB2 for z/OS version 10 test database. The information for
the database is provided during the challenge.
There will be no instructions. If you don’t know what to do, hover over the Help Me
button for guidance. Click Next when you are ready to take the challenge.
(Challenge to go through the UI steps to create V10 DB connection)
You just completed creating database connections for your production and test databases.
Let’s close the database tab and move on to the next task - managing privileges.
(Manage Privilege)
InfoSphere Capture Replay needs the database connection to capture and replay
workloads and to validate that the user IDs are authorized to perform capture and replay
task, such as capturing, transforming, replaying, and reporting. Let’s walk through the
process of managing privileges.
(Going through the UI steps of managing privileges)
The Manage Privileges view contains two tabs: Enable and Disable, and Grant and
Revoke.
From these tabs you can manage who has access to the capture and replay
workflow tasks.
Let's open the Grant and Revoke tab.
(Challenge)
User SUDB104 is granted the “Can Capture” privilege. Now, let’s assess your
understanding how to manage privileges by having you grant “Can Replay” privilege to
user SUDB104.
4
There will be no instructions. If you don’t know what to do, hover over the Help Me
button for guidance. Click Next when you are ready to take the challenge.
(Going through the UI steps for managing privileges)
User SUDB104 was granted the “Can Replay” privilege on the replay database.
Note that if you are managing a Capture Replay environment with a large number of
users, it can be easier to grant and revoke privileges using scripts.
This concludes the module two. You have learned how to create and test a database
connection, and grant privileges to user. Let’s close the Manage Privileges tab and move
on to the next module.
(Transition to module 3)
You just completed module two. Click any previous module to start again. Or click
module three to move on.
(Module 3 – Basic Workflow)
In this module you will learn how to use the InfoSphere Capture Replay web console to:
•
Capture a workload on the production subsystem
•
Prepare it for replaying on the test subsystem
•
Replay the workload
•
Create a report to compare and analyze the execution results
The scenario used in this module resembles a simple DB2 migration scenario.
Applications have been deployed in a DB2 for z/OS version 9 production environment.
Your goal is to validate that these applications will run without any problems in a DB2
for z/OS version 10 environment.
First, let’s review the tasks that you will complete. The tasks are divided into two stages:
•
Stage 1: Create a baseline.
This stage consists of the following steps:
o Capture a representative workload in the DB2 for z/OS version 9
production environment
o Prepare to replay the workload in the DB2 for z/OS version 10 test
environment
o Replay the workload to produce a baseline
o Create a report to validate that the replay sufficiently reflects the original
captured workload
5
•
Stage 2: Assess the impact that changes to the database environment have on the
workload.
This stage consists of the following steps:
o Apply query workload tuning recommendations in the DB2 10 test
subsystem
o Replay the workload again on the DB2 10 subsystem
o Create a report that compares the two replayed workloads in the test
environment to determine the impact of the query workload tuning
activities
Let’s move on to the first Capture step of stage 1.
(Step 1 – Capture)
Workloads are captured by the lightweight S-TAP software component. This component
must be installed on each subsystem, or on each member in a data sharing environment.
Each subsystem is used either as source or a target of a capture and replay activity. The
S-TAP component captures inbound subsystem traffic for local and remote applications
that are accessing the subsystem. It then transmits the information to the InfoSphere
Capture Replay server. By default, all executed dynamic and static SQL is captured but
you can filter out traffic that is considered irrelevant for the analysis.
Let’s now walk through the process of capturing a workload.
(Going through the UI steps of capturing workload)
In this example we want to capture SQL traffic that is associated with the user SUDB103
and originated from any application running on the distributed platform. We will set up a
filter that limits the captured data accordingly.
We will choose the Add Filter button to add another filter as an AND condition. Note
that the other Add Filter Group button is used for an OR condition.
You can schedule to start capturing the workload at a later time. In this example, we will
start capturing now for 4 minutes.
(Explanation for capture authentication prompt)
Only authorized users are permitted to perform the capture and replay tasks. In this
example, user SUDB103 is authorized to capture workloads on this DB2 for z/OS version
9 subsystem.
The workload capture process starts.
The Capture Process Status area shows the status and the progress of the workload
capture.
6
In this example, some application workload is already running. Any SQL traffic running
against the production database that meets the filtered criteria is captured.
After 4 minutes, the workload capture completes with 618 SQL statements captured.
We just completed the workload capture step. Let’s close the Capture Details tab and
move on to the prepare step.
(Step 2 – Prepare)
In the second workflow step we prepare the test environment for replaying the workload.
Two major tasks must to be completed:
•
First, the workload needs to be transformed into a replay-ready format. The
transform task in the web console assists with this task.
•
Second, you prepare the replay subsystem so that the workload can be run
successfully. This includes creating database objects and loading data using your
favorite database tool such as Optim Test Data Management. The replay
subsystem should adequately mirror the source subsystem to make it possible to
accurately replay the captured workload..
In this e-learning course, the DB2 for z/OS version 10 target subsystem has already been
prepared; the required database objects have been created, data has been loaded, and
permissions have been granted. We can therefore focus on transforming the workload for
replay.
Let’s walk through the process of transforming workload.
(Going through the UI steps for setting up transform)
To transform the workload, we need to specify a user ID that has the privilege to replay
workloads on the replay DB2 for z/OS version 10 subsystem.
The transform process completes. The resulting replay-ready workload is now ready to be
replayed on the target DB2 for z/OS version 10 subsystem.
Let’s close the transform details tab and move on to the next step, Replay.
(Step 3 – Replay)
When you start the replay process, the transformed workload is processed and replayed
on the target system, matching the original workload’s SQL concurrency and execution
sequence. While the workload is replaying, in and outbound database traffic on the target
subsystem is captured. This captured workload is used later to compare with other
workloads.. Note that during the replay process, no filtering is done, unlike when you
captured the workload in the source system.
The goal of initially replaying the workload on the test database is to produce a baseline
that accurately reflects the characteristics of the captured workload, such as SQL return
7
codes and number of rows retrieved or updated. This baseline helps you understand how
your workload behaves in the replay environment before you make any changes to it
.
Let’s walk through the process of replaying a workload.
(Going through the UI steps to set up replaying)
InfoSphere Capture Replay provides various options to replay your workload with
reduced, increased, or no wait time. In this example, we will use the default option to
replay at the rate of original capture workload.
Two logs let you track the progress of the workload replay:
The replay log lists the replay activities and events as they happen.
The replay capture log lists the details about the workload capture that takes place
simultaneously as the workload is replayed.
The Replay Process Status provides information about the replay progress.
The Replay Workload Success area provides summarized information about any replay
accuracy issues.
The replay completes with 100 percent matched statements.
Let’s close the Replay Details tab and move on to the next step, Compare and Analyze.
(Step 4 - Report)
InfoSphere Capture Replay includes a reporting engine to compare a replayed workload
with the original captured or subsequent replayed workload. The generated reports
provide information about SQL replay accuracy and performance. These are the two
main aspects that typically require attention during the baseline assessment before
making any change to the replay environment.
Let’s walk through the process of generating report to compare and analyze the replayed
workload with the original captured workload.
(Going through the UI steps to set up reporting)
We choose the default option to compare the selected replayed workload with the original
captured workload.
A new Details tab shows the report generation progress and also information about the
two workloads that are being compared, along with the report log.
When the report is completed, the Replay Results and Response Time tabs open.
8
The Replay Results tab shows a summary of the replay accuracy. From here you can
drill down into more granular reports if needed. In this example, the results show that
618 SQL statements were executed and that they all matched perfectly, giving 100
percent accuracy. The report consolidates all the matching SQL statements to a list of 35
unique SQL statements.
No unmatched statements are listed. These would have resulted from different returned
codes or number of rows returned and updated during the SQL execution.
All the SQL statements in the baseline workload ran successfully when we replayed the
workload.
There is no other application running during the workload replay that could cause new
SQL statements reported.
The information shown at the bottom is broken down by transactions. All transactions
replayed successfully, and there is no new transaction..
Let’s look at the Matched SQL replays.
This report shows the execution statistics for all the aggregated SQL statements that
match between the baseline and replayed workload. Each aggregated SQL statement
represents multiple executions of the same statement in the two workloads. Aggregation
of statements might vary based on the grouping options that you can specify.
Note that you can export this SQL list to an XML file that can be used with Optim Query
Workload Tuner for performance tuning.
You can drill down to see the details of each aggregated statement. We will do that later.
Let’s close this tab and look at replay performance in the Response Time tab.
This view displays metrics comparing performance statistics that were captured for each
of the workloads.
The Cumulative Statement Response Time panel shows the time it took to process all
SQL statements in the workload. In this example, the response time for the two
workloads is about the same. Note that it does not include any application think time or
time that is spent in other layers, such as network delay, that contribute to the processing
time.
The SQL Executions Over Time panel shows information about the workload’s SQL
throughput. Since there are no significant differences between the captured and replayed
environments, we can expect the graphs to align fairly closely.
The Rows Returned Over Time panel indicates whether there are significant differences in
data between the two environments. Since the replay database is an identical clone of the
capture database, the two graphs align.
9
The workload level statistics panel quantifies the performance numbers with total
improvement and regression.
•
Response time difference identifies how the change in the time it took to
process the SQL during the replay.
•
The report lists SQL processing that is on average 5% faster or slower
as an improvement or regression. In this example, out of the 35 unique
statements, 17 have improved and 10 have regressed. You can configure
the improvement and regression threshold for your reports.
•
The elapsed time shows how long the workloads ran during capture and
replay.
As the replay accuracy is perfect with similar performance, we can accept this replayed
workload as a valid baseline. Before we move on to the next stage, let’s briefly look at
the regressed SQL statements.
This list shows the regressed statements where the response time is longer in the replay
workload than in the baseline workload.
Let's sort this list by Percentage Total Response Time Change in descending order.
Let’s drill down into the SQL statements with the high regression.
This shows the top-N improved and regressed SQL executions for this particular
aggregated SQL statement. The Statement Text section shows literal values are replaced
with parameter marker in the report. Detailed executions for baseline and replay
workloads are provided.
Let’s drill down to the specific SQL that had the highest regressed response time
percentage.
This shows the exact SQL with the literal values and with detailed execution information.
Information about the application executing the statement is also provided.
Now that we have seen all the details of the regressed SQL, let’s move on to the next
stage.
(Transition)
You have just completed the first stage of the capture replay workflow and produced a
baseline that will be used to compare and analyze the impact of the tuning.
Next, you will perform stage two by going through the prepare, replay, compare and
analyze steps one more time.
10
For the prepare step, as we’ve mentioned, there are two major tasks that need to be
completed:
•
The workload needs to be transformed.
•
The database needs to be prepared for the replay.
We have already transformed the captured workload as part of stage one, and can now reuse it.
For the second task, Optim Query Workload Tuner has been used to identify and apply a
number of tuning recommendations. The replay system has also been reset to undo any
data changes that were made as part of the first workload replay. For the scope of this
learning course, we don’t go over those steps.
Now, with the replay environment configured and the workload ready to be replayed, you
can determine what impact the tuning actions might have on the workload. Let’s walk
through the process of replaying the workload.
(Going through the UI for replay step)
The replay process is running. Let’s close the Replay Details tab and fast forward to see
the results of the completed replay process.
We just completed the replay step of stage two. Next, to assess the accuracy and
performance impact of the tuning, let’s create a new report to compare the previous
baseline workload with the newly replayed workload.
(Going through the UI for report steps)
The report shows a replay accuracy of 100 percent with no unmatched SQL statements
and no new statements. Let’s look at the replay performance.
The report shows that the response time has improved 80 percent, with the same number
of SQL executions and number of rows over time. The elapse time for both the baseline
workload and the replayed workload is the same. Based on these metrics we confirm that
performance has improved significantly as a result of the tuning.
Let’s look at the improved SQL statements.
Similar to what we did for regression, we can sort the summarized SQL list by total
response time change to identify the SQL statements that benefited the most from the
tuning.
We just completed the Compare and Analyze step of stage two.
You have learned the basic capture replay flow using a simple migration and workloadtuning scenario. Let’s take a short quiz.
(Transition to Summary)
11
You just completed module three. You can click any previous module to start again.
Otherwise, let’s summarize what we have learnt
(Summary)
InfoSphere Capture Replay lets you capture production workloads and replay them in
nonproduction environments to reproduce realistic workloads for activities such as
regression testing, stress and performance testing, capacity planning, and for other
diagnostics. You can increase or decrease the speed at which the workloads are replayed
to simulate higher or lower SQL throughput.
The change-impact reports provide accuracy and performance analysis to help IT teams
assess and quickly find potential problems before production deployment and ensure
optimal performance. You can drill-down into SQL statements and transactions. This
type of detailed analysis lets organizations more efficiently manage lifecycle events such
as changes in hardware, workloads, databases, or applications without production impact.
This concludes this InfoSphere Optim Query Capture and Replay e-learning course. For
more information, refer to the link shown here.
Thanks for taking the course.
12