P. 1
Testing to Destruction

Testing to Destruction

|Views: 85|Likes:
Published by Michael Ault
A presentation on using simulated workloads from actual applications to test new system configurations in Oracle.
A presentation on using simulated workloads from actual applications to test new system configurations in Oracle.

More info:

Categories:Types, Speeches
Published by: Michael Ault on Jun 24, 2010
Copyright:Attribution Non-commercial
List Price: $3.00 Buy Now

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
See more
See less

07/09/2013

$3.00

USD

pdf

text

original

TESTING TO DESTRUCTION ± PERFORMANCE TESTING YOUR ORACLE SYSTEM

Michael R. Ault, Quest Software

Engineering is not merely knowing and being knowledgeable, like a walking encyclopedia; engineering is not merely analysis; engineering is not merely the possession of the capacity to get elegant solutions to non-existent engineering problems; engineering is practicing the art of the organized forcing of technological change... Engineers operate at the interface between science and society...

Dean Gordon Brown

Introduction
In this paper we will examine the basis for predictive modeling when dealing with databases. The types of things that we need to predict when dealing with databases deal with operating system memory needs, operating system CPU needs and operating system storage requirements. The analysis may be as simple as answering the question ³When will this table run out of space´ or as complex as ³How many CPUs will be required to support this database when the data has increased by a factor of 20 in size and user load has been increased ten fold´. In order to accurately model databases to allow us to predict future needs based on current trends we must be able to control two specific parts of the database environment: y User load y Transaction mix If you can not control the users or the transactions impacting the database then it becomes impossible to accurately predict the trends. However, if we are concerned with average loads and normal data growth then we must ensure that the transaction mix and user load when we do our measurements is ³normal´ if we don¶t know what a normal load is our efforts will probably result in inaccurate forecasts based on biased trends. One way to completely control both the users and the transaction load is to utilize benchmarking tools. In the next section of this chapter we look at the benchmark tools you can utilize to perform accurate trend analysis and prediction.

www.rmoug.org

RMOUG Training Days 2007

Testing to Destruction

Ault

Trend identification with benchmark tools
If all that benchmarking tools did were standard canned benchmarks, they would be of limited use for trend analysis. Top of the line tools such as Benchmark Factory from Quest provide utilities that allow the reading of trace files from databases such as Oracle and the entry of SQL statements to test transactions for other database systems. In addition the tools should allow for the specification of multiple user scenarios so that insert, update, delete as well as select transactions can be modeled. Let¶s take a look at a test case to determine if a particular set of transactions, specifically data manipulation language (DML) transactions to the base tables for an Oracle materialized view ( a materialized view is a ³instantiated´ view, that is, a view that is used to create and maintain an actual physical table so that its records stay in sync with its base tables) have an effect on the number of users that can select from the view as well as how many users can perform DML operations while users are performing selects against the materialized views.

Testing a Suggested Architecture
One of the suggested architectures to allow for rapid reporting without stressing the base tables is to use partitioned, refresh on commit, materialized views within Oracle. It is hoped this test will help show the affects of user load on such an architecture. In order to test this architecture the Quest Benchmark Factory was utilized with two GUI installations; one to do the INSERT into the base tables, the other to perform the SELECT activity against the refresh on commit materialized view. The testing was performed in three phases:

Phase 1:
In phase one both the INSERT and SELECT potions of the test were cycled simultaneously from 1-60 users in 5 user increments on the INSERT side and 1-30 users in 5 user increments on the SELECT side.

Phase 2:
In phase two the INSERT side was cycled from 1-60 users in 5 user increments until the response time exceeded 6 seconds while the SELECT side was run at a single constant user level during individual INSERT runs. The SELECT side was run at constant user levels of 5, 10 and 20 users during the INSERT tests.

Phase 3:
In phase 3 the materialized view was recreated as a single table and the constant user level of 20 for SELECTs was used to test the difference between use of partitions and single tables.

All Phases:
In all phases the SALES table was used for the update target with ON COMMIT processing for the materialized views causing selects from all the base tables in the PUBS schema (SALES, AUTHOR, BOOK, AUTHOR_BOOK, PUBLISHER, STORE) to publish data into the MV_AUTHOR_SALES materialized view. In Oracle ON COMMIT processing means just that, whenever there is a commit on the base tables, the effected materialized view records are updated, inserted or deleted. Prior to each test the MV_AUTHOR_SALES materialized view and the SALES table were both truncated.

System Information:
The test system consisted of two laptops each configured with the Benchmark Factory utility. Laptop 1, a VIO PCGGRT250P with 1 gigabyte of memory and a 2.8 Ghz Pentium IV processor and a 1 GigaBit Ethernet card was used for running the INSERT processing. Laptop 2, a Gateway 9300 with a 400 Mhz PII processor and 700 Megabytes of memory with a 100 Megabit Ethernet card was used for the SELECT processing. The database server is a Redhat Linux based 3.0 Ghz Pentium IV with hyperthreading and 2 Gigabytes of memory running Oracle Enterprise 10gR2 10.1.0.3 release. The server is direct attached through Fast-Wide SCSI to an 8 disk NStore disk array using all 8-19 Gigabyte 10K rpm drives in a RAID5 array. This architecture is shown in Figure 1.

www.rmoug.org

RMOUG Training Days 2007

Testing to Destruction

Ault

1-60 User Inserts in 5 User Increments

Benchmark Factory VIO using ODBC Gateway using SQLNet VIO processing INSERT Gateway Processing Select VIO PCG-GRT250P Ethernet 1 GBit Line 1 GBit Line Gateway 9300

5 user Selects 10 User Selects 20 User Selects

100 MBit Line

RedHat OS 10.1.0.3 Oracle Enterprise Single 3 Ghz Hyperthreaded CPU 2 Gigbytes Memory

Minicomputer Fast-Wide SCSI

NStore 8 Disk RAID 5 Array 8-19 Gig 10K RPM Drives

HFDW

PUBS Schema MV_AUTHOR_SALES materialized view either 12 monthly partitions Or single Table

Figure 1: Test Architecture

Database Objects
The database utilizes a base set of tables, SALES, AUTHOR, BOOK, AUTHOR_BOOK, STORE and PUBLISHER. These tables are used to create a REFRESH-ON-COMMIT materialized view constructed on top of an existing partitioned table. Details of Materialized View: The script used to create the materialized view base table is shown in Figure 2.
drop materialized view mv_author_sales; drop table mv_author_sales; truncate table sales; CREATE TABLE mv_author_sales PARTITION BY RANGE (order_date) (PARTITION p1 VALUES LESS THAN (to_date('012002','mmyyyy')), PARTITION p2 VALUES LESS THAN (to_date('022002','mmyyyy')), PARTITION p3 VALUES LESS THAN (to_date('032002','mmyyyy')), PARTITION p4 VALUES LESS THAN (to_date('042002','mmyyyy')), PARTITION p5 VALUES LESS THAN (to_date('052002','mmyyyy')), PARTITION p6 VALUES LESS THAN (to_date('062002','mmyyyy')), PARTITION p7 VALUES LESS THAN (to_date('072002','mmyyyy')), PARTITION p8 VALUES LESS THAN (to_date('082002','mmyyyy')), PARTITION p9 VALUES LESS THAN (to_date('092002','mmyyyy')), PARTITION p10 VALUES LESS THAN (to_date('102002','mmyyyy')), PARTITION p11 VALUES LESS THAN (to_date('112002','mmyyyy')), PARTITION p12 VALUES LESS THAN (to_date('122002','mmyyyy')), PARTITION p13 VALUES LESS THAN (MAXVALUE)) as (Select d.order_date, a.rowid idrowa, b.rowid idrowb, c.rowid idrowc, d.rowid idrowd, e.rowid idrowe, f.rowid idrowf, a.author_last_name, a.author_first_name,f.pub_name, a.author_contract_nbr, e.store_state,d.quantity From author a, book_author b, book c, sales d, store e, publisher f Where a.author_key=b.author_key And b.book_key=c.book_key And c.book_key=d.book_key And e.store_key=d.store_key and c.pub_key=f.pub_key) / create index mv_rida on mv_author_sales(idrowa); create index mv_ridb on mv_author_sales(idrowb); create index mv_ridc on mv_author_sales(idrowc); create index mv_ridd on mv_author_sales(idrowd); create index mv_ride on mv_author_sales(idrowe);

www.rmoug.org

RMOUG Training Days 2007

"B115". f. The SELECT transaction was designed to fully access the materialized view placing the most stress on the view as possible. b."S105"."B108"."B102". Create materialized view mv_author_sales on prebuilt table Refresh on commit as Select d. The SALES table formed the base of the materialized view MV_AUTHOR_SALES so the INSERT transaction focused on inserts into the SALES table.author_first_name.author_last_name."S103"."B112". The script to create the materialized view is shown in Figure 3."B103".order_date. Insert Transaction: INSERT INTO sales VALUES ( '$BFRandList("S101".author_key And b.author_first_name.book_key And e.rowid idrowd.book_key And c.pub_name."B106"."S107". The dynamic sampling feature of 10g was utilized to maintain statistics for the test since the table and materialized view were growing during the entire test period for each test.'mm/dd/yyyy').pub_key / Figure 3: Materialized View Creation Script After creation and refresh the MV_AUTHOR_SALES and SALES tables we analyzed using a command similar to: dbms_stats. the materialized view was defined on the existing table.author_first_name. Transaction Details: Two basic transactions were utilized to test the affect of locking on the INSERT and SELECT activities."B109".f. Select Transaction: SELECT to_number(to_char(order_date.pub_key=f.'MV_AUTHOR_SALES'.rmoug."S103". e."B104"."B111".quantity From author a. 'O'||to_char(order_number."B105". a.rowid idrowc. Figure 2: Script to Create Partitioned Table Once the base table was created. The inserts into the SALES table force the materialized view refresh (REFRESH-ON-COMMT) to select records from all of the base tables. book c."B107"."S110")'."S108".rowid idrowb.store_key and c.cascade=>true).d. e. The following Benchmark Factory function scripts where used to populate random values into the INSERT statement: y y y $BFRandList ± Insert one of the provided list into the statement at this point with frequency based on the provided integer (³val´:f) if no integer is provided."B116")'.store_state.org RMOUG Training Days 2007 .rowid idrowe. book_author b. sales d. use 1.rowid idrowa.gather_table_stats('PUBS'. a.author_key=b. c. Using the INSERT with the Benchmark Factory script functions provided a distribution of values similar to the following example distribution in all the tests.rowid idrowf. $BFRandRange ± Insert a random integer in the range specified. '$BFRandList("B101". store e. www.book_key=c. "S109"."S104".sum(quantity) FROM mv_author_sales GROUP BY to_number(to_char(order_date.author_last_name."B11 3".100)). d. to_date('$BFDate("01/01/2002".book_key=d. $BFDate ± Insert a random date in the range specified.'mmyyyy')) month_of_sales.author_contract_nbr. publisher f Where a.store_key=d."B110".a.Testing to Destruction Ault create index mv_ridf on mv_author_sales(idrowf).author_last_name.nextval)."S106". $BFRandRange(1."12/31/2002")'."B114". a.'mmyyyy')).

interations loop insert into perm4_object_locks select sysdate. dba_objects b where a.-------------MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 3 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 The INSERT side of the test results are shown in Figure 5. end loop. 25. for I in 1. end.org RMOUG Training Days 2007 . commit.object_id=b.object_name. Lock profile for MV_AUTHOR_SALES materialized view: MEAS_ ----21:10 21:11 21:12 21:13 21:14 21:17 21:18 21:19 21:21 21:22 21:23 21:25 OBJECT_NAME SUM(NUM_LOCKS) --------------.rmoug.sleep(4). dbms_lock.. I integer. Figure 4: Lock Monitoring Procedure The locking was monitored at 4 second intervals and the results for Phase 1. 10. www. b. begin interations:=floor(tim_in_min*60/4)+1. 5. 30) and 1-60 users in inserts in 5 user increments.count(*) from v$locked_object a. Phase 1: Both Insert and Select Varying In phase one. Create or replace procedure get_locks(tim_in_min number) as interations number. 15.object_id and object_name!=¶PERM4_OBJECT_LOCKS¶ group by object_name. both Benchmark Factory tests were made to scale.Testing to Destruction Ault PARTITION COUNT(*) --------. During testing locks were monitored using the procedure shown in Figure 4. From 1-30 users for selects in 5 user increments (1. 1-30 User SELECT processes in 5 user increments versus INSERT processing at 1-60 users in 5 user increments. 20.---------012002 831 022002 765 032002 805 042002 799 052002 885 062002 788 072002 896 082002 864 092002 871 102002 843 112002 888 122002 857 The next sections show the results from the three phases of testing.

004 .org ¢¡  Figure 5: Results for INSERT Test RMOUG Training Days 2007 .306 6.133 3.Testing to Destruction Ault General Information Run Information Test Run Id Start Time Comment Profile Information Profile Name Driver Data Source Name User Name Password Test Information Name: Test Type: Test Id: Overall Results Test Userload Phase 1 5 10 15 7 / / : Status Stop Time / / : ****** < x Version Avg Time 165 1.rmoug.02 2.535 3.143 90th Time 13 1.922 11.361 5.24 Max Time 16 3.993 3.684 Min Time ( ) TPS 1 1 1 1 4 41 3.534 7 6 5 4 TPS 3 2 1 0 0 5 10 U s e r lo a d 15 20 Insert Response Time 8 7 Second 6 5 4 3 2 1 0 1 5 10 15 Insert RT Insert Processes www.534 1.377 22.

298 0.565 2.829 1.23 0.org RMOUG Training Days 2007  ©¨ ¦ Select esponse ime ¥¤£ § 10 8 6 4 .672 6.84 0.575 0.64 0.04 16.457 1.09 ¥¤£ 18 16 14 12 2 0 0 5 10 15 20 25 30 35 U se rlo a d 2 1.556 1.6 1.274 1.014 2.42 15. General Information Run Information Test Run Id Start Time Comment Profile Information Profile Name Driver Net Service Name Tablespace User Name Password Test Information Name: Test Type: Test Id: Overall Results User Test load Phase 1 1 5 1 10 1 15 1 20 1 25 1 30 1 11 Status 3/10/2006 21:01 Stop Time 1-30 5 2 3/10/2006 21:29 ****** x x 2 (1-30 Version Avg Time 0.67 16.rmoug.4 1.Testing to Destruction Ault The results for the SELECT test of Phase 1 are shown in Figure 3.594 0.8 0.758 3.469 TPS 3.935 1.346 0.8 1.392 90th Time 0.6.393 0.4 0.2 0 1 5 10 Select 15 20 25 30 Select ocesses Second Figure 6: Select Test Results www.401 0.923 5) 4 Max Time 0.2 1 0.862 Min Time 0.6 0.916 2.04 13.005 1.69 12.676 1.334 0.116 1.627 2.34 8.

15.993 3. The TPS and response time for the SELECT processes were recorded at each user level for each upward increment in the number of INSERT processes to gauge the affect of increased locking on the SELECT processing. 30 INSERT operations at 4-5 minute interval ramp recorded >3 sec response at 20 users.888 3.37 25 1 5.517 2.262 7.97 3.471 30.699 1. 5. However.439 10.01 4.798 3.243 20 1 5. General Information Run Information Test Run Id Start Time Comment Profile Information Profile Name 2 Driver Data Source Name User Name Password ****** Userload Test TPS Avg Min Time Max Time 90th Time Phase Time 1 1 5.978 10 1 4.rmoug.672 30 1 4.43 3.172 0. >6 sec response at 30 users test was halted when insert processing reached >6 seconds transaction time.699 4.82 6. the affects are hard to characterize when both INSERT and SELECT processes are varying. 5 concurrent SELECTS With 1.287 0.) In Phase 2 testing the number of SELECT user processes is kept at constant values while the number of INSERT processes is increased in 5 user intervals until response time increase above 6 seconds. 25.79 0.29 0.org RMOUG Training Days 2007 .795 0.898 9.32 2.23 4.358 78 3/11/2006 20:50 5 Status Stop Time 3/11/2006 21:19 www. 10 and 20 were used. SELECT user levels of 5.113 0.732 15 1 5.56 2.602 5. 20.Testing to Destruction Ault Phase 1 Results Summary The results show that the locking affects INSERT processing resulting in the average time for inserts to increase to greater than 6 seconds within 15 user processes while SELECT processing shows little affect other than that which can be expected from the materialized view table size increase. Phase 2: SELECT transaction level constant In Phase 2 the transaction levels for SELECTs will be held at constant levels (5.10.572 5.681 2. The results for the INSERT processing are shown in Figure 7.20).315 1.225 5 1 6. and we will check TPS and response for Inserts ( levels 1-60 or where Response >6 sec.675 0. 10.

Testing to Destruction Ault TPS 7 4 TPS Us e r lo a Insert Response Time 7 6 Seconds 5 4 3 2 1 0 1 5 10 15 Select Users 20 25 Insert R Figure 7: Results from 5 Select processes on Inserts The resulting lock profile from the inserts is shown in Figure 8.org  Insert Processes             4 30 RMOUG Training Days 2007 .rmoug.-------------MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 1 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 www. MEAS_ ----20:50 20:51 20:52 20:53 20:54 20:55 20:56 20:58 20:59 21:00 21:01 21:02 21:03 21:04 21:05 21:06 21:07 21:08 21:09 21:10 21:11 21:12 21:13 OBJECT_NAME SUM(NUM_LOCKS) --------------.

369 4.rmoug.996 12.547 20 1 4. 15.org "! RMOUG Training Days 2007 . General Information Run Information Test Run Id Start Time Comment 73 3/11/2006 18:59 10 Status Stop Time 3/11/2006 19:28 Profile Information Profile Name 2 Driver Data Source Name User Name Password ****** Userload Test TPS Avg Min Time Max Time 90th Time Phase Time 1 1 5. 20.02 0.837 20.774 9. 25.183 0. The results for the INSERT processing are shown in Figure 9.07 7.723 4.858 25 1 4.639 "! 7 6 5 4 3 2 1 0 0 10 20 Us e r lo a d 30 40 www.814 1.013 3.238 5 1 6.753 40.287 15 1 5. 5.4 5.Testing to Destruction Ault 21:14 21:15 21:16 21:17 21:18 MV_AUTHOR_SALES MV_AUTHOR_SALES MV_AUTHOR_SALES MV_AUTHOR_SALES MV_AUTHOR_SALES 4 5 2 2 6 Figure 8: Lock Profile for Test 10 concurrent SELECTS With 1.946 5.83 0.043 2.51 1.077 2. 30 INSERT operations at 4-5 minute interval ramp recorded >3 sec response at 20 users.688 1.12 2.93 1.881 30 1 4.293 0. 10. >6 sec response at 30 users test was halted when insert processing reached >6 seconds transaction time.44 0.9 4.678 3.118 0.203 3.543 2.006 10 1 5.626 7.

MEAS_ ----18:59 19:00 19:02 19:04 19:05 19:06 19:07 19:08 19:09 19:10 19:12 19:13 19:15 19:16 19:18 19:19 19:20 19:21 19:22 19:24 19:25 19:26 19:27 OBJECT_NAME SUM(NUM_LOCKS) --------------. 15. 10.rmoug.org ( & ) '% # $ 5 10U RMOUG Training Days 2007 .-------------MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 8 MV_AUTHOR_SALES 5 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 Figure 10: Lock Profile for Test 12 concurrent SELECTS With 1. 25 INSERT operations at 4-5 minute interval ramp recorded >3 sec response at 15 users. The results for the INSERT processing are shown in Figure 11. 5. www. >6 sec response at 25 users test was halted when insert processing reached >6 seconds transaction time. 20.Testing to Destruction Ault n sert R es o n se T im e 8 7 6 Secon s 4 3 2 1 0 1 5 10 15 20 0 Select U sers Ins 25 30 n se rt Proce sse s Figure 9: Results from 10 SELECT Users on INSERTs The resulting lock profile from the inserts is shown in Figure 10.

93 3.122 1.168 25 1 3.277 10.org 1 2 0 4 RMOUG Training Days 2007 .992 2.214 2.249 5 1 6.032 10 1 5.12 0.042 2.929 9.491 3.4 1.015 31.027 5.418 2.86 6.rmoug.296 15 1 4.53 4.02 0.43 3.115 1 2 0 7 6 5 3 2 1 0 0 5 10 15 U s e r lo a d 20 25 30 Insert Response Time 20 Select Users 7 6 Seconds 5 4 3 2 1 0 1 5 10 15 20 25 Insert RT 20U Insert Processes Figure 11: Results from 20 SELECT Users on INSERTs www.93 5.Testing to Destruction Ault General Information Run Information Test Run Id Start Time Comment 76 3/11/2006 19:51 20 Status Stop Time 3/11/2006 20:16 Profile Information Profile Name 2 Driver Data Source Name User Name Password ****** Userload Test Phase TPS Avg Min Time Max Time 90th Time Time 1 1 5.829 0.195 0.47 4.852 1.52 0.123 0.613 20 1 4.

MEAS_ ----19:52 19:53 19:55 19:56 19:57 19:58 20:00 20:01 20:02 20:04 20:05 20:07 20:08 20:09 20:11 20:13 20:14 OBJECT_NAME SUM(NUM_LOCKS) --------------.order_date. mv_author_sales(idrowd).d. The scripts used for this test are shown in Figure 13. f. mv_author_sales(idrowb).book_key and e.author_contract_nbr. b. sales d.Testing to Destruction Ault The resulting lock profile from the inserts is shown in Figure 12.-------------MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 6 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 4 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 8 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 Figure 12: Lock Profile for Test Phase 2 Summary Over all the Phase 2 testing shows that locking has little or no affect on SELECT operations while the number of SELECT processes has an affect on the number of INSERT processes capable of operating with a less than 6 second response time and the number of TPS that can be processed for that user level.author_key and b. CREATE TABLE mv_author_sales as (Select d.book_key=d.org RMOUG Training Days 2007 .rowid idrowf. c. book_author b. www.author_first_name. a.rowid idrowd.rowid idrowe. mv_author_sales(idrowc).quantity From author a. f. e. publisher f Where a.author_key=b.rowid idrowc.store_state.book_key=c. book c.book_key and c. e.store_key=d. a.pub_key) create create create create create index index index index index mv_rida mv_ridb mv_ridc mv_ridd mv_ride on on on on on mv_author_sales(idrowa). mv_author_sales(idrowe).pub_key=f.store_key and c.rmoug.author_last_name. a. d.rowid idrowb.pub_name.rowid idrowa. a. store e. Phase 3: Materialized View with No Partitions In Phase three the affect of utilizing a single base table verses using multiple partitions at the maximum number of SELECT processes (20) is measured.

author_contract_nbr.org RMOUG Training Days 2007 .919 1.book_key And c.975 3.rowid idrowe.author_key=b.store_state.287 2.9 25 1 4.rowid idrowc.quantity From author a.cascade=>true). c.pub_name.963 9.857 5 1 5.203 4.rowid idrowd.'MV_AUTHOR_SALES'.96 0.gather_table_stats('PUBS'. Create materialized view mv_author_sales on prebuilt table Refresh on commit as Select d.book_key And e.97 3.store_key=d.663 5.838 0.394 3.book_key=d.a. General Information Run Information Test Run Id Start Time Comment 79 3/12/2006 11:13 . book c.199 0. Figure 13: Scripts Used to Create Single Table Materialized View The Phase 3 results for the INSERT processes are shown in Figure 14.18 5.rowid idrowa.143 www.pub_key=f. book_author b.art table 20 Status Stop Time rrent 3/12/2006 0:02 Profile Information Profile Name aultdb2 Driver Data Source Name User Name ubs Password ****** Test Information Name: esponse < 6000 s (1-60 by 5) Test Type: xed orkload atabase est Test Id: 5 Version 12 Test Avg Min Max Userload Phase TPS Time Time Time 1 1 5 0.7 15.499 2.947 20 1 4.206 4.f.136 8.author_first_name. store e.store_key and c.66 8.033 2.114 0.author_key And b. f.pub_key / Truncate sales and mv_author_sales exec dbms_stats. e.881 25.935 90th Time 0.744 66.rowid idrowb. a.rowid idrowf. e.017 2. a.745 30 1 3. d. b.671 10 1 5. publisher f Where a.d.author_last_name. a.book_key=c.Testing to Destruction Ault create index mv_ridf on mv_author_sales(idrowf).21 1.221 15 1 4.rmoug.66 4.08 4.254 1. sales d.order_date.

Testing to Destruction Ault TPS 7 6 5 4 TPS 3 2 1 0 0 5 10 15 U s e r lo a 20 25 30 Insert Response T e 20 Select Users No Partitions 10 Seconds 8 6 4 2 0 1 5 10 15 20 25 30 Insert Processes Insert RT 20U NP Figure 14: Results from 20 SELECT Users on INSERTs with No Partitioning The resulting lock profile from the inserts is shown in Figure 15.org 3 RMOUG Training Days 2007 . TIME ----11:33 11:35 11:36 11:37 11:38 11:40 11:41 11:42 11:43 11:44 11:45 11:46 11:48 11:49 11:50 11:51 11:53 11:55 11:56 11:57 11:58 OBJECT_NAME NUM_LOCKS ---------------.rmoug.---------MV_AUTHOR_SALES 1 MV_AUTHOR_SALES 3 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 3 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 1 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 3 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 1 MV_AUTHOR_SALES 1 MV_AUTHOR_SALES 1 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 3 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 1 MV_AUTHOR_SALES 1 MV_AUTHOR_SALES 2 MV_AUTHOR_SALES 1 www.

20 SELECT Users and the 20 SELECT users with no partitions test results.org 6 76 8 9 58 5 4 B A @ 10 5 0 1 5 10 15 n 20 25 30 5 select TPS 10 Select TPS 20 Select TPS 20 Select TPS (NP) RMOUG Training Days 2007 .---------012002 786 022002 692 032002 733 042002 737 052002 810 062002 722 072002 828 082002 803 092002 803 102002 781 112002 824 122002 780 12 rows selected. The INSERT processing affects may be mitigated by changing how rows are stored in the table such as by large PCTFREE allocations limiting the rows per block.rmoug. In the first graph we examine the affect on transactions per second (TPS). ORDER COUNT(*) -----. Figure 16: Inserted Value Distribution Phase 3 Summary Phase 3 shows that while partitions are good for SELECT processing they may have a slightly detrimental affect on INSERT processing. Combined Results It is easer to see the affects of the increasing number of SELECT processes by combining the results from the various tests into a series of graphs. Con 25 20 15 an Nu b Figure 17: Combined TPS Results www. Notice how the performance for the 20 SELECT user no partitions TPS is less than for the 20 SELECT user partitioned results. 10.Testing to Destruction Ault 11:59 12:00 12:01 12:02 MV_AUTHOR_SALES MV_AUTHOR_SALES MV_AUTHOR_SALES MV_AUTHOR_SALES 3 1 3 1 Figure 15: Lock Profile for Test The total row count for the single table test was 9299 vice 10092 in the partitioned testing (on the average.) The distribution of the values in the single table is shown in Figure 16. Figure 17 shows the combined TPS graphs for the 5. All of the other results show the affect of the increase stress of the SELECT processing on the INSERT users and the lack of affect of the INSERT processes on the SELECT users.

2 0 1 5 10 15 20 25 30 Insert Processes 5 Select RT 10 Select RT 20 Select RT 20 Select RT (NP) Figure 18: Combined Response Time Results Figure 19 shows the combined results for the INSERT processing TPS as the SELECT user loads remained constant at the 5. Again in Figure 20 we see that for the INSERT processing the response times for the 20 user non-partitioned SELECT user load we see slightly better response times.Testing to Destruction Ault In the next figure.rmoug.2 Seconds 1 0. 10 and 20 SELECT user level and 20 SELECT users with no partitioning.) In Figure 18 we can see that after an initial drop off. the results from the response times for the SELECT processes as the number of INSERT processes increased a is shown for each of the constant process levels (5.4 1.10.20 and 20 with no partitioning.8 0.4 0. Insert TPS 7 6 5 TPS 4 3 2 1 0 1 5 10 15 20 25 30 TPS TPS TPS TPS 5 10 20 20 NP Insert Processes Figure 19: Combined Insert TPS Results Figure 20 shows the affects of the varying SELECT user loads on INSERT process response times. Figure 18. the response times showed only marginal reductions which can probably be accredited to the increasing size of the materialized view.org RMOUG Training Days 2007 . In Figure 19 we see that for insert processing the TPS for the 20 user non-partitioned table was slightly better than for that of the 20 user partitioned table. www. Constant Select Response Times 1.6 0.

has little affect on SELECT processing since with Oracle¶s single row (fine grained) locking model and multi-block concurrency model readers will not be blocked by writers and writers will not be blocked by readers. First let¶s look at the architecture we will be testing. The Oracle database was at release 9. For our example we will use an actual user test case. the partitions may have a slightly negative affect on TPS and response time. then project based on your criteria what hardware will be needed. In this section we have seen an example of utilizing a benchmarking tool to see if a particular architecture was correct for our application and checking to see how our application would scale on a particular hardware setup. version 9. Recommendations Based on the data in this report it is recommended that partitioned materialized views using the REFRESH ON COMMIT refresh mechanism should be used to reduce the strain on the underlying OLTP based tables when the same database instance is used in OLTP and reporting. Planning Future Hardware & Software Needs Projecting future hardware and software needs requires you to establish what the current hardware is capable of. these results show that locking. at least at the single row per transaction level. as expected. It also shows that using the REFRESH ON COMMIT materialized views should not adversely affect INSERT or SELECT processing. In this test case we have been tasked with determining for a production server with 20 times more data the number of CPUs and Memory that will be required to give performance comparable to that we currently experience. www. the benefits of their use outweigh the potential down sides.rmoug.2. Architecture This test was performed using a SUN 480R 2-900 MHz CPU based system utilizing the Solaris 2.org F D n s e rt R e s o n s e T im e E C H G 15 20 25 30 RT RT RT RT 5 10 20 20 NP ro ce sse s RMOUG Training Days 2007 .9 64 bit architecture with 4 gigabytes of memory.2. While using partitioned materialized views shows a slight increase in response times on INSERTS.0. Also the tests seem to indicate that for SELECT processing using partitions is beneficial but for INSERT processing. The architecture diagram is shown in Figure 21.Testing to Destruction Ault 9 8 7 6 5 4 3 2 1 0 1 5 econ s 10 n se rt Figure 20: Combined Insert Response Results Combined Results Summary Again. But how can we determine if a particular hardware setup is correct? In the next section we show an example of the use of a benchmark tool to determine projected hardware needs based on user load and projected data size.1 and was being served by an EMC disk array.

1 Apache Webserver Sun Switch EMC EMC Disk Array (Clarrion shown. The testing was accomplished in three phases: Phase 1: In Phase 1 only issues queries were utilized to perform a SQL scalability test. so for purposes of brevity they will be omitted.org Q PI un ire 480 RMOUG Training Days 2007 . we don¶t need to include phases 2 and 3. ³keyboard´ or other delays were programmed into the scenario. The server memory configuration was not able to be adequately tuned due to the limitations of a shared environment.rmoug. NOTE.0.Testing to Destruction Ault Su n F ire V 2 1 0 Sun Switch Sunfire 480 Solaris 2. using 1. so there are some physical IOs which occur that would not have happened or would have been greatly reduced in a properly tuned environment. an issues type query set and a parts type query set. A basic template for each of the queries was provided by site personnel and the Benchmark Factory provided scripts were utilized to insert random values into the queries to generate the query loads. Limitations and Caveats The testing described in this session was performed on a shared system where the team had no control over what other teams were doing on the server. I Phase 1 operating system statistics and statspack were used to collect additional statistics.9. transactions and bytes per second that would not be present in an isolated testing environment. therefore there are variations in transactions per second. The random values used in the tool where selected from the test database instance to provide for a varying load for each type of query presented.2.7 gigabytes of space. Two general types of queries were tested during this time period. actual EMC type not known) Database allocated 4. 2006. Each user was able to run any of the six queries at any time and no ³think´. www. The Benchmark Factory tool from Quest was utilized to simulate loads against the test database for various user loads and queries similar to those that will be generated by the reporting system against the database during normal operations. For the purposes of this example. In Phase 1 the user load was ramped in 6 user increments from 6 users to a maximum of 84 users.9 2-900 Mhz CPU 4 Gigabytes Memory Oracle9i .2 gigabytes EMC EMC EMC Figure 21: Test Architecture Test Summary Performance testing against the test table in the test database instance was accomplished during the period April 3 ± April 7.

Testing to Destruction Ault Oracle9i Release 2 was used for the test environment. Transaction Times for Issues Tests The transaction times provided by the various forms of the Issues query are shown in Figure 21 by user load. the PRODUCTs shown in Table 2 were utilized by Benchmark Factory to randomize the queries.org RMOUG Training Days 2007 . www. The user load was ramped from 6 to 84 users (note that at 78 users the system would begin giving resource related errors and refuse further connections. At any time during the test a user process would be executing a query using any of the above values. USER GEORGEB FRANKL MIKER SAMMYJ BILLYB OZZYO Issue Count 230 225 2673 417 460 354 Table 1: Users and Issue Counts The PRODUCT was also used to help randomize the query results. there are several bugs in release two which caused Ora-00600 and other errors when large numbers of bind variables were utilized.) Randomization of the Issues Queries In Phase 1 the queries utilized by the Benchmark Factory to test the Issues table were randomized using the user identifiers from the list of users and issues shown in Table 1.rmoug. the bind variables were considered ³unsafe´ (such as to replace a string value in a LIKE statement) and CURSOR_SHARING is set to SIMILAR. providing a random number of return values for each unique query. PRODUCT RADIOX RADIOY DVDPX CDPY CAMCDR1 CAMCDR2 VCRX Issue Count 3172 1479 1210 7880 3187 2270 1510 Table 2: Products and Issue Counts The FINISHED column had the values of either NULL or µLATE¶ so both of these conditions were utilized in various queries. Phase 1: Issues Query Testing Phase 1 is a standalone test of the Issues queries.

25 154.5 390. Average Transaction Times The combined average transaction times are shown in Figure 22. on the average.5 96.25 93.75 99. User Load Id and product Id and late 48.75 243.5 62.5 75.25 Table 3: Average Transaction Time in Milliseconds by Query As you can see.25 295.25 ID and Product and Late is null 22.25 38. www.5 733.75 81.5 373.org R T ra n s a c tio n T im e y S u e ry id_and_product Id_and_late ID_and_product_and_late ID_and_late_is_null ID_and_Product_and_Late_is_null just_ID 1 0.5 401 402.5 ID and product and late 29.25 73.5 97 Just ID 6 12 18 24 30 36 42 48 54 60 66 72 78 228.25 255.75 338.25 27.5 81.5 739 874 906.25 347.5 89 96. however.25 63.25 686.75 60. all of them.25 353.75 1 1 1.25 39.75 569.5 ID and late is null 18.5 377.75 55 54.5 38.rmoug.75 77.5 77.75 442 543. are less than the specified maximum performance limit of 3 seconds.5 264.75 227.75 79.5 695.5 44.5 498 498.25 1 1 1 1 1 1 1 1 RMOUG Training Days 2007 .75 723. the various forms of the query provided for widely varying transaction times.5 66.5 622.25 45.Testing to Destruction Ault 1200 1000 Millisecond 800 600 400 200 0 0 10 20 30 40 50 60 70 80 90 Userload Figure 21: Graph of Transaction Times by Query by User Load The data used to plot the graph in Figure 21 was averaged over several 78 user runs in Phase 1 and is shown in tabular form in Table 3.25 404.5 964.75 220 259.75 82.5 116.75 126.25 25.

either at the OS or Oracle level is undergoing throttling actions. www. however due to the memory issues on the test server we were unable to attach enough users to reach this turnover point. Usually you can tell when a server has reached capacity by the down turn in the TPS verses user load graph. Response Time 0. otherwise called throughput.rmoug.1 0. Figure 23 shows the average response times for all three phase 1 tests. Another important metric is the average response time.org T V U Avg Tim e 90th Tim e Avg Tim e 90th Tim e Avg Tim e 90th Tim e Avg Response Time 90th Response Time Avg Response Time 90th Response Time Avg Response Time 90th Response Time RMOUG Training Days 2007 .25 0.15 0.Testing to Destruction Ault T ransaction T ime 100 10 1 0. Another interesting issue with the TPS graph is the indication that the system.2 Seconds 0. while the response time is the time required to return the first part of the result set to the user. notice the odd down turn at around 18-24 users in the TPS graphs for two of the test in Figure 24.1 0.01 0 10 20 30 40 Us e r lo a 50 60 70 80 90 eco n s Figure 22: Graph of Average and 90th Percentile Transaction Times Figure 22 shows that the average transaction time over all transactions per test level in each of the three phase 1 tests did not exceed 3 seconds. In a query the transaction time is the time required to generate the full transaction set.05 0 0 10 20 30 40 Userload 50 60 70 80 90 Figure 23: Average and 90th Percentile Response Times The final query metric is transactions per second.

rmoug.instance_number. In Oracle10g this data is readily available from the DBA_HIST_SYSSTAT table by utilizing a query similar to that showed in Figure 25.snap_id order by a. this is due to the variances in server availability because of the shared user environment and makes it difficult to accurately predict overall performance for scaling purposes.stat_name='session logical reads' and a.begin_interval_time / spool off set numwidth 10 pages 22 Figure 25: Example DBA_HIST Query First. physical reads and then examining the breakdown of physical reads between table scans (scattered reads) and index driven ROWID lookup reads (sequential). Database Activity Database activity levels can be shown by looking at logical reads.value from dba_hist_snapshot a.instance_number. b. col meas_date format a19 set pages 0 numwidth 12 spool logical_reads_q2 select a.'yyyymmdd hh24:mi') meas_date.Testing to Destruction Ault 350 300 T ra n s a c ti o n T T 150 100 50 0 0 20 40 U se rl o a 60 80 100 T 200 Figure 24: Transactions per Minute Notice one test has significantly higher TPS than the other two after the throttling effect at 18-24 users. dba_hist_sysstat b where b. in Figure 26 we will examine logical reads. Logical READS 9000000 8000000 7000000 6000000 5000000 4000000 3000000 2000000 1000000 0 www.begin_interval_time.org 06 05 03 09 06 :3 05 1 20 03 0 06 9: 35 05 20 03 0 06 9: 40 05 20 03 0 06 9: 44 05 20 03 0 06 9: 49 05 20 03 0 06 9: 54 05 20 03 09 06 :5 05 8 20 03 1 06 0: 0 05 03 2 20 10 06 :0 05 7 20 03 1 06 0: 11 05 20 03 1 06 0: 15 05 20 03 1 06 0: 20 05 20 03 1 06 0: 24 05 20 03 1 06 3: 58 05 20 03 1 06 4: 02 05 20 03 1 06 4: 07 05 20 03 1 06 4: 11 05 20 03 1 06 4: 16 05 20 03 1 06 4: 20 05 20 03 14 06 :2 05 5 20 03 1 06 4: 29 05 20 03 1 06 4: 33 05 20 03 1 06 4: 37 05 20 03 1 06 4: 42 05 20 03 1 06 4: 46 05 20 03 1 06 4: 5 05 03 1 14 :5 5 20 Logical READS 20 Figure 26: Database Logical Reads RMOUG Training Days 2007 Y ` Y ` Y ` 250 W X T ra n s a c tio n s e r M in u te .begin_interval_time>sysdate-7 and b.snap_id=a.to_char(a.a.

But how are the IOs being done. the gross readings were taken at user intervals during the test) The dip to zero shows the break between the tests and is not an actual reading. we were doing 27.org 06 05 20 03 09 06 :3 05 1 20 03 09 06 :3 05 03 5 20 09 06 :4 05 0 20 03 09 06 :4 05 4 20 03 0 06 05 9: 49 20 03 09 06 :5 05 4 20 03 09 06 :5 05 8 20 03 10 06 :0 05 2 20 03 10 06 :0 05 7 20 03 10 06 :1 05 03 1 20 10 06 :1 05 5 20 03 10 06 :2 05 03 0 20 10 06 :2 05 4 20 03 13 06 :5 05 8 20 03 14 06 :0 05 2 20 03 14 06 :0 05 7 20 03 14 06 :1 05 1 20 03 14 06 :1 05 6 20 03 14 06 :2 05 03 0 20 14 06 :2 05 5 20 03 14 06 :2 05 03 9 20 14 06 :3 05 3 20 03 14 06 :3 05 7 20 03 14 06 :4 05 2 20 03 14 06 :4 05 6 20 03 14 06 :5 05 03 1 14 :5 5 20 Date/Time DB File Scattered Reads DB File Sequential Reads Figure 28: Scattered and Sequential Reads RMOUG Training Days 2007 20 06 05 03 03 03 03 03 :5 :0 :2 :2 :3 :4 :5 :3 5 . Figure 29 shows the time currently spent doing physical IO for scattered and sequential reads.000 physical reads over a 5 minute interval (that is less than 35 per second as there are 300 seconds in 5 minutes (5*60)) to contrast this. Logical reads are reads from memory requiring no physical IO. performance for these queries would be optimal.Testing to Destruction Ault In Figure 26 we see the logical reads resulting from two of our 78 user ramp-up tests of the Issues materialized view queries. If the system shifts from predominately logical to predominately physical reads to satisfy the queries.000. sequential (index) reads are the predominate activity at the physical read level with only small periods of scattered reads. However.000 range (this is data taken over intervals that span a range of user increase. a supervisor checking on his subordinates issues) has no role would increase the number of table entries by a factor of around 20. This would increase the size to nearly a gigabyte in size driving up physical reads if the current database memory size is maintained. In order to put this in proper perspective we need to also look at physical reads for the same time period. this is shown in Figure 27.000 to 8. Scattered and Sequential Reads 10000 1000 Reads 100 10 1 As you can see from Figure 28. The Issues queries are performing primarily in memory which is why their performance is excellent (sub-second on the average) if this could be maintained for the production environment at least as far as the database is concerned. www.000. it is projected that with the addition of the requirement to allow searching for issues that the current user (i.000 logical IOs per second at peak.rmoug. processing time could increase by up to a factor of 17 to 100 times. Physical reads 100000 10000 1000 100 10 1 1 0 4 7 7 2 6 1 :5 14 06 05 03 14 8 2 1 5 4 7 0 0 8 2 1 6 5 4 9 5 9 3 :4 :4 :5 :0 :1 :1 :2 :0 :2 :5 :0 :1 :1 :3 :4 :4 :2 09 09 09 10 :3 14 09 10 10 10 10 14 14 14 14 10 13 14 14 14 09 09 09 14 14 14 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 20 20 20 20 06 05 06 05 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 06 05 Physical reads Figure 27: Physical reads In Figure 27 we see that the system is doing very few physical reads. As you can see from Figure 26 logical reads are in the 5.e. with peaks of around 10. by table or by index reads? Figure 28 will show us this as it compares scattered verses sequential reads.

however if these were to be increased by a factor or 17 then the application would be spending a much larger percentage of time in the physical IO process. especially if scattered reads also increase as they are currently at the 1-10 second range when they occur.rmoug. Table ROWI and Scan Rows 100000000 10000000 1000000 100000 Rows 10000 1000 100 10 1 The graph in Figure 29 clearly shows the wide range between the index based reads and table scan based reads in the system. Figure 30 shows a comparison of these values. www.1 0. Operating System Activity What about CPU and paging activity? Figure 31 shows the CPU activity representing one 78 user test run. Another way to look at physical IO is via table scan rows and table rows by ROWID statistics.01 Figure 29: Read Times During the test period read times for sequential read activities where sub-second for a given interval.Testing to Destruction Ault 10 econ s 1 0.org 06 05 03 06 0 05 9: 3 20 03 1 06 09 05 :3 20 03 5 06 0 05 9: 4 20 03 0 06 0 05 9: 4 20 03 4 06 09 05 :4 20 03 9 06 0 05 9: 5 20 03 4 06 0 05 9: 5 20 03 8 06 1 05 0: 0 20 03 2 06 1 05 0: 0 20 03 7 06 1 05 0: 1 20 03 1 06 1 05 0: 1 20 03 5 06 1 05 0: 2 20 03 0 06 10 0 :2 20 5 03 4 06 1 05 3: 5 20 03 8 06 1 05 4: 0 20 03 2 06 14 05 :0 20 03 7 06 1 05 4: 1 20 03 1 06 1 05 4: 1 20 03 6 06 14 05 :2 20 03 0 06 1 05 4: 2 03 5 20 06 1 05 4: 2 20 03 9 06 1 05 4: 3 20 03 3 06 1 05 4: 3 20 03 7 06 1 05 4: 4 20 03 2 06 1 05 4: 4 20 03 6 06 1 05 4: 5 03 1 14 :5 5 20 20 ate/Time Figure 30: Table scan and ROWID rows 1 06 0 5 0 :2 4 03 1 06 0 5 3 :5 8 03 20 06 1 0 5 4 :0 2 03 20 1 06 0 5 4 :0 7 03 20 1 06 0 5 4 :1 1 03 20 1 06 0 5 4 :1 6 03 20 1 06 0 5 4 :2 0 03 20 1 06 0 5 4 :2 5 03 20 1 06 0 5 4 :2 9 03 20 06 1 0 5 4 :3 3 03 20 1 06 0 5 4 :3 7 03 20 1 06 0 5 4 :4 2 03 20 06 1 0 5 4 :4 6 03 20 1 06 0 5 4 :5 1 03 14 :5 5 20 Date/Time DB File Scattered Reads DB File Sequential Reads 5 0 1 5 2 1 4 9 4 8 7 :1 :1 :3 09 09 :4 :5 :5 10 10 10 03 03 09 09 09 09 09 10 03 03 03 10 03 03 03 03 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 06 05 20 06 05 20 20 20 20 20 20 20 20 20 20 20 20 20 06 05 03 03 03 03 :2 :0 :3 :4 :4 :0 0 b ab ab b cattere an equential Rea econ s f e a d c Table Scan Rows Table By Rowid RMOUG Training Days 2007 .

these are due to the startup of the test users and can generally be disregarded. The biggest issue which stopped testing at 78 users was memory related and not CPU.rmoug. the 7 point moving average is a better indicator of actual CPU activity in this case and shows that even with 78 users hammering at the system we only reached 67 percent of CPU. www.5 megabytes of memory per user. (cpu total) Figure 31: CPU Activity In Figure 31 we see that there appears to be a great number of processing peaks. Memory 10000000 1000000 1k page 100000 10000 1000 1 22 43 64 85 106 127 148 169 190 211 232 253 274 295 316 337 358 10 Se c Re a ding swap free Figure 32: Memory Usage Figure 33 shows system paging activity.Testing to Destruction Ault 100 90 80 70 60 ercent 50 40 30 20 10 0 1 16 31 46 cpu us cpu sy cpu wt 61 76 91 106 121 136 151 166 181 196 211 226 241 256 271 286 301 316 331 346 361 cpu total 0 ec nter al 7 per. this spiking in paging corresponds with the startup and release of the users during the test activity. Once the peaks are removed the overall system paging is well within expected ranges and is not a performance issue. but as with the CPU activity. Figure 32 shows memory usage as a function of time for the test period. about 3. Mov. Avg.org i s r q p h g t U Acti ity RMOUG Training Days 2007 . As with the CPU Activity there appears to be a great deal of spiking. Looking at the source data the free memory dropped from 343 megabytes to 66 megabytes during the test period.

87 percent of the available CPUs (2) for each user at peak load: 68 percent of CPU at 78 users). if system data volume increase by a factor of 20 as is predicted then the memory will no longer be able to fully cache the ISSUES data and increased physical reads will seriously impact performance of the Issues queries. I have also seen SLA¶s between other departments and the IT department. thus. Should the data size increase by a factor of 20 to get the same performance the database cache area would also need to be increased by a similar amount (from 500 megabytes to 10 gigabytes) unless some form of partitioning on the ISSUES table is utilized to reduce the working data set size. However. Generally SLA¶s related to databases call for a specific response time. www.rmoug. In previous sections we saw queries that responded with data in sub second response times. then the queries that fill the screen with data or the query that pulls the data for the report. a particular screen may need to be populated within 7 seconds or a particular report must return results within 3 seconds. Maintaining Service Level Agreements (SLA¶s) An SLA (Service Level Agreement) is a contractual agreement usually between a service provider such as a hosting service. So how can the IT department ensure that it meets its specific SLA requirements? The IT department must define specific tests that are performed at specific intervals to verify SLA compliance. at least 9 CPUs (assuming the data is fully cached) would be required to just handle the Issues type queries at a 78 user load with a factor of 20 data size increase. However.org u wv pgout/s ppgout/s pgfree/s pgscan/s RMOUG Training Days 2007 . The results from the SLA performance tests are graphed or trended. for example. it may not be that easy. or lack of compliance. if a particular screen or report is the basis of the SLA. Determining SLA Test Queries Sometimes it will be easy to determine the query or queries to test for performance. Using ratios the current configuration utilizes 0.Testing to Destruction Ault Paging Acti ity 1000 100 es P 10 1 13:58:33 14:00:33 14:02:34 14:04:34 14:06:34 14:08:35 14:10:35 14:12:35 14:14:36 14:16:36 14:18:36 14:20:37 14:22:37 14:24:37 14:26:38 14:28:38 14:30:38 14:32:39 14:34:39 14:36:40 14:38:40 14:40:40 14:42:40 14:44:41 14:46:41 14:48:42 14:50:42 14:52:42 14:54:43 14:56:43 14:58:43 Time Figure 33: Paging activity Phase 1 Conclusions Phase 1 shows that for the current data size (42 megabytes in the ISSUES base table) the data is completely cached in the database buffer area leading to excellent query performance at the database level. each CPU would be doing 870 percent. The problem in the system in the previous section was the downstream reporting system. increasing the workload by a factor of 20 would drive CPU usage to 1740 percent. for example. allowing that this is for 2 CPUs. If CPU usage increases by a factor of 20 due to increases in data set size then to support the same 78 users with the same level of performance 10 CPUs would be required. In addition. However. and a client. increasing the data set size will increase the amount of logical IO and CPU usage. yet the application response time was over the SLA of 3 seconds. before the users notice.

requiring recoding 2. www. You must make sure that not only do you have a meaningful SLA. be sure your SLA is just for items you have control over! You must make sure that a SLA is meaningful for your part of the system.Testing to Destruction Ault Even though the database responded in sub second time the downstream reporting system and web server resulted in delays that caused what the user saw as response time to be longer than the 3 second SLA. so instead of just ³must respond within 3 seconds to a user request´ the SLA should have been ³The database will respond to user generated SQL at the reporting layer interface within 3 seconds. SQL may change. to a mini-benchmark that is automatically run and a scheduled basis. Your test scripts can be as simple as a SQL test harness routine that utilizes the pre-chosen SQL and is run periodically during the day. your users obviously don¶t use the system on off-peak times only.org RMOUG Training Days 2007 . It is very difficult to randomize code variables 3. Open procedure with ³X´ (number of times for each SQL iteration) Loop 1: Choose Template SQL statement from SQL table Loop 2: SQL Processing (iterate X times) Read example SQL string from test SQL table Parse variables from code Loop3 Read variable types and random values from variable table Replace variables in SQL string with proper variable End Loop3 Capture start timing Execute parsed and variable loaded SQL into cursor Capture end timing Calculate total time spent executing Load result table for executed SQL with timing End Loop2 End Loop 1 Calculate Averages for all SQL Compare calculated averages to SLAs Send alert if any SLA exceeded End Procedure Figure 34: Pseudo-Code for SQL Test Harness In the procedure in Figure 33 you need three support tables and to come up with some method of randomizing the values inserted into the test SQL. make sure the SLA specifies performance at each level of the system. after all. but also during peak loads. You must introduce randomness into SQL variables and run queries multiple times. Ok.´ Did I mention that the system with the 3 second SLA also had to service clients in Asia from a server in the Midwestern portion of the USA where the network latency was 500 milliseconds for each leg of the network round trip? Obviously whoever thought up the 3 second response SLA requirement hadn¶t worked out the details of their own architecture and whoever accepted such an SLA as a contractual obligation hadn¶t thought about the full implications of the SLA. What Now? Once you have a properly defined SLA and the queries to test it. The tests must be run not just during off hours with a low load. The pseudo-code for such a SQL test harness would look something like Figure 34. Issues with Generating Your Own Scripts If you generate your own SQL test harness you face the following issues: 1. you have to set up periodic testing routines that verify the SLA timing criteria are met. or developing your own SQL test harness to inject code into your database. Capturing timing values can be problematic Without a benchmark utility you are limited to either manually running the scripts and capturing the timings to verify your SLA. but that the queries you choose to test with are of sufficient complexity and quantity to fully test the important parts of the SLA. if you inject the same identical SQL statements in each test run you may get artificially good performance due to caching at the database level. then average the results to get valid results. I have the SLA and Queries.rmoug. However.

or whatever scheduler you use in your database.4 4. cron. Each department insisted on their own servers. their own DBAs. their own support staff. The Easy Way If you are using Oracle. This pushing of the applications to a central group has lead to the server and storage consolidation efforts.7 1. Then the most difficult part is scheduling the test to run. Supporting Server & Storage Consolidations Things always seem to move in waves.6 Hyperthreading Y Y E uiv 6 3 3 5 0 0 0 0 0 0 0 0 0 0 17 22 otal/ : 15 esired : Peak usy: 2 3. Another easy method is to use a Benchmark tool that allows you to enter the test SQL and program in randomization of variables. and sometime in the future you would get an answer.8 Peak % Busy 60 70 40 78 Raw 3. first something is up.6 1. A lab-coated elite took your requests. air conditioned room. The came the budget crunches and lo and behold everyone started passing their applications back to a central group for management. Tools like Benchmark Factory will even email you with results from SQL testing. the Grid Control and Database Control interfaces allow you to enter new procedures to calculate metrics which will be tested and the results can generate server alerts that will send you emails when SLAs are exceeded. times the number of processors times the peak percent busy.2 30 62 eeded CPUs: Figure 35: Example CPU Calculation Spreadsheet www. a sealed. However. then it is down. CPU Count Calculation CPU Count 2 1 4 8 Ghz 3 2. how can you determine how many CPUS and how many gigabytes of memory are needed to support a consolidation of many applications onto a single large SMP computer? In addition to simple things such as number and speed of the CPUs. The number of needed CPUs can be quickly calculated by using the number of processing cycles available per CPU in the existing machines. Then the people took the power and dared to have computers on the desktops. in the ´glass house´. the mainframe. A simple spreadsheet such as that used in Figure 35 allows this calculation to be done easily.992 0 0 0 0 0 0 0 0 0 0 18.89 2.5 0.rmoug. you also need to consider the speed of the memory and front side buses as well. the new Oracle scheduler.org RMOUG Training Days 2007 . This was the golden age of computers as far as consultants were concerned. In the beginning of the computer era everything was run on a single large machine. summing the results and then using that with simple ratios to determine the number of new CPUs needed to meet the required cycle usage.Testing to Destruction Ault Once the procedure for executing and testing your SQL is created (send me a copy when you get it working!) you simply schedule it using DBMS_JOB.

00 0.00 0.00 0. Determining disk needs can be much easier than determining the CPUs and memory needs.00 RAID5 10 3 3 3 3 3 3 3 3 3 3 10 y 1.00 0.00 0.00 Sum Reads+ Writes 1.00 0.00 0.000.00 1. The example is for IO to a single Oracle instance but by simply combining the results from multiple spreadsheets should give you a good starting point for sizing a combined system.00 0.00 0. you must consider IO capacity as well as user concurrency issues when dealing with disk capacity. but if you allow for needed IO rates usually you get pretty close to allowing for concurrency as well.00 0.00 0. Always look at IO rates and concurrency needs first.00 RAID5 IO rate 1.00 0.3 ‚ ƒ x € € ‚ RMOUG Training Days 2007 .00 Label ( or entered alue) ariable Manual ntry Title Constant RAID01 NMR RAID01 MR Calculated alues Default (can be changed) RAID01 No Multi-Read RAID01 Multi-Read Capable www.00 1. Column Raw Equiv Needed CPUs Calculation =B3*C3*(D3/100) =CEILING(IF((F3 = "Y").00 0.00 0. Don¶t let salesmen tell you faster memory means less memory.org  y ount Point Physical Reads Physical rites 200.00 0. Specify your disk array based on data size alone and I guarantee you will get poor performance.00 0.62 RAID5 rite Penalty: 200 RAID0 1 MR 8 0 0 0 0 0 0 0 0 0 0 8 RAID5 Adjusted IO 1.00 0.00 0.00 0.00 0.00 0.060.000.00 0.00 0. and faster CPUs mean less CPUs.00 0.82 RAID5 actor: 0. allow no more than 90 IO/sec per drive (less if you use RAID5).E3).00 0.1) =CEILING(((D17*G17)/C20)*C17/C19.00 1.00 0. In situations where clients bought into this ³less is more´ hype they usually regretted it and ended up adding CPU and memory. concurrency is a bit harder to figure out.00 0.5.1) Table 4 CPU Count Calculations Determining memory needs is a matter of looking at current usage during peak times across the various platforms to be consolidated and adding the results.00 x Instance: TO1P RAID01 factor: 0.00 0. The RAID calculations for RAID 10 and RAID 5 are shown in the spreadsheet in Figure 36. However you must not only look at disk capacity.00 0.00 0.060.00 0.000.00 0. Dur: 1 # irrors: 2 IO/sec 1.060.E3*1.00 1.00 0. RAID ARRAY CALCULATIONS DISK IO Rate: RAID0 1 NMR 14 0 0 0 0 0 0 0 0 0 0 14 1 800 Totals 800.060.00 0.000.rmoug.00 0.00 0.00 0.00 0.Testing to Destruction Ault The calculations used in the spread sheet cells are shown in Table 4.00 0.00 0.00 € eas.00 200.

82*0. www. We have seen examples using the Benchmark Factory tool to demonstrating the use of such tools for trending and planning for future needs. Minimum number of RAID5 drives assumed to be 3 (2 data and one equivalent for parity data) Figure 36: Example Disk Calculations Using the above techniques you should be able to get fairly close to the needed amount of memory and CPUs for your consolidated server. Conclusions In this chapter we have examined the uses of benchmark tools to perform capacity analysis and prediction. memory and disks in server consolidations. if less than 4 RAID0 is assumed.Testing to Destruction Ault RADI01 actor based on 90/110 RAID5 actor based on RAID01 factor less 25% for RAID5 IO penalties (1*0. haven't figured out a complex enough formula for the other levels.rmoug.org … … … ith 90 being best observed rate „ „ RMOUG Training Days 2007 . Number of Mirrors currently works for just 2. Minimum number of RAID10 disks figured to be 2 or a multiple of 2. as well as the number of disks.82-(0.25)) RAID5 is also more costly the more WRITE activity so a rite penalty of 5 ( hich is low based on experience) is also assessed. We have also examined the use of manual tools such as spreadsheets to do predictions of needed CPUs.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->