Проверка целостности базы данных sql 1с

Обновлено: 04.07.2024

Рано или поздно это случается. Посыпался рейд, админ случайно удалил базу, при восстановлении наложили базу на другую и т.д. и т.п, вобщем, все те ситуации, для устранения последствий которых необходимо прибегнуть к мерам спасения, а точнее, к восстановлению из резервных копий. Сегодня мы поговорим о вариантах восстановления баз данных из резервных копий на Microsoft SQL Server. Ниже будут рассмотрены варианты для баз с простой и полной моделью восстановления.

Для начала нам понадобятся входные условия. Собственно, вот они:

SERVER-1C на Microsoft Windows Server 2008 R2
SERVER-1C\SERVER1C - экземпляр Microsoft SQL Server 2008 R2
PingvinBuh - потерянная тестовая БД с простой моделью восстановления
PolkaBuh - потерянная тестовая БД с полной моделью восстановления
I:\Архив\PingvinBuh - директория с архивами БД PingvinBuh
I:\Архив\ PolkaBuh - директория с архивами БД PolkaBuh

В прошлых частях мы уже рассматривали модели восстановления для баз данных в Ms SQL Server 2008 R2 и их основные отличия между собой. Для начала попытаемся провести восстановление случайно удаленной БД PingvinBuh , имеющую простую модель восстановления. Процесс восстановления базы данных можно поделить на несколько тривиальных этапов:

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

Создав одноименную базу данных (не забыв установить в ней нужную вам модель восстановлении и указав место хранения файлов .log и .mdf), откройте контекстное меню для всего дерева Базы данных и пройдите в Восстановить базу данных.

В открывшемся окне в Назначение для восстановления укажем В базу данных и выберем PingvinBuh, а в Источник для восстановления выберем С устройства и укажем путь к нашему архиву с БД PingvinBuh. Не забудем отметить выбранный архив галкой Восстановить в Выберите наборы резервных данных для восстановления.

Есть возможность так же выбрать желаемое время восстановление. Оно ограничено временем создания полной резервной копии. За это отвечает опция К моменту времени. Создав полную резервную копию, вы сможете восстановить базу данных на любой момент времени до момента создания этой резервной копии.

В Параметрах восстановления укажем Перезаписать существующую базу данных (WITH REPLACE). Обратим внимание на возможность выбора места. Пути исходных файлов должны быть такие же, как и у новой созданной вами базы. Т.е. при восстановление мы просто запишем поверх этой пустой базы нашу потерянную. Состояние восстановления можно оставить по-умолчанию: Оставив базу данных готовой к использованию, выполнив откат незафиксированных транзакций.

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

Последовательность действий в процессе восстановления базы данных с полной моделью восстановления почти полностью аналогичная вышеописанному, но с небольшими дополнениями.

Для восстановления базы данных PolkaBuh на момент времени, прошедший после последнего резервного копирования требуется в Источник для восстановления указать архивы не только с последней полной резервной копией, но еще и архивы копии журнала транзакции (если они у вас не в одном архиве с полной резервной копией),а в поле Выберите наборы резервных данных для восстановления последовательно отметить полную резервную копию и все журналы транзакции, включающие интересующий вас момент времени.

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

Использование 1С Предприятие в клиент-серверном режиме дает очень много плюсов, к примеру, скорость и надежность работы. Но так же не надо забывать, что СУБД - это отдельная информационная система, которая требует определенного внимания и обслуживания. Мы подготовили основные рекомендации по созданию плана обслуживания баз данных Microsoft SQL Server в которых хранятся информационные базы 1С.

Рекомендуемые регламентные операции СУБД для работы «1С: Предприятие 8» клиент-серверного варианта при использовании СУБД MS SQL Server:

Регулярное резервное копирование баз данных
Обновление статистики
Очистка процедурного КЭШа
Реорганизация индекса
Перестроение индекса

Создание плана обслуживания

Все перечисленные выше операции возможно автоматизировать при использовании Плана обслуживания в Microsoft SQL Server.

Для начала необходимо подключиться к серверу используя Microsoft SQL Server Management Studio (устанавливается отдельно от MS SQL Server); перейти во вкладку «Управление» - «Планы обслуживания» - ПКМ – «Создать план обслуживания…» и задать имя плана.

При создании Плана обслуживания автоматически создаётся Вложенный план, для которого необходимо создать «Расписание задания» через соответствующую кнопку возле таблицы Расписание.

Теперь в наш план необходимо добавить непосредственно сами задачи по обслуживанию. Для этого используем «Панель элементов» (слева от Обозревателя объектов) и добавляем нашу первую задачу «Проверка целостности базы данных».

В задаче «Проверка целостности базы данных» выберем необходимые для обслуживания базы: ПКМ по объекту данной задачи – «Изменить», в открывшемся окне из списка «Базы данных» выбираем необходимые нам базы (все кроме системных или конкретные)

Последующие задание необходимо выбирать исходя из нагрузки и времени выполнения регламентного задания: «Перестроение индекса» или «Реорганизация индекса».

«Перестроение индекса» - включает полное перестроение индексов таблиц базы данных, однако в версии MS SQL Server Standard происходит отключение всех клиентов от базы на время выполнения операции.

«Реорганизация индекса» - исправление уже имеющихся индексов, не требует отключение клиентов от базы

«Реорганизацию индекса» имеет делать смысл каждый день. В то время как полное «Перестроение индекса» лишь раз в неделю.

Добавляем необходимую нам задачу через «Панель элементов» и выбираем необходимые для этой задачи базы.

Далее нам необходимо установить между ними связь: выбираем нашу первую задачу «Проверка целостности базы данных» и кликнув (ЛКМ) на зеленую стрелку вниз (под объектом) протянем её до объекта нашей следующей задачи.

Открыв «Редактор управления очередностью» (2х ЛКМ по появившейся линии связи) мы можем задавать значение выполнения:

Успешное выполнение ( зеленая линия ) – последующие задание будет выполняться только в случае успешного выполнения предыдущего.

Ошибка ( красная линия ) – последующие задание будет выполняться только в случае ошибки выполнения предыдущего задания.

Завершение ( темно-синяя линия ) – последующие задание будет выполняться после предыдущего независимо от результатов выполнения предыдущего.

В данном случае, после успешного выполнения задачи «Проверка целостности базы данных» начнётся выполнение задачи «Реорганизация индекса», если проверка выявила повреждение базы данных, то последующие задачи обслуживания выполнятся не будут.

После «Реорганизации индекса» или «Перестроения индекса» рекомендуется выполнять «Обновление статистик». Добавим соответствующую задачу в «Панели элементов», так же, как и в предыдущий раз не забываем выбрать базы для выполнения задачи и установить связь с предыдущей задачей на «Завершение» после выполнения предыдущей.

Далее добавим задачу по «Очистке процедурного КЭШа», однако такая задача отсутствует в «Панели элементов», поэтому мы добавляем задачу «Выполнение инструкции T-SQL».

Изменим объект «Выполнение инструкции T-SQL» (2х ЛКМ) и в появившемся окне в поле «Инструкция T-SQL» пропишем:

После чего не забываем создать связь для вновь добавленной задачи.

Теперь перейдём непосредственно к созданию резервной копии базы, добавляем соответствующий элемент на «Панели элементов». Открываем параметры задачи (2х ЛКМ по объекту).

На вкладке «Общее» мы можем выбирать необходимый нам тип резервной копии (Полное, Разностное, Журнал транзакций), базы и компонент резервного копирования (базу данных целиком или отдельные её компоненты).

На вкладке «Целевой объект» есть возможность разбить резервную копию на несколько файлов, создавать файл резервной копии и каталоги для каждой базы отдельно, а также указывать путь хранения резервной копии.

На вкладке «Параметры» рекомендуется указать параметр «Сжимать резервные копии» для уменьшения размера бэкапа и «Проверку целостности резервной копии», так же там можно указать срок действия резервного набора и шифрование.

Со временем регулярное создание бэкапов приведет к заполнению дискового пространства, поэтому рекомендуется удалять устаревшие и неактуальные архивы, для этого мы добавим задачу «Очистка после обслуживания».

В ней мы указываем путь до наших бэкапов, расширение файла (в нашем случае стандартное *.bak) и временной промежуток по прошествии которого удалятся старые файлы бэкапов.

Помимо самих бэкапов баз, место на жестком диске могут занимать журналы регламентных заданий MS SQL Server, их мы тоже будем периодически очищать, добавив задачу «Очистка журнала».

В итоге наш «План обслуживания» будет выглядеть следующим образом:

Данные задачи рекомендуется выполнять не реже 1 раза в сутки в часы минимальной загруженности сервера. Мы так же можем добавлять в «Планы обслуживания» дополнительные «Вложенные планы», которые создаются и настраиваются аналогичным образом, если, например, есть необходимость делать бэкапы чаще 1 раза за сутки или раз в неделю проводить полное «Перестроение индекса» вместо регулярной реорганизации.

