Range Partitioning Fundamentals

Transcription

1 Session: E08 Range Partitioning Fundamentals Kevin Beck IBM May 8, :20 p.m. 5:20 p.m. Platform: DB2 for Linux, UNIX, Windows 1

2 Agenda Introduction Defining Partitioned Tables Roll-Out Performance Roll-In 2 2

3 Agenda Introduction Defining Partitioned Tables Roll-Out Performance Roll-In 3 3

4 Table Partitioning in DB2 LUW Partition a table by range Each range can be in a different table space Ranges can be scanned independently Use new ALTER DETACH/ATTACH statements for roll-out/roll-in JAN FEB MAR APR MAY JUN JUL AUG SEP 4 What table partitioning does for you is allow you to create a table where each range of the data in the table is stored separately. For example, you can partition a table by month. Now all data for a given month will be kept together. In fact, internally, the database represents each range as a separate table. This has a couple of advantages. One is that if you do a query that only needs to scan certain ranges, the database will scan only those ranges that are relevant. We call this "partition elimination" - think of it as skipping partitions that don't need to be scanned. I will talk more about partition elimination in the "performance" section of the presentation. Another advantage is that you can store a lot more data in a single table now. Since each range can hold as much data as a non-partitioned table, a single partitioned table can hold literally thousands of times as much data as the old limits on table size. <more on next slide> The most exciting feature that table partitioning enables is that it is very quick and easy to attach or detach ranges of data from a partitioned table. This is very useful for rolling in or out batches of data in a data warehouse application. I'll be going over all the ins and outs of how to accomplish this later in the presentation. <more on next slide> I want to emphasize that all of this is managed internally and is completely transparent to you as the user. Once the table has been created, all queries and DML against that table work exactly as if it were a non-partitioned table, except faster in those cases where the database is able to take advantage of partitioning. The advantages of table partitioning are very similar to those of union all views. The difference is that all the complicated parts of it are taken care of for you internally. 4

5 Typical Use of Table Partitioning Large fact table in a data warehouse Data rolled out periodically using DETACH Ranges match granularity of roll-out Small or non-existent maintenance windows Business intelligence style queries Queries to roll up data by e.g. date, region, product, category Queries are complex and/or long running Complementary to other data warehouse features ESE w/ DPF MDC (Multi-Dimensional Clustering) MQTs 5 Set the expectations for how the feature is intended to be used. 5

6 Benefits Easier roll-out/roll-in New DETACH operation for roll-out New ATTACH operation for roll-in SET INTEGRITY is now online Improved performance for certain business intelligence style queries Data partition elimination Data can be spread across table spaces Reduced need for REORG Indexes can now be placed in different table spaces 6 Ranges can be placed in different tablespaces, if desired. The syntax for creating partitioned tables makes it easy to control placement of your ranges if you need to do so. Previously, your choices for expanding beyond the size limit for a single table were to use ESE w/ DPF or union all views. Table partitioning is simpler to setup and administer than either of these. The new attach and detach operations let you roll large batches of data in or out of data warehouses with very little disruption to concurrent queries. Essentially, when you do one of these operations, queries that are accessing the table being manipulated need to be drained, then the data becomes visible all at once to new queries. I will cover this is in detail later. Partition elimination improves the performance for many queries. Table partitioning allows you to spread a table across multiple tablespaces. This allows for more flexible backup strategies than if your data were all in a single table and hence in one, large tablespace. A small benefit of table partitioning that is sort of a nice side effect of the feature is that indexes on partitioned tables can be placed in different tablespaces. Currently, when you create a table you specify a single tablespace where all indexes for that tablespace will reside. Or the database will choose one for you, if you don't specify. Either way, this single tablespace becomes a permanent attribute of the table. All indexes for that table must reside there, and you can't change your mind about what tablespace you want this to be without dropping and recreating the table. For a partitioned table, you can specify where to place each index as you create it. Each index can even go in a different tablespace, if you want. 6

7 Your Data in One Monolithic Table 7 When your is stored in a single large table, many business intelligence style queries will end up reading most of the table. Even if you have an appropriate index, each IO picks up many unrelated records that happen to reside on the same page. In this illustration, the query is looking for blue triangles. Since DPF is not used, only one CPU will be utilized for much of the processing done by a query. 7

8 Your Data Distributed by Hash P 1 P 2 P 3 8 With DPF, the query may still read most of the data, but now this work can be attacked on all nodes in parallel. 8

9 Distributed + Range Partitioned P 1 P 2 P 3 Jan Feb Mar 9 With table partitioning, all data in the same user defined range is consolidated in the same data partition. The database can read just the appropriate partition. This illustration has only 3 ranges, but real tables have dozens or hundreds. So range partitioning yields a significant savings in IO for many business intelligence style queries. 9

10 Distributed + Partitioned + Organized P 1 P 1 P 1 Jan Feb Mar 10 With MDC, data is further clustered by additional attributes. Now even less IO is done to retrieve the records of interest. Plus, table partitioning enables easy roll-in/roll-out of data. 10

11 Terminology Feature Name Table Partitioning Database Partitioning Alternate names Name for one Piece Syntax Defining Columns Range Partitioning Data Partition Range PARTITION BY RANGE Partitioning Key EEE ESE w/ DPF Database Partition Node DISTRIBUTE BY HASH Distribution Key 11 There is an unfortunate history in terminology used by DB2 LUW. LUW chose to apply the name partitioning to the EEE feature. The rest of the industry uses this term for tables spread across multiple disks or tablespaces. So when LUW decided to implement partitioned tables, the term partitioned already meant something else. This table shows the compromise used to make our terminology close to the industry standard. Most people say range partitioning instead of table partitioning. This works for now. It will become a problem if we ever implement DISTRIBUTE BY RANGE to distribute data across nodes by range. Likewise, there will be similar problems if we ever implement PARTITION BY HASH to partition tables by hash rather than range. 11

12 Compatibility with Other DB2 Features Table partitioned tables can also be database partitioned and/or organized by dimension (MDC) MQTs work well on table partitioned tables LOAD into a partitioned table works seamlessly Restrictions Partitioned tables cannot contain XML columns. DETACH from the parent table in an enforced RI relationship is not allowed (easy remedy). Replication does not support partitioned tables. Some special types of tables cannot be table partitioned Staging tables (for MQTs) Defined Global Temporary Tables Exception Tables 12 ESE w/ DPF and multi-dimensional clustering are compatible with and complementary to table partitioning. MQTs work well on table partitioned tables. In conjunction with table partitioning, we have made improvements to set integrity so that maintenance of MQTs can be accomplished without interfering with applications accessing the base tables concurrently. Utilities such as LOAD and REORG work on partitioned tables, but there are a few new things to know about using them. I will talk about this later in this presentation. 12

13 Agenda Introduction Defining Partitioned Tables Roll-Out Performance Roll-In 13 13

14 Best Practices Overview Consider table partitioning for large fact tables in a data warehouse Partition on date column Make ranges match size of roll-out Use DETACH for fast roll-out Use table partitioning in combination with DPF and MDC Spread data across tablespaces Use ADD + LOAD for roll-in 14 14

15 Best Practices Defining Ranges Partition on date Enables fast roll-out via DETACH Performance benefits for common business intelligence type queries Allows separation of active / static data for reduced backup volume Reduces need for REORG TABLE Choose size of ranges to match roll-out 15 Fast roll-out via DETACH is one of the big benefits of table partitioning. You need to partition on a date column to get this benefit. Some of side benefits are * Many BI queries are date oriented, so you will often get a performance boost from partition elimination * You can tailor your backups to backup active data more frequently and static data less often * A big reason (the main reason?) people do REORG TABLE is to reclaim space after bulk deletes If you do DETACH instead of bulk delete, then this reason goes away Ranges typically are by month or quarter * Yields a manageable number of ranges * Can have ranges smaller than roll-out e.g. range by month, roll-out 3 at a time each quarter 15

16 Indexes in DPF Context TBSP1 TBSP2 TBSP1 TBSP2 Index 1 Index 2 Index 1 Index 2 TABLE TABLE 16 For ESE w/ DPF, there will be a separate piece of the index on each node. This is just like any other table or index on DPF. 16

17 Best Practices Spreading Data Ranges can be placed in different tablespaces Different indexes of the same table in different tablespaces IX_TBSP 1 IX_TBSP 2 Index 1 Index 2 Index 3 TBSP 1 TBSP 2 TBSP 3 TBSP 3 TBSP 4 TBSP 5 Jan Mar May Jul Sep Nov data data data data data data Feb Apr Jun Aug Oct Dec data data data data data data 17 For partitioned tables, indexes are separate objects. Different indexes of the same table can be placed in different tablespaces. Individual indexes can be REORGed independently. Spread ranges across more than one tablespace to allow finer granularity of backups. Consider grouping current data for more frequent backup, infrequent backup of historical data. 17

