ĐĎॹá>ţ˙ }ţ˙˙˙|€˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ěĽÁ#` řż0ĘEbjbj\.\. Šc>D>DĘ=˙˙˙˙˙˙¤4444444HđNđNđNđN üN\H_0dOzOzOzOzOUPUPUP2W4W4W4W,`W [  ^$O`hˇbÄ^4HQUPUPHQHQÄ^44zOzOŰŮ^WWWHQö4zO4zO2WWHQ2WWW44WzOXO p/eâÇđN>S˛W&W ď^0_W˝cđV˝cW˝c4W UP>“P,WżP$ăPeUPUPUPÄ^Ä^đVUPUPUP_HQHQHQHQHHHä#,+Ä#HHH,+HHH444444˙˙˙˙ Handling large datasets - Partition Views (Nov 1996) Over the last couple of years, most of the changes to the Oracle database engine have been aimed at making large databases faster and more manageable. In this article, the first of a short series, I describe the benefits and use of the partition view. Future articles will examine the Parallel Query Option, star schema, bitmapped indexes, and direct I/O. The Scenario: Consider the following requirement, which is typical of several sites I have visited in the last 18 months. I have to build a table to hold data for the last 7 financial years, as well as the ongoing data for the current year. Data arrives at a rate of 1,200,000 rows per month (40,000 per day), and each row is about 150 bytes. Typical queries are: compare this month with last month: compare this month with the same month last year: trend analysis across all 7 years. I need several efficient entry points to the data: e.g. area code, tariff-band, sales classification, client-age-band. At the end of each month, quarter, and year, I have to create summary reports for the period. The Problems How do I target the (relatively) small amount of data I need from any one month. How do I rebuild an index if one gets damaged or inefficient (which might just happen with a 15M row delete). How do I delete one year's worth of data (14,400,000 rows) at the end of a cycle in a timely fashion. How do I balance the I/O when the only significant objects I have to handle are sized in Gigabytes. The Solution Using earlier versions of Oracle, the design strategies people used to handle these problems revolved around splitting the data into a number of separate tables and then creating views that UNIONed the tables back together. Unfortunately the optimiser was not very good at recognising what was going on, and frequently ended up doing excessive tablescans. With the continuing evolution of the Oracle Optimiser many of the problems have been addressed in Oracle 7.3 by the official introduction of the "Partition View" Using a partition view, we could create 8 separate but identical tables for our data set, one for each year, or even 32 tables, one for each quarter. We then tell Oracle that the data in each table belongs to a certain date range. Finally we create a view that performs a UNION ALL across the tables doing a 'select * from table' on each table. Once this is done, any data query to the view is virtually indistinguishable from a data query to the original table. However, if the query includes a literal reference to a date range Oracle will examine ONLY the relevant underlying table. The Benefits: Instead of one table holding 120 M rows, you have 8 tables holding 15M each, or 32 tables at 3.75M each. Instead of a handful of objects in the 5-20 GB range, you will have a few dozen objects in the 100 MB to 500MB range, making general maintenance and I/O balancing easier to handle. Instead of deleting 14.4M rows from a table you simply truncate, or drop the table when it is deemed to be defunct. You can put all the older tables (and indexes) into read-only tablespaces, improving backup times. If you have to rebuild an index, it is based on a much smaller table. Many of the original indexes that would have had a date in them to improve the performance will no longer need one - saving about 1GB per index. (8 bytes x 120M rows). Because you are using much smaller tables, you will find that some queries will be much more efficient using tablescans on a single table than they used to be as an index scan on the original table. The benefits to be gained are quite surprising: obviously, however, they depend very much your actual data usage, and system setup - Parallel Query and data striping (not always at the O/S level) are two strategies that need to be reviewed as soon as you start using partition views. A Worked Example The rest of this article will describe in some detail an example of partition views, demonstrating how to set them up, how to prove they are working, and how to avoid a couple of traps for the unwary. The examples in this article were created and tested under Oracle 7.3.2 on an HP9000 running HP-UX 10.01. The Oracle ID used in the tests had DBA privileges. The database was running with: optimiser_mode=first_rows partition_view_enable=true Fig 1: Script to run as privileged user to create demo data rem rem If you have more than 50 tablespaces defined, then you will rem have to patch up the code for the updates and constraints rem create table u1 as select * from sys.uet$; create table u2 as select * from sys.uet$; create table u3 as select * from sys.uet$; update u1 set ts# = ts# + 0; update u2 set ts# = ts# + 50; update u3 set ts# = ts# + 100; rem rem Create the constraints that let Oracle see the partitions rem alter table u1 add constraint c1 check (ts# between 0 and 49); alter table u2 add constraint c2 check (ts# between 50 and 99); alter table u3 add constraint c3 check (ts# between 100 and 149); rem rem Create the partition view rem create or replace view u as select * from u1 union all select * from u2 union all select * from u3 ; rem rem Create a table to use in joins later on rem create table f1 as select * from sys.file$; In this example, I am creating a partition view from just 3 tables. The first step simply creates 3 identical tables, and populates them (with about 470 rows), and fixes up the data so that the column TS# is in the range 0-49 in the first table, 50-99 in the second table, and 100-149 in the third table. The second step is to tell Oracle about the partitioning by creating constraints on the partitioning column. In fact the optimiser would still try to execute the partitioning algorithm even if these constraints were not in place, but they are very important if you want to get the performance benefits. The final step is to create the view itself. There are some critical points to bear in mind when you create this view, as is it purely the definition of the view that determines whether or not Oracle will attempt to apply the partitioning optimisation. 1) Each separate part of the query should reference only one table, and should be 'select {all columns} from table'. If you list the columns explicitly they must match the order in which they appeared when the table was created. 2) There should be no WHERE, GROUP BY, or CONNECT BY clauses in the selections. 3) The tables should be virtually identical in structure. The names of corresponding columns do not have to be the same across the tables but column types must match and CHAR, VARCHAR2, and RAW columns must be declared at the same size. (NUMBER types are allowed to vary in precision and scale). A column may be NOT NULL in one table, and NULL in another. It is in the definition of the view that 'gotcha' number 1 appears: if you add or change a column on one of the tables without doing the same to all the other tables, the view will be silently recompiled the next time it is used but the partitioning algorithms will not be applied and performance will take a nose-dive. Note: contrary to the manual (Server SQL Reference, p4-275,276) you do not need to create an index on the column that you have used to partition the data. I have not yet created ANY indexes on the table - but let's see what happens when we use the view: Fig 2: First SQL statement to use on the View, and its trace file select /*+ first_rows */ count(*) from u x1 where x1.ts# = 3 and x1.length > 50 ; Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: HINT: FIRST_ROWS 0 SORT (AGGREGATE) 0 VIEW OF 'U' 0 UNION-ALL (PARTITION) 468 TABLE ACCESS (FULL) OF 'U1' 0 FILTER 0 TABLE ACCESS (FULL) OF 'U2' 0 FILTER 0 TABLE ACCESS (FULL) OF 'U3' Key points to note in the plan are: a) The (PARTITION) that appears after the UNION ALL b) Only ONE of the tables (U1) has actually had any rows examined c) All the irrelevant tables have been pre-filtered at no cost. My interpretation of this is that the optimiser does the following: It notes that the view is a UNION ALL, and checks for the possibility of a partition view by examining the definitions of the underlying tables, and the content of the individual select statements in the UNION ALL. If the tables meet the partition rules the optimiser looks for constraints on each of the underlying tables, and compares them with any constant conditions supplied in the query. If any table can be eliminated by virtue of this comparison then it appears in the access path with a FILTER line preceding it, and no rows returned. Any table that has not been eliminated is then accessed in a 'normal' fashion. This introduces 'gotcha' number 2: If the partitioning/constraining columns appear in the query as bind variables (i.e. PL/SQL or 3GL variables), then the partition view mechanism does not apply, all the tables will be accessed. Unfortunately, EXPLAIN PLAN and tkprof will both claim that the partition view option is being used. To prove that tkprof is reporting the path incorrectly, you need to look in the trace (.trc) file for the 'STAT:' lines of the relevant cursor: The number of lines in the access plan reported will be more than the number of available STAT lines. There are interesting side-effects to the way that constraints are used to eliminate tables. Basically the partitioning does not have to be proper partitioning. You may allow partitions to overlap; you could have 'multi-dimensional' partitioning (e.g. table1 is 1996 and Birmingham, table 2 is 1996 and London); any constraint on a table which just happens to be relevant to a WHERE clause could eliminate a table; finally, there may be some tables in the view which don't have any (relevant) constraints at all. You will note that, by the way, that I have used the FIRST_ROWS hint in my first example: this is simply because the demo tables are small. The cost of checking whether or note partitioning is viable are relatively high (lots of selects on CDEF$, etc), so for small tables, with the CHOOSE or ALL_ROWS optimiser goals, Oracle doesn't seem to bother, it just blasts through with the brute-force approach, and checks all tables with tablescans. The next step is to add some indexes. In the example above, it would clearly be a good idea to create an index on the LENGTH column. As a first step, you could just create this index on table U1 to see what happens. Surprisingly, the (PARTITION) and two FILTERs disappear from the access PLAN, and we find that U2 and U3 both report all rows scanned. If you then create identical indexes on U2 and U3 however, the (PARTITION) and FILTERs reappear, and the plan looks as you would expect. Fig 3: The output from tkprof after creating all three indexes. Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: HINT: FIRST_ROWS 0 SORT (AGGREGATE) 0 VIEW OF 'U' 0 UNION-ALL (PARTITION) 91 TABLE ACCESS (BY ROWID) OF 'U1' 92 INDEX (RANGE SCAN) OF 'I1' (NON-UNIQUE) 0 FILTER 0 TABLE ACCESS (BY ROWID) OF 'U2' 0 INDEX (RANGE SCAN) OF 'I2' (NON-UNIQUE) 0 FILTER 0 TABLE ACCESS (BY ROWID) OF 'U3' 0 INDEX (RANGE SCAN) OF 'I3' (NON-UNIQUE) This introduces 'gotcha' number 3: you can have as many indexes as you like, but every table in the view must have exactly the same indexes as every other table. You can't just put a couple of extra indexes on "this year's" data; and if you accidentally drop and fail to rebuild an index on just one of the tables your partitioning suddenly stops working. As a final example, let's try joining a table into the partition view. Table F1 was included in the original creation script; it has columns (FILE#, TS#) and the way in which U1, U2, and U3 were created ensures that the rows in U1 are 'child' rows to F1, but U2 and U3 are not because their values for TS# have been changed. After creating indexes I1, I2, and I3 on U1(FILE#) U2(FILE#) and U3(FILE#) Run the join query in fig 5. to test what happens when there is no constant condition on column TS#: Fig 4: Query and execution path with no constant condition on TS# select /*+ first_rows */ length from f1, u x1 where f1.blocks=512 and x1.ts# = f1.ts# and x1.file# = f1.file# Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: HINT: FIRST_ROWS 96 NESTED LOOPS 6 TABLE ACCESS (FULL) OF 'F1' 120 VIEW OF 'U' 120 UNION-ALL (PARTITION) 96 TABLE ACCESS (BY ROWID) OF 'U1' 97 INDEX (RANGE SCAN) OF 'I1' (NON-UNIQUE) 12 TABLE ACCESS (BY ROWID) OF 'U2' 13 INDEX (RANGE SCAN) OF 'I2' (NON-UNIQUE) 12 TABLE ACCESS (BY ROWID) OF 'U3' 13 INDEX (RANGE SCAN) OF 'I3' (NON-UNIQUE) Without any constant condition on the partitioning column, the optimiser cannot eliminate any of the partition tables, so it has had to trawl through the U2 and U3 indexes and tables to return data that is then eliminated by comparison back to the TS# value from F1. The optimiser still claims a UNION-ALL (PARTITION), but has no eliminators to help it. Luckily the condition 'blocks = 512' happens in my test data to correspond to the condition 'ts# = 4' so we can change the query to use an explicit reference to the partitioning column, noting as we do that Oracle is smart enough to deduce that: if a = b and b = c then a = c Fig 5: Join query which includes the partitioning column select /*+ first_rows */ length from f1, u x1 where f1.ts# = 4 and x1.ts# = f1.ts# and x1.file# = f1.file# Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: HINT: FIRST_ROWS 96 NESTED LOOPS 6 TABLE ACCESS (FULL) OF 'F1' 96 VIEW OF 'U' 96 UNION-ALL (PARTITION) 96 TABLE ACCESS (BY ROWID) OF 'U1' 97 INDEX (RANGE SCAN) OF 'I1' (NON-UNIQUE) 0 FILTER 0 TABLE ACCESS (BY ROWID) OF 'U2' 0 INDEX (RANGE SCAN) OF 'I2' (NON-UNIQUE) 0 FILTER 0 TABLE ACCESS (BY ROWID) OF 'U3' 0 INDEX (RANGE SCAN) OF 'I3' (NON-UNIQUE) We can see that all access to tables U2 and U3 has been eliminated, and the basic execution has been reduced to a simple nested-loop join between F1 and U1. Obviously,in this very small example the cost difference is slight, but using real-world data sizes, the importance of joining only to the required table would be great. In summary then, to use partition views (in 7.3.2): All tables should look the same All tables should be indexed identically There should be constraints on all partitioning columns Queries need to include a constant condition for a constraining column. From the experiments I have done, I feel that partitions views are already good enough to be of significant benefit to all the large-scale sites that I have visited recently, and I expect their implementation to become better still with future releases of Oracle. Jonathan Lewis is a freelance consultant with 11 years experience of Oracle. He specialises in physical database design and the strategic use of the Oracle database engine, but spends most of his time resolving performance issues. He can be contacted on 0973-188785, or e-mailed at  HYPERLINK "mailto:jonathan@jlcomp.demon.co.uk" jonathan@jlcomp.demon.co.uk Š November 1996 )+345ž Ÿ Ź f r  ivFVś‚…ä"í"ţ$'Ă*Ë*´2&595A5$7.7Ä7Ç7 8888"8'8‰8‹88p;j<l<í=ď@JDiEjEšE›EœEˇE¸EšEťEČEÉEĘEüřüřüóüěüěüěüĺüěüěüŰüóüĺüŰüĺüŰüĺüóüóüóüóüóüóüŰüóüŰüóŃ̟ѲŃóĚóĚóhm4hĎJ0J6jhm4hĎJ6U hĎJ6jhĎJ6UhŠtâCJOJQJ hŠtâ56 hŠtâ5>* hŠtâ6hĎJhŠtâ?56 ž Ÿ ­   “ ” ú ű  Ž   e f s Ä Ĺ 3 4 š › ˙  úřřřřřřřřřřřřřřřřřřřřřřřřřřřgdŠtâĘEţ rsŻ°tuhiwŕ•–  noľś_`'(EFWýýýýýýýýýýýýýýýýýýýýýýýýýýýýýW !úTUY™×ŰÜ2]^{™¸š˝ű˙?ÁÂýýýýýýýýýýýýýýýýýýýýýýýýýýýýýÂĂÄČćęë$6ASUVZ†Š‹ˇ¸üýęë  !ýýýýýýýýýýýýýýýýýýýýýýýýýýýýű!!Q!R!ş"ť"ü#ý#ţ$˙$%C%D%^%h%m%s%y%…%˜%š%›%ł%đ%#&>&U&w& &´&ýýűýýűűűűűűűűűűűűűűűűűűűűűűűű´&Ţ&ň&''A'u'v'š'ş'ú'ű'?(@())Ë)Ě)b*c*˛*ł*›+œ+ú,ű,//Ŕ0Á0ýýýýýűűűűűýýýýýýýýýýýýýýýýýýýÁ0°2ą2˛2ł2´2ő2ö23K3~3™3°3Ň3˙354I4w4Ž4Â4đ4'5(5)5‘6’6Ű6Ü6Ý7ů÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷ ĆX ŔÝ7Ţ7Ž888‘8Ó8Ô8î8ö8ű899 99/9G9H9`99Đ9ç9:%:G:t:Ş:×: ;őóóóóóóóóóóóóóóóóóóóóóóóóóóó „Đ„0ý^„Đ`„0ý ;:;p;q;r;Ő<Ö<Í=ě=í=î=ď=)>*>D>L>Q>V>\>b>n>‚>š>›>ł>đ>#?:?a?x?ýýýýýýýýýýýýýýýýýýýýýýýýýýýýýx?š?Ç?ý?@?@v@Š@¸@ď@đ@A‘A=B>B?BsB”BžB÷B@CACBCJDKDLDMDšEÉEýýýýýýýýýýýýýýýýýýýýýýýýýýýřgdŠtâÉEĘEý3 0@PBP°…. °ÂA!° "° #8$8%°°8°8 Đ7 0@PBP°…. °ÂA!° "° #8$8%°°8°8 P Đ3 0@PBP°…. °ÂA!° "° #8$8%°°8°8 Đ7 0@PBP°…. °ÂA!° "° #8$8%°°8°8 P Đ7 0@PBP°…. °ÂA!° "° #8$8%°°8°8 P Đ3 0@PBP°…. °ÂA!° "° #8$8%°°8°8 Đ7 0@PBP°…. °ÂA!° "° #8$8%°°8°8 P Đ7 0@PBP°…. °ÂA!° "° #8$8%°°8°8 P Đ3 0@PBP°…. °ÂA!° "° #8$8%°°8°8 Đ7 0@PBP°…. °ÂA!° "° #8$8%°°8°8 P Đ3 0@PBP°…. °ÂA!° "° #8$8%°°8°8 Đ7 0@PBP°…. °ÂA!° "° #8$8%°°8°8 P Đ3 0@PBP°…. °ÂA!° "° #8$8%°°8°8 Đ7 0@PBP°…. °ÂA!° "° #8$8%°°8°8 P Đ3 0@PBP°…. °ÂA!° "° #8$8%°°8°8 Đ7 0@PBP°…. °ÂA!° "° #8$8%°°8°8 P Đ3 0@PBP°…. °ÂA!° "° #8$8%°°8°8 ĐóDĐÉęyůşÎŒ‚ŞKŠ jonathan@jlcomp.demon.co.ukŕÉęyůşÎŒ‚ŞKŠ Fmailto:jonathan@jlcomp.demon.co.uk†œ``ń˙` Normal5$7$8$9DH$(CJOJQJ^J_HaJmH nHsH tHJ`J Heading 1$.„ť/„ť@&a$ 5>*\<`< Heading 2@& 5>*\8`ň8 Heading 3@&5\DA@ň˙ĄD Default Paragraph FontVi@ó˙łV  Table Normal :V ö4Ö4Ö laö (k@ô˙Á(No List F@ňF Normal Indent„Đ„0ý^„Đ`„0ý<+`<  Endnote TextCJaJ4@4 Header  ĆÓo#D`"D  Footnote Text „ ^„ 5\>ţOń2> Double Indent „ ^„ 2ţoB2 Action 5>*\6U@˘Q6 ĎJ Hyperlink >*B*ph˙Ÿˇ¸ţ˛*)-0r3î5đ8?:B;L<Ę=`˙˙˙˙5`˙˙˙˙n`˙˙˙˙Ł`˙˙˙˙Ü`˙˙˙˙a˙˙˙˙Ja˙˙˙˙ƒa˙˙˙˙źa˙˙˙˙ńa˙˙˙˙*b˙˙˙˙_b˙˙˙˙˜b˙˙˙˙Íb˙˙˙˙c˙˙˙˙;c˙˙˙˙tc˙˙˙˙56žŸ­“”úűŽefsÄĹ34š›˙ rsŻ°  t u h i w ŕ • – n o ľ ś _ ` '(EFW !úTUY™×ŰÜ2]^{™¸š˝ű˙?ÁÂĂÄČćęë$6ASUVZ†Š‹ˇ¸üýęëQRşťüýţ˙CD^hmsy…˜š›łđ#>Uw ´ŢňAuvšşúű? @ !!Ë!Ě!b"c"˛"ł"›#œ#ú$ű$''Ŕ(Á(°*ą*˛*ł*´*ő*ö*+K+~+™+°+Ň+˙+5,I,w,Ž,Â,đ,'-(-)-‘.’.Ű.Ü.Ý/Ţ/Ž000‘0Ó0Ô0î0ö0ű011 11/1G1H1`11Đ1ç12%2G2t2Ş2×2 3:3p3q3r3Ő4Ö4Í5ě5í5î5ď5)6*6D6L6Q6V6\6b6n6‚6š6›6ł6đ6#7:7a7x7š7Ç7ý78?8v8Š8¸8ď8đ89‘9=:>:?:s:”:ž:÷:@;A;B;J<K<L<M<š=É=Ě=0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0ŤhŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€56žŸ­“”úűŽefsÄĹ34š›˙ rsŻ°  t u h i w ŕ • – n o ľ ś _ ` '(EFW !úTUY™×ŰÜ2]^{™¸š˝ű˙?ÁÂĂÄČćęë$6ASUVZ†Š‹ˇ¸üýęëQRşťüýţ˙CD^hmsy…˜š›łđ#>Uw ´ŢňAuvšşúű? @ !!Ë!Ě!b"c"˛"ł"›#œ#ú$ű$''Ŕ(Á(°*ą*˛*ł*´*ő*ö*+K+~+™+°+Ň+˙+5,I,w,Ž,Â,đ,'-(-)-‘.’.Ű.Ü.Ý/Ţ/Ž000‘0Ó0Ô0î0ö0ű011 11/1G1H1`11Đ1ç12%2G2t2Ş2×2 3:3p3q3r3Ő4Ö4Í5ě5í5î5ď5)6*6D6L6Q6V6\6b6n6‚6š6›6ł6đ6#7:7a7x7š7Ç7ý78?8v8Š8¸8ď8đ89‘9=:>:?:s:”:ž:÷:@;A;B;J<K<L<M<É=Ě=jŽ0hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€hŽ0€˜0€€˜0€€hŽ0€˜0€€š0€€˜0€€ĘE# WÂ!´&Á0Ý7 ;x?ÉEĘE$&'()*+,-./ĘE%i=›=ˇ=Ę=X˙€đ8đ@ń˙˙˙€€€÷đ’đđ0đ( đ đđB đS đżË˙ ?đ˙˙Ď8 Ź Ď8 ŹC`!Ď8 Œ‚b"Ď8  Ebaź+12„7Ě=fÁ+62‰7Ě=9*€urn:schemas-microsoft-com:office:smarttags€place€ \B3ËŇŕîďůűUXY\™œ×Úý(/SZlnrt‰‹‘§Š­Żšź˝Ŕűţ(*gi§ŠÄÇČËćéVYZ]†‰Ź´PZź#Â#$$[$^$Ä)Ë)v*}*Ě*Ň*ŕ0ę0355566@6‘99Ě=ĎŘĹ2‘™ôţ†  ž Ă H ^ rxUXY\™œ×ÚÜâ 28^d{™Ÿšź˝Ŕűţ?D„ÄÇČËćéëń%+7<BHVYZ]†‰‹‘[cDM_ehlsx…ˆö˙)1ŚłäńČ#Ó#"')'))^*d*Q+Z+„+Œ+;,H,´,Á,..//0 0F0H0Ô0Ý0ď0ő0ö0ú01 111/121Ł1Ź1Î5Đ5*636E6K6L6P6\6a6n6q6‚6…6ö6˙688|8‰8š99Ě=333333333333333333333333333333333333333333333333333333333333333333333333333333Ä=Č=Ě=ĺĎJŠtâĚ=˙@PDF995Ne00:winspoolPDF995 Printer DriverPDF995ÜÄSď€ę odXXLetterPRIVâ0''''Ä\KhC?,¸[˙˙PDF995ÜÄSď€ę odXXLetterPRIVâ0''''Ä\KhC?,¸[˙˙€Č=Č=ä\;Č=Č=Ę=@@˙˙Unknown˙˙˙˙˙˙˙˙˙˙˙˙G‡z €˙Times New Roman5€Symbol3& ‡z €˙Arial?5 ‡z €˙Courier New9CG Times CP Đhl- †Ą›¸q5 Ś;˙8 ’4p8 ’4pŠ#P „ĽŔxx€24Ť=Ť=2ƒP „˙ßHP)đ˙?ä˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ĎJ2˙˙Partition Views (JLComp):Partition Views Oracle performance tuning trouble-shootingJonathan LewisJonathan Lewisţ˙ŕ…ŸňůOhŤ‘+'łŮ0 ˜ ÄĐč,dx œ ź Č Ô ŕěôüäPartition Views (JLComp)Jonathan Lewis<Partition Views Oracle performance tuning trouble-shooting0An introduction to Oracle's partition views. Normal.dotJonathan Lewis59Microsoft Office Word@ş&k@Ć|Ô4œť@¨B÷j›ť@Î×ueâÇ8 ’4ţ˙ŐÍ՜.“—+,ůŽDŐÍ՜.“—+,ůŽh$ px˜ ¨°¸ ŔČĐŘ ŕ äJL Computer Consultancy#SpŤ=Ť Partition Views (JLComp) TitleČ 8@ _PID_HLINKSäA€6#mailto:jonathan@jlcomp.demon.co.ukÉ  !"#$%&'()*+,-./01ţ˙˙˙3456789ţ˙˙˙;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijkţ˙˙˙mnopqrsţ˙˙˙uvwxyz{ţ˙˙˙ý˙˙˙~ţ˙˙˙ţ˙˙˙Root Entry˙˙˙˙˙˙˙˙ ŔFPË?eâǁ€Data ˙˙˙˙˙˙˙˙˙˙˙˙21Table˙˙˙˙:˝cWordDocument˙˙˙˙ŠcSummaryInformation(˙˙˙˙˙˙˙˙˙˙˙˙lDocumentSummaryInformation8˙˙˙˙˙˙˙˙tCompObj˙˙˙˙˙˙˙˙˙˙˙˙q˙˙˙˙˙˙˙˙˙˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ý˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ţ˙ ˙˙˙˙ ŔFMicrosoft Office Word Document MSWordDocWord.Document.8ô9˛q