MS SQL2000 Transaktionlog

[slowjoe 10]

Hallo,

 

hab ein Problem mit meinem sql Server. Meine Datenbank ist auf 46GB gewachsen und mein Transaktionslog auf mehr als 68GB.

Ich hatte das immer so verstanden, dass wenn eine vollständige Sicherung (backup database "datenbankname" to "sicherungsmedium" geschrieben wird das Transaktionsprotokoll gelöscht wird (zumindest bis zu dem Zeitpunkt der Sicherung) Dies geschieht jedoch nicht.

 

Irgendwer ne Idee hierzu??

 

mfg

c

[weg5st0 10]

Du musst auch eine Sicherung der Logs machen, damit diese abgeschnitten werden:

How to stop the transaction log of a SQL Server database from growing unexpectedly

[phoenixcp 10]

Durch das Backup wird das File nicht gelöscht, sondern nur der Platz in dem bereits allokierten File wieder freigegeben. Was du dann noch tun musst ist, shrinken. Und das möglichst Fileweise. Erst das Transaktionslog, danach die DB.

 

Machst du das alles händisch oder hast du einen Wartungsplan dafür?

[slowjoe 10]

Nö ich mach das alles händisch,

 

also im Moment noch. Hab hier in ner Firma angefangen und da gabs gar keine sicherung und das seit 5 Jahre. Krasse Sache. Hab dann halt einfach ne Vollsicherung jede Nacht und alle 2 Stunden ne differentielle gemacht. Allerdings bin ich auch recht neu auf dem Gebiet.

 

Hab ich das jetzt richtig verstanden, wenn ich also das backup log ...... mache, dann kürzt er automatisch das transaktionslog??

Die Datenbank steht auf automatisch verkleinern, oder muss ich da noch mehr einstellen??

 

 

mfg

slowjoe

[weg5st0 10]

Nö - Du mußt shrinken:

INF: Shrinking the Transaction Log in SQL Server 2000 with DBCC SHRINKFILE

[slowjoe 10]

Hallo,

 

kann ich das transaktion log shrinken (shrinkfile) während meine user weiter online mit der db verbunden sind und arbeiten??

mfg

slow

[phoenixcp 10]

Ja kannst du. Unter Umständen werden sich leichte Performanceeinbussen bemerkbar machen, aber ansonsten kann weiter gearbeitet werden und eine Umschaltung in den SingleUserMode ist nicht notwendig.

[slowjoe 10]

danke für die schnelle antwort

 

 

mfg

slow

[slowjoe 10]

Hallo,

 

hab noch eine freage bezügl. der shrinkfile funktion.

 

dbcc shrinkfile ("transakt datei",targetsize);

 

Laut sql online dokumentation muss targetsize nicht angegeben werden, jedoch bringt er mir dann immer einen Fehler (Syntaxfehler), wenn ich einen Wert angebe, dann läuft das ganze (in der testdb ausprobiert).

Da ich aber die Ursprungsgröße der Transaktonsprotokolldatei nicht kenne weiss ich nicht was ich hier als Größe eingeben soll.

 

Wo finde ich denn die ursprüngliche Größe der Transaktionsprotokolldatei.

 

für Hilfe wie immer dankbar

 

mfg

slow

[phoenixcp 10]

Die ursprüngliche Größe wirst du nirgendwo finden, da es immer davon abhängt wieviele Transaktionen er aus dem Log wegschneiden kann. Was du machen kannst: Versuch dich Schritt für Schritt nach vorne zu tasten, in dem erstmal mit nem Viertel der aktuellen Größe anfängst und dann in 50 % Schritten weiter, bis nix mehr passiert. Das solltest du ein paar Tage machen und beobachten, auf welcher Größe sich dann das Transaktionslog nach unten hin einpegelt und ein Stück darüber ansetzen,wenn du das ganze automatisierst, da sicher die DB auch weiterhin wachsen wird und damit auch das Grundgerüst des Transaktionslogs größer werden wird.

[slowjoe 10]

Jo,

 

danke. Habs jetzt wieder kleiner. Na von knappen 80 GB auf 4 :) das ist doch schonmal was.

Hab mal auf verdacht eingegeben und jetzt läufts.

So dann werd ich mich jetzt mal an eine vernüftige Planung setzen.

Danke erstmal soweit.

 

mfg

slow

[phoenixcp 10]

Na also, ein zwanzigstel klingt doch schonmal richtig gut.... Viel Erfolg bei der Maintainanceplanung.

[slowjoe 10]

sers,

 

so bin jetzt mal ein bissl am rumtesten hier um die gemachten backups auch mal zurückzuspielen, aber Problem.

1. mal "MS Sql Server in 21" irgendwie geschehen seltsame Dinge.

Ne im Ernst:

 

Ich habe jetzt vollsicherung meiner produktivdatenbank gemacht und würde gerne selbige wiederherstellen und zwar auf einem anderen Server. Denn darum gehts ja wohl im Falle eines Serverausfalls.

Allerdings bringt er mir dann die Fehlermeldung ich müsste die Option with norecovery angeben.

(Soll Beispielsweise wiederhergestellt werden als neue Datenbank in neuem verzeichnis mit anderem namen auf neuem server).

Aber so groß ist ja die Auswahl nicht was der Enterprise Manager bietet und egal welche der Optionen ich auswähle (datenbank weiter ausführen oder datenbak nicht weiter ausführen oder datenbank im schreibgeschützten Modus ausführen) immer bringt er die Fehlermeldung ich solle die Option with norecovery nutzen.

 

Im Querryanalyzer bringt er auf folgendes statement:

 

restore database handyman from "c:\datenbank\handyman.bak" with file = 1, move 'handyman' to 'C:\datenbank\handyman.mdf',recovery;

 

diesen Fehler:

Server: Nachr.-Nr. 3206, Schweregrad 16, Status 1, Zeile 1

Kein Eintrag in sysdevices für das Sicherungsmedium 'c:\datenbank\handyman.bak'. Aktualisieren Sie sysdevices, und führen Sie die Anweisung erneut aus.

Server: Nachr.-Nr. 3013, Schweregrad 16, Status 1, Zeile 1

RESTORE DATABASE wird fehlerbedingt beendet.

 

Na klar gibt es noch keinen Eintrag in der sysdevice, ist ja auch ein neuer Server. Aber dort laufen ja auch andere Datenbanken drauf, ergo kann ich ja nicht einfach die Master vom alten Server hier wieder herstellen.

 

In dem Superbuch wird leider nichts hierüber erwähnt, bei denen klappt des dann, bei mir halt nicht.

 

Das ganze ist übrigens ein ms sqlserver 2000.

 

Gibbt es kein vernünftiges Tutorial welches sowas erklärt, oder kann mir jemand ein Buch nennen in dem man nachschlagen könnte?

 

wie immer dankbar

 

mfg

slow

[phoenixcp 10]

Ok, erstmal ganz langsam. Du willst die DB auf Server A backuppen und auf Server B wieder einspielen?

 

Ich geh da folgendermaßen vor:

Ich drehe bei Restore die Pfade der Files (DB und Logfile) zurecht (da die sich ja von Server zu Server unterscheiden) und setze die folgenden Optionen: "Force restore over existing database" und "Leave database operational".

 

Was dabei Vorraussetzung sein kann / muss (da bin ich mir grade nicht zu 100 % sicher): Die beiden Server, bzw. die beiden Datenbanken müssen diesselbe Collation haben, ansonsten kann es passieren, das es dir ein wenig um die Ohren fliegt und dir Nutzdaten shreddert.

[slowjoe 10]

ollahe,

 

ich hänge noch immer an der Sicherung meines SQL Servers.

Wenn ich einen Auftrag plane und den ausführen lasse,dann meint er nur:

Führt Auftragsschritt '0 (unbekannt) aus.

Und das wars.

Keine Fehlermeldung, kein Eintrag in den logfiles keine hängenden prozesse, tab log auf der master, aber er macht nicht weiter?

Bin mit meinem Latei am Ende, oder ist der MS SQL vielleicht dafür bekannt, dass die Auftragsgesteuerte Sicherung buggi ist?

Ich kann auch den Prozess nicht killen?

Versuche jetzt mal ne ganz normale Sicherung von Hand auszuführen.

 

für Hilfe und Ideen

 

wie immer dankbar

 

mfg

c