SQL Server PAGE가 손상될 때 무슨 일이 일어나나요?
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you requested.
페이지 구조
Data files are divided into 8 KB pages, each consisting of:
| 컴포넌트 | 크기 | 설명 |
|---|---|---|
| 페이지 헤더 | 96 bytes | 페이지에 대한 메타데이터(페이지 유형, 상태 비트 등) |
| 데이터 행 | 8 060 bytes | 테이블에 저장된 실제 행 데이터 |
| 슬롯 배열 | 36 bytes | 페이지 내 각 행의 위치를 가리키는 오프셋 |
Together these components total 8 192 bytes (8 KB) – the standard SQL Server page size.
확장
확장은 연속된 8개의 8 KB 페이지(총 64 KB)로 구성된 집합입니다.
확장에는 두 가지 유형이 있습니다:
- Uniform extents – 8개의 페이지가 모두 하나의 객체에 할당됩니다.
- Mixed extents – 페이지가 여러 객체에 공유됩니다.
이 설계는 공간 사용량과 성능을 최적화하는 데 도움이 됩니다. 데이터베이스의 현재 할당 모드를 확인하려면 다음을 실행합니다:
SELECT [name], [is_mixed_page_allocation_on]
FROM sys.databases;
물리 파일
SQL Server는 페이지를 물리 파일에 저장하며, 이 파일은 세 가지 범주 중 하나에 속합니다:
| 파일 유형 | 확장자 | 용도 |
|---|---|---|
| 기본(또는 마스터) 데이터 파일 | .mdf | 기본적으로 시스템 카탈로그 데이터를 포함한 시스템 및 사용자 데이터를 보관합니다. |
| 보조 데이터 파일 | .ndf | 여러 디스크 또는 파일그룹에 걸쳐 저장소를 분산시키기 위해 사용되는 선택적 추가 데이터 파일입니다. |
| 트랜잭션 로그 파일 | .ldf | 데이터베이스에 대한 모든 변경 사항을 기록하여 내구성을 보장하고 복구를 가능하게 합니다. |
이 파일들은 함께 작동하여 저장소를 관리하고 데이터 무결성을 보장합니다.
할당 및 구조 무결성 확인
AdventureWorks2022 데이터베이스의 할당 및 구조 무결성을 확인하고(인덱스 검사는 건너뛰고) 손상 테스트를 위해 Person.Person 테이블에 집중해 보겠습니다.
-- 테이블의 논리적 일관성 확인
DBCC CHECKTABLE ('AdventureWorks2022.Person.Person');
-- 인덱스 검사는 제외하고 전체 데이터베이스의 할당 문제 확인
DBCC CHECKALLOC ('AdventureWorks2022', NOINDEX);
테이블이 사용하는 페이지 식별
DBCC IND를 사용하면 테이블이 차지하고 있는 페이지를 확인할 수 있습니다:
DBCC IND ('AdventureWorks2022', 'Person.Person', -1);
출력 결과는 페이지와 파일에 걸쳐 테이블 데이터가 어떻게 분산되어 있는지를 보여줍니다.
특정 페이지 검사
페이지 번호를 알게 되면 DBCC PAGE를 사용해 해당 페이지의 내부 구조(헤더, 행 오프셋, 데이터 행 등)를 확인할 수 있습니다. 예를 들어 파일 1의 페이지 1314를 검사하려면 다음과 같이 실행합니다:
DBCC PAGE ('AdventureWorks2022', 1, 1314, 1) WITH TABLERESULTS;
페이지 손상 시뮬레이션
⚠️ 테스트 또는 개발 환경에서만 실행하십시오. 데이터를 고의로 손상시키면 정보 손실이 발생할 수 있습니다.
-- Put the database in single‑user mode
ALTER DATABASE [AdventureWorks2022] SET SINGLE_USER WITH NO_WAIT;
-- Overwrite a byte on the page to simulate corruption
DBCC WRITEPAGE ('AdventureWorks2022', 1, 1314, 0, 1, 0x11, 1);
손상 확인
DBCC CHECKDB 또는 DBCC CHECKTABLE을 다시 실행하여 SQL Server가 문제를 어떻게 감지하는지 확인하십시오. (CHECKALLOC은 할당만 확인하고 데이터 무결성은 확인하지 않으므로 여기서는 사용하지 마세요.)
DBCC CHECKDB ('AdventureWorks2022');
DBCC CHECKTABLE ('AdventureWorks2022.Person.Person');
다음과 유사한 오류가 표시됩니다:
Msg 824, Level 24, State 2, Line 32
SQL Server detected a logical consistency‑based I/O error: incorrect checksum
(expected: 0x246e3cb2; actual: 0x24663cb2). It occurred during a ...
정리
시연이 끝난 후, 데이터베이스를 다중 사용자 모드로 되돌리고, 원한다면 깨끗한 백업에서 복원하여 손상을 제거합니다.
ALTER DATABASE [AdventureWorks2022] SET MULTI_USER;
요약
- 페이지는 헤더, 데이터 행, 슬롯 배열로 구성된 8 KB 단위입니다.
- 익스텐트는 8개의 페이지를 함께 묶으며 균일하거나 혼합될 수 있습니다.
DBCC IND로 페이지 할당을 검사하고DBCC PAGE로 페이지 내용을 확인할 수 있습니다.DBCC WRITEPAGE로 손상을 시뮬레이션하면DBCC CHECKDB/DBCC CHECKTABLE이 무결성 문제를 어떻게 감지하는지 확인할 수 있습니다.
페이지를 이해하고 이를 다루는 방법을 알면 SQL Server 저장 엔진에 대한 깊은 통찰을 얻을 수 있으며, 저수준 데이터 문제를 진단하고 해결하는 데 도움이 됩니다.
Problem Overview
read of page (1:1314) in database ID 5 at offset 0x00000000a44000 in file
'C:\MSSQL\DATA\AdventureWorks2022.mdf'.
Additional messages in the SQL Server error log or operating system error log may
provide more detail. This is a severe error condition that threatens database
integrity and must be corrected immediately. Complete a full database
consistency check (DBCC CHECKDB).
This error can be caused by many factors; for more information, see SQL Server
Books Online.
More about DBCC commands 이전 주제 here:
MSSQL DBCC – How good are they really? 👌
해결 옵션
🤞 첫 번째 옵션 – REPAIR_REBUILD
DBCC CHECKTABLE ('Person.Person', REPAIR_REBUILD);
REPAIR_REBUILD는 데이터 손실 없이 특정 유형의 인덱스 손상이나 일관성 없는 구조를 복구할 수 있습니다. 손상된 인덱스와 구조를 재구성하고 데이터를 삭제하지 않기 때문에 REPAIR_ALLOW_DATA_LOSS보다 안전합니다.
이 경우 결과
Msg 8928, Level 16, State 1, Line 39
Object ID 2101582525, index ID 1, partition ID 72057594049724416,
alloc unit ID 72057594057523200 (type In‑row data): Page (1:1314) could not be processed.
The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 39
Table error: Object ID 2101582525, index ID 1, partition ID 72057594049724416,
alloc unit ID 72057594057523200 (type In‑row data), page (1:1314).
Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -4.
Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 39
Table error: Object ID 2101582525, index ID 1, partition ID 72057594049724416,
alloc unit ID 72057594057523200 (type In‑row data). Page (1:1314) was not seen in the scan
although its parent (1:1568) and previous (1:1313) refer to it. Check any previous errors.
Repairing this error requires other errors to be corrected first.
Msg 8978, Level 16, State 1, Line 39
Table error: Object ID 2101582525, index ID 1, partition ID 72057594049724416,
alloc unit ID 72057594057523200 (type In‑row data). Page (1:1315) is missing a reference
from previous page (1:1314). Possible chain linkage problem.
Repairing this error requires other errors to be corrected first.
There are 19967 rows in 3807 pages for object "Person.Person".
CHECKTABLE found 0 allocation errors and 4 consistency errors in table
'Person.Person' (object ID 2101582525).
결론: REPAIR_REBUILD로는 문제를 해결할 수 없습니다.
😥 두 번째 옵션 – REPAIR_ALLOW_DATA_LOSS
DBCC CHECKTABLE ('Person.Person', REPAIR_ALLOW_DATA_LOSS);
경고: 이것은 최후의 수단이며 데이터 손실 가능성을 감수할 경우에만 사용하십시오.
전제 조건: 명령을 실행하기 전에 전체 백업(BACKUP DATABASE)을 반드시 수행하십시오.
🤔 세 번째 옵션 – 페이지 복원
페이지 복원은 손상된 페이지를 백업에서 가져온 깨끗한 사본으로 교체하여 전체 데이터베이스 복원을 피할 수 있습니다. 최신 전체 백업과 로그 백업이 있을 때 가장 효과적입니다.
1. 의심되는 페이지 확인
SELECT * FROM msdb.dbo.suspect_pages;