Просмотреть журнал выполнения «Плана обслуживания» на наличие ошибок возможно через «Просмотр журнала»: «Обозреватель объектов» - «Управление» - «Планы обслуживания» - ПКМ (по плану обслуживания) – «Просмотр журнала».

Отдельно стоит обратить внимание на запуск в системе службы «Агент SQL Server». Данная служба отвечает за выполнение «Планов обслуживания», соответственно, в свойствах службы необходимо проверить чтобы стоял «Тип запуска: Автоматический».

График обслуживания

Периодичность выполнения регламентных операций, рекомендуемая разработчиками «1С: Предприятие 8».

Сразу оговорюсь, что мои познания в T-SQL не сильно велики т. к. по большей части пишу код для конфигураций на платформе 1С:Предприятие, и предложенное решение может быть не совсем оптимальным.

Оптимизация и улучшения предложенного скрипта приветствуется.

Небольшое предисловие.

Часто случается, что базы данных повреждаются, по различным причинам, и мы не всегда это вовремя замечаем.

Что бы проверить базу данных надо зайти в интерфейс, запустить скрипт, получить результат. И уже в зависимости от результата принимать какие-то решения и действия. Возможно это нормально, когда есть свободно время и не лень запустить скрипт вручную. Но что делать когда, к примеру, на поддержке с 10-к и более баз и находятся они на разных серверах. Подключаться к каждому серверу и запускать скрипт руками занимает много времени, да делать это вручную лень.

Для разработчика, администратора и т. п. л ень это двигатель его прогресса, настроил систему как надо и читай логи, письма и прочее оповещения.

Вот после очередного повреждения базы, я опять вернулся к задаче проверки целостности баз по регламенту и рассылке результата на почту. Ранее я уже занимался этой задачей но не доделал, точнее не нашел нужного мне решения.

Это было небольшое предисловие, теперь перейдем к самой задаче.

Целью задачи было: проверять целостность баз данных 1с на сервере SQL по регламенту и при обнаружении поврежденной базы оповещать по почте. Оповещение только если найдена поврежденная база. Состав письма краткий, все данные результата проверки высылать не требуется.

Поиски готового решения в интернете ничего не дали. Нашел всего одно решение, но оно мне не подходит. Кому интересно, можете ознакомится с публикацией Отправляем результаты задания DBCC CHECKDB по электронной почте.

На просторах интернета прочитал, что данные можно вывести в таблицу.

DBCC CHCKDB WITH TABLERESULTS выведет данные в таблицу, но просто так взять и сделать выборку из из этой таблицы нельзя, но выход все же нашелся.

В поисках нужной информации для решения моей задачи наткнулся на публикацию Спасибо тебе R odert Pearl , что ты ее когда то написал.

1. Создаем временную таблицу.

Исходное описание таблицы немного изменено.

Добавлена колонка "DatabaseName".

Изменил типы данных в некоторых колонках, т.к. при первом же тесте получил ошибки о невозможности преобразования типов данных

Колонки: PartitionID, AllocUnitID изменил тип данных с INT на BIGINT ,

Колонка: RepairLevel с INT на VARCHAR(300)

В каких колонках нужно менять тип данных искал методом тыка и исключения.

2. В ранее созданную временную таблицу, при помощи CURSOR , по списку баз, поместим выходные данные DBCC CHCKDB .

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

Результаты DBCC CHECKDB вставляем во временную таблицу

DECLARE @database_name NVARCHAR(50)
DECLARE database_cursor CURSOR FOR

SELECT name
FROM sys.databases db
WHERE name = 'Recovery'
AND db.state_desc = 'ONLINE'
AND source_database_id IS NULL -- REAL DBS ONLY (Not Snapshots)
AND is_read_only = 0

OPEN database_cursor
FETCH NEXT FROM database_cursor INTO @database_name
WHILE @@FETCH_STATUS=0
BEGIN

FETCH NEXT FROM database_cursor INTO @database_name
END

CLOSE database_cursor
DEALLOCATE database_cursor

Результаты DBCC CHECKDB. Выборка уже из временной таблицы

Теперь с данными можно работать, накладывать отборы, делать сортировку и все остальное.

Мне на выходе нужна одна строка с описанием ошибок. Строку собираю из колонок: DatabaseName , MessageText при помощи конкатенации. Дополнительно накладываю условия на ' MessageText ', что бы получить нужные строки, т.к. если база не повреждена данные в выходном наборе все равно будут. Только в тексте будет количество ошибок "0". Мне эти данные не нужны.

DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 10 ошибок согласованности, не связанных ни с одним объектом.
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 30 ошибок согласованности в таблице "_InfoRg23950" (идентификатор объекта 469889041).
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 9 ошибок согласованности в таблице "_Reference12359" (идентификатор объекта 956790716).
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 5 ошибок согласованности в таблице "_InfoRg24673" (идентификатор объекта 1015882886).
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице "_InfoRg9101" (идентификатор объекта 1179359466).
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 57 ошибок согласованности в базе данных "Recovery".

Осталось проверить есть ли у нас в сформированной строке данные, при их наличии отправляем данные на почту.

EXEC msdb.dbo.sp_send_dbmail
@profile_name = @Profilename,
@recipients = @Recipients,
@body = @MSG,
@subject = @Msubject;
END
GO

Проверяем скрипт, все работает.

Создаем Job, настраиваем расписание и готово

DECLARE @database_name NVARCHAR(50)
DECLARE database_cursor CURSOR FOR

SELECT name
FROM sys.databases db
WHERE name = 'Recovery'
AND db.state_desc = 'ONLINE'
AND source_database_id IS NULL -- REAL DBS ONLY (Not Snapshots)
AND is_read_only = 0

OPEN database_cursor
FETCH NEXT FROM database_cursor INTO @database_name
WHILE @@FETCH_STATUS=0
BEGIN

FETCH NEXT FROM database_cursor INTO @database_name
END

CLOSE database_cursor
DEALLOCATE database_cursor

Итак в продолжении темы обслуживания баз 1С присмотримся к системе управления реляционными базами данных Microsoft SQL Server. Этот продукт предоставляет нам большие возможности обработки, хранения, резервирования и восстановления баз. Я начну небольшой цикл статей, посвященных этой теме. Все, что будет написано ниже, является личным мнением по данному вопросу и подлежит критике.

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

Сервер Windows Server 2008 Enterprise: SRV-1C-TEST.
Microsoft SQL Server 2008: SRV-1C-TEST.
Тестовая база BuhFirma.

Проводить обслуживание базы в период 00:30 - 01:00, при этом обслуживание не должно быть заметным (либо слабозаметным) для пользователей базы.

Начнём с важных моментов. MS SQL база данных может иметь один из трех типов модели восстановления:

Простая.
Полная.
С неполным протоколированием.

Так же при резервном копировании нам предоставляется на выбор три варианта копирования:

Полное.
Разностное.
Копирование журнала транзакций (логов).

При полном варианте копирования происходит сохранение базы mdf и журнала транзакций. Разностное копирование (по-другому дифференциальное) производит копирование данных, изменившихся с момента создания последней полной резервной копии. Копирование журнала транзакций соответственно производит сохранение только самого журнала транзакций.

При выборе простой модели восстановить базу данных можно с момента создания последней разностной или полной резервной копии. При выборе полной модели восстановления мы можем восстанавливать базу до минуты, создав полную резервную копию, например, ночью, и в течение дня создавать копии журнала транзакции. Ниже мы увидим, где всплывает этот момент. Хотелось так же привести некоторые выдержки из MSDN: "Модель восстановления с неполным протоколированием предназначена исключительно как дополнение к модели полного восстановления. В общем случае модель восстановления с неполным протоколированием похожа на модель полного восстановления, за исключением того, что протоколирование большинства массовых операций в ней производится в минимальной степени".

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

В MSSQL 2008 по умолчанию в созданных базах данных модель восстановления Полная.

Как выбрать модель восстановления? Надо лишь ответить на вопрос: смертельна ли потеря информации за время, прошедшее после полного резервного копирования? Если ответ да, тогда выбираем полную модель восстановления, если нет, простую. Модель с неполным протоколированием стоит применять только на время массовых операций в БД.

Таким образом, если вы выбрали простую модель, то восстановить данные вы сможете только на момент ночного полного или разностного копирования, а всю информацию после этого пользователи будут восстанавливать вручную. Выбирая Полную модель, вы обязательно должны делать резервное копирование журнала транзакций, иначе логи будут сильно расти. При любой модели восстановления вы всегда должны иметь полную резервную копию.

В начале создадим ночной план обслуживания базы, который будет включать в себя последовательность следующих действий:

Проверка целостности базы
Перестроение индекса
Обновление статистики
Очистка процедурного кэша СУБД
Резервное копирование базы данных
Очистка после обслуживания
Очистка журнала

Для этого подключимся к MSSQL серверу с помощью среды Microsoft SQLServer Management Studio. Запустить среду можно перейдя в Пуск - Все программы - Microsoft SQL Server 2008.

Подключимся с серверу SQL и перейдем в Управление - Планы Обслуживания. Кликнем правой кнопкой по Планы обслуживания и выберем Создать план обслуживания. Дадим ему имя: SRV1CTEST.

Перед нами окно SRV1CTEST, в котором мы и будем создавать последовательность действий, обозначенных раннее. Сразу видим появившейся Вложенный_План1. Справа от названия вложенного плана вы увидите иконку в виде таблички. Нажимаем на нее и попадаем в свойства расписания задания. Здесь можно менять название вложенного плана, выставить частоту повторения в Ежедневно и установить время. И так теперь осталось наполнить наш план заданиями. Для этого с Панели инструментов, которая находится справой стороны, перетаскиваем задания.

После того, как вы перетащили задание, щелкните по нему два раза. Откроется окно, в котором в строке Базы данных мы выбираем созданную нашу базу BuhFirma. Далее таким же образом добавляем задания Перестроение индекса и Обновление статистики, не забыв выбрать в них нужную базу данных.

Процедура Перестроение индекса пересоздает индекс с новым коэффициентом заполнения. За счет этого мы увеличиваем производительность работы в БД.

Задача Обновление статистики обновляет сведения о данных таблиц для MS SQL. Что тоже повышает производительность. Но после этой операции надо обязательно проводить очистку кэша.

Пока остановимся и поговорим о настройке связей между заданиями. Связи отражают последовательность выполнения. Что бы провести связь между заданиями надо нажать один раз на задание и увидите появившуюся стрелку. Её надо перетащить на следующее задание. У связи может быть 3 цвета: синий, зеленый и красный, каждый из которых означает три типа срабатывания перехода: при простом завершении предыдущего задания - Завершение, в случае успешного завершения - Успех, а в случае возникновения ошибки при выполнение предыдущего задания - Ошибка. Все эти параметры вы можете увидеть, нажав правой кнопкой мыши на проведенную между заданиями стрелку. Таким образом, если нам надо, чтобы Перестроение индекса срабатывало только после успешного завершения задания Проверка целостности базы данных, мы должны связать их стрелкой. Нажав правой кнопкой мыши на стрелку, сменим ее режим на Успешно, как видим, ее цвет изменился на зеленый.

На данный момент мы имеем 3 созданных задания в нашем вложенном плане. Как вы могли заметить, задания Очистка процедурного кэша СУБД в панели элементов нету. Мы воспользуемся задачей Выполнение инструкции T-SQL. Перетащим ее в план, и щелкнем на ней два раза. Мы видим окно, в которое впишем следующее:

Нажмем ОК. Далее стоит добавить задание задачу Резервное копирование базы данных. Так же щелкнув на добавленном задании, увидим опции настройки задания.

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

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

Задача Очистка журнала производит удаление данных журнала, связанных с процессами резервного копирования, восстановления, планами обслуживания баз, а также с деятельностью агента SQLServer.

Таким образов в конце мы получим список последовательно выполняемых задач.

Сохранив план обслуживания, надо удостовериться в том, что на нашем сервер запущен Агент SQL Server. Для этого перейдем в Пуск - Все программы - Microsoft SQL Server 2008 - Средства настройки - Диспетчер конфигурации SQL Server. Перейдя на строчку Службы SQLServer, проверим, что служба Агент SQLServer находится в состоянии Работает и режим запуска выставлен в Авто.

В конце хотелось бы сказать о том, что использование задачи Перестроение индекса можно заменить или совместить с задачей Реорганизация индекса. Реорганизация индекса представляет собой инструмент для дефрагментации индексов. Для того что бы просмотреть какие операции требуются индексу, необходимо просмотреть физическую статистику индекса. Для этого правой кнопкой мыши нажмите на базу данных, перейдите в Отчеты - Стандартные отчеты - Физическая статистика индекса.

Следить за состоянием выполняемых операций вы можете из Управление - Планы обслуживания. Для этого в свойствах плана SRV1CTEST выберите Просмотр журнала. Так же можно просмотреть журнал, который ведет Агент MS SQL по этому заданию. Для этого перейдите на строку Агент MS SQL и в свойствах задания SRV1CTEST выберите Просмотр журнала.

Читайте также: