W tej odpowiedzi postaram się podać informacje z oficjalnej dokumentacji SSIS i wspomnę o moich osobistych doświadczeniach z docelowym serwerem SQL.
1. Miejsce docelowe serwera SQL
Zgodnie z oficjalną dokumentacją miejsca docelowego serwera SQL:
Miejsce docelowe programu SQL Server łączy się z lokalną bazą danych programu SQL Server i zbiorczo ładuje dane do tabel i widoków programu SQL Server. Nie można używać miejsca docelowego programu SQL Server w pakietach, które uzyskują dostęp do bazy danych programu SQL Server na serwerze zdalnym. Zamiast tego pakiety powinny używać miejsca docelowego OLE DB.
Miejsce docelowe programu SQL Server oferuje taką samą szybkość wstawiania danych do programu SQL Server, jaką zapewnia zadanie wstawiania zbiorczego; jednak używając miejsca docelowego SQL Server, pakiet może zastosować przekształcenia do danych kolumn, zanim dane zostaną załadowane do SQL Server.
Aby załadować dane do SQL Server, należy rozważyć użycie miejsca docelowego SQL Server zamiast miejsca docelowego OLE DB
2. Miejsce docelowe OLEDB
Zgodnie z oficjalną dokumentacją miejsca docelowego OLEDB:
Miejsce docelowe OLEDB - opcja szybkiego ładowania:Załaduj dane do tabeli lub widoku w miejscu docelowym OLE DB i użyj opcji szybkiego ładowania, która jest zoptymalizowana pod kątem wstawiania zbiorczego
3. Miejsce docelowe OLEDB a miejsce docelowe serwera SQL
Zgodnie z miejscem docelowym serwera SQL Server i miejscem docelowym OLE DB — temat MSDN:
Donald Farmer, były kierownik programu grupowego ds. usług integracyjnych, powiedział, że można uzyskać od 5 do 10% wzrost wydajności, korzystając z SQL Server Destination
.
Ponadto, odnosząc się do następującego postu Matta Massona, specjalisty ds. integracji danych w firmie Microsoft, gdzie odpowiedział na następujące pytanie:
Czy powinienem używać miejsca docelowego serwera SQL?
Odpowiedź brzmiała
Nie
...
Moje zalecenie jest takie, że jeśli potrzebujesz maksymalnej wydajności (wzrost wydajności o 10% przy 10-godzinnym obciążeniu może być znaczny), wypróbuj lokalizację docelową programu SQL Server, aby zobaczyć, jak to działa. Należy jednak pamiętać o następujących ograniczeniach miejsca docelowego serwera SQL:
- Musisz mieć SSIS działające na tym samym komputerze co docelowa baza danych
- Musisz uruchomić pakiet jako administrator
- Bardzo trudno jest debugować, gdy coś pójdzie nie tak
Biorąc pod uwagę te ograniczenia, polecam używanie miejsca docelowego OLE DB nawet jeśli obserwujesz wzrost wydajności w miejscu docelowym serwera SQL.
3.1. Przewodnik po wydajności ładowania danych
(Aktualizacja 25.03.2019)
Podczas wyszukiwania najlepszych praktyk SSIS znalazłem bardzo pomocny artykuł Microsoft, który można wykorzystać jako odniesienie:
- Przewodnik wydajności ładowania danych
W tym artykule dokonali porównania między wszystkimi metodami ładowania danych, w tym miejscem docelowym SQL Server i miejscem docelowym OLEDB, wspomnieli, że:
Miejsce docelowe serwera SQL Miejsce docelowe programu SQL Server to najszybszy sposób zbiorczego ładowania danych z przepływu danych usług integracji do programu SQL Server. To miejsce docelowe obsługuje wszystkie opcje ładowania zbiorczego SQL Server – z wyjątkiem ROWS_PER_BATCH.
Należy pamiętać, że to miejsce docelowe wymaga połączeń pamięci współdzielonej z programem SQL Server. Oznacza to, że można go używać tylko wtedy, gdy Integration Services działa na tym samym fizycznym komputerze, co SQL Server.
Miejsce docelowe OLE DB: Miejsce docelowe OLE DB obsługuje wszystkie opcje ładowania zbiorczego dla programu SQL Server. Jednak do obsługi zamówionego ładunku zbiorczego wymagana jest dodatkowa konfiguracja. Aby uzyskać więcej informacji, zobacz „Posortowane dane wejściowe”. Aby korzystać ze zbiorczego interfejsu API, musisz skonfigurować to miejsce docelowe do „szybkiego ładowania”.
Miejsce docelowe OLE DB może używać zarówno połączeń TCP/IP, jak i nazwanych potoków z SQL Server. Oznacza to, że miejsce docelowe OLE DB, w przeciwieństwie do miejsca docelowego programu SQL Server, można uruchomić na komputerze innym niż miejsce docelowe ładowania zbiorczego. Ponieważ pakiety Integration Services, które używają miejsca docelowego OLE DB, nie muszą być uruchamiane na samym komputerze SQL Server, można skalować w poziomie przepływ ETL z serwerami roboczymi.
3.2. Osobiste doświadczenie
(Aktualizacja 25.03.2019)
Ponieważ to pytanie jest używane przez wielu jako punkt odniesienia i po tym, jak mam większe doświadczenie w tej domenie, dodałem tę sekcję, aby wspomnieć o moich osobistych doświadczeniach z używaniem serwera SQL Server.
Chociaż oficjalna dokumentacja wspominała, że przeznaczenie SQL Server zwiększy wydajność, w ogóle nie zalecam używania tych komponentów z wielu powodów:
- Wymaga, aby serwer docelowy i serwer ETL były takie same (działa tylko z lokalnym serwerem SQL)
- Zawsze zgłasza wyjątek, który nie ma żadnego znaczenia
- Po testach na ogromnych ilościach danych różnica wydajności z miejscem docelowym OLEDB jest znikoma (przetestowano na około 500 GB danych załadowanych porcjami, a różnica czasu jest mniejsza niż jedna minuta)
Możesz również zapoznać się z następującym postem (z @billinkc) aby uzyskać więcej informacji na ten temat:
- Czy pakiety SSIS i baza danych SQL powinny znajdować się na tym samym serwerze?
4. Wniosek
Na podstawie artykułów firmy Microsoft można powiedzieć, że SQL Server Destination
zwiększyć wydajność wstawiania danych (używa wstawiania BULK) , ale jest przeznaczony do konkretnego przypadku, jakim jest lokalny serwer SQL. OLEDB Destination
jest bardziej ogólne i zalecane w innych przypadkach oraz przy użyciu Fast Load
tryb dostępu do danych (który używa również wstawiania BULK) w OLE DB destination
zwiększy to wydajność ładowania danych.
Z drugiej strony, w oparciu o moje doświadczenie i wiele artykułów napisanych przez ekspertów SSIS, w ogóle nie zaleca się używania SQL Server Destination ponieważ nie jest stabilny i często zgłasza wyjątki, a wydajność można uznać za znikomą.
Dodatkowe informacje
Niedawno opublikowałem szczegółowy artykuł na ten temat. Możesz to sprawdzić pod adresem:
- Miejsce docelowe SSIS OLE DB a miejsce docelowe serwera SQL