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', '[email protected]', '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
