Microsoft SQL Server · Azure

SQL Server in Azure:
die passende Plattform, ein geprüfter Umstieg

Ihre Anwendung soll in Azure zuverlässig arbeiten, auch bei hoher Last, beim Monatsabschluss und nach einer Wartung. Dafür müssen Plattform, Datenbank und Anwendung zusammenpassen.

PSG unterstützt Sie bei der Entscheidung, der Planung und der Umsetzung einer SQL-Server-Migration nach Azure. Wir betrachten Ihre vorhandene Anwendung, ihre Abhängigkeiten und die tatsächliche Last. Daraus entwickeln wir mit Ihrem Team ein passendes Zielbild und prüfen nach dem Wechsel, ob es die vereinbarten Anforderungen erfüllt.

Sie betreiben SQL Server bereits in Azure? Wir untersuchen auch bestehende Umgebungen, wenn Antwortzeiten, Stabilität oder Ressourcenbedarf Fragen aufwerfen.

umstieg · abhängigkeitenStrukturmodell
Ausgangslagen

Wo stehen Sie gerade?

Ergebnisse

Was Sie von der Zusammenarbeit haben

Der Auftrag richtet sich nach Ihrer Ausgangslage. Je nach Fragestellung erarbeiten wir mit Ihnen die folgenden Ergebnisse.

illustrativVier mögliche Arbeitsergebnisse
Der konkrete Auftrag bestimmt, welche Ergebnisse wir gemeinsam erarbeiten. Musterfelder: Annahmen und offene Prüfungen sind Beispiele, keine Ergebnisse aus einem Kundenprojekt.
Ergebnis 01

Eine nachvollziehbare Plattformentscheidung

SQL Server auf einer Azure-VM, Azure SQL Managed Instance und Azure SQL Database unterscheiden sich bei Funktionen, Eingriffsmöglichkeiten und Betriebsaufgaben. Wir stellen die geeigneten Optionen Ihren Anforderungen gegenüber und benennen, was bereits geklärt ist und was noch getestet werden muss.

Sie erhalten eine begründete Auswahl mit den Konsequenzen für Anwendung, Betrieb und weitere Arbeit. Die drei Plattformen im Vergleich.

StrukturmodellDrei Ziele, unterschiedlich viel eigene Gestaltung
VMSQL Server auf Azure-VM
  1. Anwendung
  2. Datenbanken und Abfragen
  3. SQL-Instanz
  4. Enginebetrieb
  5. Betriebssystem
  6. Infrastruktur
MIAzure SQL Managed Instance
  1. Anwendung
  2. Datenbanken und Abfragen
  3. SQL-Instanz
  4. Enginebetrieb
  5. Betriebssystem
  6. Infrastruktur
DBAzure SQL Database
  1. Anwendung
  2. Datenbanken und Abfragen
  3. SQL-Instanz
  4. Enginebetrieb
  5. Betriebssystem
  6. Infrastruktur

Ihr Team gestaltetMicrosoft betreibt die Plattform

Welche Schichten Ihr Team selbst gestaltet, unterscheidet die drei Ziele. Was das für Funktionen, Betrieb und Migration bedeutet: Plattformvergleich lesen →
Ergebnis 02

Klarheit über Abhängigkeiten und Anpassungen

Welche Anwendungen greifen auf welche Datenbanken zu? Welche Jobs, Anmeldungen, Dateizugriffe und Verbindungen zu anderen Systemen sind beteiligt? Was unterstützt der Softwarehersteller für das gewählte Ziel?

Aus der Bestandsaufnahme entsteht eine Arbeitsgrundlage: übernehmbare Teile, notwendige Änderungen, Verantwortliche und offene Prüfungen. So werden Annahmen vor dem produktiven Wechsel überprüfbar.

StrukturmodellEine Anwendung zieht mit ihren Abhängigkeiten um
Heute · Ihre Umgebung Geplantes Azure-Ziel
AnwendungBenutzer und Dienste
Aufrufe
Jobszeitgesteuerte Abläufe
Verarbeitung
IdentitätenAnmeldungen und Rechte
Berechtigungen
DateienImporte, Exporte, Ablagen
Verarbeitung
Schnittstellenandere Systeme
Aufrufe
DatenbankSQL Server, heute
Umstieg
Anwendungprüfenübernehmen oder anpassen
Jobsprüfenübernehmen oder anpassen
Identitätenprüfenübernehmen oder anpassen
Dateienprüfenübernehmen oder anpassen
Schnittstellenprüfenübernehmen oder anpassen

Eine Datenbank ist mit Anwendung, Jobs, Identitäten, Dateien und Schnittstellen verbunden. Für das neue Ziel werden diese Abhängigkeiten einzeln geprüft. Ob ein Teil übernehmen oder anpassen heißt, zeigt erst die Prüfung im Projekt; das Modell bewertet keine Komponente vorab.

Zum Umstieg gehören Daten, Anwendungen und die Abläufe dazwischen.
Ergebnis 03

Eine Ausstattung, die zur Last passt

CPU, Speicher, Datenzugriffe und Schreiblast betrachten wir im zeitlichen Zusammenhang. Tagesgeschäft, Lastspitzen und periodische Verarbeitung gehören in dieselbe Bewertung. Die Zahl der bisherigen Prozessorkerne allein reicht für die Dimensionierung des Ziels nicht aus.

Die Empfehlung nennt ihre Messgrundlage und Annahmen. Dazu gehören Leistungsreserven, Wachstum und die Frage, welche Anforderungen sich durch Änderungen an Abfragen oder Anwendung beeinflussen lassen.

StrukturmodellAusstattung aus dem Lastbild ableiten
Reserve
Import
Tagesgeschäft
Abschluss
Durchschnitt

schematisch · ohne Messwerte

  • CPURechenzeit der Vorgänge
  • SpeicherArbeitsspeicher für Daten
  • DatenzugriffeLesen und Schreiben auf dem Datenspeicher
  • LogSchreiblast im Transaktionsprotokoll

Tagesgeschäft, Import und Abschluss bilden unterschiedliche Lastsituationen, für die CPU, Speicher, Datenzugriffe und Log zu bewerten sind. Der Durchschnitt allein beschreibt die Anforderungen nicht vollständig.

Die Dimensionierung muss auch die relevanten Spitzen und Verarbeitungsfenster tragen. Schematisch: Höhen und Breiten veranschaulichen nur, es sind keine gemessenen Werte.
Ergebnis 04

Einen abgestimmten Ablauf mit Abnahme

Wir planen mit Ihrem Team, wie sich der Umstieg prüfen lässt: durch eine Testmigration, definierte Geschäftsvorgänge, Lasttests im vereinbarten Umfang und konkrete Kriterien für die Freigabe. Für die Umschaltung werden Zuständigkeiten, Zeitfenster und der Umgang mit unerwarteten Ergebnissen festgelegt.

Zum Rückweg gehört eine wichtige Unterscheidung: Sobald am Ziel neue produktive Daten geschrieben wurden, muss eine Rückkehr auch diese Änderungen berücksichtigen. Diese Frage klären wir vor dem Wechsel.

illustrativAbnahme am Geschäftsvorgang
Geschäftsvorgang „Auftrag speichern“Abnahmeblatt · offenes Muster
PrüfpunktAnforderungPrüfungErgebnis
Fachlich korrektLiefert der Vorgang dieselben fachlichen Ergebnisse?Ziel vereinbarenNachweis zuordnenoffen
AntwortzeitWie schnell muss der Vorgang sein, auch unter Last?Ziel vereinbarenNachweis zuordnenoffen
Erfolgreiche AbschlüsseWerden die Vorgänge vollständig abgeschlossen?Ziel vereinbarenNachweis zuordnenoffen
FehlerWelche Fehler treten auf, und wie werden sie behandelt?Ziel vereinbarenNachweis zuordnenoffen
BetriebsnachweisLaufen Sicherung, Jobs und Überwachung wie vereinbart?Ziel vereinbarenNachweis zuordnenoffen
Die Abnahme prüft, ob die neue Umgebung die vereinbarten Aufgaben erfüllt. Offenes Muster: Ziele und Nachweise legen wir für Ihre Geschäftsvorgänge fest.

Umschaltung und Rückweg im Projektablauf: Vom Zielbild zur Abnahme ↓

Vorgehen

So gehen wir vor

StrukturmodellVom Zielbild zur Abnahme
  1. 1AnforderungenErgebnisprüfbare Kriterien für Technik und fachliche Abläufe
  2. 2BestandErgebnisDatenbanken, Abhängigkeiten und Last; fehlende Messdaten benannt
  3. 3ZielprüfungErgebnisgeprüfte Zielvarianten und ein passender Migrationsweg
  4. 4Test und UmschaltungErgebniserprobte Testmigration, Umschaltung nach abgestimmtem Plan
  5. 5AbnahmeErgebnisVergleich mit den vereinbarten Kriterien, Übergabe in den Betrieb

Bei Schritt 4: Umschaltung und Rückweg

Rückweg vor Zielschreibzugriffen

Am Ziel sind noch keine neuen produktiven Daten entstanden. Der Rückweg folgt dem vorher vereinbarten Verfahren; Voraussetzung ist ein unverändert erhaltener Ausgangsstand.

Erste produktive Schreibvorgänge am Ziel
Rückweg mit neuen Zieldaten

Eine Rückkehr muss auch die am Ziel geschriebenen Änderungen berücksichtigen. Wie, klären wir vor dem Wechsel.

Freigabe und Rückweg werden vor der produktiven Umschaltung vereinbart. Fünf Projektphasen mit Prüfergebnissen. Nach neuen Schreibzugriffen am Ziel muss der Rückweg auch diese Daten berücksichtigen.
  1. 01

    Anforderungen und Erfolgskriterien klären

    Welche Vorgänge müssen wie schnell sein? Welche Ausfallzeit und welcher Datenverlust sind tragbar? Was kann Ihr Team dauerhaft betreiben? Und was soll durch den Umstieg wirtschaftlich oder organisatorisch besser werden?

    Wir vereinbaren Kriterien, die sich am Ende prüfen lassen. Dazu gehören neben der Technik auch die fachlichen Abläufe Ihrer Anwender.

  2. 02

    Bestehende Umgebung und Workload verstehen

    Wir betrachten Datenbanken, Instanzfunktionen, Anwendungen und Betriebsabhängigkeiten. Vorhandene Messdaten helfen, typische Last und kritische Zeitfenster zu erkennen. Wo wichtige Daten fehlen, legen wir die nötige Erhebung gemeinsam fest.

  3. 03

    Zielbild und Migrationsweg prüfen

    Aus Anforderungen und Bestand leiten wir geeignete Zielvarianten ab. Wir prüfen Funktionsbedarf, Netzwerkwege, Verfügbarkeit und Dimensionierung. Der Migrationsweg richtet sich nach Quelle, Ziel, Datenumfang und zulässiger Unterbrechung.

  4. 04

    Erproben, umsetzen und umschalten

    Eine Testmigration zeigt, ob Daten und Abhängigkeiten wie vorgesehen ankommen. Gemeinsam mit Betrieb, Entwicklung und gegebenenfalls dem Softwarehersteller prüfen wir die relevanten Abläufe. Danach erfolgt die Umsetzung nach dem abgestimmten Plan.

  5. 05

    Wirkung prüfen und in den Betrieb übergeben

    Nach dem Wechsel vergleichen wir die vereinbarten Kriterien: Antwortzeiten, abgeschlossene Vorgänge, Fehler, Ressourcenbedarf und betriebliche Abläufe. Dokumentation und Wissenstransfer helfen Ihrem Team, die neue Umgebung einzuordnen und weiterzubetreiben.

Wirtschaftlichkeit

Performance und Wirtschaftlichkeit zusammen betrachten

In Azure lassen sich Ressourcen anders bereitstellen als im eigenen Rechenzentrum. Wie viel Ausstattung Ihre Anwendung braucht, hängt weiterhin von der Arbeit ab, die sie ausführt.

Deshalb betrachten wir Plattform und Workload gemeinsam. Eine aufwendige Abfrage, viele kleine Datenbankaufrufe oder lange Transaktionen können den Ressourcenbedarf und die Antwortzeiten bestimmen. Eine größere Konfiguration kann helfen; ebenso kann eine gezielte Änderung an Datenzugriff oder Anwendung der passende Schritt sein.

Wir verkaufen keine SQL-Server-Lizenzen und müssen keinen Azure-Umsatz erreichen, um einen Partnerstatus zu halten. Bei Plattformwahl, Edition und Core-Ausstattung beraten wir deshalb unabhängig, ohne eigenes Lizenz- oder Cloudverkaufsinteresse. Die Kostenbetrachtung umfasst die Annahmen des konkreten Zielbilds: benötigte Leistung, Speicher, Verfügbarkeit, Datentransfer und Betrieb.

Eine Einsparung ist dann belastbar, wenn eine Änderung auch die tatsächlich bezahlte Nutzung oder Konfiguration verbessert. Weniger CPU-Arbeit allein ist noch keine kleinere Rechnung.

StrukturmodellWirkung und Rechnung getrennt prüfen
  1. 1 · AnnahmeAngenommen: Abfrage oder Datenzugriff verbessertweniger CPU-Arbeit, kürzere Antwortzeiten
  2. 2 · Bezahlte Nutzung oder KonfigurationFall Ableibt unverändertFall Bwird kleiner gewählt oder geringer genutzt
  3. 3 · ErgebnisFall ATechnische WirkungSchnellere Vorgänge oder mehr Reserve, die Rechnung bleibt gleich.Fall BMögliche EinsparungDie Änderung verbessert auch die bezahlte Nutzung oder Konfiguration; die Höhe zeigt erst die Abrechnung.
Weniger Aufwand und eine niedrigere Rechnung werden getrennt geprüft.
Zusammenarbeit

Mit Ihrem Team und Ihren Partnern

Sie kennen Ihre Anwendung und verantworten ihren Einsatz. Ihr Betriebsteam, die Entwicklung, Ihr Hostingpartner oder der Softwarehersteller bringen weitere Teile des Gesamtbilds mit. Wir ergänzen diese Zusammenarbeit um die benötigte SQL-Server-Tiefe.

Die Unterstützung kann bei einer Zweitmeinung beginnen, einen Migrationsabschnitt begleiten oder eine konkrete Performancefrage bearbeiten. Den Umfang und die Zuständigkeiten vereinbaren wir passend zum Vorhaben. Für die laufende Begleitung greifen wir auf unsere bestehenden Angebote für SQL-Server-Betreuung und Performance Engineering zurück, soweit sie zu Ihrer Umgebung und Aufgabe passen.

StrukturmodellBeteiligte und ihre Aufgaben
SieAnwendung und Einsatz Betriebs­teamlaufender Betrieb Ent­wicklungCode und Datenzugriff
Ihr Azure-VorhabenUmfang und Zuständigkeiten: im Projekt festzulegen
Hosting­partnerPlattform und Netz Software­herstellerFreigaben PSGSQL-Server-Tiefe

Einstieg zum Beispiel über Zweitmeinung Migrationsabschnitt Performancefrage

Zuständigkeiten werden für Ihr Vorhaben festgelegt.
Kurz beantwortet

Häufige Fragen

Müssen wir für eine Migration die Anwendung umbauen?

Das hängt von den verwendeten Funktionen und dem Ziel ab. Ein SQL Server auf einer Azure-VM bietet einen anderen Rahmen als ein verwalteter Datenbankdienst. Wir prüfen die tatsächlichen Abhängigkeiten und Herstellerfreigaben, bevor notwendige Änderungen bewertet werden.

Welche Azure-SQL-Plattform ist die richtige?

Die Entscheidung folgt aus Anwendung, Betrieb und Anforderungen. Unser Plattformvergleich erklärt die Unterschiede und hilft Ihnen, die entscheidenden Fragen für Ihre Umgebung zusammenzustellen.

Können Sie ein vorhandenes Konzept überprüfen?

Ja. Für einen Review klären wir zuerst die offenen Fragen und betrachten anschließend Annahmen, Architektur und vorgesehene Nachweise. Daraus ergeben sich bestätigte Punkte, Risiken und konkrete nächste Prüfungen.

Wie viel Ausfallzeit müssen wir einplanen?

Die mögliche Unterbrechung hängt vom Migrationsweg und den beteiligten Anwendungen ab. Wir planen und erproben den Ablauf für Ihre Ausgangslage. Auch Verbindungserholung, nachlaufende Verarbeitung und die fachliche Freigabe gehören in das Zeitfenster.

Die Anwendung wurde bereits migriert und ist jetzt langsam. Wo fangen wir an?

Bei einem konkreten betroffenen Vorgang und einem klar eingegrenzten Zeitraum. Wir vergleichen Anwendungszeit, Datenbankarbeit und Plattformmetriken und leiten daraus den nächsten Prüfschritt ab. Der Ratgeber zur Performance nach der Migration zeigt dieses Vorgehen.

Kontakt

Welcher nächste Schritt hilft Ihrem Vorhaben?

Sie planen einen Umstieg, brauchen eine Zweitmeinung oder möchten eine bestehende Azure-SQL-Umgebung verbessern? Beschreiben Sie uns Ihre Ausgangslage und die Frage, die Sie klären möchten. Hilfreich sind das heutige System, das geplante oder vorhandene Azure-Ziel und der konkrete Anlass.

Im ersten Gespräch klären wir, welche Untersuchung oder Unterstützung dafür sinnvoll ist.

Telefon040 39 88 28 75E-Mailinfo@psg.deAnschriftPSG Projekt Service GmbH
Neuer Wall 80, 20354 Hamburg