none
log verzeichnis auf andere partition ohne detach-live system RRS feed

  • Frage

  • Hallo,

    gibt es eine methode alle logfiles, die derzeit auf einer seperaten partition liegen, auf eine größere partition zu ziehen ohne diese zu detachen und jede einzeln umzuziehen, quasi alle logfiles auf einmal auf die neue größere partion zu moven? Das dann auch noch ohne Ausfallzeiten :)

    Vielen Dank.


    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS

    Montag, 18. Februar 2013 14:48

Antworten

  • Es lässt sich ohne Problem skripten (Batch/PowerShell). Das Problem dabei ist die reine Datenmenge und die dafür notwendige Übertragungsdauer. Hier die Methode die ich immer verwende, ist halt mit entsprechender Downtime verbunden.

    1. T-SQL:

    ALTER DATABASE <DatenbankName> SET OFFLINE;

    2. Skript: Kopieren der dazugehörigen Log(s).

    3. T-SQL:

    ALTER DATABASE <DatenbankName> MODIFY FILE ( NAME =<DatenbankName>_log, FILENAME = '<NeuerPfad>\<DatenbankName>_log.ldf' );
    ALTER DATABASE <DatenbankName> SET ONLINE;

    Alle Datenbanke zuerst offline zu stellen und die Logs in einem aufwasch zu kopieren kann performanter sein. Hängt vom deinem Plattensystem ab.

    Backup's sind immer sinnvoll..)




    Mittwoch, 20. Februar 2013 11:12
  • Im Grunde ja, es liese sich sogar als ein einzige T-SQL Skript schreiben, aber das halte ich nicht für sinnvoll.

    Ich würde mit zwei Skripten arbeiten (Batch). Ein die die eigentliche Arbeit pro Datenbank macht (mit sqlcmd die entsprechenden T-SQL Skripts ausführt und die Dateien kopiert) und eine die diese für die 700 DBs steuert. Letzter kannst du mit

    SELECT  'Call DeineBatch.cmd ' + [name]
    FROM    master.sys.databases
    WHERE   NOT [name] IN ( 'master', 'tempdb', 'model', 'msdb');
    automatisch erzeugen.

    • Als Antwort markiert Daniel Ovadia Mittwoch, 20. Februar 2013 12:41
    Mittwoch, 20. Februar 2013 12:33

Alle Antworten

  • Nein, es sei denn deine "Partition" ist ein SAN-Volume mit entsprechender Technik im Hintergrund.. oder ein RAID-Adapter oder einer der neuen Windows-8-Speicherplätze.

    Sollten dein Logs in jeweils einer eigenen FileGroup liegen, gehts auch. Aber selbst dann wäre es ohne Ausfallzeiten nicht erreichbar, da während des Moves nur ein SELECT möglich sein sollte und keine Änderungen.

    Montag, 18. Februar 2013 15:28
  • Hallo Daniel,

    Du kannst zusätzliche Logfiles auf dem neuen Volume anlegen und dann die alten leeren.
    Wenn die dann leer sind, kann man die dann entfernen.

    Leeren: http://msdn.microsoft.com/de-de/library/ms190757.aspx
    Löschen: http://msdn.microsoft.com/de-de/library/ms175574.aspx

    Bitte daran denken das die Abfrageleistung Deines Systems dabei in die Knie gehen wird,
    da die Logdatei nicht ganz unwichtig ist.... :-)

    Gruß Klaus

    Montag, 18. Februar 2013 16:51
  • Hallo Daniel,

    Du kannst zusätzliche Logfiles auf dem neuen Volume anlegen und dann die alten leeren.
    Wenn die dann leer sind, kann man die dann entfernen.

    Leeren: http://msdn.microsoft.com/de-de/library/ms190757.aspx
    Löschen: http://msdn.microsoft.com/de-de/library/ms175574.aspx


    hallo Klaus

    das geht eben nicht.

    Du kannst nur zusaetzliche Data- resp. Logfiles leeren und loeschen, nicht aber das primary data (.mdf) and primary log (.ldf) file.

    Ergo geht es nicht ohne ein kurzes Shutdown - ausser wenn  das primary logfile minimiert und nicht geloescht werden muss.


    Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

    Montag, 18. Februar 2013 20:13
  • Hallo,

    danke für eure Vorschläge und Antworten..

    Dann frage ich etwas anders nach: Welche der möglichkeiten zum umziehen der log.LDF empfehtl ihr mir?

    Ich werde dann eine nachtschicht einlegen, es geht um ca. 700 DBs.

    Gibt es ein script das die offline setzt, das log auf eine andere partition legt und ich nur die dateien anschliessend rüber kopieren muss und diese dann wieder online gehen lasse? Oder muss ich das für jede einzeln machen?

    Sicherungen werden sowieso alle 4 stunden gemacht via DPM, deshalb denke ich ist ein backup restore nicht sinnvoll.


    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS

    Mittwoch, 20. Februar 2013 10:55
  • Es lässt sich ohne Problem skripten (Batch/PowerShell). Das Problem dabei ist die reine Datenmenge und die dafür notwendige Übertragungsdauer. Hier die Methode die ich immer verwende, ist halt mit entsprechender Downtime verbunden.

    1. T-SQL:

    ALTER DATABASE <DatenbankName> SET OFFLINE;

    2. Skript: Kopieren der dazugehörigen Log(s).

    3. T-SQL:

    ALTER DATABASE <DatenbankName> MODIFY FILE ( NAME =<DatenbankName>_log, FILENAME = '<NeuerPfad>\<DatenbankName>_log.ldf' );
    ALTER DATABASE <DatenbankName> SET ONLINE;

    Alle Datenbanke zuerst offline zu stellen und die Logs in einem aufwasch zu kopieren kann performanter sein. Hängt vom deinem Plattensystem ab.

    Backup's sind immer sinnvoll..)




    Mittwoch, 20. Februar 2013 11:12
  • Hallo Stefan,

    danke, kann ich anstatt einen DB namen auch alle userDBs angeben? Damit ich nicht für jede DB den vorgang widerholen muss. Bin nicht wirklich fit was SQL angeht, danke.


    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS

    Mittwoch, 20. Februar 2013 11:33
  • Im Grunde ja, es liese sich sogar als ein einzige T-SQL Skript schreiben, aber das halte ich nicht für sinnvoll.

    Ich würde mit zwei Skripten arbeiten (Batch). Ein die die eigentliche Arbeit pro Datenbank macht (mit sqlcmd die entsprechenden T-SQL Skripts ausführt und die Dateien kopiert) und eine die diese für die 700 DBs steuert. Letzter kannst du mit

    SELECT  'Call DeineBatch.cmd ' + [name]
    FROM    master.sys.databases
    WHERE   NOT [name] IN ( 'master', 'tempdb', 'model', 'msdb');
    automatisch erzeugen.

    • Als Antwort markiert Daniel Ovadia Mittwoch, 20. Februar 2013 12:41
    Mittwoch, 20. Februar 2013 12:33
  • cool, ich sage herzlichen dank!

    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS

    Mittwoch, 20. Februar 2013 12:41