Announcement

Collapse
No announcement yet.

Log für Queries auf MSSQL Server2005

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

  • Log für Queries auf MSSQL Server2005

    Hallo Leute,

    ich bin mitlerweile völlig am Ende meines Lateins.
    Ich soll für ein Programm, dass Änderungen an einer Datenbank vornimmt, auslesen auf welche Tabellen dieses Programm zugreift bzw. welche Tabellen geändert werden. Das Programm macht unter anderem neue Spalten, löscht Spalten und erzeugt auch neue Tabellen.

    Ich habe schon versucht über das MS SQL SERVER MANAGEMENT 2005 etwas zu machen aber ich kann dort einfach nichts finden was mich zufrieden stellt.

    MfG

    PatrickG

  • #2
    Dann solltest du dir mal die DDL-Trigger ansehen. Man kann damit aber nur Änderungen erfassen, ein reines SELECT erwischt man damit nicht (und mir ist auch keine Möglichkeit bekannt, wie sowas überhaupt gehen könnte).

    bye,
    Helmut

    Comment


    • #3
      Danke für den Tipp.
      Nun habe ich aber ein Problem. Ich kann dem Trigger ja nur sagen er soll auf eine spezielle Tabelle achten. Ich bräuchte aber eine gesamtumfassende Lösung da ich ja nicht für jede Tabelle einen Trigger schrieben möchte, das sind einfach zu viele.
      Gibt es denn eine Möglichkeit, das für die Datenbank ein Trigger geschrieben wird und der mir dann ausgibt auf welcher Tabelle was passiert und im optimalen Fall das ganze dann noch in eine Textdatei ausgibt?
      Ich kenne mich da leider nicht aus und auf den Infoseiten von MS steht auch nicht viel hilfreiches.

      Comment


      • #4
        Du könntest mit dem SQL Server Profiler der Teil des Management Studios ist (ab welcher SKU weiß ich nicht aber bestimmt nicht bei einer Express Version) einfach jedes SQL das die betroffene Anwendung an die Datenbank sendet loggen und dann das Logfile oder die Logtabelle auswerten.

        Wenn es dir nur um Daten und Schemaänderungen geht wäre auch ein Auswerten des Transaktionslog mit einem speziellen Viewer möglich. Z.B. das hier.

        Comment


        • #5
          Also für den DDL-Trigger hab ich was Datenbankübergreifendes gefunden.
          Siehe hier.
          Nur mein Problem besteht weiterhin, dass ich nicht weiß was in der Tabelle gemacht wird.
          Der Viewer ist wesentlich zu teuer und der Profiler kann nicht verbinden.
          Hab mich nun dazu durchgerungen meine Trigger vorzudefinieren und in Talend schließlich auf die Tabellen zu definieren...

          Aber vielen Dank für eure Hilfe.

          Comment


          • #6
            Wenn du selbst ein SELECT genau protokollieren willst, kannst du nur eines machen: du sperrst den direkten Zugriff auf alle Tabellen und lässt alles nur mehr über stored procedures laufen. Da kannst du dann den Benutzer, das Statement, Datum/Zeit und meinetwegen sogar das Ergebnis in deinem eigenen Log speichern. Aber das ist viel Aufwand, der SQL-Server hat standardmäßig sowas nicht vorgesehen.

            bye,
            Helmut

            Comment


            • #7
              Hallo PatrickG,

              der SQL Server verfügt seit Version 2000 über den zertifizierten C2 Audit Mode, der alle Zugriff inkl. fehlgeschlagener protokolliert.
              Siehe auch: C2 Level Auditing with SQL Server
              Nur glaube ich nicht, das Du damit glücklich wirst, den das erzeugt Massen an Protokoll-Daten und der SQL Server ist bald mehr mit dem Log beschäftigt als mit seiner eigentlichen Aufgabe.

              Mich wundert aber auch etwas Dein Ansatz. Wenn ich das richtig verstehe, erfolgt jeder Zugriff doch eh über euer eigenes Programm und das weiß ja nun selbst am besten, wann was geändert oder bloss selektiert wird.
              Warum lasst ihr nicht euer Programm selbst alles (selektiv) protokollieren?
              Olaf Helper

              <Blog> <Xing>
              * cogito ergo sum * errare humanum est * quote erat demonstrandum *
              Wenn ich denke, ist das ein Fehler und das beweise ich täglich

              Comment


              • #8
                hallo, SQL Examiner und bei Daten ggf. SQL Data Examiner. Setzt allerdings voraus das man einen vorher und einen Nachher (kann die eigentliche Datenbank sein) Stand hat. Daraus kann das Tool Differenz-Angleich-Skripte erstellen. Der Vergleich kann auch direkt mit einem nicht eingehängten bak-File gemacht werden.

                Comment


                • #9
                  Problem ist dabei nur, dass man zwar die Differenz feststellen kann, aber nicht, wer es war und wann das passiert ist. Aber vielleicht braucht das der Fragesteller eh nicht, falls nur ein Programm darauf zugreift und der Zeitpunkt egal ist.

                  bye,
                  Helmut

                  Comment


                  • #10
                    So nachdem ich nun schon eine Weile Urlaub hatte und mich das ganze GAR NICHT interessiert hat, hab ich nun den etwas umständlicheren Weg gemacht.
                    Hab mir meine SQL Query in TOS (Talend Open Source) zusammengebaut und als Trigger in jede Datenbank geschrieben.
                    Dennoch danke für die hilfreichen Antworten. Werd auf jeden Fall wieder hierher zurückkommen falls andere Probleme kommen sollten.

                    @O.Helper
                    Ja erfolgt er, aber das Programm umzuschreiben bzw. die Einträge nachzutragen wäre ein rießen Aufwand. Auch wenn man es von Anfang an hätte machen sollen bzw in einer Doku festhalten hätten sollen.

                    Comment

                    Working...
                    X