none
Logshipping: Location of TUF File RRS feed

  • Frage

  • Hi everybody,

    in SQL2003 and SQL2008 a tuf-file was created togehter with the trn-files in the backup_destination_directory of the secondary server.

    In SQL2012 the tuf-file will be created in the folder of the corresponding mdf-file. Due to reasons of monitoring, I want it to be stored together with the trn-files like it was in pervious versions of SQL.

    Where can I set or change the path of a tuf-file?

    Kind regards,
    TorFra



    • Bearbeitet TorFra Freitag, 11. April 2014 13:04
    Freitag, 11. April 2014 12:59

Antworten

  • Vielen Dank für die Geduld und die zahlreichen Erklärungsversuche. Der Thread ist ziemlich lang, deshalb fasse ich zusammen:

    Es gibt keine vorgesehene Möglichkeit den Speicherort einer tuf-Datei NACHTRÄGLICH zu ändern.

    Um den Pfad VORAB anzupassen, muss der Restorejob des Logshippings über ein entsprechendes Script  erstellt werden, was ohne tiefstgreifendes Wissen nicht möglich ist. Der Wizard selbst bietet keine Option an dem Pfad etwas zu ändern.

    • Als Antwort markiert TorFra Mittwoch, 16. April 2014 12:37
    Mittwoch, 16. April 2014 12:37

Alle Antworten

  • Hi everybody,

    in SQL2003 and SQL2008 a tuf-file was created togehter with the trn-files in the backup_destination_directory of the secondary server.

    In SQL2012 the tuf-file will be created in the folder of the corresponding mdf-file. Due to reasons of monitoring, I want it to be stored together with the trn-files like it was in pervious versions of SQL.

    Where can I set or change the path of a tuf-file?

    ...

    Hello TorFra

    you are probably referring to SQL Server 2000 or 2005 - there was no2003-version.

    The location if "tuf-file" can be specified using the STANDBY =standby_file_name -Syntax of the Restore Command

    Unfortunately, if you are using the wizard, that option is not available.

    I recommend to set up your own scripts for LogShipping, if you haven't already done so. Then it's simple :)

    By the way: this is a German forum, so feel free to write in German ;-)

    Andreas


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com



    Freitag, 11. April 2014 13:33
  • Hallo Andreas

    danke für die schnelle Antwort.

    Ich erstelle das Logshipping in zwei Schritten:

    1. Backup und Restore per Script

    Im Restore Command benutze ich STANDBY = N'Z:\TLOGSHIP\TEST\ROLLBACK_UNDO_TEST.BAK', NOUNLOAD, STATS = 10. Die Standby-Datei wird unter dem angegebenen Pfad erzeugt.

    2. manuelle Konfiguration Logshipping mit initialisierter DB

    Wenn ich mir die Konfiguration als Script anzeigen lasse, finde ich darin keinen Verweis auf eine tuf-Datei.

    3. Logshipping starten

    Beim ersten Logshipping wird die ROLLBACK_UNDO_TEST.BAK gelöscht und die tuf-Datei erzeugt. Allerdings im Verzeichnis der mdf.

    Gruuß

    TorFra


    • Bearbeitet TorFra Freitag, 11. April 2014 14:09
    Freitag, 11. April 2014 14:07
  • ...

    1. Backup und Restore per Script

    Im Restore Command benutze ich STANDBY = N'Z:\TLOGSHIP\TEST\ROLLBACK_UNDO_TEST.BAK', NOUNLOAD, STATS = 10. Die Standby-Datei wird unter dem angegebenen Pfad erzeugt.

    2. manuelle Konfiguration Logshipping mit initialisierter DB

    Wenn ich mir die Konfiguration als Script anzeigen lasse, finde ich darin keinen Verweis auf eine tuf-Datei....

    Hallo

    das ich das richtig verstehe: Du hast einen Job-Step aus T-SQL gebastelt?

    Und wenn Du ihn scriptest, ist der Part weg?

    Das kann irgendwie nicht sein. Vermutlich verstehe ich es falsch.

    Kannst Du den Restore-Job einmal gescriptet hier zeigen?


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Freitag, 11. April 2014 14:11
  • Gerne.
    Hier das Restore-Script:

            RESTORE DATABASE [test]
            FROM DISK = N'Z:\TLOGSHIP\TEST.bak'
            WITH FILE = 1,
            MOVE N'test' TO N'Z:\test\test.mdf',
            MOVE N'test_log' TO N'Z:\test\test.ldf',
            STANDBY = N'Z:\TLOGSHIP\TEST2\ROLLBACK_AND_UNDO_TEST.BAK', NOUNLOAD, STATS = 10

    Danach gehe ich in den Eingenschaften der primären DB auf Transaktionsprotokollversand und mache die Einstellungen manuell. Die Datenbank ist ja bereits initialisiert, also wähle ich das auch entsprechend aus. Wenn ich dann auf die Schaltfläche Script für Konfiguration erstellen klicke erhalte ich diese Abfrage:

    -- ****** Beginn: auf dem primären Server auszuführendes Skript: [192.168.108.245] ****** DECLARE @LS_BackupJobId AS uniqueidentifier DECLARE @LS_PrimaryId AS uniqueidentifier DECLARE @SP_Add_RetCode As int EXEC @SP_Add_RetCode = master.dbo.sp_add_log_shipping_primary_database @database = N'test' ,@backup_directory = N'z:\tlogship\test' ,@backup_share = N'\\192.168.108.245\tlogship\test' ,@backup_job_name = N'LSBackup_test' ,@backup_retention_period = 4320 ,@backup_threshold = 60 ,@threshold_alert_enabled = 1 ,@history_retention_period = 5760 ,@backup_job_id = @LS_BackupJobId OUTPUT ,@primary_id = @LS_PrimaryId OUTPUT ,@overwrite = 1 IF (@@ERROR = 0 AND @SP_Add_RetCode = 0) BEGIN DECLARE @LS_BackUpScheduleUID As uniqueidentifier DECLARE @LS_BackUpScheduleID AS int EXEC msdb.dbo.sp_add_schedule @schedule_name =N'LSBackupSchedule_192.168.108.2451' ,@enabled = 1 ,@freq_type = 4 ,@freq_interval = 1 ,@freq_subday_type = 4 ,@freq_subday_interval = 15 ,@freq_recurrence_factor = 0 ,@active_start_date = 20140411 ,@active_end_date = 99991231 ,@active_start_time = 0 ,@active_end_time = 235900 ,@schedule_uid = @LS_BackUpScheduleUID OUTPUT ,@schedule_id = @LS_BackUpScheduleID OUTPUT EXEC msdb.dbo.sp_attach_schedule @job_id = @LS_BackupJobId ,@schedule_id = @LS_BackUpScheduleID EXEC msdb.dbo.sp_update_job @job_id = @LS_BackupJobId ,@enabled = 1 END EXEC master.dbo.sp_add_log_shipping_alert_job EXEC master.dbo.sp_add_log_shipping_primary_secondary @primary_database = N'test' ,@secondary_server = N'192.168.108.246' ,@secondary_database = N'test' ,@overwrite = 1 -- ****** Ende: auf dem primären Server auszuführendes Skript: [192.168.108.245] ******

    -- ****** Beginn: auf dem sekundären Server auszuführendes Skript: [192.168.108.246] ******


    DECLARE @LS_Secondary__CopyJobId    AS uniqueidentifier
    DECLARE @LS_Secondary__RestoreJobId    AS uniqueidentifier
    DECLARE @LS_Secondary__SecondaryId    AS uniqueidentifier
    DECLARE @LS_Add_RetCode    As int


    EXEC @LS_Add_RetCode = master.dbo.sp_add_log_shipping_secondary_primary
            @primary_server = N'192.168.108.245'
            ,@primary_database = N'test'
            ,@backup_source_directory = N'\\192.168.108.245\tlogship\test'
            ,@backup_destination_directory = N'\\192.168.108.246\tlogship\test'
            ,@copy_job_name = N'LSCopy_192.168.108.245_test'
            ,@restore_job_name = N'LSRestore_192.168.108.245_test'
            ,@file_retention_period = 4320
            ,@overwrite = 1
            ,@copy_job_id = @LS_Secondary__CopyJobId OUTPUT
            ,@restore_job_id = @LS_Secondary__RestoreJobId OUTPUT
            ,@secondary_id = @LS_Secondary__SecondaryId OUTPUT

    IF (@@ERROR = 0 AND @LS_Add_RetCode = 0)
    BEGIN

    DECLARE @LS_SecondaryCopyJobScheduleUID    As uniqueidentifier
    DECLARE @LS_SecondaryCopyJobScheduleID    AS int


    EXEC msdb.dbo.sp_add_schedule
            @schedule_name =N'DefaultCopyJobSchedule'
            ,@enabled = 1
            ,@freq_type = 4
            ,@freq_interval = 1
            ,@freq_subday_type = 4
            ,@freq_subday_interval = 15
            ,@freq_recurrence_factor = 0
            ,@active_start_date = 20140411
            ,@active_end_date = 99991231
            ,@active_start_time = 0
            ,@active_end_time = 235900
            ,@schedule_uid = @LS_SecondaryCopyJobScheduleUID OUTPUT
            ,@schedule_id = @LS_SecondaryCopyJobScheduleID OUTPUT

    EXEC msdb.dbo.sp_attach_schedule
            @job_id = @LS_Secondary__CopyJobId
            ,@schedule_id = @LS_SecondaryCopyJobScheduleID  

    DECLARE @LS_SecondaryRestoreJobScheduleUID    As uniqueidentifier
    DECLARE @LS_SecondaryRestoreJobScheduleID    AS int


    EXEC msdb.dbo.sp_add_schedule
            @schedule_name =N'DefaultRestoreJobSchedule'
            ,@enabled = 1
            ,@freq_type = 4
            ,@freq_interval = 1
            ,@freq_subday_type = 4
            ,@freq_subday_interval = 15
            ,@freq_recurrence_factor = 0
            ,@active_start_date = 20140411
            ,@active_end_date = 99991231
            ,@active_start_time = 0
            ,@active_end_time = 235900
            ,@schedule_uid = @LS_SecondaryRestoreJobScheduleUID OUTPUT
            ,@schedule_id = @LS_SecondaryRestoreJobScheduleID OUTPUT

    EXEC msdb.dbo.sp_attach_schedule
            @job_id = @LS_Secondary__RestoreJobId
            ,@schedule_id = @LS_SecondaryRestoreJobScheduleID  


    END


    DECLARE @LS_Add_RetCode2    As int


    IF (@@ERROR = 0 AND @LS_Add_RetCode = 0)
    BEGIN

    EXEC @LS_Add_RetCode2 = master.dbo.sp_add_log_shipping_secondary_database
            @secondary_database = N'test'
            ,@primary_server = N'192.168.108.245'
            ,@primary_database = N'test'
            ,@restore_delay = 0
            ,@restore_mode = 1
            ,@disconnect_users    = 1
            ,@restore_threshold = 60   
            ,@threshold_alert_enabled = 1
            ,@history_retention_period    = 5760
            ,@overwrite = 1

    END


    IF (@@error = 0 AND @LS_Add_RetCode = 0)
    BEGIN

    EXEC msdb.dbo.sp_update_job
            @job_id = @LS_Secondary__CopyJobId
            ,@enabled = 1

    EXEC msdb.dbo.sp_update_job
            @job_id = @LS_Secondary__RestoreJobId
            ,@enabled = 1

    END


    -- ****** Ende: auf dem sekundären Server auszuführendes Skript: [192.168.108.246] ******



    • Bearbeitet TorFra Freitag, 11. April 2014 14:38
    Freitag, 11. April 2014 14:36
  • Hallo

    Also ich sehe einen Restore Befehl, der irgendwo ausgeführt wird. Wo und wann, ist mir nicht ersichtlich.

    Wo ist der Zusammenhang mit den LogShipping-Wizard erzeugten Jobs?

    Das hat ja nichts miteinander zu tun. Du müsstest es schon komplett selber machen und den Assistenten komplett außen vorlassen.


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Freitag, 11. April 2014 14:58
  • Wenn ich Dich richtig verstehe, dann liegt die einzige Möglichkeit darin, den Pfad der einer tuf-Datei in SQL2012 festzulegen, wenn hierfür EIN Script verwendet wird, welches Restore und Logshippingkonfig durchführt?

    Ein solches Script über den Wizard (Script für die Konfiguration erstellen) anzufertigen ist wohl nicht möglich, da Backup/Restore im Ergebnis nicht aufgeführt werden. (Egal was ich im Wizard unter Sekundäre Datenbank initialisieren angebe - es hat keine Auswirkung auf das Script.)

    Deshalb mache ich ein Backup auf dem primären Server, spiele dieses mit dem genannten Restorebefehl auf dem sekundären Server ein. Danach konfiguriere ich das Logshipping manuell und sage, die DB ist bereits initialisiert. So hat das bisher gut funktioniert und die tuf-Dateien lagen bei den trn-Dateien - bis SQL2012.

    Fragen:
    - Ich habe im Netz keine Scripte gesehen, die auch die DB-Initialisierung beinhalten. Hast Du da Quellen?
    - Eine nachträgliche Anpassung des tuf-Dateipfades (für bereits mit Logshipping konfigurierten DBs) ist generell nicht möglich? Wenn ich den Pfad beim Restore mitgeben kann, sollte der doch auch irgendwo definiert sein...

    Schönes WE!
    TorFra






    • Bearbeitet TorFra Freitag, 11. April 2014 15:46
    Freitag, 11. April 2014 15:40
  • Hallo TorFra,

    nein, Du sollst es nicht alles in EINEN Script packen. Das dürfte schwierig sein.

    Sondern Su solltest den gesamten Prozess, bestehend aus "Backup - Copy - Restore with Standby" einfach mit plain T-SQL nachbauen.

    Die Bestandteile davon kann man sich natürlich scripten. Die höchste "Herausforderung" hieran wird der Datei-Verwaltungs-Part sein. Anstelle von xcopy empfehle ich hier robocopy einzusetzen.

    Ein fertiger Script frei im Umlauf ist mir dafür nicht bekannt. Es ist halt customized", jeder wird es etwas anders benötigen. Das, was "frei verfügbar" ist, ist halt der Wizard, mit den entsprechenden Einschränkungen.

    Die Initialisierung wiederum macht man ja nur einmal, und die kann man selbstverständlich auch scripten.

    Der Pfad zur Standby-Datei hängt halt am Restore-Kommando. Das ist keine "Serverweite Konfiguration", die irgendwie hinterlegt werden würde. Der kann also bei jedem einzelnen Restore woanders liegen. Ergo muss es auch genau an dieser Stelle eingebaut werden. Und der Assistent ist quasi eine Blackbox, bestehend aus exe-Datei-Aufrufen. Daher meine Empfehlung, es selbst nach eigenem Gutdünken zu Implementieren.


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Freitag, 11. April 2014 15:59
  • Sondern Su solltest den gesamten Prozess, bestehend aus "Backup - Copy - Restore with Standby" einfach mit plain T-SQL nachbauen.

    ...

    Der Pfad zur Standby-Datei hängt halt am Restore-Kommando.

    Ich glaube, wir reden aneinander vorbei. Das Restore hatte ich ja bereits gepostet:

    RESTORE DATABASE [test]
            FROM DISK = N'Z:\TLOGSHIP\TEST.bak'
            WITH FILE = 1,
            MOVE N'test' TO N'Z:\test\test.mdf',
            MOVE N'test_log' TO N'Z:\test\test.ldf',
            STANDBY = N'Z:\TLOGSHIP\TEST2\ROLLBACK_AND_UNDO_TEST.BAK', NOUNLOAD, STATS = 10

    Die Standby Datei wird dann auch dort hinterlegt, allerdings findet sie sich nach dem ersten Logshipping nicht mehr dort.

    Da es initial offensichtlich nicht klappt: Eine nachträgliche Anpassung des tuf-Dateipfades (für bereits mit Logshipping konfigurierten DBs) ist generell nicht möglich?

    Montag, 14. April 2014 06:49
  • Sondern Du solltest den gesamten Prozess, bestehend aus "Backup - Copy - Restore with Standby" einfach mit plain T-SQL nachbauen.

    ...

    Der Pfad zur Standby-Datei hängt halt am Restore-Kommando.

    Ich glaube, wir reden aneinander vorbei. Das Restore hatte ich ja bereits gepostet:

    RESTORE DATABASE [test]
            FROM DISK = N'Z:\TLOGSHIP\TEST.bak'
            WITH FILE = 1,
            MOVE N'test' TO N'Z:\test\test.mdf',
            MOVE N'test_log' TO N'Z:\test\test.ldf',
            STANDBY = N'Z:\TLOGSHIP\TEST2\ROLLBACK_AND_UNDO_TEST.BAK', NOUNLOAD, STATS = 10

    Die Standby Datei wird dann auch dort hinterlegt, allerdings findet sie sich nach dem ersten Logshipping nicht mehr dort.

    Da es initial offensichtlich nicht klappt: Eine nachträgliche Anpassung des tuf-Dateipfades (für bereits mit Logshipping konfigurierten DBs) ist generell nicht möglich?

    Hallo

    Ja, richtig. Das ist Dein manuelles Restore. Und alle weiteren Restores erfolgen über den Wizard. Und dessen genaues T-SQL kann man nicht beeinflussen.

    Es gibt wirklich immer nur eine Standby-Datei. Keine "Kette". Sondern immer eine neue.

    wie ich bereits schrieb:

    "Der Pfad zur Standby-Datei hängt am Restore-Kommando. Das ist keine "Serverweite Konfiguration", die irgendwie hinterlegt werden würde. Der kann also bei jedem einzelnen Restore woanders liegen. Ergo müsste es auch genau an dieser Stelle eingebaut werden. Und der Assistent ist quasi eine Blackbox, bestehend aus exe-Datei-Aufrufen. Daher meine Empfehlung, es selbst nach eigenem Gutdünken zu Implementieren."

    Die Syntax und Auswirkkungen des Restore (with Standby)-Kommandos sind auch hier erklärt:

    RESTORE Arguments (Transact-SQL)


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Dienstag, 15. April 2014 10:38
  • hi ich glaube der Thread Ersteller wollte wissen wie man den Pfad der TUF Datei beim Restore über den Wizard ändern kann. 
    Dienstag, 15. April 2014 11:03
  • hi ich glaube der Thread Ersteller wollte wissen wie man den Pfad der TUF Datei beim Restore über den Wizard ändern kann. 

    Ja, das habe ich auch so verstanden.

    Vielleicht drücke ich mich zu kompliziert aus. Daher nochmal in kurz:

    Man kann den Pfad der Standby-Datei, die der Wizard erzeugt, nicht dediziert beeinflussen.


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Dienstag, 15. April 2014 11:07
  • ah ok. 

    was mich mal interessieren würde, wo genau der SQL Server den Pfad zur TUF Datei definiert.
    Also weil der pfad ja pro Datenbank immer unterschiedlich ist. Also muss der SQL server ja den Pfad der Datenbank nehmen und diese abändern das der Wizard weiß wo er die TUF datei ablegen soll?(registry eintrag? oder irgend eine stelle in der DB?)

    Dienstag, 15. April 2014 11:14
  • Mit dem Risiko, mich zu wiederholen:

    "Der Pfad zur Standby-Datei hängt am Restore-Kommando. Das ist keine "Serverweite Konfiguration", die irgendwie/irgendwo hinterlegt werden würde. Der kann also bei jedem einzelnen Restore woanders liegen. Ergo müsste es auch genau an dieser Stelle eingebaut werden. Und der Assistent ist quasi eine Blackbox, bestehend aus exe-Datei-Aufrufen. Daher meine Empfehlung, es selbst nach eigenem Gutdünken zu Implementieren."

    Entschuldige, das ich das jetzt nicht neu schreibe, ich denke es steckt da schon alles drinnen. Bitte nochmal in Ruhe genau durchlesen, und gerne BOL zu Rate ziehen. :)


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Dienstag, 15. April 2014 11:17
  • Vielen Dank für die Geduld und die zahlreichen Erklärungsversuche. Der Thread ist ziemlich lang, deshalb fasse ich zusammen:

    Es gibt keine vorgesehene Möglichkeit den Speicherort einer tuf-Datei NACHTRÄGLICH zu ändern.

    Um den Pfad VORAB anzupassen, muss der Restorejob des Logshippings über ein entsprechendes Script  erstellt werden, was ohne tiefstgreifendes Wissen nicht möglich ist. Der Wizard selbst bietet keine Option an dem Pfad etwas zu ändern.

    • Als Antwort markiert TorFra Mittwoch, 16. April 2014 12:37
    Mittwoch, 16. April 2014 12:37