Для сохранения целостности структуры баз данных и обеспечения нормальной производительности необходимо проводить периодическое обслуживание. В этой статье рассмотрим какие задания по обслуживанию необходимо выполнять для баз данных 1С Предприятия, размещенных в MS SQL.

Настройка плана обслуживания баз данных MS SQL Server выполняется через программу Microsoft SQL Management Studio. Рассмотрим задачи, которые мы будем выполнять в рамках регулярного обслуживания баз данных:

В чем отличие полного бэкапа от разностного?

Полное резервное копирование сохраняет всю базу данных целиком.

Разностное резервное копирование сохраняет все изменения созданные в базе данных с момента последнего полного бэкапа.

Такой подход к резервному копированию позваляет экономить свободное пространство на носителях информации.

Создание полного бэкапа базы.

В обозревателе объектов переходим к пункту «Управление \ Планы обслуживания». В контекстном меню выбираем «Создать план обслуживания».

В этом основном плане обслуживания будем создавать вложенные планы полного бэкапа, промежуточного (разностного) бэкапа, перестроение индекса и обновление статистики.

В созданном плане нажимаем кнопку «Добавление вложенного плана»

Вводим название «Полный бэкап» и описание. Задаем расписание для выполнения задания: Раз в неделю в воскресенье в 2:00.

Добавляем в созданный план задание. Для этого с панели элементов перетаскиваем в поле заданий вложенного плана элемент с названием Задача «Резервное копирование базы данных».

Открываем задание на редактирование: правой клавишей мыши по заданию, выбираем пункт «Изменить».

• Тип резервной копии: Полное;
• Базы данных: если выбрать «Все пользовательские базы данных», то будет выполняться бэкап всех созданных вами баз данных, но есть возможность указать на конкретные базы;
• Создать файл резервной копии для каждой базы данных: отмечаем пункт «Создавать вложенный каталог для каждой базы данных», чтобы удобнее было ориентироваться в бэкапах и указываем путь как папке, в которой будут храниться резервные копии;
• Отмечаем пункт «Проверять целостнойсть резервной копии»;
• Устанавливаем параметр «Сжимать резервные копии».

Создание разностного бэкапа.

Создание плана на выполнение разностного бэкапа выполняется аналогично полному бэкапу.

Отметим некоторые отличия в настройке:

• Расписание выполнения заданий: с понедельника по субботу в 2:00;
• Тип резервной копии выбираем «Разностное»

Очистка устаревших бэкапов.

Для очистки устаревших бэкапов баз 1С Предприятия в MS SQL выбираем на панели элементов плана обслуживания Задачу «Очистка после обслуживания».

В моем случае разностный и полный бэкап хранятся в одной папке. Поэтому я добавляю только одно такое задание во вложенный план для разностного бэкапа. Если вы резервные копии будете хранить отдельно, то лучше создать отдельное задание в плане каждого бэкапа.

Перетаскиваем задачу с Панели элементов в план и задаем такие настройки:

• Удалить файлы следующего типа: Файлы резервных копий;
• Удалить из папки файлы с определенным расширением: указываем папку хранения бэкапов баз 1С;
• Включить вложенные папки первого уровня: отмечаем галочкой, потому-что у нас для бэкапов баз создаются отдельные папки
• Удалить файлы на основе возраста во время выполнения задачи: здесь все ограничивается лишь вашими потребностями и объемом жесткого диска, а мне достаточно 4 недель.

Чтобы в текущем плане после выполнения первого задания начало выполнятся следующее, их необходимо соединить между собой стрелками. Для этого выделяем первое задание и ведем стрелку от него к следующему.

Через стрелки можно задавать условие, при котором будет выполнять следующее задание: ошибка, успешное завершение, выполнение. Изменить условие можно щелкнув правой клавишей мыши по стрелке.

По умолчанию стрелка зеленого цвета. Это значит, что следующее задание будет выполняться только при успешном завершении первого. Это условие подходит для моего случая.

Переходим к очень важному и ответственному пункту: Перестроение индекса и обновление статистики.

Дефрагментация индекса (реорганизация или перестроение).

В процессе работы базы данных 1С Предприятия, в результате постоянной записи и удаления данных, образуются пустые (фрагментированные) области. По этой причине может увеличиваться бесполезный объем БД и замедляться скорость взаимодействия с ней.

Для устранения фрагментированных областей баз данных в MS SQL существует возможность проведения Реорганизации индекса и Перестроение индекса.

В чем разница между реорганизацией и перестроением?

Перестроение индекса означает, что фрагментация будет устранена путем удаления и пересоздания индексов.

При Реорганизации индекска происходит перестроение индексов в соответствии с логическим порядком. Этот способ наименее ресурсозатратный и является более предпочтительным для регулярного обслуживания баз данных.

В каких случаях требуется реорганизация индекса?

• Уровень фрагментации от 5% до 30%, то проводим реорганизацию.
• Фрагментация свыше 30% необходимо проводить перестроение индекса

Под выполнение этих задач очень подходит инструкция Transact-SQL со следующим содержимым:

DECLARE @SQL NVARCHAR(MAX) DECLARE @MIN_IND_SIZE integer = 128 DECLARE @MIN_FRAGMENTATION_LEVEL integer = 10 DECLARE @CRITICAL_FRAGMENTATION_LEVEL integer = 30 DECLARE currentIndex CURSOR LOCAL READ_ONLY FORWARD_ONLY FOR SELECT ‘ALTER INDEX ON ) + ‘]. ‘ + CASE WHEN stat.avg_fragmentation_in_percent > @CRITICAL_FRAGMENTATION_LEVEL THEN ‘REBUILD WITH (SORT_IN_TEMPDB = ON, ONLINE = ON)’ ELSE ‘REORGANIZE’ END + ‘;’ FROM ( SELECT stat., stat.index_id, avg_fragmentation_in_percent = MAX(stat.avg_fragmentation_in_percent) FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, ‘DETAILED’) stat WHERE stat.page_count > @MIN_IND_SIZE AND stat.index_id > 0 AND stat.avg_fragmentation_in_percent > @MIN_FRAGMENTATION_LEVEL GROUP BY stat., stat.index_id ) stat JOIN sys.indexes ind WITH(NOLOCK) ON stat. = ind. AND stat.index_id = ind.index_id JOIN sys.objects obj WITH(NOLOCK) ON obj. = stat. OPEN currentIndex FETCH NEXT FROM currentIndex INTO @SQL WHILE @@FETCH_STATUS = 0 BEGIN print @sql EXEC sys.sp_executesql @SQL FETCH NEXT FROM cur INTO @SQL END CLOSE currentIndex DEALLOCATE currentIndex

Создаем вложенный план с названием «Дефрагментация индекса и обновление статистики» с расписанием раз в день в 4:00 и перетаскиваем в него из Панели элементов Задачу «Выполнение инструкции T-SQL».

Вставляем в задачу приведенную выше инструкцию T-SQL.

Обновление статистики.

Обновление статистики в базах данных MS SQL, как и дефрагментация индекса, имеет большое значение для повышения производительности работы SQL сервера. Благодаря обновлению статистики SQL Server способен более эффективно выполнять планы запроса.

Выбираем на панели элементов Задача «Обновление статистики» и добавляем ее во вложенный план «Дефрагментация индекса и обновление статистики».

• Базы данных: все пользовательские базы данных;
• Обновить: вся собранная статистика;
• Тип просмотра: полный просмотр.

При помощи стрелки связываем условием выполнение задачи по обновлению индекса с задачей по дефрагментации. Таким образом в случае успешного выполнения дефрагментации будет проведено обновление статистики.

Не забываем сохранить созданный план обслуживания…

… и убедиться, что запущен Агент SQL Server.

Доброго времени, гости и читатели блога 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

2.3. Настройка параметров сервера SQL

