Назад | Перейти на главную страницу

Сбой резервного копирования SQL Server 2005

У меня база данных в модели полного восстановления. Резервные копии журнала транзакций этой базы данных (запланированные с помощью плана обслуживания) не работают каждую ночь.

Вот инструкция CREATE базы данных и т. Д.:

USE [master]
GO
/****** Object:  Database [Gatekeeper]    Script Date: 05/18/2009 15:31:26 ******/
CREATE DATABASE [Gatekeeper] ON  PRIMARY 
( NAME = N'Gatekeeper_dat', FILENAME = N'F:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\Gatekeeper.mdf' , SIZE = 20480KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
 LOG ON 
( NAME = N'Gatekeeper_log', FILENAME = N'E:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\Gatekeeper.ldf' , SIZE = 10240KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
 COLLATE SQL_Latin1_General_CP1_CI_AS
GO
EXEC dbo.sp_dbcmptlevel @dbname=N'Gatekeeper', @new_cmptlevel=90
GO
IF (1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled'))
begin
EXEC [Gatekeeper].[dbo].[sp_fulltext_database] @action = 'enable'
end
GO
ALTER DATABASE [Gatekeeper] SET ANSI_NULL_DEFAULT OFF 
GO
ALTER DATABASE [Gatekeeper] SET ANSI_NULLS OFF 
GO
ALTER DATABASE [Gatekeeper] SET ANSI_PADDING OFF 
GO
ALTER DATABASE [Gatekeeper] SET ANSI_WARNINGS OFF 
GO
ALTER DATABASE [Gatekeeper] SET ARITHABORT OFF 
GO
ALTER DATABASE [Gatekeeper] SET AUTO_CLOSE OFF 
GO
ALTER DATABASE [Gatekeeper] SET AUTO_CREATE_STATISTICS ON 
GO
ALTER DATABASE [Gatekeeper] SET AUTO_SHRINK OFF 
GO
ALTER DATABASE [Gatekeeper] SET AUTO_UPDATE_STATISTICS ON 
GO
ALTER DATABASE [Gatekeeper] SET CURSOR_CLOSE_ON_COMMIT OFF 
GO
ALTER DATABASE [Gatekeeper] SET CURSOR_DEFAULT  GLOBAL 
GO
ALTER DATABASE [Gatekeeper] SET CONCAT_NULL_YIELDS_NULL OFF 
GO
ALTER DATABASE [Gatekeeper] SET NUMERIC_ROUNDABORT OFF 
GO
ALTER DATABASE [Gatekeeper] SET QUOTED_IDENTIFIER OFF 
GO
ALTER DATABASE [Gatekeeper] SET RECURSIVE_TRIGGERS OFF 
GO
ALTER DATABASE [Gatekeeper] SET  DISABLE_BROKER 
GO
ALTER DATABASE [Gatekeeper] SET AUTO_UPDATE_STATISTICS_ASYNC OFF 
GO
ALTER DATABASE [Gatekeeper] SET DATE_CORRELATION_OPTIMIZATION OFF 
GO
ALTER DATABASE [Gatekeeper] SET TRUSTWORTHY OFF 
GO
ALTER DATABASE [Gatekeeper] SET ALLOW_SNAPSHOT_ISOLATION OFF 
GO
ALTER DATABASE [Gatekeeper] SET PARAMETERIZATION SIMPLE 
GO
ALTER DATABASE [Gatekeeper] SET  READ_WRITE 
GO
ALTER DATABASE [Gatekeeper] SET RECOVERY FULL 
GO
ALTER DATABASE [Gatekeeper] SET  MULTI_USER 
GO
ALTER DATABASE [Gatekeeper] SET PAGE_VERIFY CHECKSUM  
GO
ALTER DATABASE [Gatekeeper] SET DB_CHAINING OFF 

Вот сообщение об ошибке из плана обслуживания:

Executing the query "BACKUP LOG [Gatekeeper] TO  DISK = N'C:\\Program Files\\Microsoft SQL Server\\MSSQL.1\\MSSQL\\Backup\\Gatekeeper\\Gatekeeper_backup_200905180100.trn' WITH NOFORMAT, NOINIT,  NAME = N'Gatekeeper_backup_20090518010003', SKIP, REWIND, NOUNLOAD,  STATS = 10
" failed with the following error: "BACKUP LOG cannot be performed because there is no current database backup.
BACKUP LOG is terminating abnormally.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

Вот соответствующий код из плана обслуживания:

EXECUTE master.dbo.xp_create_subdir N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\Gatekeeper'
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N'Gatekeeper' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'Gatekeeper' )
if @backupSetId is null begin raiserror(N'Verify failed. Backup information for database ''Gatekeeper'' not found.', 16, 1) end
RESTORE VERIFYONLY FROM  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\Gatekeeper\Gatekeeper_backup_200905190812.trn' WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND
GO

Вы не можете делать резервные копии журналов, если нет полной резервной копии базы данных в качестве их «основы». Если вы только что перешли на модель ПОЛНОГО восстановления, базы данных на самом деле не будет, пока вы не сделаете первую резервную копию базы данных - она ​​останется в псевдо-простом режиме.

Кроме того, если вы сделаете что-то, чтобы разорвать цепочку резервного копирования журнала, как упоминалось в UndertheFold, вам необходимо восстановить цепочку резервного копирования журнала с помощью другой полной резервной копии.

[Edit] Вы можете узнать время, когда была сделана последняя резервная копия вашей базы данных, используя этот запрос:

ВЫБЕРИТЕ [backup_start_date], [backup_end_date] ИЗ msdb.dbo.backupset ГДЕ [тип] = 'D' И [имя_базы_данных] = 'GateKeeper' ЗАКАЗАТЬ ПО [backup_start_date] DESC;

или чтобы перечислить все резервные копии и их типы (сделанные после того, как таблицы истории резервного копирования были очищены вручную):

ВЫБРАТЬ [backup_start_date], [backup_end_date], [type] FROM msdb.dbo.backupset WHERE [database_name] = 'GateKeeper' ЗАКАЗАТЬ ПО [backup_start_date] DESC;

D = резервная копия базы данных, L = резервная копия журнала, I = разностная резервная копия базы данных.

Дополнительная информация в электронной документации по «резервному набору»

Надеюсь это поможет

Есть еще один источник ошибок: доставка журналов может помешать процессу резервного копирования журналов, если вы поместите файлы для доставки журналов в другую папку.

Полная последовательность резервных копий журналов, начиная с последней полной резервной копии базы данных, должна находиться в том же месте (папке).

Перед резервным копированием журнала необходимо выполнить полное резервное копирование. http://support.microsoft.com/kb/928317

Согласно опубликованному вами журналу, для журналов транзакций невозможно создать резервную копию, поскольку не создается резервная копия самой базы данных. Выполняется ли резервное копирование основной базы данных перед попыткой резервного копирования журналов транзакций?

Я опубликовал в вашем дублирующем сообщении, но ошибка в опубликованном вами журнале указывает на то, что база данных не копируется до того, как будут созданы журналы транзакций. Включает ли план обслуживания задачу по резервному копированию самой базы данных?

Это может быть связано с выполнением дополнительных шагов, которые здесь не упоминаются, например

  • резервное копирование журнала с помощью truncate_only

  • или вы перешли из режима ПОЛНОГО или БЕСПЛАТНОГО восстановления на ПРОСТОЙ