ApsaraDB RDS:ApsaraDB for SQL Server インスタンスのストレージ不足の問題をトラブルシューティングする

分析

データファイルの合計サイズに等しいデータストレージの合計は、割り当て済みデータストレージと未割り当てデータストレージで構成されます。

• 割り当て済みデータストレージは、使用済みデータストレージと未使用データストレージで構成されます。未使用データストレージは、同じテーブルまたはインデックスの新しいレコードにのみ割り当てることができます。未使用データストレージを他のデータベースオブジェクトに直接割り当てることはできません。

• 未割り当てデータストレージは、割り当てられていないエクステントで構成されます。各エクステントは 64 KB の隣接ストレージを提供します。未割り当てデータストレージは、データベースオブジェクトに関連付けられていません。データファイルを縮小して、未割り当てデータストレージを解放できます。

ほとんどの場合、データ量が引き続き増加する場合、未割り当てデータストレージは小さくなります。この場合、データファイルを縮小することによって大量のデータストレージを再利用することはできません。データファイルを縮小する前に、割り当て済みデータストレージを最適化して再利用することをお勧めします。

データストレージを再利用する

次のいずれかの方法を使用して、データストレージを再利用できます。

• データファイルをアーカイブする

  頻繁に照会されない履歴データファイルを削除するか、これらのデータファイルを他の RDS インスタンスに移行するか、これらのデータファイルをアーカイブします。これにより、RDS インスタンスに保存されるデータ量が削減されます。

  この方法は、データストレージ消費の増加を効果的に軽減します。ただし、この方法には、データベースオブジェクト構造と アプリケーション のロジックに関する要件があります。また、この方法には、 アプリケーション 設計者および 開発者 との協力が必要です。

• データファイルを圧縮する

  RDS インスタンスが SQL Server 2016 以降を実行している場合、または SQL Server 2016 より前の SQL Server Enterprise Edition を実行している場合、データ圧縮機能が提供されます。この機能は、行圧縮とページ圧縮をサポートしています。この機能は、個々のテーブル、インデックス、またはパーティションで有効にできます。詳細については、「データ圧縮」をご参照ください。

  データ圧縮率は 10% から 90% の範囲で、スキーマ、列データ型、および数値の分布によって異なります。SQL Server は、指定されたテーブルまたはインデックスで圧縮を有効にすることで節約できるデータストレージ容量を迅速に評価するのに役立つ専用のストアドプロシージャ sp_estimate_data_compression_savings を提供します。

  説明

  • テーブルまたはインデックスの圧縮オプション設定を変更するには、データ定義言語（DDL）操作を実行する必要があります。これらの操作を大きなテーブルで実行すると、テーブルは長時間ロックされます。これにより、ワークロードが中断される可能性があります。オフピーク時に圧縮オプション設定を変更することをお勧めします。

  • RDS SQL Server Enterprise インスタンスは、パラメーター ONLINE を ON に設定してから、通常のビジネス運用への影響を最小限に抑えて変更操作を実行できます。

  • データ圧縮により、CPU オーバーヘッドが増加します。ビジネス要件に基づいて、RDS インスタンスでのデータ圧縮の実現可能性を評価する必要があります。大きなテーブルでのみデータ圧縮機能を有効にすることをお勧めします。

