Microsoft SQL Server News Archiv · ASPICON

Dbvisit Standby MP Maintenance Release (für alle Datenbanken)

Marcel Heinrich — Fri, 13 Mar 2026 10:36:07 +0000

Home → Microsoft SQL Server

Dbvisit Standby MP Maintenance Release (für alle Datenbanken)

Verfasst von Marcel Heinrich
13 März 2026
11:36
Dbvisit Standby, Oracle Database, PostgreSQL, SQL Server, Standby Datenbank

Dbvisit hat mit StandbyMP 12.3.1 ein neues Maintenance Release veröffentlicht. Die Aktualisierung enthält verschiedene kleinere Fehlerbehebungen sowie Verbesserungen im Bereich Sicherheit und Stabilität.

Das Update ist für alle unterstützten Datenbankplattformen relevant, also für Oracle, Microsoft SQL Server und PostgreSQL.

Details dazu findest du in den » Release Notes. Eine Kurzzusammenfassung von uns gibt’s hier.

Mit der StandbyMP Version 12.3.1 wurden unter anderem folgende Verbesserungen umgesetzt:

Verbesserte Sicherheit beim GUI-Login, um den Zugriff auf die Benutzeroberfläche weiter abzusichern
Behebung eines seltenen Fehlers, bei dem die Aktion Activation in einem speziellen Szenario bei einem Primary-Ausfall nicht mehr in der Aktionsliste angezeigt wurde
Deutlich reduzierte Größe der Trace-Log-Dateien, was die Analyse und Verwaltung von Logs erleichtert

Folgende Funktionen wurden entfernt bzw. eingestellt:

Unterstützung für mehrere veraltete Linux-Distributionen wurde entfernt (z. B. Oracle Enterprise Linux 6)
Neue PostgreSQL WAL File Shipping Konfigurationen können nicht mehr erstellt werden. Bereits bestehende Konfigurationen funktionieren weiterhin, neue Setups müssen jedoch andere Replikationsmethoden verwenden.

Hier gibt es weitere Beiträge zum Thema » Dbvisit Standby vom Dbvisit Platinum Partner ASPICON. Z.B. stellen wir in aller Kürze die StandbyMP v12 vor und geben dir eine Übersicht aller wichtigen Supportlaufzeiten.

Share this article

Der Beitrag Dbvisit Standby MP Maintenance Release (für alle Datenbanken) erschien zuerst auf ASPICON.

Microsoft SQL Server 2025: Diese Features haben uns wirklich erfreut

Tobias Braun — Fri, 13 Feb 2026 09:08:37 +0000

Home → Microsoft SQL Server

Microsoft SQL Server 2025: Diese Features haben uns wirklich erfreut

Verfasst von Tobias Braun
13 Februar 2026
10:08
Datenbank, Microsoft, SQL Server

Die Fachpresse hat berichtet, die MS-Blogs sind aufgeregt und natürlich haben auch die Newsletter von Microsoft kräftig die Werbetrommel gerührt: Die 17. Hauptversion des Microsoft SQL Server ist seit einigen Monaten verfügbar und bereit für den Einsatz.

Wenn eine neue Hauptversion veröffentlicht wird, stellen sich meist einige zentrale Fragen: Besteht überhaupt Handlungsbedarf? Für welche Umgebung ist der Einsatz sinnvoll? Sollte ein Wechsel zeitnah erfolgen? Oder ist Abwarten die bessere Strategie?

Dieser Beitrag verfolgt bewusst nicht den Ansatz einer pauschalen Migrations-Empfehlung.

Zum einen, weil technologische Entscheidungen nicht mit Druck, sondern mit Weitblick getroffen werden sollten.
Zum anderen, weil jede IT-Landschaft individuelle Anforderungen und Rahmenbedingungen mitbringt.
Und nicht zuletzt, weil der Einsatz einer neuen Software dann am meisten Mehrwert bringt, wenn er aus Überzeugung und echtem Interesse erfolgt, nicht allein aus Gründen der Kompatibilität.

Statt also vorschnelle Handlungsempfehlungen auszusprechen, werfen wir einen praxisnahen Blick auf ausgewählte Neuerungen, die den Arbeitsalltag von Datenbank-Administratoren und ‑Entwicklern tatsächlich bereichern können – und die zum Teil auch einfach Spaß machen.

SQL Server 2025 Neuerungen: Was sich im Alltag wirklich bemerkbar macht

1) Mehr Leistung und höhere Limits: Express und Standard legen spürbar zu

Das Beste zuerst: Es darf mehr genutzt werden. Im Microsoft SQL Server 2025 wurden die Obergrenzen in mehreren Editionen signifikant erhöht – und das zum ersten Mal seit vielen Versionen.

So wurde die Obergrenze für einzelne Datenbanken in der Express-Edition auf das Fünffache erhöht. Und die Standard-Edition kann nun 32 CPU-Kerne nutzen – solange man (wie gewohnt) darauf achtet, nicht mehr als vier CPU-Sockel zu verwenden. Außerdem kann erstmals auch der Resource Governor bereits in der Standard-Edition verwendet werden.

2) Praktische Verbesserungen statt KI-Show: Backup-Komprimierung, BASE64 und intelligente Abfragebearbeitung

Was in den „gehypten“ Blog-Beiträgen zwischen all den KI-Features oft untergeht, sind die wirklich coolen Neuerungen:

Zum Beispiel eine zusätzliche – und vor allem bessere – Komprimierung für Datenbank-Backups. Oder auch kleine T‑SQL-Erleichterungen, wie die beiden integrierten BASE64-Konvertierungsfunktionen.

Auch in der intelligenten Abfragebearbeitung (Intelligent Query Processing) gibt es zusätzliche Neuerungen, wie die folgende Abbildung zeigt:

3) JSON als Datentyp: Endlich ein „echter“ Spaltentyp

Designierte Datenbank-Designer werden es begrüßen: JSON ist nun endlich als echter Spaltentyp (also Datentyp) verfügbar. Damit sind JSON-Daten und XML-Daten in puncto Handhabung endlich gleichgestellt.

Zusätzlich dürften sich Open-Source-erfahrene Datenbank-Experten über die Einführung von regulären Ausdrücken (in Form von T‑SQL-Funktionen) freuen. Und ja, das funktioniert auch mit WHERE.

4) Change Event Streaming: Änderungen im Datenbestand sauber verarbeiten

Microsoft nimmt zum dritten Mal Anlauf, um einer der häufigsten Herausforderungen im Alltag zu begegnen: der Reaktion auf Änderungen im Datenbestand.

Mit Change Event Streaming wurde eine komplett neue Methode geschaffen, um auf geänderte Tabellenzeilen reagieren zu können – allerdings zum Preis einer » Azure-Anbindung.

5) Sicherheit im Fokus: TLS 1.3 und neue Kennwortrichtlinien

Selbstverständlich wurde auch an der Steigerung der Sicherheit kräftig gearbeitet.

Am deutlichsten ist hier die flächendeckende Verwendung von TLS 1.3 für die Verschlüsselung diverser Verbindungen zu nennen. Der SQL Server Agent, Verbindungsserver, Replikation sowie Client-Anwendungen wie SQLCmd und BCP sind hier nur ein paar der wichtigsten Beispiele.

Zusätzlich sind nun auch benutzerdefinierte Kennwortrichtlinien im Microsoft SQL Server 2025 für Linux möglich.

Hinweis zu Reporting Services:

Der größte Paukenschlag betrifft nicht einmal die SQL Server Engine selbst, sondern ein (bereits seit Jahren) ausgegliedertes Unterprodukt: SQL Server Reporting Services (SSRS).

Dieser Dienst ist in seiner bekannten Form nicht mehr verfügbar. An seine Stelle tritt der Power BI Report Server.

Azure SQL Managed Instance: Technologie-Level jetzt wählbar

Was wenig Beachtung findet, aber für Cloud-affine Admins nicht unrelevant sein dürfte: Das Technologie-Level des Microsoft SQL Server 2025 ist auch als Update-Richtlinie für eine Azure SQL Managed Instance auswählbar.

Konkret bedeutet das: Besitzer einer solchen Managed Instance können entscheiden, ob diese Cloud-Instanz weiterhin wie bisher als 2022er betrieben wird – oder als brandneue 2025er-Version.

Bei der 2022er-Einstellung ändert sich nichts. Das verhindert zwar die neuen Features des Microsoft SQL Server 2025, ermöglicht aber weiterhin den Datenaustausch mit lokalen (On-Premises) Instanzen auf Basis von Microsoft SQL Server 2022.
Bei der 2025er-Einstellung sind praktisch alle Verbesserungen nutzbar – allerdings ist der Datenaustausch nur zu anderen Microsoft SQL Servern 2025 gewährleistet.

Upgrade und Migration auf SQL Server 2025: Das solltest du vorher wissen

Solltest du jetzt schon über eine Migration nachdenken, hier einige relevante Details:

Auch der Microsoft SQL Server 2025 unterstützt direkte Upgrades von allen älteren Versionen ab 2014. Voraussetzung sind die jeweils letzten Service Packs oder Cumulative Updates.
Die Web-Edition, welche bis Version 2022 noch vorhanden war, ist nun nicht mehr verfügbar. Wer also ein In-Place-Upgrade des Microsoft SQL Server 2022 Web durchführen möchte, kommt um eine andere Ziel-Edition nicht herum.
Ähnlich verhält es sich mit der Express-Edition with Advanced Services. Diese Unterart wurde ebenfalls gestrichen – was in der Praxis eher einer Umbenennung entspricht. An ihre Stelle tritt die „normale“ Express-Edition.
Die Produkt-Features Data Quality Services sowie Master Data Services sind nicht mehr vorhanden. Zwar wird wohl kaum ein Datenbank-Admin diese Komponenten ernsthaft vermissen, aber es sei der Vollständigkeit halber dennoch erwähnt.
Die zuvor schon erwähnte Verwendung von TLS 1.3 kann in vielen Fällen zu Verbindungsproblemen führen – insbesondere dann, wenn der SQL-Server-Dienstprozess auf fremde oder separate Datenbank-Dienste zugreifen soll.

Obwohl der Microsoft SQL Server 2025 bereits im November des vorigen Jahres erschien, wurde bisher nur ein einziges CU veröffentlicht. Und genau das hat enttäuscht: Es wurde rasch wieder zurückgezogen und rund zwei Wochen danach erneut herausgegeben. Daher kann man getrost abwarten, bis die ersten Feedbacks aus echten Produktiveinsätzen durchs Netz schwirren.

Besonderer Tipp:

Falls du den „großen“ SQL Server nicht erst installieren willst (oder darfst), aber ohnehin gern mit etablierten Anwendungen programmierst, kannst du dir einen Microsoft SQL Server 2025 LocalDB als Unterkomponente im Microsoft Visual Studio 2026 anschauen. Da hast du nebenbei auch gleich noch das schönere IntelliSense – im Vergleich zu VS Code.

Fazit: SQL Server 2025 ist mehr als nur „2022 plus KI“

Aller Werbung zum Trotz: Der neue Microsoft SQL Server 2025 ist mehr als nur ein 2022er mit angeklebter KI.

Wer den Microsoft SQL Server 2025 aktiv einsetzt und sich die SQL Server Engine anschaut, erkennt die Arbeit der letzten drei Jahre. Microsoft hat sinnvolle Verbesserungen in diversen Bereichen integriert, um eine neue Hauptversion zu rechtfertigen.

Da diese Neuerungen in so gut wie allen Bereichen anzutreffen sind, ist nicht jede Änderung für Datenbank-Admins und ‑Entwickler gleichermaßen relevant. Doch wer schon immer einmal reguläre Ausdrücke in der WHERE-Klausel verwenden oder in der Standard-Edition die Nutzung der Temp-Datenbank begrenzen wollte, kommt im Microsoft SQL Server 2025 definitiv auf seine Kosten.

Du hast Fragen oder denkst über ein Upgrade oder eine Migration auf den SQL Server 2025 nach?
Dann lass uns gern sprechen. Wir denken mit dir gemeinsam über die Vor- und Nachteile nach und finden den für dich besten Weg.

Kontakt

Du hast Fragen oder denkst über ein Upgrade oder eine Migration auf den SQL Server 2025 nach? Dann lass uns gern sprechen. Wir denken mit dir gemeinsam über die Vor- und Nachteile nach und finden den für dich besten Weg.

Kontakt

Hier findest du weitere Features und Infos aus der Welt von Microsoft aus unserem News & Insights Bereich.

Share this article

Der Beitrag Microsoft SQL Server 2025: Diese Features haben uns wirklich erfreut erschien zuerst auf ASPICON.

Updates für Microsoft SQL Server erhältlich

Marcel Heinrich — Thu, 02 Oct 2025 09:26:57 +0000

Home → Microsoft SQL Server

Updates für Microsoft SQL Server erhältlich

Verfasst von Marcel Heinrich
02 Oktober 2025
11:26
Cumulative Update / CU, Datenbank, Microsoft, SQL Server

Im September hat Microsoft ein kumulatives Update für den SQL Server 2022 veröffentlicht sowie ein Security Update für den SQL Server 2019 und 2017. In diesem kurzen Update-Beitrag möchten wir dir einen Überblick zu den wichtigsten Punkten geben und auf die hohe Relevanz von Sicherheitsupdates im Zusammenhang mit Stabilität, Leistung und Sicherheit deiner Datenbanken hinweisen.

Kumulatives Update 21 für SQL Server 2022

Dieses Update enthält 16 Korrekturen, die nach der Veröffentlichung des kumulativen Updates 20 für SQL Server 2022 herausgegeben wurden. Es werden Komponenten in den folgenden Builds aktualisiert:

SQL Server – Produktversion: 16.0.4215.2, Dateiversion: 2022.160.4215.2
Analysis Services – Produktversion: 16.0.43.247, Dateiversion: 2022.160.43.247

Zu den wichtigsten Änderungen zählen:

Korrekturen bei seltenen Absturzszenarien und Performance-Problemen
Optimierungen für Always On, Replikation und In-Memory-Funktionen
Verbesserte Protokollierung und Diagnosemöglichkeiten

Wie bei allen kumulativen Updates gilt:

CU21 enthält alle Fixes der vorherigen Updates, du kannst also direkt von einer älteren Version auf CU21 aktualisieren, ohne Zwischenschritte.

Alle Informationen zum Update findest du » hier.

Hinweis:
Prüfe vor der Installation die „Known Issues“ im offiziellen Changelog und teste das Update in einer Staging-Umgebung, bevor du es produktiv ausrollst.

Security Updates für SQL Server 2019 und 2017

Am 9. September 2025 veröffentlichte Microsoft außerdem das Sicherheitsupdate KB5065222 für SQL Server 2019 CU32 (Version 15.0.4445.1) sowie das Sicherheitsupdate KB5065225 für SQL Server 2017 CU31 (Version 14.0.3505.1). Neben wichtigen Verbesserungen beheben diese Updates mehrere sicherheitsrelevante Schwachstellen:

CVE-2025–47997: Informationsoffenlegung in Microsoft SQL Server
CVE-2025–55227: Möglichkeit der Erhöhung von Benutzerrechten in Microsoft SQL Server
CVE-2024–21907: Fehlerhafte Behandlung von Ausnahmebedingungen in Newtonsoft.Json

Wichtige Änderungen und Fixes:

Aktualisierung der Newtonsoft.Json-Bibliothek auf Version 13.0.1 in SSIS und Master Data Services, um die oben genannte Schwachstelle zu adressieren.
Behebung eines Problems, bei dem dynamische Management-Ansichten (DMVs) potenziell sensible Informationen über andere Sitzungen preisgeben konnten.
Korrektur eines Validierungsfehlers während der Bereinigung interner temporaler Tabellen, der es Angreifern ermöglichte, SQL-Code mit erhöhten Rechten auszuführen.

Verfügbarkeit und Installation:

Die Updates sind über Windows Update, das Microsoft Update Catalog und das Microsoft Download Center verfügbar.
Für Linux-Umgebungen stehen spezifische Installationsanweisungen bereit.

Alle Informationen zum Update findest du » hier (SQL Server 2019) bzw. » hier (SQL Server 2017).

Hinweis:
Diese Security Updates sind dringend empfohlen und verbessern außerdem Stabilität sowie Protokollierung, auch über die Sicherheitsaspekte hinaus. Wenn du sie nicht installierst, bleibt dein SQL Server für bekannte Schwachstellen anfällig – besonders kritisch, wenn externe Zugriffe oder API-Anbindungen bestehen. Die Updates sind nicht kumulativ, sondern setzen voraus, dass deine Instanz bereits auf CU32 (2019) bzw. CU31 (2017) läuft.

Handlungsempfehlung

Microsoft rät allen Nutzern der oben genannten SQL Server Versionen, die neuesten Updates umgehend zu installieren. Dadurch wird sichergestellt, dass die Datenbanken vor den aktuellen Sicherheitsbedrohungen geschützt sind und du von Verbesserungen sowie Erweiterungen profitierst. Wir unterstützen die Empfehlung des Herstellers und raten aus oben genannten Gründen ebenfalls zum Update.

Solltest du Fragen oder Bedenken hinsichtlich der Installation der Updates haben, wende dich gern an unsere Microsoft SQL Server Experten.

Kontakt

Hier findest du weitere Features und Infos aus der Welt von Microsoft aus unserem News & Insights Bereich.

Share this article

Der Beitrag Updates für Microsoft SQL Server erhältlich erschien zuerst auf ASPICON.

Dbvisit StandbyMP V12 ab sofort verfügbar

Sebastian Naumann — Tue, 15 Apr 2025 13:40:00 +0000

Home → Microsoft SQL Server

Dbvisit StandbyMP V12 ab sofort verfügbar

Verfasst von Sebastian Naumann
15 April 2025
15:40
Dbvisit Standby, Oracle Database, PostgreSQL, SQL Server

Seit Anfang April ist die Version 12 von Dbvisit StandbyMP bereits für Partner verfügbar. Seit heute kann sich die breite Masse über die neuen Features und Weiterentwicklungen freuen. Egal, ob du die Ausfallsicherheit deiner Oracle‑, MS SQL Server oder PostgreSQL Datenbanken verbessern, die Performance optimieren oder einfach deine Prozesse noch schlanker gestalten willst – Version 12 der Multiplattform hat einiges im Gepäck. In diesem Beitrag zeigen wir dir in aller Kürze die zwei relevantesten Änderungen und sagen dir, was sonst noch wichtig ist.

Die Kommandozeile ist zurück

Für alle CLI Enthusiasten gibt es eine gute Nachricht: Die Kommandozeile ist zurück. Mit der V12 veröffentlicht Dbvisit ein standardisiertes CLI “dbvcli”. Damit wird erstmals ein einheitlicher Syntax für das Verwalten der Standby-Umgebung aller drei Datenbanksysteme (Oracle Database, MS SQL Server und PostgreSQL) eingeführt.

Darüber hinaus wird für Oracle Umgebungen das alte “dbvctl” vollends unterstützt.

Schnittstellenerweiterung

Dbvisit erweitert seine Schnittstelle für 3rd Party Tools, so dass eine nahtlose Integration möglich ist. Darüber hinaus hast du über die API die Möglichkeit, StandbyMP vollständig aus der Ferne von einem beliebigen Tool oder einer Software-Suite eines Drittanbieters zu steuern.

Die öffentliche API basiert dabei auf OpenAPI. Eine Dokumentation der Schnittstellen wird bei der Installation mit ausgerollt.

Wichtig für PostgreSQL

Der WAL File Shipping Replikationsmodus für PostgreSQL ist veraltet. Bestehende Konfigurationen, die den WAL File Shipping Replikationsmodus verwenden, werden weiterhin funktionieren, aber es können keine neuen Konfigurationen mit diesem Modus erstellt werden. Die Unterstützung für den WAL File Shipping Replikationsmodus wird in einer zukünftigen Version entfernt. Zu diesem Zeitpunkt müssen alle Konfigurationen, die den WAL File Shipping Replikationsmodus verwenden, unter Verwendung der WAL Archiving oder WAL Streaming Replikationsmodi neu erstellt werden.

Wichtig für Kunden mit gehärteten Linux Systemen

Dbvisit liefert standardmäßig keine Policy für SELinux, das heißt entweder man schaltet dies aus oder legt selbst Hand an und erstellt eine Policy. In unserer Testumgebung war letzteres problemlos möglich.

Fazit

Neben der Anpassung des Look and Feels sowie einiger Komfort Optimierungen der grafischen Oberfläche stellt Dbvisit mit dem neuen Release auch Bugfixes zur Verfügung.

Wir werden uns das Produkt in naher Zukunft in den Kategorien Performance (Transferraten, Switchover und Failover-Zeiten) sowie Sicherheit (Netzwerkkommunikation) noch etwas genauer ansehen. Du kannst dich also auf weiterführende Beiträge dahingehend freuen.

Zum Thema Migration sei gesagt: Obwohl das » Supportende für Dbvisit Standby Version 10 von Mai auf Dezember 2025 verschoben wurde, könnte es bereits jetzt von Vorteil sein, auf die neueste Version umzusteigen. Gerne überprüfen wir gemeinsam mit dir deine Dbvisit Standby Installation und unterstützen dich bei einem möglichen Upgrade.

Du hast Fragen zur Dbvisit V12 oder zur Migration?
Melde dich gern bei uns.

Kontakt

Marcel
Senior Account Manager bei ASPICON

Hier gibt es weitere Posts zum Thema Dbvisit Standby vom Dbvisit Platinum Partner ASPICON.

Share this article

Der Beitrag Dbvisit StandbyMP V12 ab sofort verfügbar erschien zuerst auf ASPICON.

DBA Tipp: Wie du dich für das richtige SQL Server Wiederherstellungsmodell entscheidest

Tobias Braun — Wed, 25 Sep 2024 08:38:26 +0000

Home → Microsoft SQL Server

DBA Tipp: Wie du dich für das richtige SQL Server Wiederherstellungsmodell entscheidest

Verfasst von Tobias Braun
25 September 2024
10:38
Backup & Recovery, Datenbank, DBA Tipp, Microsoft, SQL Server

Die Frage “Welches SQL Server Wiederherstellungsmodell ist das richtige für mich?” ist nicht immer so leicht zu beantworten, das erleben auch wir als Dienstleister bei unseren Kunden immer wieder. Falls du dir jetzt von diesem DBA Tipp eine einfache Antwort auf die Frage erhoffst und womöglich noch eine Pro- und Contra-Liste erwartest, solltest du vielleicht besser aufhören zu lesen. Denn – Spoiler Alarm: Es gibt kein pauschales “Besser” oder “Schlechter” der einzelnen Modelle.

Was es allerdings durchaus gibt, sind einige Überlegungen und Kernfragen, die du dir im Vorfeld unbedingt stellen solltest und die dir dabei helfen werden, künftig die richtige Wahl zu treffen. Also, falls du gewillt bist, etwas tiefer in die Materie der SQL Server Wiederherstellungsmodelle einzusteigen, um den Entscheidungsprozess künftig zu beschleunigen, ließ gern weiter.

SQL Server Wiederherstellungsmodell ist nicht gleich Sicherungsmodell!

Zu Beginn noch eine kurze Rekapitulation: Es heißt aus guten Grund “Wiederherstellungsmodell” und nicht etwa “Sicherungsmodell”. Schließlich legst du mit dem SQL Server Wiederherstellungsmodell fest, wie du im Falle einer Wiederherstellung von Tabellen und Zeilen vorgehen möchtest. Dieser Gedanke wird nicht selten vergessen, wenn man die Datensicherungsstrategie plant. Hinzu kommt, dass eine potentielle Wiederherstellung nicht erst nach Hardware-Ausfällen oder nach größeren Katastrophen notwendig wird, sondern auch (oder ganz besonders) aufgrund der “von innen ausgehenden Gefahren” (siehe Frage 5 im nächsten Abschnitt) durchgeführt werden muss.

Grundsätzlich unterscheidet man im Microsoft SQL Server Bereich drei Wiederherstellungsmodelle:

Das einfache Wiederstellungsmodell
Das vollständige Wiederherstellungsmodell
Das massenprotokollierte Wiederherstellungsmodell

Die richtigen Fragen, um das richtige SQL Server Wiederherstellungsmodell zu finden

Um sich völlig zu vergegenwärtigen, wie sich die drei möglichen Modelle von einander unterscheiden, solltest du nicht nur die klassischen Indikatoren im Blick haben, sondern auch die “stressverursachenden” Einflüsse beachten. Hier einige Beispiele dafür:

Klassische Indikatoren

Dauer der Wiederherstellung
Aufwand der Wiederherstellung (für den Admin)
Platzbedarf der Backups
Größe des Transaktionsprotokolls

Stressverursachende Einflüsse

Relevanz aktueller Daten für Fachanwender
Relevanz aktueller Daten für Entscheidungsträger
Bedeutung der Differenz zwischen aktuellen und gesicherten Daten
Möglichkeiten der (Wieder)Beschaffung nicht im Backup enthaltener Daten

Darüber hinaus sind die folgenden 5 Überlegungen geradezu essenziell, wenn du vor der Frage des sinnvollsten SQL Server Wiederherstellungsmodells für deine Datenbank stehst:

5 Fragen, die dir dabei helfen, das richtige Wiederherstellungsmodell zu finden

1. Welche Relevanz hat die Datenbank, auch im Hinblick auf die Aufrechterhaltung des Unternehmens?

Handelt es sich um eine ERP-Datenbank mit über 1000 Kunden und Lieferanten oder lediglich um ein Intranet mit mäßig brisanten Informationen?

Müssen ein Dutzend Fachanwender die verlorenen Daten erneut eingeben oder ist die Anwendung in der Lage, die fehlenden Daten aus dem alten Datenstand zur errechnen?

Stehen diverse produktionskritische Systeme und Anlagen still oder wird der Ausfall der Datenbank für bis zu 48 Stunden gar nicht bemerkt?

2. Welche Änderungen finden in den Tabellen/Zeilen statt?

Handelt es sich um eine 24/7‑Datenbank, die immer unter Last steht oder erfolgen nur sporadische Änderungen?

Werden Datensätze gleichmäßig (also ohne erkennbare Pause) geändert oder erfolgt der hauptsächliche Schreibzugriff nur in der Kernarbeitszeit?

Sind die fehlenden Daten (nach einer Wiederherstellung) komplett verloren oder kann eine Fachanwendung eine geringe Menge an Daten erneut in die Datenbank einfügen?

3. Wie viel Zeit ist nötig, um den aktuellsten Stand der Datensicherung einzuspielen?

Wie lange dauert eine komplette Wiederherstellung?

Ist die Dauer des Wiederherstellungsprozesses relevant für den Geschäftsbetrieb?

4. Sind externe Datensicherungslösungen daran beteiligt?

Wird ein Drittanbieterprodukt (wie beispielsweise Veeam) zur Datenbanksicherung verwendet oder kommen nur klassische SQL Server Agent Jobs zum Einsatz?

Wird der Host virtuell betrieben und per Snapshot gesichert? Wie oft werden die Snapshots angefertigt?

5. Mit welchen internen Fallstricken ist möglicherweise zu rechnen?

Kommt es ab und zu vor, dass die Programm-Updates der Fachanwendungen eine unangenehme Auswirkung auf die Datenbank haben?

Neigen Fachanwender dazu, Daten unbeabsichtigt zu löschen oder zu verändern?

Einfaches vs. vollständiges SQL Server Wiederherstellungsmodell

Hast du dir nun ein Bild von der Relevanz deiner Datenbanken gemacht, so fällt es wesentlich leichter, die Wiederherstellungsmodelle (man könnte auch sagen “Strategien zur Wiederherstellung”) für jede einzelne Datenbank festzulegen.

Da die Unterschiede zwischen dem massenprotokollierten und dem vollständigen Modell zu vernachlässigen sind, fassen wir diese beiden Modelle in der weiteren Betrachtung zusammen. Damit unterscheiden wir im Folgenden lediglich zwischen dem einfachen und dem vollständigen Wiederherstellungsmodell:

Das einfache SQL Server Wiederherstellungsmodell

Kann nur verwendet werden, um eine ganze Datenbank auf den Zeitpunkt eines vergangenen Komplett-Backups wiederherzustellen.
Ermöglicht komplette und differentielle Datenbank-Backups.
Ermöglicht keinerlei Transaktionsprotokoll-Backups.
Sorgt für ein eher kleines Transaktionsprotokoll.

Das vollständige SQL Server Wiederherstellungsmodell

Kann verwendet werden, um eine Datenbank auf den Zeitpunkt eines vergangenen Komplett-Backups und darauf aufbauender Transaktionsprotokoll-Backups wiederherzustellen.
Ermöglicht komplette und differentielle Datenbank-Backups.
Ermöglicht und erfordert zusätzlich auch Transaktionsprotokoll-Backups.
Sorgt meist für ein mittelgroßes Transaktionsprotokoll.

Zwischenfazit

Auf die jeweils erste Eigenschaft kommt es bei der Entscheidung an. Denn während man unter Verwendung des einfachen Wiederherstellungsmodells eine Datenbank nur auf den Datenstand zum exakten Zeitpunkt der Komplettsicherung zurückspielen kann, ist bei Verwendung des vollständigen Wiederherstellungsmodells nahezu jeder Zeitpunkt nach der Komplettsicherung möglich. Und eben genau darauf sollte deine Überlegung abzielen: Der Anspruch an die gezielte Wiederherstellbarkeit einzelner Datensätze. Denn wenn die Änderungen einzelner Aktionen in den Tabellen “ungeschehen gemacht” werden sollen, dann scheidet das einfache Wiederherstellungsmodell aus.

Fazit

Das SQL Server Wiederherstellungsmodell entscheidet maßgeblich darüber, wie granular eine Wiederherstellung durchgeführt werden kann.

Kannst du mit einem theoretischen Datenverlust leben, der sich vom Zeitpunkt des letzten Komplett-Backups bis zum Ausfall ergibt? Dann kann das einfache Wiederherstellungsmodell genügen.

Suchst du nach einem Weg, den theoretischen Datenverlust so weit wie möglich zu minimieren, indem du die Zeit zwischen zwei Komplett-Backups mit diversen kleineren Backups überbrückst? Dann bleibt nur das vollständige Wiederherstellungsmodell übrig.

Die Entscheidung für oder gegen ein bestimmtes Wiederherstellungsmodell wird also durch die maximal tolerierbare Menge an verlorenen Daten bestimmt. Als Faustregel gilt, dass mit steigender Anforderung an einen möglichst hohen/aktuellen Datenstand, die Entscheidung auf das vollständige Wiederherstellungsmodell hinausläuft. Bedenke jedoch, dass auch das vollständige Modell und sehr häufige Transaktionsprotokoll-Backups bei produktionskritischen Datenbanken kein Ersatz für eine Hochverfügbarkeitslösung darstellt.

Solltest du trotz der genannten Überlegungen nicht sicher sein, welches
SQL Server Wiederherstellungsmodell für welche deiner Datenbanken das richtige ist,
ruf uns gern an oder schreibe uns.

Kontakt

Hier findest du weitere Infos zum Thema » Microsoft SQL Server aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Wie du dich für das richtige SQL Server Wiederherstellungsmodell entscheidest erschien zuerst auf ASPICON.

Standby MP v11.7 – Neue Features und Verbesserungen jetzt verfügbar

Marcel Heinrich — Tue, 23 Apr 2024 12:29:42 +0000

Home → Microsoft SQL Server

Standby MP v11.7 – Neue Features und Verbesserungen jetzt verfügbar

Verfasst von Marcel Heinrich
23 April 2024
14:29
Dbvisit Standby, Oracle, PostgreSQL, SQL Server, Standby Datenbank

Dbvisit Standby MP v11.7 wurde am 10. April veröffentlicht. Es enthält allgemeine und übergreifende Verbesserungen, wie beispielsweise plattformübergreifende Multi-Datenbank-Aktionen, ereignisgesteuerte Echtzeitkommunikation und verbesserte Skalierbarkeit. Darüber hinaus bringt die aktuelle Version der Multi Plattform neue Funktionen für SQL Server und Verbesserungen für Oracle mit.

Hier die Highlights im Überblick:

Oracle Leistungsverbesserungen:
Standby MP 11.7 ermöglicht jetzt die Verwendung von Standby Update Delays bei der Verwendung von RMAN zur Anwendung von Archivprotokollen. Außerdem wurde die srvctl-Registrierung von Standby-Datenbanken für Kunden, die ACFS-Dateisysteme verwenden, verbessert.
Geplante SQL Server-Berichte und Aufbewahrung von Protokollsicherungen:
Standby MP für SQL Server bietet eine schneller zu implementierende und besser ausgestattete Alternative zu Log Shipping und Basic Availability Groups. In dem Bereich gibt es zwei neue Funktionen, die den Wert der Disaster Recovery-Infrastruktur maximieren: Zum Einen die zeitgesteuerte Standby-Berichterstattung und zum Anderen die Aufbewahrung von Log-Sicherungen.

Schauen wir uns die beiden letzten Punkte einmal genauer an:

Zeitgesteuerte Standby-Berichterstattung (SQL Server)

Diese neue Funktion vereinfacht die Verwendung von SQL Server-Standby-Datenbanken für die Berichterstellung. Es ist nun mühelos möglich, eine vielseitige Standby-Datenbank zu erstellen und zu konfigurieren, die nicht nur effizient für DR-Anforderungen, sondern auch für Berichtsabfragen geeignet ist.

Durch die geplanten Standby-Berichte werden CRON-Jobs, Zollskripte oder die Planung von Protokollanwendungen über SQL Server Management Studio überflüssig. Die Berichtszeiten können auf der grafischen Benutzeroberfläche festgelegt werden und Standby MP kümmert sich um den Rest. Einschließlich der Verwaltung von Datenbankzustandsübergängen, der Übertragung und Anwendung von Protokolldateien und der Überwachung von Änderungen.

Aufbewahrung von Log-Sicherungen (SQL Server)

Mit der Log Backup Retention kann jetzt ganz einfach konfiguriert werden, wie lange Log-Backups (Transaktionsprotokoll-Backups) aufbewahrt werden sollen, sodass diese für andere Backup-Aufgaben oder Verwendungen genutzt werden können.

Backups sind ein wichtiger Bestandteil jeder DR-Strategie. Mit der neuen Funktion besteht jetzt die Möglichkeit, Log-Backup-Dateien auf der Primär- oder Standby-Plattform als Teil eines Backup-Plans zu verwenden. Dadurch entfällt die Notwendigkeit, ein Transaktionsprotokoll-Backup nur als Kopie zu erstellen, was die Prozesse rationalisiert und die Belastung der Datenbank reduziert!

Hinweis:
Die Veröffentlichung dieses Features sollte eines der Probleme lösen, welches wir in unserem Nachtrag zum Beitrag “Dbvisit Standby MP v11 – Getestet für SQL Server!” bemängelt haben. Ein praktischer Test der aktuellen Version inklusive der neuen Funktionen fand unsererseits bisher noch nicht statt.
» Hier geht’s zum Beitrag

Eine detaillierte Liste der Änderungen und Verbesserungen in Standby MP v11.7 findest du → hier.

Wir möchten an der Stelle nochmals darauf hinweisen: Obwohl das Supportende für Dbvisit Standby Version 10 auf Mai 2025 verschoben wurde (von Februar 2024), könnte es bereits jetzt von Vorteil sein, auf die neueste Version umzusteigen. Gerne überprüfen wir gemeinsam mit dir deine Dbvisit Standby Installation und unterstützen dich bei einem möglichen Upgrade.

Hier gibt es weitere Posts zum Thema Dbvisit Standby vom Dbvisit Platinum Partner ASPICON.

Share this article

Der Beitrag Standby MP v11.7 – Neue Features und Verbesserungen jetzt verfügbar erschien zuerst auf ASPICON.

Häufige Fehler beim Einsatz von SQL Server Datenbanken: Teil 1 – Instanzkonfiguration

Tobias Braun — Fri, 05 Apr 2024 08:38:38 +0000

Home → Microsoft SQL Server

Häufige Fehler beim Einsatz von SQL Server Datenbanken: Teil 1 – Instanzkonfiguration

Verfasst von Tobias Braun
05 April 2024
10:38
Datenbank, DBA Tipp, Microsoft, Praxistipp, SQL Server

Dieser DBA Tipp ist der erste Teil einer kleinen Serie, welche sich detailliert mit der Fehlervermeidung beim Einsatz von Microsoft SQL Server Datenbanken beschäftigt. Um die Vielzahl von Punkten übersichtlich zu halten, haben wir die Serie in 3 Themenbereiche untergliedert.

Teil 1: Instanzkonfiguration
Teil 2: Datenbankkonfiguration
Teil 3: Sicherheit von Instanzen

Ziel ist es, dir mit Hilfe der Beiträge ein paar Handgriffe mitzugeben, um den Betrieb deiner SQL Server Datenbanken zu verbessern.

Wir beginnen ganz oben – sprich: auf Ebene der Instanz. Dazu stellen wir aus jedem Teil verschiedene Punkte vor, welche unserer Erfahrung nach am häufigsten auftreten:

1. Performance – Probleme durch starre Prozessorzuordnung

Die Zuordnung einzelner Prozessoren oder Kerne zu einer bestimmten SQL Server Instanz entsteht mehrheitlich aus dem Wunsch heraus, die Ressourcen eines von mehreren Instanzen gemeinsam genutzten Windows Hosts optimal zu verteilen. Insbesondere auch in virtualisierten Umgebungen spielt das eine erhebliche Rolle. Hier kann man sich jedoch schnell bei der korrekten Zuweisung der CPU-Ressourcen verschätzen. Man läuft hier schnell Gefahr, die zwei folgenden Tatsachen außer Acht zu lassen:

Ein Prozessor oder Kern sollte niemals für Abfragen und I/O‑Aufgaben gleichermaßen genutzt werden.
Die manuelle Zuordnung deaktiviert ebenfalls den dynamischen Wechsel eines SQL-Threads (Scheduler) von einem Prozessor zum anderen.

Werden diese beiden Tatsachen nunmehr in der manuellen CPU-Zuweisung nicht berücksichtigt, kann es schnell zu folgenden Problemen kommen:

Die Überschätzung der benötigten CPU-Ressourcen führt zu einer Verschwendung von zum Teil kostenintensiven IT-Ressourcen (Host Power, Investitionen, IT Betrieb, etc.)
Die Unterschätzung der benötigten CPU-Ressourcen führt früher oder später zwangsläufig zu Performanceproblemen und den damit verbundenen nicht unerheblichen versteckten Kosten.

In beiden Fällen läuft es also nicht optimal. Klar, wenn man das weiß, kann man die CPU-Zuweisung auch schnell wieder anpassen. Doch macht eine ständige manuelle Anpassung wirklich Sinn? Und vor Allem: Hat der DBA heute für so etwas überhaupt noch ausreichend Zeit? Das muss jeder für sich selbst bewerten, aber wir meinen, genau diese Arbeit sollte man dem SQL Server selbst überlassen. Dazu bringt das SQL Server OS bereits entsprechende Algorithmen mit, die diese Arbeit selbstständig und zuverlässig übernehmen. Und genau das ist auch unsere klare Empfehlung für diesen Punkt.

2. Stabilität – unnütze Trace Flags

Trace Flags verändern die Funktionsweise des SQL Servers an entscheidenden Stellen. Daher sind sie ab Werk (also durch Microsofts Installer) niemals automatisch aktiviert. Das manuelle Setzen an sich ist jedoch nicht komplett falsch, sondern vielmehr das unnötige Setzen. Denn einmal aktivierte Trace Flags tendieren dazu, im Arbeitsalltag sehr schnell in Vergessenheit zu geraten. Nicht zuletzt auch dadurch, dass das SQL Server Management Studio bis heute keinerlei Oberfläche zur Anzeige oder Kontrolle von Trace Flags anbietet.

Der Sinn eines Trace Flags liegt darin, einige der grundlegenden Funktionen zu steuern, die teilweise tief in der Engine verborgen sind. Hier sollte man genau wissen, was man tut.

Es ist daher ratsam, mit Trace Flags im Alltag äußerst sparsam umzugehen. Unsere Empfehlung stützt sich hierbei auf zwei Dinge:

Verstehen: Vor dem Aktivieren sollte man sich die Zeit nehmen und die Beschreibung zumindest grundlegend studieren. Erst wenn man darin einen guten Grund erkennt, sollte man das Trace Flag auch setzen.
Dokumentieren: Die Aktivierung des Trace Flags sollte auf eine solide Art und Weise vermerkt werden, idealerweise mit einer Begründung, warum es aktiviert wird. Das beugt dem Vergessen vor und ist um so wichtiger, wenn man sich die Verantwortung für einen SQL Server mit anderen Personen teilt.

Ausgewählte Beispiele für überholte Trace Flags sind:

1117 – all file grow
3023 – backup checksum default
4136 – no parameter sniffing
6545 – CLR strict security
8079 – soft-NUMA

Einige Beispiele für gefährliche Trace Flags sind:

3042 – no pre-allocation for compressed backups
3459 – no parallel redo
8020 – working set unawareness

Ein besonderes Beispiel für ein nicht existentes Trace Flag ist:

2861 – zero cost plan capture

Diese Auflistung soll selbstverständlich die Trace Flags nicht pauschalisieren. Sie soll vielmehr eine Empfehlung sein, die jeweiligen Einstellungen nicht leichtfertig zu setzen und sich außerdem über Sinn und Zweck eines Trace Flags absolut im Klaren zu sein.

3. Netzwerk – dynamische TCP/IP-Ports

Eine der unschönsten Konfigurationen eines SQL Servers entsteht bereits während der Installation. Und zwar die Verwendung dynamischer Ports des TCP/IP-Protokolls. Denn benannte SQL-Server-Instanzen verwenden von Haus aus bei jedem Hochfahren der Instanz (Dienststart) einen anderen Port.

Ändert man das auf die Verwendung von statischen Ports, ergeben sich zwei Vorteile:

Der SQL-Datenverkehr zwischen der Instanz (oder dem Host) und den Clients kann nun auch durch eine Firewall geleitet werden, was zu grundsätzlich zu einer erhöhten Sicherheit im Datenverkehr beiträgt. In einem unserer früheren Beiträge mit dem Titel “TCP/IP-Konfiguration und Probleme mit Firewalls im SQL-Server-Alltag” geben wir noch weitere Tipps und Informationen zu dieser Thematik.
Man kann nun auch bei einer benannten Instanz auf den SQL Browser verzichten, da sich die Verbindungszeichenfolge nicht mehr ändert.

Folglich empfehlen wir bei diesem Punkt die Umstellung auf feste (statische) Ports.

4. Sicherheit – Berechtigungs-Wildwuchs

Das folgende Thema ist simpel, aber wertvoll. Unter Windows-Admins ist eine Regel wohlbekannt: keine Berechtigungen für Benutzer, sondern für Gruppen. Anstatt also eine Reihe von einzelnen Logins mit vielen Einzelberechtigungen zu versehen, ist es ratsam, die jeweiligen Logins einer Rolle zuzuordnen. Und damit ist auch schon die Lösung genannt.

Dieses aus dem Windows-Bereich bekannte Prinzip lässt sich auch im SQL Server anwenden. Lediglich das Wording ist ein klein wenig unterschiedlich:

Was im Windows (oder Active Directory) die Benutzer sind, wird im SQL Server als “Login” bezeichnet
Was im Windows eine Gruppe ist, wird im SQL Server eine Server-Rolle genannt

Leider noch immer wenig bekannt ist die Tatsache, dass Microsoft mit Einführung der SQL Server Version 2012 die Option für selbst definierte Server-Rollen bereitgestellt hat. Server-Rollen können differenziert mit Berechtigungen ausgestattet werden. Sicherlich macht das hier am Anfang ein wenig mehr Arbeit, sich entsprechende Gedanken zu machen und dies auch so umzusetzen. Aber der Aufwand lohnt sich.

Erfahrungsgemäß zahlt sich das saubere Vorgehen bei der Umsetzung der oben genannten Punkte aus. Insbesondere bei der Umsetzung von Migrationen oder Konsolidierungen von SQL Server Instanzen lassen sich somit entsprechende Aufgaben optimieren. Eine konsequente Verwendung von Server-Rollen und deren sinnvolle Benennung trägt entscheidend zur Transparenz in den Systemen bei und erleichtert somit auch eine Systemdokumentation.

5. Effizienz – ungenutzte Komponenten

Ein bereits bekannter Umstand ist, dass beim Setup eines SQL Servers diverse Komponenten für die Installation auch einzeln ausgewählt werden können. Die wichtigsten Komponenten sind:

SQL Server Engine
Analysis Services
Integration Services

Vermutlich aus Gründen der “Einfachheit” werden bei vielen Installationen grundsätzlich erstmal alle Komponenten installiert – unabhängig davon, ob sie zum Einsatz kommen oder nicht. Besser wäre es jedoch, sich im Vorfeld darüber Gedanken zu machen, welche Komponenten tatsächlich gebraucht werden. Nicht zuletzt aus Sicherheitsgründen sollten nicht benötigte Komponenten von den Systemen entfernt werden – oder gar nicht erst installiert werden. Weiterhin verursacht auch die Administration (Wartung, Patchen, Rechtevergabe, …) einen erhöhten Arbeitsaufwand beim Administrator und stellt zudem eine zusätzlich Fehlerquelle dar. Nicht außen vor gelassen werden soll der Umstand, dass die Komponenten natürlich auch entsprechende Ressourcen auf der Hardware unnötig in Anspruch nehmen. Wie zuvor bereits erwähnt, lassen sich die Komponenten im Bedarfsfall auch problemlos nachinstallieren.

Als kleines Beispiel aus der Praxis heraus gegriffen, ist die Installation der Komponente PolyBase. PolyBase selbst ist ein sehr interessantes Werkzeug, um auf externe Datenquellen zuzugreifen – aber die wenigsten Administratoren nutzen dieses Tool auch tatsächlich. Trotzdem findet sich diese Komponente heute bei einer Vielzahl von SQL Server Installationen wieder.

Zusammenfassend lässt sich sagen: installiert werden sollte nur das, was tatsächlich benötigt wird.
Dieses Vorgehen

reduziert Aufwand und Verantwortung beim DBA
schont kostenintensive Hardware-Ressourcen
minimiert das Sicherheitsrisiko

Übrigens: Microsoft geht hier selbst mit gutem Beispiel voran und bietet die bekannten Reporting Services im SQL Server Setup gar nicht mehr an. Möchte man ganz bewusst eine SSRS-Instanz installieren, genügt ein kurzer Abstecher in das MS Download Center.

Fazit

Im ersten Teil unserer dreiteiligen Serie zu den häufigsten Fehlern beim Einsatz von SQL Server Datenbanken, haben wir dir fünf konkrete Ansatzpunkte an die Hand gegeben, um allein bei der Instanzkonfiguration schon einiges mehr an Performance, Stabilität und Sicherheit herauszuholen. Zum Teil sind es wirklich banale Themen, über die man doch gern mal wieder stolpert. Unser Fazit: Bereits mit kleinen Handgriffen kannst du die Arbeit respektive den Betrieb der SQL Server Datenbanken wesentlich verbessern.

Share this article

Der Beitrag Häufige Fehler beim Einsatz von SQL Server Datenbanken: Teil 1 – Instanzkonfiguration erschien zuerst auf ASPICON.

Dbvisit Standby MP v11 – Getestet für SQL Server! – Nachtrag (14.03.2024)

Isabel Dahl — Thu, 14 Mar 2024 08:43:53 +0000

Home → Microsoft SQL Server

Dbvisit Standby MP v11 – Getestet für SQL Server! – Nachtrag (14.03.2024)

Verfasst von Isabel Dahl
14 März 2024
09:43
Dbvisit Standby, SQL Server, Standby Datenbank

Nachdem wir die Anwendung “Dbvisit Standby Multiplatform v11 für SQL Server” im April 2022 intern ausführlich getestet haben (den Bericht dazu findest du » hier), bot sich im vergangenen Jahr eine Verwendung in der Praxis an. Ausgerechnet dort zeigte sich jedoch, dass Theorie und Praxis leider manchmal sehr weit voneinander entfernt liegen – und dass Murphy’s Gesetz uneingeschränkt gilt: Alles, was schiefgehen kann, wird schiefgehen.

So mussten wir zum Einen feststellen, dass der Graceful Switchover unerwartet schlecht skaliert. Denn ab einer hohen zweistelligen Anzahl an Nutzerdatenbanken dauerte der Switchover-Vorgang unangenehm lange. Dies kann ein Killerkriterium für alle Umgebungen sein, in denen man die Umschaltung von der Primär-Seite zur Standby-Seite in kürzester Zeit vollziehen möchte oder muss.

Zum Anderen offenbarte sich eine Art Designproblem in Form von “verhinderten Transaktionsprotokoll-Backups”. Da die Aktualisierung der Standby-Seite mittels Transaktionsprotokoll-Fragmenten von der primären Seite durchgeführt wird, führt der “Dbvisit StandbyMP Agent” eben auf der primären Seite auch regelmäßige Backups der Transaktionsprotokolle durch. Dies allein wäre noch kein Problem, doch leider werden die Backup-Dateien recht schnell wieder gelöscht, sodass der Administrator praktisch keine Gelegenheit hat, jene Backups für sich selbst zu nutzen. Dies ist ein klarer Nachteil, der jedoch nicht sein müsste. Tatsächlich wird dieser Punkt sogar als offizieller Change Request (Nr. 18968) bei Dbvisit geführt.

Wir werden das Produkt weiterhin beobachten – vor allem die Veröffentlichungen der Change Requests. Bis dahin ist unsere Euphorie leider etwas gedämpft und wir können nur empfehlen, die eigene Systemlandschaft und vorherrschenden Bedingungen genau zu prüfen und abzuwägen, ob der Einsatz der Multiplattform für SQL Server den individuellen Anforderungen entspricht.

Hier gibt es weitere Posts zum Thema Dbvisit Standby vom Dbvisit Platinum Partner ASPICON.

Share this article

Der Beitrag Dbvisit Standby MP v11 – Getestet für SQL Server! – Nachtrag (14.03.2024) erschien zuerst auf ASPICON.