Unsafe Assembly für CLR-Integration und Schlüssel-Signierung
Georg Gungl
entsprechend der Anleitung
<http://msdn.microsoft.com/de-de/library/ms160866(SQL.90).aspx>
habe ich Schlüsseldateien erzeugt und meine DLLs damit signiert.
Der SQL Server behauptet bei der Installation jedoch:
"Fehler bei CREATE ASSEMBLY fr die 'ConversionFunction'-Assembly, weil die
'ConversionFunction'-Assembly fr PERMISSION_SET = UNSAFE nicht autorisiert
ist. Die Assembly ist autorisiert, wenn eine der folgenden Bedingungen
zutrifft: Der Datenbankbesitzer (DBO) hat die UNSAFE ASSEMBLY-Berechtigung,
und fr die Datenbank ist die TRUSTWORTHY-Datenbankeigenschaft aktiviert;
oder die Assembly ist mit einem Zertifikat oder einem asymmetrischen
Schlssel signiert, das bzw. der einen entsprechenden Anmeldenamen mit der
UNSAFE ASSEMBLY-Berechtigung hat. Wenn Sie diese Datenbank wiederhergestellt
oder angefgt haben, vergewissern Sie sich, dass der Datenbankbesitzer dem
richtigen Anmeldenamen auf diesem Server zugeordnet ist. Wenn dies nicht der
Fall ist, beheben Sie das Problem mit sp_changedbowner."
Meine Überlegung: Muss ich meine SelfMade-Keys am SQL Server nicht "bekannt
machen" damit die DLLS als gültig anerkannt werden?! Sonst könnte ja Jeder
kommen... =:-O
BTW allgemeine Fragen zu CLR-Integration:
1) Wie sind Eure Erfahrungen bzgl. Setup-Integration der CLR-Integration?
Integration^2 :)
2) Wie sind Eure Erfahrungen bzgl. Geschwindigkeitsvorteile durch
CLR-Integration? Sprich: Anwendung führt komplexe Datenoperationen nicht
mehr selbst aus sondern startet SP, wo wiederum für die komplexe Operationen
die eigene CLRs verwendet werden. Kommunikation zw. Anwendung und Server
geht schon mal gegen Null, was bei >1Mill. Datensätze auch viel ausmacht.
Aber wie gut ist SQL Server Inter die Verwendung meiner C#-Methoden gelöst?
Darf man da doch kein Wunder erwarten?
Ciao:
GG ;-)
Günter Prossliner
> entsprechend der Anleitung
> <http://msdn.microsoft.com/de-de/library/ms160866(SQL.90).aspx>
> habe ich Schlüsseldateien erzeugt und meine DLLs damit signiert.
Ok.
> > Der SQL Server behauptet bei der Installation jedoch:
> "Fehler bei CREATE ASSEMBLY fr die 'ConversionFunction'-Assembly,
> weil die 'ConversionFunction'-Assembly fr PERMISSION_SET = UNSAFE
> nicht autorisiert ist. Die Assembly ist autorisiert, wenn eine der
> folgenden Bedingungen zutrifft: Der Datenbankbesitzer (DBO) hat die
> UNSAFE ASSEMBLY-Berechtigung, und fr die Datenbank ist die
> TRUSTWORTHY-Datenbankeigenschaft aktiviert; oder die Assembly ist mit
> einem Zertifikat oder einem asymmetrischen Schlssel signiert, das
> bzw. der einen entsprechenden Anmeldenamen mit der UNSAFE
> ASSEMBLY-Berechtigung hat.
Im Endeffekt steht alles da.
Die Signatur ist in diesem Fall NICHT der Strong-Name, sondern eine
"richtige" Signatur.
Wenn Du den Server kontrollierst - und Deinem Assembly vertraust - es ist
wesendlich einfacher die Datenbank welche das Assembly beinhaltet als
"TRUSTWORTHY" zu markieren:
ALTER DATABASE MyDatabase SET TRUSTWORTHY ON
> Meine Überlegung: Muss ich meine SelfMade-Keys am SQL Server nicht
> "bekannt machen" damit die DLLS als gültig anerkannt werden?! Sonst
> könnte ja Jeder kommen... =:-O
Im Endeffekt wird das über Zertifikate (als Login-Objekte) gesteuert. Aber
wie gesagt: Verwende am einfachsten TRUSTWORTHY. Mit Strong-Names hat das
aber alles nichts zu tun.
> 1) Wie sind Eure Erfahrungen bzgl. Setup-Integration der
> CLR-Integration?
Ich weiss nicht wie die Frage genau gemeint ist. Wie leicht sich Assembly in
der DB ausliefern lassen?
Im Endeffekt ist es einfach: Der SQL-Server hält die Assemblies intern in
seinen Metadaten. Die Datei ansich wird nicht benötigt. Man kann sogar das
Assembly ohne Datei installieren (als BLOB). Du kannst Dir das auch skripten
lassen: Einfach mittels Kontextmenü "Script Assembly as -> CREATE To ->
...".
Für die einzelnen Objekte musst Du das auch noch machen (CREATE PROC xxx
WITH .... AS EXTERNAL NAME ....). Das kann man auch alles scripten.
Solltest Du die DB mittels VS - Deploy erstellt haben, werden noch extended
properties (z.b. "AutoDeployed" gesetzt (mit SP sys.sp_addextendedproperty).
Diese werden für das Debugging / Deployment benötigt bzw. verwendet. In
einer produktiven Installation sind diese i.d.R. nicht notwendig. Auch die
ganzen "ALTER ASSEMBLY ADD FILE FROM 0x.... AS 'xxxxx.cs' sind für die
Ausführung nicht notwendig.
> 2) Wie sind Eure Erfahrungen bzgl. Geschwindigkeitsvorteile durch
> CLR-Integration? Sprich: Anwendung führt komplexe Datenoperationen
> nicht mehr selbst aus sondern startet SP, wo wiederum für die
> komplexe Operationen die eigene CLRs verwendet werden. Kommunikation
> zw. Anwendung und Server geht schon mal gegen Null, was bei >1Mill.
> Datensätze auch viel ausmacht.
Generell gesagt profitiert man klarerweise durch die Lokalität der Daten
(wie immer). Managed Code hat gegenüber von T-SQL (in welchem Du ja eine SP
auch direkt am Server ausführen musst) - neben dem reicheren Befehlssatz /
Bibliotheken - den Vorteil dass dieser nicht interpretiert sonderen (durch
den JIT-Kompiler) kompiliert wird.
Bei vielen Schleifen, Berechnungen, ... ist dieser Effekt durchaus messbar.
Aber: Grundlegene SQL-Statements (also alles was dann der DB-Engine macht),
sind nachwievor reiner SQL-Code (im managed Code ja einfach SqlCommands).
Und die größten Performanceverbesserungen erreicht man in aller Regel durch
das Tuning dieser Commands bzw. durch entsprechendes DB und Index Design.
Wenn Du also von 1 Mio. Datensätzen sprichst (was ja noch nicht so viel ist
;-)), dann bringt es tausendmal mehr diese z.b. anstelle eines Cursors mit
einem einzelnen Statements abzufragen bzw. zu aktualisieren (Stichwort Set
basierte Ausführung). Aber jetzt schweife ich ein wenig aus ...
> Aber wie gut ist SQL Server Inter die
> Verwendung meiner C#-Methoden gelöst? Darf man da doch kein Wunder
> erwarten?
Diese Frage verstehe ich leider nicht. Deine C# Methoden werden (wie in
einer Windows-Anwendung) vom JIT-Kompiler kompilert und unter der Kontrolle
des SQL-Servers (welcher einen speziellen CRL Host implementiert)
ausgeführt. So landen div. low-level Routinen (z.b. Exception Policies, Type
und Assembly-Loading, Threading & Synchronization, ...) im SQL-Server Code
welcher das - ggf. bzw. meist anders wie der Standard CLR Host - behandlet.
Das CLR Team hat in der 2.0 er CLR eine Ganze Menge in flexibles CLR Hosting
investiert (sonst hätte es das SQL-Team warscheinlich niemals genommen ;-)).
OK?
mfg Günter Prossliner
Georg Gungl
Günter Prossliner wrote:
> Aber wie gesagt: Verwende am einfachsten TRUSTWORTHY. Mit
> Strong-Names hat das aber alles nichts zu tun.
ja, dass scheint so zu funktionieren :)
>> 1) Wie sind Eure Erfahrungen bzgl. Setup-Integration der
>> CLR-Integration?
>
> Ich weiss nicht wie die Frage genau gemeint ist. Wie leicht sich
> Assembly in der DB ausliefern lassen?
Ich meinte damit, dass wir einen gangbaren Weg suchen im Rahmen eines
0815-Setups (meineanwendung.msi) am Terminalserver (i.d.R. != SQL-Server)
die CLR-Integration mit zu erledigen. Ok, inzwischen haben wir es anhand des
Beispiels durchgekaut:
1) Die Assemblies müssen am SQL-Server lokal abgelegt werden
2) Installationsskripte müssen gegen DB ausgeführt werden (SMO)
Am Server muss noch CLR-Integration aktiviert sein, dass kann ich im Rahmen
des Setups wahrscheinlich nicht beeinflussen.
>> Aber wie gut ist SQL Server Inter die
>> Verwendung meiner C#-Methoden gelöst? Darf man da doch kein Wunder
>> erwarten?
>
> Diese Frage verstehe ich leider nicht. Deine C# Methoden werden
> (wie in einer Windows-Anwendung) vom JIT-Kompiler kompilert und
> unter der Kontrolle des SQL-Servers (welcher einen speziellen CRL
> Host implementiert) ausgeführt.
Die Speicher- und Cacheverwaltung im SQL Server ist aber auf T-SQL
optimiert.
Wirkt CLR-Integration nicht wie eine Bremse?
Ciao:
GG ;-)
Frank Dzaebel
auch von mir ein paar Anmerkungen
> allgemeine Fragen zu CLR-Integration:
> 1) Wie sind Eure Erfahrungen bzgl. Setup-Integration der
> CLR-Integration? Integration^2 :)
wenn man's einmal gerafft hat, gut. Deployment aufwendiger.
Nach dem allerwichtigsten aber, nämlich dass Du da
Sachen zum einen produktiver machen "kannst" (es kann das
eingängigere C# benutzt werden kann, zum anderen
Dinge, die in SQL nur schwer formulierbar sind, und letztlich
Framework-Klassen benutzt werden können - und Du schliesslich
in SQL oft mit typunsicheren Konvertierungen arbeitest / in C# nicht
... danach hast Du garnicht gefragt (und dabei habe ich einige
Vorteile noch wggelassen ;-).
Ich sage mal ganz schlicht, mit den Infos zu den
"Vorteilen der CLR Integration" haben die MS-Artikel hier Recht:
[Einführung in CLR-Integration für SQL Server]
http://msdn.microsoft.com/de-de/library/ms254498(VS.80).aspx
[Übersicht über die CLR-Integration (Common Language Runtime)]
http://msdn.microsoft.com/de-de/library/ms131089.aspx
Aber: nicht immer ist das auch ein sinnvoller Weg, sondern
nur in gewissen Szenarien.
[Verwendungsszenarien und Beispiele für Common Language Runtime
(CLR)-Integration]
http://msdn.microsoft.com/de-de/library/ms131078.aspx
> 2) Wie sind Eure Erfahrungen bzgl. Geschwindigkeitsvorteile durch
> CLR-Integration?
Kommt drauf an, mit guter aufwändiger Cursor-Programmierung
kannst Du auch sehr performant sein. IMHO werden die
Möglichkeiten von UDTs leicht mal überbewertet.
Man hat eine "potenziell" verbesserte Leistung und
Skalierbarkeit, aber manchmal eben auch nicht.
> Aber wie gut ist SQL Server Inter die Verwendung meiner C#-Methoden
> gelöst? Darf man da doch kein Wunder
> erwarten?
ja, man darf keine "Wunder" erwarten. Aber realistisch
ist IMHO, dass einige der Vorteile zum Tragen kommen.
Gerade neu erschienen:
[SQL Server 2008-Programmierung mit der CLR und .NET von Thorsten Kansy
erschienen bei Microsoft-Press]
http://www.microsoft-press.de/product.asp?cnt=product&id=ms-5436&lng=0
Ansonsten ja auch Praxis-Feedback in Webcasts/CommunityCasts wie:
[SQL-Server 2005 (Teil 2-5) - Die Common Language Runtime [MSDN Webcast]]
http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=118764792
[TechNet Webcast: A SQL Server DBA’s Guide to CLR Integration (Level 300)]
http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032298238&CountryCode=US
[Community Cast zum Thema SQL Server 2005 CLR Integration]
http://www.giza-blog.de/content/binary/Chat_Transkript_CommunityCast_SQLServer2005.pdf
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET