ActiveX script-ek használata
A transzformáció típusától, és a használt programnyelvtől függően egy adatpumpa folyamat, ami ActiveX script segítségével alakít át adatokat, akár kétszer, vagy még talán négyszer is lassabban futhat le, mint az általános másolási művelet.
Oszlopok azonosítása esetén sokkal gyorsabb, ha számmal hivatkozunk oszlopnév helyett:
Használjuk a fenti formulát az alábbi helyett.
A sebességnövekedés nem számottevő abban az esetben, ha az oszlopok száma 20-nál kevesebb, de lényeges lehet, ha az átalakítás több oszlopot használ ennél. Kevés oszlop esetén a könnyebb olvashatóság kedvéért nyugodtan használhatjuk az oszlopneveket azonosításra sebességcsökkenés nélkül.
A VBScript futása körülbelül 10 százalékkal gyorsabb a Javascript-nél. Ez utóbbihoz képest pedig a Perlscript szintén kb. 10 százalékkal marad el.
Adatpumpa teljesítménynövelés
Az adatpumpa, egy adat átalakító komponense a Transform Data task-nak és a Data Driven Query task-nak. Amikor ezen task segítségével transzformálunk adatot, akkor az alábbi esetekben növelhetünk teljesítményt:
- Nagy mennyiségű adat esetén
- Nagyszámú transzformáció esetén
- Komplex script kód esetén
A teljesítmény növeléséhez ebben a szituációban használjunk many-to-many megfeleltetést, akárhányszor csak lehet. Kerüljük el a megfeleltetést egy különálló transzformációs függvénnyel minden oszlopra. A script motort nem hívja segítségül minden transzformáció. Eredményként gyorsabb teljesítményt kapunk.
A DTS Import/Export varázsló, a csomagokat many-to-many oszlopmegfeleltetéssel hozza létre. Ezzel szemben alapértelmezésben a DTS tervező egy az egyhez oszlopmegfeleltetést rendel a transzformációhoz azért, hogy az olvashatóságot növelje. Emiatt amikor DTS tervezőt használunk, gondoljuk át a megfeleltetések újraformálását many-to-many megfeleltetésekre, ahány transzformáció esetében csak lehetséges. A script-ben a sorrendiség használatával az optimalizáció sokkal jobban észrevehető, ahogy a tranzakciók száma növekszik. Általában, ha több mint 20 átalakítással dolgozunk, akkor észrevehető teljesítménybeli csökkenést tapasztalunk.
Data Driven Query Task és a Transform Data Task
Amikor az SQL szerver a beállított célállomás a Transform Data task-ban, akkor az átalakítások alapértelmezésben az IRowsetFastLoad felületet használják. Ha az SQL szerver nem az adatok célhelye, akkor a Transform Data task az IRowsetChange felületet használja (tipikusan INSERT utasítások küldésénél).
A Data Driven Query task transzformációi előkészített beillesztéseket végeznek az ICommand interfész segítségével. Ez gyorsabb lehet az IRowsetChange-nél, attól függően, hogy a cél OLE DB szolgáltató miként implementálja a felületet. Az ICommand és az IRowsetChange interfészek viszont nem mutatnak nagyobb teljesítményt az IRowsetFastLoad felületnél.
Kötegelt beillesztés, bcp
A Bulk Insert task, Transact-SQL BULK INSERT utasítást készít és futtat. Az SQL szerver OLE DB szolgáltatója által támogatott BULK INSERT lényegesen gyorsabb, mint a bcp vagy az adatpumpa használata text fájl importálásánál. Éppen ezért, ha transzformációt nem használunk, akkor maradjunk a Bulk Insert task használatánál és gyorsabb működést kapunk.
A BULK INSERT használata fájl importálására korlátozott.
Amikor adatot importálunk, a bcp és DTS másolási műveletek körülbelül ugyanolyan sebességűek, viszont amikor adatexportot végzünk, akkor a bcp folyamat gyorsasága a háromszorostól a hatszoros sebességig nőhet. A természetes bcp, ami csak SQL adatokat használ, gyorsabb a DTS adatpumpánál. BULK INSERT és a natív bcp hasonló sebességű.
Kapcsolatok használata
Az ExecuteOnMainThread tulajdonságot csak szükséges esetben használjuk (például olyan driver-ek esetében, amelyek nem szálbiztosak (thread-safe)). Mindig kerüljük el az ExecuteOnMainThread használatát ActiveX script-ekben, hogy megvalósítsuk az egybeesést, kivéve ha a csomag, vagy annak lépése tartalmaz:
- Sorrendiség feltételeket, amelyek befolyásolhatják a DTS csomag műveleti sorrendjét.
- Scripteket, ami Visual Basic-ben írt COM objektumokat hív meg.
- Olyan task-okat, amelyek nem szabad szálúak.
A biztonság érdekében csak egy task használhat egy kapcsolatot egyszerre. Ahhoz, hogy párhuzamos futást tudjunk megvalósítani, használunk minden task-hoz külön kapcsolatot. Például egy adatforrás két célhelyhez kapcsolódik, és a folyamat rendszeresen lefut, akkor használjunk két ugyanolyan beállítású adatforrást, és egy forrás csak egy célhelyhez kapcsolódjon.
Ha két task összekapcsolódik egy csomag tranzakcióban és mindegyik ugyanazt az SQL szervert használja párhuzamosan, akkor a csomag futása hibával leáll.
Alapértelmezésben a maximális egyidejű lépések száma négy. Ez a MaxConcurrentSteps tulajdonsággal módosítható.
Egyéb SQL szerver megoldások használata
Egy Transact-SQL lekérdezés a leggyorsabb megoldás adatmozgatásra táblák között tranzakciók, jóváhagyások nélkül. Több adatforrás esetén gondoljuk át az elosztott lekérdezések használatát, mint pl. egy SELECT INTO utasítást.
Több csomagot használó környezetben, minden DTS csomag külön folyamatként kell fusson a dtsrun eszközt használva, vagy batch műveletként az SQL szerver Agent segítségével. Ez a DTS-t kliens folyamattá teszi. Ha nagyszámú csomagot kell szerver folyamatként futtatni (pl. 1000, vagy több darabot), akkor fontoljuk meg a replikáció használatát, ha az első másolja csak azokat az SQL szerver adatokat, amelyek változtak.
Lekérdezések teljesítményének javítása meta adatok tárházában tartott nagyméretű DTS csomagoknál
Ha a meta adattárházból kérdezünk le nagyméretű DTS csomagot, akkor jobb eredményt érhetünk el, ha növeljük a lekérdezés timeout értékét. Ez biztosítja azt, hogy a lekérdezés megtegye az oda-vissza utat a tárház adatbázishoz, ha a DTS csomag nagyméretű. Alapértelmezésben a lekérdezés timeout ideje 10 másodperc. Az alábbi registry kulcs létrehozásával tudjuk a timeout értéket beállítani:
[HKEY_LOCALMACHINE\SOFTWARE\Microsoft\Repository\Engine\ODBCQueryTimeout]
Erre a kulcsra állítsunk be az alapértelmezettnél nagyobb értéket (például 60 másodpercet, vagy annál többet). A mértékegység másodperc.