Expert Oracle Exadata - Parent Directory

CHAPTER 13 MIGRATING TO EXADATAIn this example the source table is still range-partitioned by order_date, but it is hash partitioned to64 subpartitions. As it’s not possible to send the SUBPARTITION clause through the database link, either,we have used the ORA_HASH function to fetch only the rows belonging to the first hash subpartition of 64total subpartitions. The ORA_HASH SQL function uses the same kgghash() function internally, which isused for distributing rows to hash partitions and subpartitions. If we had 128 subpartitions, we wouldchange the 63 in the SQL syntax to 127 (n – 1).As we would need to transfer all the subpartitions, we would copy other subpartitions in parallel,depending on the server load of course, by running slight variations of the above query and changingonly the target subpartition name and the ORA_HASH output to corresponding subpartition position.INSERT /*+ APPEND */INTOfact SUBPARTITION ( Y20080101_SP02 )SELECT*FROMfact@sourcedbWHEREorder_date >= TO_DATE('20080101 ', 'YYYYMMDD ')AND order_date < TO_DATE('20080102', 'YYYYMMDD ')AND ORA_HASH(customer_id, 63, 0) + 1 = 2And so you’ll need to run a total of 64 versions of this script:... INTO fact SUBPARTITION ( Y20080101_SP03 ) ... WHERE ORA_HASH(customer_id, 63, 0) + 1 = 3...... INTO fact SUBPARTITION ( Y20080101_SP04 ) ... WHERE ORA_HASH(customer_id, 63, 0) + 1 = 4......... INTO fact SUBPARTITION ( Y20080101_SP64 ) ... WHERE ORA_HASH(customer_id, 63, 0) + 1 = 64...If your table’s hash subpartition numbering scheme in the subpartition name doesn’t correspond tothe real subpartition position (the ORA_HASH return value), then you’ll need to queryDBA_TAB_SUBPARTITIONS and find the correct subpartition_name using the SUBPARTITION_PO/SITIONcolumn.There’s one more catch though. While the order_date predicate will be used for partition pruning inthe source database, the ORA_HASH function won’t—the query execution engine just doesn’t know how touse the ORA_HASH predicate for subpartition pruning. In other words, the above query will read all 64subpartitions of a specified range partition, then the ORA_HASH function will be applied to every rowfetched and the rows with non-matching ORA_HASH result will be thrown away. So, if you have 64sessions, each trying to read one subpartition with the above method, each of them would end upscanning through all subpartitions under this range partition, this means 64 × 64 = 4096 subpartitionscans.We have worked around this problem by creating views on the source table in the source database.We would create a view for each subpartition, using a script, of course. The view names would follow anaming convention such as V_FACT_Y2008010_SP01, and each view would contain the SUBPARTITION( xyz ) clause in the view’s SELECT statement. Remember, these views would be created in the sourcedatabase, so there won’t be an issue with database links syntax restriction. And when it’s time tomigrate, the insert-into-subpartition statements executed in the target Exadata database wouldreference appropriate views depending on which subpartition is required. This means that some largefact tables would have thousands of views on them. The views may be in a separate schema, as long as4411