Для настройки сервера запускаем «SQL Server Management Studio», подключаемся к установленному серверу Database Engine’ом и открываем свойства (Server Properties). Тут нам нужно настроить 3 пункта:

Память (Memory)

Параметр «Maximum server memory (in MB)» задает максимально отведенное серверу количество памяти из расчета: – – . Например, если у нас на сервере всего 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 серера

Удачных Вам бэкапов

В статье ранее о регламентных работах на сервере Microsoft SQL Server мы рассмотрели виды и назначение основных регламентных работ. Для достижения наилучшего результата необходимо, что бы регламентные задания проводились максимально эффективно и минимальным образом влияли на работу сервера во время их проведения.

В большинстве случаев регламентные задания на SQL-сервере проводят раз в сутки ночью, поэтому сгруппируем их для максимально эффективной работы по частоте выполнения. Простые регламентные задания можно создавать через Мастер планов обслуживания, но для тонкой настройки проще создать пустой План заданий и его наполнять, согласно нашим требованиям.

Базовый суточный план обслуживания

Создаем новый План обслуживания и назовем его просто «Ежедневное обслуживание”. С Панели элементов натаскаем в Область конструктора необходимые нам задания: «Проверка целостности базы данных», «Обновление статистики», «Выполнение инструкции T-SQL», «Резервное копирование базы данных” и «Очистка после обслуживания». Для задания последовательности выполнения задания соединим блоки схемы стрелочками. Кроме последовательности выполнения можно задать и условие выполнения этой последовательности. Щелкнув правой кнопкой мышки на линии связи, выбираем условие: «Успешное завершение», «Ошибка” или просто «Выполнение». Выполнение заданий имеет смысл только в случае успешного завершения тестирования баз, а Очистку кеша – после Обновления статистики. Остальные задания выполняются независимо от результата выполнения предыдущего задания.

Настроим каждую задачу:

Проверка целостности базы данных

Проверку выполняем для всех баз, включая индексы

Для всех баз, для все статистики в режиме полного просмотра.

Выполнение инструкции T-SQL

В окне скрипта указываем команду очистки кеша DBCC FREEPROCCACHE

Резервное копирование базы данных

В большинстве случаев достаточно выполнять ежесуточно Полное копирование для Всех пользовательских баз. Зададим папку для сохранения баз – место хранения бакапов должно быть хотя бы на другом диске, а в идеале вообще на другом дисковом массиве. Если баз много, лучше копировать каждую базу в отдельную папку: ставим птичку «Создавать вложенный каталог для каждой базы данных». Весьма полезным будет «Проверять целостность резервной копии” и «Сжимать резервные копии».

Очистка после обслуживания

Чтобы не засорять дисковое пространство старыми неактуальными резервными копиями, необходимо их периодически подчищать. Указываем в задании, что мы будем чистить файлы резервных копий, папку хранения, расширения файлов и срок хранения копий. В выборе срока хранеия необходимо руководствоваться размером копий, доступного места и здравым смыслом. Думаю, вряд ли копии, старше 2 недель имеют какую либо актуальность при исправном выполнении регулярного Резервного копирования.

В добавок, можно переименовать каждое задание по своему усмотрению – F2 или два щелчка по блоку задания.

Теперь осталось указать расписание, например, на 1 час ночи ежедневно, и базовый План обслуживания готов.

Еженедельные планы

Для борьбы с фрагментацией индексов создадим новый план «Недельное обслуживание” и добавим в него два вложенных плана для заданий «Реорганизация (дефрагментация) индексов” и «Перестроение индекса (Реиндексация таблиц)». Для первого зададим периодичность еженедельно по средам на 3 часа ночи, а для второго по воскресеньям тоже на 3 часа ночи. Таким образом мы получаем фактически дефрагментацию 2 раза в неделю. Если потребности в такой частой дефрагментации индексов нет, то можно, например, задать для дефрагментации расписание еженедельно по воскресеньям, а для реиндексации – каждую 4-ю субботу.

