When you run an initial (first-time) sync from an on‑premises SQL Server database to Azure SQL Database using SQL Data Sync, the local agent may fail with a disk-space error—even when the disk “looks” like it has free space. The reason is that the initial sync can generate large temporary files in the Windows TEMP location used by the Data Sync Agent.
This post explains the symptom, what’s happening under the hood, and the most practical mitigation: move the Data Sync Agent’s TEMP/TMP to a drive with sufficient space and restart the service.
Symptom
During an initial sync (commonly on-premises ➜ Azure), the sync fails while applying a batch file.
Error
You may see an error similar to:
Sync failed with the exception:
“An unexpected error occurred when applying batch file … .batch. See the inner exception for more details. Inner exception: There is not enough space on the disk …”
Microsoft Learn also calls out “disk insufficient space” scenarios for SQL Data Sync and points to the %TEMP% directory as the key location to check.
What’s actually happening (Root Cause)
1) Initial sync uses temp files on the agent machine
During initialization, the local agent can load data and store it as temp files in the system temp folder. This is explicitly called out in the Azure SQL Data Sync scalability guidance.
2) The agent can generate more than “just the batch files”
In practice, you’ll often see:
- Batch files (e.g., sync_*.batch)
- Extra temp files under folders like MAT_ / MATS_ that are used for internal processing (commonly described as “sorting”/intermediate work).
Internal field experience shared in the Data Sync support channel highlights that the MAT/MATS files can be much larger than the batch files—sometimes 8–10× larger than the data being synced for that table (especially during initialization).
3) Why “I still have free disk space” can be misleading
If your Data Sync Agent’s TEMP points to a system drive (often C:), it can fill quickly with temp batches + MAT/MATS files during the first sync—particularly for large tables or many tables being initialized. The Azure SQL Data Sync “large scale” guidance recommends ensuring the temp folder has enough space before starting initialization and notes you can move TEMP/TMP to another drive.
Mitigation (Recommended)
Option A — Move TEMP/TMP to a larger drive (recommended)
The Microsoft Azure Blog guidance for large-scale initialization is clear: move the temp folder by setting TEMP and TMP environment variables and restart the sync service.
Key point: change the variables for the same account running the Data Sync Agent service
Environment variables exist at user scope and machine scope, and the effective TEMP location depends on which account the agent service runs under.
A simple PowerShell approach (run elevated) is to read and set the variables at the appropriate scope. (Example shown below uses the standard .NET environment APIs.)
# Run in Administrator mode
# Get current values
[Environment]::GetEnvironmentVariable("TEMP","User")
[Environment]::GetEnvironmentVariable("TEMP","Machine")
# Set new values (examples)
[Environment]::SetEnvironmentVariable("TEMP","D:\TempUser","User")
[Environment]::SetEnvironmentVariable("TMP" ,"D:\TempUser","User")
# or machine scope:
[Environment]::SetEnvironmentVariable("TEMP","D:\TempMachine","Machine")
[Environment]::SetEnvironmentVariable("TMP" ,"D:\TempMachine","Machine")Important: After updating TEMP/TMP, restart the SQL Data Sync agent service so it picks up the new environment settings.
Option B — If you can’t log in as the service account: update TEMP/TMP in the registry for that account
If you need to change TEMP/TMP for a specific account without interactive logon, you can update the user environment variables stored in the registry.
General Windows guidance indicates:
- User environment variables live under HKEY_CURRENT_USER\Environment (and for other users, under that user’s SID hive loaded under HKEY_USERS).
A common approach is:
- Identify the service account SID (example commands such as WMIC are often used in practice).
- Open Registry Editor
- Navigate to:
HKEY_USERS\<SID>\Environment - Update TEMP and TMP to a path on a drive with sufficient space.
-
Restart the Data Sync service.
Option C — Clean up leftover sync temp files (when sync is NOT running)
In some cases, the “disk out of space” condition is caused by leftover sync files that were not removed (for example, if something had files open during deletion). Microsoft Learn suggests manually deleting sync files from %temp% and cleaning subdirectories only when sync is not in progress.
Validation checklist (after the change)
After moving TEMP/TMP and restarting the service, confirm:
- New temp path is being used
Initiate sync and check that new sync_*.batch / temp artifacts appear under the new folder. - Sufficient free space exists for initialization
Especially for large tables, ensure the chosen drive can accommodate temp growth during the first sync. - Rerun initial sync
Retry the initial sync after making the change.
Classification
- Symptom type: Agent side / initialization failure
- Primary root cause: Insufficient disk space on the TEMP location used by the Data Sync Agent during initial sync temp-file generation
- Fix type: Configuration / operational (move TEMP/TMP to a larger drive + restart agent service)
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }
Helpful references
Microsoft