• インデックスをデフラグする

  インデックスの断片化の度合いが高い場合、インデックスの基礎となるデータは異常に大量のストレージを消費します。この場合、インデックスをデフラグして、使用済みデータストレージの量を削減できます。

  インデックスの断片化の度合いを表示する: ApsaraDB RDS コンソールにログインし、自律型サービス (CloudDBA) > 性能を最適化する を選択します。次に、[インデックスの使用状況] タブをクリックします。このタブでは、さまざまなテーブルのインデックスの断片化を表示できます。さらに、インデックスを再構築または再編成するために自律サービスによって提案された提案を表示できます。

  説明

  • インデックスの断片化の度合いは、論理順序がインデックス内の物理順序と一致しないページの割合を表します。この割合は、インデックスページ内のアイドルストレージ容量の割合とは異なります。通常のケースでは、断片化の度合いが高いインデックスは、ストレージ容量を再利用するためにデフラグされる可能性があります。

  • インデックスのページあたりのアイドルストレージの平均割合を分析する場合は、sys.dm_db_index_physical_stats システムビューを SAMPLED または DETAILED モードで照会できます。次に、返された結果の avg_page_space_used_in_percent 列の値を表示できます。詳細については、「sys.dm_db_index_physical_stats (Transact-SQL)」をご参照ください。システムは、クエリ中に多くのインデックスページを読み取ります。クエリ中にインデックスをデフラグすると、RDS インスタンスのパフォーマンスが低下する可能性があります。オフピーク時にインデックスをデフラグすることをお勧めします。

  • インデックスを再構築する

    この方法は、高い断片化率に対してより良い最適化結果とより高い実行効率を提供します。デフォルトでは、実行中はテーブルがロックされます。Enterprise Edition では、パラメーター ONLINE を ON に設定して、長期のテーブルロックを回避できます。

    重要

    大きなインデックスの場合、再構築操作により、短期間でデータベースストレージ容量とログサイズが大幅に増加する可能性があります。通常、インデックスの再構築操作を実行する前に、RDS インスタンスは再構築されるインデックスのサイズの少なくとも 2 倍を使用可能容量として予約する必要があります。したがって、インスタンスに十分な使用可能容量があることを確認してください。

    RDS インスタンスのストレージ容量を表示する: RDS インスタンス詳細ページの [基本情報] ページに移動します。[インスタンスリソース] セクションで、インスタンスの合計ストレージ容量サイズと使用済みストレージ容量サイズを表示します。

    ALTER INDEX <IX_YourIndexName> ON <YourTableName> REBUILD WITH (ONLINE = ON);

    コマンドが実行されると、システムはバックグラウンドで非同期的にデータを再収集します。これには時間がかかります。[再収集] ボタンをクリックして最新のデータを手動で収集し、データ収集が完了したら、[スクリプトのエクスポート] をクリックしてローカルにダウンロードし、インデックスの再利用ステータスを確認できます。

    

  • インデックスを再編成する

    この方法は、断片化の度合いが低い場合に適しています。ただし、最適化の有効性は、インデックス再構築方法ほど高くありません。

データファイルを縮小する

提案されたすべての解決策を試した後も使用可能なストレージが不足している場合は、次のいずれかの方法を使用してデータストレージを解放できます。

• 方法 1: データファイルをバッチで縮小します。一度に 5 GB のデータファイルを縮小することをお勧めします。サンプルコード：

  DECLARE @dbName NVARCHAR(128) = 'YourDatabaseName'  -- データベース名
  DECLARE @fileName NVARCHAR(128)  -- データファイル名
  DECLARE @targetSize INT = 1024   -- ターゲットサイズ（MB）
  DECLARE @shrinkSize INT = 5120   -- 一度に縮小するデータファイルのサイズ（MB）、一度に 5 GB をお勧めします
  DECLARE @currentSize INT         -- 現在のサイズ
  DECLARE @sql NVARCHAR(500)       
  DECLARE @waitTime INT = 10      -- 各縮小操作後に待機する時間（秒）
  
  -- データファイル名を取得する
  SELECT @fileName = name
  FROM sys.master_files
  WHERE database_id = DB_ID(@dbName)
  AND type_desc = 'ROWS'
  
  -- ループ縮小
  WHILE 1 = 1
  BEGIN
      -- 現在のファイルサイズを取得する
      SELECT @currentSize = size/128
      FROM sys.database_files
      WHERE name = @fileName
      
      -- ターゲットサイズに達したら終了する
      IF @currentSize <= @targetSize
      BEGIN
          PRINT '縮小完了、現在のサイズ: ' + CAST(@currentSize AS VARCHAR(20)) + 'MB'
          BREAK
      END
      
      -- この縮小操作後のサイズを計算する
      DECLARE @newSize INT = @currentSize - @shrinkSize
      IF @newSize < @targetSize
          SET @newSize = @targetSize
          
      -- 縮小操作を実行する
      SET @sql = 'DBCC SHRINKFILE (N''' + @fileName + ''', ' + CAST(@newSize AS VARCHAR(20)) + ')'
      PRINT '縮小を実行中: ' + @sql
      EXEC (@sql)
      
      -- 続行する前に一定時間待機する
      PRINT '続行する前に ' + CAST(@waitTime AS VARCHAR(10)) + ' 秒待機しています...'
      WAITFOR DELAY '00:05:00'
  END

• 方法 2：DBCC SHRINKFILE コマンドを実行して、個々のデータファイルを縮小し、未割り当てデータストレージを オペレーティングシステム に解放します。詳細については、「データベースの縮小」および「DBCC SHRINKFILE (Transact-SQL)」をご参照ください。

  DBCC SHRINKFILE(<ファイル ID>, <縮小後の予想ファイルサイズ（MB）>)

  展開してサンプルコードを表示する

  上記の例では、エクステントのサイズは 64 KB です。データファイルの合計サイズは (1673344 x 64)/1024 = 104584 MB で、割り当て済み容量は (1313432 x 64)/1024 = 82089.5 MB です。これは、圧縮後、データファイルの合計サイズが 82089.5 MB 未満になることはできないことを意味します。したがって、このデータファイルの合計サイズを 90000 MB にするには、次のコマンドを実行します。

  DBCC SHRINKFILE(1, 90000)

よくある質問

使用済みログストレージを表示する

ログストレージの再利用は比較的簡単です。DBCC SQLPERF(LOGSPACE) コマンドまたは自律サービスを使用して、データベースログファイルの使用済みログストレージの割合を表示できます。使用済みストレージの割合が高い場合、ログファイルを縮小しても効果はほとんどありません。システムビュー sys.databases を照会し、log_reuse_wait 列と log_reuse_wait_desc 列の出力情報をチェックして、容量を再利用できない理由を特定できます。

トランザクションログを縮小する

縮小操作が完了したら、RDS インスタンスの [監視とアラート] ページに移動して、最新のログストレージ使用量を表示できます。

分析

一時ファイルストレージは、tempdb システムデータベースで使用されるストレージ容量です。 tempdb システムデータベースは、SIMPLE 復旧モデルのみを使用します。通常のケースでは、tempdb システムデータベースのログファイルの合計サイズは小さくなります。ただし、tempdb システムデータベースのデータファイルの合計サイズは、短期間で大幅に増加する可能性があります。たとえば、多数の一時テーブルを作成したり、大きなテーブルを結合したり、データをソートしたりすると、tempdb システムデータベースのデータファイルの合計サイズが増加します。

解決策

• アプリケーションレベルでストレージ消費の増加を防ぎます。たとえば、不要な一時テーブルを減らし、大きなテーブルの結合を必要とするクエリを減らし、大きなトランザクションを実行しないでください。

• オフピーク時に RDS インスタンスを再起動します。再起動後、tempdb システムデータベースで使用されるストレージ容量は、インスタンスが作成されたときのサイズに減少します。

分析

その他のファイルストレージとは、sqlserver.other_size、mastersize、modelsize、msdbsize、およびその他の類似のファイルによって占有される容量を指します。ほとんどの場合、これらのファイルは小さくなります。ただし、これらのファイルは、次のシナリオで大量のストレージ容量を消費する可能性があります。

• 多数の errorlog ファイルが存在し、エラーログファイルのサイズが数 GB 以上に増加しています。

• 重大な例外が発生したときにメモリダンプファイルが生成されます。

解決策

1. RDS インスタンスの [監視とアラート] ページに移動し、[標準監視] タブをクリックして、これらのファイルによって占有されているストレージを表示できます。メトリックの詳細については、「標準監視を表示する」をご参照ください。

   

2. errorlog が大量のストレージを占有している場合は、[ログ管理] ページでエラーログをクリアできます。詳細については、「ログの管理」をご参照ください。

   説明

   他のファイル（sqlserver.other_size など）が容量を占有しすぎている場合は、ヘルプデスクに連絡してください。原因を特定し、問題を解決するお手伝いをいたします。