Reading DB2 LUW EXPLAIN plans (with special emphasis on XML) Susanne Englert 3/31/2009
© 2008 IBM Corporation
Agenda Why should I be interested in EXPLAINs? What IS an EXPLAIN? How do I get them? How do I read them? ► What do the operators mean? ► Which ones are XML-specific?
Examples (many) Summary and references
© 2009 IBM Corporation
Information Management
2
Why should I be interested in EXPLAINs? The single most powerful tool to debug performance problems! Answer questions like: ► Which indexes are getting used? ► How many rows does DB2 think my query will read? ► Does my query require sorts? ► For joins, what join methods are being used? In what order are the tables joined?
© 2009 IBM Corporation
Information Management
3
What happens when I ask for an EXPLAIN? DB2 query optimizer populates special tables in the catalog that describe the execution strategy (the “plan”) ► EXPLAIN_ARGUMENT, ► EXPLAIN_INSTANCE ► … more
Two tools are available to read the tables and provide a visual/graphical representation of the plan ► db2exfmt (command line) ► Visual Explain
Other tools that do not use the “Explain tables” ► dynexpln ► db2expln
© 2009 IBM Corporation
Information Management
4
What does an EXPLAIN look like? Representation of the query optimizer’s execution plan as a tree ►Leaf nodes are data ►Internal nodes are operators that filter, join, sort, group, etc.
For queries, data flows upwards from the leaves through the tree’s operators towards the root
© 2009 IBM Corporation
Information Management
5
Types of EXPLAIN outputs db2exfmt command-line tool
Visual Explain tool – start from ►DB2 Control Center or ►IBM Data Studio Developer
Rows RETURN ( 1) Cost I/O | 1 GRPBY ( 2) 15.2737 2 | 0.438058 HSJOIN ( 3) 15.2736 2 /-----+-----\ 92.6111 92 IXSCAN IXSCAN ( 4) ( 5) 15.1963 0.0655628 2 0 | | 19450 92 INDEX: SENGLERT INDEX: SENGLERT PRODX1 DSX4
© 2009 IBM Corporation
Information Management
6
How to use db2exfmt Not as pretty as Visual Explain, but ► ► ► ►
Text format provides all information without clicking Easy to cut, paste, attach to email Preferred format when dealing with DB2 support and sending explains to IBM Prerequisite: (Create Explain tables in the database catalog – a one- time operation) db2 –tvf sqllib/misc/EXPLAIN.DDL
Steps (assume a connection to “mydb”) ► ► ► ►
OR
db2 set current explain mode explain db2 –tvf db2exfmt –d mydb -1 –o db2 set current explain mode no
(set flag to explain, don’t run query) (populate the explain tables) (format output) (reset the explain-only flag)
► db2 explain plan for ► db2exfmt –d mydb -1 –o (format output) ► When using this method, text following XQUERY must be enclosed in single quotes
Both options explain a single query and format the most-recentlyexplained query into a file called . © 2009 IBM Corporation
Information Management
7
db2exfmt examples: Single-table queries involving ► Relational columns only (Q1) ► XML extraction, relational predicate (Q2) ► XQUERY, using one XML index for one predicate (Q3) ► XQUERY, using two XML indexes and two predicates (Q4) ► One XML index, One relational index (Q5)
Join queries ► Relational join with XML predicates and extraction (Q6) ► Q6 rewritten using XML joins, two ways – Incorrectly written, doesn’t use index on join element (Q7) – Corrected to use index on join element (Q8)
© 2009 IBM Corporation
Information Management
8
Single-table queries: The PRODUCT table. Relational columns and one 1 XML column that replicates relational data CREATE TABLE "SENGLERT"."PRODUCT" ( "PRODKEY" INTEGER NOT NULL , "UPC_NUMBER" CHAR(11) NOT NULL , "PACKAGE_TYPE" CHAR(20) , "FLAVOR" CHAR(20) , "FORM" CHAR(20) , "CATEGORY" INTEGER , "SUB_CATEGORY" INTEGER , "CASE_PACK" INTEGER , "PACKAGE_SIZE" CHAR(6) , "ITEM_DESC" CHAR(30) , "P_PRICE" DECIMAL(11,2) , "CATEGORY_DESC" CHAR(30) , "P_COST" DECIMAL(11,2) , "SUB_CATEGORY_DESC" CHAR(70) , "PRDDOC" XML ); Relational indexes: • PRODKEY (primary key), (CATEGORY, PRODKEY) XML indexes: /product/prodkey (type double), /product/category (type double) /product/sub_category (type varchar(30)) © 2009 IBM Corporation
Information Management
9
Query with relational columns only (Q1) -- Uses the PRODUCT table in database “POPSSER” db2 => set current explain mode explain; DB20000I The SQL command completed successfully.
db2 => select count(*) from product where db2 (cont.) => category = 42 and sub_category = 3; SQL0217W The statement was not executed as only Explain information requests are being processed. SQLSTATE=01604 db2 => !db2exfmt -d popsser -1 -o q1.exfmt; DB2 Universal Database Version 9.7, 5622-044 (c) Copyright IBM Corp. 1991, 200 Licensed Material - Program Property of IBM IBM DATABASE 2 Explain Table Format Tool Connecting to the Database. Connect to Database Successful. Output is in q1.exfmt. db2 => set current explain mode no; db2 => -- Let's see what's in q1.exfmt!
© 2009 IBM Corporation
Information Management
10
The top of q1.exfmt DB2 Universal Database Version 9.5, 5622-044 (c) Copyright IBM Corp. 1991, 2007 Licensed Material - Program Property of IBM IBM DATABASE 2 Explain Table Format Tool ******************** EXPLAIN INSTANCE ******************** DB2_VERSION: 09.07.0 SOURCE_NAME: SQLC2G13 SOURCE_SCHEMA: NULLID SOURCE_VERSION: EXPLAIN_TIME: 2009-03-28-21.14.50.051131 EXPLAIN_REQUESTER: SENGLERT Database Context: ---------------Parallelism: CPU Speed: Comm Speed: Buffer Pool size: Sort Heap size: Database Heap size: Lock List size: Maximum Lock List: Average Applications: Locks Available:
None 4.000000e-005 0 880100 1024 2476 423444 98 1 13279204
Package Context: --------------SQL Type: Optimization Level: Blocking: Isolation Level:
Dynamic 5 Block All Cursors Cursor Stability
© 2009 IBM Corporation
Database parameters that can affect query plan selection!
Information Management
11
The next part of q1.exfmt ---------------- STATEMENT 1 SECTION 201 ---------------QUERYNO: 1 QUERYTAG: CLP Statement Type: Select Updatable: No Deletable: No Query Degree: 1 Original Statement: -----------------select count(*) from product where category = 42 and sub_category = 3
Optimized StatementA SQL-like representation of the query after rewriting: • View merging • Redirection to summary tables • Pre-computation of constant expressions • Subquery-to-join transformations
Optimized Statement: ------------------SELECT Q3.$C0 FROM (SELECT COUNT(*) FROM (SELECT $RID$ FROM SENGLERT.PRODUCT AS Q1 WHERE (Q1.SUB_CATEGORY = 3) AND (Q1.CATEGORY = 42)) AS Q2) AS Q3
© 2009 IBM Corporation
Information Management
12
Total Cost: Query Degree:
45.259 1
Rows RETURN ( 1) Cost I/O | Compute 1 aggregate: count(*) GRPBY ( 2) 45.2234 17 | 0.377555 FETCH Fetch rows from base ( 3) table and apply 45.2096 17 SUB_CATEGORY = 3 /---+---\ predicate 92.6111 19450 RIDSCN TABLE: SENGLERT ( 4) PRODUCT 18.7684 1 | Sort Row-IDs (RIDs) 92.6111 SORT generated by index ( 5) scan 18.7169 1 | 92.6111 Relational Index scan: IXSCAN ( 6) CATEGORY = 42 16.3696 1 | Relational 19450 INDEX: SENGLERT (category, PRODX2
© 2009 IBM Corporation
The interesting part of q1.exfmt 92.6111 IXSCAN ( 6) 16.3696 1 A sample operator
A tree of operators Every operator has: ►Rowcount estimate: 92.6111 ►Operator name: IXSCAN ►Operator number: (6) ►Cost: 16.3696 ►I/O count: 1 If you forget what the numbers mean, look at the RETURN operator! It serves as a legend. index on prodkey)
Information Management
13
How to see what each operator is doing – Example: IXSCAN in operator 6 – look at detail section in output 6) IXSCAN: (Index Scan)… Predicates: ---------3) Start Key Predicate Comparison Operator: Subquery Input Required: Filter Factor: What predicate is Predicate Text: being evaluated? -------------(Q1.CATEGORY = 42) 3) Stop Key Predicate Comparison Operator: Subquery Input Required: Filter Factor: Predicate Text: -------------(Q1.CATEGORY = 42)
PRODX2 is the relational index on (category, prodkey)
No
No
Input Streams: 1) From Object SENGLERT.PRODX2 Estimated number of rows: Number of columns: Output Streams: 2) To Operator #5 Estimated number of rows:
© 2009 IBM Corporation
Equal (=) 0.0047615
Equal (=) 0.0047615
19450 2 92.6111
Information Management
14
EXPLAIN plan operators – last three are XML-specific Operator: DELETE FETCH FILTER GENROW GRPBY HSJOIN INSERT IXAND IXSCAN MSJOIN NLJOIN RETURN RIDSCN RPD SHIP SORT TBSCAN TEMP TQ UNION UNIQUE UPDATE XANDOR XISCAN XSCAN
Description: Deletes rows from a table. Fetches rows from a table. Filters data. Used by DB2 to generate rows of data. Groups rows. Performs a hash joins in which the qualified rows from tables are hashed. Inserts rows into a table. The AND’ing of the results of multiple index scans. Scans or probes an index on relational. Performs a merge-sort join. Performs a nested loop join. Returns data from a query. Scans a list of row identifiers (RIDs). Retrieves data from a non-relational remote data source. Retrieves data from a remote data source. Sorts rows or rowIDs from a table. Performs a table scans. Stores data in a temporary table. A table queue, for parallelization of a query. Concatenates streams of rows from multiple tables. Eliminates rows with duplicate values. Updates data in the rows of a table. Evaluates multiple predicates simultaneously with two or more XISCAN operators. Scans or probes an index on XML data. Navigates XML data to evaluate XPath expressions.
© 2009 IBM Corporation
Table courtesy of Matthias Nicola
Information Management
15
XML-specific EXPLAIN operators XSCAN – XML document scan. Traverse XML document trees, extract document sequences or values, evaluate predicates XISCAN - XML index scan ► Input: path-value pair such as $doc/product[p_price > 1.00] ► Output: row IDs of qualifying documents and node IDs within those documents
XANDOR – XML index AND-ing ► Input: two or more XISCANs ► Output Row IDs of document that satisfy all XISCANs ► Can be used if: – Only equality predicates are used. – There are no wildcards in the index lookup path. – All predicates involve the same XML column
► XANDOR does round-robin probing of indexes to efficiently find qualifying Row IDs
© 2009 IBM Corporation
Information Management
16
XML extraction, relational predicate (Q2)
FETCH documents from base table
Rows RETURN ( 1) Cost I/O | 1 NLJOIN ( 2) 26.2359 3 /-+--\
1 FETCH ( 3) 18.1042 2 /---+---\
explain plan for select xmlquery( '$PRDDOC/product/item_desc/text()') from product where prodkey = 1; !db2exfmt -d popsser -1 -t|more;
1 XSCAN ( 5) 8.13169 1
1 19450 IXSCAN TABLE: SENGLERT ( 4) PRODUCT 9.9514 Q2 1 | 19450 IXSCAN - Relational index INDEX: SYSIBM SQL090217203311130 scan: PRODKEY = 1 Q2 © 2009 IBM Corporation
This NLJOIN operator is not really joining anything. Delivering documents to the XSCAN operator XSCAN – the navigation operator – extracts /product/item_desc/text() Details of XSCAN operator (5) 5) XSCAN : (XML Doc Navigation) Arguments: INPUTXID: (Context Node) PRDDOC JN INPUT: (Join input leg) INNER XPATH : (Internal XPath Expression) ( $INTERNAL_XMLTOXML_NIEO$(Q2.PRDDOC)) /product/item_desc/(text())(:-->$C0:)
Information Management
17
FAQ about Q2 Q. How come the plan shows a NLJOIN? There is no join happening. A. True, there isn’t. This is a notation used to indicate that documents are being passed to XSCAN. The pictures shows how to think of what is happening. Imagine that the FETCH feeds the XSCAN. Actual Plan
How to think about it – FETCH feeds XSCAN
Rows RETURN ( 1) Cost I/O | 1 NLJOIN ( 2) 26.2359 3 /-+--\ 1 1 FETCH XSCAN ( 3) ( 5) 18.1042 8.13169 2 1 /---+---\ 1 19450 IXSCAN TABLE: SENGLERT ( 4) PRODUCT 9.9514 Q2 1 | 19450 INDEX: SYSIBM SQL090217203311130 Q2 © 2009 IBM Corporation
Rows RETURN ( 1) Cost I/O | 1 XSCAN ( 2) 8.13169 | 1 FETCH ( 3) 18.1042 2 /---+---\ 1 19450 IXSCAN TABLE: SENGLERT ( 4) PRODUCT 9.9514 Q2 1 | 19450 INDEX: SYSIBM SQL090217203311130 Q2
Idea/pictures courtesy of M. Nicola
Information Management
18
Rows RETURN ( 1) Cost I/O Again, not a | real nested 30.7726 FILTER loop join xquery for $i in db2-fn:xmlcolumn ( 2) Delivers | ('PRODUCT.PRDDOC') where documents 32.0548 $i/product/category = 54 return NLJOIN for navigation. ( 3) /--+--\ {$i/product/item_desc} 34.1379 0.938979 FETCH XSCAN ; ( 4) ( 8) /---+----\ 34.1379 19450 XSCAN – the navigation operator – RIDSCN TABLE: SENGLERT extracts /product/item_desc/text() and ( 5) PRODUCT rechecks /product/category = 54 | 34.1379 SORT ( 6) SORT RIDs of rows | with qualifying docs 34.1379 XISCAN ( 7) Details of XSCAN operator 8: | XPATH : (Internal XPath Expression) 19450 Q2.PRDDOC/{(.[(product/category = 54)])(:-->$C0:), XMLIN: SENGLERT XISCAN: XML index scan product/(item_desc)(:-->$C1:)} DIM_PRODCATEGORYIDX on /product/category = 54 Q2
XQUERY that uses an XML index for one predicate (Q3)
© 2009 IBM Corporation
Information Management
19
FAQ about Q3 Q. Why is there a NLJOIN shown? This is not a join. ► A. See FAQ for Q2
Q. The details for XSCAN operator (8) show that it does two things- extraction of /product/item_desc and re-evaluation of the /product/category predicate. Why do we need to re-evaluate the predicate? Hasn’t the index scan XISCAN operator (7) already returned only the rows with documents satisfying the predicate? ► A. Good question! It turns out that there are some (rare) cases in which the index can return documents that don’t satisfy the predicate (but it never misses any that do). So we are careful and plan a navigation to make sure that the predicate is really satisfied. However, a run-time optimization is able to avoid this “extra” navigation in many cases. Often, we are able to detect that we don’t need to do it.
© 2009 IBM Corporation
Information Management
20
RETURN ( 1) | 0.067333 FILTER ( 2) | 0.0701385 XISCAN: XML index NLJOIN scan on ( 3) /product/category = 54 /--+---\ 0.0747235 0.938641 FETCH XSCAN ( 4) ( 10) /----+----\ 0.0747235 19450 RIDSCN TABLE: SENGLERT ( 5) PRODUCT | 0.0747235 SORT ( 6) | 0.0747235 XANDOR ( 7) /--------+---------\ 34.1379 42.5735 XISCAN XISCAN ( 8) ( 9) | | 19450 19450 XMLIN: SENGLERT XMLIN: SENGLERT DIM_PRODCATEGORYIDX DIM_PRODSUBCATEGORYIDX Q2 Q2
XQUERY with two predicates and two XML indexes (Q4)
© 2009 IBM Corporation
xquery for $i in db2fn:xmlcolumn('PRODUCT.PRDDOC') where $i/product/category = 54 and $i/product/sub_category = 3 return {$i/product/item_desc} ;
XSCAN navigation to extract item_desc as well as to re-check predicates on category and sub_category
XANDOR: XML index-anding. See slide 17. Output: RIDs that satisfy both XISCANs.
XISCAN: XML index scan on /product/sub_category = 3
Information Management
21
RETURN ( 1) | 1 GRPBY ( 2) | 24.0385 explain plan for ^NLJOIN select count(*)from product ( 3) /-+--\ where xmlexists( 24.0385 1 '$PRDDOC/product/category[. < 10]') FETCH XSCAN and prodkey between 30 and 100; ( 4) ( 10) /---+----\ !db2exfmt -d popsser -1 -t|more; 24.0385 19450 RIDSCN TABLE: SENGLERT ( 5) PRODUCT XSCAN | navigation to re24.0385 SORT check predicate ( 6) on category IXAND – index anding- can be | used with a combination of 24.0385 IXAND XML and relational indexes. ( 7) Allows range predicates, /-------+-------\ wildcards in XML expressions 70.9319 6591.52 IXSCAN XISCAN ( 8) ( 9) | | XISCAN: XML index scan 19450 19450 on /product/category < 10 INDEX: SYSIBM XMLIN: SENGLERT SQL090217203311130 DIM_PRODCATEGORYIDX
One XML index, one relational index (Q5)
© 2009 IBM Corporation
Information Management
22
For join queries: The DAILY_SALES table CREATE TABLE "SENGLERT"."DAILY_SALES“ ( "PERKEY" INTEGER NOT NULL , "STOREKEY" INTEGER NOT NULL , "CUSTKEY" INTEGER NOT NULL , "PRODKEY" INTEGER NOT NULL "PROMOKEY" INTEGER NOT NULL , "SALDOC" XML );
One row per sale Each row has a foreign key “prodkey” that refers to our product table Relational index on “prodkey” (others as well, but not used in our examples) One XML document per row, sample at right. Replicates keys of relational column, adds other data. XML indexes: /fact/keys/prodkey (type double)
© 2009 IBM Corporation
Information Management
23
Relational join with XML predicate and extractions (Q6) select px.sub_category, sx.shelf_number from daily_sales s, product p, xmltable('$SALDOC/fact/measures/shelf_number‘ columns shelf_number integer path '.') as sx, xmltable('$PRDDOC/product[category < 150]' columns sub_category varchar(30) path 'sub_category') as px where s.prodkey = p.prodkey;
For certain product categories, find sales of those categories and list their shelf numbers There’s an XML index on /product/category p.prodkey and s.prodkey are (indexed) relational columns
© 2009 IBM Corporation
Information Management
24
Rows RETURN ( 1) Cost I/O | 2.20389e+07 NLJOIN HSJOIN (hash join) on ( 2) s.prodkey = p.prodkey /--+---\ 2.16407e+07 1.0184 HSJOIN XSCAN ( 3) ( 11) /-----+------\ 2.22907e+07 18882.9 TBSCAN NLJOIN ( 4) ( 5) | /-+--\ 2.22907e+07 9725 1.94168 TABLE: SENGLERT FETCH XSCAN DAILY_SALES ( 6) ( 10) /---+----\ 9725 19450 RIDSCN TABLE: SENGLERT ( 7) PRODUCT | 9725 SORT ( 8) | 9725 XISCAN ( 9) 48 | 19450 XMLIN: SENGLERT DIM_PRODCATEGORYIDX
Relational join with XML predicate and extractions (Q6)
© 2009 IBM Corporation
Not real nested loop joins
XSCAN navigation to extract /fact/measures/shelf_number
XSCAN navigation to re-evaluate /product[category < 150] and to extract /product/sub_category
XISCAN to evaluate /product[category < 150]
Information Management
25
The same join as Q6, with XML join keys (Q7) explain plan for select px.sub_category, sx.shelf_number from daily_sales s, product p, xmltable('$SALDOC/fact/measures/shelf_number‘ columns shelf_number integer path '.') as sx, xmltable('$PRDDOC/product[category < 150]' columns sub_category varchar(30) path 'sub_category') as px where xmlexists ('$SALDOC/fact/keys[prodkey = $PRDDOC/product/prodkey]'); !db2exfmt -d popsser -1 -t|more;
Same query as before, except relational join predicate on prodkey has been replaced by XML join predicate inside XMLEXISTS Remember that $SALDOC/fact/keys/prodkey and $PRDDOC/product/prodkey have XML indexes © 2009 IBM Corporation
Information Management
26
Plan for the XML join query Q7 This IS a real nested loop join! NLJOIN is the only RETURN ( 1) option for XML joins. | 1.72347e+07 XSCAN to NLJOIN retrieve ( 2) TEMP of entire product/prodkey /------+------\ DAILY_SALES table. Why?? 18694.5 921.915 NLJOIN TBSCAN ( 3) ( 9) /-+--\ | 9725 1.92232 2.05329e+07 FETCH XSCAN TEMP ( 4) ( 8) ( 10) XSCAN to extract /---+----\ | /fact/keys/prodkey and 9725 19450 2.05329e+07 /fact/measures/shelf_number RIDSCN TABLE: SENGLERT NLJOIN ( 5) PRODUCT ( 11) XISCAN | /---+---\ to 9725 2.22907e+07 0.921143 SORT TBSCAN XSCAN evaluate ( 6) ( 12) ( 13) /product[ | | category 9725 2.22907e+07 XISCAN TABLE: SENGLERT < 150] ( 7) DAILY_SALES | TBSCAN of DAILY_SALES table. 19450 XMLIN: SENGLERT Hmmmm… Why is the index on DIM_PRODCATEGORYIDX /fact/keys/prodkey not used?
© 2009 IBM Corporation
Information Management
27
Q8: Corrected join from Q7 with casts around XML join keys! explain plan for select px.sub_category, sx.shelf_number from daily_sales s, product p, xmltable('$SALDOC/fact/measures/shelf_number' columns shelf_number integer path '.') as sx, xmltable('$PRDDOC/product[category < 150]' columns sub_category varchar(30) path 'sub_category') as px where xmlexists ('$SALDOC/fact/keys[prodkey/xs:double(.) = $PRDDOC/product/prodkey/xs:double(.)]'); !db2exfmt -d popsser -1 -t|more;
For XML joins: need to cast both sides of the join predicate in order to enable use of the XML index(es)! Now it is possible to use index(es) on $SALDOC/fact/keys/prodkey and $PRDDOC/product/prodkey © 2009 IBM Corporation
Information Management
28
Plan for the corrected XML join query (Q8) RETURN ( 1) This IS a real nested loop Cost I/O join! NLJOIN is the only XSCAN to | option for XML joins. retrieve 3.83852e+08 NLJOIN product/prodkey ( 2) /----------+----------\ 18694.5 20532.9 NLJOIN NLJOIN ( 3) ( 9) /-+--\ /-+--\ XISCAN to 9725 1.92232 753.287 27.2577 XSCAN to extract evaluate FETCH XSCAN FETCH XSCAN /fact/measures/shelf_number and /product[category ( 4) ( 8) ( 10) ( 14) recheck /fact/keys/prodkey /---+----\ /---+----\ < 150] predicate 9725 19450 753.287 2.22907e+07 RIDSCN TABLE: SENGLERT RIDSCN TABLE: SENGLERT ( 5) PRODUCT ( 11) DAILY_SALES | | 9725 753.287 SORT SORT 48 5 | | 9725 753.287 XISCAN XISCAN ( 7) ( 13) | | Hooray, XISCAN of 19450 2.22907e+07 /fact/keys/prodkey index (join) XMLIN: SENGLERT XMLIN: SENGLERT DIM_PRODCATEGORYIDX PRODKEYIDX © 2009 IBM Corporation
Information Management
29
Things to remember when reading EXPLAINs Start reading from the lower left corner – since that is (generally) where execution begins Ignore the cost numbers ► They are in units called timerons that correspond somewhat to estimated elapsed time ► They give clues about the optimizer’s expense estimates, but are of little value to an outside observer
DO watch the estimated row counts – they may help you understand the optimizer’s decisions Most value in EXPLAINs: ► Determining index use ► Join order ► Row count (“cardinality”) estimates
© 2009 IBM Corporation
Information Management
30
Further reading ► http://download.boulder.ibm.com/ibmdl/pub/software/dw/dm/d b2/bestpractices/DB2BP_Query_Tuning_0508I.pdf ► http://download.boulder.ibm.com/ibmdl/pub/software/dw/dm/d b2/bestpractices/DB2BP_XML_0508I.pdf ► http://www.ibm.com/developerworks/data/library/techarticle/d m-0611nicola/ ► http://www.ibm.com/developerworks/data/library/techarticle/d m-0508kapoor/ ► http://hoadb2ug.org/Docs/accessplans.pdf (old, but good)
© 2009 IBM Corporation
Information Management
31
Acknowledgements Matthias Nicola – review and ideas Wolfgang Krause – careful review Anjali Norwood – patient answers to random questions
© 2009 IBM Corporation
Information Management
32
