Добрый день. Имеется железка i7-10700K, 112gb ram, windows server 2019 standart, ms sql standart 2019. Все базы на ssd, базы 1С на одном физическом диске, tempdb на другом, сам sql на третьем где стоит система.
Сервер используется в режиме "все в одном", т.е. это и сервер терминалов, и сервер 1с-приложений и sql сервер.
6 баз бухгалтерии, 5 примерно одного объема (~4gb), одна больше всех (~15gb), 20 пользователей.
Переехали недавно, до этого были все файловые базы. Сейчас все работает быстро и бухгалтера счастливы, но я не счастлив)
Вопрос такой, почему происходит долгое перестроение индекса баз?
Опытным путем я выяснил что при создании плана обслуживания, если в одну задачу по перестроению индекса добавить все базы, то это задание будет выполняться последовательно для каждой из указанных баз и на первый запуск такого задания у меня ушло 7 часов(!).
Тогда я сделал на каждую базу свое задание в одном плане, стартуют одновременно и за ~2 часа заканчивают, но все равно мне кажется это очень долго. Так как есть на другом сервере самописная база на основе старого ДО там sql 2014, объем ~13gb и такая операция занимает минут 20 от силы.
Игрался с MAXDOP и когда он не равен 1, то быстрее выполняется эта операция. В итоге сделал такой план обслуживания:
1) MAXDOP = 0
2) проверка целостности баз
3) перестроение индекса для 6 баз одновременно
4) после окончания каждого перестроение происходит обновление статистки
5) когда вся статистика 6 баз обновлена, выполняется резервное копирование баз
6) MAXDOP = 1
7) очистка журналов и старых копий
При работе такого плана я мониторил нагрузку железа и было видно что процессор нагружен не постоянно, в среднем 40%, не все ядра. ОЗУ тоже используется не все доступное, выделил для sql 64гб, он забирал максимум 37.
сервер приложений 1с настроен на использование shared memory, но думаю это не так важно, так как вопрос у меня в длительности операций которые выполняет сам sql без участия 1с.
Данный регламент выполняется ночью, когда нет активных пользователей.
Может кто подскажет что-то. Спасибо.
Сервер используется в режиме "все в одном", т.е. это и сервер терминалов, и сервер 1с-приложений и sql сервер.
6 баз бухгалтерии, 5 примерно одного объема (~4gb), одна больше всех (~15gb), 20 пользователей.
Переехали недавно, до этого были все файловые базы. Сейчас все работает быстро и бухгалтера счастливы, но я не счастлив)
Вопрос такой, почему происходит долгое перестроение индекса баз?
Опытным путем я выяснил что при создании плана обслуживания, если в одну задачу по перестроению индекса добавить все базы, то это задание будет выполняться последовательно для каждой из указанных баз и на первый запуск такого задания у меня ушло 7 часов(!).
Тогда я сделал на каждую базу свое задание в одном плане, стартуют одновременно и за ~2 часа заканчивают, но все равно мне кажется это очень долго. Так как есть на другом сервере самописная база на основе старого ДО там sql 2014, объем ~13gb и такая операция занимает минут 20 от силы.
Игрался с MAXDOP и когда он не равен 1, то быстрее выполняется эта операция. В итоге сделал такой план обслуживания:
1) MAXDOP = 0
2) проверка целостности баз
3) перестроение индекса для 6 баз одновременно
4) после окончания каждого перестроение происходит обновление статистки
5) когда вся статистика 6 баз обновлена, выполняется резервное копирование баз
6) MAXDOP = 1
7) очистка журналов и старых копий
При работе такого плана я мониторил нагрузку железа и было видно что процессор нагружен не постоянно, в среднем 40%, не все ядра. ОЗУ тоже используется не все доступное, выделил для sql 64гб, он забирал максимум 37.
сервер приложений 1с настроен на использование shared memory, но думаю это не так важно, так как вопрос у меня в длительности операций которые выполняет сам sql без участия 1с.
Данный регламент выполняется ночью, когда нет активных пользователей.
Может кто подскажет что-то. Спасибо.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3)
То есть стандартными средствами долго, а скриптами нет? Я думал использовать ola.hallengren, но сначала решил стандартным методом. На другой базе, на более слабом железе (i7-3770k, 24gb ram, ssd, win server 2019 standart, ms sql 2014 standart), с объемом базы 12gb, данная операция занимает 10 минут.
gilev .ру / dbreindex
То есть стандартными средствами долго, а скриптами нет? Я думал использовать ola.hallengren, но сначала решил стандартным методом. На другой базе, на более слабом железе (i7-3770k, 24gb ram, ssd, win server 2019 standart, ms sql 2014 standart), с объемом базы 12gb, данная операция занимает 10 минут.
(5)
В теории возможно, все обрабатывать или только требуемые. Можешь провести сравнение на копии БД, развернуть ее пару раз из бэкапа и проверить стандартным методом и скриптом, не забудь потом поделиться результатом)
То есть стандартными средствами долго, а скриптами нет?
В теории возможно, все обрабатывать или только требуемые. Можешь провести сравнение на копии БД, развернуть ее пару раз из бэкапа и проверить стандартным методом и скриптом, не забудь потом поделиться результатом)
Есть такая вещь в 2019 ms sql, что индексы долго перестраиваются. Якобы баг такой был, и установка какого-то CU помогает (по факту нет, ну +-5% скорости, может быть). Реиндексация идет стандартным методом, который Management studio предлагает при создании плана обслуживания? Рекомендую скрипт взять, который обрабатывает не все индексы, а только те, по которым были изменения, и нужно перестроить/дефрагментировать статистику. На ИС были такие. Если платформа 8.3.22 и выше, еще нужно будет выключение/включение блокировки на уровне страниц добавить.
(4) платформа 8.3.22+
Про измененный режим блокировки страниц читал, но подумал что проще сделать перестроение индекса и все, а оно ну очень долго это делает. Скрипты видел, но не решился их использовать. На ms sql установлен последний CU на октябрь 2023. То есть все сводится к скриптам...
Про измененный режим блокировки страниц читал, но подумал что проще сделать перестроение индекса и все, а оно ну очень долго это делает. Скрипты видел, но не решился их использовать. На ms sql установлен последний CU на октябрь 2023. То есть все сводится к скриптам...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот