Ändern des Datenbankeigentümers in SQL Server 2008; CLR-Probleme je nach verwendeter Methode?


7

Ich habe eine Datenbank angehängt und versucht, den Eigentümer in ein gültiges Login zu ändern.

Ich habe die Anweisung verwendet: ALTER AUTHORIZATION ON database :: my_db_name TO "sa". Die Datenbankeigenschaften zeigten, dass der neue Eigentümer "sa" war. Es wurden jedoch weiterhin Berechtigungsfehler für uneingeschränkte CLR-Assemblys (0x80FC80F1, 0x8013150A) angezeigt.

Ich habe das Problem behoben, indem ich stattdessen die folgende Anweisung verwendet habe: EXEC sp_changedbowner 'sa'; um den Datenbankeigentümer zu ändern.

Meine Frage ist, was ist der Unterschied zwischen diesen beiden Methoden zum Ändern des Datenbankeigentümers. Sind sie gleichwertig? Mir scheint klar zu sein, dass sp_changedbowner etwas mehr / Richtiges tut, was die Änderung der Berechtigungsanweisung nicht tut.


Falls Sie interessiert sind ... bevor ich Dinge mit sp_changedbowner reparierte, habe ich versucht:

  • Setzen der vertrauenswürdigen Eigenschaft der Datenbank auf EIN; Tatsächlich habe ich das ein paar Mal gemacht. Ich weiß, dass es eine Anforderung ist, uneingeschränkte, nicht signierte 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 in SSMS ist es einfach immer leer.
  • Ändern des Besitzers jeder CLR-Assembly in etwas anderes, aber das funktioniert nicht, da Assemblys mit abhängigen Assemblys anscheinend immer denselben Eigentümer benötigen. Es ist jedoch unmöglich, den Eigentümer auf beiden mit der bereitgestellten Schnittstelle gleichzeitig zu ändern.
  • Aufruf von GRANT UNSAFE ASSEMBLY an [sa]; Anscheinend können Sie diesem integrierten Konto zusammen mit einigen anderen keine Berechtigungen erteilen. Sie haben bereits die Erlaubnis
  • Aufruf von GRANT UNSAFE ASSEMBLY an [NT AUTHORITY \ NETWORK SERVICE] (die Kontoaufrufmethoden in den Assemblys); Keine Fehler, aber anscheinend nichts erreicht (möglicherweise die Fehlernummer geändert? Die Meldung hat sich jedoch nie geändert).
  • ... und wahrscheinlich ein paar andere Dinge, an die ich mich nicht erinnern kann.

Antworten:


3

Auf Ihrer Liste sehe ich das Einrichten der Datenbank nicht als vertrauenswürdig an, daher gehe ich davon aus, dass Sie diesen Schritt vergessen haben:

ALTER DATABASE my_db_name SET TRUSTWORTHY ON;

Aber vielleicht auch nicht ...

Überprüfen Sie mit diesem Artikel: http://support.microsoft.com/kb/918040 es scheint, dass sie tatsächlich empfehlen, sp_changedbowner anstelle von ALTER AUTHORIZATION zu verwenden. Tatsache ist jedoch, dass es genau das Gleiche tut (sp_changedbowner ruft ALTER AUTHORIZATION unter der Decke auf). Der Unterschied besteht darin, dass auch "Aliase" für den dbo-Benutzer entfernt werden (ohnehin veraltete Funktionalität) und ein Prüfpunkt der Datenbank erzwungen wird. Das letzte Stück könnte das sein, das Sie suchen.


Die Vertrauenswürdigkeit war eigentlich der erste Punkt auf der Liste der Dinge, die ich versucht habe (siehe noch einmal) ... aber der von Ihnen gepostete Link beschreibt das Problem gut und scheint die Ursache zu identifizieren. Es muss etwas damit zu tun haben, dass die Anmeldungen nicht richtig eingerichtet sind. Ich dachte, ich hätte sie alle mit Konten auf dem neuen Server verknüpft, aber vielleicht dauerte es in der Mischung der Dinge nur eine Weile, bis alle erforderlichen Schritte abgeschlossen waren.
Triynko

4

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

Das von Ihnen angegebene Verhalten klingt jedoch sehr seltsam. Können Sie es replizieren?


Ich werde versuchen, das Problem zu replizieren, aber erst heute, wenn ich sicher bin, dass keine Tests dagegen ausgeführt werden.
Triynko
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.