Sizing WinCC Tag Logging: Single vs All Segments Explained

1. Overview

WinCC (TIA Portal and WinCC V7.x) stores historical tag and alarm data in a Microsoft SQL Server database. The archive is not a single monolithic file: it is split into segments, and each segment is a discrete pair of .mdf (primary data) and .ldf (transaction log) files placed under the project's ArchiveManager folder. Two parameters control how segments are created, how large they grow, and when old data is purged:

• Time period covered by a single segment (also called segment cycle)
• Time period of all segments (the rolling retention window)

Misconfiguring these two values is the most common cause of unbounded disk growth, SQL Server performance degradation, and missing historical data in trend controls. This reference documents the rules Siemens recommends and the file-system behavior the runtime actually exhibits.

For the canonical procedure in TIA Portal, see the official Siemens documentation: Defining the Log Size and Segmentation (RT Professional) - WinCC. The sizing model itself is described in the long-standing FAQ Entry ID 34473263.

2. Archive Database Structure

When you compile a WinCC project, the Runtime database generator creates the following folder hierarchy beneath the active project path:

<ProjectPath>\ArchiveManager
  ├─ TagLoggingFast\
  │    ├─ TLGF_20240101_000001.mdf
  │    ├─ TLGF_20240101_000001.ldf
  │    ├─ TLGF_20240108_000001.mdf
  │    └─ TLGF_20240108_000001.ldf
  ├─ TagLoggingSlow\
  │    └─ ...
  └─ AlarmLogging\
       └─ ...

Each pair of files represents one segment — a self-contained SQL Server database that the WinCC ArchiveManager attaches and detaches on the fly as time advances. The MDF holds compressed process values, the LDF holds the SQL transaction log. A single segment is the atomic unit of rotation: you cannot split it further, and the WinCC Runtime will never write to two segments at the same time for the same archive.

3. What "Single Segment" Means

The Time period covered by a single segment defines how long the WinCC ArchiveManager keeps writing into one MDF/LDF pair before closing it and opening a new pair. When the configured period elapses, the runtime:

1. Detaches the current segment database from the embedded SQL Server instance.
2. Creates a new MDF/LDF pair with a timestamped filename.
3. Continues inserting new tag values into the freshly created segment.

The period is selected per archive and applies independently to Tag Logging Fast, Tag Logging Slow, and Alarm Logging. Typical values are 1 day, 1 week, or 1 month. Siemens' sizing FAQ 34473263 treats the segment as a pair of files and explicitly notes that one segment = one MDF + one LDF.

4. What "All Segments" Means

The Time period of all segments defines the rolling retention window across the entire archive. The ArchiveManager continuously counts how many closed segments still fall within this window. The oldest segment whose timestamp falls outside the window is detached from SQL Server and deleted from disk.

For example, with:

• Single segment period = 1 day
• All segments period = 7 days

the runtime will keep at most 7 closed segment files plus the currently open one, giving you 7 full days of historical data in trends, the HMI, and SQL queries. On day 8, the segment from day 1 is removed.

5. Configuration Parameters

In WinCC Explorer (V7.x) the parameters live under Tag Logging > Archives > [Archive name] > Properties > Timed Corrected. In TIA Portal for WinCC Professional / RT Professional they live in Runtime settings > Logging, as documented in Defining the Log Size and Segmentation (RT Professional):

Both a time and a size condition exist. Whichever limit is reached first triggers the action (segment rotation for single-segment limits; segment deletion for all-segments limits).

6. The 200-Segment Performance Rule

Siemens' FAQ 34473263 warns that the embedded SQL Server instance becomes slow when too many segment databases are attached simultaneously. The practical ceiling verified by Siemens support and field engineers is:

"A maximum of 200 single elements connected to the SQL Server has proven to be a practical number." — Siemens Support FAQ 34473263

The 200 limit is across all three archives in the project:

• Tag Logging Fast
• Tag Logging Slow
• Alarm Logging

Therefore:

Segments_Fast + Segments_Slow + Segments_Alarm ≤ 200

Exceeding this number can cause:

• Slow trend refresh in the HMI
• Delayed alarm acknowledgements
• SQL Server timeout events in the WinCC diagnostics window
• Occasional gaps in the archive if the segment attach/detach cycle cannot keep up with the archive rate

7. Sizing Example: One Year of Retention

Assume you need to retain exactly one year of fast and slow tag data and one year of alarm data. The configuration recommended in the Siemens FAQ is:

One year is not an integer multiple of a week (52.18 weeks), so the FAQ suggests using 53 weeks as the total retention window to ensure that no partial week is truncated at year-end. The sum of 159 segments is well below the 200-segment ceiling, leaving 41 segments of headroom for growth, additional tags, or alarm sources.

8. Disk-Size Calculation

Once the segment count is fixed, the disk footprint is governed by the size of one segment. The Siemens FAQ 34473263 provides a worked example. The compression scheme used by the WinCC archive manager is lossless, so the dominant input variables are:

• N = number of tags in the archive
• A = number of archive events per second per tag (depends on acquisition cycle and on-change triggers)
• D = data type size in bytes (REAL = 4, BOOL = 1, INT = 2, etc.)
• T = segment duration in seconds

Uncompressed row count per segment:

Rows_per_segment = N * A * T

Approximate raw data per segment:

Size_raw = Rows_per_segment * (D + 16)  // 16 bytes overhead per row

With WinCC's archive compression the MDF on disk is typically 30%–60% of Size_raw. Always measure one real segment on the target hardware before extrapolating.

9. Worked Numerical Example

Project parameters:

• 500 tags in Tag Logging Fast
• 1-second acquisition, no on-change
• REAL data type (4 bytes)
• Segment period = 1 week = 604 800 s

Step 1 — rows per segment:

Rows = 500 * 1 * 604800 = 302 400 000

Step 2 — raw bytes per segment:

Size_raw = 302 400 000 * (4 + 16) = 6 048 000 000 B ≈ 5.63 GiB

Step 3 — on-disk MDF (assume 40% of raw):

MDF ≈ 0.40 * 5.63 GiB ≈ 2.25 GiB per segment

Step 4 — total disk for 53 weeks of Fast archive:

Total_Fast = 53 * 2.25 GiB ≈ 119 GiB

Add LDF overhead (10%–20% of MDF is normal for the transaction log) and Slow + Alarm contributions, and the final disk budget for one year of retention on this project is roughly 250–300 GiB. Always reserve 20% free space on the archive volume to keep SQL Server's internal operations performant.

10. Best Practices

1. Pick a segment period that is a clean divisor of the desired retention. 1 day / 30 days, 1 week / 4 weeks, 1 week / 52 weeks are all acceptable. Avoid odd units (1 day / 365 days is mathematically valid but produces 365 segments).
2. Use a multiple of at least 3. A 1:2 ratio gives the runtime no margin to close the previous segment and open the next under heavy load.
3. Stay well below 200 total segments. A budget of 150–160 leaves headroom for tags added during commissioning and for additional alarm sources.
4. Set both time AND size limits. The time limit ensures predictable rotation; the size limit protects the disk if the tag rate grows unexpectedly.
5. Document the formula in the project folder so the next engineer can re-derive the numbers from the tag list.
6. Monitor the ArchiveManager folder size via SNMP, PRTG, or a simple Windows scheduled task that writes the directory size to a log. A sudden growth spike usually means a tag is in an unintended acquisition storm.
7. Back up closed segments only when the runtime is stopped or when the segment is no longer the active one. Hot-copying an attached MDF risks corruption.
8. Always use a fixed-size, dedicated logical disk for the ArchiveManager path. Do not place it on the system drive or on a deduplicated volume.

11. Troubleshooting Matrix

12. Field-Proven Configuration Templates

The following templates are conservative starting points derived from the Siemens FAQ and from typical SCADA projects. Adjust the tag count and acquisition rates to your project, but keep the segment counts in the safe band.

All rows use a multiple of at least 7 and stay comfortably under the 200-segment ceiling. The 2-year template deliberately uses 4-week segments so that a single MDF stays below 4 GB, which keeps the embedded SQL Server responsive on long-running installations.

13. Differences Across WinCC Variants

The segment/retention model described here is consistent across the major WinCC products, but the path and editor change:

• WinCC V7.x (Classic): Archive properties edited in WinCC Explorer under Tag Logging and Alarm Logging. Folder: <Project>\ArchiveManager.
• WinCC Professional / RT Professional (TIA Portal): Edited in Runtime settings > Logging. Folder: <Project>\IM\ArchiveManager (V20) or <Project>\ArchiveManager (V16/V17). See Defining the Log Size and Segmentation (RT Professional).
• WinCC Comfort/Advanced Panels: Use a single CSV-based log, not SQL segments. The "Single/All segments" model does not apply.

14. Verification Procedure

After commissioning, validate the configuration with this checklist:

1. Open Windows Explorer and browse to the ArchiveManager\TagLoggingFast folder. Confirm that files are being created on the expected schedule (one new pair per segment period).
2. Open a trend in the HMI and request data older than the current segment. The data must appear, and the query must return within 2–3 seconds on a typical plant-floor PC.
3. Check the WinCC diagnostics window (start > WinCC > Tools > ApDiag) for SQL errors, timeouts, or "too many attached databases" warnings.
4. After one retention period, verify that the oldest segment is deleted and the free space on the archive volume matches the original budget.
5. Trigger a controlled power loss, restart the runtime, and confirm that the current segment is recreated and that no data is lost within the segment that was active at the time of the crash.

15. Frequently Asked Questions