Операции с индексами – достаточно ресурсоемкие и требуют разумного взвешенного подхода. В то же время, как показывает практика, дефрагментирование индексов с низкой степенью фрагментации либо с небольшим количеством страниц не дает каких-либо заметных улучшений, способствующих повышению производительности при работе с ними. В простом случае, для не очень нагруженного сервера с небольшим количеством баз подойдут работы с простым расписание разом для всех баз. Для серверов с большим количеством разнонагруженных баз необходим тщательный анализ динамики фрагментации баз. Соответственно, для такого сервера потребуется более тонкая настройка: для некоторых баз или таблиц возможно более частое выполнение (ежесуточно), а для некоторых пореже (ежемесячно). Представление о фрагментированности дает отчет «Физическая статистика индекса». Для формирования отчета кликаем правой кнопкой мышки на базе данных и идем по меню Отчеты –> Стандартные отчеты –> Физическая статистика индекса.

Объединение и группировка планов обслуживания

В самом простом случае можно создать вообще один план обслуживания, а в нем сделать несколько Вложенных планов со своим расписанием и алгоритмом заданий. Однако, для работы нагляднее все же группировать регламентные задачи по периодичности их выполнения.

С 9 сентября 2019 года пользователи 1С:Предприятие 8 ПРОФ могут получить ошибку:

Операция не может быть выполнена с текущим составом лицензий.
Свойства кластера ‘Допустимое отклонение количества ошибок сервера’, ‘Режим распределения нагрузки’ или свойства рабочего сервера ‘Максимальный объём памяти рабочих процессов’, ‘Безопасный расход памяти за один вызов’, ‘Объём памяти рабочих процессов, до которого сервер считается производительным’, ‘Количество ИБ на процесс’ содержит значения, отличные от значений по умолчанию.
Использование этих функций возможно только для лицензии на платформу уровня КОРП. Обратитесь к администратору для решения вопросов приобретения и установки лицензии уровня КОРП.

Для продолжения работы с текущими настройками локального кластера и рабочего сервера необходимо приобрести лицензии уровня КОРП или вернуть значения данных свойств к значениям «по умолчанию».

В любом случае в первую очередь нужно дать пользователям возможность работать дальше, поэтому вернём значения «по умолчанию».

Перезагрузка сервера не потребуется.

Настройки локального кластера

Настройки рабочего сервера

Красным подчёркнуты те значения, которые явно перечислены в тексте ошибки.

Значения по умолчанию

• Допустимое отклонение количества ошибок сервера — 0.
• Режим распределения нагрузки — «Приоритет по производительности».
• Максимальный объём памяти рабочих процессов — 0. Значение определяется автоматически как 80% объема оперативной памяти сервера.
• Безопасный расход памяти за один вызов — 0. Значение объема определяется автоматически, как 5% максимального объема памяти рабочих процессов на данном рабочем сервере.
• Объём памяти рабочих процессов, до которого сервер считается производительным — 0. Значение 0 означает, что никакого ограничения не установлено.
• Количество ИБ на процесс — 8. Если количество информационных баз превысит это количество, то кластер серверов создаст на этом рабочем сервере дополнительный рабочий процесс.

Примечание

Ряд параметров контроля объема памяти процессов можно будет делать с лицензией ПРОФ (04.10.2019)

Нами принято решение, что изменение значений параметров:
* Критический объем памяти процессов
* Временно допустимый объем памяти процессов
* Предел превышения (секунд) временно допустимого объема памяти процессов
можно будет делать с лицензиями уровня ПРОФ.

При этом поведение для опции «Временно допустимый объем памяти процессов» для ПРОФ и КОРП лицензий будет отличаться.
С лицензиями ПРОФ изменение параметра будет действовать только на перезапуск процессов, а с лицензиями КОРП – и на перезапуск процессов, и на прерывание объёмных клиентских вызовов сервера.

Сейчас в версии 8.3.15 эти опции доступны только с лицензиями уровня КОРП.

Изменение попадет в следующую финальную версию 8.3.15 (после 8.3.15.1656).