SQL Server 복제를 구현할시기를 나타내는 객관적인 요소는 무엇입니까?

데이터베이스의 고성능과 유지 관리 용이성 사이의 균형을 유지하려고합니다. SSRS 보고서를 트랜잭션 데이터베이스와 물리적으로 분리 된 데이터베이스에 복제하여 복제 기능을 사용하여 성능을 향상시킬 것을 고려하고 있습니다. 그러나 복제를 활성화하면 개발자의 관점에서 여러 가지 단점이 있습니다.

• 스키마 변경이 더 어려워집니다.
• 자동화 된 통합 / 빌드 서버를 방해합니다
• SQL 소스 제어를 구현하기가 어려운 것 같습니다

내 질문은 : 당신은 언제 이러한 단점에 비추어 복제와 함께 갈 시간을 알고 있습니까? 추가 복잡성이 이득을 정당화하는지 여부를 어떻게 결정합니까?

우리는 그것을 사용하기 전에 그것을 사용했기 때문에 설정하는 것은 문제가되지 않습니다. 이는 의사 결정을 활성화할지 여부에 관한 것입니다. 다른 사람들이 복제를 통해 관찰 한 일부 개체 성능 지표를 찾고 있습니다.

물론 가장 좋은 방법은 자체 서버에서 시뮬레이션 된로드 테스트를 수행하여 스스로 알아내는 것이지만, 일반적인 지침이 있기를 바랍니다.

응용 프로그램 디자인 단계에서 복제를 고려해야합니다. 지리적으로 분산 된 인력 / 사용자 기반이있는 경우 지역 데이터베이스와 중앙 데이터베이스가 적합 할 수 있습니다. 랩톱에서 연결이 끊긴 데이터베이스는 네트워크에 마지막으로 다시 연결될 때 "동기화"될 수 있습니다 (도로상의 영업 직원을 생각하십시오).

보고 목적과 관련하여 복제는 답이 아닙니다. 보고 환경에서 성능 문제의 대부분은 OLTP (Online Transaction Processing) 용으로 구성된 시스템에 대해 보고서를 작성한다는 사실에서 비롯됩니다.

보고 목적의 복제는 단순히 OLTP 데이터를 다른 서버로 옮기는 것과 동일한 보고서를 친숙하지 않은 구조로 유지하는 것입니다. 본질적으로, 문제가 발생하면 더 많은 하드웨어를 사용하고 유지 보수 비용을 늘리지 만 한계가 있습니다.

보고 있어야 할 것은 보고서에 필요한 특정 데이터를 가져 와서보다 유용한 형식으로 변환하는 방법입니다. 프로덕션 데이터베이스에서 새 트랜잭션을 가져와보고 데이터베이스, 바람직하게는 별도의 서버에 저장하는 피드를 작성하십시오. 피드가 실행될 때마다 마지막으로 실행 한 것보다 최신 인 모든 데이터를 가져 와서 변환하고 저장해야합니다. 현재 실행중인 보고서는 필요한 변환 유형에 대한 좋은 아이디어를 제공합니다.

이 접근 방식을 따르면 성능이 크게 향상됩니다.

보고서 작성자가 복제 된 데이터베이스의 인덱스를 "소유"할 수 있기 때문에 유사한 상황에서 복제가 유용한 것으로 나타났습니다. 이를 통해 애플리케이션 개발자가 INSERTS 및 UPDATES에 부정적인 영향을 미치므로 프로덕션에서 승인되지 않은 인덱스를 추가하여 쿼리 성능을 향상시킬 수있었습니다.

유스 케이스의 일부는 트랜잭션 테이블을 복사하고 인덱싱을 변경하고 그 가치가 있는지 확인하는 것입니다.

도움이 되었기를 바랍니다!