InfoSphere® Guardium® Hands-On I Security Policy and Reporting InfoSphere Guardium & Optim Technology Ecosystem Contents Table of Contents 1.PREREQUISITES............................................................................................................ 3 2.SQL AUDITING – INTRODUCTION................................................................................3 2.1Scenario Overview.....................................................................................................3 2.2Scenario Objectives....................................................................................................4 3.CREATING AND INSTALLING THE POLICY.................................................................5 3.1Creating a Security Policy...........................................................................................6 3.1.1Defining the Sensitive Tables Rule.....................................................................9 3.1.2Defining the Test Database Rule......................................................................15 3.1.3Reviewing the Policy Settings...........................................................................18 3.2Installing the Policy...................................................................................................19 3.3Reporting on SQL Constructs...................................................................................20 3.3.1Building the Query and the Report....................................................................20 3.3.2Viewing the Report............................................................................................27 3.4Reporting on SQL with Values..................................................................................32 3.5Creating the Base Query and Tabular Report...........................................................36 4.APPENDIX A: POLICY RULE ACTIONS FOR AUDITING...........................................42 5.APPENDIX B: SAMPLE SQL SCRIPT.........................................................................43 2 1. Prerequisites IMPORTANT This lab requires the completion of the Setup Guardium Using VMware Workstation guide to establish Guardium VM connectivity. 2. SQL Auditing – Introduction Database auditing means monitoring and recording all the SQL statements, configuration changes, and other transactions run against the data server for reference later on. Auditing the data server is often a compliance requirement and is also a best practice to help keep the data server secure. Without data server auditing, it would be nearly impossible to confirm who is performing what functions on a data server. Guardium has an extensive set of functions to help with data server auditing. These functions can help organizations comply with legal mandates, and can also help keep the data well governed and secure. This lab concerns auditing the SQL statements run against the database. Further labs will explain and demonstrate the other auditing functions. 2.1 Scenario Overview A DVD store has recently been made aware that in order to comply with regulatory requirements, and ensure that the data in the database is being used appropriately, they need to implement an auditing system for their data servers. You have been charged with using Guardium to implement this system. There are three databases you are concerned with. The first is a DB2 database named orders that is the production system. The second is a mirror of the first, an Oracle XE database. The third database is a DB2 database named test used for application testing purposes. After consulting with the appropriate subject matter expert and with the customer's help, you define the following requirements: 1. Sensitive tables should be audited at the level of parameter values. Sensitive tables are tables that have columns that involve credit card numbers or other sensitive personal information (eg: Social Security Numbers). For our scenario, the only table with sensitive information is the GUARD.CUSTOMERS table 2. Ignore all SQL run against the test database. The test database is a DB2 database named TEST. We do not need to audit this data because the confidential information located inside it has been masked (ie: deidentified or anonymized) 3. SQL construct should be logged for all other database activity. 3 As you can see, we will not be logging the complete value information for all the objects in the environment. By only logging the data we need, it reduces the performance and storage requirements for the Guardium collector. It is a general best practice that you only audit the information you need to audit, and no more, in order to help keep the system healthy and keep total cost of ownership low. 2.2 Scenario Objectives Objective: To fulfil the SQL auditing requirements listed in Section 2.1 using Guardium SQL statement auditing involves the following basic functions: 1. Using Policies to specify what should be recorded by the Guardium Collector 2. Installing those policies 3. Using Queries to access the data that has been recorded by the appliance 4. Using Reports to define how the data in a query is displayed 5. Placing those reports on a Portlet page for ease of access During this lab you will be performing all these tasks in order to fulfil the requirements. 4 3. Creating and Installing the Policy This section outlines the steps necessary for creating and installing the security policies. Policies are one of the most important components in Guardium. With policies, you can adjust what kind of information is recorded in the Guardium Collector. Policies also allow you to create an additional layer of security using termination and alerting functions. Later presentations and labs will deal specifically with those other functions. This lab concentrates on how policies relate to auditing. Our requirements specify a need to capture differing levels of auditing information depending on what information is being accessed. In Guardium, this translates into setting up a rule for each type of information and selecting an appropriate action for the level of logging desired. Security policies contain rules which specify a grouping of statements and then an action to take. A complete listing of actions can be found in Appendix A. The table below summarizes how our requirements map to those actions. Object Group Business Requirement Rule Action Sensitive Objects (GUARD.CUSTOMERS) Log full SQL statement Log Full Details Test Database (TEST) Do not log Ignore S-TAP Session Others Log only SQL construct Default logging behavior for security policies that do not use selective audit trail. 5 3.1 Creating a Security Policy Policies are just sets of rules. The rules are what determine archiving behaviour. Log in and create a security policy. 1. At the bottom left corner of the “Dataserver” virtual machine, click Computer, then click Firefox. 2. The Firefox homepage is the Guardium GUI, so you should be directed there automatically. If you get a Security Error message, click OK. 6 3. Enter the username: poc and the password: guardium. Click Login 4. Select the Protect tab and then click on Create a new Policy with no Baseline. Baselines are a used to build policies based on previously observed traffic to help identify unusual situations. 7 5. For the new policy enter the information specified below. Policy Description – BC Auditing Reports This is a long form name of the auditing policy Policy Category – CC Data Auditing Categories are just useful organizational mechanisms to help you keep track of the objects you create in Guardium. They do not affect the behaviour of the policy Selective Audit Trail – Not Checked This setting means we will be logging everything unless we specify rules that doesn't log certain database activities. We will ignore the “Flat” options as they are special options used only if you would like to log the audit data to flat files instead of the Guardium relational database. We will also ignore the Audit Pattern field which can also be used to limit what audit data is logged when Selective Audit Trail is selected. Rules can be used to override the default logging behavior, whether it is selective audit trail, which does not log anything by default and requires rules to be defined for any logging to take place, or non-selective audit trail, which by default logs the SQL construct even if a rule is not defined. We will be creating a non-selective audit trail and defining rule to increse the logging level when sensitive object is accessed, and also defining rule to ignore the database session and not log any acticity if it is a session with the test database: 6. Click Apply 7. Click OK at the dialogue that informs you that the policy has been saved. 8 8. Now that we have our policy, we need to define it's behaviour. That is done with rules. Click Edit Rules.... 3.1.1 Defining the Sensitive Tables Rule In this section we will create the rule that fulfills the following requirement: • Sensitive Tables: Log full SQL including parameter values There are three kinds of rules you can add: ▪ ▪ ▪ Access Rules apply to the SQL statements run against the database. Exception Rules apply to SQL errors that are returned by the database such as a failed login attempts. Extrusion Rules apply to data being returned by the database to a client. For our requirements, we only need to define Access Rules. 9 1. Start by clicking Add Access Rule... 10 2. This rule will be designed to fulfil the requirement of auditing the SQL with values for sensitive objects. In the Access Rule Definition page that appears, leave everything blank except for the Rule # 1 Description field. For this field enter Sensitive Objects - Log With Values. We are concerned with tables that have sensitive information contained inside them. As such, let's create a group of those objects. Click on the Group Button ( ) next to the Object field. 11 3. In the popup window, enter the following under the Create New Group section. Group Description – Tables with Sensitive Objects This is the name of the group Group Type Description – OBJECTS This is the type of group. This is important because it defines where the group can be selected from. We choose OBJECTS here because that is the field we were concerned with in the Policy window Group Sub Type Description – TABLES This is an optional field to help you organize your groups. Because the type or object we are listing is tables, it makes sense to put this name here Category – CC Data Auditing This again is an optional field. To help organize things, we give it the same category as we did for our policy 4. Then click Add 5. In the field named Create and add a new Member type GUARD.CUSTOMERS 6. Then click Add 12 7. Also add the Member name without the creator id, so enter CUSTOMERS. 8. Then click Add. 9. Click Back Please Note: One of the features of Guardium is to be able to populate these groups automatically based on their contents. This is explained in the other labs. 10.Next, select your newly created group, Tables with Sensitive Objects, in the Object group drop down menu 13 11.Now, scroll down to the Action section and click add action ( ). 12.Once the add action button is clicked the following appears on the page, 13. On this click on the drop down, and select the field LOG FULL DETAILS 14.Our first rule is set! This should log SQL for all members of our newly created group. Now, click Apply. 14 15.Now click on Save button ( 3.1.2 ). Defining the Test Database Rule In this section, we will create the rule that fulfils the following requirement: • Test Database: Ignore Monitoring 1. Click the Add Access Rule... 2. Enter Test DB – Ignore Monitoring for the description, and TEST for the DB Name. 15 3. Click on Add Action and select IGNORE S-TAP SESSION. This will turn of all the monitoring and logging of the activities performed on the Test Database. 4. Click Apply and then Click Save. 5. We now have two rules set up. It's important to note that both rules will never be applied to one statement in our current setup. If that was our goal, we would have selected the “Continue to Next Rule” option inside the rules. Fortunately, stopping at a rule once satisfied is exactly what our requirements call for. This being said, because we are not continuing on to the next rule, the order of our rules matter for any statement that overlaps any two rules. For our example any statement that uses the GUARD.CUSTOMERS table inside the TEST database. So, we have a decision to make about which rule should apply first to any such 16 statement. Our requirements say that the test data is already masked, so the information inside it does not need to be audited including the statements run against the GUARD.CUSTOMERS table. As such, our Test Database – Ignore Monitoring rule should be applied to those statements first. To do this click the order up button ( ) next to our Test Database – Ignore Monitoring. It should look like the following once ordered: Congratulations! You have now created a policy that has rules that fulfils all the requirements that were specified. 17 3.1.3 Reviewing the Policy Settings That was quite a few steps, so let's take a look at all of the settings to confirm that we have built the rules correctly. The policy page has a convenient method to help you do that. 1. At the policy window, click view the rule settings by clicking the expand buttons ( ) The expanded rules should look like the picture below. The changes we made have been highlighted for a quicker comparison. 2. Once reviewed, click on Protect Tab ( lab. ) to continue with the remaining steps in the 18 3.2 Installing the Policy Once you have created a policy, you need to install it for it to take effect. Installing a Policy applies it to the currently registered inspection engines. 1. Click in Protect tab ( ) and then click the Install Policy icon. 2. Select BC Auditing Requirements from the Policy Installer section and select the Install & Override from the drop down list. 19 3. Click OK at the confirmation box warning you that a new policy is about to be applied 4. You can see the installed policy on the right of the screen as such. You have now successfully created and applied the policy to all currently active inspection engines. An important part of data server auditing is creating reports to easily view the audit data once it is collected. In Guardium you use two mechanisms called Queries and Reports to accomplish the task. Queries draw data from the Guardium Collector, while reports define how to display the data drawn from a query. 3.3 Reporting on SQL Constructs In the previous sections we created a policy that included a rule that dictated that we should log the SQL statement information for all objects except those in the test database. In this section we will build a simple query and report to view that data. 3.3.1 Building the Query and the Report In this section of the lab you will build the report 1. Start by switching to the Monitor/Audit tab and then click on the Build Reports sub-tab and then click on the Track Data Access icon. 20 2. Click on the New... button in the Query Finder view that appears 3. Type All SQL Constructs as the query name because we are most interested in SQL statements, 4. Select SQL as the Main Entity 5. Now, click the Next button 6. In the query editor screen on your new query, expand the Client/Server entity, click on Server Type and then click Add Field 21 7. Follow the same previous steps to add Server IP and DB User Name fields. 8. Scroll down in the entity list and expand Session. Add Timestamp and Database Name 22 9. Scroll down and expand the SQL entity and add the Sql field 10. We have all the fields we need for the report, but the ordering of them could be confusing. Sometimes it's easier if they are organized in terms of a hierarchy. Use the check boxes ( ) and reorder buttons ( ) to reorder the fields Keep reordering until the fields are in the following order: 23 11. We will now add a parameter for a filter based on DB User Name. This can help users of the report to focus on what they are concerned about, filtering out the information they do not need. Scroll back up to the Client/Server entity, click on DB User Name, and select Add Condition 12. In the new Query Condition that appears in the second window, enter the following values: Operator: LIKE Runtime Param.: Parameter DB_Username Note: “DB_Username” is the parameter name not the value that is placed in the condition 24 13. Finally, to again to help the reader of the report, specify that the report be sorted on the timestamp by default. Select the Order-by option, enter 1 for Sort Rank, and select the Descend option. Also Select the Add Count checkbox which allows you to group the same constructs together rather then get the same type of sql constructs recorded on every entry. For example, this would allow you to view how many select statements were made, rather then see an entry for each select statement made. 14. Finally, click the Save button and then the Generate Tabular button 15. We have now built the query. The next steps will create a default tabular report on top of the query just created, this report will be added to the My New Reports portlet. This distinction between queries and reports will be highlighted later. Select OK at the prompt that warns that you will be creating a report and portlet 25 16. Click Ok 17. Click on Add To My New Reports button 18. Click Ok, to add an instance of the report to the My New Reports pane 19. Click Ok 20. We now need to refresh the page, so click on the My New Reports. 26 3.3.2 Viewing the Report In this section we will specify the report parameters and generate some data to view. 1. Click on the newly created All SQL Constructs report on the left. Notice that the report is empty. 2. The report is empty because we have not specified our parameters yet. To do that click on the edit button. 3. Specify GUARD for the DB_Username parameter and click the Update button Note: Normally the QUERY_FROM_DATE and QUERY_TO_DATE parameters are also very important and require changing. In our example, this is not necessary because we are about to execute a series of SQL statements in the next hour 4. Notice that still no data comes up, this is because the no statements have been run using the GUARD user recently 27 5. Let's change that situation. Minimize the Guardium Interface 6. Open a Gnome Terminal window from the Desktop and type the following: cd Scripts/ gedit RunToAudit.sql & 7. This is the script we will be running. Scroll through it and briefly familiarize yourself with it's contents. We will run it on three databases: The DB2 ORDERS database, meant to act as a production environment for our scenario. The ORACLE XE database instance, meant to act as a mirror of the DB2 ORDERS database. And the DB2 TEST database meant to act as a test environment that isn't being audited. We will run the same script on all three databases. A complete copy of the script has also been provided in Appendix B for your reference. 28 8. Type the following commands into the terminal: db2 connect to orders db2 -tvf RunToAudit.sql 9. Wait for the SQL commands to finish executing then enter the following command into the console: db2 terminate 29 10. Now. Lets do the same thing for the TEST database. Enter the following commands into the Terminal: db2 connect to test db2 -tvf RunToAudit.sql 30 11. Wait for the SQL to finish executing. Afterwards, execute the same script on the Oracle database by typing the following into the terminal: db2 terminate sqlplus guard/password @RunToAudit.sql 12. Wait for the SQL to finish executing and close the window 13. Open the Guardium interface back up by clicking on Firefox at the bottom of the screen 14. Click on the All SQL Constructs report again to reload it. 15. Notice that all the SQL statements have been recorded, but no parameter values show. They are instead replaced with question marks (?). This is the result of creating a report with the SQL column. Also note that the statements refer to two databases, the ORACLE XE instance and the DB2 ORDERS database. Now, click on the next page button ( ) 31 Congratulations! You have just created a report that shows SQL constructs being logged for ORDERS database, and the same SQL command executed against the TEST database is not being logged. In the next section, you'll prove that the first requirement has been satisfied. 3.4 Reporting on SQL with Values In this section, we will create a report that displays all the collected data that includes SQL parameter values. 1. Start by clicking on the Monitor/Audit tab and then click on the Build Reports sub-tab and then click on the Track Data Access icon 32 2. Use the Query Name drop down box to select All SQL Constructs 3. We are going to clone this query to help us save time in creating a new one. Click on the Clone button 4. Enter All SQL With Values as the name of the new Query 5. Select the Timestamp and Sql attributes ( ) and then click the delete button ( ) 33 6. Expand the Full SQL Entity. Add the Timestamp and Full Sql fields to the query. 7. Select the Timestamp field ( ) and move it to the front of the report using the up order button ( ). Once moved the order of attributes should be as follows: 8. For the Timestamp field, select Order-by, set Sort Rank to 1, and set Descend 34 9. Now, click Save button, then click Generate Tabular button and then Add to My New Reports button to create a new report to be added to My New Reports list. 10. Select OK at the prompts that warns that you will be creating a report and portlet 11. Click OK 12. Click the My New Reports tab to refresh the report list and click on the All SQL With Values report. Notice it returns no results. Again, this is because we have not yet defined the parameter values for our new report. Click on the Edit button to set the parameters 35 13. Enter GUARD for the DB_Username parameter, then click Update 14. The Report showing SQL with values is now displayed. Three things to notice: 1) The parameters in the report have values, not the question marks that we saw in the previous report. 2) Only the tables named CUSTOMERS are shown, because the policy specifies to Log Full Detail for only those tables 3) Although statements were run against the CUSTOMERS and other tables in the DB2 TEST database, nothing appears as per our requirements 36 Congratulations! You have now created two reports that show that our three requirements have been satisfied: Object Group Business Requirement Selective Audit Action Sensitive Log all SQL with values Objects(GUARD.CUSTOMERS) Log Full Details With Values Test Database (TEST) Ignore Monitoring DB Activity Ignore S-Tap Session Others Log only SQL construct Default logging behavior for security policies that do not use selective audit trail. 3.5 Creating the Base Query and Tabular Report In this section you will create a base query and you will also create a simple tabular report that uses that base query to outline the commands that are run against the database. 1. Click on Build Reports sub-tab and then click on Track Data Access icon 37 2. Click on New... 3. Enter the following values for each on the fields and click the Next button Query Name: Commands Run Against Table Main Entity: Command 4. Expand the Command entity and add the SQL Verb field to the report 38 5. Under Client/Server add DB User Name as a condition. 6. Under Object entity, add Object Name field as a condition. 7. Enter the following values for the two new conditions DB Username: Operator: LIKE Runtime Param.: Parameter DB_Username Object Name: Operator: LIKE Runtime Param.: Parameter Object_Name 8. Select the Add Count and Sort by Count check box at the top of the page. This will sort by the Total Access field that is automatically included in the report that will result from this process 39 9. Click Save to save the query and then click Generate Tabular and then click on Add to My New Reports to create a report from the query and add it to My New Reports portlet. 10. Click OK at the prompts that warns that you will be creating a report and portlet 11. Click OK. 12. Click the My New Reports tab to refresh the report list and click on the Commands Run Against Table report. Now, click on the Edit button in order to set it's parameters 13. Enter the parameters as follows and click Update -DB_Username: -Object_Name: GUARD CUSTOMERS 40 14. This report shows the kinds of SQL requests that were run against all tables named CUSTOMERS that are being audited. 15. A great feature about Guardium is that it allows you to drill down through audit information. To drill down, Double click on the Update row. Now click Show SQL with Values 41 16. The SQL appears. Notice that there are only 6 entries. This is because each statement was run twice, once against the Oracle XE database, and once against the DB2 ORDERS database. In Guardium, it's possible to create and modify your own drill down reports. That topic, however, is out of the scope of this lab. Congratulations! You have just completed Guardium Auditing Lab 1. In this lab you performed the following tasks: 1. Created a non-selective audit policy with two rules that applied to two different classes of SQL statements 2. Installed that policy 3. Created two queries and reports that showed that your policy was correctly configured 4. Create one query and a reports off of it showing the data in tabular format and allowing you to drill down to the details of them. 42 4. Appendix A: Policy Rule Actions for Auditing These actions control the level of logging based on the observed traffic. You define these actions inside rules that are included in a selective audit trail policy. The description of these rules can also be found in the Guardium help documents. 1. Audit Only: Available for a Selective Audit Trail policy only. Log the construct that triggered the rule. For a Selective Audit Trail policy, no constructs are logged by default, so use this command to indicate what does get logged. 2. Log only: Log the policy violation only. Except for the Allow action, a policy violation is logged each time a rule is triggered (unless that action suppresses logging). 1. Log masked details: Log the full SQL for this request, replacing values with question marks (???). 2. Log full details: Log the full SQL, including values, for this request. 3. Log Full Details With Values: Like the above, but in addition, each value will stored as a separate element. This takes more time and space, but speeds searching and reporting tasks later. 4. Log Full Details Per Session: Log the full SQL (including values) for this request and for the remainder of the session 5. Log Full Details Per Session With Values: Like the above, but in addition, each value will stored as a separate element. This takes more time and space, but speeds searching and reporting tasks later. 6. Skip Logging: When matched, do not log a policy violation, and stop logging constructs. This is similar to the Allow action, but it additionally stops the logging of constructs. This action is used to eliminate the logging of constructs for requests that are known to be of no interest. 7. Ignore Responses Per Session: Responses for the remainder of the session will be ignored. This action is useful in cases where you know the database response will be of no interest. 8. Ignore Session: The current request and the remainder of the session will be ignored. This action might be useful if, for example, the database includes a test region, and there is no need to apply policy rules against that region of the database. 9. Ignore S-TAP Session: This action will send the ignore message to the S-TAP just like the standard 'Ignore Session' action but will keep track of this session on the appliance in case another 'Ignore' command should be sent. Using this action will promise that the ignore lists are up to date and in sync with the current policy definitions. 10.Ignore SQL Per Session: No SQL will be logged for the remainder of the session, except when an exception occurs, in which case all exception data (including the SQL causing the exception) will be logged. 11.Quick Parse: For access rules only, for the remainder of the session, WHERE clauses will not be parsed. This reduces parsing time. In this mode all objects accessed can be determined (since objects appear before the WHERE clause), but the exact object instances affected will be unknown, since that is determined by the WHERE clause. 43 5. Appendix B: Sample SQL Script This script is run during the lab on three databases in the environment in order to demonstrate auditing reports and policies. -- 20 Random Select Statements on CUSTOMERS SELECT * FROM CUSTOMERS WHERE CUST_ID='10000'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10006'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10028'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10496'; SELECT * FROM CUSTOMERS WHERE CUST_ID='13519'; SELECT * FROM CUSTOMERS WHERE CUST_ID='18128'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10000'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10006'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10028'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10496'; SELECT * FROM CUSTOMERS WHERE CUST_ID='13519'; SELECT * FROM CUSTOMERS WHERE CUST_ID='18128'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10000'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10006'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10028'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10496'; SELECT * FROM CUSTOMERS WHERE CUST_ID='13519'; SELECT * FROM CUSTOMERS WHERE CUST_ID='18128'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10000'; SELECT * FROM CUSTOMERS WHERE CUST_ID='10006'; -- 6 Random UPDATE Statements on CUSTOMERS UPDATE CUSTOMERS SET CITY='SOUTHBOROUGH' WHERE CUST_ID='10000'; UPDATE CUSTOMERS SET CITY='WESTBOROUGH' WHERE CUST_ID='10000'; UPDATE CUSTOMERS SET CITY='CAMBRIDGE' WHERE CUST_ID='10000'; UPDATE CUSTOMERS SET CITY='ROME' WHERE CUST_ID='10099'; UPDATE CUSTOMERS SET CITY='VENICE' WHERE CUST_ID='10099'; UPDATE CUSTOMERS SET CITY='CORLEONE' WHERE CUST_ID='10099'; -- 3 Random DELETE FROM DELETE FROM DELETE FROM DELETE Statements on CUSTOMERS CUSTOMERS WHERE CUST_ID='10033'; CUSTOMERS WHERE CUST_ID='10036'; CUSTOMERS WHERE CUST_ID='10064'; -- 1 Random INSERT Statement on CUSTOMERS INSERT INTO CUSTOMERS VALUES('13520', 'Vito Corleone', '3840 Byers Lane', NULL, NULL, 'Las Vegas', 'NV', 'US', '02110', '0000', 'Vito.Corleone@mailinator.com', '951-3776099', 904.86, 'SE331', 'IT', '8297790B', '3088000354660030', 'JCB', '0709', '9597', NULL, NULL); -- 12 Random Select SELECT * FROM ITEMS SELECT * FROM ITEMS SELECT * FROM ITEMS SELECT * FROM ITEMS SELECT * FROM ITEMS SELECT * FROM ITEMS Statements on ITEMS WHERE ITEM_ID='AD100'; WHERE ITEM_ID='AD101'; WHERE ITEM_ID='AD102'; WHERE ITEM_ID='AD103'; WHERE ITEM_ID='AD104'; WHERE ITEM_ID='AD105'; 44 SELECT SELECT SELECT SELECT SELECT SELECT * * * * * * FROM FROM FROM FROM FROM FROM ITEMS ITEMS ITEMS ITEMS ITEMS ITEMS WHERE WHERE WHERE WHERE WHERE WHERE ITEM_ID='AD100'; ITEM_ID='AD101'; ITEM_ID='AD102'; ITEM_ID='AD103'; ITEM_ID='AD104'; ITEM_ID='AD105'; -- 2 Random Update Statement on ITEMS UPDATE ITEMS SET UNIT_PRICE = UNIT_PRICE * 1.1; UPDATE ITEMS SET UNIT_PRICE = UNIT_PRICE - 0.10; -- 9 Random DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE FROM DELETE Statements on DETAILS/ORDERS DETAILS WHERE ITEM_ID='HR170'; ITEMS WHERE ITEM_ID='HR170'; DETAILS WHERE ITEM_ID='HR171'; ITEMS WHERE ITEM_ID='HR171'; DETAILS WHERE ITEM_ID='HR172'; ITEMS WHERE ITEM_ID='HR172'; DETAILS WHERE ITEM_ID='HR173'; ITEMS WHERE ITEM_ID='HR173'; DETAILS WHERE ITEM_ID='HR174'; ITEMS WHERE ITEM_ID='HR174'; DETAILS WHERE ITEM_ID='HR175'; ITEMS WHERE ITEM_ID='HR175'; DETAILS WHERE ITEM_ID='HR176'; ITEMS WHERE ITEM_ID='HR176'; DETAILS WHERE ITEM_ID='HR177'; ITEMS WHERE ITEM_ID='HR177'; DETAILS WHERE ITEM_ID='HR178'; ITEMS WHERE ITEM_ID='HR178'; -- 9 Random INSERT INTO INSERT INTO INSERT INTO INSERT INTO INSERT INTO INSERT INTO INSERT INTO INSERT INTO INSERT INTO INSERTS Statements on ITEMS VALUES('HR170', ITEMS VALUES('HR171', ITEMS VALUES('HR172', ITEMS VALUES('HR173', ITEMS VALUES('HR174', ITEMS VALUES('HR175', ITEMS VALUES('HR176', ITEMS VALUES('HR177', ITEMS VALUES('HR178', ITEMS 'Rocky 1', 'Drama', 'R', 31.00, 28); 'Rocky 2', 'Drama', 'R', 31.00, 28); 'Rocky 3', 'Drama', 'R', 31.00, 28); 'Rocky 4', 'Drama', 'R', 31.00, 28); 'Rocky 5', 'Drama', 'R', 31.00, 28); 'Rocky 6', 'Drama', 'R', 31.00, 28); 'Rocky 7', 'Drama', 'R', 31.00, 28); 'Rocky 8', 'Drama', 'R', 31.00, 28); 'The Running Man', 'Action', 'R', 32.00, 28); 45 © Copyright IBM Corporation 2011 All Rights Reserved. IBM Canada 8200 Warden Avenue Markham, ON L6G 1C7 Canada Printed in Canada 11-01 IBM, IBM (logo), Optim, and DB2 are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both UNIX is a registered trademark of The Open Group in the United States, other countries, or both Windows is a trademark of Microsoft Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. The information in this publication is provided AS IS without warranty. Such information was obtained from publicly available sources, is current as of January 2011, and is subject to change. Any performance data included in the paper was obtained in the specific operating environment and is provided as an illustration. Performance in other operating environments may vary. More specific information about the capabilities of products described should be obtained from the suppliers of those products. References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. 46