page155
138
Having confirmed the data retention period, let’s drop the parent table.
DROP TABLE tpc.tpc_owner.partsupp_baseline;
And check whether storage has been affected by the earlier
UPDATE
; you may
experience latency.
SELECT path_to_object,
active_GB,
time_travel_GB,
failsafe_GB,
retained_for_clone_GB
FROM v_table_storage_metrics
WHERE path_to_object IN
( 'TPC.TPC_OWNER.PARTSUPP_BASELINE',
'TPC.TPC_OWNER.PARTSUPP_BASELINE_CLONE' );
Figure 4-15 shows the expected result where
active_GB
storage is allocated for active
or current micro-partitions.
Figure 4-15.
partsupp_baseline and partsupp_baseline_clone Active Storage
You must wait at least one day before storage migrates to
time_travel_GB
after
which time you expect to see the following:
•
The
active_GB
value reduces as any unreferenced micro-partitions
for the dropped parent table transition to
time_travel_GB
.
•
time_travel_GB
increases reflecting the unreferenced dropped
parent table micro-partitions.
•
When Time Travel data retention period for the dropped parent table
expires,
failsafe_GB
to increase and
time_travel_GB
to decrease.
During your testing, after three days, you found the storage did not migrate to
time_
travel_GB
. You suspect the default cluster key on the “parent” table did not cause micro-
partitions to be de-referenced.
ChaPTer 4
MiCro-ParTiTionS