2. 손상된 페이지 복원
RESTORE DATABASE [AdventureWorks2022] PAGE = '1:1314'
FROM DISK = N'Z:\BCKP\w19$SQ\AdventureWorks2022\FULL\w19$SQ_AdventureWorks2022_FULL_20260214_122842.bak'
WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5;
3. 트랜잭션 로그 체인을 유지하기 위해 이후 로그 백업 적용
RESTORE LOG [AdventureWorks2022]
FROM DISK = N'Z:\BCKP\w19$SQ\AdventureWorks2022\LOG\w19$SQ_AdventureWorks2022_LOG_20260214_122900.trn'
WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5, ONLINE; -- ONLINE은 Enterprise 전용
4. 최신 로그 백업 수행 (선택 사항이지만 권장)
BACKUP LOG [AdventureWorks2022]
TO DISK = N'Z:\BCKP\w19$SQ\AdventureWorks2022\LOG\LOG_AdventureWorks2022'
WITH INIT;
5. 데이터베이스를 온라인 상태로 전환
RESTORE LOG [AdventureWorks2022]
FROM DISK = N'Z:\BCKP\w19$SQ\AdventureWorks2022\LOG\LOG_AdventureWorks2022'
WITH RECOVERY;
6. 복구 확인
DBCC CHECKDB ('AdventureWorks2022');
팁: 대형 데이터베이스의 경우 페이지 수준 복원과 로그 복원을 결합하면 전체 데이터베이스 복원보다 훨씬 덜 방해가 됩니다.
복구 옵션 요약
| Option | When to use | Risks | Prerequisites |
|---|---|---|---|
REPAIR_REBUILD | 인덱스 경미한 손상, 데이터 손실이 필요 없는 경우 | 심각한 페이지 오류를 해결하지 못할 수 있음 | 없음 (DBCC CHECKDB를 먼저 실행) |
REPAIR_ALLOW_DATA_LOSS | 다른 방법이 실패했을 때 최후의 시도 | 데이터 손실 가능성 | 전체 데이터베이스 백업 |
| Page restore + log restore | 최근 백업이 가능한 손상된 페이지(들) | 올바른 백업 세트와 로그 체인이 필요함 | 해당 페이지를 포함한 전체 백업 및 이후 로그 백업 |
환경, 백업 전략 및 데이터 손실 허용 범위에 가장 적합한 방법을 선택하십시오. 복구를 시도하기 전에 항상 백업을 수행하십시오.
🫡 네 번째 옵션: 원격 복원 및 재생성
새 위치에 복원하고 해당 테이블을 다시 생성합니다(소규모 데이터베이스용).
손상이 단일 테이블이나 데이터베이스의 작은 부분에 국한되고, 데이터베이스 크기가 이를 허용한다면 간단하게 처리하십시오. 또 다른 방법은 데이터베이스를 새 위치에 복원한 다음, 기본 DB에서 손상된 테이블을 다시 만드는 것입니다. 이 과정에서 SQL Server가 여전히 INSERT, UPDATE, DELETE를 허용한다면, 모든 상호 작용을 차단하는 트리거를 생성할 수도 있습니다.
CREATE TRIGGER tr_tableDENY ON Person.Person
AFTER INSERT, UPDATE, DELETE
AS
BEGIN
RAISERROR ('This table is temporarily locked for investigation.', 16, 1);
ROLLBACK TRANSACTION;
END
Final Advice
- DBCC CHECKDB를 정기적으로 실행하십시오. 이는 데이터베이스 무결성을 유지하는 데 필수적이지만, DBCC 검사에만 의존하지 마세요.
- 손상 감지를 위한 실시간 알림을 설정하십시오.
Suggested Monitoring Approach
msdb.dbo.suspect_pages 테이블을 지속적으로 모니터링하고 새로운 항목이 생기면 즉시 알림을 보내는 SQL Agent 작업을 만드세요. 알림이 처리된 후에는 테이블을 정리할 수 있습니다.
Error 823, 824, 825는 데이터베이스 페이지 손상과 관련되어 있으므로, 이러한 오류 번호에 대한 알림도 설정하십시오. 이렇게 하면 오류가 발생했을 때 즉시 통보받을 수 있습니다.
- SQL Server Agent에서 Alerts를 마우스 오른쪽 버튼으로 클릭 → New Alert 선택.
- 각 오류 번호마다 알림을 생성.
- 응답 담당자(이메일)를 Operator로 지정.

Error Descriptions
- Error 823 – 디스크에 읽기 또는 쓰기 작업 중 I/O 오류가 발생했습니다.
- Error 824 – 페이지에서 읽은 데이터에 논리적 일관성 오류가 감지되었습니다.
- Error 825 – I/O 작업 중 페이지 실패가 발생했습니다.