Настройка и оптимизация MS SQL 2019
Добрый день!
На сайте ИТС указаны рекомендации (2016 год) относительно базы model MS SQL сервера:
Начальный размер файла данных - от 1Гб до 10Гб.
Начальный размер журнала транзакций - от 1Гб до 2Гб.
Прирост файлов – 512Мб.
Зачем такие размеры? У нас на рабочих серверах размер этой базы 16 Мб, лога 8 Мб, и они не растут годами.
Как параметры базы model повлияют на производительность баз 1С?
И вопрос №2.
Уже поднимал, но ответ не нашел.
MS SQL 2019. При выполнении плана обслуживания долгие промежутки между выполнением шагов. Например, между бэкапом и реиндексацией несколько часовая пауза. На 2008, 2012 SQL такой проблемы нет, планы обслуживания аналогичны.
Спасибо.
На сайте ИТС указаны рекомендации (2016 год) относительно базы model MS SQL сервера:
Начальный размер файла данных - от 1Гб до 10Гб.
Начальный размер журнала транзакций - от 1Гб до 2Гб.
Прирост файлов – 512Мб.
Зачем такие размеры? У нас на рабочих серверах размер этой базы 16 Мб, лога 8 Мб, и они не растут годами.
Как параметры базы model повлияют на производительность баз 1С?
И вопрос №2.
Уже поднимал, но ответ не нашел.
MS SQL 2019. При выполнении плана обслуживания долгие промежутки между выполнением шагов. Например, между бэкапом и реиндексацией несколько часовая пауза. На 2008, 2012 SQL такой проблемы нет, планы обслуживания аналогичны.
Спасибо.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) такие размеры даны предположу из того что баз данных 1С типовых размером 10 мб не бывает, они сразу занимают указанную вилку размеров
прирост файлов подогнан под разметку современных файловых систем опять таки на современных быстрых SSD, нет ни какого смысла приращивать по мегабайту, или по дефолтовому проценту, который по мере роста будет не сбаланнсированно себя вести.
Но лично я не сторонник роста файлов вообще лучше имхо сразу резервировать максимально возможное базе место и ограничивать рост. Но это старая тема в стиле " windows ws linux) и холиварить не надо.
Напрямую параметры базы model не влияют. Потому что в новых базах при создании на скуле вы можете указать отличные от копируемых значений из базы model. Если вопрос трактовать как какие параметры в любой базе влияют, то их много - и зеркалирование, и количество файлов раскинутых по разным физическим дискам, legacy cardinality estimation, как раз размер файла прироста в отдельных случаях.
"У нас на рабочих серверах размер этой базы 16 Мб, лога 8 Мб, и они не растут годами." если в продуктивной базе два несчастных пользователя, то плевать на параметры вообще на совмременном то железе, у вас база целиком закэшируется. Если вы говорите про model - то эта база шаблон настроек, ее размер постоянен в силу не использования.
Если у вас задания выполняются не так как вы ожидали, то прежде всего посмотрите в журнал сообщений скуля (логи) на предмет ошибок. Если там есть ошибки, то надо разобраться с причинами возникновения и устранить. Множественные ошибки могут быть связаны с циклом повторных попыток выполнения неудачного задания.
Судя по тому как вы строите вопросы, вам стоит изменить приоритеты и найти время погрузиться в архитектуру MS SQL Server.
Можете ознакомится также с
прирост файлов подогнан под разметку современных файловых систем опять таки на современных быстрых SSD, нет ни какого смысла приращивать по мегабайту, или по дефолтовому проценту, который по мере роста будет не сбаланнсированно себя вести.
Но лично я не сторонник роста файлов вообще лучше имхо сразу резервировать максимально возможное базе место и ограничивать рост. Но это старая тема в стиле " windows ws linux) и холиварить не надо.
Напрямую параметры базы model не влияют. Потому что в новых базах при создании на скуле вы можете указать отличные от копируемых значений из базы model. Если вопрос трактовать как какие параметры в любой базе влияют, то их много - и зеркалирование, и количество файлов раскинутых по разным физическим дискам, legacy cardinality estimation, как раз размер файла прироста в отдельных случаях.
"У нас на рабочих серверах размер этой базы 16 Мб, лога 8 Мб, и они не растут годами." если в продуктивной базе два несчастных пользователя, то плевать на параметры вообще на совмременном то железе, у вас база целиком закэшируется. Если вы говорите про model - то эта база шаблон настроек, ее размер постоянен в силу не использования.
Если у вас задания выполняются не так как вы ожидали, то прежде всего посмотрите в журнал сообщений скуля (логи) на предмет ошибок. Если там есть ошибки, то надо разобраться с причинами возникновения и устранить. Множественные ошибки могут быть связаны с циклом повторных попыток выполнения неудачного задания.
Судя по тому как вы строите вопросы, вам стоит изменить приоритеты и найти время погрузиться в архитектуру MS SQL Server.
Можете ознакомится также с
(5) Спасибо за разъяснение и совет.
16Мб - это про базу model.
Ошибок при выполнении плана обслуживания нет. Перед реорганизацией индекса SQL же формирует запрос ...alt er index [...] on... ? И перед update statistics аналогично. Может ли формирование запроса занимать несколько часов? На сервере крутятся по 10 баз ЗУП 3.1 / Бух 3 (размеры от 2 до 30 Гб) и пара самописных баз в 50 и 200 Гб.
Наверное, есть смысл пересмотреть план обслуживания, и взять более оптимальный, который будет обслуживать только необходимые таблицы, а не все в базе..
16Мб - это про базу model.
Ошибок при выполнении плана обслуживания нет. Перед реорганизацией индекса SQL же формирует запрос ...alt er index [...] on... ? И перед update statistics аналогично. Может ли формирование запроса занимать несколько часов? На сервере крутятся по 10 баз ЗУП 3.1 / Бух 3 (размеры от 2 до 30 Гб) и пара самописных баз в 50 и 200 Гб.
Наверное, есть смысл пересмотреть план обслуживания, и взять более оптимальный, который будет обслуживать только необходимые таблицы, а не все в базе..
(6) ну вы и сами практически ответили на свой вопрос
вам достаточно взять запрос обслуживания и вручную выполнить в студии, посмотрев на итоговое время выполнения
если у вас не очень быстрая дисковая система, а регламент выполняет сканирование статистики с full scan, т.е. полным обсчетом всей базы, то такое возможно
особенно проблема может быть усилина ожиданиями к оборудованию, по-хорошему надо записать счетчики производительности очередей к процессорам и время реакции дисков. При очередях к диску очень вероятно. Тут еще и распараллеливание подзапросов (maxdop) имеет значение, так как например тот же обсчет статистики может быть многопоточным и сопровождаться ожиданиями cxpackets и т.п.
также видел когда одновременно регламент проходил с бэкапом, там диск точно просядет
смысл в избирательной перестройке индексо точно есть, и малого размера, и слабофрагментированные индексы лучше не трогать
вам достаточно взять запрос обслуживания и вручную выполнить в студии, посмотрев на итоговое время выполнения
если у вас не очень быстрая дисковая система, а регламент выполняет сканирование статистики с full scan, т.е. полным обсчетом всей базы, то такое возможно
особенно проблема может быть усилина ожиданиями к оборудованию, по-хорошему надо записать счетчики производительности очередей к процессорам и время реакции дисков. При очередях к диску очень вероятно. Тут еще и распараллеливание подзапросов (maxdop) имеет значение, так как например тот же обсчет статистики может быть многопоточным и сопровождаться ожиданиями cxpackets и т.п.
также видел когда одновременно регламент проходил с бэкапом, там диск точно просядет
смысл в избирательной перестройке индексо точно есть, и малого размера, и слабофрагментированные индексы лучше не трогать
1) Рекомендации вещь очень усредненная. Пишутся из принципа "чтоб у 80% работало и они не кричали "Ваша 1С говно"".
Рекомендации надо прочитать, а потом подумать и применять обдуманно.
У нас на одном сервере была ERP на 250Гб и куча БП по 4Гб. Как думаете, у них был одинаковый размер журналов транзакций? А прирост файлов?
2) Вопрос сформулирован в стиле "У меня в одной комнате светло, а в другой темно. Как думаете, почему?"
Покажите сами планы обслуживания. Расписание запуска. Журнал их выполнения.
Если вы думали что причина в новой версии sql - то нет, очень маловероятно.
Рекомендации надо прочитать, а потом подумать и применять обдуманно.
У нас на одном сервере была ERP на 250Гб и куча БП по 4Гб. Как думаете, у них был одинаковый размер журналов транзакций? А прирост файлов?
2) Вопрос сформулирован в стиле "У меня в одной комнате светло, а в другой темно. Как думаете, почему?"
Покажите сами планы обслуживания. Расписание запуска. Журнал их выполнения.
Если вы думали что причина в новой версии sql - то нет, очень маловероятно.
Как параметры базы model повлияют на производительность баз 1С?
это параметры, по которым будет создаваться новая база
а Дмитрий74Чел - четко вам ответил - свет в комнате зависит от электричества и солнечного света
хотя, может и лампочка перегореть :)
На 2008, 2012 SQL такой проблемы нет, планы обслуживания аналогичны.
2019 похож на 2008 и 2012 ?
и даже если разница только в циферках - но ведь не только.
это как бухгалтерия 2.0 и 3.0
это параметры, по которым будет создаваться новая база
а Дмитрий74Чел - четко вам ответил - свет в комнате зависит от электричества и солнечного света
хотя, может и лампочка перегореть :)
На 2008, 2012 SQL такой проблемы нет, планы обслуживания аналогичны.
2019 похож на 2008 и 2012 ?
и даже если разница только в циферках - но ведь не только.
это как бухгалтерия 2.0 и 3.0
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот