Migratie naar Windows Azure SQL Database (Deel 1)

Om de data naar Windows Azure SQL Database te kunnen migreren, geeft Microsoft een aantal tips. Allereerst zorg je dat het databaseschema in Windows Azure SQL Database terecht komt. Voor BesteProduct zijn dat ongeveer 100 tabellen, een paar stored procedures, triggers en user defined functions. Daarnaast is er nog een assembly, die in de procesruimte van SqlServer wordt gehost en een aantal logins op basis van Windows Authenticatie.

Die gehoste assembly is al meteen een heet hangijzer. Windows Azure SQL Database ondersteunt geen gehoste assemblies. Die zal er dus uit moeten. Deze assembly is destijds gemaakt om stringmanipulaties uit te kunnen voeren die in T-SQL nogal lastig zijn. Gelukkig niet onmogelijk en na enig gepeuter zijn die routines nu overbodig.

Windows Authenticatie zal er ook uit moeten. Eigenlijk zijn er alleen maar applicaties die de database aanspreken, te weten de invoerapplicatie, een importmodule en de dataservices. De dataservices hebben een eigen login die alleen mag lezen. De invoerapplicatie heeft ook een eigen login. De gebruikers van de invoerapplicatie worden afgehandeld via Access Control Service (ACS), die de data van een aantal Identity Providers, zoals Live ID, Google, Yahoo en Facebook, netjes naar claims transformeert. Zij zijn dus niet geregistreerd in de database als logins, scheelt alweer een slok op een borrel. De import heeft dezelfde rechten nodig als de invoerapplicatie. Die kunnen dus delen. Kort samengevat, de logins kunnen er dus uit en dienen later in Windows Azure SQL Database opnieuw te worden aangemaakt.

Een andere zaak om rekening mee te houden is de Clustered Index. Windows Azure SQL Database eist dat iedere tabel een clustered index heeft. BesteProduct heeft een paar tabellen die dat niet hebben, maar dat euvel is zo verholpen.

Tijd om te beginnen met het exporteren van het database schema. In Sql Server Management Studio (SSMS) selecteer je de database en via het contextmenu selecteer je "Tasks->Generate Scripts...". Dit levert het scherm in afbeelding 1 op. Op zich kun je weinig met dat scherm, dus snel naar het volgende scherm (afbeelding 2). Hier wordt het interessant. Default wil de tool de hele database scripten. Deze optie is niet handig om te kiezen. Het geeft teveel instructies en voor je het weet ben je uren aan het knoeien in dat script om het compatible met Windows Azure SQL Database te krijgen. Kies dus voor "specific database objects" en daarna de zaken die ook echt nodig zijn.

Afbeelding 1. Generate and Publish Scripts

Afbeelding 2. Wat te scripten?

Een "Next" later kom je op het scherm van afbeelding 3, waarin je kunt aangeven waarnaar en hoe het script gegenereerd moet worden. De belangrijkste optie hierop is de "Advanced" knop die je naar het scherm in afbeelding 4 leidt.

Afbeelding 3: Bestandsinformatie

Afbeelding 4: Belangrijk scherm

Alweer een boel opties die hier uitvoerig besproken worden. Allereerst de User Defined Data Types (UDDT). Windows Azure SQL Database ondersteunt geen UDDT's. Die moeten worden geconverteerd naar Windows Azure SQL Database portable types. Zorg er ook meteen voor dat het script compatible is met Windows Azure SQL Database.  Dit doe je door bij de optie "Script for database engine type" "SQL Azure Database" te selecteren. 
Let verder op de opties Triggers en Indexes. Ze kunnen in de weg zitten wanneer je data gaat importeren, dus wellicht in een apart script opslaan.
Vervolgens krijg je de samenvatting uit afbeelding 5 met daaropvolgend het resultaat van de scriptgeneratie (afbeelding 6). Hopelijk zijn alle bolletjes groen.

Afbeelding 5: De samenvatting

Afbeelding 6: alles goed.

Het script met het databaseschema is nu gereed. Hoogste tijd om hem in Windows Azure SQL Database te importeren. Daarvoor gaan we eerst naar de Azure portal. Van daaruit gaan we naar het "Dashboard" van de database en klikken we op de hyperlink bij "Manage URL" zodat we op de landingspagina van afbeelding 7 komen.

Afbeelding 7: Landingspagina SQL Azure

Vanaf de landingspagina klik je de "Open" knop en navigeer je naar het exportscript en als dat geladen is klik je op de "Run" knop. Het script wordt nu uitgevoerd. Er kunnen wat berichten door het beeld rollen, maar zolang die groen zijn hoeft er niks aan de hand te zijn. In mijn geval ontbraken een paar Stored Procedures die gewoon later in het script stonden. Eenmaal geladen kun je in de "Design" mode het resultaat bewonderen (afbeelding 8).

Afbeelding 8: Het schema

Kijk ook eens naar het "dependencies" venster. Je komt er door achter een tabel op "dependencies" te klikken. Je krijgt dan de grafische representatie uit afbeelding 9. Door te klikken op een dependency krijg je dan weer de first-level dependencies van dát item te zien.

Afbeelding 9. First Level dependencies

Erg mooi allemaal, maar het belangrijkste is dat de import van het databaseschema geslaagd is. Natuurlijk moet je checken of alles meegekomen is, maar ik vertrouw erop dat de exporttool van SSMS zijn werk goed heeft gedaan.
De volgende stap in het migratietraject is het importeren van de data.