page196
282
ORDER BY warehouse_name,
start_time DESC;
SELECT v1.start_time,
v1.end_time,
v1.query_id,
v1.total_elapsed_time_in_secs,
v1.date_time
FROM v_warehouse_workload_by_hour v1
WHERE EXISTS
(
SELECT 1
FROM v_warehouse_workload_by_hour v2
WHERE v2.start_time <= v1.end_time
AND v2.end_time >= v1.start_time
AND v2.date_time = v1.date_time
AND v2.query_id != v1.query_id
)
AND v1.warehouse_name = '<YOUR_WAREHOUSE_HERE>'
AND v1.date_time = '<YOUR_DATE_TIME_HERE>'
ORDER BY v1.start_time DESC;
Scaling across should be avoided as this approach can both reduce concurrency and
increase costs, as explained within Chapter 6.
Next, check the logged information to ensure feed runtimes do not exceed the
service-level agreements (SLAs), and ensure each run completes before the next batch
cycle. You must prove there is no backlog accruing throughout the day, which unwinds
during the quiet times. Historical performance monitoring will prove very useful
in predicting future capacity issues, because trends often foretell future problems.
Assuming event logging is used, extracting the start time from the end time for each
process will determine the runtime. This is an exercise I leave to you for your further
investigation. Note that Chapter 6 contains information about event logging.
Having investigated the external factors that may have affected your feed, you
determine the warehouse is not overloaded and shows no signs of queueing. Analyzing
the recent query profiles does not show spills to disk or OOMs. The logged information
Chapter 8
parallelization