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

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

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

Мне было поручено выяснить, почему простой план обслуживания на этом сервере дает сбой, ТОЛЬКО когда НЕ запускаются полные резервные копии. Я немного покопался и определил, что виноват в том, что мой журнал транзакций заполняется (статически установлено на 20 ГБ, а затем на 40 ГБ после первого раунда сбоев задания). Я также пришел к выводу, что наша текущая модель восстановления (простая) - плохая идея для производственного SQL-сервера и должна быть переведена либо на пакетную, либо на полную. Я также провел мониторинг использования файла журнала (%) и заметил, что файл журнала минимально (менее 1%) используется в рабочие часы и заполняется только после завершения обслуживания. Успешный простой план обслуживания потребляет от 40% до 80% транзакций. Ошибка приведет к исчерпанию журнала. Какая еще информация вам нужна?

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

Среда сервера: SQL Ent 2005 x64 (9.0.3080) с SSRS на Windows Server 2003 R2 x64. Полное резервное копирование выполняется на всех БД M-F. Основная оперативная база данных имеет 10-минутную разницу в производственном / рабочем времени и простую модель восстановления. Простой план обслуживания запускается каждые 24 часа. В файловой системе: основная оперативная база данных составляет ок. 70 ГБ, индексные файлы (из них 4) имеют размер ок. 2 ГБ, транслог - 40 ГБ. Полные резервные копии составляют около 50 ГБ

Нет репликации или зеркалирования.

Я смотрю на задание, и его тип указан как пакет SSIS. Имеет ли это смысл?

Задачи выполнения: Целостность базы данных - Включить индексы Перестроить индексы - Свободное место по умолчанию на странице - Результаты сортировки в статистике обновления tempdb - Только статистика столбца - Полная очистка обслуживания сканирования - Удаление файлов: текстовые отчеты плана обслуживания - Возраст: старше 2 недель Очистка истории - Удаление файлов: резервное копирование и восстановление, история заданий агента SQL Server, история планов обслуживания - возраст: старше 2 недель

Пожалуйста помогите. Любая помощь приветствуется.

Эта статья Symantec Connect об использовании попытки выяснить стратегию резервного копирования для различных моделей восстановления SQL должна помочь. Даже если вы не используете Backup Exec, все это актуально и применимо к другим моделям резервного копирования, в том числе при использовании инструментов SQL для создания дампов БД для резервного копирования: http://www.symantec.com/connect/forums/be2012-backing-sql-databases-full-simple-recovery-mode-issue