18 Best Practices Data Placement for Backups DB2 9 allows restore from tablespace backups only Data spread over several small tablespaces Backup schedules are more flexible with more small backups Restore individual tablespaces (for roll-forward to end of logs) Separate active and historical data Historic data can be backed up less frequently Indexes contain references to active data, but can be rebuilt rather than restored IX_TBSP 1 IX_TBSP 2 Index 1 Index 2 Index 2 TBSP 1 TBSP 2 TBSP 3 TBSP 4 TBSP 5 TBSP 6 Jan Mar May Jul Sep Nov Feb Apr Jun Aug Oct Dec 18 With DB2 9, it is possible to restore the entire database starting with only tablespace backups. Thus, you can create a backup strategy that never requires a single backup of the full database. The ability to spread large tables across multiple tablespaces via table partitioning means that you can make each tablespace backup smaller. You still backup the same total amount of data, but you have flexibility to do it in more manageable chunks. Better yet, you can arrange the schedule to backup active data more frequently than historical data. Restores TO END OF LOG can also be more granular. That is, you can recover from a disk failure by restoring only the affected tablespaces. However, point in time roll-forward must include all tablespaces related to the table. 18

19 Best Practices Index Placement Separate indexes and table data to simplify size planning Size for each month s worth of table data is fairly predictable Co-habitation of indexes and table data OK, but complicates space planning Separating indexes necessary for some performance tuning (advanced topic) Different indexes of same table can be in different tablespaces Specify index placement at CREATE INDEX time Default placement is undesirable (all indexes will end up together with one range) IX_TBSP 1 IX_TBSP 2 Index 1 Index 2 Index 2 TBSP 1 TBSP 2 TBSP 3 TBSP 4 TBSP 5 TBSP 6 Jan Jan Jan Jan Jan Jan Feb Feb Feb Feb Feb Feb 19 Separation of indexes and table data is not at all required, rather it is suggested to simplify * space planning * backup strategy * some advanced performance tuning ends up putting indexes in separate tablespaces If you don t specify the tablespace when you do CREATE INDEX, it looks at what you specified For INDEX IN when you created the table. If you didn t specify this either, the index will be placed in the tablespace that held the first range at the time the table was created. Since indexes tend to be much larger than one range of the table, this often makes you run out of space unexpectedly. 19

20 Agenda Introduction Defining Partitioned Tables Roll-Out Performance Roll-In 20 20

21 Best Practices Roll-out via DETACH Use DETACH to roll-out a range of data Rolled-out data is available in a new, separate table Data disappears from view immediately upon DETACH Delete triggers do not fire for DETACH Rolled-out data can be dropped, archived, moved to HSM Queries are drained and table locked by DETACH Dependent refresh immediate MQTs go offline and need to be refreshed via SET INTEGRITY Example: ALTER TABLE sales DETACH PARTITION part_jan00 INTO jan00; 21 21

22 Asynchronous Index Cleanup AIC is a new feature to cleanup indexes Low priority background process Reclaims space in index (keys corresponding to data rolled-out) Automatically started when DETACH is committed (or after refresh of dependent MQTs) Pauses if would have gotten lock conflict with user activity Will NOT keep database active 22 The other thing that you should be aware of with DETACH is that index entries for the partition that has been detached need to be cleaned up. There is a new feature that does this for you automatically. It is triggered by the DETACH and runs as a low priority background process to remove all the index entries corresponding to data that has been rolled out. Meanwhile, the entries are present, but invisible to normal queries. Features that make AIC unobtrusive - Periodically checks for waiters and releases locks - Won t activate a database partition - Won t keep a database partition active if all applications disconnect 22

23 Table Availability for DETACH (No MQTs) OLD METHOD: DELETE DELETE available contention available NEW METHOD: DETACH DETACH ASYNCH INDEX CLEANUP available off line slight contention available 23 23

24 Table Availability for DETACH OLD METHOD: DELETE DELETE table MQTs available available contention contention available available NEW METHOD: DETACH ASYNCH INDEX CLEANUP table DETACH available off line contention slight contention available MQTs off line slight contention available REFRESH MQT 24 Refresh Immediate MQTs 24

