業務システムのSQL Serverで、数年分の履歴をBigQueryなどへ移して消した。データベースの中身は小さくなったのに、Cloud SQLのディスクの容量は変わらず、ストレージの費用も下がらない。こうした状態を、長い停止なしで解消する方法を、Google Cloudが公式ブログで紹介しました。
2026年11月3日の記事「Beyond Migration: Using Database Migration Service for disk shrinking」は、Database Migration Service（DMS）を、移行のときだけでなく日々の運用の道具として使う例です。小さいディスクの新しいインスタンスへデータを複製し続け、短い切り替えだけで移ります。この記事では、ディスクが縮まない理由、標準の縮小とDMSの使い分け、移らないものの準備と切り替え後の作業を整理します。
ファイルを縮めても、ディスクは縮まない
ブログによると、SQL Serverはデータを消すと、データファイル（.mdf、.ndf）の中の空いた領域を再利用できる印を付けます。トランザクションログ（.ldf）も、切り捨てで中に空きができます。ただし、ファイル自体は最大まで使った大きさを保ちます。AUTO_SHRINK を設定すれば縮みますが、索引の断片化と性能の負担が大きいため、本番では一般に推奨されないとブログは書いています。
DBCC SHRINKFILE で手動で縮めれば、ファイルの空きをディスクへ返せます。それでも、Cloud SQLの永続ディスクは最大まで割り当てた容量のままです。自動でストレージを増やす機能は容量不足の停止を防ぐために重要ですが、ブログの言葉では、多くの本番環境で容量は「上にしか動かない」ことになります。
ブログは、ディスクの縮小を検討する場面として次の3つを挙げています。
- 大量の古いデータを、低温のストレージやBigQueryへ移した
- 暴走したトランザクションや一時的な読み込みで自動増加が動き、要らない容量の費用を払っている
- 大きな表を別のサービスへ分けた、使っていない索引を消した、データを圧縮した
縮める余地があるかは、Cloud Monitoringの database/disk/bytes_used（実際の使用量）と database/disk/quota（割り当てた容量）を比べて判断します。データベースのファイルごとの割り当てと空きは、sys.database_files と FILEPROPERTY(name, 'SpaceUsed') で確かめるクエリがブログに載っています。
標準の縮小とDMSの使い分け
Cloud SQLには、割り当て済みで使っていない領域を回収する標準の縮小の機能があります。ブログによると、この方法は計画的な保守の時間を取れる場合に向きますが、停止の時間は割り当てたディスクの全体の大きさに比例し、数TBのディスクでは数時間の停止になることがあります。
Cloud SQLのドキュメントも、ディスクの大きさによっては停止がかなり長くなるとして、停止を短くしたい場合はDMSで小さい新しいインスタンスへ移すよう勧めています。標準の縮小は2026年4月6日のリリースノートで案内された機能です。対象はプライマリインスタンスだけで、共有コアのインスタンスでは使えず、Terraformにも対応していません。実行の前に gcloud sql instances get-storage-shrink-config を使うと、縮められる最小の大きさ（minimalTargetSizeGb）と作業時間の見込みを確かめられます。
その停止を取れない場合の代わりが、DMSです。小さいディスクで新しいCloud SQLのインスタンスを作り、既存のインスタンスから複製し続け、最後に短い切り替えだけを行います。ブログの比較の表は、次の内容です。
| 項目 | 標準の縮小 | DMSでの移行 |
|---|---|---|
| 停止の時間 | 長い（ディスクの大きさに比例） | 短い（切り替えの時間だけ） |
| IPアドレスと接続文字列 | 既存のIPアドレスを保つ | 新しいインスタンスへ向け直す |
| ログインやジョブなどサーバーのオブジェクト | 自動で保たれる | 手動かスクリプトで移す |
| ログインとデータベースのユーザーの対応 | 自動で保たれる | 別のSIDでログインを作り直すと孤立ユーザーになる |
DMSの複製の仕組みは、SQL Serverのログ配布に近いとブログは説明しています。
- 選んだユーザーのデータベースの完全バックアップ（.bak）を取り、新しいインスタンスに復元する
- トランザクションログのバックアップ（.trn）を取り続け、新しいインスタンスに適用してほぼ同時の状態に保つ
ブログは、同じプロジェクト、別のプロジェクト、別のリージョンのいずれのCloud SQLのインスタンスの間でも複製できると書いています。ただし、DMSの移行ガイドが挙げるのは同じプロジェクトと別のプロジェクトです。接続プロファイル、移行ジョブ、移行先のデータベース、バケットは1つのリージョンに置くよう書かれています。別のリージョンへ移す場合は、この条件を先に確かめてください。
ドキュメントにある条件と制限
Cloud SQL for SQL Serverを移行元にする方法は、2026年5月22日のDMSのリリースノートで一般提供（GA）と案内されました。ブログに書かれていない条件が、DMSのドキュメントにあります。
- gcloud CLIが必要: 移行元の接続プロファイルと移行ジョブは、Google Cloud CLIでしか作れません。コンソールでは進み具合を見られます
- 移行元のPITR: トランザクションログのバックアップを作るため、移行元でポイントインタイムリカバリ（PITR）を有効にします。移行用のユーザーを作り、権限を付けることも必要です
- 移行先のPITR: 移行の間は移行先で有効にできません。移行が終わってから有効にします
- データベースの数: バックアップを使う移行は、1つの移行ジョブで最大20個までです。1つの移行先のインスタンスで動かせる移行ジョブは1つです
- バックアップのバケット: 移行先のプロジェクトにCloud Storageのバケットを作ります。DMSは書き出したファイルを消さないため、14〜30日の保持期間の設定が勧められています。自動で作るバックアップは暗号化されません
- 費用: Cloud SQLへの同種の移行では、DMS自体の追加料金はありません。Cloud SQLとCloud Storageの料金はかかります
移らないものを、切り替えの前に作る
DMSはユーザーのデータベースの単位で複製するため、その外にあるものは自動では移りません。ブログが挙げる準備は次のとおりです。
- ログイン:
sp_help_revloginで元のインスタンスから書き出し、新しいインスタンスで作り直す。Cloud SQLでは、データベースフラグcloud sql enable sp_help_revloginを追加すると、このストアドプロシージャが入ります（ドキュメントの記載） - SQL Server Agentのジョブ: SSMSのオブジェクトエクスプローラーで「Script [Object] as > CREATE To」から書き出し、新しいインスタンスへ作る。ジョブの手順がオンプレミスのファイルのパスや、対応していないOSの依存を参照していないか確かめる
- リンクサーバー: 同じ方法で書き出す。作る前に、新しいインスタンスでリンクサーバーのデータベースフラグを有効にする。ブログは
cloudsql.linked_serversと書いていますが、Cloud SQLのドキュメントのフラグ名はcloudsql enable linked serversです - 拡張イベント: 同じ方法で書き出す
- TDE: 透過的データ暗号化を使う場合は、元のインスタンスから証明書を書き出し、新しいインスタンスへ取り込んでおく
- インスタンスの設定: データベースフラグ、Active Directory、Entra ID などの設定を、元と同じになるよう手で設定する
- PolyBase: 使っている場合は、データベーススコープの資格情報が動くようDMK（データベースマスターキー）を暗号化し直す
ディスクの大きさを決めるときは、トランザクションログと今後の増加の余裕を残すよう、ブログは書いています。具体的な量はブログにありません。標準の縮小のドキュメントは、再索引などに備えて、約100GBか現在の使用量の20%以上のうち大きいほうを残すよう勧めており、目安になります。
切り替えたあとの孤立ユーザー
切り替えのあとに確かめたいのが、データベースのユーザーがサーバーのログインと結び付かず、認証できなくなる「孤立ユーザー」です。ブログによると、新しいインスタンスでログインを作ると、元とは違うセキュリティ識別子（SID）が付きます。データベースの中のユーザーは元のSIDを持ったままのため、既定では孤立します。sp_help_revlogin を使えばSIDは保たれますが、別の方法でログインを作った場合は結び直しが要ります。
ブログは、Microsoftの手順にある次のクエリで孤立ユーザーを見つけ、ALTER USER で結び直す方法を示しています。
-- 孤立ユーザーを見つける（各ユーザーデータベースで実行）
SELECT dp.type_desc, dp.sid, dp.name AS user_name
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON dp.sid = sp.sid
WHERE sp.sid IS NULL AND dp.authentication_type_desc = 'INSTANCE';
-- 見つかったユーザーを新しいログインへ結び直す
ALTER USER [user_name] WITH LOGIN = [login_name];編集部の提案：手順書に入れておくこと
ブログの手順をもとに、実行の前に手順書へ入れておく点を提案します。
- 費用と停止の比較を先に出す。縮めた後の月々のストレージの差額と、標準の縮小で必要になる停止の時間（
get-storage-shrink-configの見込み）を並べ、DMSを使う手間に見合うかを判断します。DMSでは、切り替えまでの新しいインスタンスとバケットの費用も足します。小さいディスクや、夜間に停止できるシステムでは標準の縮小で足りる場合があります - サーバー単位のものの一覧を元のインスタンスから作る。ログイン、ジョブ、リンクサーバー、拡張イベント、TDE、フラグを一覧にし、新しいインスタンスで1つずつ確かめます
- 切り替えの手順と戻し方を決める。書き込みを止める時刻、最後のログの適用の確認、昇格、接続先の変更、孤立ユーザーの確認、新しいインスタンスのPITRの有効化を順に書き、問題があったときに元のインスタンスへ戻す条件も決めておきます
- 自動増加の設定を見直す。縮めた原因が一時的な読み込みなら、同じ作業でまた増えないよう、作業の手順やステージングの場所を見直します
データベースの停止を短くする別の告知として、AlloyDBのホットスタンバイの記事も参照してください。本番のデータベースへの変更を自動化する場合の注意は、AIエージェントが本番DBを削除した事件の記事で扱いました。
確認した範囲
2026年11月3日と6日に、Google Cloud公式ブログの記事「Beyond Migration: Using Database Migration Service for disk shrinking」（2026年11月3日）を直接取得し、本文の手順・名称・クエリ・比較の表を原文と照合しました（資料調査）。11月6日に、DMSとCloud SQLのドキュメントとリリースノート、Microsoftの孤立ユーザーの手順も確かめました。別のリージョンへ複製できるかどうかと、移行元のSQL Serverの対応版は確かめられていません（DMSの対応表はCloud SQLを移行元に挙げていません）。
sp_help_revloginの出力をCloud SQLで流せるかも含めて、Cloud SQLでの縮小や移行の検証はしていません。
業務システムのデータベースの運用や費用の見直しは、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Beyond Migration: Using Database Migration Service for disk shrinking（Google Cloud Blog、2026-11-03）
- About storage shrink（Cloud SQL for SQL Server）
- Shrink instance storage capacity（Cloud SQL for SQL Server）
- Migrate from a Cloud SQL for SQL Server instance（Database Migration Service）
- Known limitations（Database Migration Service for SQL Server）
- Database Migration Service release notes
- Configure database flags（Cloud SQL for SQL Server）
- Troubleshoot orphaned users（Microsoft Learn）
