Đăng nhập SQL Server 2012

Tôi là nhà phát triển tại một cửa hàng nhỏ không có DBA và tôi đang cố gắng để vận chuyển nhật ký với máy chủ sql 2012 hoạt động. Tôi đang cố gắng tắt báo cáo từ hệ thống giao dịch sang kho dữ liệu mới và sẽ sử dụng db này làm khu vực tổ chức.

Tôi đã chạy trình hướng dẫn vận chuyển nhật ký và các công việc sao lưu tệp và sao lưu chính hoạt động mọi lúc. Công việc khôi phục thứ cấp dường như thất bại ngẫu nhiên.

Máy chủ chính chỉ có một công việc nhật ký giao dịch. Sao lưu vi sai bị vô hiệu hóa (không chắc chắn nếu điều đó có vấn đề) nhưng có một bản sao lưu đầy đủ.

Máy chủ thứ cấp là một bản cài đặt mới không có kế hoạch bảo trì, sao lưu hoặc người dùng hoạt động.

Có cách nào để buộc sao lưu trở lại đồng bộ hóa hay luôn đảm bảo nó được đồng bộ hóa?

Nó chỉ có vẻ rất mong manh. Xin tư vấn.

Nhật ký được xử lý lại dưới đây:

*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'*

CẬP NHẬT: Chạy bên dưới truy vấn có một số sao lưu nhật ký giao dịch kỳ lạ (có thể)

NUL là những gì trong bảng. Không biết tại sao nó không phải là NULL

Đây là thời gian kết thúc sao lưu, thiết bị, loại

2016-01-08 02: 00: 01.000 D: \ Thư mục \ DB_20160108090001.trn Nhật ký

2016-01-08 01: 00: 01.000 D: \ Thư mục \ DB_20160108080001.trn Nhật ký

2016-01-08 00: 00: 00.000 D: \ Thư mục \ DB_20160108070000.trn Nhật ký

2016-01-07 23: 46: 41.000 Nhật ký NUL

2016-01-07 23: 41: 07.000 {51C661F9-2DC2-4424-913F-B9CFADA69FEE} 1 Cơ sở dữ liệu

2016-01-07 23: 00: 01.000 D: \ Thư mục \ DB_20160108060001.trn Nhật ký

Nó chỉ có vẻ rất mong manh.

Logshipping được kiểm tra và chứng minh kể từ ngày máy chủ sql 2000 (và thậm chí cũ hơn). Nó không dễ vỡ.

Nhìn vào lỗi ...

Tệp được khôi phục lần cuối: \ server \ thư mục \ db_201601050 60002 .trn ,

Logshipping đang cố gắng khôi phục

Đích đến: '\ server \ thư mục \ db_201601050 80001 .trn '

Điều này có nghĩa là bạn có một khoảng cách trong chuỗi nhật ký . Có thể có các bản sao lưu nhật ký adhoc xảy ra đang phá vỡ chuỗi nhật ký.

Tham khảo câu trả lời của tôi - Làm thế nào để vận chuyển Log biết để theo dõi .

Bạn thậm chí có thể Hạn chế người dùng sao lưu CHỈ sao lưu nhật ký , để sao lưu nhật ký adhoc sẽ không phá vỡ chuỗi nhật ký. Cũng thế,

@ Spörri đã tạo một điểm hợp lệ để vô hiệu hóa dịch vụ ghi SQL VSS, để công cụ sao lưu của bên thứ 3 không thể tương tác với SQL. Thật đau đớn khi phát hiện ra điều đó, vì phần mềm của bên thứ 3 đôi khi thật điên rồ !

Để tìm ra những khoảng trống trong bản sao lưu nhật ký của bạn, bạn có thể sử dụng truy vấn bên dưới

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;

Một truy vấn hữu ích khác:

-- 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;