Migrieren von CLR-Assemblys

Ich migriere eine SQL Server 2008R2-Datenbank auf einen neuen Server. (auch 2008R2)

Auf dem Server befinden sich mehrere CLR-Assemblys. Werden diese automatisch mit der Datenbank migriert oder muss ich sie manuell skripten?

Vielen Dank!

Wie migrieren Sie die Datenbank? Das Kopieren einer Datenbank auf einen anderen Server über Sichern / Wiederherstellen oder Trennen / Anhängen umfasst die Assemblies sowie die T-SQL-Wrapper-Objekte, die auf den Code in den Assemblies verweisen. Wenn Sie ein Tool verwenden, mit dem Sie Objekttypen auswählen können, müssen Sie möglicherweise mindestens überprüfen, ob Baugruppen für die Migration ausgewählt wurden.

Wenn alle Ihre Baugruppen ein PERMISSION_SETvon haben SAFE, sollten Sie ohne zusätzliche Schritte in Ordnung sein (außerhalb der offensichtlichen Aktivierung der CLR-Integration, wie in einer anderen Antwort erwähnt).

Wenn jeder der Versammlungen haben eine PERMISSION_SETvon entweder EXTERNAL_ACCESSoder , UNSAFEdann müssen Sie ein paar zusätzliche Schritte tun:

1. Wenn Sie die nicht bevorzugte, aber einfachere und damit häufigere Methode zum Festlegen der Datenbankeigenschaft von TRUSTWORTHYto verwenden ON, müssen Sie sicherstellen, dass sie ONauf dem neuen Server auf gesetzt ist. Ich würde erwarten, dass die Backup / Restore-Methode diese Einstellung korrekt überträgt, andere Methoden jedoch möglicherweise nicht, insbesondere wenn sie die Datenbank neu am Ziel erstellen.
2. Wenn Sie die bevorzugte Methode für ein Asymmetric Key-basiertes Login verwenden, befinden sich diese Teile in der [master]Datenbank und Sie müssen sicherstellen, dass sie auf dem Ziel kopiert oder neu erstellt werden:
   1. Stellen Sie sicher, dass alle asymmetrischen Schlüssel (die für die CLR-Sicherheit verwendet werden) im [master]Ziel vorhanden sind
   2. Stellen Sie sicher, dass alle Anmeldungen, die auf diesen asymmetrischen Schlüsseln basieren, am [master]Ziel vorhanden sind
   3. Stellen Sie sicher, dass diese Anmeldungen für das Ziel dieselben Berechtigungen auf Serverebene haben: GRANT EXTERNAL ACCESS ASSEMBLYund / oderGRANT UNSAFE ASSEMBLY
3. Unabhängig davon, welche der beiden oben genannten Optionen Sie verwenden, stellen Sie sicher, dass die SID des Datenbankeigentümers zwischen den [master]Angaben in den Datenbankeigenschaften und den Angaben in den Datenbank-Metadaten übereinstimmt . Dies ist normalerweise kein Problem, wenn Sie die Ziel-Datenbank erstellen und anschließend Objekte in diese kopieren. Wenn Sie jedoch Sichern / Wiederherstellen verwenden, kann es zu einer Nichtübereinstimmung der SIDs des DB-Besitzers kommen, wodurch die Ausführung von CLR-Code verhindert wird
4. Ich bin mir dessen weniger sicher, da ich es seit einigen Jahren nicht mehr gesehen habe. Wenn sich jedoch die SID des DB-Besitzers ändert, müssen Sie für Assemblies mit einer PERMISSION_SETvon entweder EXTERNAL_ACCESSoder UNSAFEzumindest die Eigenschaft PERMISSION_SET auf zurücksetzen SAFEund dann zurück zu dem, was es ursprünglich war. Wenn dies nicht hilft, müssen Sie möglicherweise die Assemblies und die zugehörigen T-SQL-Wrapper-Objekte DROPEN und neu erstellen.

Es wäre auch eine gute Idee, sicherzustellen, dass alle auf dem aktuellen / Quellserver vorhandenen Versionen des .Net-Frameworks vor 4.0 auch auf dem Zielserver vorhanden sind. Es spielt keine Rolle, ob zusätzliche Framework-Versionen auf dem Ziel vorhanden sind, aber es macht den Übergang reibungsloser, wenn zumindest nichts fehlt. Obwohl SQL Server 2005 - 2008 R2 statisch mit der .NET 2.0-Serie verknüpft ist (2012 und 2014 sind statisch mit der 4.0-Serie verknüpft), kann eine Assembly 3.0 oder 3.5 erfordern. Wenn dies passiert und diese Framework-Versionen nicht geladen wurden, erhalten Sie eine kryptische Nachricht, die nicht bedeutet, dass eine .NET-Framework-Version fehlt. Eine Version, die sich nicht auf dem Quellserver befindet, wird jedoch eindeutig nicht benötigt, wenn die CLR-Objekte derzeit funktionieren.

Kommt darauf an.

Wenn die Assemblys erstellt wurden und in der zu migrierenden Datenbank gespeichert sind, werden sie mit der Datenbank verknüpft, da sie bereits Objekte in der Datenbank sind.

Wenn die Assemblys in anderen Datenbanken erstellt wurden, die nicht migriert werden, müssen sie irgendwo in der Quellinstanz neu erstellt werden. Wenn die Assembly beispielsweise in der Master-Datenbank erstellt wurde, ist sie nicht Teil der Benutzerdatenbank, die Sie migrieren, und muss im Master auf dem Zielserver erstellt werden.

Da Sie von und zu derselben Version von SQL Server migrieren, ist dies kein Problem. Bei der Migration von Formularen von 2005 auf 2012 kann es jedoch zu Problemen bei der Ausführung von Assemblys kommen, da diese in einer anderen Version von .net erstellt wurden und unterschiedliche Klassen hatten, die als sicher eingestuft wurden.