SQL Server의 백업 및 복원 성능 최적화
Microsoft SQL Server에서는 백업 및 복원 작업 속도를 높일 수 있는 다음 두 가지 방법을 제공합니다.
여러 개의 백업 장치를 사용하면 백업을 모든 장치에 병렬로 기록할 수 있습니다. 백업 장치 속도는 백업 처리량에 있어 병목 상태를 야기할 수 있는 한 가지 요소가 됩니다. 여러 개의 장치를 사용하면 사용하는 장치 수에 비례하여 처리량이 증가할 수 있습니다. 마찬가지로 백업을 여러 장치에서 병렬로 복원할 수 있습니다. 자세한 내용은 이 항목의 뒷부분에 나오는 "다중 미디어 또는 다중 장치 사용"을 참조하십시오.
전체, 차등 및 트랜잭션 로그 백업(전체 또는 대량 로그 복구 모델의 경우)을 조합해서 사용하면 복구 시간을 최소화할 수 있습니다. 차등 데이터베이스 백업은 일반적으로 전체 데이터베이스 백업보다 빠르게 만들 수 있으며 데이터베이스 복구에 필요한 트랜잭션 로그의 양도 줄일 수 있습니다. 자세한 내용은 SQL Server 데이터베이스의 전체 및 차등 백업 만들기를 참조하십시오.
다중 미디어 또는 다중 장치 사용
백업 장치의 데이터와 트랜잭션 로그를 데이터베이스와 트랜잭션 로그 파일에 복사하는 작업은 판독기/기록기 스레드로 수행됩니다. 각 백업 장치마다 한 개의 스레드가 할당됩니다. 백업 장치의 데이터 전달 능력 또는 데이터베이스와 트랜잭션 로그 파일의 데이터 수용 능력에 의해 성능이 제한됩니다. 따라서 데이터베이스 또는 트랜잭션 로그 파일이 데이터를 수용할 수 있는 최대 처리량에 도달할 때까지 백업 장치 수에 따라 성능도 높아집니다.
백업 및 복원 작업에 여러 개의 백업 장치를 사용하는 경우 다른 백업 장치와 동시에 각 백업 장치에 작성하고 읽을 수 있으므로 SQL Server에서 병렬 I/O를 사용하여 백업 및 복원 작업의 속도를 높일 수 있습니다. 데이터베이스의 크기가 큰 기업의 경우 많은 백업 장치를 사용하면 백업 및 복원 작업을 하는 데 걸리는 시간이 상당히 줄어듭니다. SQL Server에서는 단일 백업 작업에 대해 최대 64개의 백업 장치를 지원합니다.
백업이 다중 백업 장치에 기록되는 동안 몇몇 내부 동기화 지점이 발생합니다. 가장 중요한 내부 동기화 지점은 데이터베이스의 모든 데이터를 백업하고 트랜잭션 로그를 백업하려고 할 때 발생합니다.
.gif "중요 정보") 중요 |
|---|
여러 가지 백업 장치를 사용하여 백업 작업을 실행할 때 관련된 백업 미디어는 SQL Server 백업 작업에만 사용할 수 있습니다. 자세한 내용은 백업 미디어 사용을 참조하십시오. |
다중 백업 장치를 사용하여 백업을 만들고 복원하는 것은 단일 장치를 사용하여 백업을 만들고 복원하는 것과 같습니다. 한 가지 다른 점은 작업에 관련된 백업 장치를 모두 지정해야 하는 것입니다. 예를 들어 \\.\TAPE0, \\.\TAPE1 및 \\.\TAPE2 같은 3가지 테이프 백업 장치를 사용하여 데이터베이스 백업을 만들 경우 나중에 백업을 복원할 때 더 적은 수의 테이프 백업 장치를 사용하더라도 테이프 장치 각각을 백업 작업의 일부로 지정해야 합니다.
이동식 미디어를 사용하여 여러 백업 장치에서 백업을 만들 때 여러 장치는 다른 속도로 작동할 수 있고 해당 미디어 볼륨에서 사용할 수 있는 공간의 크기가 다를 수 있습니다. 백업 작업 중 백업 장치의 미디어 볼륨에 공간이 부족하게 되면 해당 장치에 기록하는 작업이 중지되고 새 미디어 볼륨을 요구하는 메시지가 나타납니다. 가득 찬 미디어 볼륨을 비어 있는 미디어 볼륨으로 대체할 때까지 해당 장치는 차단됩니다. 한편, 백업 작업을 통해 아직 미디어에 사용할 공간이 있는 장치에 데이터가 계속하여 작성됩니다. 가득 찬 미디어 볼륨을 대체하면 그 장치를 사용할 수 있게 되고 백업에서 해당 장치에 데이터를 쓰는 작업을 재개합니다. 그러나 장치가 차단되는 동안 내부 동기화 지점이 발생하는 경우 해당 장치를 다시 사용할 수 있게 될 때까지 백업 작업이 전체적으로 일시 중지됩니다.
예
속도가 같은 3개의 테이프 백업 장치를 사용하여 전체 데이터베이스 백업을 저장하는 시나리오를 가정해 보십시오. 처음 두 개의 테이프는 사용 가능한 공간이 10GB이지만 3번째 미디어는 5GB뿐입니다. 3개의 테이프 백업 장치에 모두 20GB의 데이터베이스를 동시에 백업하면 백업이 완료되기 전에 3번째 테이프가 가득 차게 됩니다. 3번째 테이프에 5GB의 데이터가 기록된 후 백업 작업에서 3번째 장치에 대한 쓰기를 중지합니다. 이 작업으로 인해 해당 장치는 차단되고 새 테이프를 요구하는 메시지가 나타납니다. 한편 백업 작업은 다른 두 개 백업 장치에 계속하여 데이터를 작성합니다. 그러나 3번째 테이프가 대체되기 전에 내부 동기화 지점이 발생합니다. 이때 전체 백업 작업은 새 테이프가 3번째 장치에 탑재될 때까지 일시 중지됩니다.
전체 및 차등 백업 성능 최적화
전체 또는 차등 백업을 만드는 과정은 다음 단계로 구성됩니다.
데이터베이스 파일의 데이터를 백업 장치로 복사
데이터베이스를 동일한 백업 장치와 일관된 상태로 롤포워드하기 위해 필요한 트랜잭션 로그의 일부를 복사
차등 백업 만들기는 변경된 데이터만 복사한다는 점을 제외하면 전체 백업 만들기와 동일합니다. 데이터베이스 파일 백업은 파일의 데이터를 백업 장치로 복사하는 간단한 작업으로 구성됩니다.
데이터베이스 저장을 위해 사용하는 데이터베이스 파일은 디스크 장치를 기준으로 정렬되며 각 장치마다 판독기 스레드가 할당됩니다. 판독기 스레드는 데이터베이스 파일에서 데이터를 읽습니다. 기록기 스레드는 각 백업 장치에 할당되며 데이터를 백업 장치에 기록합니다. 더 많은 논리 드라이브로 데이터베이스 파일을 분산시켜 병렬 읽기 작업을 늘릴 수 있습니다. 마찬가지로 더 많은 백업 장치를 사용하여 병렬 기록 작업을 늘릴 수 있습니다.
일반적으로 데이터베이스 파일 또는 백업 장치가 병목 상태가 됩니다. 전체 읽기 처리량이 전체 백업 장치 처리량보다 큰 경우에는 백업 장치 쪽이 병목 상태가 됩니다. 백업 장치와 필요에 따라 SCSI 컨트롤러를 추가하면 성능이 향상될 수 있습니다. 그러나 전체 백업 처리량이 전체 읽기 처리량보다 큰 경우에는 데이터베이스 파일 또는 장치를 추가하거나 RAID 장치에 디스크를 추가하여 읽기 처리량을 늘리십시오.
트랜잭션 로그 백업 성능 최적화
트랜잭션 로그 백업은 로그에서 아직 백업 장치에 백업되지 않은 부분을 복사하는 간단한 작업만으로 생성됩니다. 트랜잭션 로그 파일은 여러 개가 있을 수 있지만 트랜잭션 로그는 한 스레드에 의해 순차적으로 읽어지는 논리적인 하나의 스트림입니다.
기록기 스레드는 각 백업 장치에 할당되며 백업 장치를 많이 추가할수록 더 좋은 성능을 낼 수 있습니다.
장치의 상대적인 속도와 사용하는 백업 장치 수에 따라 트랜잭션 로그 파일이 포함된 디스크 장치 또는 백업 장치가 병목 상태가 될 수 있습니다. 백업 장치를 추가할 경우 트랜잭션 로그 파일이 포함된 디스크 장치의 용량 한계에 도달할 때까지는 비례적으로 확장되지만 디스크 스트라이프 등을 사용하여 트랜잭션 로그가 포함된 디스크 장치의 속도를 높이지 않고서는 더 이상 확장될 수 없습니다.
복원 성능 최적화
데이터베이스 또는 차등 백업의 복원은 다음 4개의 단계로 구성됩니다.
데이터베이스와 트랜잭션 로그 파일 만들기(없는 경우)
백업 장치의 데이터를 데이터베이스 파일로 복사
트랜잭션 로그 파일의 트랜잭션 로그 복사
트랜잭션 로그를 롤포워드한 다음 필요에 따라 복구를 다시 시작
트랜잭션 로그 백업 적용은 다음 두 단계로 구성됩니다.
백업 장치의 데이터를 트랜잭션 로그 파일로 복사
트랜잭션 로그 롤포워드
데이터베이스 파일 복원은 다음 두 단계로 구성됩니다.
손실된 데이터베이스 파일 만들기
백업 장치의 데이터를 데이터베이스 파일로 복사
파일 초기화
데이터베이스와 트랜잭션 로그 파일이 아직 없는 경우에는 먼저 만들어야 데이터를 복원할 수 있습니다. 데이터베이스와 트랜잭션 로그 파일이 생성되고 파일 내용은 0으로 초기화됩니다. 별도의 작업자 스레드가 파일 만들기와 초기화를 병렬로 수행합니다. 데이터베이스와 트랜잭션 로그 파일이 디스크 장치를 기준으로 정렬되며 별도의 작업자 스레드가 각 디스크 장치마다 할당됩니다. 파일 만들기와 초기화를 위해서는 매우 많은 처리량이 필요하므로 사용할 수 있는 논리 드라이브 전체에 파일을 고르게 분산시키면 최고의 성능을 낼 수 있습니다.
즉시 파일 초기화
SQL Server 2005 이상 버전에서는 데이터 파일을 즉시 초기화하여 데이터베이스 또는 파일 그룹 복원 작업을 빠르게 실행할 수 있습니다. 즉시 파일 초기화는 사용된 디스크 공간을 0으로 채우지 않고 회수합니다. 대신 새 데이터가 파일에 기록되면서 디스크 내용을 덮어쓰게 됩니다. 로그 파일 초기화에서 파일을 비워야 하지만 백업에서의 데이터 전송과 병렬로 작업이 수행됩니다. 복원의 롤포워드 단계는 모든 데이터가 전송되고 전체 로그가 초기화될 때까지 시작되지 않습니다.
[!참고]
즉시 파일 초기화는 Microsoft Windows XP 또는 Windows Server 2003 이상의 시스템에서만 사용할 수 있습니다.
즉시 파일 초기화를 사용하려면 Windows 계정으로 MSSQLSERVER 서비스 계정을 실행하고 해당 Windows 계정에 Windows SE_MANAGE_VOLUME_NAME 특수 권한을 할당해야 합니다. 이 권한은 기본적으로 Windows Administrators 그룹에 할당됩니다. 시스템 관리자 권한이 있는 사용자는 볼륨 관리 태스크 실행 보안 정책에 Windows 계정을 추가함으로써 이 권한을 할당할 수 있습니다. 사용자 권한 할당 방법은 Windows 설명서를 참조하십시오.
테이프 백업 장치 성능 최적화
테이프 백업 장치 성능에 영향을 주고 테이프 장치를 더 추가함에 따라 SQL Server 백업 및 복원 성능 작업이 비례적으로 확장될 수 있게 하는 여러 가지 요인이 있습니다.
소프트웨어 데이터 블록 크기
SCSI(Small Computer System Interface) 버스를 공유하는 테이프 장치 수
테이프 장치 유형
소프트웨어 데이터 블록 크기는 SQL Server에서 최적의 성능을 위해 계산되므로 변경해서는 안 됩니다. 최대 BLOCKSIZE는 64KB입니다.
고속 테이프 드라이브의 경우 사용하는 각 테이프 드라이브에 대해 전용 SCSI 버스가 있을 때 좋은 성능을 발휘하는 경우가 많습니다. 성능 저하를 방지하려면 기본 전송 속도가 SCSI 버스 속도의 50%를 넘는 드라이브는 전용 SCSI 버스에 배치되어야 합니다. 테이프 드라이브 성능에 영향을 미치는 설정 방법은 테이프 드라이브 공급업체의 설명서를 참조하십시오.
| 중요 |
|---|
테이프 드라이브를 디스크 또는 CD-ROM 드라이브와 동일한 SCSI 버스에 배치해서는 절대 안 됩니다. 이러한 장치들에 대한 오류 처리 동작이 서로 호환되지 않기 때문입니다. |
로드된 테이프에 여러 개의 백업 작업을 수행하는 경우 NOREWIND를 지정하여 성능을 향상시킬 수 있습니다. 이 옵션을 설정하면 SQL Server에서 백업 작업 후에 테이프를 열어 놓습니다. NOREWIND에는 NOUNLOAD가 내포되어 있습니다.
디스크 백업 장치 성능 최적화
디스크 백업 장치의 원시 I/O 속도는 디스크 백업 장치 성능에 영향을 주며 여러 디스크 장치가 추가됨에 따라 SQL Server 백업 및 복원 성능 작업이 비례적으로 확장될 수 있게 합니다.
디스크 백업 장치에 대한 RAID 사용은 신중히 고려해야 합니다. 예를 들어 RAID 5의 쓰기 성능은 패리티 정보 유지 관리로 인해 단일 디스크와 거의 비슷하게 낮습니다. 또한 파일에 대한 데이터 추가의 원시 속도는 원시 장치 쓰기 속도보다 현저하게 낮습니다.
백업 장치가 조밀하게 스트라이프되어 백업 장치에 대한 최대 쓰기 속도가 파일에 데이터를 추가할 수 있는 속도를 훨씬 초과하는 경우에는 동일한 스트라이프 세트에 여러 개의 논리 백업 장치를 배치하는 것이 적합할 수 있습니다. 즉, 동일한 논리 드라이브에 몇 개의 백업 미디어 패밀리를 배치하면 백업 성능이 향상될 수 있습니다. 그러나 이것이 각각의 환경에 대해 득이 되는지 실이 되는지를 확인하기 위해서는 경험이 필요합니다. 대체로 각각의 백업 장치를 별도의 디스크 장치에 배치하는 것이 더 적절합니다.
Ultra-wide와 Ultra-2 버스는 더 많은 처리가 가능하지만 일반적으로 SCSI 버스에서는 최대 속도로 작동할 수 있는 디스크가 몇 개 안 됩니다. 따라서 최적의 성능을 내려면 하드웨어를 신중하게 구성해야 합니다.
디스크 성능에 영향을 미치는 설정 방법은 디스크 공급업체의 설명서를 참조하십시오.
데이터 압축
요즘 나오는 테이프 드라이브에는 데이터를 드라이브로 전송하는 속도를 현저히 향상시킬 수 있는 하드웨어 데이터 압축 기능이 기본적으로 제공됩니다. 데이터베이스의 실제 데이터에 대한 압축 가능성은 데이터 자체와 사용하는 테이프 드라이브 모두에 의해 좌우됩니다. 다양한 범위의 데이터베이스에 대해 일반적인 데이터 압축 비율은 1.2:1부터 2:1까지입니다. 데이터베이스에 따라 압축 비율이 더 높거나 낮아질 수 있지만 다양한 업무용 응용 프로그램 데이터에 대해서는 이 압축 비율이 일반적입니다. 예를 들어 대부분 이미 압축된 이미지로 구성된 데이터베이스는 테이프 드라이브에 의해 더 이상 압축되지 않습니다. 데이터 압축 방법은 테이프 드라이브 공급업체의 설명서를 참조하십시오.
SQL Server에서는 기본적으로 하드웨어 압축을 지원하지만 3205 추적 플래그를 사용하여 이 프로시저의 사용을 해제할 수 있습니다. 하드웨어 압축의 사용을 해제하면 백업 성능이 향상되는 경우도 드물게 있을 수 있습니다. 예를 들어 하드웨어 압축을 해제하면 데이터가 이미 충분히 압축되어 있는 경우에 테이프 장치가 데이터를 더 압축하려고 함으로써 시간이 낭비되는 것을 막을 수 있습니다.
추적 플래그에 대한 자세한 내용은 추적 플래그(Transact-SQL)를 참조하십시오.
백업 압축
기본적으로 백업 압축을 사용하여 백업하면 CPU 사용량이 크게 늘어나고 압축 프로세스에 의해 사용되는 추가 CPU는 동시 작업에 악영향을 줄 수 있습니다. 따라서 CPU 충돌이 발생하면 CPU 사용량이 리소스 관리자에 의해 제한되는 세션에서 우선 순위가 낮은 압축 백업을 만들 수 있습니다. 자세한 내용은 방법: 리소스 관리자를 사용하여 백업 압축을 통해 CPU 사용량 제한(Transact-SQL)을 참조하십시오.
테이프로 전송되는 데이터 양
데이터 또는 차등 백업을 만들면 실제 데이터가 포함된 데이터베이스의 일부분만 캡처되고 사용하지 않은 공간은 백업되지 않습니다. 따라서 백업 작업 속도가 더 빨라집니다.
SQL Server 데이터베이스는 필요에 따라 자동으로 증가하도록 구성할 수 있지만 데이터베이스 내의 공간을 예약하여 계속해서 이 공간을 사용 가능한 공간으로 만들 수 있습니다. 데이터베이스 내의 공간 예약은 백업 처리량이나 데이터베이스 백업에 필요한 전체 시간에 나쁜 영향을 주지 않습니다.
로그 전달 동기화 최적화
로그 전달 대상을 동기화하려는 경우 RESTORE LOG 단계 사이에 WITH STANDBY를 사용할 필요가 없습니다.