none
Problem beim Entfernen einer Log-Datei aus einer Datenbank RRS feed

  • Frage

  • Hallo

    ich habe bei meiner Datenbank 2 Log-Datei, davon möchte ich eine entfernen...............was aber immer zu einer Fehlermeldung führ - siehe http://bit.ly/hF40Ei

    Interessant ist, dass physisch in dem Datenbank-Ordner die 2. Log-Datei gar nicht mehr vorhanden ist.

    Wie kann ich aus den DB.Eigenschaften die 2. Log-Datei entfernen ??

    Kann mir dazu bitte jemand weiterhelfen.

    Vielen Dank schon mal & schönen Gruß

    Michael

     


    Michael Erlinger
    Samstag, 26. März 2011 14:47

Antworten

  • Hallo Michael,

    Wie bitte hast Du das den hin bekommen?

    Ich habe mal versucht, das nachzustellen und bekomme es (natürlich) nicht hin. Sobald man eine weitere Datei einer DB hinzufügt, ist diese sofort in Verwendung und kann somit auf Dateisystem-Ebene nicht gelöscht werden. Schaltet man die DB Offline, kann man die Datei zwar löschen, ein Online-Schalten schlägt dann aber fehl. Gleiches wenn man den SQL Server beendet, Datei löscht und wieder startet, bei der DB läuft es auf Fehler und die Datenbank wird nicht mehr hochgefahren.

    Kannst Du den auf die Datenbank zugreifen? Stehen im Log Einträge, dass das Log File "vermisst" wird? Ich hatte so eine Meldung im Log erhalten: File activation failure. The physical file name "D:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL105DEV\MSSQL\DATA\LogTest_log2.ldf" may be incorrect.

    Wichtig ist erst mal rauszufinden, ob es wirklich ein Problem gibt, bevor Du etwas weiteres machst. Bitte auch nicht die DB detachen und nur als Single File attachen, das schlägt bei meinem Test fehl; weil es 2 Logfiles geben sollte.

    Und das allerwichtigste, hast Du eine Sicherung, die Du im Notfall restoren könntest?

     


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    • Als Antwort markiert M.Erlinger Montag, 28. März 2011 07:12
    Sonntag, 27. März 2011 11:45
  • Ich haben den Schritt "Rücksicherung" gewählt, und jetzt ist das Problem aus der Welt - Anlass dafür war: es gab eine 3,5 GB große Log-Datei, und in der DB. war Transaction-Log. "Vollständig" eingestellt; jetzt wurde da herumgebastelt, und versucht eine 2. Log-Datei zu erstellen, und die große Log-Datei zu deaktivieren (weil verkleinern hat auch nicht funktion - erst als Transaction-Logging auf "Einfach" gestellt wurde).


    Wenn man das Wiederherstellungsmodel "Vollständig" verwendet, dann sichern man das Log File normlerweise auch regelmäßig und dann wird der Speicherplatz im Log wieder freigegeben und wird dann wiederverwendet; so bleibt das Log File in einer bestimmten Größenordnung.

    Benötigt man das Log File und damit die Möglichkeit auf eine sekundengenauen Zeitpunkt zurückzusichern, dann stellt man das Wiederherstellungsmodel auf "Einfach" ... aber solche Experimente hören sich allein schon gefährlich an ... und testet es vorher ausgiebig mit einer Test DB.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    • Als Antwort markiert M.Erlinger Montag, 28. März 2011 07:12
    Montag, 28. März 2011 07:09

Alle Antworten

  • Hallo Michael,

    Wie bitte hast Du das den hin bekommen?

    Ich habe mal versucht, das nachzustellen und bekomme es (natürlich) nicht hin. Sobald man eine weitere Datei einer DB hinzufügt, ist diese sofort in Verwendung und kann somit auf Dateisystem-Ebene nicht gelöscht werden. Schaltet man die DB Offline, kann man die Datei zwar löschen, ein Online-Schalten schlägt dann aber fehl. Gleiches wenn man den SQL Server beendet, Datei löscht und wieder startet, bei der DB läuft es auf Fehler und die Datenbank wird nicht mehr hochgefahren.

    Kannst Du den auf die Datenbank zugreifen? Stehen im Log Einträge, dass das Log File "vermisst" wird? Ich hatte so eine Meldung im Log erhalten: File activation failure. The physical file name "D:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL105DEV\MSSQL\DATA\LogTest_log2.ldf" may be incorrect.

    Wichtig ist erst mal rauszufinden, ob es wirklich ein Problem gibt, bevor Du etwas weiteres machst. Bitte auch nicht die DB detachen und nur als Single File attachen, das schlägt bei meinem Test fehl; weil es 2 Logfiles geben sollte.

    Und das allerwichtigste, hast Du eine Sicherung, die Du im Notfall restoren könntest?

     


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    • Als Antwort markiert M.Erlinger Montag, 28. März 2011 07:12
    Sonntag, 27. März 2011 11:45
  • Hallo Olaf

    vielen Dank für Deine Rückmeldung und Bemühungen!!

    Ich haben den Schritt "Rücksicherung" gewählt, und jetzt ist das Problem aus der Welt - Anlass dafür war: es gab eine 3,5 GB große Log-Datei, und in der DB. war Transaction-Log. "Vollständig" eingestellt; jetzt wurde da herumgebastelt, und versucht eine 2. Log-Datei zu erstellen, und die große Log-Datei zu deaktivieren (weil verkleinern hat auch nicht funktion - erst als Transaction-Logging auf "Einfach" gestellt wurde).

    Danke & schönen Gruß - Michael


    Michael Erlinger
    Montag, 28. März 2011 06:02
  • Ich haben den Schritt "Rücksicherung" gewählt, und jetzt ist das Problem aus der Welt - Anlass dafür war: es gab eine 3,5 GB große Log-Datei, und in der DB. war Transaction-Log. "Vollständig" eingestellt; jetzt wurde da herumgebastelt, und versucht eine 2. Log-Datei zu erstellen, und die große Log-Datei zu deaktivieren (weil verkleinern hat auch nicht funktion - erst als Transaction-Logging auf "Einfach" gestellt wurde).


    Wenn man das Wiederherstellungsmodel "Vollständig" verwendet, dann sichern man das Log File normlerweise auch regelmäßig und dann wird der Speicherplatz im Log wieder freigegeben und wird dann wiederverwendet; so bleibt das Log File in einer bestimmten Größenordnung.

    Benötigt man das Log File und damit die Möglichkeit auf eine sekundengenauen Zeitpunkt zurückzusichern, dann stellt man das Wiederherstellungsmodel auf "Einfach" ... aber solche Experimente hören sich allein schon gefährlich an ... und testet es vorher ausgiebig mit einer Test DB.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    • Als Antwort markiert M.Erlinger Montag, 28. März 2011 07:12
    Montag, 28. März 2011 07:09
  • Hallo

    danke für die Info!!

    Die Sache läuft noch im Test-Betrieb...............sonst....................

    Schönen Gruß

    Michael


    Michael Erlinger
    Montag, 28. März 2011 07:11