In dit antwoord zal ik proberen informatie te verstrekken uit de officiële documentatie van SSIS en zal ik mijn persoonlijke ervaring met de SQL Server-bestemming vermelden.
1. SQL Server-bestemming
Volgens de officiële SQL Server Destination-documentatie:
De SQL Server-bestemming maakt verbinding met een lokale SQL Server-database en laadt gegevens in bulk in SQL Server-tabellen en -weergaven. U kunt de SQL Server-bestemming niet gebruiken in pakketten die toegang hebben tot een SQL Server-database op een externe server. In plaats daarvan moeten de pakketten de OLE DB-bestemming gebruiken.
De SQL Server-bestemming biedt dezelfde snelle invoer van gegevens in SQL Server die de taak Bulksgewijs invoegen biedt; door echter de SQL Server-bestemming te gebruiken, kan een pakket transformaties toepassen op kolomgegevens voordat de gegevens in SQL Server worden geladen.
Voor het laden van gegevens in SQL Server moet u overwegen de SQL Server-bestemming te gebruiken in plaats van de OLE DB-bestemming
2. OLEDB-bestemming
Volgens de officiële OLEDB Destination-documentatie:
OLEDB-bestemming - optie voor snel laden:laad gegevens in een tabel of weergave in de OLE DB-bestemming en gebruik de optie voor snel laden, die is geoptimaliseerd voor bulkinvoegingen
3. OLEDB-bestemming versus SQL Server-bestemming
Volgens SQL Server Destination versus OLE DB Destination - MSDN-onderwerp:
Donald Farmer, de voormalige Group Program Manager for Integration Services, zei dat je een prestatieverbetering van 5 tot 10% kunt krijgen met behulp van de SQL Server Destination .
Daarnaast verwijzend naar de volgende functie van Matt Masson, een data-integratiespecialist bij Microsoft, waar hij de volgende vraag beantwoordde:
Moet ik de SQL Server-bestemming gebruiken?
Het antwoord was
Nee
...
Mijn aanbeveling is dat als je elk beetje prestatie nodig hebt (een prestatieverhoging van 10% bij een belasting van 10 uur kan aanzienlijk zijn), probeer dan de SQL Server Destination om te zien hoe het voor jou werkt. Houd echter rekening met de volgende beperkingen van de SQL Server-bestemming:
- Je moet SSIS op dezelfde computer hebben draaien als de doeldatabase
- U moet het pakket als beheerder uitvoeren
- Het is erg moeilijk om fouten op te sporen als er iets misgaat
Gezien deze beperkingen, Ik raad aan om de OLE DB-bestemming te gebruiken zelfs als u een prestatieverbetering ziet met de SQL Server Destination.
3.1. De prestatiegids voor het laden van gegevens
(Update @ 25-03-2019)
Tijdens het zoeken naar best practices van SSIS vond ik een zeer nuttig Microsoft-artikel dat als referentie kan worden gebruikt:
- De prestatiegids voor het laden van gegevens
In dit artikel maakten ze een vergelijking tussen alle methoden voor het laden van gegevens, inclusief SQL Server-bestemming en OLEDB-bestemming, ze vermeldden dat:
SQL Server-bestemming De SQL Server-bestemming is de snelste manier om gegevens in bulk te laden van een Integration Services-gegevensstroom naar SQL Server. Deze bestemming ondersteunt alle bulklaadopties van SQL Server, behalve ROWS_PER_BATCH.
Houd er rekening mee dat deze bestemming gedeelde geheugenverbindingen met SQL Server vereist. Dit betekent dat het alleen kan worden gebruikt wanneer Integration Services op dezelfde fysieke computer als SQL Server draait.
OLE DB-bestemming: De OLE DB-bestemming ondersteunt alle bulklaadopties voor SQL Server. Om bestelde bulklading te ondersteunen, is echter enige aanvullende configuratie vereist. Zie “Gesorteerde invoergegevens” voor meer informatie. Om de bulk-API te gebruiken, moet u deze bestemming configureren voor "snel laden".
De OLE DB-bestemming kan zowel TCP/IP- als named pipes-verbindingen met SQL Server gebruiken. Dit betekent dat de OLE DB-bestemming, in tegenstelling tot de SQL Server-bestemming, kan worden uitgevoerd op een andere computer dan het bulklaaddoel. Omdat Integration Services-pakketten die de OLE DB-bestemming gebruiken niet op de SQL Server-computer zelf hoeven te worden uitgevoerd, kunt u de ETL-stroom uitbreiden met werkpaardservers.
3.2. Persoonlijke ervaring
(Update @ 25-03-2019)
Aangezien deze vraag door velen als referentie wordt gebruikt, en nadat ik meer ervaring heb opgedaan in dit domein, heb ik deze sectie toegevoegd om mijn persoonlijke ervaring met het gebruik van SQL Server-bestemmingen te vermelden.
Hoewel officiële documentatie vermeldde dat de SQL Server-bestemming de prestaties zal verbeteren, raad ik het gebruik van deze componenten om verschillende redenen helemaal niet aan:
- Het vereist dat de doelserver en de ETL-server hetzelfde zijn (werkt alleen met lokale SQL-server)
- Het werpt altijd uitzonderingen op die geen betekenis hebben
- Na testen op enorme hoeveelheden gegevens is het prestatieverschil met de OLEDB-bestemming te verwaarlozen (getest op ongeveer 500 GB gegevens die in brokken zijn geladen en het tijdsverschil is minder dan een minuut)
Je kunt ook verwijzen naar het volgende bericht (van @billinkc) voor meer informatie over dit onderwerp:
- Moeten SSIS-pakketten en SQL-database op dezelfde server staan?
4. Conclusie
Op basis van Microsoft-artikelen kun je zeggen dat SQL Server Destination de prestaties van het invoegen van gegevens verbeteren (het gebruikt BULK-insertie) , maar het is ontworpen voor een specifiek geval, namelijk de lokale SQL-server. OLEDB Destination is algemener en wordt aanbevolen in de andere gevallen en met behulp van de Fast Load gegevenstoegangsmodus (die ook BULK-invoeging gebruikt) op de OLE DB destination het zal de prestaties van het laden van gegevens verhogen.
Aan de andere kant, op basis van mijn ervaring en uit vele artikelen geschreven door SSIS-experts, het wordt helemaal niet aanbevolen om SQL Server Destination te gebruiken omdat het niet stabiel is en vaak uitzonderingen genereert en de prestaties als verwaarloosbaar kunnen worden beschouwd.
Aanvullende informatie
Onlangs heb ik een uitgebreid artikel over dit onderwerp gepubliceerd. Je kunt het controleren op:
- SSIS OLE DB-bestemming versus SQL Server-bestemming