Benutzer mit den meisten Antworten
Verbindungsserver auf sich selbst scheint nicht zu funktionieren

Frage
-
Ich verwende einen Verbindungsserver, um Joins über zwei SQL Server aufzubauen. Für die Abfrage melde ich mich am Server A als Benutzer 1 mit Rechten auf die Datenbank X an. Als Verbindungsserver hat dieser SQL Server einen Eintrag zu Server B mit Benutzer 2/Passwort 2. Der Benutzer 2 hat auf Server B Rechte auf die Datenbank Y. Mit diesem Konstrukt kann ich erfolgreich gejointe Abfragen durchführen.
Nun habe ich die Situation, dass ein Kunde beide Datenbanken X und Y auf dem Server A hat. Der Benutzer 1 hat ebenfalls nur Rechte auf Datenbank X und Benutzer 2 nur auf Datenbank Y. Wenn ich nun einen Join zwischen Tabellen aus Datenbank X und Y erstelle, funktioniert dies weder mit Benutzer 1 noch mit Benutzer 2, was ja auch so gewollt ist.
Der Versuch auch hier einen Verbindungsserver zu definieren, scheint zunächst zu funktionieren, endet aber in der Fehlermeldung: Der Serverprinzipal 'Benutzer 1' kann unter dem aktuellen Sicherheitskontext nicht auf die Datenbank Y-Datenbank zugreifen.
Es scheint also so zu sein, dass bei diesem Szenario der Verbindungsserver (bzw. die Benutzereinstellungen) ignoriert werden.
Gibt es dennoch eine Möglichkeit ohne Änderungen der Rechte der Benutzer hier zum Ziel zu kommen?
TIA Stephan Frigge
P.S.: Probiert habe ich das beschriebene Verhalten in der Version 2008 R2
Antworten
-
Hallo Stephan,
hast Du den Verbindungsserver entsprechend konfiguriert?
Unter der Voraussetzung, dass der Name des Verbindungsservers pvloopback wäre, sollte dieses funktionieren:
USE MASTER GO EXEC sp_addlinkedserver @server = N'pvloopback',@srvproduct = N' ',@provider = N'SQLNCLI', @datasrc = @@SERVERNAME GO EXEC sp_serveroption pvloopback,N'RPC Out','TRUE' Go EXEC sp_serveroption pvloopback,N'remote proc transaction promotion','FALSE' Go
Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu
- Als Antwort markiert Stephan Frigge Montag, 22. August 2016 09:03
Alle Antworten
-
Hallo Stephan,
wenn es auf dem gleichen DB Server ist, benötigst Du meiner Meinung nach gar keinen Verbindungsserver .
Die Abfrage wäre dann:
SELECT *
FROM Datenbankname_X.dbo.Tabellenname
LEFT JOIN Datenbankname_Y.dbo.Tabellenname ON ( ...)Das habe ich mehrfach schon so gemacht, und ist u.a. hilfreich, wenn man Daten_alt und Daten_neu abgleichen möchte.
Voraussetzung ist nur, dass ein (neuer) Benutzer auf beide Datenbank lesende Rechte besitzt - ggfs. ohne Möglichkeiten der Änderungen am Datenbestand, wenn gefordert. Wer die Zugangsrechte für den neuen Benutzer bekommt, kann ja danach festgelegt werden (Benutzer A und/oder Benutzer B, oder jemand ganz anderes, der nur diese übergreifenden Abfragen ausführt).
Schönen Abend.
-
wenn es auf dem gleichen DB Server ist, benötigst Du meiner Meinung nach gar keinen Verbindungsserver .
Hallo Jörg,
vielen Dank für deine Antwort. So wie du es beschreibst, mache ich es jetzt auch.
Ich habe halt gehofft, unsere Software und die Benutzer/-rechte für diesen Fall nicht anpassen zu müssen.
-
Hallo Stephan,
hast Du den Verbindungsserver entsprechend konfiguriert?
Unter der Voraussetzung, dass der Name des Verbindungsservers pvloopback wäre, sollte dieses funktionieren:
USE MASTER GO EXEC sp_addlinkedserver @server = N'pvloopback',@srvproduct = N' ',@provider = N'SQLNCLI', @datasrc = @@SERVERNAME GO EXEC sp_serveroption pvloopback,N'RPC Out','TRUE' Go EXEC sp_serveroption pvloopback,N'remote proc transaction promotion','FALSE' Go
Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu
- Als Antwort markiert Stephan Frigge Montag, 22. August 2016 09:03
-
Du musst natürlich auch bei dem Verbindungsserver sagen, mit welchem anderen Benutzer dieser Account durchgreifen soll.
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'pvloopback',@useself=N'False',@locallogin=N'Benutzer1',@rmtuser=N'Benutzer2',@rmtpassword='geheim'
HTH!
Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu
- Bearbeitet Christoph Muthmann Montag, 22. August 2016 07:47
-
EXEC sp_serveroption pvloopback,N'RPC Out','TRUE'
Mit dieser Option funktioniert es genau so wie ich es haben wollte. Besten Dank!
EXEC sp_serveroption pvloopback,N'remote proc transaction promotion','FALSE'
Für ein reines Select spielt diese Option keine Rolle (Funktioniert sowohl mit Einstellung FALSE als auch TRUE). Soweit ich die Doku verstehe, ware es aber bei Schreibvorgängen besser diese Option auf TRUE zu setzen, oder sehe ich das falsch? Gibt es nennenswerte Geschwindigkeitsunterschiede, wenn MS DTC eingeschaltet wird?
Nochmals vielen Dank!
Stephan
- Als Antwort vorgeschlagen Christoph Muthmann Montag, 22. August 2016 09:09
- Nicht als Antwort vorgeschlagen Christoph Muthmann Montag, 22. August 2016 09:09
-
Die letzte Option brauchst Du wahrscheinlich nicht, da Du keine remoten Prozeduren aufrufst. Geschwindigkeitsunterschiede dürften auch da nicht relevant sein.
Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu