• 아티클

SQL Q+A데이터 보관, 연결된 서버, 대역폭 측정 및 기타 정보

편집자: Nancy Michell

데이터 보관

Q: 그룹에서 사용할 완벽한 데이터 보관 전략이 필요합니다. 현재는 데이터를 백업한 다음 유틸리티를 실행하여 기록 데이터를 삭제하는 표준 모델 기반의 방법을 사용하고 있습니다. 삭제된 데이터를 검색해야 하는 경우 해당 환경과 데이터베이스가 복원됩니다.

단계별로 수행할 수 있는 보관 솔루션을 찾고 있습니다. 1단계에서는 데이터가 데이터베이스에서 삭제되기는 하지만 실시간으로 해당 데이터에 액세스할 수 있어야 합니다. 즉, 프로덕션 데이터베이스의 크기를 관리하기 쉽도록 유지하기 위해 데이터를 제거하기는 하지만 최종 사용자는 계속 데이터에 액세스할 수 있어야 합니다. 2단계에서는 데이터가 완전히 제거되고 해당 데이터에 액세스하려면 먼저 복원 작업을 수행해야 합니다. 이렇게 하려면 어떻게 해야 합니까?

A: 가장 간단한 방법은 데이터베이스의 보관 복사본을 복원한 다음 응용 프로그램을 수정하여 용량이 줄어든 새 데이터베이스에 액세스하거나 사용자가 원하는 경우 용량이 줄어들지 않은 기존 데이터베이스에 액세스하는 것입니다. 결과적으로 각각의 제거 기간 동안에는 데이터베이스 복사본을 유지하게 됩니다.

데이터 변경이 느리게 진행되고 제거 간격 사이에 대부분의 데이터가 변경되지 않는 경우에는 중복되거나 낭비되는 공간이 많아질 수 있습니다. 한편 데이터 액세스가 자주 발생하지 않기 때문에 보관된 데이터를 여러 개의 빠르고 비싼 소용량 드라이브 대신 소수의 느리고 저렴한 대용량 드라이브에 저장할 수도 있습니다. 각 기간 동안에 데이터가 완전히 새로 고쳐지는 경우 이 방법이 적합할 것입니다. 이 프로세스는 관리하기가 매우 쉬우며 대체로 안전합니다.

또한 기존 데이터베이스의 용량을 줄이기 전에 지정 시간 복제본을 만드는 방법을 제공하는 데이터베이스 스냅숏을 사용할 수 있는지 알아 보십시오. 스냅숏이 일부 시나리오에서 잘 작동하기는 하지만 여러 가지 고려할 점이 있습니다. 데이터베이스 스냅숏은 "기록 중 복사"이며 원래 데이터베이스와 스냅숏이 만들어진 지정 시간 사이에 변경된 내용을 지속적으로 유지 관리합니다. 원래 데이터베이스의 변경 내용이 많으면 스냅숏 용량이 매우 커질 수 있습니다.

어떤 의미에서 데이터베이스 스냅숏은 백업 및 복원과 반대됩니다. 데이터베이스 스냅숏은 변경 내용만을 저장하기 때문에 변경이 많지 않을 것으로 예상될 경우에 적합한 반면, 백업 및 복원은 변경이 많을 것으로 예상되는 경우에 더 적합합니다. 이 경우 "기록 중 복사" 공간 절약의 이점은 사라지고 스냅숏 관리의 어려움만 지속됩니다.

또는 테이블 분할(영문)을 사용할 수도 있습니다. 테이블 분할을 사용하면 특정 테이블에서 키 값 범위를 다른 파티션에 속한 것으로 지정한 다음 해당 파티션을 다른 파일 그룹에 배치할 수 있습니다. 한 테이블 내에서 어느 데이터가 어느 파일 그룹으로 이동하게 되는지를 제어하게 되면 관련 비용을 효과적으로 관리할 수 있습니다. 어느 파일 그룹을 어떤 물리적 드라이브에 저장할 것인지(저가 및 고가 드라이브를 비교한 앞의 설명 참조), 그리고 어느 파일 그룹을 얼마나 자주 백업해야 하는지 등을 선택할 수 있습니다. 이러한 파일 그룹을 읽기 전용으로 설정하면 부분 백업을 사용할 수도 있습니다.

데이터베이스 개수

Q: 약 5,000곳의 고객업체에 서비스를 제공할 응용 프로그램을 구현하여 호스팅할 계획입니다. 기밀 유지를 위해 고객별로 하나의 데이터베이스를 구현하고 싶습니다. 서버에 1개 또는 5,000개의 데이터베이스가 있다면 어느 경우에 지정된 데이터 및 인덱스 크기, 사용자 연결 수 및 작업 부하에 대해 서버 리소스가 비효율적으로 사용됩니까?

A: 직원의 수와 관계없이 데이터베이스 간에 동일한 코드 베이스를 유지하기는 어렵습니다. 데이터베이스 코드에서 버그 하나를 수정한다면 수정한 내용을 5,000번 롤아웃해야 합니다. 또한 데이터베이스 복구 시간이 매우 길어질 뿐만 아니라 백업 및 데이터베이스 일관성 검사와 같은 작업의 수행 시간도 길어집니다. 이렇게 한번 생각해 봅시다. 당좌 예금 계좌를 갖고 있는 고객별로 개별 데이터베이스를 호스팅하는 은행이 있습니까?

SQL Server™에서는 원하는 만큼 데이터베이스를 만들 수 있지만 이 방법이 항상 최선의 선택은 아닙니다. 동일한 기간 동안 각 데이터베이스에서 하나의 트랜잭션을 수행해야 하는 작업이 있고, 각 데이터베이스별로 자체 트랜잭션 로그가 있는 경우를 생각해 봅시다. 모두 알다시피 OLTP(Online Transaction Processing) 성능을 결정하는 요소 중 하나는 트랜잭션 로그를 기본 디스크에 순차 쓰기할 수 있는 환경을 유지하는 것입니다. 이러한 데이터베이스에서 읽기 작업보다는 트랜잭션을 수행하려는 경우에는 이 방법을 사용하지 마십시오.

연결된 서버 쿼리

Q: SQL Server 2005 서비스 팩 1(SP1)에서 데이터 웨어하우스를 개발하고 있습니다. 원본 서버는 파트너의 도메인에 있고 대상 서버는 우리 도메인에 있습니다. 연결된 서버를 통해 원본 서버에 있는 레코드를 인출하고 있습니다. 원본 테이블 간의 조인을 사용하여 원본에서 쿼리를 실행하면 쿼리가 매우 빠르게 실행됩니다. 그러나 대상 테이블과의 간단한 조인만 있더라도 쿼리의 실행 속도가 심각하게 느려집니다. 왜일까요?

A: 서버 간 조인은 사용하지 않는 것이 가장 좋은 방법입니다. 특히 도메인이 다른 경우에는 더욱 그렇습니다. 즉, 파트너는 귀사의 도메인을 신뢰하는데 귀사에서는 파트너의 도메인을 신뢰하지 않기 때문에 특정 결과에 따라 이 문제가 발생할 수 있습니다. 쿼리를 리팩터링한 후 원본에서 실행한 다음 결과를 대상에 복사하십시오. 이렇게 하면 더 나은 결과를 얻을 수 있을 것입니다.

대역폭 측정

Q: 데이터베이스 미러링에 사용된 대역폭을 측정하는 가장 유용한 방법이 있습니까? 로그 생성 속도에 약 3배가 되어야 한다는 요구 사항을 이해하기는 하지만 중요한 요청이 아닌 경우 웹상의 광대역 연결을 통해 데이터베이스 미러링을 수행할 수 있습니까?

A: 원시 처리량 외에도 왕복 메시지 대기 시간(safety=full인 경우 더욱 중요함)과 링크 안정성을 고려해야 합니다. 데이터베이스 미러링은 안정적인 네트워크 연결에 최적화되어 있으므로 다시 연결해야 하는 상황에서는 상당한 양의 오버헤드가 발생할 수 있습니다. 광대역 연결이 안정적이지 않은 경우(연결이 끊어지거나 지연 시간이 긴 경우) 연결을 유지하지 못할 수 있습니다. 자세한 내용은 미러링 성능 고려 사항에 대한 백서(영문)를 참조하십시오.

SQL Server 액세스 보안

프로덕션 환경의 SQL Server에 대한 액세스 보안과 관련된 권장 사항을 찾고 계십니까? Microsoft patterns & practices Developer Center(영문)를 참조하십시오. 다음 세 가지 패턴을 주의 깊게 살펴보십시오.

전체 운영 환경을 구성하는 방법을 자세히 알고 싶으십니까? 다음을 참조하시면 많은 도움이 될 것입니다.

많은 Microsoft 기술 전문가들께서 도움을 주셨습니다. Denis Altudov, Jayashree Anand, Gus Apostol, Bhavana Bartholf, Mike Blaszczak, Dibyendu Chakraverty, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Nakul Garg, Phil Hummel, Steve Lindell, Kaloian Manassiev, Al Noel, Ward Pond, Paul Randal, Remus Rusanu, Mike Shelton, Christy Sutton, Kevin Tsai, Peter Ty, Val Wittenberg, Steven Wort, Kalyan Yella와 Frankie Yuen에게 감사의 말을 전합니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..