Business Central のデータベースを Azure に BACPAC でエクスポートしようとすると、「コンテナーが出てこない」「Out of memory」「タイムアウト」など、現場では定番の壁に当たりがちです。本稿は 150 GB クラスの実データを前提に、権限（ロール）・ネットワーク・実行環境・Azure SQL の観点で“落ちる理由”を具体的に分解し、確実に通すための手順とチェックリスト、さらに運用の型まで一気通貫で解説します。
Business Central データベースを Azure へ BACPAC でバックアップできない問題 ― 何が起きているのか
目的は Azure SQL Database 上の Business Central データベース（約 150 GB）を BACPAC として Azure Storage に保存すること。しかし実際には次のような障害が頻発します。
- エクスポート先の ストレージ・コンテナーが一覧に表示されない
- 20–25 GB 程度で 「Out of memory」（主にクライアント/実行環境側）
- タイムアウト／ネットワークの切り分けが難しい
- どのロール（権限）ならエクスポートできるか不明確
以降では、上記 4 点を素早く潰すための「結論ファーストの手順」と、仕組みからの深掘りを併記します。
結論ファースト：最短で通すための実行手順
| ステップ | 具体的な対処 | 補足 |
|---|---|---|
| 1. 必要ロールを確認 | Azure SQL 側：対象 DB の db_owner（エクスポート時に指定する資格情報がこれを満たす） Business Central 側：管理操作は SUPER または BCAdmin 等の上位ロール Azure RBAC（管理プレーン）：ストレージ アカウントに対して Contributor 以上 データ プレーン（Blob）：Storage Blob Data Contributor（書き込み必須） | どれか 1 つでも不足するとコンテナーが表示されない／書き込めない。 |
| 2. ストレージ疎通テスト | Storage Explorer または AzCopy で任意ファイルの手動アップロード NSG・ファイアウォール・Private Endpoint・VNet サービスエンドポイントの影響を確認 RBAC 切り分けに SAS トークン（短期・最小権限）を使用 | RBAC 問題かネットワーク問題かを 5 分で切り分け可能。 |
| 3. タイムアウトの原因特定 | サーバー側：拡張イベント（XEvent）で long‑running クエリと attention を捕捉 履歴：Query Store で上位消費クエリ／期間を特定 現在値：DMV（メモリ グラント・待機事象）でボトルネックを把握 | Azure SQL Database でも全て利用可能。 |
| 4. メモリ不足対策 | エクスポート元 DB のスケールアップ（vCore / メモリ増。必要に応じて Business Critical / Hyperscale へ） 実行環境のメモリ増強（VM／Runbook／Self-hosted Agent 等を 64–128 GB+ に） SqlPackage.exe のタイムアウトを拡大（例：/p:CommandTimeout=0） | BACPAC 作成はクライアント側メモリ消費が激しい。まずは実行環境を太らせる。 |
| 5. 大容量 DB の代替手段 | 不要データをパージし BACPAC サイズを抑制（アーカイブ設計） 論理バックアップに固執せず、Azure SQL の PITR（ポイントインタイム復元）を主軸に アーカイブ DB を分離して分散取得（BACPAC の分割保存は非サポート） | 「移行・監査用 = BACPAC」「日常の復旧 = PITR」が基本設計。 |
| 6. 運用ベストプラクティス | 定期的に別環境へ インポート復元テスト を自動化（破損防止） Azure Monitor で storage_percent・dtu_percent（または vCore の CPU・メモリ相当）を監視 業務時間外の排他・負荷を避けるためジョブ窓口を固定、同時実行を制御 | バックアップは「取得」より復元検証が重要。 |
なぜ失敗するのか：仕組みから理解する
BACPAC の正体と限界
BACPAC は「スキーマ + データ」を含む論理エクスポートです。データは実体としては一括抽出（BCP レベル相当）で、巨大テーブルや LOB（NVARCHAR(MAX) / VARBINARY(MAX) など）が多いほど、クライアント側のメモリ・一時ディスク・圧縮 CPU を強く消費します。したがって、20–25 GB で止まる「Out of memory」は、DB 側ではなく実行ホスト側のボトルネックであることがほとんどです。
権限（ロール）が揃わないとコンテナーは見えない
Azure ポータルや自動化からエクスポート先コンテナーを選ぶ際、Azure RBAC と Blob のデータ プレーン権限の両方が必要です。RBAC でアカウントを見れても、Blob の Storage Blob Data Contributor がなければ書き込みに失敗します。RBAC の付与には伝播時間があるため、割り当て直後は反映を待つか、短寿命の SAS で即時検証するのが確実です。
ネットワーク／ファイアウォールの見落とし
ストレージ側のネットワーク制限（ファイアウォール + Private Endpoint）があると、一覧取得・書き込みがブロックされます。「信頼できる Microsoft サービスを許可」の有効化、VNet サービスエンドポイントの設定、DNS 解決（*.blob.core.windows.net → Private/パブリック）も要確認です。
ロール・権限を正しく整える（確実に一覧に出す）
| 対象 | 必要ロール（代表例） | ポイント |
|---|---|---|
| Azure SQL Database | db_owner | エクスポートで指定する SQL ユーザー/ログインが db_owner を満たすこと。 |
| Business Central（アプリ） | SUPER または BCAdmin 相当 | BC Online の管理操作でエクスポートをトリガーする場合に必要。 |
| Azure RBAC（管理プレーン） | Contributor 以上（ストレージ アカウント） | コンテナーの列挙・SAS 発行など管理操作に必要。 |
| Blob データ プレーン | Storage Blob Data Contributor | 実データを書き込むために必須。閲覧のみなら Reader。 |
RBAC トラブルを避けたいときは、事前に SAS を発行し、Storage Explorer → コンテナー直結でアップロードできるか試すのが最速です。SAS で通るのに RBAC で失敗するなら、割り当て範囲（サブスクリプション/リソース グループ/個別リソース）や伝播の問題に絞れます。
ストレージ疎通テストの具体例（最短 2 コマンド）
AzCopy での検証
REM 例：ローカルのテストファイルを BLOB へアップロード
azcopy copy "C:\temp\probe.txt" ^
"https://<account>.blob.core.windows.net/<container>?<SAS>" ^
--from-to=LocalBlob --overwrite=ifSourceNewer
これが通れば、少なくとも「実行ホスト → ストレージ」への 書き込み経路は生きています。失敗するなら、SAS/権限・DNS・NSG/Firewall/Private Endpoint へ観点を絞ります。
Storage Explorer での検証ポイント
- アカウント直結（RBAC）ではなく SAS URL 直結で試す（RBAC 問題の切り分け）
- コンテナー作成可否／ファイルのアップロード可否を確認
- 同一テナント／サブスクリプションの混在ミスに注意（権限の付け先）
タイムアウトの正体を掴む：XEvent・Query Store・DMV
クライアントの CommandTimeout による中断は、サーバーから見ると attention で表れます。つまり「サーバーが遅い」のか「クライアントが短気なのか」を、サーバー側の証跡で判定します。
拡張イベント（XEvent）での最小構成
-- DB スコープの拡張イベント：長時間処理と中断を捕捉
CREATE EVENT SESSION [bacpac_troubleshoot] ON DATABASE
ADD EVENT sqlserver.sql_batch_completed(
ACTION (sqlserver.client_app_name, sqlserver.username)
WHERE (duration > 300000) -- 300,000ms = 5 分
),
ADD EVENT sqlserver.rpc_completed(
ACTION (sqlserver.client_app_name, sqlserver.username)
WHERE (duration > 300000)
),
ADD EVENT sqlserver.attention(
ACTION (sqlserver.client_app_name, sqlserver.username)
)
ADD TARGET package0.ring_buffer;
GO
ALTER EVENT SESSION [bacpac_troubleshoot] ON DATABASE STATE = START; エクスポート実行中に attention が出ていれば、クライアントタイムアウトの可能性が高いと判断できます。
Query Store で上位消費クエリを特定
-- 直近 24 時間での平均実行時間上位トップ 20
SELECT TOP 20
rs.avg_duration, rs.avg_cpu_time, rs.avg_logical_io_reads,
qsq.query_sql_text
FROM sys.query_store_runtime_stats AS rs
JOIN sys.query_store_plan AS qp ON rs.plan_id = qp.plan_id
JOIN sys.query_store_query AS qs ON qp.query_id = qs.query_id
JOIN sys.query_store_query_text AS qsq ON qs.query_text_id = qsq.query_text_id
WHERE rs.last_execution_time > DATEADD(hour, -24, SYSUTCDATETIME())
ORDER BY rs.avg_duration DESC;
DMV でメモリ／待機の現在値を見る
-- メモリ グラントが詰まっていないか
SELECT *
FROM sys.dm_exec_query_memory_grants
ORDER BY requested_memory_kb DESC;
-- データベース スコープの待機統計
SELECT wait_type, SUM(wait_time_ms) AS wait_ms
FROM sys.dm_db_wait_stats
GROUP BY wait_type
ORDER BY SUM(wait_time_ms) DESC; メモリ グラント行が大量に滞留していれば、クエリ側のメモリ要求過多、あるいはサービス層のメモリ不足が疑われます。
「Out of memory」への現実解
多くの場合、BACPAC が 20–25 GB 前後で止まるのは ホスト（実行環境）の物理メモリ不足です。以下の順で対処します。
- 実行ホストを増強：64 GB 以上、できれば 96–128 GB の RAM を搭載。ページファイルはメモリ同容量以上。ディスクは高速 SSD。
- 64bit の SqlPackage.exe を使用（DacFx）し、OS/プロセスのアドレス空間制限に掛からないようにする。
- パラメータ調整：
/p:CommandTimeout=0（無制限）または十分大きい値。環境により/p:MaxParallelismを下げてピークメモリを平準化。 - エクスポート対象の見直し：アーカイブ完了済みの履歴テーブルを事前にスリム化（後述）。
- DB 側スケールアップ：一時的に vCore/メモリを増やし、スキャンの時間を短縮して全体のグリップ時間を圧縮。
SqlPackage.exe の典型コマンド
"C:\Program Files\Microsoft SQL Server\160\DAC\bin\SqlPackage.exe" ^
/Action:Export ^
/SourceServerName:"tcp:<server>.database.windows.net,1433" ^
/SourceDatabaseName:"<database>" ^
/SourceUser:"<user>" /SourcePassword:"<password>" ^
/TargetFile:"D:\backup\<database>_20251113.bacpac" ^
/p:CommandTimeout=0 ^
/p:MaxParallelism=4
ポータル経由の「エクスポート」はストレージへ直接吐き出せますが、SqlPackage.exe は基本的にローカル .bacpac を作成してからアップロードする運用が堅実です。I/O ボトルネックを避けるため、書き込み先ディスクの空き容量とスループットも事前に確認しておきましょう。
コンテナーが一覧に出ない／書き込めないときの特効薬
- RBAC を最小で整える：ストレージ アカウントに
Contributor、Blob にStorage Blob Data Contributor。サブスクやリソースグループに割り当てたつもりで別テナントだった、という誤配属に注意。 - SAS で即時検証：有効期限を短く・IP 制限付きで発行し、Storage Explorer/AzCopy でアップロードが通るかを確認。
- ネットワーク経路を簡略化：Private Endpoint 利用時は DNS 解決が Private を指すか、実行ホストのサブネットに必要な NSG/UDR が入っていないかを確認。
- ポータルのリージョン跨ぎに注意：アカウント/コンテナーは見えても、ポリシーやレイテンシでタイムアウトに寄与することがあります。可能なら同一リージョンに寄せる。
タイムアウトの再発防止：クライアント設定とジョブ設計
| 層 | 対策 | 備考 |
|---|---|---|
| クライアント（SqlPackage.exe/Runbook/Agent） | /p:CommandTimeout=0 もしくは 2–4 時間以上。再試行ロジックを挟む。 | 長時間実行は通常。無制限か十分大きい値で。 |
| ネットワーク | プロキシ/SSL インスペクションを迂回。443 の長時間セッション許可。 | SSL 終端やアイドル タイムアウトに注意。 |
| DB 側 | スケールアップ、統計更新、断片化の高いテーブルのメンテ。 | スキャン速度を底上げして総実行時間を短縮。 |
大容量 DB での現実的な選択：BACPAC と PITR の役割分担
BACPAC は「移行・監査・長期保管」向け、日々の事故復旧は PITR（ポイントインタイム復元）を主とするのが合理的です。150 GB クラスなら BACPAC 取得の頻度は週～月単位、PITR はサービス既定の保持期間内で容易に任意時点へ復元できます。BACPAC の「分割保存」はサポートされません。長期保管が必要なら、アーカイブ用 DB を切り分け、サイズを抑えた BACPAC を複数世代保存する設計が安全です。
Business Central ならではのスリム化ポイント
- 監査・履歴テーブル（Change Log 等）：運用で保持期間を見直し、アーカイブ/削除を徹底。
- 添付ファイル・BLOB：アプリ側の保管方針をクラウド ストレージ連携に寄せ、DB 直格納を削減。
- 「コピー用 DB」を作成してからエクスポート：本番と同一サーバー上で
CREATE DATABASE AS COPY OFを用いて静的コピーを作り、そちらで BACPAC を取得。ロック影響と変動データを回避。
テーブル別の重さを見つける（サイズと行数の可視化）
-- テーブルごとの行数とサイズ（MB）を概観
WITH s AS (
SELECT object_id, SUM(reserved_page_count) AS pages
FROM sys.dm_db_partition_stats
GROUP BY object_id
)
SELECT TOP 50
QUOTENAME(SCHEMA_NAME(o.schema_id)) + '.' + QUOTENAME(o.name) AS table_name,
p.rows,
CAST(s.pages / 128.0 AS DECIMAL(18,2)) AS reserved_mb
FROM sys.objects o
JOIN sys.partitions p ON o.object_id = p.object_id AND p.index_id IN (0,1)
JOIN s ON o.object_id = s.object_id
WHERE o.type = 'U'
ORDER BY reserved_mb DESC;
上位テーブルが把握できたら、アプリ側のアーカイブ方針を適用し、エクスポート前にデータ量を計画的に抑えます。
スケールアップ戦略：いつ・どの層へ増資するか
- DB サービス層：一時的に vCore を増やすか、I/O レイテンシ/メモリを改善できる層へ切り替え（例：General Purpose → Business Critical、または Hyperscale）。
- 実行環境：BACPAC はローカルに一時的な展開を行うため、RAM と高速ディスクが支配的。最優先で投資。
- ネットワーク：長時間・大容量のアウトバウンドが許される設計に（プロキシのアイドル タイムアウト、帯域制限に注意）。
現場で使えるチェックリスト（保存版）
| 症状 | 一次切り分け | 決め手となる検査 | 対処 |
|---|---|---|---|
| コンテナーが表示されない | RBAC 不足 or Storage Firewall | Storage Explorer（SAS 直結）でアップロード可否 | RBAC に Contributor + Storage Blob Data Contributor、Firewall 例外/Private Endpoint の確認 |
| 20–25 GB 付近で Out of memory | 実行ホストの物理メモリ不足 | タスクマネージャ/PerfMon でプロセスのコミット サイズ推移 | 64–128 GB RAM、ページファイル拡大、/p:MaxParallelism 調整 |
| タイムアウトで失敗 | クライアント側 CommandTimeout / ネットワーク | XEvent の attention、プロキシ/SSL ログ | /p:CommandTimeout=0、長時間セッション許可、スケールアップで時間短縮 |
| 書き込みで失敗 | Blob の権限不足 or Firewall | AzCopy のエラーコード／Storage Analytics | データ プレーン権限（書き込み）付与、SAS で再検証、ネットワーク例外 |
自動化の実装ヒント（PowerShell/Runbook/パイプライン）
# 1) 事前検証：AzCopy でストレージ疎通
$src = "C:\backup\bc.bacpac"
$dst = "https://<account>.blob.core.windows.net/<container>?<SAS>"
azcopy copy $src $dst --overwrite=ifSourceNewer
# 2) SqlPackage でエクスポート（タイムアウト無制限・並列制御）
$sqlpackage = "C:\Program Files\Microsoft SQL Server\160\DAC\bin\SqlPackage.exe"
& $sqlpackage /Action:Export ` /SourceServerName:"tcp:<server>.database.windows.net,1433"`
/SourceDatabaseName:"" ` /SourceUser:"<user>" /SourcePassword:"<password>"`
/TargetFile:$src `
/p:CommandTimeout=0 /p:MaxParallelism=4
# 3) 完了後にアップロード（再試行付与）
for ($i=0; $i -lt 3; $i++) {
$r = azcopy copy $src $dst --overwrite=ifSourceNewer
if ($LASTEXITCODE -eq 0) { break }
Start-Sleep -Seconds 60
} 長時間ジョブは一度の失敗でやり直しが重いので、途中成果物（ローカル .bacpac）を残す・ストレージへの転送は再試行の 2 段構えに分離しておくと運用が安定します。
よくある質問（FAQ）
Q. Azure SQL のサービス層を上げるだけで「Out of memory」は解決しますか？
A. いいえ。BACPAC のメモリは主に 実行ホストで消費されます。DB 側のスケールアップはスキャン時間短縮に効きますが、Out of memory そのものはホスト増強で対処します。
Q. BACPAC を分割して保存できますか？
A. いいえ。BACPAC の分割保存は非サポートです。サイズが巨大な場合は、アーカイブ DB を分離し、必要部分だけを BACPAC に切り出す設計へ舵を切りましょう。
Q. どのロールが足りないとコンテナーが見えませんか？
A. ストレージ アカウントの Azure RBAC（Contributor）に加え、Blob データ プレーンの Storage Blob Data Contributor が不足していると書き込み不可になりがちです。SAS での検証が切り分けの最短手です。
Q. タイムアウトはサーバー側にエラーとして残りますか？
A. クライアントの CommandTimeout は、サーバー側では attention として観測されるのが一般的です。XEvent/Query Store/DMV を用いた観測で、原因をサーバー or クライアントのどちらに寄せるかを決めましょう。
運用の型：失敗しないためのルーチン
- 毎回の事前健診：AzCopy の疎通、ディスク空き容量、RAM、ページファイル、タイムアウト値。
- 窓口一元化：BACPAC ジョブは業務時間外に限定し、リソースと同時実行数を制御。
- 復元演習：別環境へインポートし、スキーマ不整合・破損・性能を定期に検証。
- 監視：Azure Monitor / ログアラートで、CPU・ストレージ使用率・長時間クエリを可視化。
- ドキュメント化：成功条件（ロール・ネットワーク・コマンド）と失敗時の初動（XEvent 開始、AzCopy 検証等）を SOP（標準手順）化。
障害対応の決め台詞（テンプレート）
最後に、サポートへ調査を依頼する場合に添付して説得力が増す“ひな型”を載せておきます。これらが揃っていれば、再現性が上がり、解決までの往復を大幅に減らせます。
- 実行コマンド（SqlPackage.exe の全パラメータとバージョン）
- 実行ホスト情報（CPU/RAM/ディスク/OS/ページファイル/ネットワーク経路）
- 失敗時刻と相関ログ（XEvent の attention、Query Store の上位クエリ、AzCopy の出力）
- ストレージ側設定（RBAC、SAS、Firewall/Private Endpoint、リージョン）
- DB サービス層と同時実行状況（他の重いバッチの有無）
まとめ
- ロール不足とストレージ到達性が最初のハードル。RBAC + Blob データ プレーンを両輪で整える。
- 「Out of memory」はクライアント側を疑う。まずは実行ホストの RAM/ページファイル/ディスクを増強。
- タイムアウトはサーバー/クライアントのどちらか。XEvent（attention）・Query Store・DMV で事実ベースに切り分ける。
- BACPAC は論理、PITR は復旧。役割を分け、アーカイブ設計で BACPAC 自体を軽量化。
- 詰まったら、ログを揃えて SR を起票するのが最短ルート。
付録：トラブル実例と対処の全記録（サンプル）
事象：20 GB 付近でエクスポート失敗。ログは System.OutOfMemoryException。
環境：実行 VM 16 GB RAM、ページファイル 4 GB。DB は General Purpose 4 vCore。
対策：
- VM を 64 GB RAM・ページファイル 64 GB に拡大。エフェメラル OS ディスクから高速データディスクへ出力先を変更。
/p:MaxParallelism=2に下げ、ピーク メモリ使用量を平準化。- DB を一時的に 8 vCore へスケールアップ、統計更新を実施。
- ストレージは SAS で直結し、AzCopy の疎通を事前検証。
- XEvent を開始し、attention の有無を監視。
結果：実行時間は 2 時間 → 1 時間 20 分に短縮、BACPAC 生成に成功。XEvent 上の attention は発生せず。
付録：監視とメンテのクイック コマンド
-- 統計更新（サンプル、本番は業務窓口で計画的に）
EXEC sp_updatestats;
-- 断片化の高いインデックス検出（再構築/再編成の判断に）
SELECT
dbschemas.[name] AS schema_name,
dbtables.[name] AS table_name,
dbindexes.[name] AS index_name,
indexstats.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, 'SAMPLED') AS indexstats
INNER JOIN sys.tables dbtables ON dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas ON dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
WHERE indexstats.database_id = DB_ID()
ORDER BY indexstats.avg_fragmentation_in_percent DESC;
-- 容量サマリー（データ/ログ）
SELECT
(SUM(size) * 8.0) / 1024 AS total_mb
FROM sys.database_files; 最後に
「コンテナーが見えない」「Out of memory」「タイムアウト」は、感覚的にはバラバラでも、権限・疎通・ホスト資源の 3 本柱で系統立てて潰せます。この記事の手順とスクリプトをテンプレート化し、まずは 1 回、確実に通してください。そこからは監視と復元演習をルーチン化し、トラブルを“イベント”ではなく“運用”に変えていきましょう。
コメント