7
SQL LDF Datei SHRINKFILE
SQL LDF Datei SHRINKFILE
Servus,
ich bräuchte mal eure Hilfe im Bezug auf SQL. Ich bin hier leider total unerfahren und frage lieber noch mal nach, bevor ich den falschen Befehl abschieße.
Wir haben auf unserm SQL Server Standard eine Instanz mit 30 Datenbanken. Das Programm (nennen wir es NSA) für unsere Finanzbuchhaltung hat für jede Firma eine eigene Datenbank. Hierbei sind die .ldf – also LOG Dateien extrem groß angewachsen, sodass unsere Festplatte vollgelaufen ist.
Der Hersteller (NSA) empfiehlt die Datenbanklogs per SHRINKFILE zu verkleinern. Hierzu haben wir folgenden Link erhalten:
Mein Problem welches sich mir hier stellt ist die sogenannte file_id bzw. der file_name. Ich denke der File Name ist der Datenbankname?
In meinem Beispiel nun die sa001 für die erste Datenbank?
Jetzt brauche ich doch eigentlich nur die file_id – und daran hapert es. Ich habe hier ein Script gefunden, welches mir die file_id ausgibt. Nun weis ich aber nicht was ich anstatt AdventureWorks2008R2 eintragen soll. Ist das die Datenbank sa001 oder der Instanzname?
--> File ID = 1
Bei allen Datenbanken erhalte ich die Gleiche ID – und das denke ich, ist falsch.
Des Weiteren habe ich mir mal die Eigenschaften der Datenbanken angeschaut. Hier lässt sich eine sogenannte „Automatische Vergrößerung“ im Bereich Dateien angeben.
Was würde mit den ca. 9 GB Daten passieren, wenn ich wie auf dem Bild zu sehen die Obergrenze auf 1024 MB beschränken würde? Werden die ältesten Daten gelöscht? Läuft das Datenbank LOG voll und funkioniert dann nicht mehr?
Vielen Dank schon einmal im Voraus!!
beste Grüße
lupolo
Servus,
ich bräuchte mal eure Hilfe im Bezug auf SQL. Ich bin hier leider total unerfahren und frage lieber noch mal nach, bevor ich den falschen Befehl abschieße.
Wir haben auf unserm SQL Server Standard eine Instanz mit 30 Datenbanken. Das Programm (nennen wir es NSA) für unsere Finanzbuchhaltung hat für jede Firma eine eigene Datenbank. Hierbei sind die .ldf – also LOG Dateien extrem groß angewachsen, sodass unsere Festplatte vollgelaufen ist.
Der Hersteller (NSA) empfiehlt die Datenbanklogs per SHRINKFILE zu verkleinern. Hierzu haben wir folgenden Link erhalten:
Mein Problem welches sich mir hier stellt ist die sogenannte file_id bzw. der file_name. Ich denke der File Name ist der Datenbankname?
Jetzt brauche ich doch eigentlich nur die file_id – und daran hapert es. Ich habe hier ein Script gefunden, welches mir die file_id ausgibt. Nun weis ich aber nicht was ich anstatt AdventureWorks2008R2 eintragen soll. Ist das die Datenbank sa001 oder der Instanzname?
USE SA007;
GO
SELECT FILE_IDEX('SA007')AS 'File ID';
GO--> File ID = 1
Bei allen Datenbanken erhalte ich die Gleiche ID – und das denke ich, ist falsch.
Des Weiteren habe ich mir mal die Eigenschaften der Datenbanken angeschaut. Hier lässt sich eine sogenannte „Automatische Vergrößerung“ im Bereich Dateien angeben.
Vielen Dank schon einmal im Voraus!!
beste Grüße
lupolo
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 316529
Url: https://administrator.de/contentid/316529
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
wenn deine SQL logs nicht kleiner werden, stimmt was nicht. Bei jedem Backup sollten die logs verkleinert werden.
Also erstmal Backup von jeder DB und anschließend die logs verkleinern.
Über dem SQL wartungsplan solltest Du die eine automatische Sicherung einstellen, die dir auch die Logs klein hält.
Gruß
Looser
wenn deine SQL logs nicht kleiner werden, stimmt was nicht. Bei jedem Backup sollten die logs verkleinert werden.
Also erstmal Backup von jeder DB und anschließend die logs verkleinern.
Über dem SQL wartungsplan solltest Du die eine automatische Sicherung einstellen, die dir auch die Logs klein hält.
Gruß
Looser
Hi
erst mal: Shrinkfile ist nicht wirklich zu empfehlen. Das ist im Grunde die Holzhammermethode und der letzte Ausweg.
Am einfachsten gehst du da mal per Rechtsklick auf die Datenbank und da unter Tasks - Shrink - Files. Da gibts dann einen Knopf "Script", der dir den Befehl anzeigt, der ausgeführt werden würde, wenn du OK drückst. Das kannst du dann einfach kopieren und für die anderen DBs anpassen.
Da kommt dann sowas bei raus
Aber:
Korrekt wäre es, die Datenbanken z.B per Wartungplan zu sichern. Danach gibt der Server die nicht mehr benötigten Logs frei.
Beim Wartungsplan bitte Index-Rebuild, Index-Reorga, Shrink-DB und Statistik-Update NICHT verwenden.
Das Autogrowth zu limitieren ist gefährlich. Wenn das Limit erreicht ist, steht deine Anwendung, weil der SQL die Logs nicht mehr schreiben kann und dir dann Fehlermeldungen um die Ohren haut. Lass es also sein
erst mal: Shrinkfile ist nicht wirklich zu empfehlen. Das ist im Grunde die Holzhammermethode und der letzte Ausweg.
Am einfachsten gehst du da mal per Rechtsklick auf die Datenbank und da unter Tasks - Shrink - Files. Da gibts dann einen Knopf "Script", der dir den Befehl anzeigt, der ausgeführt werden würde, wenn du OK drückst. Das kannst du dann einfach kopieren und für die anderen DBs anpassen.
Da kommt dann sowas bei raus
USE [ms3test]
GO
DBCC SHRINKFILE (N'ms3test_log' , 0, TRUNCATEONLY)
GOAber:
Korrekt wäre es, die Datenbanken z.B per Wartungplan zu sichern. Danach gibt der Server die nicht mehr benötigten Logs frei.
Beim Wartungsplan bitte Index-Rebuild, Index-Reorga, Shrink-DB und Statistik-Update NICHT verwenden.
Das Autogrowth zu limitieren ist gefährlich. Wenn das Limit erreicht ist, steht deine Anwendung, weil der SQL die Logs nicht mehr schreiben kann und dir dann Fehlermeldungen um die Ohren haut. Lass es also sein
Moin,
wenn Du Dich mit SQL nicht gut auskennst, was nicht schlimm ist, dann lass das lieber jemanden machen, der das täglich macht.
Eventuell ist die DB auf massenprotokoliert gestellt und dann wächst das log immer wieder an.
Vielleicht sollte auch über die Trennung DB und LOG auf unterschiedliche HDs nachgedacht werden, falls nicht virtuell.
Gruss
wenn Du Dich mit SQL nicht gut auskennst, was nicht schlimm ist, dann lass das lieber jemanden machen, der das täglich macht.
Eventuell ist die DB auf massenprotokoliert gestellt und dann wächst das log immer wieder an.
Vielleicht sollte auch über die Trennung DB und LOG auf unterschiedliche HDs nachgedacht werden, falls nicht virtuell.
Gruss
die Datenbanken müssen aber nicht auf der gleichen Patition gespeichert werden wie die .ldf und mdf Dateien Liegen oder?
So sieht der Wartungsplan aus.
So sieht der Wartungsplan aus.
Zitat von @SeaStorm:
Hi
erst mal: Shrinkfile ist nicht wirklich zu empfehlen. Das ist im Grunde die Holzhammermethode und der letzte Ausweg.
Am einfachsten gehst du da mal per Rechtsklick auf die Datenbank und da unter Tasks - Shrink - Files. Da gibts dann einen Knopf "Script", der dir den Befehl anzeigt, der ausgeführt werden würde, wenn du OK drückst. Das kannst du dann einfach kopieren und für die anderen DBs anpassen.
Da kommt dann sowas bei raus
Hi
erst mal: Shrinkfile ist nicht wirklich zu empfehlen. Das ist im Grunde die Holzhammermethode und der letzte Ausweg.
Am einfachsten gehst du da mal per Rechtsklick auf die Datenbank und da unter Tasks - Shrink - Files. Da gibts dann einen Knopf "Script", der dir den Befehl anzeigt, der ausgeführt werden würde, wenn du OK drückst. Das kannst du dann einfach kopieren und für die anderen DBs anpassen.
Da kommt dann sowas bei raus
Hallo SeaStorm,
danke für den Hinweis. Ich denke ich muss hier den Punkt von Datei auf Protokoll umstellen?
Besten Dank
lupolo
jupp
nein. Eine Trennung auf physisch unterschiedliche Laufwerke ist eigentlich empfehlenswert, da die Logs recht viel Leistung von der Platte fressen.
