Säg adjö till DTS

Många företag har en gammal last av kod som rullar och som man inte vet riktigt hur man ska hantera. Andra har livscykelhantering av systemet och kanske i alla fall har en plan för om, hur, när och till vilket pris man kommer vidare till nästa supportade kodplattform. I och med Denali släpper Microsoft nu stödet för det 11-åriga ETL verktyget DTS (Data Transformation Services). Den kom redan i SQL Server 7.0, men de flesta kanske har den i 2000 versionen, vilket fortfarande förekommer här och där. Om du stuckit huvudet i DTS-sanden tills nu, så är SSIS en helt omskriven produkt, betydligt snabbare, mer kraftfull i vad den kan göra, och därmed också mer komplicerad. Migreringen är heller inte enkel. Inte bara för mängden av DTS paket som skrivits utan också för att viss funktionalitet är borttagen (ersatt med andra motsvarande verktyg i de flesta fall). DTS syns t ex inte längre i menyerna (där den tidigare låg, under “legacy”) i administrationsverktyget som kommer med Denali CTP3, inte heller om man kopplar sig till en äldre version av SQL Server instans. Och “Execute DTS Package Task” går heller inte att använda.

STÖD UPPHÖR FÖR DTS KOMPONENTEREn lista på vad mer, som är bortplockat i Denali:

– DTS runtime
– DTS API
– Package Migration Wizard för att migrera DTS packet till nästa version av Integration Services-support för DTS paket underhåll i SQL Server Management Studio
– Execute DTS 2000 Package task
– Upgrade Advisor scan av DTS paket

FÖRBÄTTRINGAR I SSIS JÄMFÖRT MED DTSHär är en lista på vad SSIS har, som inte DTS hade:

– Separering av “control flow” och “data flow”
– Flera käll- och destinationstyper har optimerats
– Många nya transformeringar
– Större antal möjliga data källor /-destinationer
– Säkerhet
– Ett verktyg för ETL, analys och rapport projekt (BIDS)
– Integrering med källkodhanteringsverktyg
– Checkpoint och “in place” återstarter av paket
– Dynamiska “runtime” konfigurationer
– Betydligt bättre möjligheter att logga vad paketet gör
– Mycket snabbare på transformeringar eftersom det i SSIS sker direkt i minnet

MIGRERINGSSTRATEGI De som inte migrerat bort DTS kommer alltså tvingas göra det när de går över till SQL Server Denali versionen. Så – vad gör man då om man inte kommit över till SSIS ännu – och finns det t ex verktyg för att migrera? Börja med att bestämma en migreringsstrategi;

– Ska man skriva om allt från början för att fullt ut för att utnyttja den nya förbättrade SSIS paradigmen?
– Ska man istället migrera vad som migreras kan mha den wizard man får med sig?
– Ska man använda 3:e partsprodukter?

Att automatmigrera är kanske mest kostnadseffektivt för just migreringsprojektet, men inte alltid lika optimalt i längden. Man skulle kunna tänka sig att bygga bort funktionalitet redan i DTS, som inte finns i SSIS, innan man migrerar, där så är möjligt, men då blir det en iterativ process att köra upgrade advisor igen, och så kanske man sitter och lägger tid i onödan på att bygga i gammal teknik. En gyllene medelväg att automatmigrera allt och bygga om det som inte gick igenom samt kritiskt granska SSIS paketen och se om det är några av de automatmigrerade som behöver ses över. ANALYS Först behöver man analysera situationen. Hur många paket gäller det. Hur avancerade är de. Vilka beroenden finns.  Börja t ex med att köra “Microsoft® SQL Server® 2008 R2 Upgrade Advisor” för att veta hur landet ligger. Det här är saker man behöver ta med i sin analys:

– Paketens komplexitet
– De alerts man fått fram från “Package Upgrade Advisor“
– Förekomst av Föräldra/barn paket
– Externa paket beroenden

MILJÖ

Du behöver åtminstone ha en separat utvecklingsmiljö, som klarar alla versioner av produkterna du använder. Developer edition innehåller allt som de andra editionerna innehåller så den är bäst för uppgiften, om du inte redan har enterprise versionen (vilket kanske inte är så vanligt i utvecklingsmiljön). Här kan det vara fråga om ett flertal versioner som levt kvar. Säg att du idag finns på en 2008 R2 plattform, men har kvar paket som skrevs i vesion 7.0, 2000, och som kanske migrerats till 2005 fast körs i 2000 kompabilitetsläge. Även viss 2005 funktionalitet körs i 2008 som 2005-kompabilitetsläge, t ex viss scriptad kod. Då behöver du kanske en installation av SQL Server 2000 DTS Designer, 2008 R2 och Denali, vilket för små företag kan behöva samsas på samma fysiska burk. Test, acceptanstest och produktion blir renare för där räcker det med Denali-migrerade SSIS paket, dvs där kan man köra Denali versionen i alla instanser. MIGRERA Om vi utgår från att man vill klara sig med de licenser man redan köpt och vill få hjälp på traven och slippa skriva om alltihopa på nytt i SSIS, så får man försöka med Microsofts verktyg för migreringen. Microsoft tillhandahåller “Packet migration wizard” i 2005 och 2008 versionerna (inklusive 2008 R2) i Standard, Enterprise,och Developer editionerna och med varierande framgång kan man få över lejonparten av sina DTS paket. Den klarar i och för sig endast ca 40% av alla möjliga paketkonfigurationer så det beror på hur avancerade paket man har (“it depends”). Det finns tre sätt att starta wizarden:

– Från “SQL Server Management Studio”. Koppla en instans av “SQL Server Database Engine”, högerklicka på “Data Transformation Services” i “Object Explorer” under “ManagementLegacy” och välj “Migration Wizard”.
– Från “Business Intelligence Development Studio”. Skapa eller öppna ett “Integration Services” projekt, högerklicka på SSIS Packet noden i “Solution Explorer” och välj “Migrate DTS 2000 Package”.
– Från commandoprompten. Starta “DTSMigrationWizard.exe” från “C:Program FilesMicrosoft SQL Server100DTSBinn” mappen.

Det troligast scenariot är att du har eller kommer ha en 2005, 2008 eller 2008 R2 version att börja jobba med migreringen på, innan Denali släpps. Jag rekommenderar att åtminstone använda 2008 R2 för migreringsarbetet så man kommer så nära i version som möjligt när man ändå gör jobbet, tills Denali släpps i produktion. Testa också de migrerade, nya SSIS paketen, i Denali CTP3, så du inte får några överraskningar där. Vilka DTS komponenter du kan komma att få problem med kan du se om du kör en “DTS Package scan” med hjälp av “SQL Server Upgrade Avisor” (SSUA 2008). För att göra en “DTS Package scan” kan man inte ha paketen i MSDB databasen, istället behöver du ha filerna i filsystemet, i “Structured Storage File Format” och för att spara om paketen till det formatet behöver du “SQL Server 2000 DTS Designer Components” som finns t ex i “SQL Server 2000 Enterprise Manager”: Öppna paketen och välj spara som, för varje paket. Du kan välja att lägga ihop alla paket till samma fil här, vilket gör det något lättare att hantera. Tänk på att DTS paket inte kan öppnas i “BI Development Studio” (BIDS) så du behöver tillgång till gamla verktygen här! Beroende på vad det ger för resultat får man därefter planera in det återstående jobbet med de som inte migrerades väl, som till sist måste göras handgripligen. När man väl fått fram en .dtsx (SSIS) version av paketen behöver man testa och se att de fortfarande ger rätt resultat och deploya till sin testmiljö, för vidare befordran till produktion när de är godkända.

MER HJÄLP

Glöm inte att ta bort befintliga DTS paket från produktion. Spara dem gärna i filformat, och checka in i ditt källkodshanteringsverktyg eller ta backup på annat sätt. Kan vara bra att ha för referens ett tag framåt. Och glöm heller inte att avaktivera SQL Agent job som kör dem, om du inte återanvänder jobben (byt ut jobbstegen mot motsvarande SSIS jobbsteg) förstås. DTSXChange (tredjepartsprodukt) från Pragmatic Works hävdar att de kan underlätta migreringsjobbet, utöver det Microsofts medskickade egna verktyg klarar.

Om inte annat så visar de en lista vad man bör hålla utkik efter:

– Conversion of Dynamic Properties Task
– ODBC Support
– UDL File Support
– Password protected Access Database
– Flat File that doesn’t map all columns
– Data conversion between source and destination
– SQL Native Client support
– Full package validation after migration
– Detailed logs of conversion
– Enterprise rules for migration to get the benefit of SSIS
– SSIS logging turned on
– Checkpoint file support
– Children package migration
– Profiling capability

Låter bra om det verktyget klarar allt detta, utöver det “Package Migration Wizard” klarar, men det är oprövat för min del – har ni tips på, och erfarenheter av, andra migreringsverktyg som ni använt, så kommentera gärna inlägget, för allas intresse.  

SUMMERING:

– Sätt migreringsstrategin
– Analysera hur stort problemet är att inte kunna automatmigrera.Planering av migreringsprojektet är av största vikt för att veta hur mycket tid och vilka resurser som krävs för just ditt projekt
– Bygg eller använd en befintlig utvecklingsmiljö som stöttar alla versioner som ska migreras, samt mål versionen.
– Testa ordentligt innan produktionssättning.
– Städa bort DTS på ett ordnat sätt vid produktionssättning.

Kontakta oss konsulter på SQL Service om du vill ha hjälp med delar av eller hela migreringen.

/Jonas Bergström

PS. Annat SSIS relaterat, som är borttaget i Denali DS.