25 Authorities for DETACH For the source table: ALTER + SELECT + DELETE For the target table, one of the following: SYSADM or DBADM or CREATETAB (database) and USE (tablespace) as well as one of IMPLICIT_SCHEMA CREATEIN 25 DETACH lets you move data from an existing table into a new table that is created as a result. So it would be a security hole if we did not require the authorization ID to have sufficient authorities to do all of these operations by other means. 25

26 Agenda Introduction Defining Partitioned Tables Roll-Out Performance Roll-In 26 26

27 Best Practices Combine with DPF Table (range) partitioning provides Scan parallelism (same as ordinary tables) Partition elimination ESE w/ DPF provides Query parallelism Divide and conquer for REORG and BACKUP Use both together for maximum benefit Use design guidelines for BCU unchanged 27 The benefits provided by table partitioning and ESE w/ DPF are distinct but complementary. Use both together to get all the benefits. The BCU concept provides design and sizing guidelines for configuring ESE w/ DPF. Because the effects of applying these features are independent, the guidelines in the BCU documents apply unchanged regardless of whether you are using table partitioning or not. 27

28 Partition Elimination (Table Scan) select * from tab1 where a>32 and a<54 scan a >= 0 a < 20 a >= 21 a < 40 a >= 41 a < 60 a >= 61 a < Partition elimination is the ability of the optimizer to determine that certain ranges don't need to be accessed at all for a query. This diagram shows how this works for a simple table scan. However, partition elimination also applies for index scans. Most real queries are going to make use of indexes. 28

29 Partition Elimination (Index Scan) Scan involving two indexes select l_shipdate, l_partkey, l_returnflag from lineitem where l_shipdate between '01/01/1993' and '03/31/1993 and l_partkey=49981 fetch fetch index anding present in both? partition elimination matching range? RIDs for date range RIDs for RIDs for l_shipdate l_partkey l_partkey 29 Many plans are possible for this query Without partitioning, one likely plan is index anding - Read all relevant index entries from each index - Save both sets of RIDs - Match them up to find which occurred in both indexes - Use those to fetch the rows With partitioning, each RID in the index contains the datapartid Look at this to discover if the row might be in the desired date range, instead of reading from the l_shipdate index Half the IO in indexes, much less memory w/o index anding In the partition elimination picture, everything happens in DMS + IXM That is, index anding passes RIDs back up to runtime, ands them, then goes back to kernel to fetch them In contrast, partition elimination skips irrelevant RIDs w/o ever returning them to runtime 29

30 Partition Elimination in DB2 Explain (1 of 3) Optimized Statement: SELECT Q1.L_SHIPDATE AS "L_SHIPDATE", AS "L_PARTKEY", Q1.L_RETURNFLAG AS "L_RETURNFLAG" FROM KBECK.LINEITEM AS Q1 WHERE (Q1.L_PARTKEY = 49981) AND (Q1.L_SHIPDATE <= '03/31/1993') AND ('01/01/1993' <= Q1.L_SHIPDATE) Access Plan: Total Cost: Query Degree: 1 RETURN ( 1) FETCH ( 2) / \ IXSCAN DP-TABLE: KBECK ( 3) LINEITEM INDEX: KBECK PIX 30 DP-TABLE: KBECK LINEITEM These slides point to table partitioning specific details of formatted explain output from db2exfmt. In the access plan, table partitioned tables are labeled as such with the tag DP- TABLE. 30

31 Partition Elimination in DB2 Explain (2 of 3) 3) IXSCAN: (Index Scan) Cumulative Total Cost: Cumulative CPU Cost: Cumulative I/O Cost: 1 Cumulative Re-Total Cost: Cumulative Re-CPU Cost: 7044 Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: 2 Arguments: DPESTFLG: (Number of data partitions accessed are Estimated) FALSE DPLSTPRT: (List of data partitions accessed) DPNUMPRT: (Number of data partitions accessed) 3 GLOBLOCK: (Global Lock intent) INTENT SHARE MAXPAGES: (Maximum pages for prefetch) 1 PREFETCH: (Type of Prefetch) NONE ROWLOCK : (Row Lock intent) NEXT KEY SHARE 31 List of data partitions accessed This query happens to scan only 3 partitions, numbered Look for List of data partitions accessed to see which partitions are to be scanned after irrelevant ones have Been excluded by partition elimination. 31

