page139
122
7.
Day 10: At 09:30 the dropped table storage exits Fail-Safe, and the
view has 90 minutes of latency.
8.
Day 10: At 11:00 the view latency is complete, and the Fail-Safe
storage clears.
As exposed by the previous explanation, monitoring storage is not straightforward.
Throughout the remainder of this section, you work through the expected storage
timeline.
Data and Micro-partition Lifecycle
In this section I cover the performance time costs for
INSERT
,
UPDATE
, and
DELETE
. Recognize I have deliberately chosen to use an X-Small warehouse. I also
expose the hidden storage costs of Time Travel and Fail-Safe before discussing storage
implications for both cloning and replication.
Tune the design before implementing a single line of code.
Setting a Baseline
Using the view
v_table_storage_metrics
, let’s establish the starting point by identifying
your initial storage metrics for
LINEITEM_BASELINE
.
SELECT active_GB,
time_travel_GB,
failsafe_GB,
retained_for_clone_GB
FROM v_table_storage_metrics
WHERE path_to_object = 'TPC.TPC_OWNER.LINEITEM_BASELINE';
Figure 4-6 shows the expected outcome where all values are set to zero except
active_GB
.
Figure 4-6.
LINEITEM_BASELINE expected storage
ChaPTer 4
MiCro-ParTiTionS