Package: PRE_DISPATCH

Results from a published Predispatch Run.

Global-Roam Comments

We have chosen to configure the GR-MMS and Historical-MMS by choosing primary keys similar to option 2b to retain all the history.

AEMO's notes on storage options

There are 2 ways to define the Pre-dispatch table primary keys (PKs) to define which data is loaded to the database and which data is retained:

Option 1 (default)

Overwrite older records when they are succeeded by later versions for the same entity and period. This is the Data Model default and results in the consumption of far less storage. Data Model updates issued by AEMO target this configuration so participants implementing option 2a or 2b must maintain their changes when AEMO releases a new Data Model version.

PredispatchLoad: DateTime, DUID
PredispatchInterconnectorRes: DateTime, InterconnectorID,
PredispatchPrice: DateTime, RegionID
PredispatchPriceSensitivities: DateTime, RegionID
PredispatchInterSensitivities: InterconnectorID, DateTime
PredispatchRegionsum: DateTime, RegionID

Option 2a

Retain only the Pricing records for tables relating to Price data and Physical records for tables relating to Physical data (e.g. targets). Approximately 50 times more storage volumes than option 1.

PredispatchLoad: PredispatchSeqNo, DateTime, DUID
PredispatchInterconnectorRes: PredispatchSeqNo, DateTime, InterconnectorID,
PredispatchPrice: PredispatchSeqNo, DateTime, RegionID
PredispatchPriceSensitivities: PredispatchSeqNo, DateTime, RegionID
PredispatchInterSensitivities: PredispatchSeqNo, DateTime, InterconnectorID
PredispatchRegionsum: PredispatchSeqNo, DateTime, RegionID

Option 2b

Retain both Physical and Pricing data for Intervention runs. If Intervention cases are stored in entirety, you must select the data carefully. The logic is the same as for Dispatch, i.e. Intervention Pricing is always where Intervention = 0 and Physical data is where Intervention = PredispatchCaseSolution.Intervention for the same PredispatchSeqNo.

Doubles the storage of option 2a but ONLY for Intervened cases.

PredispatchLoad: PredispatchSeqNo, Intervention, DateTime, DUID
PredispatchInterconnectorRes: PredispatchSeqNo, Intervention,DateTime, InterconnectorID,
PredispatchPrice: PredispatchSeqNo, Intervention, DateTime, RegionID
PredispatchPriceSensitivities: PredispatchSeqNo, Intervention, DateTime, RegionID
PredispatchInterSensitivities: PredispatchSeqNo, Intervention, DateTime, InterconnectorID
PredispatchRegionsum: PredispatchSeqNo, Intervention, DateTime, RegionID

Notes:

The data in the PredispatchIS file is always ordered so the pdrLoader writes the relevant data first and discards the subsequent irrelevant data, or writes the subsequent data, depending on how the PKs are defined.

You may order the PKs in a different order, depending on your local requirements. Any decision to change the PK column composition or order must consider the functional and performance impacts to existing applications or queries.

The pdrLoader caches PK definitions for performance reasons so any change to the PKs requires a restart of the application.

The TRANSACTION_TYPE default in the PDR_REPORT_RECORDS management tables for PREDISPATCH* tables is UPDATE-INSERT. You can modify this to INSERT for Option 2b, as the attempt to first perform an update becomes redundant. This can improve load performance.