2009-07-30 2 views

답변

2

이 중 일부는 다른 사람에게도 적용될 수 있지만 SSIS에만 구체적으로 이야기 할 수 있습니다.

패키지를 파일로 저장하고 소스 제어에 넣습니다.

가능한 경우 서버간에 변경되거나 실행되도록 실행되는 변수를 사용하십시오.

다른 환경에 대한 구성을 저장하려면 구성 파일을 사용하십시오.

외부 소스에서 오는 데이터를 처리 할 때 경고없이 형식이 변경된다고 가정합니다 (예 : 각 열에서 예상하는 데이터가 사용자가 가지고있는 데이터인지 확인하십시오). 이메일을 성 필드 (또는 한 번 DTS에서 우리에게 일어난 일로 사회 보장 번호는 그 사람에게 돈을 얼마나 많이 썼는지를 말했고, 누군가가 그 돈을 지불하기 전에 우리가 그걸 알아 냈기 때문에 기뻤습니다.).

새로운 항목 추가, 프로세스에 중요한 열 제거, 열 순서 변경 (특히 파일 자체에 열 이름이 없을 때 좋지 않음) 등이 발생하여 열 제목이 동일하게 유지됩니다. (예를 들어 성 데이터가 First_name으로 표시된 열에 있고 그 반대의 경우 파일을 얻은 후에는 데이터를 변경합니다.) 시스템의 값과 일치하지 않는 새 값을 가진 데이터 (생각합니다. 이메일 필드의 노트와 같은 이상한 데이터, 성 (lastname) 형식의 이름 - 'Willams, Jo'first_name - 'hn'(두 필드를 결합하여 전체 이름을 얻습니다. 분명히 그들의 데이터 입력 사람들은 공백을 다 쓸 때까지 이름을 타이프했고 이름에 상관없이 다음 필드에서 계속되었습니다!).

깨끗한 데이터를 데이터베이스에 저장하지 마십시오.

귀하가 처리하거나 발송하는 파일의 사본을 항상 보관하십시오. 놀랍게도 얼마나 자주 연구해야합니까?

필드의 문제로 인해 프로세스가 실패한 경우에는 청소가 필요한 오류 및 로그 레코드를 기록하십시오. 하나의 레코드에 여분의 레코드가 있으므로 2 천만 레코드 파일이 실패했음을 알리는 것보다 테이블에서 오류를 보는 것이 훨씬 쉽습니다. 그 중 어느 것이 었는지 알아 내려고 노력하십시오.

SSIS에서 유사한 가져 오기를 많이 수행하는 경우 표준 로깅 및 데이터를 모두 포함하는 템플릿 프로젝트를 만듭니다. 템플리트에서 시작하여 작업중인 새 파일을 기반으로 새 매핑을 조정하고 모든 SSIS 패키지를 처음부터 다시 작성하는 것보다 해당 파일에 특정한 사안에 부수적으로 대처하는 것이 훨씬 빠릅니다.

메타 데이터를 저장하십시오. 조만간 파일을받은 후 얼마나 자주 실패했는지, 얼마나 빨리 파일을 받았는지, 마지막으로 가져 왔는지 묻습니다. 모든 메타 데이터 테이블은 메타 데이터 테이블에 시작 및 중지 시간을 저장하는 작업으로 시작하여 끝납니다. 모든 실패 경로에는 가져 오기를 메타 데이터에서 실패한 것으로 표시하는 작업이 포함됩니다. 결국 새로운 파일이 상당히 떨어져 있다면 예상 할 레코드 수를 알고 있고 실패 할 수있는 시스템을 구축 할 수 있습니다. 메타 데이터를 사용하면 예상했던 전체 파일 대신 부분 파일을 보낸시기를 식별하고 실제로 원하는 300,000 개의 판매 목표를 날려 버리지 않도록 할 수있는 레코드 수를 저장하는 데 사용할 수도 있습니다.

관련 문제