SQL Server DBCC CHECKDB 데이터베이스 도구 REPAIR_ALLOW_DATA_LOSS, REPAIR_REBUILD, TABLOCK, ESTIMATEONLY, PHYSICAL_ONLY 및 MAXDOP 옵션을 다루는 SQL Server DBCC CHECKDB 데이터베이스 도구를 사용하는 시기와 방법은 다음과 같습니다.
안녕하세요, 저는 Kirk입니다. 수석 주임 엔지니어로 GSE 팀에서 일하고 있습니다. 이 비디오에서는 Microsoft SQL Server TSQL 데이터베이스 도구인 DBCC CHECKDB를 살펴봅니다. DBCC CHECKDB를 실행해야 하는 이유와 시기를 비롯하여 관련된 데이터베이스 검사 및 런타임 수준을 결정하는 명령 옵션에 대해 설명합니다.
데모를 시작하기 전에 몇 가지 사항에 대해 이야기하겠습니다. DBCC CHECKDB는 지정된 SQL Server 데이터베이스 내에 있는 모든 개체의 논리적 및 물리적 무결성을 확인하는 TSQL 도구입니다. 몇 가지 복구 옵션도 사용할 수 있으며 데이터베이스 스냅샷의 사용 여부와 관련된 옵션으로 "TABLOCK"이라는 옵션도 있습니다. "ESTIMATEONLY" 옵션을 사용하는 이유와 CHECKDB 프로세스 중 "TEMPDB" 사용과 관련된 옵션을 살펴보겠습니다.
또한 "PHYSICAL_ONLY", 이 옵션을 사용해야 하는 이유와 시기를 살펴볼 것입니다. 또한 "MAXDOP"라는 것을 사용하여 CHECKDB 프로세스에 관련된 프로세서 수를 제어하는 방법을 살펴볼 것입니다. 이제 DBCC CHECKDB를 실행할 때 볼 수 있는 몇 가지 예를 살펴보겠습니다. 따라서 첫 번째 명령 자체는 말 그대로 DBCC CHECKDB가 지정된 데이터베이스 내에서 볼 수 있는 모든 것을 확인합니다.
결과는 다음과 같습니다. 이 명령을 실행할 때 가장 관심 있는 반환 라인은 데이터베이스에서 발견된 "할당 오류" 및 "일관성 오류"의 수입니다. 정상적인 "AdventureWorks2019" 데이터베이스가 있으므로 모든 것이 오류 없이 복구됩니다. 또한 이 데이터베이스는 크기가 작기 때문에 매우 빠르게 실행됩니다. 만약 우리가 훨씬 더 큰 데이터베이스를 가지고 있다면, 예를 들어 이 데이터베이스보다 100배 더 큰 데이터베이스가 있다면, 이것을 실행하는 데 훨씬 더 오랜 시간이 걸릴 것입니다.
그리고 많은 사람들이 DBCC CHECKDB를 얼마나 자주 실행해야하는지 궁금해하며 일반적으로 SQL 마스터는 가능한 한 빨리 실행하기를 원한다고 말할 것입니다. 데이터베이스에 불일치나 소프트웨어 손상이 있는 경우 가능한 한 빨리 이를 발견하고 처리해야 합니다. 다음으로 살펴볼 옵션은 "WITH PHYSICAL_ONLY"입니다.
이 경우 문자 그대로 물리적 엔터티 또는 데이터베이스 자체의 구조만 확인한다는 점을 제외하고는 동일한 명령입니다. 일반적으로 전체 검사보다 훨씬 빠르게 실행됩니다. 유지 보수 시간에 제한이 있는 운영 환경에서 이 방법을 실행하려고 합니다. "WITH TABLOCK"이라는 또 다른 옵션도 있으므로 DBCC CHECKDB에 대해 이해해야 할 한 가지는 가장 먼저 수행하는 작업 중 하나는 "TEMPDB" 데이터베이스에 포함된 스냅숏 파일을 만드는 것이며 CHECKDB 프로세스에서 이와 같은 작업에 "TEMPDB"를 사용하지 못할 수 있는 경우가 있습니다.
따라서 "WITH TABLOCK"이라고 지정하는 것이 무엇이든 간에 DBCC CHECKDB에 스냅숏 파일을 만들지 않도록 지시하므로 "TEMPDB"에서 해당 공간을 차지하지 않으며 일반적으로 그 결과로 더 빠르게 실행됩니다. 옵션으로 실행할 수 있는 다른 것 중 하나는 "WITH ESTIMATEONLY"입니다. 이 특정 명령은 CHECKDB를 실행할 때 "TEMPDB" 데이터베이스 내에서 사용할 것으로 예상되는 공간의 양을 알려줍니다.
여기 출력 예가 있습니다. 킬로바이트 단위로 돌아오니까 약 230메가바이트입니다. 또 다른 옵션은 "WITH MAXDOP"입니다. 이제 DBCC CHECKDB가 무엇을 실행하든 병렬로 실행하는 데 필요한 만큼의 프로세서를 사용하려고 합니다. 가능한 한 빨리 실행하기 위해 여러 스레드를 실행하려고 합니다. 따라서 이 프로세스에서 실행할 수 있는 프로세서 수에 제한이 있을 수 있으므로 "WITH MAXDOP" 문으로 제한할 수 있습니다.
이 경우 SQL에 CHECKDB 실행에 하나의 프로세서만 사용하도록 지시합니다. 그리고 이렇게 하면 전용 프로세서가 줄어들지만 일반적으로 DBCC CHECKDB를 실행하는 데 시간이 더 오래 걸립니다. 이제 복구 옵션을 살펴보겠습니다. 여러 가지 복구 옵션이 있습니다. 가장 과감한 옵션은 "REPAIR_ALLOW_DATA_LOSS"입니다. 이 옵션을 사용하여 오류가 발생하는 데이터베이스를 복구하려고 할 때마다 말 그대로 데이터가 손실 될 수 있습니다. 다른 방법으로 "REPAIR_REBUILD"를 사용할 수 있습니다.
REPAIR_REBUILD는 소프트 복구 옵션으로 간주되며, 이는 실행할 때 데이터베이스에서 사용 가능한 데이터가 손실되지 않는다는 것을 의미합니다. 따라서 이 명령이 배치되는 방식에서는 "마스터" 데이터베이스의 컨텍스트를 사용합니다. 이와 같은 작업을 수행 할 때마다 복구 작업을 허용하려면 데이터베이스를 "SINGLE_USER"모드로 설정해야합니다. 이렇게 설정하고 실행하겠습니다.
이제 "ESTIMATEONLY" 옵션이 있는데, 다시 한번 "ESTIMATEONLY"를 통해 이를 위해 "TEMPDB"에서 포기할 공간이 표시됩니다. 스냅샷 파일은 약 230MB를 차지할 것입니다. 그리고 이것으로 수리를 한 후 다시 "MULTI_USER"모드로 전환하고 싶습니다. "ESTIMATEONLY"를 사용하면 실제로 수리를 실행하지 않고 추정만 수행했습니다. 이제 "REPAIR_REBUILD"를 사용하여 명령을 실행하는 방법을 살펴보겠습니다.
다시 한 번 "Execute"로 이동하여 "MULTI_USER"에 다시 넣습니다. 다시 한번 강조하지만, "마스터" 데이터베이스에서는 "SINGLE_USER" 모드로 설정합니다. 여기서는 복구 작업을 실행하겠습니다. 소프트 복구 작업입니다. 보시는 것은 일반 DB 검사에서 볼 수 있는 것과 같으며, 물론 다시 한 번 보고된 오류를 확인하려고 합니다. 이번에도 오류가 없습니다.
데이터베이스 상태가 양호합니다. 이 작업의 마지막 부분은 다시 "MULTI_USER" 모드로 전환하는 것입니다. "REPAIR_ALLOW_DATA_LOSS" 복구 명령은 "REPAIR_ALLOW_DATA_LOSS"를 사용한다는 점을 제외하면 "REPAIR_REBUILD"과 똑같습니다. 일반적으로 "REPAIR_REBUILD"를 실행하려고 시도했을 때 "REPAIR_REBUILD"가 돌아와서 데이터베이스 복구를 완료할 수 없다고 알릴 때 이 작업을 실행합니다.
따라서 좋은 백업이 없는 최후의 수단이며, 예, "REPAIR_ALLOW_DATA_LOSS"를 수행하기 전에 좋은 백업을 사용해야 합니다. 백업이 없는 경우 데이터베이스를 다시 온라인 상태로 전환하여 사용할 수 있는 유일한 방법입니다. 이것으로 DBCC CHECKDB에 대한 설명, CHECKDB 사용 시기 및 사용 가능한 가장 일반적인 명령 옵션 몇 가지를 고려하는 데모를 마칩니다. 이 비디오가 일관되고 안정적인 SQL Server 데이터베이스 설치를 유지 관리하려고 할 때 DBCC CHECKDB를 사용하는 것의 가치를 이해하는 데 도움이 되었기를 바랍니다.
시청해 주셔서 감사합니다.
