1
설정 : 나는 다른 플랫 파일의 많은 일을 정렬하고 T.에 파일 정의에 맞게 테이블에 그들을 던져 매우 큰 SSIS 패키지가 .. 날짜 제외. 날짜는 다음 형식으로 제공됩니다. "MM/dd/yyyy HH:mm:ss.ffffff." 물론 dbtimestamp의 경우이 값을 "yyyy-MM-dd HH:mm:ss.ffffff"으로 변환해야합니다. 주어진 파일에는 적어도 2 개의 날짜가 있습니다. 생성 및 업데이트되었습니다. 일부에는 더 있습니다.SSIS 파생 열 매우 느리게 (날짜 조작)
문제 2 : 내가 분석 한 26 개의 파일 중 하나는 특히 다른 파일보다 큽니다. 어떤 경우에는 40+ MB가 될 수 있습니다. 전에는 잘 돌아가는 것 같았지만 3 개의 날짜를 파생시킨 파생 된 열 구성 요소를 실행하는 것이 이제는 매우 느립니다. 약 걸리고 ~ 90,600 행을 구문 분석합니다.
데이터 흐름이 실행 중일 때 병목 현상이 파생 된 열과 비슷하게 보입니다. 모든 오류 행을보고합니다. 오류 행이있을 경우 아무 것도 없으므로 행에 질식하지 않습니다. 너무 오래 걸리는 부분을 파악할 수 없습니다. CPU은 실행 중 (큰 놀라움은 없음) 최대 100 %까지 촬영하지만 메모리은 12 %로 낮게 유지됩니다.
(DT_DBTIMESTAMP)(SUBSTRING(COLUMN,7,4) + "-" + SUBSTRING(COLUMN,1,2)
+ "-" + SUBSTRING(COLUMN,4,2) + SUBSTRING(COLUMN,11,14))
어떤 아이디어 :
다음은 각 라인 3 날짜의 각각에서 발생 정확한 변환입니까?
나에게 잘 보입니다. 먼저이 줄을 증명해야합니다. 그것을 제거하고 성능이 여전히 발생하는지 확인하십시오. 그렇지 않다면 더 사냥 할 필요가 있습니다. 그것이 간다면, 내 첫 번째 성향은 스크립트 변압기에 대한 시도이며 실수로 40 메가 오랫동안 일부 라인과 같은 더 많은 단서를 제공하는지보십시오. SSIS에서 발견 할 수있는 사실은 그것이 다소 변덕스럽고 사소한 것처럼 보이는 일부 사실은 실제로 디버깅하기가 어려울 수 있다는 것입니다. –
Preet, 아주 좋은 생각이었습니다. 파생 된 열이 병목 현상이었던 것처럼 보였으 나 더 나아갔습니다. 데이터베이스를 복사하고 테스트 DB에 미러링했을 때 나타납니다 (SSIS 패키지가 크게 변경 되었기 때문에). 아무런 제약 조건도 없었습니다. 나는 그들 모두를 재 설립했고 이제는 모든 것이 2.5 분 미만이다. :). – Phrozt
잘 했어. 그 끔찍한 (:-) 기술로 작업해야하는 다음 가난한 사람의 대답에 세부 정보를 입력하십시오! –