Mam pakiet SSIS - dwa zadania przepływu danych, po 8 komponentów, czytanie z dwóch płaskich plików, nic spektakularnego. Jeśli uruchomię go w BIDS, zajmuje to niezawodnie około 60 sekund. Mam serwer DB piaskownicy z pakietem uruchomionym w zadaniu, który również niezawodnie zajmuje 30-60 sekund. Na moim serwerze produkcyjnym ta sama praca z tym samym pakietem zajmuje od 30 sekund do12 godzin.

Po włączeniu rejestrowania w pakiecie wygląda na to, że zapada się - początkowo przynajmniej - w fazie przed wykonaniem jednego lub drugiego (lub obu) zadań przepływu danych. Ale widzę też nadchodzące dane - powoli, w kawałkach, więc myślę, że to się później zmieni. Podsystem IO zostaje rozbity, a SSIS generuje wiele dużych plików tymczasowych (o wartości około 150 MB - moje pliki danych wejściowych są tylko około 24 MB razem) i energicznie odczytuje i zapisuje z tych plików (rzucając?).

Warto zauważyć, że jeśli wskażę moją instancję pakietu BIDS na serwerze produkcyjnym, uruchomienie zajmie tylko około 60 sekund! Więc musi to być coś z uruchomieniem tam dtexec, a nie sama DB.

Próbowałem już zoptymalizować mój pakiet, zmniejszając rozmiar bajtów wiersza wejściowego, i wykonałem dwa zadania przepływu danych uruchamiane szeregowo, a nie równolegle - bezskutecznie.

Oba serwery DB korzystają z 64-bitowego MSSQL 2008 R2, tego samego poziomu poprawki. Oba serwery to maszyny wirtualne na tym samym hoście, z tą samą alokacją zasobów. Obciążenie na serwerze produkcyjnym nie powinno być teraz o wiele wyższe niż na serwerze piaskownicy. Jedyną różnicą, jaką widzę, jest to, że serwer produkcyjny działaWindows Serwer 2008, podczas gdy piaskownica znajduje się w systemie Windows Server 2008R2.

Wsparcie!!! Jakieś pomysły na wypróbowanie są mile widziane, co może powodować tę ogromną rozbieżność?

załącznik A

Oto jak wygląda mój pakiet…

Przepływ sterowania jest niezwykle prosty:

Przepływ danych wygląda tak:

Drugie zadanie przepływu danych jest dokładnie takie samo, tylko z innym plikiem źródłowym i tabelą docelową.

Uwagi

Ograniczenie ukończenia w przepływie sterowania polega tylko na tym, aby zadania były uruchamiane szeregowo, aby spróbować ograniczyć zasoby potrzebne jednocześnie (nie żeby pomogło to rozwiązać problem)… nie ma rzeczywistej zależności między tymi dwoma zadaniami.

Jestem świadomy potencjalnych problemów z transformacjami blokującymi i częściowo blokującymi (nie mogę powiedzieć, że rozumiem je całkowicie, ale przynajmniej w pewnym stopniu) i wiem, że łączenie agregatów i scalanie blokują się i mogą powodować problemy. Jednak znowu wszystko to działa dobrze i szybko w każdym innym środowisku z wyjątkiem serwera produkcyjnego… więc co daje?

Powodem łączenia scalania jest spowodowanie, aby zadanie czekało na zakończenie obu gałęzi Multicast. Prawa gałąź znajduje minimalny datetime na wejściu i usuwa wszystkie rekordy w tabeli po tej dacie, podczas gdy lewa gałąź przenosi nowe rekordy wejściowe do wstawienia - więc jeśli prawa gałąź przechodzi przed zagregowaniem i usunięciem, nowe rekordy będą zostać usunięte (to się stało). Nie znam lepszego sposobu zarządzania tym.

Wyjście błędu z „Usuń rekordy” jest zawsze puste - jest to celowe, ponieważ w rzeczywistości nie chcę żadnych wierszy z tej gałęzi w scaleniu (scalenie służy jedynie do synchronizacji zakończenia, jak wyjaśniono powyżej).

Zobacz komentarz poniżej na temat ikon ostrzegawczych.