Datenbankbesitzer in SQL Server 2008 ändern; CLR-Probleme abhängig von der verwendeten Methode?

Datenbankbesitzer in SQL Server 2008 ändern; CLR-Probleme abhängig von der verwendeten Methode?

Ich habe eine Datenbank angehängt und versucht, den Besitzer in einen gültigen Login zu ändern.

Ich habe die Anweisung ALTER AUTHORIZATION ON database::my_db_name TO "sa" verwendet. Die Datenbankeigenschaften zeigten, dass der neue Besitzer "sa" war, ich erhielt jedoch immer noch Berechtigungsfehler für uneingeschränkte CLR-Assemblys (0x80FC80F1, 0x8013150A), etwas wegen Problemen mit der Assemblyvertrauensstellung.

Ich habe das Problem gelöst, indem ich stattdessen die Anweisung „EXEC sp_changedbowner 'sa';“ verwendet habe, um den Datenbankbesitzer zu ändern.

Meine Frage ist, was der Unterschied zwischen diesen beiden Methoden zum Ändern des Datenbankbesitzers ist. Sind sie gleichwertig? Mir scheint klar, dass sp_changedbowner mehr/korrekter macht als die Anweisung „alter authorization“.


Falls es Sie interessiert ... bevor ich die Dinge mit sp_changedbowner behoben habe, habe ich Folgendes versucht:

  • Setzen der vertrauenswürdigen Eigenschaft der Datenbank auf ON; tatsächlich habe ich das ein paar Mal gemacht; ich weiß, dass es eine Voraussetzung ist, um uneingeschränkte, unsignierte benutzerdefinierte CLR-Assemblys auszuführen
  • Ändern des Besitzers jeder CLR-Assembly in dbo, da der Besitzer leer war, aber anscheinend war dbo bereits der Besitzer und es ist in SSMS einfach immer leer.
  • Ändern des Besitzers jeder CLR-Assembly in etwas anderes, aber das funktioniert nicht, da Assemblys mit abhängigen Assemblys scheinbar immer den gleichen Besitzer benötigen; mit der bereitgestellten Schnittstelle ist es jedoch unmöglich, den Besitzer beider Assemblys gleichzeitig zu ändern.
  • Aufruf von GRANT UNSAFE ASSEMBLY für [sa]; anscheinend können Sie diesem integrierten Konto und einigen anderen keine Berechtigungen erteilen; sie haben bereits die Berechtigung
  • Aufruf von GRANT UNSAFE ASSEMBLY für [NT AUTHORITY\NETWORK SERVICE] (das Konto, das Methoden in den Assemblys aufruft); keine Fehler, hat aber scheinbar auch nichts bewirkt (vielleicht habe ich die Fehlernummer geändert? Die Meldung hat sich jedoch nie geändert).
  • ... und wahrscheinlich noch ein paar andere Dinge, an die ich mich nicht erinnern kann.

Antwort1

Bei deiner Liste halte ich die Einrichtung der Datenbank für nicht vertrauenswürdig, daher nehme ich an, dass du diesen Schritt vergessen hast:

ALTER DATABASE my_db_name SET TRUSTWORTHY ON;

Aber vielleicht nicht …

Prüfen Sie mit diesem Artikel:http://support.microsoft.com/kb/918040es scheint, dass sie tatsächlich die Verwendung von sp_changedbowner anstelle von ALTER AUTHORIZATION vorschlagen. Tatsächlich macht es aber genau dasselbe (sp_changedbowner ruft im Hintergrund ALTER AUTHORIZATION auf). Der Unterschied besteht darin, dass es auch „Aliase“ für den dbo-Benutzer entfernt (ohnehin veraltete Funktionalität) und einen Checkpoint der Datenbank erzwingt. Dieser letzte Teil ist möglicherweise der, nach dem Sie suchen.

Antwort2

Ich glaube , ALTER_AUTHORIZATIONund sp_changedbownerbeide können den Besitz des Datenbankobjekts ändern. Der Unterschied zwischen den Befehlen besteht natürlich darin, dass ALTER_AUTHORIZATIONandere Dinge geändert werden können (wie der Besitz von Tabellen), während sp_changedbownernur der Eigentümer der Datenbank geändert werden kann.

Das von Ihnen beschriebene Verhalten klingt allerdings sehr merkwürdig. Können Sie es reproduzieren?

verwandte Informationen