8.х MS SQL Server - обслуживание базы данных

Тема в разделе "Установка платформы "1С:Предприятие 8"", создана пользователем Adminspb, 21 мар 2017.

  1. TopicStarter Overlay
    Adminspb
    Offline

    Adminspb Опытный в 1С

    Регистрация:
    18 дек 2006
    Сообщения:
    146
    Симпатии:
    1
    Баллы:
    29
    Добрый день!
    Есть MS SQL 2012, и БД 1С на нем.

    Как с помощью мастера планов обслуживания произвести проверку БД и настроить резервное копирование самой БД понятно, но, какие операции помимо этих нужно производить в обязательном порядке, и как часто?

    2017-03-20_213513.jpg

    Нашел инструкцию https://its.1c.ru/db/metod8dev#content:5837:hdoc, но насколько она актуальна сейчас? Можно ли вместо скриптов приведенных там воспользоваться только мастером планов обслуживания? Что лучше и почему?
  2. nomad_irk
    Offline

    nomad_irk Гуру в 1С

    Регистрация:
    20 окт 2008
    Сообщения:
    9.828
    Симпатии:
    1.024
    Баллы:
    204
    Нужны:
    1. Реорганизация индексов
    2. Обновление статистики
    и собственно все.

    Можно написать свой, более правильный скрипт по реорганизации индексов.
  3. TopicStarter Overlay
    Adminspb
    Offline

    Adminspb Опытный в 1С

    Регистрация:
    18 дек 2006
    Сообщения:
    146
    Симпатии:
    1
    Баллы:
    29
    А в какой последовательности это надо делать и как часто?

    Пока думаю так сделать такую последовательность используя мастер создания плана обслуживания

    1) Проверка целостности базы данных - раз в сутки, до снятия полного бекапа
    2) Полный бекап - раз в сутки, ночью
    3) Реорганизация индекса - раз в сутки, после снятия полного бекапа
    4) Обновление статистики - раз в сутки, после снятия полного бекапа
    5) Разностный бекап - ежедневно в рабочее время, каждый час
    6) Резервное копирование базы данных (журнал транзакций) (пока использовать не буду) - исп. простая модель восстановления, но
    если использовать - журнал транзакций нужно писать в тот же файл что полный и разностный бекап, или лучше в отдельный файл?
    Как лучше и правильно?
    7) Очистка после обслуживания

    Что думаете?
    Еще вопрос - почему не нужно использовать "Восстановить индекс" ?
    Насчет более правильного скрипта? Можно поподробнее? Хотите сказать реорганизации индекса для 1С - мало?
  4. nomad_irk
    Offline

    nomad_irk Гуру в 1С

    Регистрация:
    20 окт 2008
    Сообщения:
    9.828
    Симпатии:
    1.024
    Баллы:
    204
    Выполнять в той, в которой указал. Раз в сутки, в моменты наименьшей нагрузки, будет достаточно.

    При простой схеме восстановления п.5 не делается вообще(могу ошибаться), п. 6 - не имеет большого смысла.

    Восстановление индекса более ресурсоемкая в плане быстродействия БД процедура и смысла мало при исправных и не изменяемых структурах таблиц.

    Проверять целостность БД - ну можно конечно, но на моей памяти не было такого, чтобы база повредилась без наличия проблем с железом: вырубили 220В при отсутствии ИБП/посыпался RAID(восстанавливали)/etc
  5. nickpugachev
    Offline

    nickpugachev Профессионал в 1С Команда форума

    Регистрация:
    28 май 2012
    Сообщения:
    3.397
    Симпатии:
    155
    Баллы:
    104
    Какие диски под базами? В случае ssd реорганизация индексов практически не имеет смысла. Имеет смысл перестроение, но не всех индексов, а только достаточно сильно фрагментированных и больших. Учитывайте, что перестроение индексов на стандартной версии SQL Server блокирует таблицу, делайте это во время технологических окон или когда база очень мало используется.
    Проверка целостности базы - на уровне базы данных или на уровне 1С (ТиИ)? На уровне базы - гораздо большее значение имеет тестирование бэкапа, а не самой базы. ТиИ не стоит в регламентное обслуживание ставить.
    Про пункт 5 - если у вас маленькая база - делайте полный бэкап, а не дифференциальный, проблем при восстановлении и тестировании бэкапов меньше, медленные большие диски для бэкапов стоят дешево.
    Про пункт 6 - любой бэкап в свой файл, имя которого включает в себя и тип бэкапа и дату-время создания. Стандартные действия планов обслуживания делают это по умолчанию. Если вам не нужно восстановление базы на конкретную точку во времени - не переводите базу в режим восстановления Full вне зависимости от ее размера. Вторая причина использования Full модели - добавление базы в группу доступности на кластере.
    По поводу периодичности бэкапов - она зависит от того объема данных, который вы готовы потерять, ни от чего больше.
    По поводу периодичности остальных операций - если база небольшая и не особо нагружена и есть большое окно ночью - делайте ночью
  6. TopicStarter Overlay
    Adminspb
    Offline

    Adminspb Опытный в 1С

    Регистрация:
    18 дек 2006
    Сообщения:
    146
    Симпатии:
    1
    Баллы:
    29
    Попробовал
    Полный бекап - ежедневно 1 раз ночью
    Разностный бекап - ежедневно в рабочее время, каждый час делается без проблем.
    Причем я для него указал тот же файл что и под полный бекап. В результате, при попытке восстановления предлагается диапазон времени на выбор из сохраненных.
    Если время жизни бекапов допустим 10 дней..потом они будут замещаться в файле бекапами за другие даты? (При отсутствии в плане ограничения по времени...)

    Т.е. мне нужно делать

    1. Реорганизация индексов
    2. Обновление статистики

    а что с очисткой после обслуживания? Надо?


    Диски под базами SSD, под бекапами не SSD
    Вы рекомендуете проверку бекапа проводить регулярно? При каждом бекапе?

    База более 25 гигов.

    Почему вы советуете каждый бекап в свой файл?
    Даже Полный и Разностный? Они отлично дописываются в один. Причем при выборе файла можно выбрать и интервал восстановления.
    Как тогда после восстановления базы из полного бекапа накатить еще и разностные? Что плохого если все будет в одном файле?
  7. nickpugachev
    Offline

    nickpugachev Профессионал в 1С Команда форума

    Регистрация:
    28 май 2012
    Сообщения:
    3.397
    Симпатии:
    155
    Баллы:
    104
    Естественно. Будет очень весело при мертвой базе получить еще и битый бэкап :)
    По той же причине, что и проверять бэкапы. Мертвый дифф не так страшен, как мертвый полный или мертвый файл с несколькими бэкапами.
    К тому же можно для разных типов бэкапов использовать разное время хранения. Например полные бэкапы первого дня месяца живут 3 года, остальные полные год, бэкапы лога транзакций (диффы в вашем случае, у нас они не используются) 3 месяца.

    Для восстановления из нескольких файлов восстанавливаете последний полный с опцией NORECOVERY и потом на нее поднимаете последний дифф с опцией RECOVERY
    --- Объединение сообщений, 23 мар 2017 ---
    Значит реорганизация индексов вам не даст эффекта.
  8. TopicStarter Overlay
    Adminspb
    Offline

    Adminspb Опытный в 1С

    Регистрация:
    18 дек 2006
    Сообщения:
    146
    Симпатии:
    1
    Баллы:
    29
    Можете пояснить, почему реорганизация индексов не даст эффекта?
    Обслуживание базы ведь все равно производить надо...
  9. nickpugachev
    Offline

    nickpugachev Профессионал в 1С Команда форума

    Регистрация:
    28 май 2012
    Сообщения:
    3.397
    Симпатии:
    155
    Баллы:
    104
    Реорганизация индекса имеет значение для шпиндельных дисков, последовательное чтение у них сильно быстрее случайного. Во время реорганизации страницы индекса просто располагаются рядом и чтобы их прочитать не надо особо дергать головой диска.
    Для ssd не имеет значения где лежат страницы, скорость чтения от этого не зависит.
    --- Объединение сообщений, 23 мар 2017 ---
    обслуживание базы проводить надо, никто не спорит :)
    просто зачем совершать лишние действия?
  10. TopicStarter Overlay
    Adminspb
    Offline

    Adminspb Опытный в 1С

    Регистрация:
    18 дек 2006
    Сообщения:
    146
    Симпатии:
    1
    Баллы:
    29
    Выходит реорганизация индекса не нужна, восстановление выходит тоже.
    Так какое тогда обслуживание?
  11. nomad_irk
    Offline

    nomad_irk Гуру в 1С

    Регистрация:
    20 окт 2008
    Сообщения:
    9.828
    Симпатии:
    1.024
    Баллы:
    204
    бэкапы и проверка бэкапов :)
  12. nickpugachev
    Offline

    nickpugachev Профессионал в 1С Команда форума

    Регистрация:
    28 май 2012
    Сообщения:
    3.397
    Симпатии:
    155
    Баллы:
    104
    Статистика, перестроение индексов, очистка процедурных кешей, это никто не отменяет :)
    реорганизация таки сильно от перестроения отличается
  13. nomad_irk
    Offline

    nomad_irk Гуру в 1С

    Регистрация:
    20 окт 2008
    Сообщения:
    9.828
    Симпатии:
    1.024
    Баллы:
    204
    Статистику нужно после реорганизации обновлять, процедурные кэши вроде как в 2012 уже сами успешно чистятся
    Перестроение индексов как бы вообще не нужно.

    Исходя из того, что базы на SSD, то остаются бэкапы, т.к. реорганизация индексов имеет мало смысла.
  14. nickpugachev
    Offline

    nickpugachev Профессионал в 1С Команда форума

    Регистрация:
    28 май 2012
    Сообщения:
    3.397
    Симпатии:
    155
    Баллы:
    104
    Перестроение индекса с фрагментацией более 30% (про количество процентов можно холиварить) обычно просто уменьшает количество чтений, потому как перестраивается содержимое страниц, оно нужно на больших индексах.
    Статистику обновлять можно в любое время, от процессов реорганизации индексов этот процесс не зависит, а процесс убийства статистики зависит от активности работы с таблицей в части изменения данных

    Кэши 8.3 начала меньше засирать, а 2012 с не помню каким трейс-флагом не дает его засирать и 8.2 и одноразовым запросам 8.3 :), 2016 не дает засирать его и без трейсов