32 Partition Elimination in DB2 Explain (3 of 3) Predicates: ) Start Key Predicate Comparison Operator: Equal (=) Subquery Input Required: No Filter Factor: Predicate Text: (Q1.L_PARTKEY = 49981) DP Elim Predicates: 2) Stop Key Predicate Comparison Operator: Equal (=) Subquery Input Required: No Filter Factor: Predicate Text: (Q1.L_PARTKEY = 49981) Stop Predicate: (Q1.L_SHIPDATE <= Start Predicate: ('01/01/1993' <= DP Elim Predicates: Range 1) Stop Predicate: (Q1.L_SHIPDATE <= '03/31/1993') Start Predicate: ('01/01/1993' <= Q1.L_SHIPDATE) 32 When partition elimination is used, you can see the boundaries of the ranges scanned in the Predicates section. Look for the label DP Elim Predicates. Notice that the terminology used is the same as is used for index scans. Here you can see start and stop predicates from your query that delimit the portions of the table that will be scanned. 32

33 Best Practices Combine with MDC Query performance MDC best for querying multiple dimensions Table partitioning helps via partition elimination Use together for maximum benefit Design Advisor Define table partitioning first based on roll-out Design advisor, with ranges defined, will recommend appropriate MDC dimensions 33 33

34 Partition Elimination + MDC CREATE TABLE sales( ) PARTITION BY (sale_date) (STARTING 01/01/2001 ENDING 12/31/2005 EVERY 3 MONTHS) ORGANIZE BY (region, product) Q Q Q NW desk NW sofa NW desk NW desk NE table SW chair SW sofa SW chair SW sofa.... SW chair SW sofa NE desk NE table NE desk NE table NE desk NE table SE chair SE table SE chair SE sofa SE chair SE sofa 34 Here we have a table that is both table partitioned and organized by MDC. There are 2 MDC dimensions (region and product). The partitioning is by quarter, on the "sale_date" column. Here partition elimination can give you the same benefit that you might have gotten by having another MDC dimension for "quarter". To see why, notice that each MDC cell is split across multiple ranges. So a query that has sale_date in the WHERE clause will usually be able to apply partition elimination and end up scanning just the relevant portion of each cell. There are a couple of possible advantages to this: 1) Using table partitioning enables roll-in/roll-out via ATTACH/DETACH 2) Partition by range might allow you to avoid a generated column. For example, if you want to accomplish what is going on in this picture using MDC alone, you would need to introduce a generated column for "quarter". Table partitioning lets you avoid that. 34

35 Table Partitioning and MDC partitions MDC Q14 Q2 Q9 Q20 Q6 Q17 Q18 Q8 Q21 Q13 Q3 Q22 Q16 Q4 Q11 Q15a Q1 Q10 Q19 Q5 Q7 Q12 QppH QthH QphH This slide compares single dimension MDC on a date range and table partitioning Often you will want to combine DPF/MDC/range partitioning 35 35

36 Agenda Introduction Defining Partitioned Tables Roll-Out Performance Roll-In 36 36

37 Best Practices Roll-In Alternatives ADD + LOAD Best for majority of customers Minimize logging Entire table is read only, at best, during LOAD ATTACH + SET INTEGRITY Minimal disruption SET INTEGRITY takes place in one long transaction 37 37

38 Online Roll-In via ATTACH Create empty source table for roll-in Load data into the source table Perform any data transformation, cleansing ATTACH it to partitioned table ATTACH completes as soon as concurrent queries already running against fact table complete Example: alter table sales attach partition starting (' ') ending (' ') from sales_jul05; 38 38

39 Use SET INTEGRITY to Complete the Roll-in SET INTEGRITY does Index maintenance Checking of range and other constraints MQT maintenance Generated column maintenance Table is online through out process except for ATTACH New data becomes visible at end of SET INTEGRITY 39 When you do an ATTACH, you must follow up with SET INTEGRITY. This will incorporate the data into the indexes on the table. At the same time, it will also validate that the data is all within the boundaries defined for that range. SET INTEGRITY has been made online so that this longer running portion of roll-in can take place while applications continue to read and write the existing data in the table. 39

