Обслуживание баз 1с на сервере ms sql 2012
В общем раньше не настраивал планы обслуживания, на
прочитал какие планы лучше чего использовать.
Создал 1-й план ежедневно, кроме субботы:
1. Обновление статистик
2. Очистка процедурного кэша
3. Полный бэкап
Создал 2-й план, еженедельно в субботу:
1. Обновление статистик
2. Очистка процедурного кэша
3. Реорганизация индекса
4. Восстановить индекс
5. Полный бэкап
Правильная ли последовательность у 2го плана? Нужно ли выполнять проверку целостности? В общем жду ваших советов по обслуживанию бд. В инете хоть и много информации, но она везде своя, а мне охото иметь представление о том что я делаю.
прочитал какие планы лучше чего использовать.
Создал 1-й план ежедневно, кроме субботы:
1. Обновление статистик
2. Очистка процедурного кэша
3. Полный бэкап
Создал 2-й план, еженедельно в субботу:
1. Обновление статистик
2. Очистка процедурного кэша
3. Реорганизация индекса
4. Восстановить индекс
5. Полный бэкап
Правильная ли последовательность у 2го плана? Нужно ли выполнять проверку целостности? В общем жду ваших советов по обслуживанию бд. В инете хоть и много информации, но она везде своя, а мне охото иметь представление о том что я делаю.
По теме из базы знаний
- Курс "Подготовка к экзамену 1С:Эксперт и 1С:Профессионал по технологическим вопросам. Основной курс" в формате видеокурса и онлайн-курса c 17 по 21 июня 2024 г.
- Вопросы и ответы по лицензированию Microsoft SQL Server
- Ловля блокировок на связке "Microsoft SQL server - 1С"
- Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"
- Базы данных. Несколько шагов до серьезного обслуживания
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) ultrannge, зачем ежедневно полный делать?
делать полный в субботу или воскресенье, а в остальные дни разностный архив.
Про реогрнанизацию/перестройку индексов: на просторах интернета можно найти примеры скриптов для умной перестройки индексов, когда перестраиваются/дефрагментируются только те, которым это действительно требуется,а не все подряд. Лучше использовать такие скрипты, т.к. иначе в случае использования полной модели восстановления получите значительный рост журнала транзакций.
Также можно настроить хранение архивов с определенной глубиной - тогда sql сам будет старые архивы удалять (Cleanup Task).
делать полный в субботу или воскресенье, а в остальные дни разностный архив.
Про реогрнанизацию/перестройку индексов: на просторах интернета можно найти примеры скриптов для умной перестройки индексов, когда перестраиваются/дефрагментируются только те, которым это действительно требуется,а не все подряд. Лучше использовать такие скрипты, т.к. иначе в случае использования полной модели восстановления получите значительный рост журнала транзакций.
Также можно настроить хранение архивов с определенной глубиной - тогда sql сам будет старые архивы удалять (Cleanup Task).
(1) ultrannge, Реорганизацию/ перестроение индекса лучше всего выполнять одним заданием, статья на тему
Отдельно про резервное копирование средствами MS SQL
И еще одна с набором полезных скриптов
П.С.: Все советы по "сжатию" (shrink) можете смело игнорировать. Они актуальны только в одном случае - из базы было удалено большое количество данных, например зачем то выполнили свертку базы...
Другой вариант сжатия, и именно сжатия, максимальный эффект дает на ССД массивах.
Отдельно про резервное копирование средствами MS SQL
И еще одна с набором полезных скриптов
П.С.: Все советы по "сжатию" (shrink) можете смело игнорировать. Они актуальны только в одном случае - из базы было удалено большое количество данных, например зачем то выполнили свертку базы...
Другой вариант сжатия, и именно сжатия, максимальный эффект дает на ССД массивах.
(10) smallbuk, правильно настроенная архивация сообщает SQL серверу с какого места файл лога можно начинать перезаписывать.
Там нет никакой самоочистки, или чего-то подобного, что вы делаете с помощью шринка - просто на место старых заархивированных транзакций начинают писаться новые в результате чего размер лога остается +- постоянным без всяких шринков.
Там нет никакой самоочистки, или чего-то подобного, что вы делаете с помощью шринка - просто на место старых заархивированных транзакций начинают писаться новые в результате чего размер лога остается +- постоянным без всяких шринков.
(10) smallbuk, "Архивация базы" - это что и откуда? Если мы про все еще SQL Server то эта софтинка не знает такого процесса, а знает только "Бэкап=резервная копия базы". И - таки да - на логическом уровне можно считать что при этом в логе появляется свободное место, т.е. он как бы очищается. Хотя физически ничего подобного не происходит. Главный профит из всего этого для стороннего наблюдателя - что лог не растет в размерах. Соотв. и "шринкать" его незачем.
(8) smallbuk, Как человек обладающий всеми официальными сертификатами MS по платформе SQL Server официально же вам сообщаю: необходимость принудительного и регулярного сжатия файлов транз. лога значит одно и только одно - платформа SQL Server НЕ НАХОДИТСЯ в состоянии "нормальный режим эксплуатации". Источников проблемы может быть много, а вот вывод - только один: снимайте "пластырь"(ваше сжатие) с запущенного нарыва и вскрывайте его скальпелем(ищите причину по которой лог не проводит нормальное самообслуживание, в ходе которого корректируется и размер оного).
(12) SamMan,
без иронии. задумался.
у меня молокозавод (отраслевая разработка). на этапе внедрения привлекли франчей. если честно, то до сих пор их "доработки" вычищаю/оптимизирую. заметил, что журнал транзакций дико разрастался в момент формирования тяжелой отчетности или в момент пиковой нагрузки.
спасибо за пинок. буду искать причину.
а вот этого не понял.
"софтина" честно мастерит архив базы. полностью функциональный. мало того, она любезно пакует выполненный бакап в рар, благодаря чему, размер файла архива базы уменьшается на порядок.
без иронии. задумался.
у меня молокозавод (отраслевая разработка). на этапе внедрения привлекли франчей. если честно, то до сих пор их "доработки" вычищаю/оптимизирую. заметил, что журнал транзакций дико разрастался в момент формирования тяжелой отчетности или в момент пиковой нагрузки.
спасибо за пинок. буду искать причину.
а знает только "Бэкап=резервная копия базы"
а вот этого не понял.
"софтина" честно мастерит архив базы. полностью функциональный. мало того, она любезно пакует выполненный бакап в рар, благодаря чему, размер файла архива базы уменьшается на порядок.
(15) smallbuk,
А что тут не понятного то? Ваша софтинка для бэкапов либо работает криво, либо настроена криво, так как работает по усеченному методу, подразумевающему что модель восстановления базы - простая, а у базы, возможно, модель восстановления полная. Отсюда и проблемы с ростом журнала транзакций.
Изучите статью по основам резервного копирования для MS SQL , возможно появится понимание того, о чем вам пишут.
А регулярный шринк файлов базы или журнала приводит только к одному, при записи данных MS SQL регулярно выполняет лишние действия по расширению файла бд или журнала. Особенно это круто, когда стоят настройки по умолчанию в %...
а вот этого не понял.
А что тут не понятного то? Ваша софтинка для бэкапов либо работает криво, либо настроена криво, так как работает по усеченному методу, подразумевающему что модель восстановления базы - простая, а у базы, возможно, модель восстановления полная. Отсюда и проблемы с ростом журнала транзакций.
Изучите статью по основам резервного копирования для MS SQL , возможно появится понимание того, о чем вам пишут.
А регулярный шринк файлов базы или журнала приводит только к одному, при записи данных MS SQL регулярно выполняет лишние действия по расширению файла бд или журнала. Особенно это круто, когда стоят настройки по умолчанию в %...
(15) smallbuk, >>что журнал транзакций дико разрастался в момент формирования тяжелой отчетности или в момент пиковой нагрузки.
Это нормально. Скорей всего при этом идут массовые INSERT/UPDATE/DELETE во всякие таблицы(возможно временные). Пространство выделяемое лог-файлу на HDD должно быть адекватно такой пиковой загрузке. НО! Лог НЕ должен расти постоянно! Т.е. выкатился он к какой-то "верхней" отметке - пусть 10Гб. Все. После этого идет варка в "собственном соку", никакие дополнительные мега-гига-байты не нужны месяцами, возможно - годами. Потом дела предприятия идут в гору, вместо 200 покупателей - 2000, строк в таблицах не по 500 тыс, а по 3 млн. - лог берет новую отметку, допустим 15Гб. И вновь варится в этих новых границах годами. И т.д.
>>"софтина" честно мастерит архив базы
Нету в SQL официально такого термина. Приведите линк на MS-доки по SQL-ю что б там было "архив базы", а не "резервная копия". 1С-цы, понятно, могут обзываться как угодно, но мы же, опять же, все еще про SQL Server говорим?
>>она любезно пакует выполненный бакап в рар
А, ну это уже "фичи" 1Ски/стороннего софта(чего вы там используете). Сам SQL Server никаких раров не делает(хотя умеет сжимать бэкапы, но остаются они все-равно .bak-файлами). Если вы хотите говорить в разрезе стороннего софта - другое дело, но тогда нужны четкие знания о командах посылаемых этим софтом на SQL.
Это нормально. Скорей всего при этом идут массовые INSERT/UPDATE/DELETE во всякие таблицы(возможно временные). Пространство выделяемое лог-файлу на HDD должно быть адекватно такой пиковой загрузке. НО! Лог НЕ должен расти постоянно! Т.е. выкатился он к какой-то "верхней" отметке - пусть 10Гб. Все. После этого идет варка в "собственном соку", никакие дополнительные мега-гига-байты не нужны месяцами, возможно - годами. Потом дела предприятия идут в гору, вместо 200 покупателей - 2000, строк в таблицах не по 500 тыс, а по 3 млн. - лог берет новую отметку, допустим 15Гб. И вновь варится в этих новых границах годами. И т.д.
>>"софтина" честно мастерит архив базы
Нету в SQL официально такого термина. Приведите линк на MS-доки по SQL-ю что б там было "архив базы", а не "резервная копия". 1С-цы, понятно, могут обзываться как угодно, но мы же, опять же, все еще про SQL Server говорим?
>>она любезно пакует выполненный бакап в рар
А, ну это уже "фичи" 1Ски/стороннего софта(чего вы там используете). Сам SQL Server никаких раров не делает(хотя умеет сжимать бэкапы, но остаются они все-равно .bak-файлами). Если вы хотите говорить в разрезе стороннего софта - другое дело, но тогда нужны четкие знания о командах посылаемых этим софтом на SQL.
(18) SamMan, тут вся соль в (4) smallbuk,
Про проблемы забыл... :) и бэкапит, и в рар сжимает, прям красота... вот только журнал транзакций приходится шринковать.
П.С.: Я конечно понимаю, что сжатие бэкапов очень удобная фишка, а в MS SQL она стала доступна в основном только с версии 2008R2. Но, резервное копирование средствами субд - чуть ли не единственный способ получить корректную резервную копию. Ну и приятными бонусами типа уведомления о результате операции на почту/мессенджер и т.п..
лет эдак 7 назад наткнулся на софтинку Эффектор-савер. и с тех пор забыл про проблемы с архивацией 1с.
Про проблемы забыл... :) и бэкапит, и в рар сжимает, прям красота... вот только журнал транзакций приходится шринковать.
П.С.: Я конечно понимаю, что сжатие бэкапов очень удобная фишка, а в MS SQL она стала доступна в основном только с версии 2008R2. Но, резервное копирование средствами субд - чуть ли не единственный способ получить корректную резервную копию. Ну и приятными бонусами типа уведомления о результате операции на почту/мессенджер и т.п..
(19) h00k,
Верно. Что бы держать ситуацию под абсолютным контролем нужно работать на достаточно низком уровне, прочтя перед этим тонн 5 литературы. Либо в красивом окошке нажать внушающую доверие кнопку с красивой 3Д-иконкой и надписью "Сделать все хорошо" ничего не читая. Второй подход на порядки быстрее и легче, но череват. :)
Справедливости для - в SQL Server встроена мыльная подсистема, так что отквоченное возможно и без сторонних софтин. Правда, опять же, 5 тонн литературы, изволь. :) Не то чтоб подсистема была архисложна для понимания, но ее общая архитектура из 90-х годов местами доставляет, разобраться просто листая окна мастера весьма проблематично.
Но, резервное копирование средствами субд - чуть ли не единственный способ получить корректную резервную копию.
Верно. Что бы держать ситуацию под абсолютным контролем нужно работать на достаточно низком уровне, прочтя перед этим тонн 5 литературы. Либо в красивом окошке нажать внушающую доверие кнопку с красивой 3Д-иконкой и надписью "Сделать все хорошо" ничего не читая. Второй подход на порядки быстрее и легче, но череват. :)
приятными бонусами типа уведомления о результате операции на почту/мессенджер и т.п.
Справедливости для - в SQL Server встроена мыльная подсистема, так что отквоченное возможно и без сторонних софтин. Правда, опять же, 5 тонн литературы, изволь. :) Не то чтоб подсистема была архисложна для понимания, но ее общая архитектура из 90-х годов местами доставляет, разобраться просто листая окна мастера весьма проблематично.
(20) SamMan,
Так я и имел в виду только встроенные в MS SQL средства, без всяких сторонних "приблуд". Просто многие либо не знают, либо ленятся настраивать, игнорируя всю полезность данной возможности.
П.С.: Вообще, на мой взгляд, начиная с MS SQL 2008 R2 средства резервного копирования MS SQL сервера настолько развили, что использование каких-либо сторонних программ для выполнения резервного копирования у меня вызывает только недоумение.
Справедливости для - в SQL Server встроена мыльная подсистема, так что отквоченное возможно и без сторонних софтин.
Так я и имел в виду только встроенные в MS SQL средства, без всяких сторонних "приблуд". Просто многие либо не знают, либо ленятся настраивать, игнорируя всю полезность данной возможности.
П.С.: Вообще, на мой взгляд, начиная с MS SQL 2008 R2 средства резервного копирования MS SQL сервера настолько развили, что использование каких-либо сторонних программ для выполнения резервного копирования у меня вызывает только недоумение.
не сочтите за рекламу, но...
лет эдак 7 назад наткнулся на софтинку Эффектор-савер. и с тех пор забыл про проблемы с архивацией 1с. хоть выгрузка, хоть архив базы средствами скуля (хочешь полный, хочешь инкрементный).
архивы баз делаю в течение дня каждые 3 часа.
(3) Bazin, и это должно идти не от руководства, а от админа. для поддержания умиротворения и покоя на душе.
лет эдак 7 назад наткнулся на софтинку Эффектор-савер. и с тех пор забыл про проблемы с архивацией 1с. хоть выгрузка, хоть архив базы средствами скуля (хочешь полный, хочешь инкрементный).
архивы баз делаю в течение дня каждые 3 часа.
(3) Bazin, и это должно идти не от руководства, а от админа. для поддержания умиротворения и покоя на душе.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот