Настройка Microsoft SQL Server для 1С Предприятие (Maintenance Plans)
Доброго времени, гости и читатели блога k-max.name. Сегодня публикую небольшую мемори-записку о настройке Microsoft SQL 2005 для 1С Предприятия. Думаю для других нужд использования MS SQL данная статья тоже даст некоторую информацию. Итак, начнем…
Шаг 0. Перед установкой и настройкой MS SQL 2005 желательно иметь 3 физических диска. Один – для системы, второй – для файлов баз и третий – для журналов транзакций SQL. При этом, раздел для логов SQL и tempdb желательно чтобы был более производительным (например RAID 1+0).
Шаг 1. Установка сервера MS SQL
При установке SQL-сервера для работы с 1С достаточно следующих включенных компонентов (более подробно о компонентах Microsoft SQL тут, об установке серера тут):
На данном изображении:
– Integration services – не обязательный элемент – необходим для управления пакетами SSIS (планами обслуживания (экспорт/импорт)), потом его можно будет отключить
– Database Servises – собственно сам сервер СУБД
– Client Component – Managment Tools – утилита управления
Остальные настройки при установке по Вашему вкусу. Единственный нюанс – необходимо правильно установить способ сортировки collate. Для автоматической и правильной работы необходимо в “Языке и региональных стандартах” операционной системы выбрать “Русский”. В этом случае при установке SQL Server сам предложит правильную сортировку Cyrillic_General_CI_AS. Выбор режима проверки подлинности пользователей укажите смешанный (mixed). Остальные параметры всегда можно скорректировать после установки – 1С:Предприятие будет работать независимо от них.
Более подробно об установке (ахтунг – English):
Желательно обновить сервер MS SQL до актуального релиза (на текущий момент – SP4 для 2005 SQL). Кроме того, на многопроцессорных системах сервер Microsoft SQL 2005 может отказаться устанавливаться с ошибкой 1053 (The error is (1053) The service did not respond to the start or control request in a timely fashion). Решение этой проблемы описано тут.
Шаг 2. Настройка сервера Microsoft SQL 2005
2.1. Настройка протоколов подключения
Для настройки протоколов взаимодействия сервера и клиента Microsoft SQL необходимо запустить “SQL Server Configuration Manager”:
…и оставить для работы только протоколы TCP/IP и Shared Memory:
Если устанавливается версия MS SQL Express по-умолчанию выключен протокол TCP/IP, нужный для работы с 1С:Предприятие 8 – его необходимо включить. Протокол именнованных каналов (Named Pipe) выключите совсем (и для “клиента” тоже на сервере приложений).
2.2. Перенос tempdb на быстрый независимый массив/диски
Для переноса tempdb необходимо запустить sql-скрипт примерно следующего содержания:
USE master GO ALTER DATABASE tempdb modify file (NAME=tempdev, FILENAME='E:\Temp\tempdb_data.mdf') GO ALTER DATABASE tempdb modify file (NAME=templog, FILENAME='E:\Temp\tempdb_log.ldf') GO
где, E:\Temp\ – каталог, в котором будут лежать tempdb, а tempdb_data.mdf и tempdb_log.ldf имя файла базы данных и лога соответственно.
2.3. Настройка параметров сервера SQL
Для настройки сервера запускаем “SQL Server Management Studio”, подключаемся к установленному серверу Database Engine‘ом и открываем свойства (Server Properties). Тут нам нужно настроить 3 пункта:
Память (Memory)
Параметр “Maximum server memory (in MB)” задает максимально отведенное серверу количество памяти из расчета: [Общее количество оперативной памяти сервера] – [3ГБ под систему(1,5ГБ если Win2k3)] – [сколько_нужно ГБ * количество процессов работающих на данном сервере (если SQL еще какой-то важный сервис крутится на этом же сервере)]. Например, если у нас на сервере всего 24 ГБ оперативной памяти, стоит Windows 2003 и запущен сервер 1С Предприятия с 2мя процессами rphost (которым нужна память хотябы по 1,5Гб) то рассчет будет следующим: 24 – 1,5 – 1,5*2 = 19,5 ГБ ставит параметр “Maximum server memory (in MB)”. Это необходимо для того, чтобы sql-сервер рассчитывал на заданный объем и освобождал память заблаговременно, т.к. если поставить неограниченный объем, и сервер попробует получить память, которой нет, он начинает лезть в файл подкачки, что сильно замедлит работу.
Процессоры (Processors)
Максимальное количество потоков (Maximum worker threads) стОит регулировать только при большом количестве клиентов (более 255) и для 1С это не актуально, поэтому оставим по-умолчанию. (хотя некоторые утверждают обратное 
). Также выставляем галку повышенного приоритета сервера (Boost SQL Server priority).
Database Settings
В данном пункте можно настроить каталоги для файлов Данных и логов, чтобы новые базы данных создавались именно там.
2.4. Дополнительные “приседания”
Желательно просканировать СКЛ утилитой SQL Server 2005 Best Practices Analyzer и избавиться от ошибок и сообщений (как? и еще раз как?).
Шаг 3. Настройка рабочих баз данных Ms SQL
Если база еще не развернута из .dt файла, и вы знаете примерный ее размер, то первичному файлу размер инициализации лучше сразу указать больший или равный размеру базы, но это дело вкуса, он все равно вырастет при развертке до нужных размеров. А вот Автоувеличение (Autogrowth) размера надо обязательно указать примерно по 200 МБ на базу и по 50 МБ на лог (можно увеличить/уменьшить, в зависимости от размера конечной базы и наличия места на диске), т.к. значения по умолчанию – рост по 1МБ и по 10% очень сильно тормозят работу сервера, когда ему при каждой 3й транзакции надо файл увеличивать. В этом же параметре можно ограничить размер файла лога, чтоб сильно не разрастался, хотя это очень спорный параметр…
Остальные параметры можно оставить по умолчанию, за исключением некоторых:
Например, параметр AutoShrink советуют отключить, ибо он приводит к постоянным скачкам размера лога. Лучше его держать в узде с помощью Планов обслуживания (они же Регламентные задания, они же Maintenance Plans).
Шаг 4. Настройка Планов обслуживания (Maintenance Plans, Регламентных заданий)
Для работы регламентных заданий необходимо создать план обслуживания:
Итак, приведу свой пример настроенного Maintenance Plans с комментариями. Мой план состоит из 5 подпланов:
Первый подплан (ежедневное еженочное обслуживание сервера и резервных копий):
Данный подплан состоит из нескольких шагов. Связи зеленого цвета задают переход к следующему заданию при удачном завершении (т.е. без ошибок), связи синего цвета задают переход к следующему заданию при любом результате выполнения текущего. Параметры шагов видны на размещенных в редакторе заданиях. Параметры некоторых заданий нужно описать отдельно. Первым шагом выполняется “Проверка целостности базы данных” (Check Database Integrity Task), которая выполняется для всех баз системы и следующие задания выполняются только при отсутствии ошибок при проверке баз. Следующим шагом выполняется “Перестроение индексов баз данных” (Rebuild Index Task) для всех баз данных сервера. Данная процедура довольно ресурсоемкая, но в последствии ускоряет работу базы, т.к. если фрагментированость индексов > 25%, это резко снижает производительность сервера. Если размер баз не позволяет выполнять данную задачу, т.к. она занимает много времени, то рекомендуется делать данное действие хотябы раз в неделю, при этом, на ночные задания заменить задачу Перестроение индексов баз данных (Rebuild Index Task) на Дефрагментацию индекса (Reorganize Index Task), которая менее ресурсоемка. Далее происходит “Обновление статистики базы данных” (Update Statistics Task) для всех баз данных, опять же для оптимизации. После этого задания рекомендуется выполнить “Очистку процедурного кэша“:
При этом, запускается процедура
DBCC FREEPROCCACHE
После оптимизации работы желательно сделать резервную копию журналов транзакций. Этот шаг делать не обязательно, но желательно. Во время выполнения предыдущих шагов (Перестроение индексов баз данных (Rebuild Index Task) и Обновление статистики базы данных (Update Statistics Task)) файлы журналов вырастают примерно до размера базы данных, а то и более. В результате, в следующих подпланах при выполнении первого резервного копирования журнала транзакций, размер копии имеет довольно большой объем. Это может сильно увеличить вермя восстановления базы. Таким образом, делая копию логов до полной копии, мы избавляемся от данной проблемы. (спасибо за идею комментатору Kyoshiro)
Далее можно выполнить полный бэкап заданием Создание резервной копии базы данных (Back Up Database Task):
При выполнении данного задания копии складываются в сетевую папку на файловом сервере с расширением bak, при этом, для каждой базы создается своя папка:
SAMBA ~ # ls -1 /backup/full/ database1 database2 ... SAMBA ~ # ls -1 /backup/full/satabase1/ database1_backup_201111210250.bak database1_backup_201111220251.bak ...
После заверешения создания резервной копии параллельно запускается 3 задания: очистка резервных копий журналов транзакция (о создании таких копий – ниже) старее 5 дней, очистка полных бэкапов старее 1 недели и очистка истории старше 1 месяца (сюда входит в основном – очистка служебной информации MS SQL, такой как журналы):
Данный подплан у меня запускается каждую ночь в нерабочее время по будням:
Второй, третий, четвертый подплан (обновление статистики 3 раза в день):
Следующие 3 подплана одинаковы по содержимому и различаются лишь временем выполнения. Выполняются 3 раза в день – в 6, 13 и 19 часов:
Обновление статистики довольно ресурсоемкая задача, поэтому спланируйте ее выполнение в то время, когда база данных не сильно загружена.
Пятый подплан (резервное копирование журнала транзакций):
Данный план выполняет инкрементальное копирование транзакционного лога Microsoft SQL Server:
Копирование выполняется каждые пол часа в рабочее время и сохраняется в сеть с расширением trn:
После настройки данного плана мы имеем регулярное резервное копирование с необходимым регламентным обслуживанием, с хранением копий базы данных за последние 7 дней с возможностью восстановления базы интервалом до 30 минут.
Более подробно о выборе и планировании плана обслуживания можно посмотреть данный подкаст(временно убран по причине заражения сайта s.rpod.ru):
Шаг 5. Траблешуттинг
Периодически необходимо анализировать фрагментированность индекса для снижения нагрузки. Для больших баз данных нужно уменьшать ненужные операции по дефрагментации тех индексов, для которых это не требуется. То есть дефрагментацию выполнять не для всей базы, а для избранных таблиц, например. Если значение avg_fragmentation_in_percent в этом столбце превышает 25%, то для восстановления исходных параметров производительности рекомендуется выполнить дефрагментацию/реиндексацию этого индекса. Чтобы просмотреть текущую фрагментированность, можно воспользоваться отчетом:
Для настроенного плана регламентных заданий периодически желательно просматривать историю на наличие ошибок и устранять их:
FAQ MS SQL для 1С Предприятие
В связи с частыми одинаковыми вопросами в комментах решил добавить FAQ.
Q: Сегодня настроил SQL и создал план обслуживания. Все в точности по данной статье, но бэкапы не создаются. Почему? (ведь настроено создание бэкапов каждые 30 минут)
A: Потому что бэкапы каждые 30 минут создают копии журналов транзакций. Данный вид копий может создаваться только от полной копии. Соответственно, пятый подплан (бэкап лога транзакций) будет выполнен только после выполнения первого подплана и только после удачного выполнения шага полного бэкапа в первом подплане!!! Соответственно, выход из ситуации – дождаться выполнения первого подплана.
Q: Почему файл жарнала транзакций растет? Как от этого избавиться? Что делать?
A: Самый правильный выход из ситуации – увеличить раздел жесткого диска, на котором размещен файл журнала. Уменьшать размер файла с помощью операции shrink только вызовет лишние обращения сервера к жесткому диску. Сервер увеличивает размер этого файла до того размера, который ему необходим для выполнения транзакций. Соответственно, обрезав файл журнала мы заставляем SQL сервер лишний раз насиловать жесткий диск – снова увеличивая размер журнала при очередной ресурсоемкой транзакции. Данный нюанс я обсуждал в этой теме – советую перечитать ее. Есть еще выход – “если не очень сыкотно – можно перед ребилдом делать “финальный” бакап (можно только логов), ставить симпл модель, после ребилда – возвращать фулл рекавери и опять делать фулл бакап” отпять же отсюда (с).
Q: Почему не делается shrink для лога? многие советуют…
A: см предыдущий вопрос\ответ
Дополнительно почитать:
– обслуживание базы данных MS SQL (регламентные задания и резервное копирование) от мекрософт тут и тут.
– установка MS SQL 2005
– Лучшие советы по эффективному обслуживанию баз данных
– Настройка почтовых уведомлений об ошибках выполнения плана MS SQL серера
Удачных Вам бэкапов
upd 2012.12.09: добавлен FAQ
С Уважением, Mc.Sim!
Другие материалы в категории Windows
- Ошибка 0x80004005 0x80070035 на Windows 10 при доступе к сетевой папке
- Удаление неиспользуемого оборудования (драйверов) Windows
- This application failed to start because msvcr71.dll was not found. (скачать msvcr71.dll)
- Ошибка установки OpenOffice 3 на Windows 7 через MSI и GPO
- HOWTO SAMBA на 2 интерфейса и 2 сети с разными smb.conf
- Acrobat Reader печатает кракозябры
- SQUID аутентификация (Kerberos и LDAP) на основе доменных групп Active Directory
- Аутентификация и авторизация squid (basic, Digest, NTLM, negotiate)
- Настройка Database Mail в MS SQL 2005 для уведомления об ошибках
- Настройка Microsoft SQL Server для 1С Предприятие (Maintenance Plans)
Спасибо за статью. Познавательно.
Вот вопрос по “ночному бэкапу” у вас сначала выполняется проверка базы данных, потом переиндексация и очистка кэша. А не случается ли так что во время выполнения переиндексации происходит сбой? не лучше ли сразу после проверки выполнить бэкап? или есть какие-то другие беглонезримые основания для такой схемы?
За статью пожалуйста.
Проверка базы делается как раз для того, чтобы переиндексация не порушила поломанную базу. Если во время переиндексации произойдет сбой, то база продолжит работать, но без корректного индекса, что немного скажется на скорости и не более.
При создании копий журнала транзакций я указал время с 8.00 до 23.59. А так же при условии что ночное обслуживание запускается в 00.30 – это позволит в случае каких-либо проблем с СУБД при ночном обслуживании откатиться как раз к моменту перед ночным обслуживанием.
Где то я читал что переиндексация вызывает неявную транзакцию и что в случае неудачи все состояние базы откатывается. Но в целом стретегия понятна.
Вот еще вопрос, возможно покажется слишком наивным. Но я не могу понять в какой момент “обнуляется” лог транзакций?
Лог транзакций обнуляется при завершении “Пятый подплан (резервное копирование журнала транзакций):” каждые пол часа.
Ага понятно и в это же время происходит создание контрольной точки. Так как очистка журнала подразумевает запись “грязных страниц” на диск.
Спасибо за ответы.
Пожалуйста! Приходите еще!
Еще вопрос, я не совсем понял процесс создания контрольных точек. Настройку частоты создания контрольных точек нужно выполнять через тот же Maintenance Plans? или же это параметр который задается где-то в настройках сервера?
Что имеется ввиду под “контрольными точками”?
Контрольные точки это момент когда страницы загруженные и измененные в памяти ОЗУ начинают записываться обратно на жесткий диск, тем самым освобождая процесс восстановления из лога транзакций, в случае внезапного отключения питания.
Ясно
Об этом хорошо рассказано в видео-подкасте.
Спасибо за отличную статью.
Есть пара вопросов:
Первый – сделал примерно такую же схему, как у тебя. В результате после переиндексации сильно растет лог и получается, что первый бэкап лога после полного бэкапа базы становится очень большим. Ты как-то с этим боролся?
Второй вытекает из первого – если я восстановлю полный бэкап (который после переиндексации), а следом восстановлю лог, сервер ведь не будет производить все операции, что записаны в логе?
По первому вопросу есть мысль, что нужно перед полным бэкапом снимать бэкап лога, тогда следующий лог будет маленьким, соответственно мы сможем быстрее восстановиться из бэкапа. Я правильно мыслю?
C большим размером лога я тоже столкнулся. Но после долгах обсуждений на форумах – оставил как есть.
Как вариант мне посоветовали – перед переиндексацией делать “финальный” бакап (можно только логов), ставить Simple модель в базе данных, после переиндексации – возвращать Full и опять делать полный бэкап.
Но что-то я побоялся ставить эксперименты с переключением режимов восстановления и оставил как есть.
По второму вопросу – сервер будет делать все, что описано в логе, ибо переиндексация – логируемая операция.
Если под словом “снимать” имеется ввиду – пропускать/удалять лог, то восстановление последующих логов будет невозможно.
“Снимать”, в данном случае – делать бэкап.
Как это делать всё? Бэкап же сделан после переиндексации. Как он может всё заново сделать? Я думал там метки какие-то и скуль относительно них накатывает лог, т.е. ищет в логе место, которое после бэкапа, и оттуда начинает проводить операции.
Хм… А ведь действительно, во время полного бэкапа создается контрольная точка… И теоретически после полного бэкапа – бэкап лога должен быть минимален.
На следующей недели попробую выполнить Вашу идею:
Я был очень удивлён, когда это оказалось не так.
Дополнил статью еще одним шагом обслуживания. Спасибо за идею, Kyoshiro!
Мне кажется ты делаешь дописываюший лог транзакций, попробуй поменять на перезапись(overwrite).
можно об этом поподробней?
При создании задания резервного копирования лога, если выбирать сохранение в один или более файлов, есть опция “если файл резеврной копии существует – if backup file exist” и действия “дописывать – append” или “перезаписывать – overwrite”.
Я лично не обратил на этот пункт никакого внимания, но после того как увидел размер лога, начал было суетится и решил отключить резервную копию этого лога, потом обратил внимание на эту опцию, выбрал перезапись и размер лога стал более вменяемый.
Это при создании копии “на устройство”, а в моем примере создается копия в сетевой каталог, поэтому нет такой опции.
Да в твоем случае каждый бэкап делается в отдельный файл. А вот как у Kyoshiro это делается?
У меня тоже на сетевую шару.
Отличная статья, оч познавательно.
Поделитесь, каким образом вы боретесь с фрагментацией бд?.
У меня три базы, в двух из них фрагментация не превышает 2%, а с третьей базой (торговля), просто беда. Фрагментация растет и уже составляет 67%. План обслуживания проходит без ошибок, в конфигураторе 1с тоже выполнял все нужные операции, а воз и ныне там.
Давайте определимся о чем мы говорим? Что есть “Фрагментация бд” в вашем вопросе?
Имеется ввиду фрагментация индекса?
Именно о ней идет речь
Дефрагментация в моем случае не делается. НО при ночном обслуживании делается “Перестроение индексов баз данных” (Rebuild Index Task). То есть весь индекс полностью удаляется и создается по новой. По идее он должен создаваться без фрагментации, но тем не менее, на некоторых таблицах в базе данных 1С торговли у меня фрагментация индекса зашкаливает. Но в целом, производительность не падает, даже при зашкаливающих процентах фрагментации на некоторых таблицах. Например, dbo._AccumRg5048 фрагментация некоторых индексов 50%, в dbo._AccumRg7072 – 88% ну и т.д.
Аналогично, с производительностью проблем нет, просто хотелось довести до “идеала”. Спасибо за конструктивный ответ.
Пожалуйста! Буду рад Вас видеть снова тут.
Если найдете решение, которое доведет до идеала – буду благодарен и внесу в статью
Добрый день.
Цитирую:MS SQL 2005 желательно иметь 3 физических диска. Один – для системы, второй – для файлов баз и третий – для журналов транзакций SQL.
А если у меня 8 дисков – все в рейде 10,разделены на 3 логических диска.Даст ли какой-нибудь прирост разнесение данных и логов на разные лог.диски?
Если на 3 логических разбит силами венды, то прирост производительности очень спорный, а если силами RAID разбит на LUN, то прирост будет, но все же лучше разделить их на раздельные RAID.
Mc.Sim, а размер лога в настройках базы данных ограничивать стоит или нет?
и ещё вопрос, модель восстановления у вас полная стоит?
Думаю, что в ограничении смысла большего – нет. Т.к. если лог захочет вырасти больше ограниченного размера, то выдаст пользователям ошибку, чтоо размер лога ограничен и выкинет пользователя.
модель восстановления установлена Full. На скриншоте это видно: https://www.k-max.name/wp-content/uploads/2011/11/SQL-server-options-database.png
Привет!
Столкнулся с проблемой бэкапа логов, он не хочет делать без фулл бэкапа. Это можно как то обойти?
привет. На сколько я знаю, журналы могут бэкапиться только в фулл и bulk logged модели восстановления. http://msdn.microsoft.com/ru-ru/library/ms189275.aspx
есть большой и важный вопрос. нужен человек хорошо понимающий защиту базы 1с с помощью SQL и как ее обойти. возможен заработок) скайп vzlom1cSQL
в MSSQL не глубоко силен…
Видео-подкасте неработает.
Да, действительно… Может поправят со временем…
Спасибо за статью
. Хочу настроить план обслуживания. Но не знаю, как уменьшить файл транзакций. В настоящее время при размере базы 53Гб, файл транзакций занимает 175Гб. Выполняется ежедневное полное копирование базы. Копии добавляются в резервный набор. + ещё вопрос: Хоть в параметрах и стоит, что действие резервного набора истекает через 2 дня, но он он всё равно пополняется, пока не забъёт весь диск. Есть информация по настройке резервного копирования с использованием резервных наборов или этим лучше не пользоваться?
175 Гб для лога такой базы – довольно нормальный размер, особенно если обрабатываются большие таблицы из базы. С резервным набором дела иметь не приходилось, поэтому вряд ли подскажу…
И под рукой sql пока, к сожалению, нет (
Как вариант – бэкапить логи каждый час (или чаще).
А чем не устраивает тот метод, который я в статье описал?
Большое спасибо! Настроил план обслуживания по предлагаемой схеме, но лог был 175Гб и меньше не стал (размер базы 60Гб). Пробовал в ручную выставить размер лога в свойства базы – ставлю 50Гб, но он автоматически меняется 110Гб. Есть подозрение на незавершенные транзакции. Как в этом убедиться и как избавиться?
Доброго времени, Юрий!
Уменьшать размер лога крайне не рекомендуется. Это скажется на производительности. MS SQL использует лог такого размера, который ему необходим для работы.
Тут выход только использовать simple модель, вместо full логирования.
Лог продолжает расти и уже мешает выполнению плана обслуживания (недостаточно места на диске). У меня MSSQLSRV2008. Нашел следующий способ обрезки физического файла транзакций:
USE ИмяБазы
ALTER DATABASE ИмяБазы SET RECOVERY SIMPLE
DBCC SHRINKFILE (ИмяФайлаЛога, ЖелаемыйРазмер);
ALTER DATABASE ИмяБазы SET RECOVERY FULL
Пробовал – работает. Что думаете, добавить как выполнение инструкции T-SQL в план обслуживания? Напр. после бэкапа лога, перед бэкапом баз???
Добрый день, Юрий.
На Вашем месте я бы добавил еще жестких дисков.
В данной теме (http://www.sql.ru/forum/actualthread.aspx?tid=859632) я обсуждал похожую проблему. Для интереса можно почитать.
В целом, вам предложенное решение – вполне себе решение, но опасное.
Туда-сюда (SIMPLE – FULL) переключать режим базы данных – можно все порушить ).
ДА и смысл FULL модели восстановления при выполнения данного скрипта несколько размывается.
Лично я решаю проблему больших логов так – не даю им разростаться бесконтрольно. Не ограничиваю размер лога – это тупо, просто перестанет работать база. Делаю регулярный бекап логов (например каждые 5-60 минут). Бекап логов их урезает. Он конечно размер файла логов менять не будет :). Но и расти лог перестанет. Так как если файл лога скажем 1 гиг, но после бекапа логов данных там остается 10 метров, то к следующему бекапу логов их обьем до 1 гига просто не доростает, и опять обрезается бекапом лога. Таким образом файл лога определяется на какой-то отметке и потом просто не увеличивается.
Варианты с доп винтами и сменой модели бекапарования по моему мнению от невозможности найти другие решения :).
Большое спасибо за статью!
позвольте задать дополнительные вопросы по настройве SQL Server:
1) под какими пользователями должны запускаться службы SQL server
2) как настроить возможность резервного копирования в сетевые папки
спрашиваю потому как есть проблемы с сетевыми доступами (в/из сервера)
Если безопасность не стоит на первом месте, то можно запустить под отдельно созданной учеткой с правами администратора домена с хорошим паролем.
Если безопасность критична, то придется долго приседать с настройкой прав и разрешений для учетки.
В статье описана возможность бэкапа в сетевые папки.
Пути, которые задаются на шаге 4 являются сетевыми.
Спасибо за статью – оч полезная инфа, только вот проблема с бэкапами…. сделал все как вы описали, только бэкапы не делаются никакие…. папки создались, отчеты пишуться а бэкапов нет, хотя пишет что бэкап прошел успешно
Сколько времени прошло с момента создания плана?
больше дня, нажимаю execute на плане бэкапа – ничего не происходит, и чтото не дошло как делать подплан, точнее как его создать
Подожди сутки. Я думаю, что пока у тебя не выполнится полный бэкап – ничего не появится в каталогах.
План создается кликом правой кнопкой мыши на подраздел Maintenance Plans в разделе Management. И выбрать Create (если я не ошибаюсь…)
Спасибо, подождем день-два, будем посмотреть) а вот создать подплан так и не нашел(
и мне не план надо создать, а подплан))))
Спасибо, будем смотреть)
только чтото нету у меня таких кнопочек(((
скриншот в студию.
http://s018.radikal.ru/i518/1209/96/d11d36d790b6.jpg
Ох как интересно… А что за версия SQL? 2000?
да нет, 2005
А что показывает меню Help – About?
2005й пишет
Microsoft SQL Server Management Studio 9.00.1399.00
Microsoft Analysis Services Client Tools 2005.090.1399.00
Microsoft Data Access Components (MDAC) 2000.086.3959.00 (srv03_sp2_rtm.070216-1710)
Microsoft MSXML 2.6 3.0 5.0 6.0
Microsoft Internet Explorer 8.0.6001.18702
Microsoft .NET Framework 2.0.50727.3634
Operating System 5.2.3790
А натяни ка ты себе SP4 http://www.microsoft.com/en-us/download/details.aspx?id=7218
надо попробывать будет, сервак перегружать не надо будет? ато у меня народ в 1Ске висит))))
Перегружать будет нужно. Мало того, не один раз. Возможно, потребуется установка SP1, SP2, SP3 последовательно перед SP4.
эмммм, до 3 СП включительно у меня все стоит. Значит вечером буду пробывать ставить и эксперементировать)
Версия 9.00.1399.00 – это версия без сервис паков.
Возможно, что просто установлена Management Studio старая…
Новую можно взять с дистрибутива MS SQL SP4.
Спасибо, заработало))) делает бэкапы каждую ночь))))
Всё настроил по инструкции ,но бэкапов нет, можно ли расчитывать на Вашу помощь по удаленному доступу к нашему серверу? Вохможно таким способом можно сэкономить кучу времени.
Сколько времени прошло после создания планов обслуживания?
Начало плана обслуживания поставили на 1 ночи, прошло уже 13 часов с указанной даты.
Первые копии будут созданы только после выполнения первого полного резервного копирования.
вопрос следующий, не делает бэкап транзакций…..
вот репорт:
Microsoft(R) Server Maintenance Utility (Unicode) Version 9.0.1399
Report was generated on “SERVER”.
Maintenance Plan: MaintenancePlan
Duration: 00:00:00
Status: Warning: One or more tasks failed..
Details:
Back Up Database (Transaction Log) (SERVER)
Backup Database on Target server connection
Databases: All databases
Type: Transaction Log
Append existing
Task start: 10.09.2012 16:11.
Task end: 10.09.2012 16:11.
Failed:(-1073548784) Executing the query “BACKUP LOG [model] TO DISK = N’D:\\Backup\\Transact\\model\\model_backup_201210091611.trn’ WITH NOFORMAT, NOINIT, NAME = N’model_backup_20121009161146′, 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.
Command:EXECUTE master.dbo.xp_create_subdir N”D:\Backup\Transact\master”
GO
EXECUTE master.dbo.xp_create_subdir N”D:\Backup\Transact\model”
GO
EXECUTE master.dbo.xp_create_subdir N”D:\Backup\Transact\msdb”
GO
EXECUTE master.dbo.xp_create_subdir N”D:\Backup\Transact\AdventureWorksDW”
GO
EXECUTE master.dbo.xp_create_subdir N”D:\Backup\Transact\AdventureWorks”
GO
EXECUTE master.dbo.xp_create_subdir N”D:\Backup\Transact\WORK”
GO
BACKUP LOG [model] TO DISK = N”D:\Backup\Transact\model\model_backup_201210091611.trn” WITH NOFORMAT, NOINIT, NAME = N”model_backup_20121009161146”, SKIP, REWIND, NOUNLOAD, STATS = 10
А сейчас?
Тож самое
Ну вообще, в логе сообщение “BACKUP LOG cannot be performed because there is no current database backup.” говорит о том, что бэкап лога не может быть выполнен, т.к. не выполнен бэкап базы данных. Нужно смотреть, что за ошибка при полном бэкапе и выполнился ли он вообще…
Через пару дней все начало делаться нормально, бэкап баз делался а вот транзакций нет, и почемуто проходит неделя и все – план не работает.
Заново создал план. Будем смотреть. Просто раньше стояло почемуто target server connection, а не Local, может быть проблема была в этом?
А что в логах было, когда бэкап не выполнялся?
ничего не было – писало что все прошло усчпешно. сейчас бэкап не делается….
Сейчас пишет при нажатии Execute следующие:
Execute Maintenance Plan
– Execute maintenance plan. Service (Error)
Messages
* Execution failed. See the maintenance plan and SQL Server Agent job history logs for details.
——————————
ADDITIONAL INFORMATION:
Execution failed. See the maintenance plan and SQL Server Agent job history logs for details. (SqlManagerUI)
приветствую, anonim2005.
SQL нам как бы намекает, посмотреть лог выполнения задания для большей информации “See the maintenance plan and SQL Server Agent job history logs for details.”. ))
Покажите скриншот лога выполнения
заданийплана обслуживания. еще можно настроить уведомления от SQL сервера.Чтобы вручную на отслеживать ошибки.
А почему Вы нигде и никогда не делаете шринк базе?
Советуют что надо делать, только не могу понять куда его втавить в ваш план обслуживания (ночной субплан)?
Приветствую, Сергей.
Добавил FAQ – там ответ.
Спасибо за интересную статью!
Но есть вопрос по разрастающемуся лог файлу.
Он растет в одном из первых 3 заданий (Первый подплан (ежедневное еженочное обслуживание сервера и резервных копий))
Что делать?
igor, добавлен FAQ содержащий ответ.
День добрый. Спасибо за интересную и полезную статью!
Установлен SQL 2008 r2. При создании данного плана ночью создались фуллы, а у транзакций только папки с названиями баз. Однако, днем “поперло”. Но вместо ожидаемого ежеполу-часно подрастающего файла обнаружил кучу мелких. С чем окромя радиуча кривизны рук может быть связано?
На кошках всё работало (30 минутку там не использовал).
Вопрос номер два – почему не используем проверку полученных бэкапов?
ДимДим,
приветствую.
> ожидаемого ежеполу-часно подрастающего файла
ожидания были не верны. )))
Для каждого архива создается отдельный файл. Мне это было удобно, тк.к позволяет визуально контролировать количество, объем и время созданных бэкапов.
> почему не используем проверку полученных бэкапов?
дабы не создавать лишнюю нагрузку на сеть, диски и СУБД. Ну и я не совсем могу представить ситуацию, когда архив может получиться битым…
А почему после Ребилда индексов не уменьшается их процент фрагментированости?
процент смотрю при помощи кода:
DECLARE @db_id SMALLINT;SET @db_id = DB_ID(N'BASE_NAME');
SELECT * FROM sys.dm_db_index_physical_stats (@db_id, NULL, NULL, NULL, NULL) ORDER BY avg_fragmentation_in_percent ASC;
GO
ЗЫ отчет не работает, т.к. уровень совместимости базы, 2000.
мне тоже был интересен ответ на этот вопрос )
Почему-то на моей базе, по которой писал данную статью изначальный процент фрагментированности был около 60-70%. После обслуживания стал около 23-25% и ниже не снижался. Скорей всего это вопрос к разработчикам 1С.
Здравствуйте!
Спасибо за подробную статью.
Сделал все по инструкции, но есть ошибки на шаге Перестроения индекса. Не могли бы Вы пояснить в чем причина. Привожу последнюю часть лога.
Источник: Задача “Перестроение индекса” Выполнение запроса “USE [buh] “.: 0% завершено Конец выполнения Выполнение: 2013-12-03 00:04:51.22
Источник: Задача “Перестроение индекса” Выполнение запроса “ALTER INDEX [_Acc16_ByField480_SR] ON [dbo].[_Acc1…”.: 0% завершено Конец выполнения Выполнение: 2013-12-03 00:04:51.22
Источник: Задача “Перестроение индекса” Выполнение запроса “USE [buh] “.: 0% завершено Конец выполнения Выполнение: 2013-12-03 00:04:51.22
Источник: Задача “Перестроение индекса” Выполнение запроса “ALTER INDEX [_Acc16_ByOrder_SR] ON [dbo].[_Acc16] …”.: 0% завершено Конец выполнения Выполнение: 2013-12-03 00:04:51.22
Источник: Задача “Перестроение индекса” Выполнение запроса “USE [buh] “.: 0% завершено Конец выполнения Выполнение: 2013-12-03 00:04:51.23
Источник: Задача “Перестроение индекса” Выполнение запроса “ALTER INDEX [_Acc16_ByParentCode_RSR] ON [dbo].[_A…”.: 0% завершено Конец выполнения Выполнение: 2013-12-03 00:04:51.23
Источник: Задача “Перестроение индекса” Выполнение запроса “USE [bu… Не удалось выполнить п… Шаг завершился с ошибкой.
Добрый день.
К сожалению, не видно полного текста сообщения.
Добрый день! У меня база mdf 26Г, а логи 279Г.Модель базы полная.Ежедневное сохранение. Размер bak файла 34Г. И вот после последнего обновления конфигурации базы архив вырос до 92Г. Встречались ли Вы с таким и как справиться, как посмотреть что такое лишнее добавляется в bak файл? В содержании архива вижу только свою базу. Да сохраняем Backup with init,nounload. Спасибо за ответ
Вероятно, при обновлении конфигурации 1С произвела какие-то манипуляции по резервированию таблиц БД. Как вариант, можно выгрузить базу силами 1С в md файл и попробовать импортировать в новую созданную чистую базу. Теоретически, размер должен уменьшиться.
Добрый день! Размер файлов базы и файла транзакции mdf и ldf вообще не меняется, т.к. базу перенесла на отладочный сервер,а размер сохраняемого bak файла катастрофически растет, при базе 26Г и файл транзакций 289Г, размер full buckup -179Г.Уже перестраивала средствами 1С таблицы, выгружала базу, загружала, увеличение размеров buckup идет еще интенсивнее. Просто катастрофа!
Думаю, что это говорит лишь о том, что клиенты довольно интенсивно работают с базой. Когда я администрировал 1С порядок цифр был примерно таким же… база – 40, логи – 300. при этом, выгруженный dt файл был около 2Гб. Вообще, пользуйтесь архиватором. Логи особенно хорошо жмутся.
Добрый день!
Нашел вашу статью уже после того как сам сделал план заданий.
Вкратце – sql 2008 r2;
Создал два плана, перед этим обрезав лог:
В воскресенье в 2 ночи делается Обслуживание – ЧекДБ, Перестройка индекса – Обновление статистики – DBCC FREEPROCCACHE – (уже отсюда скопировал – Копия журнала) – Очистка журнала и удаление старых баков
Также в воскресенье в 12 ночи делается полный бак; раз в день в 12 ночи (кроме вск) – дифференцированный бак; и раз в час по будням – бак журнала.
Так вот после операции Обслуживания (в 2 ночи) лог вырос в 10 раз (местами и больше mdf). И при дальнейших снятиях баков не уменьшается. Подскажите что в таком случае делать? По всем прочитанным статьям лог должен был урезаться – но не уменьшился ни разу
ВНИМАНИЕ!
Для всех, задающих вопросы про логи, я специалоно выделил красным в FAQ:
Q: Почему файл жарнала транзакций растет? Как от этого избавиться? Что делать?
A: Самый правильный выход из ситуации – увеличить раздел жесткого диска, на котором размещен файл журнала. Уменьшать размер файла с помощью операции shrink только вызовет лишние обращения сервера к жесткому диску. Сервер увеличивает размер этого файла до того размера, который ему необходим для выполнения транзакций. Соответственно, обрезав файл журнала мы заставляем SQL сервер лишний раз насиловать жесткий диск – снова увеличивая размер журнала при очередной ресурсоемкой транзакции. Данный нюанс я обсуждал в этой теме – советую перечитать ее. Есть еще выход – “если не очень сыкотно – можно перед ребилдом делать “финальный” бакап (можно только логов), ставить симпл модель, после ребилда – возвращать фулл рекавери и опять делать фулл бакап” отпять же отсюда (с).
Добрый день! Пробую задать вопрос еще раз. Файл базы и файл логов растет очень медленно, но оно и понятно были праздники и народ почти не работал. НО!!! Архивирование базы едет ежедневно. так вот файл бак растет гараздо быстрее файлов лога и базы. Выгружаю ,базу в DT, загружаю в новую базу и все класс, bak файл размером с MDF и файл логов не растет. Модель базы SIMPLE. Странно, неужели с этим никто не сталкивался? Я уже предпологаю, что несмотря на то, что у меня при архивировании в BAK, стоит INIT, где глюк в SQL server и он делает NOINIT, но я бы это наверно видела при просмотре содержимого архива. Спасибо
Ольга, покажите полную команду (Transact-SQL) для создания архива?
ДОБРЫЙ ДЕНЬ! Команда архивации сама простая, может Вы увидете увидите что не так…
osql /Q “BUCKUP DATABASE [TTT] TO DISK= N’E:\TTT.BAK’ WITH INIT, NOUNLOAD, NAME=N’TTT BACKUP’,NOSKIP,STATS=10,NOFORMAT” /U SA /P 12345
Есть несколько вопросов:
1. зачем указан NOUNLOAD? Это же параметр для лент?
2. Кроме BUCKUP DATABASE у вас выполняется BACKUP LOG?
3. Какая версия сервера SQL?
Добрый день! Nounload это вроде действительно лишнее, но как бы не должно мешать. а сохранение логов не делаем, но дело в том, что размер файла лога не меняется, вернее меняется ,но незначительно, т.к.модель Simple а размер архива BAK увеличивается на несколько ГБ ежедневно. спасибо за внимание к вопросу
Дополнительно для будущей оптимизации, Microsoft рекомендует (http://technet.microsoft.com/ru-ru/library/ms162806(v=sql.100).aspx) вместо osql использовать sqlcmd.
Если я правильно понял конечную задачу: иметь последнюю копию базы в файле E:\TTT.BAK и при следующем архивировании перезаписывать имеющуюся копию новой (независимо от заголовков и времени устаревания существующей резервной копии). Могу порекомендовать следующий набор параметров.
BUCKUP DATABASE [TTT] TO DISK= N’E:\TTT.BAK’ WITH INIT, NAME=N’TTT BACKUP’,STATS=10,FORMAT» /U SA /P 12345Ну или оставить имеющийся набор параметров без nounload, но добавить EXPIREDATE = ‘date’ или RETAINDAYS = days. Которые укажут, сколько времени хранить созданную копию.
Да, сервео 2008, только нет обновления
Ольга, оба Ваши комментария опубликованы. Видимо страница у вас из кеша загружалась. Выше, я написал свои рекомендации.
Прочитала Ваши комменты через RSS. попробую. Меня только смущает FORMAT. Команда не начнет форматировать весь носитель? мы архивируем на тот же диск, где и база и только потом переносим архив. Спасибо
Я сам не пользовался форматом, но на сколько я понял, данная опция очищает именно E:\TTT.BAK.
Если страшно, то можно следовать этому совету:
В таком случае INIT должен отработать корректно.
возможно “Второй, третий, четвертый подплан (обновление статистики 3 раза в день)” можно было совместить в одном подплане – в расписании выставить – выполнять каждые 6 часов в период с 7:00 до 20:00
Да, вполне.
Но мне удобней явно задать время, т.к. оно выпадает на минимальную нагрузку на базу.
при попытке воспользоваться отчетом (шаг 5) выходит ошибка
Error:
Incorrect syntax near ‘(‘.
прошу подсказать с чем это связано.
Увидеть бы скриншот ошибки…
Могу предположить, что у вас не соответствует версия SQL Server Management Studio и SQL сервера.
скриншот ошибки – https://drive.google.com/file/d/0B1uhKDMeGeb1anEwSjhFOXlQckk/edit?usp=sharing
версия
Microsoft SQL Server Management Studio 9.00.5000.00
Microsoft Analysis Services Client Tools 2005.090.5000.00
Microsoft Data Access Components (MDAC) 2000.086.3959.00 (srv03_sp2_rtm.070216-1710)
Microsoft MSXML 2.6 3.0 5.0 6.0
Microsoft Internet Explorer 8.0.6001.18702
Microsoft .NET Framework 2.0.50727.3655
Operating System 5.2.3790
Aidar, проблема еще актуальна?
да, еще актуальна
Тогда, кроме версии Microsoft SQL Server Management Studiо, покажите версию самого SQL сервера?
Microsoft SQL Server 2005 – 9.00.5000.00 (Intel X86) Dec 10 2010 10:56:29 Copyright (c) 1988-2005 Microsoft Corporation Workgroup Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
Даже затрудняюсь что-либо сказать… В таких случаях говорят – попробуйте переустановить ОС )))
А если серьезно, можно попробовать спросить на форуме sql.ru.
Но в целом, я склоняюсь к ошибке при установке либо managment studio, либо самого SQL сервера.
Клиент-сервер 1С. Windows server 2012. SQL server 2012. Возникает проблема конфликт блокировок и не дает проводить документы, помогает только рестарт сервера 1С. В журнале windows пишет что Система Windows обнаружила, что файл регистра используется другими приложениями или службами. Связано это с увеличение лог файла? Сама База 4 гига, лог около 50 гигов.
Это связано с недостаточной производительностью вашего сервера.
Здравствуйте, подскажите как сделать и где прописать, что бы была возможность сохранять на сетевой диск.
Здравствуйте.
В данной статье как раз рассматривается сохранение резервных копий на сетевой диск.
Точнее будет сказать – в сетевую папку.
Здравствуйте. Подскажите пожалуйста чайнику))
В журнале приложений выскакивает часто сообщение: “Автоматическое увеличение размера файла “Base1C2011_log” в базе данных “BASE1C” было отменено пользователем или истек период его ожидания после 15569 миллисекунд. Командой ALTER DATABASE установите меньшее значение FILEGROWTH для этого файла или явно задайте его новый размер”
Значения стоят по умолчанию (1Мб и 10% для лога).
Какое лучше поставить значение? База 3Гб, лог 21Гб
База растет максимум 0.5Гб в год.
Спасибо.
Думаю, что можно поставить рост файла в 50 или 100Мб. Следите за свободным местом на диске с логом.
Сделал по Вашему примеру план обслуживания. Подскажите пожалуйста, почему не выполняется подплан “Ночное обслуживание”? Точнее, выполняется операция проверки целостности с успехом и далее джобик завершает свою работу. При этом ошибок в логе никаких нет, т.е. до дефрагментации дело вообще не доходит. (MSSQL 2012 R2)
Вопрос еще актуален?
Добрый день уважаемый. Использую 1C 7.7 в связке c MSSQL 2005 SP4 на w2k3 x64. Терминальный сервер, одноранг. 50 пользователей.
В примере настройки базы у вас стоит Model: FULL и Compatibility level – 90.
У меня в базе 7.7, Simple и 80, соответственно. Размер базы 14 Гб. Тормозит сильно.
Хотел оптимизировать работу сервера и по жестким дискам и по настройкам, согласно вашего руководства.
1й вопрос: могу ли я поставить модель FULL для базы 1с 7.7? и что это даст? У меня 5й шаг из вашего плана обслуживания “Бэкап логов” пишет что базы с Simple моделью восстановления будут пропущены.
2й вопрос: могу ли я уровень совместимости повысить до 90?
Я с 7.7 SQL не работал, но принцип описанный в статье, думаю, будет полезен.
ответ на первый вопрос: то, что бэкап логов не делается для FULL – это нормальное поведение. Т.к. логов как таковых нет. Да, для того чтобы план обслуживания работал, необходимо переключить в режим FULL.
Имейте ввиду, что файл лога будет занимать значительное место, возможно в несколько раз больше базы.
ответ на второй вопрос: повышать уровень совместимости нет никакой необходимости. К тому же, 7.7 может некорректно взаимодействовать или вообще не работать с таким режимом. Я могу ошибаться, нужно читать документацию 1С, которой у меня нет.
День добрый, после каждого ночного обслуживания журнал транзакций выростал по 6-7 гигов, бэкапы ЖТ не помогали, убрал шаг “Перестроение индексов баз данных” вроде стало норм? Насколько важен этот шаг? В вашем уроке написано что можно заменить эту задачу на “Дефрагментацию индекса” не могли бы вы подробнее описать функции этих задач? Или в чем их отличия?
Перестроение индекса – это его удаление и создание с нуля.
Дефрагментация – это его оптимизация. Можно заменить перестроение на дефрагментацию.
База 11 гиг, лог 780 гиг. База синхронизирована с другим сервером в режиме высокой безопасности. Соответственно модель восстановления Полная. Что можно придумать в данном случае для уменьшения лога?
В данном случае, нужно смотреть в сторону приложения, которое делает транзакции, увеличивающие лог.
P.S. при условии, что полное резервное копирование и резервное копирование логов не уменьшает размер.
После недельных бэкапов логов и фул бэкапов баз, запустил сжатие баз и о чудо – лог с 780 гиг сжался до 29 гиг.
А нонче лог ужался до размера базы. Таким образом получается, что делая полный бэкап логов транзакций, как в комплексе – ночью, так и по расписанию днем через некоторое время можно сжать раздувшиеся логи до вполне адекватных размеров.
Кстати, это можно и в фак внести. И обязательно необходимо ограничивать прожорливость SQL, плановые задания по перестройке индекса, обновление статистики сжирают память. Даже при 128 гигах – через неделю памяти не хватает.
То, что памяти не хватает, это нормальное поведение. SQL сервер обычно ставиться единственной ролью на железку и пытается максимально задействовать всю доступную память для ускорения своей работы.
Вот если начинается запись в файл подкачки – это уже плохо.
Вопрос к автору: если Check Database Integrity Task например на одной из баз закончится с ошибкой, то дальше по зеленой стрелке пойдет выполнение ?
Зеленая стрелка нам говорит о том, что следующий шаг будет выполнен только, если предыдущий завершился без ошибок.