DACPAC und BACPAC aus Entwicklersicht 18.11.2024, 00:00 Uhr

Handlich verpackt

Ein Transfer-Dateiformat ermöglicht die fehlerfreie Synchronisierung eines Datenbankschemas mit einer Datei, einer Codebasis, einer anderen Datenbank – und umgekehrt.
(Quelle: dotnetpro)
Als .NET-Entwickler hat man relativ häufig auch mit dem Microsoft SQL Server zu tun. Bei der täglichen Arbeit kam eine Frage auf, und die Suche nach einer Antwort gab zugleich den Anstoß für diesen Artikel: Wie kann ich meine Daten elegant von einem SQL Server zu einem anderen oder in die Cloud übertragen? Kann man das automatisieren, oder gibt es da eigentlich auch ein API dafür?
Alle Datenbankadministratoren werden jetzt vermutlich ­lachend vom Stuhl fallen, tatsächlich aber war das zumindest für mich – als .NET-Entwickler – durchaus eine Frage.
In diesem Artikel sehen wir uns daher etwas genauer die Datenformate DACPAC und BACPAC an, und wir werden klären, was Microsoft unter einer Data-Tier Application versteht und welche Möglichkeiten diese uns bietet.

BAK-Format zum Exportieren und Importieren?

Der erste Gedanke zu der ursprünglichen Frage geht vermutlich in Richtung einer Backup-Datei (Dateiendung .bak). Natürlich lässt sich über das SQL Server Management Studio ­eine BAK-Datei der Datenbank erstellen, allerdings sind damit gewisse Einschränkungen verbunden. So lassen sich BAK-Dateien aus einer neueren SQL-Server-Version nicht auf einem älteren SQL Server einspielen. Bei einer Migration in die Cloud kann der Import ebenfalls erschwert oder gänzlich unmöglich sein. Azure SQL etwa unterstützt keinen BAK-Import.
Grundsätzlich sind BAK-Dateien Datenbankabbilder und funktionieren als solche prächtig für alltägliche Backups. Als Transportformat sind sie allerdings nur mäßig gut geeignet.

Data-Tier Application

Blickt man genauer in die Kontextmenüs des SQL Server Management Studios (SSMS), gibt es dort ein paar Vertreter, die auf ein „Kopieren“ hindeuten.
Da ist zunächst die bereits angesprochene Variante über Backup & Restore. Daneben gibt es (zumindest im SSMS) noch Export Data und Copy Database, aber diese Optionen haben – zumindest bei meinen Versuchen – entweder nur ­mäßige oder gar seltsame Resultate zutage gefördert. Es kann aber sein, dass dies bei einfacheren Datenmodellen durchaus gut funktioniert.
Eine etwas kryptisch anmutende Kategorie enthält allerdings eine Funktion, die genau für das hier angesproche Problem eine Lösung bietet: Extract Data-tier Application … beziehungsweise Export Data-tier Application … zum Exportieren sowie Register as Data-tier Application … beziehungsweise Upgrade Data-tier Application … zum Importieren (Bild 1).
Das Tooling im SQL Server Management Studio (Bild 1)
Quelle: Autor

DACPAC

Die Option Extract Data-tier Application … erzeugt eine DACPAC-Datei, die in der Regel nur die Schema-Informationen der Datenbank enthält.

BACPAC

Im Unterschied zu DACPAC beinhaltet das Format BACPAC neben den Schema- und Daten-Infos auch Login-Informationen und fungiert eher als eine Art klassisches Backup, ähnlich einer BAK-Datei. Eine solche Datei wird ebenfalls über den Menüpunkt Export Data-tier Application erzeugt.
Möchte man eine komplette Datenbank von A nach B kopieren, ist dies über BACPAC durchaus möglich, doch dies hat nicht den Anspruch, ein komplettes Backup zu ersetzen.
Im Unterschied zu einer BAK-Datei wird die BACPAC-Datei sequenziell Tabelle für Tabelle geschrieben, und Änderungen während des Erstellungsprozesses werden einfach mit exportiert, anders als bei einer BAK-Datei, die als Backup genau einen Snapshot zu genau einem Zeitpunkt einfangen kann.

Einsatzzweck

Wenn also eine DACPAC-Datei nur das Schema enthält und eine BACPAC-Datei zwar eine Art Backup darstellt, aber durchaus Probleme mit sich bringt, wofür sind die beiden denn dann gut?
Der Ursprung kommt aus der SQL-Entwicklerwelt, um eine Art Paket zu haben, das sich einfach verteilen lässt und das Änderungen sauber in einem Entwicklungsprozess abbilden kann. Vor diesem Hintergrund ist auch der Name entstanden, denn DACPAC steht für „Data Application Component – Package“. Hinzu kommt, dass zum Beispiel der SQL-Azure-Dienst keine BAK-Dateien nativ importieren kann, jedoch mit DACPAC und BACPAC umgehen kann.

Tooling in Visual Studio

Wie bereits gezeigt, kann ein DACPAC ebenso wie ein BACPAC über das SQL Server Management Studio erstellt werden. Möchte man die SQL-Datenbank, die neben Schema und Daten auch Trigger oder Stored Procedures beinhalten kann, über einen eher entwicklertypischen Prozess aufsetzen, gibt es in Visual Studio eigens ein SQL Database Project, das als Build-Artefakt ein DACPAC erzeugt (Bild 2).
Das Tooling in Visual Studio (Bild 2)
Quelle: Autor
Über diesen Weg ist es möglich, solche Pakete zu bauen und so zum Beispiel Schemaänderungen von der Entwicklungsumgebung hin zu den produktiven Systemen zu bringen. Das Wording, um Änderungen zu publizieren, ist auf den ersten Blick etwas merkwürdig, aber man muss das Ziel eines DACPAC-Imports eher als Applikation begreifen, und dann ergibt „Deploy“ auch tatsächlich Sinn.

Tooling im Azure Data Studio

Neben dem SQL Server Management Studio (SSMS) kann man über das recht junge Azure Data Studio ebenfalls DACPAC- und BACPAC-Dateien erstellen oder importieren. Der Funktionsumfang entspricht aber – zumindest aktuell – so ziemlich dem, was man auch im SSMS findet. Der Hauptunterschied liegt darin, dass die Beschreibungen hier präziser sind und man nicht sofort von einem riesigen Kontext­menü von Optionen erschlagen wird (Bild 3).
Das Tooling im Azure Data Studio (Bild 3)
Quelle: Autor

SqlPackage.exe zur Automatisierung

Wer lieber ein Tool nutzen möchte, um diese Prozesse zu automatisieren, kann SqlPackage.exe einsetzen. Dieses Werkzeug kann man entweder direkt bei der SQL-Installation mit installieren lassen oder separat installieren. Am einfachsten geht der Weg als .NET Tool:

dotnet tool install -g microsoft.sqlpackage
Danach steht einem über sqlpackage ein sehr mächtiges Werkzeug zur Erzeugung und zum Importieren von DACPAC- beziehungsweise BACPAC-Dateien zur Verfügung (Bild 4).
SqlPackage.exe im Einsatz (Bild 4)
Quelle: Autor

.NET API

Die bisher gezeigten Möglichkeiten sind insbesondere für Datenbankadministratoren ein Segen. Allerdings geht es in dem Artikel ja um Entwickler, und für diese gibt es das NuGet-Paket DacFx, um via Code DACPAC-Dateien zu erstellen oder zu deployen. Hat man DacFx einmal hinzugefügt, ist das Erzeugen einer Datei äußerst einfach:

string connectionString = "...";
DacServices dacServices = new(connectionString);
DacExtractOptions options = new DacExtractOptions
{
  ExtractAllTableData = true,
  IgnorePermissions = true,
  IgnoreUserLoginMappings = true,
};
Version version = new Version("1.0");
dacServices.Extract(@"C:\Temp\", 
                    "DatabaseName", 
                    "AppName", 
                    version, extractOptions: options);
Wichtig zu erwähnen ist hierbei, dass die Datei direkt auf dem Client erzeugt wird. Bei einem klassischen SQL-Backup muss man wesentlich genauer überlegen, wohin das resultierende Backup geschrieben wird und ob der aufrufende Client auf diesen Pfad Zugriff hat. Über DacFX entfällt das komplett.
Das Importieren einer Datei geschieht über folgende Codezeilen:

string connectionString = "";
DacServices dacServices = new(connectionString);
DacPackage dacpac = DacPackage.Load(
  @"C:\Temp\test.dacpac");
DacDeployOptions options = new()
{
  IgnorePermissions = true,
  IgnoreUserSettingsObjects = true,
  IgnoreLoginSids = true,
  IgnoreRoleMembership = true,
  AllowIncompatiblePlatform = true,
  ExcludeObjectTypes = new[]
  {
    ObjectType.Users,
    ObjectType.Logins,
    ObjectType.RoleMembership
  }
};
dacServices.Deploy(
  dacpac,
  "DatabaseName",
  true,
  options);

Optionen

Es scheint zwar, als wären DACPAC und BACPAC völlig verschiedene Dateiformate, aber tatsächlich ist der Grundaufbau bei beiden identisch. Es ist bei beiden ein gezippter Ordner, der aus einer Handvoll XML-Dateien und den eigentlichen Daten besteht. Letztere sind in einem binären Format hinterlegt.
Grundsätzlich kann man auch in einem DACPAC über die Eigenschaft ExtractAllTableData Daten exportieren, und diese werden dann auch wieder importiert. Allerdings kann dann nicht jedes Tooling mit den Daten umgehen. Ein DACPAC mit Daten wird zum Beispiel vom Visual-Studio-Tooling als invalide betrachtet.
Welche Eigenschaften zur Verfügung stehen, sieht man am besten in der Dokumentation von SqlPackage.exe und dem jeweiligen Befehl, zum Beispiel bietet Extract noch diverse zusätzliche Eigenschaften. Alle diese Optionen können auch via DacFx genutzt werden.

Kombination mit dem Entity Framework und Co.

Wer in seinen Projekten das Entity Framework oder einen ähnlichen OR-Mapper einsetzt, der die Datenbank-Entitäten auch via Code erstellen kann, wird vermutlich DACPAC im Sinne eines Applikationspakets nicht unbedingt benötigen. Grundsätzlich kann man natürlich SQL Database Projects einsetzen, um Migrationen so abzubilden, aber hier ist die Antwort vermutlich wie so oft: Es kommt darauf an. Besteht ein Kunde auf einen „sauberen“ Migrationsprozess der Datenbank und möchte er ein DACPAC, um Schemaänderungen so auszurollen, ist das ein valider Anwendungsfall. Meist kommt man aber über einen Code-First-Ansatz bereits sehr weit.

Fazit

Eine Data-Tier Application ist nichts, wovor man Angst haben müsste. Möchte man eine Datenbank designen und in einem geordneten Entwicklungsprozess abbilden, eignet sich das SQL-Database-Projekt – zumindest überall dort, wo En­tity Framework und Co. nicht im Einsatz sind.
DACPAC- und BACPAC-Dateien lassen sich über diverse Werkzeuge erstellen, und per API ist dies auch als Entwickler einfach in bestehende Anwendungen integrierbar.
Dokumente
Artikel als PDF herunterladen


Das könnte Sie auch interessieren