giip
SES 안건 등록
SQL Serverストレージログファイルインデックス性能

DBCC SHRINKDATABASE와 DBCC SHRINKFILE의 차이와 실행 전 확인 사항

公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13

結論

`DBCC SHRINKDATABASE`는 데이터베이스 내의 모든 파일을 대상으로, `DBCC SHRINKFILE`은 지정한 파일 하나만을 대상으로 축소합니다. 데이터 파일의 축소는 페이지를 이동시키므로 실행 후 인덱스 단편화가 크게 진행됩니다. 정기 유지보수로 수행해야 할 작업이 아닙니다. 반면 로그 파일의 축소는 비대해진 부분을 되돌리는 타당한 작업일 수 있지만, 그 전에 `log_reuse_wait_desc`의 원인을 해소해 두어야 합니다.

この文書の適用条件

対象製品SQL Server / Amazon RDS for SQL Server / Azure SQL Managed Instance
確認バージョンSQL Server 2008 이후
適用環境온프레미스, EC2, Amazon RDS, Azure
必要権限sysadmin 고정 서버 역할 또는 db_owner 고정 데이터베이스 역할
実行影響페이지 이동과 파일 크기 변경을 수반합니다. 실행 중에는 I/O가 증가하고 대상 개체에 대한 접근이 느려집니다
再起動불필요
最終検証日2026-08-13

そのまま実行できるコマンド

실행 전 확인: 파일별 사용량과 여유 공간(참조 전용)参照のみ
対象
SQL Server 2008 이후 / Amazon RDS for SQL Server
権限
대상 DB에 대한 연결 권한
変更作業
없음(참조만)
Production実行
가능
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象DBへの接続権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
USE [SampleDB];
GO
SELECT
    f.file_id,
    f.name                                              AS logical_name,
    f.type_desc,                                        -- ROWS(データ)/ LOG(ログ)
    f.physical_name,
    f.size * 8 / 1024                                   AS size_mb,
    CAST(FILEPROPERTY(f.name, 'SpaceUsed') AS bigint) * 8 / 1024 AS used_mb,
    (f.size - CAST(FILEPROPERTY(f.name, 'SpaceUsed') AS bigint)) * 8 / 1024 AS free_mb,
    CASE
        WHEN f.is_percent_growth = 1 THEN CAST(f.growth AS varchar(10)) + ' %'
        ELSE CAST(f.growth * 8 / 1024 AS varchar(10)) + ' MB'
    END                                                 AS autogrowth,
    CASE
        WHEN f.max_size IN (-1, 268435456) THEN NULL
        ELSE f.max_size * 8 / 1024
    END                                                 AS max_size_mb
FROM sys.database_files AS f
ORDER BY f.type_desc, f.file_id;

먼저 "실제로 여유 공간이 있는지"를 확인합니다. `free_mb`가 작은 파일은 축소해도 효과가 없습니다. 축소할 수 있는 것은 미사용 영역뿐입니다.

실행 전 확인: 로그가 해제되지 않는 이유(로그 축소의 전제 조건)参照のみ
対象
SQL Server 2008 이후 / Amazon RDS for SQL Server
権限
`sys.databases`의 메타데이터 가시성
変更作業
없음(참조만)
Production実行
가능
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: sys.databases のメタデータ可視性
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    name                  AS database_name,
    recovery_model_desc,
    log_reuse_wait_desc,
    is_auto_shrink_on
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

`log_reuse_wait_desc`가 NOTHING 이외인 채로 로그를 축소해도, 그 원인이 남아 있는 한 다시 확장됩니다. 로그 축소의 전제 조건은 이 열이 NOTHING이 되는 것입니다. `is_auto_shrink_on`이 1인 경우 자동 축소가 활성화되어 있으므로 비활성화를 검토하십시오.

로그 파일 끝부분 절단(TRUNCATEONLY·데이터 이동 없음)
対象
SQL Server 2008 이후 / Amazon RDS for SQL Server
権限
sysadmin 또는 db_owner
変更作業
있음(파일 끝부분의 미사용 영역을 OS에 반환)
Production実行
실행 가능. 다만 `log_reuse_wait_desc` 해소가 전제
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: sysadmin または db_owner
-- 変更作業: あり(ファイル末尾の未使用領域を OS に返却)
-- Production 実行: 可能。ただし log_reuse_wait_desc が NOTHING であることが前提
USE [SampleDB];
GO
-- 末尾の未使用領域だけを解放する(ページ移動を伴わない)
DBCC SHRINKFILE (N'SampleDB_log', TRUNCATEONLY);

-- 目標サイズ(MB)を指定して縮小する
-- DBCC SHRINKFILE (N'SampleDB_log', 1024);

`TRUNCATEONLY`는 파일 끝부분의 미사용 영역만 반환하며 데이터 이동은 수행하지 않습니다. 로그 파일에서는 가상 로그 파일(VLF)의 사용 현황에 따라 끝부분이 사용 중이면 예상대로 축소되지 않는 경우가 있습니다. 그 경우 로그 백업 또는 체크포인트 후에 다시 실행합니다. 또한 이 기술 자료에서는 실제 영향의 크고 작음에 관계없이 SHRINK 계열 작업을 모두 "높음"으로 표시합니다. 사전 확인 없이 실행하지 않도록 하기 위한 표시 방침으로, 이 작업이 목표 크기를 지정하는 축소와 같은 영향을 가진다는 의미는 아닙니다.

데이터 파일 축소(단편화를 초래하므로 원칙적으로 비권장)
対象
SQL Server 2008 이후 / Amazon RDS for SQL Server
権限
sysadmin 또는 db_owner
変更作業
있음(페이지를 이동시켜 파일을 축소. 인덱스 단편화가 진행됨)
Production実行
원칙적으로 불가. 실시할 경우 유지보수 시간대와 재구축 계획을 함께 준비할 것
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: sysadmin または db_owner
-- 変更作業: あり(ページ移動によりインデックス断片化が大きく進む)
-- Production 実行: 原則不可。メンテナンス時間帯+事後のインデックス再構築が前提
USE [SampleDB];
GO
-- 目標サイズ(MB)を指定してデータファイルを縮小する
DBCC SHRINKFILE (N'SampleDB', 8192);

-- 末尾の未使用領域だけを返す(ページ移動なし・断片化の影響が小さい)
-- DBCC SHRINKFILE (N'SampleDB', TRUNCATEONLY);

목표 크기를 지정한 축소는 파일 끝부분의 페이지를 여유 영역으로 이동시킨 후 끝부분을 잘라냅니다. 이 이동이 논리적인 정렬 순서를 무너뜨려 인덱스 단편화를 크게 진행시킵니다. 파일 끝부분만 반환하는 `TRUNCATEONLY`는 페이지 이동을 하지 않으므로 단편화 관점에서는 영향이 작아집니다.

데이터베이스 전체 축소(영향이 가장 큼)
対象
SQL Server 2008 이후 / Amazon RDS for SQL Server
権限
sysadmin 또는 db_owner
変更作業
있음(데이터베이스 내 모든 파일을 대상으로 페이지 이동과 축소)
Production実行
원칙적으로 불가. 실시할 경우 업무 정지에 상응하는 영향을 예상할 것
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: sysadmin または db_owner
-- 変更作業: あり(全ファイル対象のページ移動と縮小)
-- Production 実行: 原則不可。業務停止相当の影響を見込み、事後の再構築計画を用意すること
USE [SampleDB];
GO
-- 第2引数は「縮小後にファイルに残す空き領域の割合(%)」
DBCC SHRINKDATABASE (N'SampleDB', 10);

-- 末尾の未使用領域だけを返す
-- DBCC SHRINKDATABASE (N'SampleDB', TRUNCATEONLY);

`DBCC SHRINKDATABASE`는 데이터베이스 내의 모든 파일(데이터·로그)을 대상으로 합니다. 대상을 선택할 수 없어 영향을 예측하기 어려우므로, 실무에서는 `DBCC SHRINKFILE`로 파일을 하나씩 다루는 것이 제어하기 쉽습니다. 두 번째 인수인 `target_percent`는 "축소 후 남길 여유 공간의 비율"이며 축소율이 아닙니다.

실행 후 확인: 인덱스 단편화 현황
対象
SQL Server 2008 이후 / Amazon RDS for SQL Server
権限
대상 DB에 대한 연결 권한과 VIEW DATABASE STATE
変更作業
없음(참조만. 다만 페이지를 읽으므로 I/O가 발생함)
Production実行
가능. `LIMITED` 모드로 실행할 것
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象DBへの接続権限と VIEW DATABASE STATE
-- 変更作業: なし(参照のみ。ただしページを読むため I/O が発生する)
-- Production 実行: 可能。DETAILED は負荷が高いため LIMITED を使うこと
USE [SampleDB];
GO
SELECT
    OBJECT_SCHEMA_NAME(ips.object_id) AS schema_name,
    OBJECT_NAME(ips.object_id)        AS table_name,
    i.name                            AS index_name,
    ips.index_type_desc,
    ips.avg_fragmentation_in_percent,
    ips.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') AS ips
INNER JOIN sys.indexes AS i
        ON ips.object_id = i.object_id
       AND ips.index_id  = i.index_id
WHERE ips.page_count > 1000        -- 小さいインデックスは断片化の影響が小さい
ORDER BY ips.avg_fragmentation_in_percent DESC;

축소 전후로 같은 쿼리를 실행하여 `avg_fragmentation_in_percent`의 변화를 비교하십시오. `DETAILED` 모드는 모든 페이지를 읽으므로 부하가 높아 운영 환경에서는 `LIMITED`를 사용합니다.

AUTO_SHRINK 비활성화
対象
SQL Server 2008 이후 / Amazon RDS for SQL Server
権限
sysadmin 또는 db_owner(ALTER 권한)
変更作業
있음(데이터베이스 옵션 변경)
Production実行
실행 가능. 비활성화는 데이터베이스 옵션 변경으로 관리할 것
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: sysadmin または db_owner(ALTER 権限)
-- 変更作業: あり(データベースオプションの変更)
-- Production 実行: 可能。変更管理の手順に従うこと
ALTER DATABASE [SampleDB] SET AUTO_SHRINK OFF;

-- 現在の設定を確認する(参照のみ)
SELECT name, is_auto_shrink_on
FROM sys.databases
WHERE database_id > 4;

AUTO_SHRINK는 기본적으로 비활성화되어 있습니다. 활성화되어 있으면 축소와 자동 확장이 반복되며, 그때마다 페이지 이동에 의한 단편화와 확장 대기가 발생합니다. 활성화되어 있다면 비활성화를 검토하십시오.

結果の読み方

意味確認するポイント
type_desc파일의 종류(ROWS / LOG)데이터 파일과 로그 파일은 축소의 타당성이 완전히 다름
size_mb파일의 현재 크기축소 전 값을 기록해 둘 것
used_mb실제로 사용 중인 용량이보다 더 작게는 축소할 수 없음. 목표 크기는 이보다 크게 설정
free_mb미사용 영역작으면 축소해도 효과가 없음. 실행 필요 여부를 여기서 판단
autogrowth자동 확장 설정축소 후 재확장이 발생함을 전제로 확장량이 적절한지 확인
log_reuse_wait_desc로그가 재사용되지 않는 이유NOTHING이 아닌 한 로그 축소는 무의미. 먼저 원인을 해소
is_auto_shrink_on자동 축소의 활성화/비활성화1이면 비활성화를 검토. 축소와 확장의 반복을 초래
avg_fragmentation_in_percent인덱스의 평균 단편화율축소 전후로 비교. 크게 상승했다면 재구축이 필요
page_count인덱스의 페이지 수페이지 수가 적은 인덱스는 단편화율이 높아도 영향이 작음

こういう状況で使います

  • 디스크 여유 공간이 줄어들어 데이터베이스 파일을 작게 만들고 싶다
  • 대량 삭제를 했는데도 데이터 파일의 크기가 바뀌지 않는다
  • 일시적인 처리로 로그 파일이 비대해져 원래 크기로 되돌리고 싶다
  • 정기 유지보수로 축소 작업을 구성해 두었는데 성능이 점점 나빠지고 있다

考えられる原因(可能性の高い順)

  1. 01

    대량 삭제·아카이브 후의 미사용 영역

    데이터를 삭제해도 파일 크기는 자동으로 줄어들지 않습니다. 미사용 영역으로 유지되어 이후의 쓰기에서 재사용됩니다. 이 상태는 보통 문제가 아니며 축소가 필요하다고는 할 수 없습니다.

  2. 02

    일시적인 처리로 인한 로그 비대화

    대규모 데이터 이전이나 일괄 업데이트로 로그가 일시적으로 커지는 경우입니다. 처리가 끝나고 지속적으로 불필요한 크기라면 로그 축소는 타당한 작업이 됩니다.

  3. 03

    로그가 해제되지 않는 원인이 남아 있음

    열려 있는 트랜잭션, 정지된 CDC·복제, 로그 백업 미실시 등이 해당합니다. 이 상태에서는 축소해도 다시 확장됩니다.

  4. 04

    AUTO_SHRINK가 활성화되어 있음

    자동 축소가 활성화되어 있으면 축소와 자동 확장이 반복됩니다. 그때마다 페이지 이동에 의한 단편화와 확장 대기에 의한 쓰기 지연이 발생합니다. 기본값은 비활성화이며 활성화할 이유는 거의 없습니다.

  5. 05

    축소를 정기 유지보수에 포함시키고 있음

    축소 → 단편화 → 재구축 → 파일 확장 → 축소라는 루프를 돌리고 있는 상태입니다. I/O를 소비할 뿐이며 지속적인 개선으로 이어지지 않습니다.

確認手順

  1. 1

    파일별 여유 용량을 확인한다

    参照のみ

    `sys.database_files`와 `FILEPROPERTY`로 `free_mb`를 확인합니다. 여유 공간이 작으면 축소해도 효과가 없습니다.

  2. 2

    데이터 파일인지 로그 파일인지를 구분한다

    参照のみ

    `type_desc`로 대상을 명확히 합니다. 둘은 판단 기준이 다릅니다.

  3. 3

    로그인 경우 `log_reuse_wait_desc`를 확인한다

    参照のみ

    NOTHING이 아니라면 먼저 그 원인을 해소합니다. 축소는 그 이후입니다.

  4. 4

    축소 전 인덱스 단편화율을 기록한다

    `sys.dm_db_index_physical_stats`를 `LIMITED` 모드로 실행하여 비교용 기준값을 가져옵니다.

  5. 5

    자동 확장 설정을 확인한다

    参照のみ

    축소 후 재확장 비용을 추정합니다. % 지정인 채로 두면 확장할 때마다 커집니다.

  6. 6

    AUTO_SHRINK 설정을 확인한다

    参照のみ

    `is_auto_shrink_on`이 1이면 먼저 이 설정의 타당성을 검토합니다.

対応方法

すぐに実施できる低リスクの対応

  • 축소하지 않는다는 선택을 검토한다

    参照のみ

    미사용 영역은 이후의 쓰기에서 재사용됩니다. 스토리지 용량에 여유가 있다면 축소하지 않는 것이 가장 안전하고 비용이 낮은 선택입니다.

  • AUTO_SHRINK가 활성화되어 있다면 비활성화한다

    축소와 확장의 반복에 의한 단편화와 지연을 멈출 수 있습니다. 기본값은 비활성화입니다.

  • 로그인 경우 먼저 원인을 해소한다

    `log_reuse_wait_desc`가 NOTHING이 된 후에 축소하십시오. 순서를 거꾸로 하면 효과가 없습니다.

事前検討が必要な変更

  • 로그 파일을 `TRUNCATEONLY`로 축소한다

    페이지 이동을 수반하지 않으므로 데이터 파일 축소보다 영향이 작은 작업입니다. `log_reuse_wait_desc`의 원인을 해소한 후 실시합니다. SHRINK 계열은 모두 "높음"으로 표시되어 있으므로 실행 전 확인을 생략하지 마십시오.

  • 축소 후의 재확장을 고려한 크기를 설정한다

    목표 크기를 사용량에 거의 딱 맞게 하면 곧바로 자동 확장이 발생하여 쓰기가 지연됩니다. 평상시 운영에 필요한 여유를 남기십시오.

  • 자동 확장을 고정 MB 지정으로 변경한다

    % 지정은 파일이 커질수록 한 번의 확장량이 늘어납니다. 고정 MB 지정이 동작을 예측하기 쉽습니다.

  • 아카이빙과 파티셔닝으로 크기를 지속적으로 억제한다

    오래된 데이터를 별도 테이블·별도 파일 그룹으로 옮기는 설계로 하면 축소에 의존하지 않고 파일 크기를 관리할 수 있습니다.

再起動・サービス影響を伴う変更

  • 데이터 파일을 축소한다

    페이지 이동으로 인덱스 단편화가 크게 진행됩니다. 실시할 경우 사후 인덱스 재구축과 그 소요 시간·로그 증가까지를 포함한 계획이 전제입니다.

  • `DBCC SHRINKDATABASE`를 실행한다

    데이터베이스 내 모든 파일이 대상이 되어 영향 범위를 제어할 수 없습니다. 파일 단위의 `DBCC SHRINKFILE`로 대체할 수 없는지 먼저 검토하십시오.

  • 축소 후 인덱스를 재구축한다

    단편화를 되돌리기 위한 작업이지만, 재구축으로 파일이 다시 확장됩니다. "축소하여 작게 만든다"는 목적과 상충하는 점을 이해한 후 계획하십시오.

!注意事項

  • 데이터 파일의 축소는 페이지를 이동시키므로 실행 후 인덱스 단편화가 크게 진행됩니다. 정기 유지보수로 포함시켜야 할 작업이 아닙니다.
  • 축소 → 단편화 → 재구축 → 파일 확장이라는 루프는 I/O를 소비할 뿐이며 지속적인 개선이 되지 않습니다. 재구축으로 파일이 다시 커진다는 점에 주의하십시오.
  • `DBCC SHRINKDATABASE`는 데이터베이스 내 모든 파일을 대상으로 합니다. 대상을 선택할 수 없으므로 파일 단위로 제어할 수 있는 `DBCC SHRINKFILE`을 우선하십시오.
  • `DBCC SHRINKDATABASE`의 두 번째 인수는 "축소 후 남길 여유 공간의 비율"이며 축소율이 아닙니다. 잘못 지정하면 의도하지 않은 크기가 됩니다.
  • 로그 파일의 축소는 `log_reuse_wait_desc`가 NOTHING이 된 후에 수행하십시오. 원인이 남아 있으면 축소해도 다시 확장됩니다.
  • AUTO_SHRINK는 기본적으로 비활성화되어 있습니다. 활성화하면 축소와 확장이 반복되어 단편화와 쓰기 지연을 초래합니다. 활성화는 권장되지 않습니다.
  • 축소는 실행 중 I/O를 크게 소비하며 대상 개체에 대한 접근이 느려집니다. 실행 중 중단한 경우 그때까지 이동한 페이지는 되돌아가지 않습니다.
  • 목표 크기를 사용량에 거의 딱 맞게 설정하면 직후에 자동 확장이 발생합니다. 확장 중에는 쓰기가 지연되므로 평상시 운영에 필요한 여유를 남기십시오.

バージョン・環境による違い

SQL Server 2008 이후`DBCC SHRINKDATABASE` / `DBCC SHRINKFILE`과 `TRUNCATEONLY`, `NOTRUNCATE`, `EMPTYFILE` 옵션을 사용할 수 있습니다.
SQL Server 2019 이후`RESUMABLE` 옵션을 수반하는 축소가 지원되는 버전이 있습니다. 사용 가능 여부는 대상 환경의 버전에서 확인하십시오(확인 필요).
Amazon RDS for SQL Server`DBCC SHRINKFILE`은 일반적으로 db_owner 권한으로 실행할 수 있지만, 실행 가능 여부와 스토리지 쪽으로의 반영(할당된 스토리지가 자동으로 축소되지 않는다는 점 포함)은 대상 환경에서 확인하십시오(확인 필요).

これで解決しない場合に確認すること

  • 축소 후 인덱스 단편화율

    `LIMITED` 모드로 축소 전후를 비교하여 재구축이 필요한 범위를 특정합니다.

  • 스토리지 쪽의 실제 여유 용량

    클라우드 블록 스토리지에서는 데이터베이스 파일을 축소해도 할당된 스토리지 용량이 자동으로 줄어든다고는 할 수 없습니다.

  • 자동 확장 이벤트의 발생 이력

    기본 추적이나 로그에서 축소 후 확장이 반복되지 않았는지 확인합니다.

  • 파일 그룹과 데이터 배치

    여러 파일 그룹이 있는 경우, 어느 파일에 여유가 편중되어 있는지 확인한 후 대상을 결정합니다.

この文書の根拠と限界

製品の公式ドキュメントに基づく説明

SQL Server의 `DBCC SHRINKDATABASE` / `DBCC SHRINKFILE`(`TRUNCATEONLY` 포함), `sys.database_files`, `FILEPROPERTY`, `sys.dm_db_index_physical_stats`, `ALTER DATABASE ... SET AUTO_SHRINK`의 공개 사양에 기반한 일반적인 절차입니다. 축소로 발생하는 단편화의 정도는 데이터 배치에 의존하므로 구체적인 수치는 기재하지 않았습니다. Amazon RDS에서의 스토리지 용량 반영은 대상 환경에서의 확인을 전제로 합니다.

よくある質問

SHRINKDATABASE와 SHRINKFILE 중 어느 것을 사용해야 합니까?

실무에서는 `DBCC SHRINKFILE`을 권장합니다. `DBCC SHRINKDATABASE`는 데이터베이스 내 모든 파일을 대상으로 하므로 어느 파일이 얼마나 축소되는지 제어할 수 없습니다. `DBCC SHRINKFILE`이라면 대상 파일과 목표 크기를 지정할 수 있어 영향 범위를 한정할 수 있습니다.

데이터 파일의 축소가 권장되지 않는 이유는 무엇입니까?

목표 크기를 지정한 축소는 파일 끝부분의 페이지를 여유 영역으로 이동시킨 후 끝부분을 잘라냅니다. 이 이동이 논리적인 정렬 순서를 무너뜨려 인덱스 단편화를 크게 진행시킵니다. 게다가 축소 후의 재확장과 이후의 재구축에서 I/O를 소비하므로 지속적인 개선이 되지 않습니다.

로그 파일의 축소는 문제없습니까?

데이터 파일과는 사정이 다르며, 일시적인 처리로 비대해진 부분을 되돌리는 작업으로서는 타당합니다. 다만 `log_reuse_wait_desc`가 NOTHING이 되어 있는 것이 전제이며, 원인이 남아 있는 채로 축소해도 다시 확장됩니다.

TRUNCATEONLY란 무엇입니까?

파일 끝부분의 미사용 영역만 OS에 반환하는 옵션입니다. 페이지 이동을 수반하지 않으므로 목표 크기를 지정하는 축소에 비해 단편화에 대한 영향이 작습니다. 다만 끝부분이 사용 중인 경우 예상대로 축소되지 않는 경우가 있습니다.

운영 환경에서 실행할 수 있습니까?

확인용 쿼리는 참조 전용이며 운영 환경에서 실행할 수 있습니다. 데이터 파일의 축소와 `DBCC SHRINKDATABASE`는 원칙적으로 운영 환경에서 실시하지 않으며, 필요한 경우 유지보수 시간대와 사후 인덱스 재구축 계획을 함께 준비하십시오. 로그 파일의 `TRUNCATEONLY`는 원인 해소 후라면 실시할 수 있습니다.

AWS RDS에서도 사용할 수 있습니까?

`DBCC SHRINKFILE`은 일반적으로 db_owner 권한으로 실행할 수 있습니다. 다만 데이터베이스 파일을 축소해도 RDS에 할당된 스토리지 용량이 자동으로 줄어든다고는 할 수 없습니다. 스토리지 쪽 처리는 대상 환경에서 확인하십시오.

この文書がカバーする質問

  • SQL Server에서 데이터 파일을 작게 만들고 싶다
  • 축소하면 왜 성능이 떨어지는지 알고 싶다
  • 로그 파일만 축소하는 방법을 알고 싶다

リスク表示の意味

  • 参照のみデータと設定を変更しません。
  • 影響は限定的ですが、権限と負荷の確認が必要です。
  • 性能・ロック・コストに影響する可能性があります。
  • 障害・データ損失・復旧作業が発生する可能性があります。
  • 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

파일 축소는 "한 번 하고 끝"인 것처럼 보이지만, 실제로는 단편화·재확장·I/O 증가라는 후속 영향을 수반합니다. GIIP에서는 파일 크기와 사용량, 인덱스 단편화율, 자동 확장 이벤트를 같은 시계열로 보관하여 축소 전후로 무엇이 바뀌었는지 추적할 수 있게 하고 있습니다. 축소는 영향이 크고 되돌릴 수 없는 작업이므로 AI 에이전트의 자동 실행 대상에서 제외하고, 실시 판단과 시간대 조정은 사람이 하는 방식으로 운영합니다.

執筆・技術検証

GIIP プロダクション運用チーム

大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。

関連するナレッジ

関連サービス

파일 비대화에 대한 근본 대책을 설계하기

同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。

파일 비대화에 대한 근본 대책을 설계하기

ナレッジベース一覧へ