40 Comparison of Table Availability (DB2 9) LOAD + SI Extract, Transform, Cleanse Load Data LOAD Build Indexes SET INTEGRITY Constraints MQT maint available read only available ATTACH + SI Extract, Transform, Cleanse LOAD into source table ATTACH SET INTEGRITY Build Indexes Constraints MQT maint available off line 40 available The upper portion of this diagram shows table availability during roll-in for current versions (DB2 9). Prior to DB2 9, SET INTEGRITY was always offline. The lower portion shows a side by side comparison when using the new ATTACH operation to roll-in data. There are two key differences here. The first is that in the new scheme, since the load goes into a separate table, it has not impact whatsoever on the fact table. The second, is that SET INTEGRITY is now online, so the table will be available while SET INTEGRITY is running as well. The only period of when the table is not available is for a minute or less during the ATTACH. 40

41 Tips for Smoother Roll-in (1 of 2) Issue COMMIT WORK after ATTACH, SET INTEGRITY ATTACH locks whole table until committed New data is not visible after SET INTEGRITY until committed SET LOCK TIMEOUT WAIT Prevent SET INTEGRITY from failing on lock conflict at the end Plan for query draining by ATTACH ATTACH won t complete until it drains existing queries for the table Meanwhile, no new queries can start 41 ALLOW NO ACCESS will be faster cuz it gets an exclusive lock. How much faster? I should investigate this before the conference. 41

42 Tips for Smoother Roll-in (2 of 2) Use a single SET INTEGRITY statement Include all refresh immediate MQTs and the base table in the same SET INTEGRITY statement MQTs that are not refreshed in the first pass go off line Multiple SET INTEGRITY statements can mean more passes thru the data Specify ALLOW WRITE ACCESS with SET INTEGRITY The default is the old, offline behaviour Also available: ALLOW READ ACCESS Tradeoff: higher availability options may run slower Make use of exception tables Consider doing Roll-in and Roll-out together (aka rotate) ATTACH and DETACH in the same transaction minimizes the time that the table is unavailable 42 42

43 Authority for ATTACH For the target table: ALTER + INSERT For the source table, one of the following: SELECT (table) and DROPIN (schema), or CONTROL privilege, or SYSADM or DBADM authority 43 ATTACH effectively pulls data out of one table, puts it in another, then drops the original. There would be a security hole if we did not require that the authorization ID had sufficient privileges to accomplish this by other means. 43

44 Session: E08 Range Partitioning Fundamentals Kevin Beck IBM 44 44

45 Backup Slides 45 45

46 Table Partitioned MQTs MQTs can also be range partitioned Same advantages as for base tables Easy roll-in/roll-out Query performance via partition elimination Flexible space management Proper ranges must exist in MQT, else you can get SQL0327N out of bounds DETACH and ADD are supported ATTACH is not supported on partitioned MQTs ATTACH on the MQT is not needed if refreshed via SET INTEGRITY For case of user maintained MQTs, there is a workaround: Convert MQT to plain table Roll-in to base and MQT Use IMMEDIATE UNCHECKED to restore MQT 46 46

47 Table Partitioned MQTs Illustrated (1 of 3) Step 1, 2 Create new empty table, LOAD it base table Jan Data Feb Data Mar Data New Data LOAD MQT Jan Sum Feb Sum Mar Sum Step 3 Create and refresh MQT for new data base table MQT Jan Data Jan Sum Feb Data Feb Sum Mar Data Mar Sum New Data New Sum Refresh MQT 47 For step 3, you can create an MQT and refresh it 47

48 Table Partitioned MQTs Illustrated (2 of 3) Step 4 - Convert the MQT and staging MQT to plain tables ALTER TABLE <mqt> DROP MATERIALIZED QUERY; ALTER TABLE <staging_mqt> DROP MATERIALIZED QUERY; base table Jan Data Feb Data Mar Data New Data MQT as a plain table Jan Sum Feb Sum Mar Sum New Sum Step 5 ATTACH new data and MQT to base table and MQT table base table Jan Data Feb Data Mar Data Apr Data MQT as a plain table Jan Sum Feb Sum Mar Sum Apr Sum 48 48

49 Table Partitioned MQTs Illustrated (3 of 3) Step 4 - Convert the summary data back to an MQT ALTER TABLE <mqt> ADD MATERIALIZED QUERY ; SET INTEGRITY FOR <mqt> ALL IMMEDIATE UNCHECKED; base table Jan Data Feb Data Mar Data Apr Data MQT Jan Sum Feb Sum Mar Sum Apr Sum Step 4 SET INTEGRITY to complete the roll-in SET INTEGRITY FOR <base>, <mqt> ; base table Jan Data Feb Data Mar Data Apr Data MQT Jan Sum Feb Sum Mar Sum Apr Sum 49 49