2009-10-02 6 views
3

나는이 질문에 어떻게 대답 할 지 모르겠다. 그래서 나는 설명하려고 노력할 것이다. SQL Server 2005에 타사 데이터베이스가 있습니다. 타사 데이터베이스에도 일부 데이터를 "게시"하고자하는 또 다른 SQL Server 2008이 있습니다. 이 데이터베이스는 포털 및보고 서비스의 백엔드로 사용되며 데이터웨어 하우스가됩니다.SQL Server - ETL의 쿼리와 테이블을 동기화 된 상태로 유지하려면 어떻게해야합니까?

대상 서버에서 다른 테이블 구조의 데이터를 타사 db의 데이터와 함께 저장하려고합니다. 비정규 화하려는 일부 테이블에는 필요하지 않은 컬럼이 많이 있습니다. 또한 동일한 행에 저장된 데이터를 기반으로 업데이트해야하는 일부 테이블에 필드를 추가해야합니다. 예를 들어, 다른 열을 채울 정보가 들어있는 varchar 필드가 있습니다. 이 모든 것은 데이터를 정화하고보고하기가 더 쉬워야합니다.

특정 대상 테이블에서 원하는 모든 정보를 얻기 위해 쿼리를 작성할 수 있습니다. 그러나 다른 서버의 소스를 최신 상태로 유지하려고합니다. 그것은 즉시 업데이트 될 필요는 없지만 (좋을지라도) 아마 10 분마다 업데이트되기를 바랍니다. 100 개의 데이터 행이 있지만 데이터 변경 및 새로운 행 추가 등은 크지 않습니다.

나는 주변을 둘러 보았지만 여전히 이것을 달성하는 가장 좋은 방법은 확실하지 않습니다. 내가 아는 한 복제는 내가 필요한 것을하지 않을 것이다. Merge 문을 사용하여 업데이트를 수행 한 다음 SQL Server 에이전트를 사용하여 작업으로 예약하도록 t-sql을 수동으로 작성할 수 있습니다. 나는 또한 SSIS를 살펴 봤는데 그것은 ETL과 같은 것들을 목표로하고있는 것처럼 보인다.

나는 이것을 달성하기 위해 무엇을 사용해야하는지 잘 모르겠다. 나는 이런 종류의 일을 어떻게해야하는지에 관해 조언을 얻기를 희망했다. 어떤 제안이라도 대단히 감사하겠습니다.

답변

0

닉, SSIS 경로를 직접 통과했습니다. 저는 SSIS를 기반으로하고 매 15 분마다하는 일을하고 있으며 당신이하려고하는 정확한 일을합니다. 우리는 거대한 관계형 데이터베이스를 가지고 있으며 그 다음에 Tableau라는 제품을 사용하여 복잡한보고를 수행하기를 원했습니다. 우리는 관계형 모델이 그다지 열성적이지 않아 SSAS로 큐브를 만들었고 그 큐브는 15 분마다 업데이트되고 처리된다는 것을 곧 알게되었습니다. 예 SSIS는 주로 직선 ETL 작업에 대한 분위기를 나타내지 만 이와 같은 간단한 빠른 작업에도 사용할 수있는 것으로 나타났습니다.

+0

응답 해 주셔서 감사합니다. 비슷한 것을 달성하기 위해 SSIS를 사용했다는 이야기를 듣고 흥미 롭습니다. SSIS를 사용하여 성능이 어떻게됩니까? SSIS의 어떤 종류의 기능을 사용 했습니까? 실행 한 T-SQL 코드 또는 이러한 데이터 흐름 변환을 사용하는 T-SQL 코드였습니까? – Nick

+0

사실 두 가지 모두 포함됩니다. 수많은 데이터 흐름 변환을 사용하여 차원을 업데이트하고 일부 T-SQL 구성 요소를 사용하여 프로세스 중에 사용하는 원시 데이터 테이블을 지 웁니다. 성능에 문제가 없었으며 작업 실행시 서버의 속도 저하에 대해 아무도 불평하지 않았습니다. 전반적으로 SSIS는 지금까지 매우 행복합니다. – ajdams

+0

성능 소리가 좋아. 그리고 그걸위한 스테이징 테이블을 사용합니까? 필자는이 주제에 대해 읽었으며 스테이징 테이블을 제안하고 파티셔닝을 사용하여 새로 업데이트 된 데이터로 전환했습니다. – Nick

1

스키마/realtions이 변경되지 않는 테이블의 경우 복제를 강력히 권장합니다.

데이터 및/또는 관계가 크게 변경되는 테이블의 경우이를 처리하기 위해 Service Broker 구현을 개발하는 것이 좋습니다. 서비스 브로커 (SB)와 하이 레벨의 접근 방식은 다음과 같습니다 당신이 dialy 수출/수입 같은에 가고 싶어하지 않는 나는, 이것에 대한 SSIS를 권하고 싶지 않다

Table-->Trigger-->SB.Service >====> SB.Queue-->StoredProc(activated)-->Table(s) 

. 이런 종류의 일은 괜찮지 만, IMHO는 지속적이거나 단기간의 증분 데이터 분배에 너무 복잡하고 성가신 일입니다.

+0

스키마 변경이 필요하므로 데이터를 검사해야하므로 복제가이 인스턴스에 적합하지 않다고 생각합니다. 타사 db에는 각 테이블에 대한 기본 키가 없으므로 트랜잭션 복제가 제외됩니다. 서비스 브로커 방식은 여러 테이블에 트리거를 추가해야 할 때 사용할 수있는 솔루션이며 서비스 브로커 솔루션을 작동시키기 위해 더 많은 작업이 필요합니다. SSIS 접근법에 대한 귀하의 우려를 공유하지만, 다른 사람들이 자신의 DW를 이보다 자주 업데이트한다고 들었습니다. 또한 SSIS를 사용한다고 가정합니다. – Nick

+0

SSIS는 진행중인 스키마 변경을 전혀 처리하지 않습니다. 이것은 적어도 Service Broker가 처리 할 수있는 기회입니다 (DDL 트리거를 소스로 사용). 나는 소스와 타겟 DB 스키마가 다르기 시작할 때 할 수있는 다른 것을 모른다. – RBarryYoung

0

내 생각에 스테이징 및 파티셔닝이 너무 어려울 것입니다. SSIS에서 동일한 작업을 지금 구현하고 있지만 지원 활동에 약간의 시간을 할애해야하므로 1 시간의 빈도로 수행합니다. SSIS를 사용하는 것이 좋은 방법이라고 확신합니다.

디자인 중에 변경 데이터 캡처 (CDC) 프로세스를 사용자 지정하여 사용자 지정 복제를 수행하는 또 다른 방법을 생각해 보았습니다. 이렇게하면 거의 실시간으로 복제 할 수 있지만 까다로운 일입니다.

+0

CDC는 2008 년 버전으로 출시 된 것 같아요. 소스 코드로 2005 년을 고수 했으므로 고려하지 않았습니다. 스테이징 및 파티셔닝이 너무 많을 것이라고 말하면 업데이트하려는 빈도 때문입니다. – Nick

+0

주파수와 지연이 발생할 수 있습니다. 비용과 이득을 고려한다면 그럴 수 없습니다. – Faiz

관련 문제