Log Pengiriman SQL Server 2012

Saya seorang pengembang di sebuah toko kecil yang tidak memiliki DBA dan saya mencoba untuk mendapatkan pengiriman log dengan server sql 2012 yang berfungsi. Saya mencoba menonaktifkan pelaporan dari sistem transaksi ke data warehouse baru dan akan menggunakan db ini sebagai area pementasan.

Saya menjalankan wizard pengiriman log dan pekerjaan pencadangan serta penyalinan primer berfungsi setiap saat. Pekerjaan pemulihan sekunder tampaknya gagal secara acak.

Server utama hanya memiliki satu pekerjaan log transaksi. Diferensial cadangan dinonaktifkan (tidak yakin apakah itu penting) tetapi apakah memiliki cadangan lengkap.

Server sekunder adalah instalasi baru tanpa rencana pemeliharaan, cadangan, atau pengguna aktif.

Apakah ada cara untuk memaksa cadangan kembali sinkron, atau selalu memastikan cadangan tetap sinkron?

Sepertinya sangat rapuh. Mohon saran.

Log yang dihapus di bawah:

*Starting transaction log copy. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieving copy settings. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieved copy settings. 
Primary Server: '', 
Primary Database: 'db', Backup Source Directory: '\\server\folder', 
Backup Destination Directory: '\\server\folder', 
Last Copied File: '\\server\folder\db_20160105070002.trn'
Starting transaction log restore. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieving restore settings. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Copying log backup files. 
Primary Server: 'server', Primary Database: 'db', 
Backup Source Directory: '\\server\folder', 
Backup Destination Directory: '\\server\folder'
Retrieved common restore settings. 
Primary Server: 'server', 
Primary Database: 'db', 
Backup Destination Directory: '\\server\folder', 
File Retention Period: 14400 minute(s)
Retrieved database restore settings. 
Secondary Database: 'db', 
Restore Delay: 10, 
Restore All: True, 
Restore Mode: Standby, 
Disconnect Users: True, 
Last Restored File: \\server\folder\db_20160105060002.trn, 
Block Size: Not Specified, 
Buffer Count: Not Specified, 
Max Transfer Size: Not Specified
Disconnecting users. 
Secondary DB: 'db'
Copying log backup file to temporary work file.
 Source: '\\server\folder\db_20160105080001.trn', 
Destination: '\\server\folder\db_20160105080001.wrk'
Renamed temporary work file. 
Source: '\\server\folder\db_20160105080001.wrk',
Destination: '\\server\folder\db_20160105080001.trn'
Checking to see if any previously copied log backup files that are required by the restore operation are missing. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
The copy operation was successful. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7', 
Number of log backup files copied: 1
An error occurred restoring the database access mode. (Alter failed for Database 'db'. )
The file '\\server\folder\db_20160105070002.trn' is too recent to apply to the secondary database 'db'. 
(The log in this backup set begins at LSN 52498000002221000001, which is too recent to apply to the database. An earlier log backup that includes LSN 52498000002197900001 can be restored.
RESTORE LOG is terminating abnormally.)
Searching for an older log backup file. 
Secondary Database: 'db'
Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105060002.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105050001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105040001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105030001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105020000.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105010001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105000001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104230001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104220001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104210001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104200001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104190004.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104180000.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104170002.trn'

Could not find a log backup file that could be applied to secondary database 'db'.
Deleting old log backup files. Primary Database: 'db'

The restore operation completed with errors. Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'*

PEMBARUAN: Berjalan di bawah query ada beberapa cadangan log transaksi aneh (mungkin)

NUL adalah apa yang ada di tabel. Tidak tahu mengapa ini bukan NULL

Ini adalah Waktu Selesai Cadangan, Perangkat, Jenis

2016-01-08 02: 00: 01.000 D: \ Folder \ DB_20160108090001.trn Log

2016-01-08 01: 00: 01.000 D: \ Folder \ DB_20160108080001.trn Log

2016-01-08 00: 00: 00.000 D: \ Folder \ DB_20160108070000.trn Log

2016-01-07 23: 46: 41.000 NUL Log

2016-01-07 23: 41: 07.000 {51C661F9-2DC2-4424-913F-B9CFADA69FEE} 1 Basis Data

2016-01-07 23: 00: 01.000 D: \ Folder \ DB_20160108060001.trn Log

Sepertinya sangat rapuh.

Logshipping diuji dan dibuktikan sejak sql server 2000 (dan bahkan lebih tua) hari. Itu tidak rapuh.

Lihat kesalahannya ...

File Yang Terakhir Dipulihkan: \ server \ folder \ db_201601050 60002 .trn,

Logshipping sedang mencoba untuk memulihkan

Tujuan: '\ server \ folder \ db_201601050 80001 .trn'

Ini berarti Anda memiliki celah dalam urutan log . Mungkin ada cadangan log adhoc yang terjadi yang memutus rantai log.

Lihat jawaban saya - Bagaimana cara pengiriman Log tahu untuk melacak .

Anda bahkan dapat membatasi pengguna untuk hanya menyalin cadangan log , sehingga cadangan log adhoc tidak akan memutus rantai log. Juga,

@ Spörri membuat poin yang valid untuk menonaktifkan layanan penulis SQL VSS, sehingga alat cadangan pihak ketiga tidak dapat berinteraksi dengan SQL. Sulit untuk mengetahui hal itu, karena perangkat lunak pihak ke-3 terkadang gila !

Untuk mengetahui celah dalam cadangan log Anda, Anda dapat menggunakan kueri di bawah ini

SELECT 
    s.database_name,s.backup_finish_date,y.physical_device_name
FROM 
    msdb..backupset AS s INNER JOIN
    msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
    msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
    msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE 
    (s.database_name = 'databaseNamePrimaryServer')
ORDER BY 
    s.backup_finish_date DESC;

Permintaan lain yang bermanfaat:

-- http://sqlblog.com/blogs/tibor_karaszi/archive/2014/11/03/can-you-restore-from-your-backups-are-you-sure.aspx
-- modified by Kin to include backup start and finish dates
SELECT TOP(100)
database_name
,CASE bs.TYPE
   WHEN 'D' THEN 'Full'
   WHEN 'I' THEN 'Differential'
   WHEN 'L' THEN 'Log'
   WHEN 'F' THEN 'File or filegroup'
   WHEN 'G' THEN 'Differential file '
   WHEN 'P' THEN 'Partial'
   WHEN 'Q' THEN 'Differential partial'
END AS backup_type
,bs.is_copy_only
,bs.is_snapshot
,bs.backup_start_date
,bs.backup_finish_date
,DATEDIFF(SECOND, bs.backup_start_date, bs.backup_finish_date) AS backup_time_sec
,mf.physical_device_name
,bs.database_name
FROM msdb.dbo.backupset AS bs
  INNER JOIN msdb.dbo.backupmediafamily AS mf ON bs.media_set_id = mf.media_set_id  
  where database_name = 'master' -- change here for your database 
ORDER BY backup_finish_date DESC;