Проверка целостности базы данных sql 1с
Сразу оговорюсь, что мои познания в 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', использую для разных целей. Сегодя она играет роль поврежденной базы данных. Результ ее проверки и поместим во временную таблицу.
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
Теперь с данными можно работать, накладывать отборы, делать сортировку и все остальное.
Мне на выходе нужна одна строка с описанием ошибок. Строку собираю из колонок: 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
EXEC msdb.dbo.sp_send_dbmail
@profile_name = @Profilename,
@recipients = @Recipients,
@body = @MSG,
@subject = @Msubject;
END
GO
Поступила жалоба от бухгалтера о проблемах с проведением документов в 1С.
Из скриншота выяснилось, что 1С «ругается» на проблемы с согласованностью «внутри» базы данных и предлагает провести проверку на согласованность.
Переходим в SQL Server Management Studio и, сделав, на всякий случай, бэкап текущего состояния, выполняем проверку:
Для начала переводим нужную нам БД в однопользовательский режим
Запускаем Окно запросов (CTRL+N). Выбираем Новый запрос и вводим запрос Transact-SQL (T-SQL) в этом окне:
Далее, вводим запрос на сканирование базы данных:
Проверка продлилась около 15 минут, после чего выдала следующее:
CHECKDB обнаружил 0 ошибок размещения и 766 ошибок согласованности, не связанных ни с одним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysdbfiles" (идентификатор объекта 20).
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysxmlcomponent" (идентификатор объекта 91).
CHECKDB обнаружил 0 ошибок размещения и 49 ошибок согласованности в таблице "_AccRg1025" (идентификатор объекта 1778313595).
CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице "_AccRgAT21046" (идентификатор объекта 1826313766).
CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице "_AccRg1051" (идентификатор объекта 1906314051).
CHECKDB обнаружил 0 ошибок размещения и 2603 ошибок согласованности в базе данных "KA".
Вариант решения №1: восстановление из бэкапа выявило накопительный характер ошибки: чем раньше сделан бэкап – тем меньше в базе ошибок, вплоть до самого «дальнего» (14 дней). Примерно на третьем бэкапе количество ошибок перестало уменьшаться – стало ясно, что этим путём мы придём только к потере актуальности базы и проблему не решить
Вариант решения №2: В справочной информации описаны три возможных варианта исправления этих ошибок, рассмотрим каждый:
REPAIR_FAST
Синтаксис поддерживается только для обеспечения обратной совместимости. Действия по восстановлению не выполняются.
REPAIR_REBUILD
Выполняет действия по восстановлению данных, которые можно выполнить без риска их потери. Это может быть быстрое восстановление (например, восстановление отсутствующих строк в некластеризованных индексах) или более ресурсоемкие операции (например, перестроение индекса).
REPAIR_ALLOW_DATA_LOSS
Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.
Аргумент REPAIR_FAST нам не подходит, REPAIR_ALLOW_DATA_LOSS оставим на крайний случай - пробуем REPAIR_REBUILD:
CHECKDB обнаружил 0 ошибок размещения и 766 ошибок согласованности, не связанных ни с одним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysdbfiles" (идентификатор объекта 20).
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysxmlcomponent" (идентификатор объекта 91).
CHECKDB обнаружил 0 ошибок размещения и 49 ошибок согласованности в таблице "_AccRg1025" (идентификатор объекта 1778313595).
CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице "_AccRgAT21046" (идентификатор объекта 1826313766).
CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице "_AccRg1051" (идентификатор объекта 1906314051).
CHECKDB обнаружил 0 ошибок размещения и 2603 ошибок согласованности в базе данных "KA".
Не помогло, переводим базу данных обратно в многопользовательский режим:
На всякий случай, я попробовал провести обслуживание базы данных и перепроверил – результат тот же.
Решил провести тестирование и исправление информационной базы средствами 1С, на что получил ошибку
Выгрузить базу данных в *.dt файл тоже не удалось:
Что ж, стало понятно, что часть потерянных данных – меньшее зло, по сравнению с «развалившейся» базой данных, пробуем REPAIR_ALLOW_DATA_LOSS:
И, наконец, после нескольких прогонов, количество ошибок немного уменьшилось:
CHECKDB обнаружил 0 ошибок размещения и 733 ошибок согласованности, не связанных ни с одним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysdbfiles" (идентификатор объекта 20).
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysxmlcomponent" (идентификатор объекта 91).
CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице "_AccRg1051" (идентификатор объекта 1906314051).
CHECKDB обнаружил 0 ошибок размещения и 2518 ошибок согласованности в базе данных "KA ".
Ситуацию это не спасло: база, по-прежнему не выгружалась и не «лечилась» средствами 1С.
Дальнейшие попытки (по очереди несколько раз запускал REPAIR_REBUILD и REPAIR_ALLOW_DATA_LOSS) не увенчались успехом: количество ошибок не уменьшилось, база, по-прежнему, не выгружалась и не «лечилась».
Коллеги подсказали попробовать очистить (именно очистить, без удаления самой таблицы) «проблемную» таблицу в MS SQL.
Больше всего ошибок в таблице "_AccRg1051" – ей и было принято решение заняться:
И, после успешного выполнения, прогоняем проверку еще раз:
15 минут ожидания и, о чудо – все ошибки исчезли, в том числе и в остальных таблицах.
Перевожу базу в многопользовательский режим, выгружаю в *.dt файл и загружаю обратно.
Звоню бухгалтеру – прошу проверить проблемные документы: всё работает нормально. Пускаю остальных пользователей в базу.
Через час снова ошибка:
Делаем вывод, что выгрузка в *.dt – не панацея. Выгоняем Вежливо просим пользователей выйти и ещё немного потерпеть и тестируем базу с исправлением ошибок в режиме конфигуратора 1С со следующими параметрами
Видим, что всё ОК
Пускаем обратно пользователей в 1С и идём молиться настраивать планы обслуживания баз данных.
Использование 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».
Итак в продолжении темы обслуживания баз 1С присмотримся к системе управления реляционными базами данных Microsoft SQL Server. Этот продукт предоставляет нам большие возможности обработки, хранения, резервирования и восстановления баз. Я начну небольшой цикл статей, посвященных этой теме. Все, что будет написано ниже, является личным мнением по данному вопросу и подлежит критике.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
В данной статье рассмотрен процесс создания планов обслуживания баз. Оповещение оператора, а так же пример восстановления базы рассмотрим в следующих статьях.
- Сервер Windows Server 2008 Enterprise: SRV-1C-TEST.
- Microsoft SQL Server 2008: SRV-1C-TEST.
- Тестовая база BuhFirma.
Проводить обслуживание базы в период 00:30 - 01:00, при этом обслуживание не должно быть заметным (либо слабозаметным) для пользователей базы.
- Простая.
- Полная.
- С неполным протоколированием.
- Полное.
- Разностное.
- Копирование журнала транзакций (логов).
При полном варианте копирования происходит сохранение базы mdf и журнала транзакций. Разностное копирование (по-другому дифференциальное) производит копирование данных, изменившихся с момента создания последней полной резервной копии. Копирование журнала транзакций соответственно производит сохранение только самого журнала транзакций.
При выборе простой модели восстановить базу данных можно с момента создания последней разностной или полной резервной копии. При выборе полной модели восстановления мы можем восстанавливать базу до минуты, создав полную резервную копию, например, ночью, и в течение дня создавать копии журнала транзакции. Ниже мы увидим, где всплывает этот момент. Хотелось так же привести некоторые выдержки из MSDN: "Модель восстановления с неполным протоколированием предназначена исключительно как дополнение к модели полного восстановления. В общем случае модель восстановления с неполным протоколированием похожа на модель полного восстановления, за исключением того, что протоколирование большинства массовых операций в ней производится в минимальной степени".
Модель восстановления своей базы вы можете посмотреть, зайдя в свойства базы данных, например BuhFirma и перейдя на строку - Параметры.
Как выбрать модель восстановления? Надо лишь ответить на вопрос: смертельна ли потеря информации за время, прошедшее после полного резервного копирования? Если ответ да, тогда выбираем полную модель восстановления, если нет, простую. Модель с неполным протоколированием стоит применять только на время массовых операций в БД.
Таким образом, если вы выбрали простую модель, то восстановить данные вы сможете только на момент ночного полного или разностного копирования, а всю информацию после этого пользователи будут восстанавливать вручную. Выбирая Полную модель, вы обязательно должны делать резервное копирование журнала транзакций, иначе логи будут сильно расти. При любой модели восстановления вы всегда должны иметь полную резервную копию.
В начале создадим ночной план обслуживания базы, который будет включать в себя последовательность следующих действий:
- Проверка целостности базы
- Перестроение индекса
- Обновление статистики
- Очистка процедурного кэша СУБД
- Резервное копирование базы данных
- Очистка после обслуживания
- Очистка журнала
Для этого подключимся к 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 выберите Просмотр журнала.
- Обслуживание баз 1С в MS SQL Server. Часть 1. Настройка планов обслуживания БД.
- Обслуживание баз 1С в MS SQL Server. Часть 2. Оповещение по e-mail.
- Обслуживание баз 1С в MS SQL Server. Часть 3. Восстановление из резервных копий.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Проверка целостности баз данных SQL при помощи DBCC CHECKDB, автоматическое исправление поврежденных индексов в таблицах данных и оповещение о повреждении баз данных и результатах исправления на e-mail.
На разработку данного кода повлияло несколько факторов:
1. При работе с ежедневным обслуживанием баз мы используем широко известные скрипты Ola (//infostart.ru/public/1234180/ . О необходимости их детекта и ежедневного отслеживания сказано там же, но в нашем случае этот прискорбный случай произошел после очередного обновления Windows на сервере, приведшего к неудачному выключению сервера (процесс шатдауна завис, ничего не сделав, никакие методы не помогли, рубить пришлось "железно"). Как выяснилось в дальнейшем, за промежуток времени до регламентных работ в индексах базы данных, с которой постоянно идет работа, произошли ошибки, приведшие к постоянным крахам процессов и переполнению каталога с логами и дампамиSQL сервера. Утром вся работа на предприятии встала. При ручной проверке индексы, к сожалению, нормально ребилдиться без предварительного их отключения не захотели, эта ситуация уже описывалась и ранее по поиску в интернете.
3. Для того, чтобы все-таки избежать по возможности подобных случаев и не проходить вручную по неисправным индексам или отключать базу и ребилдить ее без пользователей, искалось решение, которое обработабывало бы результаты проверки базы данных и исправляло только поврежденные таблицы (экономя время в автоматическом режиме в еженочных планах обслуживания в случае обнаружения таких ошибок, либо помогало при обработке вручную).
В процессе из наиболее близкого здесь же была найдена уже упомянутая статья Анатолия Симакова, за что отдельное спасибо, всем рекомендую ознакомиться с ней, там более подробно описано первоначальное назначение модуля, послужившего прообразом - повторяться не буду.
К этому алгоритму был добавлен блок с исправлением таблиц методом отключения индексов и их перестроения с последующим включением и интегрирован код с учетом использования нами ставшими стандартами
Читайте также: