Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

MS SQL 2005 - Fehler beim Verkleinern des TA Logs

Frage Entwicklung Datenbanken

Mitglied: Viprex

Viprex (Level 1) - Jetzt verbinden

22.07.2010 um 08:40 Uhr, 4960 Aufrufe, 8 Kommentare

Hallo,

meine MS SQL Schulung ist schon etwas her. Seit der Schulung habe ich nicht wieder mit MS SQL DBs gearbeitet. Das ist ne Grundlage

Jetzt haben wir hier eine MS SQL 2005'er DB, für die wir keinen Support gekauft haben. Ja, ist doof, ich weiß. Daher bin ich erstmal in den Foren der Welt auf der Suche nach Hinweisen, was schief laufen könnte. Folgende Situation:

Durch einen nächtlichen Reorg der DB läuft das TA Log auf gut 40GB voll. Das ist zu groß für die Festplatte. Es wird daher direkt nach dem Reorg eine Sicherung des TA Logs durchgeführt und das log geleert.In den Informationen zum Log steht auch, dass es nur noch zu 96% gefüllt ist. Klar, nach der Sicherung des Logs wird dieses geleert, der Speicherplatz auf der Festplatte aber nicht verkleinert. Daher wollen wir das Log jetzt automatisiert durch einen Wartungsplan verkleinern. Das manuelle Verkleinern durch einen Task (Rechtsklick auf DB - Tasks - Verkleinern - Dateien - Auswahl Protokoll und dann das entsprechende logfile) funktioniert problemlos. Jetzt haben wir probiert, das, was manuell funktioniert, in den Wartungsplan für den Reorg aufzunehmen. Dazu wollte ich einen T-SQL Task im Wartungsplan erstellen und entsprechend in der Ablauf verknüpfen.
Folgender T-SQL Code sollte eigentlich funktionieren (zumindest ist das das Skript, welches das Management Studio dafür erzeugt, wenn man den Task manuell ausführen will und dann oben auf Skript generieren geht):

01.
    USE [pb_echt] 
02.
    GO 
03.
    DBCC SHRINKFILE (N'pb59_echt_Log' , 0, TRUNCATEONLY) 
04.
    GO
Leider scheint das Skript aber nicht die richtige Datenbank zu wählen, denn es versucht immer die Datei in der master DB zu finden:

01.
Fehler beim Ausführen der Abfrage 'DBCC SHRINKFILE (N'pb59_echt_Log' , 0, TRUNCATEONLY)': 'Die Datei 'pb59_echt_Log' wurde für die 'master'-Datenbank nicht in sys.database_files gefunden. Die Datei ist entweder nicht vorhanden oder wurde gelöscht. '. Mögliche Ursachen sind folgende: Probleme bei der Abfrage, nicht richtig festgelegte ResultSet-Eigenschaft, nicht richtig festgelegte Parameter oder nicht richtig hergestellte Verbindung.
Das verstehe ich nicht. Das og. T-SQL Skript hat mir der Management Studio selbst erzeugt. Und schaue ich mir die Syntax an, ist das auch alles korrekt. Testweise habe ich dann mal geschaut, ob es mit der File ID für die Datei "pb59_echt_log" klappt. Die File ID ist die 2. Mit dem Code:

01.
    USE [pb_echt] 
02.
    GO 
03.
    DBCC SHRINKFILE (2 , 0, TRUNCATEONLY) 
04.
    GO
gibt es wenigstens keine Fehlermeldungen mehr, interessanterweise verkleinert er jetzt aber die Datei mit der File ID2 der Master DB. Ehrlich gesagt verstehe ich nicht, warum er mit dem og. Skript nicht auf die richtige DB zugreift.

Das Einfügen von Semikolons hat nichts geändert.
Manuelle Abfragen im Management Studio funktionieren auch auf Verschiedenen DB heraus, sogar mit dem Use "DB" Befehl.

Was mir noch aufgefallen ist: Der Besitzer dieser DB ist nicht sa, sondern ein Domänen-Benutzer. Dieser hat die DB damals angelegt (ist ein Dienstleister von uns, das Domänenkonto existiert immer noch).

Hat jemand eine Ahnung, was ich falsch mache? Viele lieben Dank fürs Lesen und drüber nachdenken.
Mitglied: goscho
22.07.2010 um 10:19 Uhr
Morgen Viprex,
ein derartiges Anwachsen der TA-Logs ist immer ein Zeichen dafür, das das Wiederherstellungsmodell nicht auf 'einfach' gestellt ist.
Jetzt stellt sich die Frage, warum?
Müssen die Logs zwischen den Sicherungen aufgehoben werden?

Ich habe keine einzige Datenbank, welche einen anderen Wiederherstellungsmodus als simple eingerichtet hat.

Wenn du die Einstellung suchst:
Eigenschaften der DB -> Optionen -> Wiederherstellungsmodell (einfach wäre am Besten)
Wenn du eine aktuelle Sicherung hast, kannst du dies auch dort umstellen.
Bitte warten ..
Mitglied: Viprex
22.07.2010 um 12:01 Uhr
Das Wiederherstellungsmodell ist in der Tat "Vollständig". Warum, weiß ich nicht. So ganz unwichtig sit die DB nicht, denn dort läuft unser ERP System im Cluster. So einfach etwas umstellen kann und will ich da nicht. Ich mache mich jetzt erstmal schlau, was das Wiederherstellungsmodell denn bedeutet.

Meinst du denn, dass die Probleme mit dem Verkleinern des Logs daher rühren?
Bitte warten ..
Mitglied: goscho
22.07.2010 um 12:33 Uhr
Zitat von Viprex:
Das Wiederherstellungsmodell ist in der Tat "Vollständig". Warum, weiß ich nicht. So ganz unwichtig sit die
DB nicht, denn dort läuft unser ERP System im Cluster. So einfach etwas umstellen kann und will ich da nicht. Ich mache mich
jetzt erstmal schlau, was das Wiederherstellungsmodell denn bedeutet.
Hier solltest du dich in der Tat schlau machen. Von Clustern habe ich keinerlei Ahnung.
Meinst du denn, dass die Probleme mit dem Verkleinern des Logs daher rühren?

Beim Wiederherstellungsmodell 'vollständig' müssen diese Logs gesichert werden. Dann wird das Protokoll automatisch gelöscht/verkleinert.

Schau einfach in die Online-Hilfe vom SQL-Server (Managementstudio -> DB-Optionen -> F1)
Bitte warten ..
Mitglied: MadMax
22.07.2010 um 12:43 Uhr
Moin Viprex,

wenn ich mir den Dateinamen anschaue, frage ich mich, ob Deine DB vielleicht "pb59_echt" und nicht "pb_echt" heißt.

Ansonsten gäbe es noch die Möglichkeit, gleich die ganze DB und nicht nur die Logdatei zu verkleinern:
01.
dbcc shrinkdatabase ('pb_echt') 
02.
-- oder (?) 
03.
dbcc shrinkdatabase ('pb59_echt')
Und außerdem noch die Variante, die Datenbank zu trennen, dann die Logdatei zu löschen und anschließend die Datendatei wieder anzuhängen. Dann wird die Logdatei neu erzeugt:
01.
exec sp_detach_db 'pb_echt' 
02.
exec xp_cmdshell 'del c:\datenbanken\pb59_echt_Log.ldf' -- xp_cmdshell muss erlaubt sein oder es wird anders geloescht 
03.
exec sp_attach_db 'pb_echt', 'c:\datenbanken\pb59_echt.mdf'
Hat natürlich den Nachteil, daß die DB kurzzeitig offline ist.

Weitere Möglichkeit ist auch noch, daß der Benutzer, der den Job im Wartungsplan ausführt, nicht die nötigen Berechtigungen hat, auf die DB zuzugreifen.

Dein Problem liegt auf jeden Fall nicht im "dbcc shrinkfile", sondern im "use [pb_echt]".

Und weil hier grade die Diskussion um das Wiederherstellungsmodell geht:
Für eine produktive DB solltest Du das Modell auf "Vollständig" lassen. Wenn Dir Deine DB abschmiert, willst Du sie ja wahrscheinlich so weit wie möglich wiederherstellen. Mit dem einfachen Modell geht das bis zur letzten Sicherung und fertig. Mit dem vollständigen Modell kannst Du bis zum Crash wiederherstellen oder auch bis zu einem bestimmten Zeitpunkt.
Wenn Du keine Ahnung hast, welches Modell Ihr braucht, dann laß die Finger von dem Schalter weg!

Gruß, Mad Max
Bitte warten ..
Mitglied: Viprex
22.07.2010 um 13:00 Uhr
Hallo nochmal,

vielen Dank für eure Antworten.

Die Datenbank heißt definitiv pb_echt.

Ein manuelles Verkleinern der Datei funktioniert problemlos.

Das USE PB_Echt scheint in der Tat der Knackpunkt zu sein. Der Hinweis auf fehlende Berechtigung ist ein sehr guter. Da werde ich mal nachforschen.

Das Wiederherstellungsmodell lasse ich unberührt, denn es werden ja sowieso ständig Vollsicherungen durchgeführt. Das ist also kein Hindernis. Anscheinend leert die Vollsicherung die TA Protokoll Datei zwar, aber verkleinert sie nicht physikalisch. Daher eben die Idee den T-SQL Task hinten dran anzufügen.

Die Datenbank trennen, um die logdatei löschen zu können, ist ja nicht notwendig, denn das manuelle Verkleinern durch den Wizzard funktioniert ja (wie oben geschrieben: Rechtsklick auf DB - Task - Verkleinern - Dateien -> Auswahl von Protokoll und dann die Datei)

Frage zum Vorschlag, die ganze DB zu verkleinern: Wird dann auch das logfile verkleinert? Außerdem dachte ich, dass es mit MS SQL (zumindest in Version 2005) nicht möglich ist, einmal physikalisch belegten Speicherplatz wieder freizugeben. Logisch (also innerhalb der DB Datei) geht das zwar - das nennt sich dann doch "leeren der DB" - aber verkleinern geht nicht, oder liege ich da auch vollkommen daneben?

Ich werde erstmal schauen, ob ich mit den Benutzerrechte weiterkomme. Vielen Dank.
Bitte warten ..
Mitglied: MadMax
22.07.2010 um 22:31 Uhr
Zitat von Viprex:
Frage zum Vorschlag, die ganze DB zu verkleinern: Wird dann auch das logfile verkleinert? Außerdem dachte ich, dass es mit
MS SQL (zumindest in Version 2005) nicht möglich ist, einmal physikalisch belegten Speicherplatz wieder freizugeben. Logisch
(also innerhalb der DB Datei) geht das zwar - das nennt sich dann doch "leeren der DB" - aber verkleinern geht nicht,
oder liege ich da auch vollkommen daneben?

Ja, auch die Logdatei wird verkleinert. Und auch die physikalische Datei kann verkleiner werden. Das war doch auch das, was Du mit dbcc shrinkfile versucht hast, oder?

Gruß, Mad Max
Bitte warten ..
Mitglied: Viprex
23.07.2010 um 09:11 Uhr
Ich habe mich wohl auch nicht ganz deutlich ausgedrückt. Sorry.

Also mit leeren ist das logische Platz schaffen innerhalb der DB Datei gemeint.
Mit verkleinern ist das Freigeben von Speicherplatz auf der Festplatte durch zusammenschrumpfen der Datei auf die virtuell benötigte Größe gemeint.

Ich dachte bisher immer, dass man bei MS SQL 2005 DB Dateien zwar leeren, aber nicht verkleinern kann.
Ganz im Gegenteil zu den Protokolldateien. Diese lassen sich sowohl leeren, als auch verkleinern.


Zitat von MadMax:
Ja, auch die Logdatei wird verkleinert.

Meinst du jetzt verkleinert oder geleert?

Zitat von MadMax:
Ja, auch die Logdatei wird verkleinert. Und auch die physikalische Datei kann verkleiner werden. Das war doch auch das, was Du mit
dbcc shrinkfile versucht hast, oder?

Wenn du auch vom Verkleinern redest, so wie ich hier, dann ist es genau das, was ich eigentlich gerne (automatisiert - denn manuell gehts ja) wollte.
Bitte warten ..
Mitglied: MadMax
23.07.2010 um 12:57 Uhr
Hallo Viprex,

mit "verkleinert" meine ich verkleinert, deswegen habe ich auch "verkleinert" geschrieben. Wenn ich geleert gemeint hätte, hätte ich "geleert" geschrieben

Im Übrigen gibt es noch zwei weitere Möglichkeiten, Dein Problem zu lösen:
1. In den Datenbankeigenschaften, Fenster Optionen, gibt es den Schalter "Automatisch verkleinern". Allerdings hatte ich mit der Einstellung den Eindruck, daß die Geschwindigkeit der Zugriffe darunter leidet, weil der Server ständig mit dem Verkleinern und wieder Vergrößern beschäftigt war.

2. Einen Windows-Task einrichten und per sqlcmd den Befehl "dbcc shrinkwasauchimmer" ausführen.

Gruß, Mad Max
Bitte warten ..
Neuester Wissensbeitrag
Humor (lol)

Linkliste für Adventskalender

(3)

Information von nikoatit zum Thema Humor (lol) ...

Ähnliche Inhalte
Datenbanken
MS-SQL-Server + T-SQL+Batch (4)

Frage von kallewirsch zum Thema Datenbanken ...

Datenbanken
gelöst Täglicher Export einer View aus MS SQL 2008 in Excel oder CSV (9)

Frage von Arafat zum Thema Datenbanken ...

Heiß diskutierte Inhalte
Windows Server
DHCP Server switchen (25)

Frage von M.Marz zum Thema Windows Server ...

SAN, NAS, DAS
gelöst HP-Proliant Microserver Betriebssystem (14)

Frage von Yannosch zum Thema SAN, NAS, DAS ...

Grafikkarten & Monitore
Win 10 Grafikkarte Crash von Software? (13)

Frage von Marabunta zum Thema Grafikkarten & Monitore ...

Router & Routing
gelöst Empfehlung günstiges ADSL2+ nur Modem (10)

Frage von TimMayer zum Thema Router & Routing ...