ĐĎॹá>ţ˙ qsţ˙˙˙p˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ěĽÁ#` řż0 Abjbj\.\. ŁZ>D>D 9˙˙˙˙˙˙¤ttttttt4¨???? ?T¨‚N0|?’?’?’?’?m@m@m@•F—F—F—F,ĂF cJ N$˛OhR'Ntî@m@m@î@î@'Ntt’?’?Ű= 0 and n < 1); create index t1_i on t1(v); create table t2 ( n number, v varchar2(20), d date ); alter table t2 add constraint c_t2 check (n >= 1 and n < 2); create index t2_i on t2(v); create view pv as select * from t1 union all select * from t2; Fig 1 - creating a partition view The main problems with partition views are that any code to insert data ‘into the view’ has to know which underlying table should actually be used, and if you need to add extra partitions you need to create or drop tables and redefine the view. A further complication arises if some of your maintenance code fails silently or a file becomes corrupted leaving you, for instance, with a missing index: the view suddenly ceases to be a ‘partition view’, and the resulting performance side-effects can be catastrophic. There are also some nasty side-effects on performance when using partition views with a large number of tables, particularly when you are also using the Parallel Query Option. In an attempt to address some of these problems, Oracle 8 offers the partitioned table - Fig 2 is a sample of code that generates the table equivalent of our previous view. create table pt ( n number, v varchar2(20), d date ) partition by range (n) ( partition p01 values less than (1), partition p02 values less than (2) ); create index pt_i on pt(v) local; Fig 2 - Creating a partitioned table As you can see, the code is much more concise. You will note that in copying the view, I have chosen the option to create the index as a ‘local non-prefixed’ index - i.e. the index is automatically broken into sections that exactly match the underlying table partitions, and the index does not include the partitioning column. Frankly I feel that this is almost invariably the only sensible kind of index to use on partitioned tables although unique indexes (hence primary key indexes) can only be local if they include all the columns that define the partitioning. If I want to add a further partition to the table, all I need do is: alter table pt add partition p03 values less than (3); As the table partition is created, the corresponding partition is added to the local index. Similarly, I can get rid of data I no longer need and the corresponding partitions of the local index with: alter table pt drop partition p01; If I choose to insert data into the table, it will automatically be inserted into the correct partition. If I query the table with a predicate: and n = 1.2 only the relevant partitions will be accessed.. If one of the table’s partitions, or one of the partitions of a local index, goes offline or is otherwise damaged I can still query the table efficiently so long as I do not need to access the bad partitions. I can even (according to the manual) start a query in one session which maintains read-consistency across a ‘drop partition’ that is subsequently issued by a second session ! The only documented restriction on partition tables (which is also true for partition views) is that an update to a row may not move the row from one partition to another. With my example table I could not: update pt set n = n + 1 where …. On the face of it, then, partitioned tables are much more desirable than partition views - and I haven’t even started to describe the wonderful performance benefits you can get from parallel execution against partitioned tables - so how do they compare in real life ? Features or Benefits: Before examining the various features of partitioning, and the benefits they may give, I would like to give a bit of background to my opinions by describing the types of application where I would expect to see partitions. Essentially I would not expect to see partitioning used in anything other than a data warehouse. It is likely that the partitioning would be by time. I would expect the application to be loading a very large number of ‘recent’ data items each day, and a small fraction of late or corrected items of older data. End-users would be interested in a small number of items reviewed over a large time-scale, or a large number of items viewed over a small time-scale or pair of small time-scales such as a ‘this year vs. last year’ comparison. To handle the larger queries the parallel query option would probably be configured into the system. Given this context, what features of partitioned tables can be translated into benefits to the application ? Adding a partition Let’s look at adding a new partition. It is very easy to add a new partition - or is it ? What if you use one tablespace per month or week of data - which is a simple and common administrative feature for dealing with vary large data sets ? How do you specify which tablespaces the new partition and its indexes should be built ? You can’t: you have to write code that changes the default tablespace for the table and each of its indexes before you create the partition. Loading partition data What about filling the partition - all you have to do is specify the table, and Oracle will get the data into the correct partition - but is this sensible ? My first problem with this was that the loader kept crashing when I tried it, but more significantly there are two strategic points to consider. First there is the overhead needed to check every row so that it can go into the correct partition. For OLTP processes the overhead may be irrelevant, but for several million rows it may be the difference between hitting and missing the SLA. Fortunately you can specify partitions explicitly and avoid this overhead, but there goes the easy coding option. The second consideration is the effect of queries hitting the table whilst loading is going on - unless the queries are designed to miss the latest partition, you may find that loading whilst end-user queries are running results in contention due to the need for read-consistency. Again there is an alternative - create a (non-partitioned) table that emulates the required partition, fill it, add a new partition to your main table, then exchange the temporary table with the empty partition. But the code is about as complex as the code you would have to write to handle partition views. All in all, my impression of real-life use of partition tables has been that the ‘administrative convenience’ is something of an illusion, the code to add and load new partitions is just as complex as the code to maintain the tables of a partition view. What do the users think ? The previous two sections cast some doubt on the benefit of partitioned tables, but there is good in them. Most significantly, they can work much more rapidly than partition views, particularly with the parallel query option. With partitioned tables the optimiser passes partition-specific queries to each parallel query slave, so slaves receive code of the form: select n, v, d from pt partition (:b1) where n >= 1.3 and n <= 1.5 and v = ‘abc’; By comparison, code generated for the partition view would look more like: select n, v, d from ( select /*+ rowid */ n, v, d from t1 where rowid between :b1 and :b2 and n >= 1.3 and n <= 1.5 and 1.3 < 0 and v = ‘abc’ union all select /*+ rowid */ n, v, d from t2 where rowid between :b3 and :b4 and n >= 1.3 and n <= 1.5 and v = ‘abc’ ) Both code fragments have been simplified for clarity , even so extended to a view with 365 tables, you appreciate that partitioned tables can have a big run-time advantage. An interesting feature you may notice from the code fragments is that parallel queries in version 7 have to be driven by tablescans - in version 8 with a partitioned table you can specify a hint of /*+ parallel_index() */ and each partition will be handled by its own parallel query slave which can then use indexed access to the table. This feature alone can make a huge difference to the overall performance of a data warehouse - when combined with bitmap indexes the effect can be truly staggering. Finally, there is one class of queries which partitioned tables handle perfectly but partition views cannot handle at all well, these are queries of the form: where partition_col between a and b or partition_col between c and d Partition elimination fails on partition views if you supply this type of query, and in the absence of suitable indexes the performance cost can be massive. There is a partial damage-limiting work-around, writing the query as: where partition_col between a and d and ( partition_col <= b or partition_col >= c) results in partitions elimination outside the main range. This is an amazing failing of partition views, given that almost ANY data-oriented organisation will want to say: “compare this year with last year”. But… There are always bugs or anomalies. /*+ parallel_index()*/ can produce results very quickly, however any parallel query kicks off a global checkpoint. Since Oracle 8 allows for 1,000 tablespaces of 1,000 files each a global checkpoint could in theory take about 3 hours to complete - this is due to be reviewed in 8.1, but until then be cautious of how many files you create in your data warehouse. Parse time for partitioned tables with a large number (250+) of partitions can be significant - on top of this, any exchange, add, or drop of a partition causes the table to be invalidated and the entire dictionary cache content (for every partition, and every index, and every constraint) for that table has to be reloaded. Of course there are still some dramatic bugs with optimisation and partitioned tables - I quoted above the theory that you could maintain read-consistency across a ‘drop partition’. I have an example where a long running query simply stopped and returned the wrong results the moment dropped a partition from another session. I also have cases where the optimiser ‘forgets’ to divide costs by the number of partitions involved - so a query uses an index when 1 to 4 partitions are needed, but switches to a tablescan if 5 or more partitions are hit. The motto is ‘always test to scale’. There are some irritating features to partition tables too - you will have noticed the odd constraints I put on the tables in the partition view in Fig.1 above: check (n >= 1 and n < 2); This was done to demonstrate the way in which partitioned table are defined by using ‘upper bounds’. Partitioned tables are about ‘continuous’ values in columns, rather than ‘discrete’ values. The range allowed in any one partition is from, and including, the upper boundary of the previous partition to, but excluding, the boundary of the current partition. As a quirky example of what this means: if you partitioned your data by date then the partition holding data for 1st January 1998 would be defined somewhat counter-intuitively by the date 2nd January 1998. Partition views on the other hand allow you to put anything in the table constraints - and can actually allow you to partition your data in different ways simultaneously. Imagine a data warehouse where a table holds (with the redundancy common in data warehouses) the columns: year, month, week, sales_date. It is easy to set this up as a very efficient partition view that allows a user to query for all daily data in week 3 of 1998. I still have to work out how this can be done effectively with partition tables. (answers on a postcard please) Another example of functionality in partition views that cannot be handled by partitioned tables is the one given in the Oracle manuals of a partition view that combines data from different databases using ‘where clause’ partitioning instead of constraint-based partitioning. Conclusion. The administrative benefits of partitioned tables are probably less significant than might be apparent from the code supplied in the manuals. Partitioned tables offer some options for vastly improved performance, which I will be pleased to take advantage of once some of the bugs are fixed. They also offer some extra robustness because a partial failure can be tolerated without without impacting on performance. On the other hand partition views allow some flexibility which cannot be matched by partitioned tables, and the optimiser overhead of partition views is not too bad if the number of tables involved does not get excessive. The ‘readme’ file with Oracle 8.0.4 points out that support for partition views is going to be dropped at some stage in the future - I hope that this is a long way into the future, I would prefer to see partition views stay in Oracle with a couple of improvements brought over from partitioned tables for a long time to come. Jonathan Lewis is a freelance consultant with 13 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 Š June 1998  )*+Ž Ż ż ż Ă 6 M ž Nˇ›W!Gk›°„–v!Œ!v''(#()&)U0Y0ż0Â0$6>6[7c78 8i8k8`:k:š;Ä;‘?Ž@Ż@ß@ŕ@á@ü@ý@ AüřüřóřěřĺřěřŰřŰřŰřŰřŰřěřěřěřěřÓřÎřěřĺřŰřÉřÄřÄřěřěřóşóŞş şóh5h>/0J6jh5h>/6Ujh>/6U h>/H* h>/>* h>/5h>/56>*h>/CJOJQJ h>/56 h>/5>* h>/6h>/h^2ř:+,­ Ž Ż ż   „ … G H l “ í 5 6 N   c d q r ž úřřřřřřřřřřřřđđđřřřřřîîîř & Fgd^2řgd>/ Aţž Đ Ű ë ň ő ö 45RSTfqʑ‘‘Ę‘Ę‘‘ĘĘĘĘʑ‘9„Đ„m„ö& #$$d%d&d'd-D/„´MĆ ˙˙NĆ˙OĆ˙PĆ˙QĆ˙`„Đ5„m„ö& #$$d%d&d'd-D/„´MĆ ˙˙NĆ˙OĆ˙PĆ˙QĆ˙ˆ‹Œœ°ĘËčéęü*+,ƑƑĆƑ‘‘‘‘‘‘‘‘‘5„m„ö& #$$d%d&d'd-D/„´MĆ ˙˙NĆ˙OĆ˙PĆ˙QĆ˙9„Đ„m„ö& #$$d%d&d'd-D/„´MĆ ˙˙NĆ˙OĆ˙PĆ˙QĆ˙`„Đ,NOFGV śˇÉĘČČČČČČČȕ3„& #$$d%d&d'd-D/„´MĆ ˙˙NĆ˙OĆ˙PĆ˙QĆ˙5„m„ö& #$$d%d&d'd-D/„´MĆ ˙˙NĆ˙OĆ˙PĆ˙QĆ˙ ÉÔäëí*NQRtuv›œÍÎČČȕ••Č•••••••“““3„& #$$d%d&d'd-D/„´MĆ ˙˙NĆ˙OĆ˙PĆ˙QĆ˙7„Đ„& #$$d%d&d'd-D/„´MĆ ˙˙NĆ˙OĆ˙PĆ˙QĆ˙`„ĐÎÖ×AWX´ľ!"FG°ąŮÚçčęëš›klýýýýýýýýýýýýýýýýűűűýýýýýýýýýýą‘*+ĚÍŻ°ƒ„—Œ  u!v!!-"."ż"Ŕ"&$'$v&w&u'v'ýýýýýýýýýýýýýýýýýýýýýýýýýýýýýv'‘'t(u(˙()')8)E)T)U) )Ą)ˇ)Ü)ü) **$*2*<*b*‚***Ť*­*Ž*[+\+ýýýýýűűűűýýýűűűűűűűűűűűűűűýýý\+S-T-ó-ő-.:.;./ /D/]/€//ź/˝/T0U0Z0~0ę1ë12333z4{45‚5#6ýýýűőőőýűőőűőýýýýýýýýýýýýýýý„Đ`„Đ#6$6>6?6Ş7Ť7z8{8Ł:¤:¸;š;Ĺ;S<T<ë<ě<g=h=H>I>??‘?’?ţ@ A Aý÷ýýýýýýýýýýýýýýýýýýýýýýýýý„Đ`„Đ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 TextCJaJ44 Header  ĆÓo#D"D  Footnote Text „ ^„ 5\>ţń2> Double Indent „ ^„ 2ţB2 Action 5>*\6U@˘Q6 >/ Hyperlink >*B*ph˙>ţOb> programCJOJQJ^JaJŻ‘7 9Z˙˙˙˙5Z˙˙˙˙nZ˙˙˙˙+,­ŽŻż„…GHl“í56NcdqržĐŰëňőö45RSTfqˆ‹Œœ°ĘËčéęü*+,NOFGV  ś ˇ É Ô ä ë í   * N Q R t u v › œ Í Î Ö × AWX´ľ!"FG°ąŮÚçčęëš›klą‘*+ĚÍŻ°ƒ„—Œuv-.żŔ&'vwuv‘t u ˙ !'!8!E!T!U! !Ą!ˇ!Ü!ü! ""$"2"<"b"‚"""Ť"­"Ž"[#\#S%T%ó%ő%&:&;&' 'D']'€''ź'˝'T(U(Z(~(ę)ë)2+3+z,{,-‚-#.$.>.?.Ş/Ť/z0{0Ł2¤2¸3š3Ĺ3S4T4ë4ě4g5h5H6I677‘7’7ţ8 9 90€€˜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€€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€€˜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€€+,­ŽŻż„…GHl“í56NcdqržĐŰëňőö45RSTfqˆ‹Œœ°ĘËčéęü*+,NOFGV  ś ˇ É Ô ä ë í   * N Q R t u v › œ Í Î Ö × AWX´ľ!"FG°ąŮÚçčęëš›klą‘*+ĚÍŻ°ƒ„—Œuv-.żŔ&'vwuv‘t u ˙ !'!8!E!T!U! !Ą!ˇ!Ü!ü! ""$"2"<"b"‚"""Ť"­"Ž"[#\#S%T%ó%ő%&:&;&' 'D']'€''ź'˝'T(U(Z(~(ę)ë)2+3+z,{,-‚-#.$.>.?.Ş/Ť/z0{0Ł2¤2¸3š3Ĺ3S4T4ë4ě4g5h5H6I677‘7’7 9 9 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€˜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€€ A!ž ,ÉΏv'\+#6 A"$%&'()*+, A#Ž8ŕ8ü8 9X˙€đ8đ@ń˙˙˙€€€÷đ’đđ0đ( đ đđB đS đżË˙ ?đ˙˙iß: t^Ž 9ą 99*€urn:schemas-microsoft-com:office:smarttags€place€ Ěůöř_ c N!Q!Â!Ç!â!ç!-"0"G"L"h"m"Ś"Š"&$4$ű%&&)&&'3'J'W'l'y'‚((0-9-Ľ1Ż1E5L5 9łžăě*4ehrvžÄĐŃŰÜëěöű 5;TZfgqr‚Œ‘œŸ°ľËŃęđüˇ ˝ É Ę Ô Ő ä ĺ í ö   + 4 R X #AG"'ŰŢč쐙lr”šu‚íńƒ‰Ţĺ)ř‰!!'!,!8!;!E!H!Ą!§!ˇ!˝!Ü!á!ü!˙! " """$"'"2"7"<"B"b"g"‚"…""“"" "Ű"ä"'%.%ő%ú%&& '%'D'G'i'k''ˆ'U(Y(‹(‘($.).…2Œ2š3Ä3Ů4Ý4 9333333333333333333333333333333333333333333333333333333333333333333333333333333333 9ţ˙˙˙ÜÉ$ľ˙˙˙˙˙˙˙˙˙*ţ˙˙˙Čŕ;˙˙˙˙Ôŕ; @ „„ĺţ^„`„ĺţOJQJo(ˇđ˙˙˙˙ĺś >/^2ř 9˙@PDF995Ne00:winspoolPDF995 Printer DriverPDF995ÜÄSď€ę odXXLetterPRIVâ0''''Ä\KhC?,¸[˙˙PDF995ÜÄSď€ę odXXLetterPRIVâ0''''Ä\KhC?,¸[˙˙€ř\; 9@@˙˙Unknown˙˙˙˙˙˙˙˙˙˙˙˙G‡z €˙Times New Roman5€Symbol3& ‡z €˙Arial?5 ‡z €˙Courier New9CG Times CP Đh“$†˘›¸ž F ƒˆ0gƒˆ0g!P „ĽŔxx€24î8î82ƒQP „˙ßHP)đ˙?ä˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙^2ř2˙˙Partitioning (JLComp)AOracle partition views tables performance tuning trouble-shootingJonathan LewisJonathan Lewis ţ˙ŕ…ŸňůOhŤ‘+'łŮ0$˜ ŔĚä0| ¨´ Ô ŕ ě ř äPartitioning (JLComp)Jonathan LewisDOracle partition views tables performance tuning trouble-shootingDAn comparison of partition views and partitioned tables in Oracle. Normal.dotJonathan Lewis10Microsoft Office Word@d‰@\E>ź@şô|^˝@›™eâǃˆ0ţ˙ŐÍ՜.“—+,ůŽDŐÍ՜.“—+,ůŽd  px˜ ¨°¸ ŔČĐŘ ŕ äJL Computer Consultancyrgî8Ť Partitioning (JLComp) TitleČ 8@ _PID_HLINKSäA€6#mailto:jonathan@jlcomp.demon.co.uk   !"#$%&'()*+,-ţ˙˙˙/012345ţ˙˙˙789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ţ˙˙˙abcdefgţ˙˙˙ijklmnoţ˙˙˙ý˙˙˙rţ˙˙˙ţ˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙Root Entry˙˙˙˙˙˙˙˙ ŔFđË̜eâÇt€Data ˙˙˙˙˙˙˙˙˙˙˙˙.1Table˙˙˙˙68SWordDocument˙˙˙˙ŁZSummaryInformation(˙˙˙˙˙˙˙˙˙˙˙˙`DocumentSummaryInformation8˙˙˙˙˙˙˙˙hCompObj˙˙˙˙˙˙˙˙˙˙˙˙q˙˙˙˙˙˙˙˙˙˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ţ˙ ˙˙˙˙ ŔFMicrosoft Office Word Document MSWordDocWord.Document.8ô9˛q