I det här svaret kommer jag att försöka tillhandahålla information från officiell dokumentation av SSIS och jag kommer att nämna min personliga erfarenhet av SQL Server-destination.
1. SQL Server Destination
Enligt den officiella SQL Server-destinationsdokumentationen:
SQL Server-destinationen ansluter till en lokal SQL Server-databas och massläser in data till SQL Server-tabeller och vyer. Du kan inte använda SQL Server-destinationen i paket som har åtkomst till en SQL Server-databas på en fjärrserver. Istället bör paketen använda OLE DB-destinationen.
SQL Server-destinationen erbjuder samma snabba infogning av data i SQL Server som uppgiften Bulk Insert ger; Men genom att använda SQL Server-destinationen kan ett paket tillämpa transformationer på kolumndata innan data läses in i SQL Server.
För att ladda data till SQL Server bör du överväga att använda SQL Server-destinationen istället för OLE DB-destinationen
2. OLEDB-destination
Enligt den officiella OLEDB-destinationsdokumentationen:
OLEDB-destination - snabbladdningsalternativ:Ladda data i en tabell eller vy i OLE DB-destinationen och använd snabbladdningsalternativet, som är optimerat för massinlägg
3. OLEDB-destination vs SQL Server-destination
Enligt SQL Server Destination Vs OLE DB Destination - MSDN-ämne:
Donald Farmer, tidigare Group Program Manager för Integration Services sa att du kan få en 5 till 10 % ökning i prestanda med SQL Server Destination .
Dessutom, med hänvisning till följande inlägg av Matt Masson, en dataintegrationsspecialist på Microsoft, där han svarade på följande fråga:
Ska jag använda SQL Server-destinationen?
Svaret var
Nej
...
Min rekommendation är att om du behöver varje bit av prestanda (en 10 % perf-ökning på en 10 timmars belastning kan vara betydande), prova SQL Server-destinationen för att se hur det fungerar för dig. Men – kom ihåg följande begränsningar för SQL Server-destinationen:
- Du måste ha SSIS igång på samma dator som måldatabasen
- Du måste köra paketet som administratör
- Det är mycket svårt att felsöka när saker går fel
Med tanke på dessa begränsningar rekommenderar jag att du använder OLE DB-destinationen även om du ser en prestandaökning med SQL Server-destinationen.
3.1. Prestandaguiden för dataladdning
(Uppdatering @ 2019-03-25)
När jag sökte på SSIS bästa praxis hittade jag en mycket användbar Microsoft-artikel som kan användas som referens:
- The Data Loading Performance Guide
I den här artikeln gjorde de en jämförelse mellan alla dataladdningsmetoder inklusive SQL Server-destination och OLEDB-destination, de nämnde att:
SQL-serverdestination SQL Server-destinationen är det snabbaste sättet att massladda data från ett Integration Services-dataflöde till SQL Server. Den här destinationen stöder alla bulkladdningsalternativ för SQL Server – förutom ROWS_PER_BATCH.
Tänk på att denna destination kräver delade minnesanslutningar till SQL Server. Det betyder att den endast kan användas när Integration Services körs på samma fysiska dator som SQL Server.
OLE DB-destination: OLE DB-destinationen stöder alla bulkladdningsalternativ för SQL Server. För att stödja beställd bulklast krävs dock ytterligare konfiguration. För mer information, se "Sorterade indata". För att använda bulk-API:et måste du konfigurera denna destination för "snabbladdning".
OLE DB-destinationen kan använda både TCP/IP och namngivna pipes-anslutningar till SQL Server. Detta innebär att OLE DB-destinationen, till skillnad från SQL Server-destinationen, kan köras på en annan dator än bulkbelastningsmålet. Eftersom Integration Services-paket som använder OLE DB-destinationen inte behöver köras på själva SQL Server-datorn, kan du skala ut ETL-flödet med workhorse-servrar.
3.2. Personlig erfarenhet
(Uppdatering @ 2019-03-25)
Eftersom den här frågan används som referens av många, och efter att ha varit mer erfaren inom denna domän, lade jag till det här avsnittet för att nämna min personliga erfarenhet av att använda SQL Server-destination.
Även om officiell dokumentation nämnde att SQL Server-destination kommer att öka prestandan, rekommenderar jag inte alls att använda dessa komponenter på grund av många anledningar:
- Det kräver att destinationsservern och ETL-servern är samma (fungerar endast med lokal SQL-server)
- Det ger alltid undantag som inte har någon betydelse
- Efter att ha testats på enorma datavolymer är prestandaskillnaden med OLEDB-destination försumbar (testad på cirka 500 GB data laddad i bitar och tidsskillnaden är mindre än en minut)
Du kan också hänvisa till följande inlägg (från @billinkc) för att få mer information om detta ämne:
- Bör SSIS-paket och SQL-databas finnas på samma server?
4. Slutsats
Baserat på Microsoft-artiklar kan du säga att SQL Server Destination öka prestandan för att infoga data (den använder BULK insert) , men den är designad för ett specifikt fall som är den lokala SQL-servern. OLEDB Destination är mer allmänt och rekommenderas i andra fall och genom att använda Fast Load dataåtkomstläge (som även använder BULK insert) på OLE DB destination det kommer att öka prestandan för dataladdning.
Å andra sidan, baserat på min erfarenhet och från många artiklar skrivna av SSIS-experter, rekommenderas det inte alls att använda SQL Server Destination eftersom det inte är stabilt och det ofta ger undantag och prestandan kan anses vara försumbar.
Ytterligare information
Nyligen publicerade jag en detaljerad artikel om detta ämne. Du kan kontrollera det på:
- SSIS OLE DB-destination kontra SQL Server-destination