내가 찾고 있어요 실제 의 값을 설정하기위한 지침 BUFFERCOUNT, BLOCKSIZE그리고 MAXTRANSFERSIZE의 BACKUP명령. 나는 약간의 연구를 해왔고 (아래 참조), 약간의 테스트를 해왔으며, 진정으로 귀중한 답변은 "글쎄요 .."로 시작한다는 것을 완전히 알고 있습니다. 내가 수행 한 테스트와 내가 찾은 리소스 중 하나에 표시된 테스트 (아래 방법 참조)에 대한 내 관심사는 테스트가 진공 상태에서 수행되고 다른로드가없는 시스템에서 수행된다는 것입니다.
장기간의 경험을 기반으로 한이 세 가지 옵션에 대한 적절한 지침 / 모범 사례가 궁금합니다. 주 또는 몇 달에 걸친 많은 데이터 포인트. 그리고 나는 사용 가능한 하드웨어의 기능이기 때문에 특정 값을 찾고 있지 않지만 알고 싶습니다.
- 다양한 하드웨어 / 부하 요소가 수행 대상에 미치는 영향
- 이 값 중 어느 것도 무시해서는 안되는 상황이 있습니까?
- 즉시 명백하지 않은 것을 무시할 수있는 함정이 있습니까? 너무 많은 메모리 및 / 또는 디스크 I / O를 사용하십니까? 복원 작업이 복잡합니까?
- 나는의 (a 기본 인스턴스와 두 개의 명명 된 인스턴스)를 실행하는 SQL Server의 여러 인스턴스가있는 서버가, 나는 동시에 3 개 인스턴스의 백업을 실행하면, 그게 내가 만드는 이상으로이 값을 설정하는 방법에 영향을 줄 경우 반드시 그 집단 (
BUFFERCOUNT*MAXTRANSFERSIZE)가 사용 가능한 RAM을 초과하지 않습니까? 가능한 I / O 경합? - 하나의 서버에 세 개의 인스턴스가 있고 세 개의 인스턴스에서 동시에 백업을 다시 실행하는 동일한 시나리오에서 각 인스턴스 내에서 여러 데이터베이스에 대한 백업을 동시에 실행하면 이러한 값의 설정에 어떤 영향을 미칩니 까? 즉, 3 개의 인스턴스 각각에 각각 100 개의 데이터베이스가있는 경우 6-9 개의 백업이 동시에 실행되도록 각 인스턴스 당 2 또는 3 개의 백업을 동시에 실행합니다. (이 상황에서는 몇 개의 큰 데이터베이스가 아닌 중소 규모의 데이터베이스가 많이 있습니다.)
내가 지금까지 수집 한 것 :
BLOCKSIZE:- 지원되는 크기는 512, 1024, 2048, 4096, 8192, 16384, 32768 및 65536 (64KB) 바이트입니다. [1]
- 테이프 장치의 경우 기본값은 65536이고 그렇지 않은 경우 512입니다. [1]
- CD-ROM으로 복사하고 CD-ROM에서 복원하려는 백업을 수행하는 경우 BLOCKSIZE = 2048 [1]을 지정하십시오 .
- 단일 디스크에 쓸 때 기본값 인 512는 괜찮습니다. RAID 어레이 또는 SAN을 사용하는 경우 기본값 또는 65536이 더 나은지 테스트해야합니다. [13 (18 페이지)]
수동으로 설정하면 값이 데이터 파일을 만드는 데 사용 된 블록 크기보다 크거나 같아야합니다. 그렇지 않으면 다음 오류가 발생합니다.
메시지 3272, 수준 16, 상태 0, 줄 3
'C : \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak'장치의 하드웨어 섹터 크기는 4096이지만 블록 크기 매개 변수는 호환되지 않는 대체 값 512. 호환 가능한 블록 크기를 사용하여 명령문을 다시 발행하십시오.
BUFFERCOUNT:기본 [2], [8] :
SQL Server 2005 이상 버전 :
(NumberofBackupDevices * [mystery_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)[mystery_multiplier] :이 값과 관련하여 일부 불일치가 있습니다. 나는 그것이 3 가지 형태로 표현되는 것을 보았다 :
3[2]GetSuggestedIoDepth[8]GetSuggestedIoDepth + 1[8]
멀티 플라이어를 보여주는 테스트는3SQL Server 2005 SP2에서 수행되었습니다 [9] .SQL Server 2008 R2 및 2012에 대한 나의 테스트와 SQL Server 2014에 관한 사용자 의견 [8] 은 승수를로 나타
4냅니다. 다음에 대해GetSuggestedIoDepth(직접 아래에) 보고 된 값이 주어지면 다음 중 하나를 의미합니다.GetSuggestedIoDepth지금4이거나- 승수는 지금
GetSuggestedIoDepth + 1
GetSuggestedIoDepth3DISK 장치에 대한 반환 [9]- 하드 셋 최대 값은 없지만 필요한 메모리 = (
BUFFERCOUNT*MAXTRANSFERSIZE)가 주어지면 실제 최대 값은 다음과 같습니다.BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
MAXTRANSFERSIZE:- 가능한 값은 최대 4194304 바이트 (4MB) 범위의 65536 바이트 (64KB)의 배수입니다. [1]
- 기본값 : 장치가 읽기 모드 (복원)이거나 Desktop 또는 Express Edition 64K를 사용하는 경우 1MB를 사용하십시오. [9]
- 일반 / 기타 :
- 사용할 수있는 최대 크기는 ( 버퍼 풀의 실제 메모리로 / 16 )입니다. GlobalMemoryStatusEx (ullTotalPhys) API 호출 에서 리턴 된대로 . [9]
- 추적 플래그는
3213백업 / 복원 조작을 수행하는 동안 백업 / 복원 구성 매개 변수를3605출력하고 출력을 ERRORLOG 파일로 덤프 합니다.DBCC TRACEON (3213, 3605, -1); - 일부 메트릭을보다 쉽게 테스트하기 위해 (UNIX에서
DISK = N'NUL:'DOS / Windows와 동일/dev/null)를 사용할 수 있습니다 (하지만 쓰기 I / O를 건너 뛰기 때문에 전체 프로세스 시간을 잘 알 수는 없습니다)
자원
- T-SQL BACKUP 명령에 대한 MSDN 페이지
- KB904804 : SQL Server 2000에서 데이터베이스를 백업 할 때 성능이 저하된다
- SQL Server 백업 성능을 향상시키는 옵션
- 백업 및 복원
- SQL Server 백업 및 복원 최적화
- 백업 성능 최적화
- 압축 및 솔리드 스테이트 디스크를 사용하여 SQL 데이터베이스 전체 백업 속도를 높이는 방법
- 잘못된 BufferCount 데이터 전송 옵션으로 인해 OOM 상태가 발생할 수 있음
- 작동 방식 : SQL Server 백업 및 복원은 전송 크기를 어떻게 선택합니까
- 작동 방식 : SQL Server 백업 버퍼 교환 (VDI 포커스)
- SQL 백업 튜닝 큰 데이터베이스
- 백업 버퍼를위한 SQL Server 메모리
- 사례 연구 : 네트워크를 통한 VLDB의 빠르고 안정적인 백업 및 복원 (.docx 파일)
- 백업 성능을 향상시키기 위해 몇 개의 백업 장치가 권장됩니까?
나는 다음과 같이 테스트했다.
--DBCC TRACEON (3213, 3605, -1);
BACKUP DATABASE [Test] TO
DISK = 'NUL:'
--,DISK = 'NUL:'
-- DISK = 'BackupTest1.bak'
-- ,DISK = 'BackupTest2.bak'
WITH
STATS = 5,
FORMAT,
CHECKSUM,
NO_COMPRESSION,
COPY_ONLY
--,BUFFERCOUNT = 40
--,MAXTRANSFERSIZE = 4194304--2097152,
--,BLOCKSIZE = 16384
--DBCC TRACEOFF (3213, 3605, -1);
최신 정보
때로는 질문에 대답 할 때 항상 다른 사람들에게 제공하도록 요청하는 정보 중 일부를 추가하는 것을 잊어 버린 것 같습니다 ;-). 현재 상황과 관련하여 위의 정보를 제공했지만 자세한 내용을 제공 할 수 있습니다.
24 / 7 / 365.25 SaaS 애플리케이션을 제공하는 클라이언트를 위해 일하고 있습니다. 따라서 사용자는 어느 시점 에나있을 가능성이 있지만 현실적으로 사용자는 모두 미국을 기반으로하고 (현재는) "표준"시간 인 오전 7시 (동부 오전 10시)에서 오후 7시 (태평양 표준시)까지 주로 일하는 경향이 있습니다. (예 : 동부 표준시 오후 10시), 주말은 약간 가벼워도 월요일 ~ 금요일이 아니라 일주일에 7 일입니다.
각 클라이언트마다 고유 한 DB를 갖도록 설정됩니다. 그것은 틈새 산업이므로 수만 (또는 그 이상)의 잠재 고객이 없습니다. 클라이언트 DB의 수는 인스턴스마다 다르며 가장 큰 인스턴스는 206 개의 클라이언트를 보유합니다. 가장 큰 DB는 약입니다. 8GB이지만 약 30 개의 DB 만 1GB를 초과합니다. 따라서 VLDB의 성능을 극대화하려는 것은 아닙니다.
이 클라이언트를 시작했을 때 백업은 항상 하루에 한 번 가득 차 있었고 LOG 백업은 없었습니다. 또한 MAXTRANSFERSIZE를 4MB로, BUFFERCOUNT를 50으로 설정했습니다.이 설정을 약간 맞춤화 된 Ola Hallengren의 데이터베이스 백업 스크립트 버전으로 대체했습니다 . 약간 사용자 정의 된 부분은 각 인스턴스에 연결될 때 DB를 동적으로 감지하고 인스턴스 당 스로틀 링을 허용하는 멀티 스레딩 도구 (필자가 작성하고 곧 판매를 시작할 것입니다)에서 실행된다는 것입니다. 세 개의 인스턴스를 동시에, 각 인스턴스 당 DB는 순차적으로 실행하는 데 따른 영향을 확신하지 못했기 때문에 순차적으로).
설정은 이제 일주일에 한 번 전체 백업을 수행하고 다른 날에는 DIFF 백업을 수행합니다. LOG 백업은 10 분마다 수행됩니다. 여기에서 문의하는 3 가지 옵션에 기본값을 사용하고 있습니다. 그러나 그들이 어떻게 설정되었는지 알고, 나는 최적화를 취소하지 않기를 원했습니다 (오래된 시스템에 몇 가지 중대한 결함이 있었기 때문에 모든 것이 의미하지는 않습니다)잘못되었습니다). 현재 206 개의 데이터베이스의 경우 FULL 백업 (일주일에 한 번)의 경우 약 62 분이 소요되고 나머지 날 (FULL의 첫날 7 일, 마지막 날 20 일)의 DIFF 백업의 경우 7 분에서 20 분 사이가 소요됩니다. 다음 전체). 그리고 그것은 순차적으로 실행됩니다 (단일 스레드). LOG 백업 프로세스 (총 3 개의 인스턴스에있는 모든 DB)는 매번 50 초에서 90 초까지 (10 분마다) 소요됩니다.
나는 DB 당 여러 파일을 실행할 수 있다는 것을 알고 있지만 a) 멀티 스레딩과 중소 규모의 DB가 얼마나 더 나은지 잘 모르겠습니다 .b) 복원 프로세스를 복잡하게하고 싶지 않습니다 ( 단일 파일을 다루는 것이 바람직한 이유는 여러 가지가 있습니다).
또한 압축을 활성화 할 수 있다는 것을 알고 있습니다 (테스트 쿼리가 의도적으로 비활성화되어 있음). 팀에 권장했지만 내장 압축이 다소 어려워졌습니다. 이전 프로세스의 일부는 각 파일을 RAR로 압축하는 것이 었으며 자체 테스트를 수행 한 결과 RAR 버전이 기본 압축 버전보다 최소 50 % 작다 는 것을 알았습니다 . 기본 압축을 먼저 사용하여 속도를 높이고 파일을 RAR로 시도했지만 파일은 원래 압축 된 것보다 작지만 여전히 RAR 전용 압축 버전보다 약간 크며 정당화하기에 충분한 차이가 있습니다. 기본 압축을 사용하지 않습니다. 백업 압축 프로세스는 비동기식이며 X 분마다 실행됩니다. 발견 한 경우 .bak또는.trn파일을 압축합니다. 이렇게하면 각 파일을 압축하는 데 걸리는 시간으로 인해 백업 프로세스가 느려지지 않습니다.