Beyond Migration: Using Database Migration Service for disk shrinking
Google Cloud’s Database Migration Service now supports disk shrinking for Cloud SQL for SQL Server, enabling storage cost reduction with minimal downtime by replicating to a smaller disk while the application remains online.
Database Migration Service (DMS) traditionally handles migrations but now supports Cloud SQL for SQL Server as a source, enabling continuous replication between instances. This allows SQL Server customers to use DMS for day-two operations like storage management, including disk shrinking, rather than just one-time migrations. By replicating data to a newly provisioned instance with a smaller disk, DMS minimizes application downtime while reclaiming unused storage space. The process avoids the hours-long downtime required by native disk shrinking, which scales with allocated disk size.
Cloud SQL’s automatic storage increase prevents outages during spikes, but deleted data leaves allocated disk space unused unless manually reclaimed. SQL Server’s AUTO_SHRINK is discouraged in production due to performance risks, so manual shrinking via DBCC SHRINKFILE releases space from database files but not the underlying persistent disk. DMS addresses this by enabling migration to a smaller disk while the application remains operational, reducing storage costs after events like data archiving or schema optimization.
To identify shrinking opportunities, Cloud Monitoring tracks two key metrics: database/disk/bytes_used for actual consumption and database/disk/quota for provisioned capacity. A significant gap between these metrics signals unused allocated space. Native storage shrink in Cloud SQL requires downtime proportional to disk size, which can extend for hours with multi-terabyte drives, making it impractical for production environments with strict SLAs.
DMS replicates data using a process similar to SQL Server log shipping, starting with a full backup and applying continuous transaction log backups to keep the target instance synchronized. Server-level objects like logins or jobs must be migrated manually, as DMS focuses on user databases. The cutover involves stopping application traffic, applying final logs, promoting the target instance, and repointing the application, ensuring minimal disruption while reducing storage costs.