IT University of Copenhagen

Paulius Juodisius (170786 pjuo)

ReserveWithUs Tuning

Database Tuning II-F2011

Teacher: Philippe Bonnet

Copenhagen, 2011

Part I

ReserveWithUs TuningTask 1

EvaluationIn order to determine whether Application server should be installed in separate machine one has to measureapplication server impact on overall system performance.Application server is based on Java, so main Java process (sun-java6 runtime environment) was observed.Initial application and database server load testing was conducted by making 50 thread (user) parallel re-quests from a client machine. Persistent monitoring utilizing top program (top -b | grep java) showed thatApplication server is a lightweight process and in most cases it was using less than 4% of processor time witha maximum jump up to 6% as it can be seen in table 1. The memory consumption was also limited, stayingunder 3%.Additional monitoring using vmstat (table 2) showed that at the beginning of the test system bottleneck isIO bound due to high number of threads sitting in uninterrupted read (waiting for IO to be done). As soonall data is read and placed in RAM, bottleneck switches and becomes CPU bound with user CPU usagereaching 50% (due to DB2 limitation) and many threads waiting in queue for the processor to be available.So in the chosen testing environment it can be expected that system’s performance would improve justslightly by placing Application server on a separate machine. This is due to the fact application server is notperforming any IO operations, so only small CPU usage can be saved by distributing servers across multiplemachines.This hypothesis was confirmed by tests conducted using JMeter with a test plan shown in figure 2. Totalnumber of parallel requests varied between 10 and 50. All tests were conducted with cold cache. Slight about3% average improvement in performance was noticed and is displayed in figure 1. Deployed on a secondarymachine application server was using up to 10% of processor time.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P TIME COMMAND

6722 db2inst1 20.00 0 1155m 57m 7580 S 1 1.5 0:00:02 3 0:01 java6722 db2inst1 20.00 0 1158m 64m 7588 S 4 1.7 0:00:02 3 0:02 java6722 db2inst1 20.00 0 1162m 65m 7612 S 5 1.7 0:00:02 3 0:02 java6722 db2inst1 20.00 0 1168m 65m 7612 S 3 1.7 0:00:02 3 0:02 java6722 db2inst1 20.00 0 1175m 67m 7652 S 4 1.8 0:00:02 3 0:02 java6722 db2inst1 20.00 0 1180m 75m 7652 S 6 2 0:00:03 3 0:02 java6722 db2inst1 20.00 0 1181m 75m 7652 S 1 2 0:00:03 3 0:02 java6722 db2inst1 20.00 0 1184m 76m 7652 S 1 2 0:00:03 3 0:02 java6722 db2inst1 20.00 0 1184m 76m 7652 S 0 2 0:00:03 3 0:02 java6722 db2inst1 20.00 0 1184m 76m 7652 S 2 2 0:00:03 3 0:02 java6722 db2inst1 20.00 0 1184m 76m 7652 S 2 2 0:00:03 3 0:02 java6722 db2inst1 20.00 0 1184m 76m 7668 S 3 2 0:00:03 3 0:02 java

Table 1: TOP statistics

2

