Announcement

Collapse
No announcement yet.

Ausnahme beim Ausführen einer Transact-SQL-Anweisung

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ausnahme beim Ausführen einer Transact-SQL-Anweisung

    Hallo zusammen,

    ich verbinde mich über eine Windows-Anwendung mit einem SQL-Server als SA (Sys-Admin). Nun möchte über das Server-, Backup-, bzw. Restore-Objekt verschiedene Aktionen durchführen. Teilweise ist dies kein Problem (z.B. alle Datenbanken des Servers anzeigen,...), jedoch bei manchen Befehlen kommt folgende Fehlermeldung:
    "Ausnahme beim Ausführen einer Transact-SQL-Anweisung oder eines Transact-SQL-Batches."
    Dies ist z.B. der Fall bei:
    MyRestoreObject.ReadFileList(MyServerObject)

    Sind hierzu erweiterte Rechte notwendig? Dachte als SA hätte ich alle nötigen Rechte...

    Danke schon mal für eure Hilfsbereitschaft - auch wenn ihr nicht helfen könnt...

    Liebe Grüße,
    SanDee

  • #2
    Hallo,

    Dachte als SA hätte ich alle nötigen Rechte...
    die effektiven Rechte hängen davon ab, unter welchem Dienst-Benutzerkonto der Prozess des SQL Servers ausgeführt wird. Es ist verständlich, dass Microsoft aufgrund der Erfahrungen der Vergangenheit dafür gesorgt hat, dass ein "geknackter" SQL Server nicht mehr als Brechstange im Betriebssystem verwendet werden kann ;-)

    Die erfolgreiche Anmeldung als sa bedeutet nur, dass man im Hoheitsbereich des SQL Servers der Chef ist. Sobald jedoch auf externe Ressourcen des Servers (die von Windows kontrolliert werden) zugegriffen werden soll, hängen die Rechte vom Prozesskonto ab.

    Ein SQL Server Principal ist ein Benutzerkonto, das Windows (genauer gesagt, der Domänenautorität) unbekannt ist. Solange alle Zugriffe innerhalb des SQL Servers bleiben, spielt dieser Unterschied keine Rolle. Sobald jedoch ein SQL Server Principal auf eine Ressource außerhalb des SQL Servers zugreifen soll, muss das Betriebssystem die Berechtigungen des Benutzers prüfen können. Der SQL Server 2005 stellt daher mit der CREATE CREDENTIAL-Anweisung erstmals die Option zur Verfügung, ein SQL Server Principal an ein bereits vorhandenes Windows Principal zu binden. Wenn dann der Benutzer nach der Anmeldung mit dem SQL Server Principal auf eine externe Ressource zugreift, erfolgt dies mit den Rechten des zugeordneten Windows Principals. Allerdings sollte man gründlich überlegen, bevor die Sicherheitsabschottung derart gelockert wird!

    Comment


    • #3
      Hallo Andreas,

      Danke für die Info... Wie sieht das ganze denn aus, wenn ich in meinem Netz nun verschiedene Versionen des SQL Servers habe und es mit keiner Version funktioniert?

      Es ist verständlich, dass Microsoft aufgrund der Erfahrungen der Vergangenheit dafür gesorgt hat, dass ein "geknackter" SQL Server nicht mehr als Brechstange im Betriebssystem verwendet werden kann ;-)
      Das klingt ja, als ob es mit älteren Versionen noch möglich war, auf Dateien des Rechners zuzugreifen. Aber irgendwie haut das bei mir überhaupt nicht hin...

      Na ja, werde wohl meine Pläne ändern und eben vorraussetzen, dass Backups im Backup-Ordner liegen usw. - und falls sie sich doch irgendwoanders befinden, muss man eben von jenem (SQL Server-) Rechner aus agieren.

      Also dann, einen schönen Tag noch,
      Sandra

      Comment


      • #4
        Hallo,

        Das klingt ja, als ob es mit älteren Versionen noch möglich war, auf Dateien des Rechners zuzugreifen....
        genau so war es leider auch. In älteren MS SQL Server-Versionen war die Systemprozedur xp_cmdshell in der Voreinstellung scharf und für das Konto sa wurde kein Passwort erzwungen. Die Folgen sind bekannt...

        ..und eben vorraussetzen, dass Backups im Backup-Ordner liegen usw...
        Der MS SQL Server speichert die Backup-Historie in seinen Systemtabellen:
        msdb.dbo.backupfile, msdb.dbo.backupmediafamily, msdb.dbo.backupmediaset und msdb.dbo.backupset. Man kann somit zumindest über den SQL-Weg nachsehen, ob ein aktuelles Backup vorliegt:

        Code:
        SELECT db.name AS [Database], max(backup_finish_date) AS [LastBackupDate] 
        FROM [master].[dbo].[sysdatabases] db 
          LEFT OUTER JOIN [msdb].[dbo].[backupset] bs 
            ON bs.database_name = db.name AND bs.type = 'D' 
        GROUP BY db.name 
        ORDER BY db.name
        Zuletzt editiert von Andreas Kosch; 15.02.2007, 19:35.

        Comment


        • #5
          jetzt hänge ich am "Wiederherstellungsstatus"

          Hallo und vielen Dank für die Antworten,

          auf die Systemdatenbanken (genauer: die DB 'msdb') bin ich inzwischen auch gekommen und lese von dort auch meine Backupsets aus.

          Jetzt tritt nach dem Restore der Fehler auf, dass sich die Datenbank im "Wiederherstellungsstatus" befindet und ich nicht mehr darauf zugreifen kann. Eigentlich dachte ich, dieses Problem sei mit der Anweisung 'myRestoreObject.norecovery = false' gelöst, aber leider ist dies nicht der Fall.

          Des Weiteren ist die DB nach einem "Shrink" exklusiv geöffnet und somit für manche Funktionen ebenfalls gesperrt.

          Sorry, wenn ich blöde Fragen stelle... Bin halt ein totaler Frischling auf diesem Gebiet.

          Liebe Grüße,
          Sandra

          Comment

          Working...
          X