sql >> Database teknologi >  >> RDS >> Sqlserver

SQL Server-destination vs OLE DB-destination

I dette svar vil jeg forsøge at give oplysninger fra den officielle dokumentation af SSIS, og jeg vil nævne min personlige erfaring med SQL Server-destination.

1. SQL Server-destination

Ifølge den officielle SQL Server-destinationsdokumentation:

SQL Server-destinationen opretter forbindelse til en lokal SQL Server-database og masseindlæser data til SQL Server-tabeller og -visninger. Du kan ikke bruge SQL Server-destinationen i pakker, der får adgang til en SQL Server-database på en ekstern server. I stedet skal pakkerne bruge OLE DB-destinationen.

SQL Server-destinationen tilbyder den samme højhastighedsindsættelse af data i SQL Server, som Bulk Insert-opgaven giver; Men ved at bruge SQL Server-destinationen kan en pakke anvende transformationer til kolonnedata, før dataene indlæses i SQL Server.

For at indlæse data i SQL Server bør du overveje at bruge SQL Server-destinationen i stedet for OLE DB-destinationen

2. OLEDB-destination

Ifølge den officielle OLEDB-destinationsdokumentation:

OLEDB-destination - mulighed for hurtig indlæsning:Indlæs data i en tabel eller visning i OLE DB-destinationen, og brug muligheden for hurtig indlæsning, som er optimeret til bulkinserts

3. OLEDB-destination vs SQL Server-destination

Ifølge SQL Server Destination Vs OLE DB Destination - MSDN emne:

Donald Farmer, den tidligere Group Program Manager for Integration Services sagde, at du kan få en 5 til 10 % stigning i ydeevnen ved at bruge SQL Server Destination .

Derudover med henvisning til følgende indlæg af Matt Masson, en dataintegrationsspecialist hos Microsoft, hvor han besvarede følgende spørgsmål:

Skal jeg bruge SQL Server-destinationen?

Svaret var

Nej

...

Min anbefaling er, at hvis du har brug for hver eneste smule ydeevne (en 10 % perf-stigning på en 10 timers belastning kan være betydelig), så prøv SQL Server-destinationen for at se, hvordan den fungerer for dig. Dog – husk følgende begrænsninger for SQL Server-destinationen:

  • Du skal have SSIS kørende på den samme maskine som destinationsdatabasen
  • Du skal køre pakken som administrator
  • Det er meget svært at fejlfinde, når tingene går galt

I betragtning af disse begrænsninger anbefaler jeg at bruge OLE DB-destinationen selvom du ser en ydelsesforøgelse med SQL Server-destinationen.

3.1. Vejledning til ydeevne for dataindlæsning

(Opdatering @ 2019-03-25)

Mens jeg søgte på SSIS bedste praksis, fandt jeg en meget nyttig Microsoft-artikel, der kan bruges som reference:

  • The Data Loading Performance Guide

I denne artikel lavede de en sammenligning mellem alle dataindlæsningsmetoder inklusive SQL Server-destination og OLEDB-destination, de nævnte, at:

SQL-serverdestination SQL Server-destinationen er den hurtigste måde at masseindlæse data fra et Integration Services-dataflow til SQL Server. Denne destination understøtter alle bulk load muligheder for SQL Server – undtagen ROWS_PER_BATCH.

Vær opmærksom på, at denne destination kræver delte hukommelsesforbindelser til SQL Server. Det betyder, at det kun kan bruges, når Integration Services kører på den samme fysiske computer som SQL Server.

OLE DB-destination: OLE DB-destinationen understøtter alle bulk load-indstillinger for SQL Server. For at understøtte bestilt bulkbelastning er der dog behov for yderligere konfiguration. For mere information, se "Sorterede inputdata". For at bruge bulk-API'en skal du konfigurere denne destination til "hurtig indlæsning".

OLE DB-destinationen kan bruge både TCP/IP og navngivne rørforbindelser til SQL Server. Dette betyder, at OLE DB-destinationen, i modsætning til SQL Server-destinationen, kan køres på en anden computer end bulk load-målet. Fordi Integration Services-pakker, der bruger OLE DB-destinationen, ikke behøver at køre på selve SQL Server-computeren, kan du udskalere ETL-flowet med workhorse-servere.

3.2. Personlig erfaring

(Opdatering @ 2019-03-25)

Da dette spørgsmål bruges som reference af mange, og efter at have været mere erfaren på dette domæne, tilføjede jeg dette afsnit for at nævne min personlige erfaring med at bruge SQL Server-destination.

Selvom officiel dokumentation nævnte, at SQL Server-destination vil øge ydeevnen, anbefaler jeg slet ikke at bruge disse komponenter af mange årsager:

  1. Det kræver, at destinationsserveren og ETL-serveren er de samme (fungerer kun med lokal SQL-server)
  2. Det giver altid undtagelser, der ikke har nogen betydning
  3. Efter test på store mængder data er ydeevneforskellen med OLEDB-destination ubetydelig (testet på ca. 500 GB data indlæst i bidder, og tidsforskellen er mindre end et minut)

Du kan også henvise til følgende indlæg (fra @billinkc) for at få flere oplysninger om dette emne:

  • Skal SSIS-pakker og SQL-database være på samme server?

4. Konklusion

Baseret på Microsoft-artikler kan du sige, at SQL Server Destination øge ydelsen ved indsættelse af data (den bruger BULK insert) , men det er designet til et specifikt tilfælde, som er den lokale SQL-server. OLEDB Destination er mere generel og anbefales i de andre tilfælde og ved at bruge Fast Load dataadgangstilstand (som også bruger BULK insert)OLE DB destination det vil øge ydelsen af ​​dataindlæsning.

På den anden side, baseret på min erfaring og fra mange artikler skrevet af SSIS-eksperter, anbefales det slet ikke at bruge SQL Server Destination da det ikke er stabilt, og det ofte giver undtagelser, og ydeevnen kan betragtes som ubetydelig.

Yderligere oplysninger

For nylig udgav jeg en detaljeret artikel om dette emne. Du kan tjekke det på:

  • SSIS OLE DB-destination vs SQL Server-destination


  1. Find, prioriter og løs SQL Server-problemer på få minutter

  2. Multi-threading C#-applikation med SQL Server-databasekald

  3. Hvornår skal jeg bruge et sammensat indeks?

  4. Håndtering af samtidige opdateringer i dvale