Keine Frage – SQL Server 2008 spielt mit in der obersten Liga der Datenbanksysteme. Im Gegensatz zu anderen Anbietern integriert Microsoft Business Intelligence Komponenten mit in das Produktrelease des Datenbanksystems. Diese Marktstrategie trug dazu bei, dass MS Produkte mit zu den Marktführern im BI Bereich gehören.

Viele Firmen entwickelten ihre BI-Anwendungen mit SQL Server 2005 und möchten nun auf die seit 2010 verfügbare Version 2008 R2 migrieren. In dieser dreiteiligen Artikelserie möchte ich über meine Erfahrungen mit verschiedenen Lösungsansätzen der Migration von BI-Anwendungen von SQL Server 2005 nach 2008 R2 berichten. Eine sehr detaillierte Beschreibung liefert Microsoft selbst im Technical Upgrade Guide. Von praktischer Bedeutung ist insbesondere die dort beschriebene Side-By-Side Migration auf neue Server.

Die Überführung existierender SQL Server 2005 Datenbanken nach 2008 gelingt erstaunlich problemlos. Man kann sowohl ein mit dem SQL Management Studio 2005 (SSMS) erstelltes Backup mit SSMS 2008 über Restore als Datenbank verfügbar machen als auch aus einem Backup aus SSMS 2008. Auch Datenbank Setup-Skripte der Version 2005 laufen problemlos auf SQL Server 2008.

Bei Analysis Services gibt es ebenfalls zwei Migrationsstrategien. Zum einen kann die AS-Datenbank über Deployment Skripte im XMLA Format in der Zielumgebung neu erzeugt werden. Dann muss ein Reprocessing erfolgen, um die AS DB mit Daten aus der relationalen DB zu befüllen. Der zweite Ansatz überträgt die AS DB mit Backup/Restore auf die Zielumgebung. Beide Strategien verlaufen normalerweise problemlos. Doch Achtung: Microsoft hat die Verbindungsprovider umgestellt. Für SQL Verbindungen ist dieser nun SQLNCLI10, für OLAP-Verbindungen MSOLAP.4. Dies ist in den ConnectionStrings in den Data Sources der AS DB bzw. im Deployment Skript zu überprüfen und gegebenenfalls zu editieren.

Die Migrationsstrategie mit Backup/Restore der AS DB bringt Zeitvorteile gegenüber dem Ansatz des neu Erstellens/Reprocessing. Beim Backup wird die AS DB nämlich mindestens 50% komprimiert. Der Vorteil kommt insbesondere in produktiven Umgebungen zum Tragen, wenn ein zuverlässiges Filecopy-Tool verwendet wird um die AS DB auf den neuen Server zu kopieren.

Auf der anderen Seite kann mit einem neuen Deployment und Reprocessing auch ein neues Release verknüpft werden. Läßt sich der mit dem Reprocessing verbundene Zeitbedarf produktiv planen, ist diese Migrationsstrategie flexibler.

Bei einem Migrationsprojekt sind diese und andere Aspekte vorher zu diskutieren und auch Zeitmessungen bei Testmigrationen durchzuführen. Die SDX AG kann Sie hierzu kompetent beraten und die optimale Strategie für Ihre Umgebung ausarbeiten.