18. Nov 2024
Lesedauer 6 Min.
Handlich verpackt
DACPAC und BACPAC aus Entwicklersicht
Ein Transfer-Dateiformat ermöglicht die fehlerfreie Synchronisierung eines Datenbankschemas mit einer Datei, einer Codebasis, einer anderen Datenbank – und umgekehrt.
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)
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)
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 Kontextmenü von Optionen erschlagen wird (Bild 3).
Das Tooling im Azure Data Studio (Bild 3)
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)
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); 
