Admin-Nutzer in DB soll Admin nach Restore einer fremden DB bleiben

[wos 0]

Guten Tag,

 

wir haben hier die fixe Idee gehabt, dass man auf einem MS SQL Server, einigen Nutzern ein Login geben kann und diese haben dann dort innerhalb der ihnen zugewiesenen DB Admin Rechte. Das funktioniert soweit ja auch. Der Gedanke der dahinter steckt, ist dass jeder dieser Nutzer jeweils eine DB am Server hat, mit der er alles können soll, dort quasi Vollzugriff hat. Eigentlich eine Art Hülle, die mit verschiedenen DBs bei Bedarf gefüllt werden kann.

 

Das Problem fängt an, wenn eine DB durch eine andere ersetzt werden soll. Zunächst wollt SQL Server noch das Recht DBCREATOR haben, damit innerhalb der eigenen DB Hülle (in der man bereits/noch Admin ist), dort eine andere DB von einem anderen Server wiederherstellen kann. Das gelingt soweit auch, aber unmittelbar nach dem Wiederherstellen, hat man dann auf diese DB kein Recht mehr. Dort ist in der DB naturgemäß natürlich auch nicht der Nutzer (SQL Anmeldung) enthalten, über den auf diese zugegriffen werden kann.

 

Wie löst man das? Ich will "einfach" eine Möglichkeit schaffen, wo verschiedene Supporter auf "ihre" DB zugreifen können, diese auch immer wieder überschreiben dürfen und dort dann auch im Anschluss noch arbeiten dürfen, ohne das ein dritter gefragt werden muss, der das Recht dann gibt ... ich hoffe man versteht die Intension dahinter.

 

Danke und Gruß

[q617 1]

Ja

[Nobbyaushb 1.471]

Den User q617 einfach ignorieren - das ist der Foren-Troll

 

Zu deinem Problem - wenn es in der importierten Datenbank diesen User nicht wüsste ich auf die Schnelle keine Lösung 

Aber hier gibt es genug SQL Spezis

[t-sql 18]

Eigentlich wird ja beim Restore immer das Login des Wiederherstellers als Datenbankbesitzer (nicht zu verwechseln mit der db_owner Rolle) eingetragen. Dann haste eh immer volle Rechte auf die Datenbank. Schau mal nach was beim Owner nach dem Restore drin steht.

 

[cj_berlin 1.313]

Moin,

bei einem Kunden haben wir das nach langen Diskussionen mit mehreren Instanzen gelöst, wo das betreffende Team zwar nicht sa, aber immerhin db_creator hatte. Es waren aber nur drei Dev teams plus Produktion, da geht es. Hast Du zwanzig solche User oder Teams, wird es nicht mehr händelbar.

[t-sql 18]

vor 1 Stunde schrieb cj_berlin:

aber immerhin db_creator hatte.

Und mehr ist auch gar nicht nötig.

[zahni 554]

Ganz verstanden habe ich es nicht. Wenn man eine DB mit einem SQL-User (SQL-Anmeldung) versetzt (auf einen anderen Server), muss man 1x 'sp_change_users_login 'AUTO_FIX', 'MYUSER'' ausführen. Natürlich muss es auf dem Server einen Konto mit dem gleichen Namen geben. 

 

[wos 0]

Hallo und erst mal Danke für die vielen Antworten!

 

@Nobbyaushb:
Na, mindestens einen verwirrten gibts immer ...

 

@t-sql:
Bin mir nicht sicher, ob ich das recht verstehe. Bei SQL DBs ist mir bisher noch nirgendwo das Stichwort "Besitzer" untergekommen. Die Begrifflichkeit würde ich eher in den Windows Dateirechen vermuten wollen. Aber scheinbar gibts lt. Google wirklich sowas wie eine Besiter der DB, man lernt nie aus. Und im Management Studio wird der angezeigt (in den Optionen der DB), mit dem ich ursprünglich mal die Sicherung gemacht habe (dem Admin mit seinem Windows Anmeldenamen in Form domäne\benutzername). Wenn dass das Problem ist, dann würde das schlicht unmöglich sein, denn die Datenbanken die am SQL eingehängt werden, sind ausnahmslos von unseren Kunden und der Besitzer dort dementspr. immer ein anderer (und nie derjenige Supporter von uns der so eine DB einhängen möchte). Oder anders herum gesagt, ist der Nutzer der da immer volle Rechte haben will, nie einer von uns selbst.

 

Dann hattest Du noch eine Bemerkung gemacht in Bezug auf den DB_CREATOR "Und mehr ist auch gar nicht nötig". Das ist prinzipiell richtig, so kann man die DB herstellen. Aber ab dem Moment ist auch Schluss. Mit der Widerherstellung verliest man augenblicklich die Berechtigung auf die DB zuzugreifen, wie ich eingangs geschrieben habe. Dann wollen die Kollegen wieder bei mir antanzen, aber ich will eigentlich nichts damit zu tun haben, deren Spielumgebung ... das sollen die schön alleine machen. So mein Wunsch zumindest.

 

@cj_berlin:
Ihc bin mir nicht sicher (wie kann man sich jemals beim MS Lizenzdschungel überhaupt sicher sein), aber wenn ich eine 2. Instanz installiere, dann dürfte damit auch ein weiterer SQL Server zu lizenzieren sein?! Damit würde das ausscheiden, nur für den Zweck auch nur einen Cent auszugeben. Oder habe ich da vielleicht durchaus was falsch verstanden?

 

@zahni:
Das Problem ist, dass ein entspr. berechtigter Nutzer, das für denjenigen, der die DB eingehangen will, dann machen muss. Es würde mich sehr wundern, wenn sich derjenige die Rechte geben kann, die ihm fehlen. Da die DBs von Kunden kommen, kann da auch keiner unserer Mitarbeiter als Benutzer irgendwo eingetragen sein.

 

Merke schon, ein einfacher Gedanke, ein einfacher Wunsch, stellt sich dann doch wesentlich komplexer dar, diesen technisch auch umzusetzen. Bin mir gar nicht sicher, ob das überhaupt geht, was ich mir vorstelle.

[cj_berlin 1.313]

vor 18 Minuten schrieb wos:

Ihc bin mir nicht sicher (wie kann man sich jemals beim MS Lizenzdschungel überhaupt sicher sein), aber wenn ich eine 2. Instanz installiere, dann dürfte damit auch ein weiterer SQL Server zu lizenzieren sein?! 

Hier kannst Du dir sicher sein: eine 2. Instanz auf derselben Windows-Maschine ist von derselben Lizenz abgedeckt wie die erste.

vor 21 Minuten schrieb wos:

Bin mir gar nicht sicher, ob das überhaupt geht, was ich mir vorstelle.

Doch, mit mehreren Instanzen geht das. Die Anzahl der Instanzen muss aber halt noch managebar bleiben...