r b swpd free buff cache si so bi bo in cs us sy id wa0 0 0 3038960 5072 259456 0 0 28 6 178 377 8 8 83 10 0 0 3041120 5088 256864 0 0 0 5 220 310 1 0 99 00 0 0 3040972 5224 256864 0 0 14 0 209 303 0 0 100 01 1 0 2642216 5800 643888 0 0 1713 266 798 2621 2 1 89 841 9 0 2516292 6140 751824 0 0 9611 32 2314 6249 48 2 48 242 0 0 2459044 6168 807952 0 0 3833 17 4007 13709 49 2 49 050 1 0 2445160 6200 821664 0 0 144 10 5055 19191 49 2 49 050 0 0 2398824 6288 867508 0 0 194 25 4889 18313 49 2 49 034 0 0 2265392 6320 999224 0 0 103 15 5130 19210 48 2 49 046 0 0 2259404 6344 1004808 0 0 574 9 4768 17055 49 2 49 034 0 0 2211664 6360 1051268 0 0 128 5 4539 16303 49 2 48 051 0 0 2074416 6392 1189212 0 0 298 15 5466 20613 49 2 49 025 0 0 2025284 6424 1237824 0 0 64 18 4703 16759 49 2 49 049 0 0 1935372 6440 1327660 0 0 61 9 5117 17668 49 2 49 043 0 0 1843160 6472 1419036 0 0 149 10 4255 14899 49 2 49 041 0 0 1844772 6504 1419432 0 0 74 12 3516 13216 49 2 49 020 0 0 1845164 6536 1419312 0 0 107 31 3397 10183 50 2 48 015 0 0 1844532 7320 1419424 0 0 155 34 2534 7301 49 1 48 110 0 0 1844704 7348 1419376 0 0 17 13 2237 6005 50 1 49 00 0 0 1845148 7380 1419388 0 0 95 25 1116 3165 25 1 72 2

Table 2: VMSTAT results with 10 second interval

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

0 5 10 15 20 25 30 35 40 45 50

Thr

ough

put (

com

man

ds/s

)

Number of threads

App server on main machineApp server on secondary machine

Figure 1: Total performance depending on application server placement

3

Figure 2: JMeter test plan

ConclusionIn the event that software and hardware is configured as it was during task 1 evaluation, Application servershould be deployed on the same machine as database server. The improvement is not significant and was onlynoticed when software was stressed beyond normal capacity which is unrealistic. However in a real worldscenario Application server would be responsible for a much wider range of functionality and therefore wouldlikely require isolation from Database Server. For instance, different Application server components wouldprovide security, business logic execution, administration, presentation functions and etc.

Task 2In order to find appropriate indices all performed DB queries are analyzed. Using results from first taskqueries were ordered by execution time. Execution time was also confirmed using Timespent interface.Indices on table keys are already established by default in DB2 database, therefore only additional indicesare analyzed.

ROOM QUERY

Using Timespent interface in addition to reports from task1 one can see that room search is the most expensivequery. Therefore first aim is to find appropriate indexes to speed up room query.An example of room search query is shown in figure 2.

4

SELECT H.HOTEL_ID, RDE.ROOM_TYPE, Q.ROOM_TYPE_ID, Q.DATE_START, Q.DATE_STOP, Q.NUMROOMS, Q.TOTAL_PRICE

FROM DB2INST1 .HOTEL AS H, DB2INST1 .ROOM_TYPE AS RDE, TABLE (

SELECT RDA.ROOM_TYPE_ID, MIN(RDA.SINGLE_DAY_DATE) AS DATE_START, MAX(RDA.SINGLE_DAY_DATE) AS DATE_STOP, 8 AS NUMROOMS, SUM(RDA.PRICE) AS TOTAL_PRICE

FROM DB2INST1 .ROOM_DATE AS RDAWHERE RDA.PRICE < 144

AND RDA.NUMAVAIL >= 8AND RDA.SINGLE_DAY_DATE >= ’2011−05−12 ’AND RDA.SINGLE_DAY_DATE < ’2011−05−21 ’

GROUP BY RDA.ROOM_TYPE_IDHAVING COUNT(∗ ) = ( DAYS( ’2011−05−21 ’) − DAYS( ’2011−05−12 ’) ))

AS QWHERE H.CITY = ’ c i ty38 ’

AND H.COUNTRY = ’ country15 ’AND H.HOTEL_ID = RDE.HOTEL_IDAND Q.ROOM_TYPE_ID = RDE.ROOM_TYPE_ID;

Figure 3: Room search query

First lets analyze nested query on table ROOM_TYPE. This query uses three predicates on followingcolumns: SINGLE_DAY_DATE, NUMAVAIL, PRICE. This is a range query, so it should be worth toestablish clustering index. A supporting factor is that deals (new records in ROOM_DATE table) are onlyinserted once a month.

CREATE INDEX roomdate_cluster ON db2inst1 . room_date ( single_day_date , numavail ,room_type_id , p r i c e ) CLUSTER ALLOW REVERSE SCANS;

During query execution results from nested query are written to temporary table which is inner joined withHOTEL and ROOM_DATE. HOTEL table search uses predicates on COUNTRY and CITY. In additionJOIN operation is performed using equality on HOTEL_ID. Proposed composite index for HOTEL table isshow below should provide the fastest access to data. Although this index requires significant amount of stor-age space, such can be considered acceptable due to tested hardware capabilities and increased performance.Again, index maintenance is not an issue because hotels are not updated frequently.

CREATE INDEX hote l_cover ing ON db2inst1 . ho t e l ( c i t y , country , d istance_to_center ,r a t i ng , s t a t e , zip_code , s t r e e t , name , hote l_id ) ALLOW REVERSE SCANS;

To minimize IO reads for ROOM_TYPE table composite index is declared in a sequence the columns arecalled.

CREATE INDEX roomtype_covering ON db2inst1 . room_type ( hotel_id , room_type_id ,room_type ) ALLOW REVERSE SCANS;

All these three indices should significantly improve query execution time.

5

HOTEL query

In a common scenario (e.g. hotels.com) when searching for a hotel one enters location and date filter.Therefore typical hotel command query would look like:

command=search_hote l s&country=country23&c i t y=c i ty47&price_max=107&date_start=2011−05−31&date_stop=2011−06−14

Such command invokes query shown in figure 4.

SELECT H.HOTEL_ID, H.NAME, H.STREET, H.CITY, H.ZIP_CODE, H.STATE, H.COUNTRY, H.RATING, H.DISTANCE_TO_CENTER

FROM DB2INST1 .HOTEL AS H, DB2INST1 .ROOM_TYPE AS RDE, DB2INST1 .ROOM_DATE AS RDA

WHERE H.CITY = ’ c i ty47 ’AND H.COUNTRY = ’ country23 ’AND RDA.SINGLE_DAY_DATE >= ’2011−05−31 ’AND RDA.SINGLE_DAY_DATE < ’2011−06−10 ’AND RDA.NUMAVAIL > 0AND H.HOTEL_ID = RDE.HOTEL_IDAND RDE.ROOM_TYPE_ID = RDA.ROOM_TYPE_ID;

Figure 4: Typical Hotel query

This query again joins three tables: HOTEL, ROOM_TYPE and ROOM_DATE. Due to the fact thatHOTEL table updates are not frequent, declaring composite index for HOTEL table should not suffer frommaintenance drawbacks. Most searches include city and country, so this index can also be clustered to putall hotel tuples from same city close to each other in storage device.

CREATE INDEX hote l_cover ing ON db2inst1 . ho t e l ( c i t y , country , distance_to_center ,zip_code , s ta te , s t r e e t , name , rat ing , hote l_id ) CLUSTER ALLOW REVERSE SCANS;

It might be worth to declare another index on ROOM_DATE table to cover ROOM_TYPE_ID and SIN-GLE_DAY_DATE in sequence to increase the efficiency of the nested loop join between ROOM_DATE andROOM_TYPE.

CREATE INDEX roomdate_covering ON db2inst1 . room_date ( room_type_id , single_day_date ,numavail ) ALLOW REVERSE SCANS;

Other sample queries used issued by application server are listed below. Most of them are simple queriesand can utilize default key attribute indices that already exist in database on used tables. One queries(room_date_update) should be satisfied with indices described before.

s e l e c t count (∗ ) from LOGIN where customer_id = 312780;s e l e c t va lue from LOGIN_COUNTER fo r update ;i n s e r t i n to LOGIN va lues (734 ,312780) ;update LOGIN_COUNTER se t value = 735 ;s e l e c t count (∗ ) from LOGIN where customer_id = 312780;i n s e r t i n to SHOPPING_CART va lues (312780 , ’2011−05−21 ’ , ’2011−05−22 ’ ,119918 ,21 ,163.0);

6

s e l e c t count (∗ ) from LOGIN where customer_id = 312780;s e l e c t ∗ from SHOPPING_CART where customer_id =312780;−−room_date_updateupdate ROOM_DATE se t numtaken = numtaken + 21 , numavail = numavail − 21where room_type_id = 119918 and single_day_date between ’2011−05−21 ’ and ’2011−05−22 ’;i n s e r t i n to BOOKED va lues (312780 , ’2011−05−21 ’ , ’2011−05−22 ’ ,119918 ,21 ,163.0 ,2) ;d e l e t e from LOGIN where customer_id = 312780;

EvaluationAfter indices were defined, reorg commands were issues to defragment table and index storage structures.At this point indices impact can be measured. Query execution time before and after index declaration iscompared. In addition it should be checked whether new indices are used at all for queries.Index impact on query execution is displayed in figure 4. In addition indices that were suggested by db2advistool are tested. Suggested indices are displayed in below:

CREATE INDEX DB2INST1 . IDX1105161019230 ON DB2INST1 .ROOM_TYPE (HOTEL_ID ASC,ROOM_TYPE_ID ASC) ALLOW REVERSE SCANS;CREATE INDEX DB2INST1 . IDX1105161019260 ON DB2INST1 .HOTEL (CITY ASC, COUNTRY ASC,DISTANCE_TO_CENTER ASC, RATING ASC, STATE ASC, ZIP_CODE ASC, STREET ASC, NAME ASC,HOTEL_ID ASC) ALLOW REVERSE SCANS;CREATE UNIQUE INDEX DB2INST1 . IDX1105161021050 ON DB2INST1 .ROOM_DATE (ROOM_TYPE_ID ASC,SINGLE_DAY_DATE ASC) INCLUDE (NUMAVAIL) ALLOW REVERSE SCANS;CREATE INDEX DB2INST1 . IDX1105161021300 ON DB2INST1 .ROOM_DATE (SINGLE_DAY_DATE ASC,NUMAVAIL ASC) ALLOW REVERSE SCANS;CREATE INDEX DB2INST1 . IDX1105161021540 ON DB2INST1 .HOTEL (CITY ASC, COUNTRY ASC,HOTEL_ID ASC) ALLOW REVERSE SCANS;CREATE INDEX DB2INST1 . IDX1105161022100 ON DB2INST1 .ROOM_TYPE (HOTEL_ID ASC,ROOM_TYPE ASC, ROOM_TYPE_ID ASC) ALLOW REVERSE SCANS;

0

500

1000

1500

2000

2500

3000

3500

Ro

om

qu

ery

Ho

tel q

ue

ry

Inse

rt in

to h

ote

l

Exe

cu

tio

n t

ime

(m

s)

Query

No Index

With Indices

With db2advis indices

With merged indices

Figure 5: Query performance

7

Query benchmark show that room query performance improved 20% and hotel query 55%. On a negativeside inserts into hotel table slowed down approximately 5 times. However such operation occurs seldom andshould not be a concern.It can also be seen that from room query point of view indices outperform db2advis suggested indices. HoweverHotel query is indeed performed faster using db2advis indices. So perfect solution for this situation woulda be a merge between chosen indices and db2advis ones. Merged index set is shown below and benchmarkresults are displayed in figure 4 last column.

CREATE INDEX hote l_l ight_cover ing ON db2inst1 . ho t e l ( c i ty , country , hote l_id )ALLOW REVERSE SCANS;CREATE INDEX roomtype_covering ON db2inst1 . room_type ( hotel_id , room_type_id ,room_type ) ALLOW REVERSE SCANS;CREATE INDEX roomdate_cluster ON db2inst1 . room_date ( single_day_date , numavail ,room_type_id , p r i c e ) CLUSTER ALLOW REVERSE SCANS;CREATE INDEX hote l_cover ing ON db2inst1 . ho t e l ( c i t y , country , distance_to_center ,zip_code , s ta te , s t r e e t , name , rat ing , hote l_id ) CLUSTER ALLOW REVERSE SCANS;CREATE UNIQUE INDEX roomdate_newUniqueIndex ON DB2INST1 .ROOM_DATE ( room_type_id ,single_day_date ) INCLUDE ( numavail ) ALLOW REVERSE SCANS;

In the last place index participation was tested using db2 explain tool (db2expln). Results confirmed thatall indices are involved in query execution plans.

Task 3There are several ways to back up and load table data in DB2. One way is to use Export and Import commandaccordingly. Export command can save data in various format and in this assignment IXF and DEL areconsidered. File in IXF format (proprietary binary format) includes data and table schema information aswell as indices. File in DEL saves data in simple comma separated value style. It is expected that IXFformat file would take more space and would require more time to generate. However additional redundantinformation (schema and indices) are saved and is not used later then importing back to customer table.In this assignment these export commands are considered:

−−Export IXFEXPORT TO customers . i x f OF IXF SELECT ∗ FROM customer ;−−Export DELEXPORT TO customers . de l OF DEL SELECT ∗ FROM customer ;

Execution time was primary concern and experiments were conducted by enforcing cold cache. Customertable consisted 100000 records with average row size of 262B. Results are shown in table 3. Exporting inDEL format is faster so it is more suitable for this assignment.

Export IXF Export DELAverage time (s) 136.6585 95.61367Average file size 407.9Mb 222.3Mb

Table 3: Export benchmark results

There couple ways in how data can be deleted:

LOAD FROM empty . de l o f DEL REPLACE INTO db2inst1 . customer ALLOW NO ACCESS;DELETE FROM db2inst1 . customer ;

First command performed very quickly in 5s. DELETE command failed with error “The transaction logfor the database is full.”. So to delete data LOAD command with REPLACE option is very efficient and ispreferred for use in ReserveWithUs application.Exported data can be imported using IMPORT or LOAD command. IMPORT command is a reverse toExport command and in low level uses SQL insert statements. It can also recreate table according to original

8

schema if file is in IXF format. Load command is faster because it does not check if data is consistent toexisting constraints. To achieve that set Integrity command has to be used after loading data. However itdoes not call triggers if they exist. Load is an efficient way of loading high volume of data into tables becauseit writes pages directly to database storage instead of using SQL INSERT. This is the reason why LOAD isexpected to be a more suitable solution in this assignment.

LOAD FROM /home/ db2inst1 /dbtun2/ customers2 . de l OF DEL INSERT INTO db2inst1 . customerALLOW NO ACCESS SET INTEGRITY PENDING CASCADE IMMEDIATE;IMPORT FROM /home/ db2inst1 /dbtun2/ customers2 . de l OF DEL COMMITCOUNTAUTOMATIC INSERT INTO db2inst1 . customer ;

Execution time was measured and results are displayed in table 4. It is clear that Load option is signifi-cantly faster and suits ReserveWithUs needs better.

Import LoadAverage execution time (s) 725.97 37

Table 4: Import procedure execution time

So the import/export procedure would look like this:

EXPORT TO customers . de l OF DEL SELECT ∗ FROM customer ;LOAD FROM empty . de l o f DEL REPLACE INTO db2inst1 . customer ALLOW NO ACCESS;LOAD FROM /home/ db2inst1 /dbtun2/ customers2 . de l OF DEL INSERT INTO db2inst1 . customerALLOW NO ACCESS SET INTEGRITY PENDING CASCADE IMMEDIATE;

Task 4Checkout function is a synchronized Java method which performs four SQL statements in one transaction.In addition it includes a 4 second automatic wait for customer to confirm the order. Multiple contentionsmay happen. Because checkout is a synchronized method, it has to wait for intrinsic lock on Shopping-Cartobject before it is executed. However this behavior can not be changed because it may return inconsistentresults.

Transaction choppingCheckout function includes four statements of which three are updating tuples. Therefore while executingthese statements db2 query processor has to acquire exclusive locks on 3 tables and keep them for the wholetime. Table 5 displays all statements and conflicting transactions. It may cause other reading transactionsto wait for extensive period.

Statement description Operation R/W (table name) Conflicting transactionget_shopping_cart R (shopping_cart)update room_date W (room_date) find_hotel, find_roominsert into booked W (booked)

empty shopping cart W (shopping_cart) add_to_shopping_cart

Table 5: SQL Statements

Using algorithm from “Database Tuning” book Appendix B, checkout transaction can be chopped tomultiple transactions. Proposed transactions are shown in table 6.

9

Transaction identifier Statements OperationT1 get_shopping_cart, empty shopping cart R (Shopping_cart), W (shopping_cartT2 update room_date W (room_date)T3 insert into booked W (booked)

Table 6: Proposed chopped transactions

Lack of resourcesNew test plan (figure 6) was assembled with higher number of addToCart, browse hotel and browse roomscommands so that pressure on checkout transaction is increased. Investigation of vmstat output during a testexecution showed that bottleneck switches intermittently between CPU-bound and IO-bound. Timespentinterface output (pool_index_p_reads) was constantly returning high numbers which means that indicesare not cached in buffer all the time. Default buffer pool size was increased to 400000 pages (4K page size= 1.6GB of RAM needed) which is more than 319596 pages used by DB. So in reality the whole databasecould be cached in RAM. Performance gain after increasing buffer pool is very significant as it can be seenin figure 7. Throughput have increased about 600%.

Figure 6: Test plan for checkout transaction testing

10

2

4

6

8

10

12

14

16

18

20

22

24T

hro

ughput (r

equest/s)

Bufferpool management

Default buffer pool size

Increased buffer pool size

Figure 7: Buffer pool increase impact

Automatic 4 second waitEvery checkout command takes at least 4 seconds to conduct due to the 4 second user interaction wait.Wrapping user interaction session inside of a transaction is inefficient and should avoided. User may takeextensive amount of time to make a decision and it could cause concurrency issues because locks are held fora prolonged time.

A suggestion in ReserveToUs instance would be to to introduce checkout_confirmation command whichwould perform tasks shown in table 5 without any delay. To satisfy such command, BOOKED relationorder_status attribute could be used to transition between pending orders and confirmed orders. In themean time checkout command functionality would decrease.

Task 5Sample Hotel query with distance parameter is show below:

SELECT H.HOTEL_ID , H.NAME , H.STREET , H.CITY , H.ZIP_CODE , H.STATE , H.COUNTRY ,H.RATING , H.DISTANCE_TO_CENTERFROM DB2INST1 .HOTEL AS H

, DB2INST1 .ROOM_TYPE AS RDE, DB2INST1 .ROOM_DATE AS RDA

WHERE H.CITY = ’ c i ty47 ’AND H.COUNTRY = ’ country23 ’AND RDA.SINGLE_DAY_DATE >= ’2011−05−31 ’AND RDA.SINGLE_DAY_DATE < ’2011−06−10 ’AND RDA.NUMAVAIL > 0AND H.DISTANCE_TO_CENTER < 5AND H.HOTEL_ID = RDE.HOTEL_IDAND RDE.ROOM_TYPE_ID = RDA.ROOM_TYPE_ID;

This query can take advantage of clustered index on hotel table that already is established. Thereby, noextra indices are required in order to speed up this query.

11

CREATE INDEX hote l_cover ing ON db2inst1 . ho t e l ( c i t y , country , distance_to_center ,zip_code , s ta te , s t r e e t , name , rat ing , hote l_id ) CLUSTER ALLOW REVERSE SCANS;

Part II

Logbook1 HardwareTwo machines were used during this project. Hardware configuration is shown in table 7.

Description Lenovo x201 (Primary) HP nx6325 (Secondary)Processor Intel i5-480M 2.66Ghz AMD Turion X2 TL-60 2Ghz

Cores/Threads (Logical CPU Cores) 2/4 2/2RAM 4GB 3.2GB

HDD speed 7200RPM 5400 RPMOS Ubuntu Server 11.04 64bit with LXDE Ubuntu 11.04 64bit

Table 7: Hardware configuration

To emulate real world server environment, IBM DB2 Express C database server was installed on a dedicatedOS (Ubuntu 11.04 Server Edition with LXDE desktop environment) in the primary machine. DB2 wasinstalled without any issues using DB2 installation wizard. Machines were connected using single Ethernetcable without using any routing devices.

2 Log• Primary dilemma was to find a proper benchmark setup which would apply realistic load and provide

consistent results. It was especially important for the first question in order to find application serverimpact on whole system. Measures had to be taken from a client side because it is mainly the client orcustomer who would feel the difference of shorter waiting times. Instead of writing a benchmark scriptI have decided to utilize a very suitable tool for such occasion called JMeter. This Java applicationis designed to apply customized load in a very organized way and can provide functional and non-functional testing measurements.

• To simulate a real world scenario I have made a test plan (shown in figure 2 and figure 6) where one user(one thread) performed set number of tasks in a random order so that load is uniformly distributed.Multiple loops were conducted to ensure that average results are objective. To ensure that CPU is notused during testing while generating random command parameters, CSV file was generated by a scriptbefore every experiment. Each CSV line contained commands with unique parameters that representeda single user activities during the experiment.

• Testing client was sending high number of parallel TCP requests, so application thread pool was in-creased to 200.

• After loading initial data to DB tables, login command was not working. It was resolved by settingcorrect counter value. Solution was posted in blogs.

i n s e r t i n to log in_counter va lue s ( 1 ) ;

• For each experiment to be comparable cold cache had to be enforced using:

12

db2stop f o r c esudo syncecho 3 | sudo tee /proc / sys /vm/drop_cachesdb2star t

• Supplied application did not performed administration functions, therefore I had to write extra SQLcommands for inserting records to hotel and room_date tables. This was done to measure index impacton maintenance operations. Increased execution time was not considered harmful because updates occurseldom only once or twice a month. However in real world scenario new deals are inserted all the timeand therefore index maintenance would play bigger role.

• There was dilemma on how to find true query execution time. DB2 Timespent interface was choseninstead of running python script or JMeter test plan in an effort to solely concentrate only on DB2process without depending on other frameworks.

• Indices were not fully operational until reorg and runstats commands were called in:

REORG TABLE db2inst1 . ho t e l ALLOW NO ACCESS;REORG INDEXES ALL FOR TABLE db2inst1 . ho t e l ALLOW NO ACCESS;RUNSTATS ON TABLE db2inst1 . ho t e l AND SAMPLED DETAILED INDEXES ALL;

• When performing export using IXF format I noticed that ntfs-3g process is taking about 75% processortime and whole export procedure was taking over 16 minutes on average. However this flaw did notaffect export in DEL format. Execution time was the same when file was saved to EXT4 and NTFS.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P TIME COMMAND730 root 20 0 17316 1620 756 S 73 0 .0 34 : 55 . 35 0 34 :55 mount . nt f s−3g

File was saved in a partition which uses NTFS, so I switched working directory to a path in EXT4 filesystem partition. After the switch export procedure execution time dropped to just over 2 minutes.

• Export execution time was measured using Unix Time tool.

time db2 −t f export . s q l

• Timespent query was written to export all statements that occurred during a test in order to analyzereading/writing time, lock waiting time, number of physical page read information and etc.

export to wa i t e r s . csv o f de l s e l e c tsubs t r ( stmt_text , 1 , 600) stmt_text ,stmt_exec_time ,total_act_wait_time ,lock_wait_time ,log_buffer_wait_time ,log_disk_wait_time ,fcm_recv_wait_time ,fcm_send_wait_time ,pool_read_time ,pool_data_p_reads ,pool_index_p_reads ,pool_write_time ,direct_read_time ,direct_write_time

from tab l e (mon_get_pkg_cache_stmt ( ’ d ’ , nu l l , nu l l ,−1)) as xorder by stmt_exec_time desc ;

13