Optimizing WinCC V17 SQL Server TempDB for SSD Endurance

Overview: SSD Endurance and WinCC V17 SQL Server Behavior

WinCC Professional V17 (Runtime + Configuration) uses an embedded Microsoft SQL Server instance to host Tag Logging, Alarm Logging, and user archive data. On systems deployed in a redundant Server-Server pair (WinCC Server with RT Professional, redundancy mode), the runtime continuously commits buffered measurement, alarm, and configuration deltas to disk through the SQL Server transaction log, to a SQL Server tempdb scratch area, and to the Windows operating system TEMP folder where WinCC writes compressed intermediate (.cmp) buffer files.

On flash-based storage (SATA SSD, NVMe SSD, or M.2) the combination of small-block, synchronous, high-frequency writes can exhaust the drive's endurance budget long before the controller's wear-leveling tables reach steady state. Industrial IPCs (Siemens SIMATIC IPC227G, IPC277G, IPC477E, IPC547G, or third-party SIMATIC Rack PCs) that ship with a single SATA SSD as the OS/data volume are particularly exposed because the OS, WinCC project path, SQL data, SQL log, and Windows TEMP all sit on the same device.

This reference consolidates the configuration options that an engineer can apply on a V17 system to:

1. Move WinCC and SQL Server scratch writes off the primary SSD.
2. Constrain or eliminate the .cmp file flush frequency to the Windows TEMP folder.
3. Place a RAM-backed or Optane-backed caching layer in front of the SSD.
4. Exclude the WinCC directories from antivirus, Windows Search indexer, and VSS snapshots.

Scope: WinCC Professional V17 Update 1 through V17 Update 4 (WinCC Runtime Professional V17.x, Engineering in TIA Portal V17). SQL Server instances used by V17 ship as Microsoft SQL Server 2019 Standard or as a bundled WinCC-specific MSDE variant on smaller stations. SQL Server 2019 Express is not supported for WinCC Server roles, so the SSD-wear problem applies to licensed Server installations.

Root Cause: Where the High-Frequency Writes Originate

Three distinct write streams converge on the system drive during normal WinCC Runtime operation:

The .cmp files are an artifact of WinCC's internal buffering layer: the runtime aggregates tag value changes, compresses them, and stages them in the Windows TEMP folder before committing them into SQL Server. On a redundant pair, the standby server also receives the same data stream and stages its own .cmp files until the redundancy handshake completes and the data lands in the relational tables.

WinCC V17 SQL Server Architecture Details

WinCC Runtime Professional V17 uses a Microsoft SQL Server instance that is installed by the WinCC Setup as part of the "WinCC Server" role. The setup places the SQL Server service account, the system databases (master, msdb, model), and the default tempdb under C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\. The user databases CC_AlarmLog_<ProjectName>, CC_TagLog_<ProjectName>, and CC_UA_<ProjectName> are created during runtime startup inside the project path's AlarmManager subfolder.

Key behavioral facts that drive SSD wear:

• Recovery model: WinCC V17 leaves the runtime user databases in FULL recovery model. Without an explicit log backup plan, the transaction log (.ldf) grows on every commit until SQL Server stops accepting writes and the WinCC runtime begins to queue tag values in memory.
• Auto-growth: Default autogrowth is 10% with unrestricted growth. On a 50 GB drive this means log files can balloon by several GB before a human notices.
• tempdb configuration: Default 8 MB initial size, 10% unrestricted growth, single data file, single log file, located on the OS volume.
• Checkpoints: Default 1-minute automatic checkpoint on the user databases — every checkpoint flushes dirty buffers to disk.

The official WinCC V17 Information System documents this architecture in the manual "WinCC Professional V17 — Configuration & Runtime" under the chapters "Database System" and "Runtime Database Manager". See the Siemens Industry Online Support entry 109769506 — WinCC Professional V17 Documentation.

Moving the SQL Server tempdb Off the SSD

Microsoft's official tempdb database documentation and the Move System Databases article describe the supported procedure. For a WinCC Server V17 host the engineered sequence is:

1. Open SQL Server Management Studio (SSMS) and connect to the WinCC instance MSSQLSERVER.
2. Run SELECT name, physical_name FROM sys.master_files WHERE database_id = 2; to list current tempdb files.
3. For each tempdb file execute:

   ALTER DATABASE tempdb 
   MODIFY FILE (NAME = tempdev, FILENAME = 'D:\SQLData\tempdb.mdf');
   ALTER DATABASE tempdb 
   MODIFY FILE (NAME = templog, FILENAME = 'D:\SQLLogs\templog.ldf');
   GO

4. Restart the SQL Server service from services.msc (or via net stop MSSQLSERVER && net start MSSQLSERVER) while the WinCC runtime is stopped.
5. Delete the original tempdb files from C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\.

Recommended file layout for a WinCC V17 redundant pair:

Add I/O affinity and tempdb sizing per the Microsoft recommendation: one tempdb data file per logical processor up to 8, all of equal size, initial size 1 GB, autogrowth 512 MB unrestricted. Apply with:

ALTER DATABASE tempdb 
MODIFY FILE (NAME = tempdev, SIZE = 1024MB, FILEGROWTH = 512MB);
ALTER DATABASE tempdb ADD FILE (NAME = tempdev2, FILENAME = 'D:\SQLData\tempdb2.mdf', SIZE = 1024MB, FILEGROWTH = 512MB);
GO

Relocating the Windows TEMP Folder Used by WinCC .cmp Writes

Because WinCC resolves the system TEMP folder via the standard Windows environment variables %TEMP% and %TMP%, the supported path to move the .cmp destination is to relocate the Windows TEMP at the OS level for the user account under which the WinCC runtime service executes. WinCC runtime runs under the local system account or under a dedicated WinCC user — verify with services.msc → "Siemens S7DOS Help Service" and "WinCC Runtime" properties.

Procedure for the service account:

1. Stop the WinCC Runtime service and any redundancy partner service.
2. Create the new folder, e.g. D:\WinCCTemp\ and D:\WinCCTemp\Log\.
3. Set permissions: SYSTEM and the WinCC service user require Modify and Read & Execute.
4. Open System Properties → Advanced → Environment Variables. Change both TEMP and TMP for the system variables (not the user row):

   TEMP=D:\WinCCTemp
   TMP=D:\WinCCTemp

5. Reboot the server. Verify with echo %TEMP% from an elevated command prompt.

For redundancy, apply the identical change on the standby server. WinCC replicates the runtime project but not the Windows environment, so both nodes must be configured independently.

SQL Server Recovery Model and Log Backup Strategy

Switching the WinCC user databases from FULL to SIMPLE recovery model eliminates the requirement to back up the transaction log to mark VLFs as reusable. For most WinCC Runtime installations where tag logging data is intended as a rolling buffer (rotated by configurable archive size/time), the database is operationally equivalent to a write-once, read-many archive; SIMPLE recovery is the correct choice. Apply via SSMS or T-SQL:

ALTER DATABASE [CC_TagLog_<ProjectName>] SET RECOVERY SIMPLE;
ALTER DATABASE [CC_AlarmLog_<ProjectName>] SET RECOVERY SIMPLE;
GO

If business requirements mandate point-in-time recovery, keep FULL recovery and configure a SQL Agent job that runs every 15 minutes:

BACKUP LOG [CC_TagLog_<ProjectName>] 
TO DISK = 'D:\SQLBackups\TagLog_<ProjectName>_log.trn' 
WITH COMPRESSION, INIT;
GO

Both approaches prevent unbounded log growth on the SSD. Reference: Recovery Models (SQL Server).

RAM Disk Caching for the .cmp Stream

Because .cmp files are short-lived and self-rebuilding on each WinCC restart, a RAM disk is a defensible target for them. Common Windows RAM disk implementations include:

Recommended configuration for a WinCC Server V17 redundant node with 32 GB RAM:

• Create an 8 GB RAM disk on R: formatted NTFS, 64 KB cluster, mounted at boot.
• Set TEMP=R:\ and TMP=R:\ system environment variables.
• Add an OSFMount /a autoload entry in HKLM\Software\Microsoft\Windows\CurrentVersion\Run that rehydrates an empty folder structure before the WinCC service starts.
• Verify with fsutil fsinfo volumeinfo R: — output should report a virtual disk.

Intel Cache Acceleration Software (CAS) with Optane

When a RAM disk is not acceptable (memory headroom, system validation constraints), the next-best tier is Intel CAS paired with an Intel Optane 800P / 905P / P5800X accelerator. Intel CAS transparently caches hot read and write blocks in front of the SSD; only the cold footprint eventually reaches the NAND.

Deployment procedure for WinCC V17:

1. Install the Optane device as a secondary data drive (e.g. E:).
2. Install Intel CAS 3.0.x or newer. Verify the driver signature matches a WHQL release.
3. Create a caching tier with the Optane device as the cache and the primary SSD as the backing store.
4. Configure the cache mode to Write-Back with a write-policy threshold that allows the Optane to coalesce small WinCC writes.
5. Pin the WinCC project path (D:\Projects\<ProjectName>) and SQL data path (D:\SQLData, D:\SQLLogs) into the accelerated volume.
6. Set the eviction policy to LRU.
7. Monitor with cas_cli.exe --show-cache-stats for cache hit ratio — target ≥ 95% for write workload.

Limitations: Optane capacities (58 GB / 118 GB / 280 GB) constrain the cache size; the SSD still receives evicted writes, so Intel CAS reduces rather than eliminates SSD wear. For absolute elimination, combine RAM disk (for TEMP) + Intel CAS (for SQL paths).

Antivirus, Indexer, and VSS Exclusions

Each excluded process or directory reduces background write amplification:

• Windows Defender Real-Time Protection: Add process exclusions for WinCCRTPro.exe, s7omcsx.exe, sqlservr.exe. Add path exclusions for %TEMP%, the project path, D:\SQLData\, D:\SQLLogs\.
• Windows Search Indexer: Exclude the project path, SQL paths, and TEMP folder. Verify with Get-MgServicePrincipal PowerShell or the Indexing Options Control Panel applet.
• Volume Shadow Copy (VSS): Disable system-restore points on data volumes or at minimum exclude WinCC folders. vssadmin list shadowstorage shows current shadow storage.
• Windows Superfetch / SysMain: Disable on WinCC servers via sc config SysMain start=disabled followed by a reboot.
• Scheduled defragmentation: Disable on SSDs — TRIM only. defrag D: /O once at first deployment, then disable the task.

SSD Endurance Sizing for WinCC V17 Hosts

Calculate the SSD endurance requirement using the manufacturer's TBW (Terabytes Written) rating and the projected daily write volume. The formula:

Required TBW = DailyWriteVolume_GB × 365 × DesignLife_Years / 1024

Example: a redundant WinCC Server with 10,000 tags, 1-second archive cycle, 8-byte tag value + 24-byte overhead per write = 32 × 10,000 × 86,400 = 27.6 GB/day raw. With 5x write amplification on the SSD, effective daily write is ~138 GB/day. Over a 5-year design life:

Required TBW = 138 × 365 × 5 / 1024 ≈ 246 TBW

An enterprise SSD rated at 1,400 TBW (e.g., Samsung PM893 960 GB, 1.3 DWPD) comfortably exceeds this. A consumer SSD rated at 200 TBW does not. Industrial-grade SSDs (Swissbit, Apacer, Innodisk) typically quote 1–3 DWPD and include PLP (Power Loss Protection) capacitors that flush the DDR write buffer to NAND on power loss — a critical feature for SQL Server write integrity.

Azure Reference Architecture for SQL Server on SSD

For hybrid deployments where the WinCC archive is replicated to Azure SQL Managed Instance, the Microsoft Azure Ultra SSD SQL Server reference documents Ultra SSD as a backing volume for transaction logs, achieving sub-millisecond latency. The architectural pattern — hot data on Ultra SSD, warm data on Premium SSD, cold data on Standard HDD — translates directly to on-premises tiering with Optane / NVMe SSD / SATA SSD as the three tiers.

Verification Procedure After Configuration Changes

1. Stop and start the WinCC Runtime service.
2. Confirm TEMP resolution: cmd /c echo %TEMP% from an elevated prompt, executed as the service account via psexec -s cmd.
3. Confirm tempdb location: SELECT name, physical_name FROM sys.master_files WHERE database_id = 2;
4. Confirm recovery model: SELECT name, recovery_model_desc FROM sys.databases WHERE database_id > 4;
5. Run a 24-hour burn-in with the WinCC project at peak tag rate. Capture typeperf "\PhysicalDisk(_Total)\Disk Writes/sec" and typeperf "\PhysicalDisk(_Total)\Disk Write Bytes/sec" into a CSV.
6. Verify SSD SMART attributes via smartctl -A /dev/sda (Linux) or the manufacturer's Windows utility (Samsung Magician, Intel MAS). Track Total LBAs Written over 24 hours and project the 5-year endurance consumption.
7. Inspect D:\WinCCTemp\ with Get-ChildItem -Recurse | Group-Object Extension | Sort-Object Count -Descending to verify .cmp files are landing in the new location.
8. Test redundancy failover: stop the active server, confirm standby promotes within the configured switchover time, confirm .cmp files are recreated on the new active node.

Troubleshooting Matrix

FAQ