Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Concurrency control wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Database model wikipedia , lookup
ContactPoint wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Relational model wikipedia , lookup
(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