트랜잭션 로그 백업 직렬 또는 병렬?

우리는 SQL Server 2012 Standard Edition을 사용하고 있습니다. 또한 Ola Hallengren의 스크립트를 사용하여 백업 및 유지 관리를위한 쉽고 유연한 프레임 워크를 제공합니다.

이 질문은 Ola의 스크립트에 관한 것이 아니라 모범 사례에 관한 것입니다. 궁극적 인 답변은 "회사의 요구 사항에 따라 다릅니다"라는 것입니다. 그러나 저는 회사의 요구 사항을 이해하는 최선의 방법에 대한 지역 사회의 조언을 구하려고합니다.

15 분마다 트랜잭션 로그 백업을 설정하고 싶습니다. 이런 식으로 우리는 15 분 이상의 데이터를 잃지 않기를 바랍니다. ALL_DATABASES를 사용하는 하나의 작업을 설정해야합니까? 또는 각 데이터베이스마다 하나의 작업을 설정하고 모두 병렬로 시작하는 것이 더 낫습니까? 나는 Ola의 스크립트가 백업이 연속적으로 시작되는 방식을 보는 방식에 따라 느낌이 있기 때문에 묻습니다. 직렬의 단점은 각 연속 백업이 다른 백업이 완료 될 때까지 대기한다는 것입니다. 이것은 백업 사이의 시간을 잠재적으로 증가시킬 수 있습니다 (즉, 15 분 이상). 또한 하나의 백업에서 장애가 발생하면 다른 백업이 중단되는 것을 우려 할 수 있습니다. 다른 사람들이 계속 백업하기를 원합니다.

Ola의 스크립트가 직렬로 실행되고 실패하면 연속 백업이 중지된다는 것이 사실입니까?

그리고 각 데이터베이스에 대해 직업을 갖는 것이 더 낫습니까? 아니면 모두를 수행하는 단일 작업? 내 성향은 별도의 작업에 대한 것이지만 SQL Server DBA가 일반적으로하는 일을 이해하고 싶습니다.

ALL_DATABASES를 사용하는 하나의 작업을 설정해야합니까? 또는 각 데이터베이스마다 하나의 작업을 설정하고 모두 병렬로 시작하는 것이 더 낫습니까?

트랜잭션 로그를 백업하는 작업 하나를 설정하는 것이 좋습니다. 또한 한 번에 하나씩 데이터베이스에 대한 백업을 실행하기 때문에 백업이 I / O를 크게 유틸리티하지 않도록해야합니다.

병렬로 실행하면 가능한 단점

1. 50 개의 데이터베이스가 있고 모든 데이터베이스의 트랜잭션 로그 백업을 예약하고 모두 병렬로 실행하기 시작하면 많은 I / O를 사용할 것입니다. 파일을 백업하는 디스크에 다른 데이터 파일이 있으면 속도가 느려집니다. 많은 I / O를 요청하는 쿼리가 백업 작업과 함께 실행될 때 백업 속도가 느려지는 것을 보았습니다.

2. 다시 한 번 50 개의 데이터베이스가 SQL Server 에이전트에서 50 개의 작업을 관리하는 것이 어렵지 않고 100-200 개의 데이터베이스가있는 경우 어떤 조건이 될 것이라고 가정합니다. 간단하게 유지하십시오. 나는 당신과 같은 사건이 일어날 것이라고 확신합니다.

직렬의 단점은 각 연속 백업이 다른 백업이 완료 될 때까지 대기한다는 것입니다. 이것은 백업 사이의 시간을 잠재적으로 증가시킬 수 있습니다 (즉, 15 분 이상).

트랜잭션 로그 백업은 대부분 작으며 많은 로그 레코드를 생성하는 데이터베이스가 많은 경우 백업 빈도를 변경해야 할 수 있습니다. 빈도가 15 분일 때 트랜잭션 로그 백업이 정상적으로 완료되는 것을 보았습니다. 나는 당신이 걱정할 필요가 없다고 생각합니다.

또한 하나의 백업에서 장애가 발생하면 다른 백업이 발생하는 것을 막을 수 있습니다.

걱정하지 말라고하겠습니다. 실수를하지 않으면 트랜잭션 로그 백업은 실패 할 수 없습니다. 실수는

1. 작업을 실행하는 소유자가 AD에서 제거되었습니다.

2. 누군가 데이터베이스 복구 모델을 변경했습니다.

3. 디스크 공간 부족

위와는 별도로 트랜잭션 로그 백업이 실패하는 이유를 보지 못했습니다. 믿을 수있는 매우 강력합니다.

일반적으로 항상 T-log 백업을 직렬로 실행하십시오. 많은 인스턴스에는 수십 개의 데이터베이스가 있으며 일부는 매우 활성화되어 있으며 트랜잭션 로그 백업에는 총 몇 초 밖에 걸리지 않습니다. 특히 바쁠 때 최대 30 분 정도 소요됩니다.

다음 조건 모두에 해당되는 경우 백업을 병렬로 실행하는 것이 실제로 유리합니다.

• 데이터베이스 및 로그 파일은 모두 고유 한 독립 스핀들에 있거나 모든 조합의 솔리드 스테이트 디스크에 있습니다.

  • T- 로그 백업의 경우 로그 파일 만이 요구 사항을 충족해야합니다.

• 각 데이터베이스의 백업 대상은 별도의 스핀들에 있습니다.

• SQL Server 인스턴스와 미디어간에 공유 SAN HBA 또는 iSCSI 또는 기타 대역폭을 사용하고 있지 않습니다.

• 즉, 데이터베이스 A를 읽고 백업 A를 쓰는 IOPS는 데이터베이스 B를 읽고 백업 B를 쓰는 것과 같은 디스크를 사용 하지 마십시오 .

이 모든 것이 사실이라면 어느 정도의 병렬 처리로 인해 전체 달력 시간이 줄어들 수 있습니다. 이 모든 것이 사실이 아닌 경우 하나 이상의 디스크 세트가 작동하지 않을 가능성이 있으며 병렬 백업은 실제로 직렬보다 달력 시간이 더 많이 걸리지 만 OS 파일 시스템 또는 스토리지 레벨 조각화가 발생할 수 있습니다. 백업 A와 백업 B를 동시에 쓰고 있습니다!

하나의 백업 실패와 나머지 성공에 대해 걱정하지 마십시오. 실패 할 경우 모든 것을 확인해야하며 백업이 실패한 것으로 확인 된 유일한 시간은 다음과 같습니다.

• 디스크 고장

• Hyperbac / Litespeed / 타사 압축 소프트웨어 오류 (SQL과 디스크간에 소프트웨어가있는 경우)

  • 경고로서 실패는 완료되지 않은 백업 작업의 형태를 취할 수 있으므로 경고를 보내는 "예상보다 오래 실행되는 작업"을 확인하는 것이 중요합니다.

• 암호화 제품 실패 (SQL과 디스크간에 소프트웨어가있는 경우 실패)

• 네트워크 오류 (데이터베이스 파일 또는 백업 파일이 네트워크에있을 경우)

• 권한

  • 새로운 설치에서 가장 일반적

  • 또는 새로운 백업 위치

  • SQL Server 서비스 사용자 변경 (일반 백업에 대한 권한이 필요함)

  • 둘 이상의 SQL Server 인스턴스에서 사용되므로 SQL Server 서비스 사용자 잠금

• 구성 오류

• 정전

• OS 충돌

위의 조건이 충족되지 않으면 대부분 영향을 미치지 않습니다.

덧붙여서 Ola는 어떤 이유로 든 하나의 데이터베이스 백업이 백업에 실패하면 다음 스크립트를 시도하는 스크립트를 설계합니다. 앞에서 언급했듯이 모든 데이터베이스를 백업한다고 가정 할 때 모든 사용자 데이터베이스에서 하나의 데이터베이스 백업 만 실패한 경우에도 백업 작업이 계속 실패하므로 작업 실패를 알리는 경고를 설정할 수 있습니다. 모두를위한 직업).