Weisheiten - der Netz-Weise Blog

SQL-Server und mySql sind leider SQL-seitig nicht wirklich kompatibel. So gibt es zwar die Möglichkeit, eine Datenbank in mySQL als Script zu exportieren, aber leider kann man das Script auf dem SQL-Server nicht mehr für den Import benutzen. Der beste Weg für den Import führt daher über den SQL Server Migration Wizard. Der Migration Wizard steht für verschiedene Datenbanken zur Verfügung und hilft z.B. auch bei der Migration von Access-Datenbanken zu SQL-Server. Da das Tool recht komplex ist, möchte ich hier nur kurz zeigen, wie man eine einfach Migration durchführt, ohne auf die schmutzigen kleinen Details des Tools eingehen zu wollen. Ich verwende hierzu die derzeit aktuelle Version 6.0.1, 6.1 (für SQL-Server 2016) ist derzeit in der Beta-Phase.

Sie benötigen auf dem Rechner, auf dem Sie den SSMA einrichten wollen, zuerst einmal einen mySQL-ODBC-Treiber. Haben Sie die mySQL-Datenbank unter Windows auf dem gleichen Rechner installiert, dann müssen Sie nichts weiter machen, denn mySQL installiert den passenden ODBC-Treiber gleich mit. Ansonsten laden Sie den Treiber einfach bei mysql.com herunter. Nutzen Sie den 64-Bit Treiber, der SSMA wird nämlich auch in einer 64-Bit-Version installiert. Eine Konto für die Authentifizierung ist übrigens nicht notwendig, klicken Sie einfach auf den Link "No thanks, just start my download", wenn Sie nach Ihrem Login gefragt werden. Anschliessend installieren Sie den SSMA.

Wenn Sie den Migration Assistenten zum ersten Mal starten, müssen Sie ein Migrationsprojekt erstellen. Wählen Sie hierfür im Menü File "New Project" aus. Wichtig ist, dass Sie im folgenden Fenster das Migrationsziel auswählen. Standardmässig ist hier Azure angegeben. Leider können Sie das Ziel im Projekt selber dann nicht mehr ändern. Das kann ziemlich verwirrend sein!

Nun müssen Sie eine Verbindung zum Quell- und zum Zielsystem herstellen. Wählen Sie hierfür in der Toolbar zuerst "Connect to MySql". Wählen Sie im Verbindungsfenster den Provider aus - dies ist der ODBC-Treiber, den Sie installiert haben. Ist hier kein Treiber sichtbar, obwohl Sie einen Treiber installiert haben, dann prüfen Sie, ob Sie den Treiber und SSMA beide in der gleichen Version (32-Bit / 64-Bit) installiert bzw. gestartet haben. Außerdem benötigen Sie den Namen des Quellservers, den mySQL-Port (standardmässig 3306), sowie ein Konto mit Leserechten auf dem mySQL-System. 

Nun verbinden Sie sich mit dem SQL-Server. 

Mit dem SQL-Server Agent und der Datenbankrolle ""SQLAgentUserRole"" in der msdb-Datenbank kann man einem SQL-Login Zugriff auf einen Job geben. Voraussetzung ist, dass der Login dem JOB auch als Owner zugewiesen wird. Soll der User allerdings auch die Zeitpläne für geplante Aufträge verwalten, stellt man fest, dass dies nicht unbedingt klappt. Ursache dafür ist die schlecht Dokumentierte Tatsache, dass der Login auch Besitzer der Zeitpläne sein muß. Hat er diese nicht angelegt, kann er dementsprechend keine Änderungen durchführen. Stattdessen bekommt er eine Meldung "The specified schedule @schedule_id() does not exist". Den Besitzer des Zeitplans kann man nur über die Tabelle msdb.dbo.sysschedules in der Spalte owner_sid einsehen. Das folgende Script zeigt alle Job an, bei denen Besitzer für Zeitplan und Job nicht identisch sind:

SELECT (SELECT name FROM sys.server_principals WHERE [SID] = ss.owner_sid) AS ScheduleOwner,
 (SELECT name FROM sys.server_principals WHERE [SID] = sj.owner_sid) AS JobOwner,
 ss.name AS ScheduleName, 
 ss.owner_sid AS ScheduleOwnerSid, 
 sj.name AS JobName, 
 sj.owner_sid AS JobOwnerSID
FROM msdb.dbo.sysschedules AS ss
INNER JOIN msdb.dbo.sysjobschedules AS sjs
 ON sjs.schedule_id = ss.schedule_id
INNER JOIN msdb.dbo.sysjobs AS sj
 ON sjs.job_id = sj.job_id
WHERE ss.owner_sid <> sj.owner_sid

Und mit folgendem Script beheben Sie das Problem, indem Sie den Besitzer aller zeitpläne auf den gleichen Besitzer setzen wie den zugehörigen Job. Um nicht alle Jobs ungesehen zu überschreiben, geben Sie in der 1. Zeile einen Login-Namen ein:

DECLARE @JobOwner NVARCHAR(255) = 'Benutzer'
DECLARE @JobOwnerSid VARBINARY(85)
SELECT @JobOwnerSid = [sid] FROM master.sys.server_principals WHERE name = @JobOwner
UPDATE SS
SET ss.owner_sid = sj.owner_sid
FROM msdb.dbo.sysschedules AS ss
INNER JOIN msdb.dbo.sysjobschedules AS sjs
ON sjs.schedule_id = ss.schedule_id
INNER JOIN msdb.dbo.sysjobs AS sj
ON sjs.job_id = sj.job_id
WHERE (ss.owner_sid <> sj.owner_sid)
AND (sj.owner_sid = @JobOwnerSid)

SQL-Server lassen sich mit Hilfe der SMO-Erweiterungen (Server Management Objects) des SQL-Servers per Powershell wunderbar verwalten. Einen ganzen Satz von Beispielen finden Sie z.B. auf unserer Website unter Dokus. Für den Einsatz von SMO muß SMO allerdings erst einmal installiert werden. Dies geschieht entweder bei der SQL-Server Installation, indem Sie unter der Feature-Auswahl "Client Tools SDK" auswählen, oder indem Sie von der Microsoft-Website aus dem Feature-Pack Download "SharedManagementObjects.msi" und "SQLSysCLRTypes.msi" herunterladen und installieren. Oder Sie bauen sich alternativ ein Powershell-Modul, dass die notwendigen dll´s enthält und von selbst nachlädt. Alles, was Sie hierzu benötigen, sind die beiden Downloads aus dem Feature Pack, und eine Powershell Modul-Datei. Hierfür bietet sich passenderweise eine Manifest-Datei (.psd1) an. 

Aber fangen wir von vorne an. SMO ist ein Feature, dass Microsoft eingeführt hat, um die Verwaltung von SQL-Servern aus dem .NET-Framework zu erleichtern. Anstatt über SQL-Befehle kann man per SMO programmatisch über Objekte auf den SQL-Server zugreifen. Und da man mit Powershell auf alles zugreifen kann, was das .Net-Framework zur Verfügung stellt, kann man natürlich auch SMO nutzen. Tatsächlich tun Sie das sogar bereits, wenn Sie mit der SQL-Server Konsole für Powershell (SQLPS) arbeiten, denn das besondere an dieser Konsole ist vor allem, dass beim Starten von SQLPS automatisch die SMO-Assemblies geladen werden. 

Unschön an SMO ist, dass auf jedem Rechner, auf dem Sie Ihre SQL-Server Powershell-Scripte laufen lassen möchten, SMO installiert sein muß. Allerdings läßt sich dieses Problem mit einem kleinen Trick umgehen, denn tatsächlich muß die SMO-Funktionalität gar nicht installiert werden - Sie benötigen nur die dll-Dateien, die die SMO-Funktionalität zur Verfügung stellen. Und die erhalten Sie, wenn Sie die beiden oben angegebenen msi-Pakete auf einem beliebigen Rechner installieren. Die SMO-Assemblies finden Sie nach der Installation standardmässig im Ordner %ProgramFiles% unter "Microsoft SQL Server\<Version>\SDK\Assemblies", wobei Version der internen Versionsnummer des SQL-Servers entspricht. Bei einer Standardinstallation von SMO für SQL Server 2014 wäre das also Beispielsweise:

C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\

Kopieren Sie den Ordner Assemblies. Weiterhin benötigen Sie die "Microsoft.SqlServer.SqlClrProvider.dll", an die allerdings nicht so einfach heran zu kommen ist. Sie ist im Global Assembly Cache installiert und wird standardmässig aus der Explorer-Ansicht gefiltert. Sie müssen den Filter deaktivieren. Starten Sie hierfür den Registieriungseditor und setzen Sie die folgenden Wert: