Product: Mingcedar CONTROL

Data retention: periods and execution | Mingcedar

Location: Configuration Center → Data Retention (retention:manage permission).

Published 2026-10-25T12:48:42.628971186Z Updated 2026-10-25T12:48:42.628970365Z

<div class="manual-doc-article manual-doc-article-section"><h2 id="data-retention">Operating guide: Data retention: periods and execution</h2>

Set event, alarm, raw-trend and rollup retention to project requirements, then check background execution.

<h3 id="retention-select">1. Select the correct policy</h3>

<p>Location: Configuration Center → Data Retention (retention:manage permission).</p>

<ol>

<li>Inspect the four policy cards: Operation and Login Records, Alarm History, Trend Live Samples, and Trend Summary Curve.</li>

<li>Match missing operations to the event policy, alarm history to the alarm policy, and raw points or long-range rollups to the corresponding trend policy.</li>

<li>Open the policy and verify its drawer title and read-only Policy Code.</li>

<li>Record current online/total periods, enablement, expiry cleanup, and last execution.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Confirm the policy matches the target data class.</p>

</article>

<h3 id="retention-period">2. Set online and total retention days</h3>

<p>Total retention is measured from the original timestamp and is not added to online retention. For example, online retention of 30 days and total retention of 365 days work as follows.</p>

<ol>

<li>For events or alarms, Online Retention Days 30 moves older records to archive tables after 30 days.</li>

<li>Total Retention Days 365 retains data to age 365 days, not 395. Zero means permanent. A nonzero total must not be shorter than the online period.</li>

<li>Trend policies do not use online-to-archive table migration. Set Total Retention Days separately for raw samples and summary curves; expiry cleanup removes whole chunks.</li>

<li>Set Background Run Interval as needed. Batch Size appears under Advanced for event and alarm policies only and affects short-term database load.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Shortening total retention with cleanup enabled makes expired data eligible for deletion.</p>

</article>

<h3 id="retention-save">3. Save and confirm background execution</h3>

<p>Enable Policy and expiry cleanup are separate controls. Disabling either can allow history to keep growing.</p>

<ol>

<li>Set Enable Policy and Clean up after total retention expires according to the agreed requirements.</li>

<li>Click Save. When shortening total retention or re-enabling cleanup, review the Confirm Wider History Cleanup dialog. Reopen the policy to verify fields and switches.</li>

<li>After the background interval, refresh and inspect Last Run and Last Summary.</li>

<li>Check that recent records remain queryable and inspect expired ranges. Trend cleanup removes expired data chunks, not individual rows at their exact expiry second.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Check save and execution results separately. Monitor disk space when total retention is 0 or cleanup is disabled.</p>

<div class="doc-step-troubleshooting"><p><strong>If the result differs</strong></p><ul>

<li>Saved but Last Run unchanged: check enablement, interval, and service state.</li>

<li>Execution failure: preserve Last Summary and inspect the database and relevant service; repeatedly shortening retention does not address the cause.</li>

<li>Save outcome uncertain or version conflict: refresh the policy list and inspect current values before editing or submitting again.</li>

</ul></div>

</article>

</div>

<strong>Figure 1: Data retention policies</strong>

<p>The page lists Operation and Login Records, Alarm History, Trend Live Samples, and Trend Summary Curve, with retention periods, run intervals, and recent results.</p>

</figcaption>

</figure>

</div>