Как настроить SQL Server для 1С и избежать проблем с производительностью

Переход 1С из файлового варианта в клиент-серверный режим часто воспринимают как автоматический способ ускорить работу пользователей. На практике это не всегда так. Если SQL Server установлен с настройками по умолчанию, база может работать нестабильно: отчеты выполняются долго, пользователи жалуются на зависания, регламентные задания мешают дневной работе, а резервные копии занимают слишком много времени.

Причина не всегда в самой 1С. В клиент-серверной схеме производительность зависит сразу от нескольких компонентов: сервера 1С, SQL Server, дисковой подсистемы, памяти, сети, настроек базы данных и качества обслуживания. Если один из этих элементов настроен неправильно, пользователи видят это как «тормозит 1С», хотя реальная проблема может находиться на уровне СУБД.

В этой статье разберем, какие параметры SQL Server особенно важны для работы 1С: редакция SQL Server, память, MaxDOP, tempdb, файлы базы данных, журнал транзакций, резервное копирование, индексы и статистика. Это не универсальный рецепт для любой инфраструктуры, а практический чек-лист, который помогает избежать типичных ошибок при настройке SQL Server под 1С.

Когда 1С действительно нужен SQL Server

Файловый вариант 1С удобен для небольших баз и простых сценариев. Его проще развернуть, не нужно отдельно администрировать СУБД, а резервное копирование часто сводится к копированию файла информационной базы. Но по мере роста базы и количества пользователей файловый режим начинает упираться в ограничения архитектуры.

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

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

Важно понимать: сам по себе SQL Server не делает 1С быстрой. Он дает больше возможностей для масштабирования, обслуживания, резервного копирования и контроля нагрузки. Но если его установить «по умолчанию» и не настроить под рабочую базу, часть преимуществ клиент-серверной архитектуры будет потеряна.

Что влияет на скорость 1С в связке с SQL Server

Производительность 1С в клиент-серверном варианте складывается из нескольких факторов.

• Процессор. Важна не только частота, но и поведение конкретной конфигурации 1С. Некоторые операции лучше масштабируются по ядрам, другие зависят от скорости выполнения одного потока.
• Оперативная память. SQL Server активно использует память для кэширования данных и планов запросов. Если память не ограничить, СУБД может занять почти всю доступную RAM и оставить слишком мало ресурсов операционной системе и другим службам.
• Диски. Для рабочих баз 1С особенно важна задержка ввода-вывода. Медленные диски быстро становятся узким местом при активной записи, построении отчетов, обновлении индексов и работе журнала транзакций.
• Настройки SQL Server. Память, MaxDOP, tempdb, автоувеличение файлов, модель восстановления и план обслуживания напрямую влияют на стабильность работы.
• Состояние базы. Фрагментация индексов, устаревшая статистика, чрезмерно выросший журнал транзакций и ошибки в регламентных заданиях могут заметно ухудшить работу пользователей.
• Нагрузка со стороны 1С. Медленные запросы, тяжелые отчеты, фоновые задания, обмены и блокировки часто оказывают большее влияние, чем «железо» само по себе.

Поэтому настройку SQL Server для 1С нельзя свести к одной команде или одному параметру. Нужен комплексный подход: сначала корректная установка и базовая конфигурация, затем обслуживание и регулярный мониторинг.

Выбор редакции SQL Server для 1С

Редакцию SQL Server нужно выбирать по ограничениям конкретной версии, размеру базы, нагрузке, требованиям к резервному копированию и доступности функций администрирования.

SQL Server Express может использоваться для разработки, тестирования и небольших рабочих сценариев, если база и нагрузка укладываются в ограничения выбранной версии. Но перед использованием нужно проверить:

• максимальный размер одной базы;
• доступный объем памяти для Database Engine;
• ограничения по процессорным ресурсам;
• наличие необходимых средств автоматизации и обслуживания;
• прогноз роста базы;
• возможность последующего перехода на другую редакцию.

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

Подготовка сервера

Перед установкой SQL Server стоит проверить базовые параметры сервера. Это особенно важно, если 1С и SQL Server работают на одной виртуальной машине.

• Операционная система должна быть обновлена. Накопленные обновления Windows Server и драйверов лучше установить до ввода сервера в эксплуатацию.
• Диски нужно разделить по назначению. По возможности файлы данных, журналы транзакций, tempdb и резервные копии размещают на разных дисковых томах или массивах. В небольшой инфраструктуре это не всегда возможно, но смешивать все на одном медленном диске — плохая идея.
• Антивирус нужно настроить аккуратно. Проверка файлов баз данных SQL Server в реальном времени может создавать дополнительную задержку. Исключения следует настраивать осознанно, с учетом политики безопасности.
• Нужно заранее определить учетные записи служб. Для SQL Server лучше использовать отдельные служебные учетные записи с минимально необходимыми правами.
• Нужно понимать схему размещения ролей. Если сервер 1С и SQL Server находятся на одной машине, настройки памяти и дисков нужно планировать особенно внимательно.

Для небольших баз допустимо размещать сервер 1С и SQL Server на одной виртуальной машине. Для более нагруженных систем лучше разделять роли: отдельно сервер 1С, отдельно SQL Server. Это упрощает масштабирование, обслуживание и диагностику.

Collation: что проверить до создания базы

Collation определяет правила сравнения и сортировки строк, чувствительность к регистру и некоторые особенности работы текстовых данных. Неподходящие параметры могут привести к ошибкам при создании или эксплуатации информационной базы.

Перед установкой SQL Server и созданием базы нужно проверить:

• какие параметры сортировки поддерживает используемая версия платформы 1С;
• какой collation установлен у экземпляра SQL Server;
• какой collation будет назначен новой базе;
• не используются ли на сервере другие приложения с собственными требованиями;
• совпадают ли параметры новой и переносимой базы.

Память SQL Server: почему нельзя оставлять настройку по умолчанию

Одна из самых частых ошибок — оставить максимальный объем памяти SQL Server без ограничения. По умолчанию SQL Server может использовать очень большой объем RAM. Для выделенного сервера СУБД это не всегда проблема, но для сервера, где одновременно работают SQL Server, сервер 1С, антивирус, агенты мониторинга и другие службы, такая настройка может привести к нехватке памяти у операционной системы.

max server memory

Правильный подход — задать параметр max server memory. Он ограничивает объем памяти, который SQL Server может использовать для своих внутренних задач. Значение не должно выбираться наугад. Нужно оставить память операционной системе, службам 1С, антивирусу, резервному копированию и другим процессам.

Например, если на сервере 64 ГБ RAM и на нем работает только SQL Server, под СУБД можно выделить большую часть памяти, оставив запас системе и служебным процессам. Если на этой же машине расположен сервер 1С, запас должен быть больше. Универсальной цифры нет: ее выбирают по роли сервера, объему базы, числу пользователей и фактической нагрузке.

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

Пример настройки через T-SQL:

Ниже показан только синтаксис настройки. Значение 49152 нельзя переносить на другой сервер без расчета.

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'max server memory (MB)', 49152;
RECONFIGURE;

Параметр вступает в силу без перезапуска SQL Server. После изменения нужно контролировать память Windows, процесс sqlservr.exe, использование файла подкачки и потребление памяти рабочими процессами 1С.

В этом примере SQL Server ограничен 48 ГБ памяти. Значение приведено только как пример. Для реального сервера его нужно рассчитывать отдельно.

MaxDOP: когда для базы 1С используют значение 1

Параметр max degree of parallelism ограничивает число процессоров, которые SQL Server может использовать для параллельного выполнения одного запроса.

В методических рекомендациях для серверов, обслуживающих базы 1С, часто используется MAXDOP = 1. Такое значение отключает параллельное выполнение запросов и может уменьшить проблемы, связанные с нежелательным параллелизмом в типичной нагрузке 1С.

Однако это не универсальное правило для любого экземпляра SQL Server. Перед изменением нужно учитывать:

• используется ли экземпляр только для баз 1С;
• версию SQL Server;
• число логических процессоров и структуру NUMA;
• наличие других баз и приложений;
• фактические ожидания и планы выполнения;
• влияние настройки на обслуживание индексов и DBCC CHECKDB.

Сначала проверьте текущее значение:

SELECT name, value, value_in_use
FROM sys.configurations
WHERE name = 'max degree of parallelism';

Изменение до 1 может выглядеть так:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;

Отдельно существует параметр cost threshold for parallelism, который влияет на то, для каких запросов SQL Server рассматривает параллельный план. Если MAXDOP установлен в 1, параллельное выполнение отключено, но при других значениях оба параметра следует рассматривать вместе.

tempdb: почему эта база важна для 1С

tempdb — системная база SQL Server, которая используется для временных объектов, сортировок, промежуточных результатов запросов, версионности строк и других внутренних операций. В обычной работе ее легко не замечать, но при высокой нагрузке именно tempdb может стать одним из узких мест.

Для 1С это особенно важно, потому что платформа активно работает с временными таблицами и сложными запросами. Если tempdb размещена на медленном диске, имеет один маленький файл данных или часто увеличивается во время работы, пользователи могут видеть задержки при формировании отчетов, проведении документов и выполнении регламентных операций.

Основные рекомендации по tempdb:

• разместить tempdb на быстром диске;
• не держать ее на одном медленном томе вместе с файлами базы, журналами и резервными копиями;
• создать несколько файлов данных одинакового размера;
• заранее задать разумный начальный размер файлов;
• использовать фиксированный прирост, а не прирост в процентах.

В общих рекомендациях Microsoft часто встречается подход: начинать с нескольких файлов данных tempdb и увеличивать их количество при наличии признаков конкуренции за страницы распределения. В средах 1С обычно используют более консервативный практический вариант: несколько файлов одинакового размера, часто четыре файла данных, с последующим наблюдением за нагрузкой.

Главная мысль здесь простая: tempdb не должна расти хаотично во время рабочего дня. Ее размер и размещение нужно продумать заранее.

Как настроить файлы tempdb

Универсального числа файлов tempdb для любой базы 1С нет. Для современных версий SQL Server установщик обычно предлагает несколько файлов с учетом числа логических процессоров.

При проверке конфигурации убедитесь, что:

• файлы данных имеют одинаковый начальный размер;
• для них установлен одинаковый прирост;
• начальный размер покрывает обычную рабочую нагрузку;
• на диске есть запас для незапланированного роста;
• автоувеличение не происходит регулярно в рабочее время;
• число файлов увеличивается только при подтвержденной конкуренции в tempdb.

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

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

Файлы базы данных и журнал транзакций

Информационная база 1С в SQL Server обычно состоит как минимум из двух типов файлов:

• файл данных — содержит таблицы, индексы и другие объекты базы;
• журнал транзакций — фиксирует изменения, необходимые для восстановления целостности базы.

Размещение файлов

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

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

Разделение файлов имеет смысл, если оно действительно дает независимые ресурсы ввода-вывода, упрощает контроль свободного места или позволяет применять разные политики хранения и резервного копирования.

Мгновенная инициализация файлов данных

Instant File Initialization позволяет SQL Server быстрее создавать и увеличивать файлы данных, не заполняя все новое пространство нулями. Для этого учетной записи службы SQL Server предоставляется право Windows «Выполнение задач по обслуживанию томов».

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

Автоувеличение файлов: как сделать рост предсказуемым

Автоувеличение — это защитный механизм на случай незапланированного роста, а не основной способ управления размером базы. Файлы лучше заранее выделять с учетом текущего объема и прогноза роста.

Фиксированный прирост в мегабайтах обычно проще контролировать, чем процент: администратор заранее понимает, сколько места потребуется при каждом событии расширения. Но конкретное значение зависит от размера файла, скорости роста и производительности хранилища.

Для каждого файла нужно определить:

• разумный начальный размер;
• фиксированный прирост;
• максимальный размер либо порог оповещения;
• минимальный запас свободного места;
• мониторинг событий автоувеличения.

Журнал транзакций: почему он растет

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

Администратор видит, что файл журнала становится все больше, и иногда пытается решить проблему простым уменьшением файла. Это временная мера, которая не устраняет причину. Если не настроить правильное резервное копирование, журнал снова начнет расти.

Нужно различать две вещи:

• размер файла журнала на диске;
• используемое пространство внутри журнала.

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

Журнал может не освобождать внутреннее пространство и по другим причинам:

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

Перед уменьшением файла нужно проверить, почему SQL Server не может повторно использовать пространство журнала:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = N'ИмяБазы';

Модель восстановления базы данных

В SQL Server для базы данных можно выбрать модель восстановления. На практике чаще всего встречаются две модели: Simple и Full.

В SQL Server также существует модель Bulk-logged, предназначенная для отдельных сценариев массовых операций. В типовой эксплуатации 1С чаще выбирают между Simple и Full, поэтому далее рассмотрены именно они.

Simple проще в обслуживании. SQL Server сам освобождает неактивную часть журнала транзакций после контрольных точек. Но восстановиться можно только на момент последней полной или дифференциальной резервной копии.

Full позволяет восстанавливать базу более гибко, вплоть до определенного момента времени, если настроены резервные копии журнала транзакций. Но эта модель требует дисциплины: нужно регулярно делать не только полные копии, но и резервные копии журнала.

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

Резервное копирование и обслуживание SQL Server для 1С

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

• RPO — сколько последних данных допустимо потерять;
• RTO — за какое время база должна быть восстановлена.

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

Возможная схема может включать:

• полная резервная копия — например, ежедневно ночью;
• дифференциальная копия — несколько раз в день, если база большая и полная копия занимает много времени;
• копии журнала транзакций — при полной модели восстановления, с интервалом, который соответствует требованиям к потере данных;
• копия вне сервера — чтобы сбой диска или виртуальной машины не уничтожил и базу, и резервные копии одновременно.

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

Отдельно нужно проверять восстановление. Бэкап, который ни разу не восстанавливали на тестовой среде, нельзя считать надежным. Файл может быть поврежден, копия может не содержать нужный момент времени, а процедура восстановления может оказаться слишком долгой для бизнеса.

Что важно учитывать при резервном копировании 1С

При работе с 1С важно согласовать резервное копирование SQL Server с особенностями эксплуатации информационной базы.

• Не стоит запускать тяжелое резервное копирование в часы пик.
• Регламентные задания 1С и обслуживание SQL Server лучше развести по времени.
• Перед крупными обновлениями конфигурации нужно делать отдельную резервную копию.
• После настройки бэкапов нужно проверить восстановление на тестовом сервере.
• Для важных баз нужно документировать порядок восстановления.

Правильный вопрос звучит не «есть ли у нас бэкап», а «сможем ли мы восстановить базу в нужный срок и с допустимой потерей данных». Для рабочих баз 1С это критично, потому что простой учетной системы быстро становится проблемой не только ИТ-отдела, но и всей компании.

Обслуживание индексов и статистики

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

Перед выполнением работ нужно учитывать:

• размер таблицы и индекса;
• фактическую фрагментацию;
• число страниц;
• характер рабочей нагрузки;
• доступное технологическое окно;
• рост журнала транзакций;
• доступное место на диске;
• влияние операции на пользователей и резервное копирование.

Небольшие индексы часто не требуют обслуживания, даже если процент фрагментации выглядит высоким. Для крупных объектов решение принимают по измерениям и истории нагрузки.

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

Статистика помогает SQL Server оценивать, сколько строк будет обработано при выполнении запроса. От этого зависит выбор плана выполнения: какие индексы использовать, в каком порядке соединять таблицы, какие операции выполнять.

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

На практике администратор должен следить за тем, как база ведет себя после обновлений, закрытия месяца, массовых загрузок данных, обменов и крупных изменений конфигурации. Именно после таких операций проблемы со статистикой проявляются особенно заметно.

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

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

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

DBCC CHECKDB проверяет логическую и физическую целостность базы, но на крупной системе может потреблять значительные ресурсы и место для внутреннего снимка. Запуск нужно планировать с учетом размера базы и производительности хранилища.

DBCC CHECKDB (N'ИмяБазы')
WITH NO_INFOMSGS, ALL_ERRORMSGS;

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

Что проверить, если 1С тормозит на SQL Server

Когда пользователи жалуются на медленную работу 1С, не стоит сразу менять все настройки SQL Server подряд. Сначала нужно понять, где именно находится узкое место.

Базовая диагностика обычно начинается с нескольких вопросов:

• тормозит вся база или отдельные операции;
• проблема возникает у всех пользователей или только у части;
• замедление постоянное или появляется в определенное время;
• совпадает ли проблема с резервным копированием, обменами или регламентными заданиями;
• есть ли рост очереди диска, нехватка памяти, высокая загрузка CPU;
• не вырос ли журнал транзакций;
• обновлялись ли недавно платформа 1С, конфигурация, SQL Server или Windows.

Если тормозит только один отчет или одна обработка, проблема может быть не в сервере, а в конкретном запросе, блокировках или особенностях конфигурации. Если медленно работает вся база, нужно смотреть ресурсы сервера, состояние SQL Server и активность фоновых заданий.

На что смотреть в первую очередь

При первичной диагностике полезно проверить несколько базовых показателей.

Диагностику лучше вести от простого к сложному. Сначала ресурсы сервера и очевидные события, затем SQL-ожидания, активные запросы, блокировки, планы выполнения и технологический журнал 1С.

Типичные ошибки настройки SQL Server для 1С

Ниже — ошибки, которые часто встречаются при эксплуатации 1С на SQL Server.

Когда стоит разделить сервер 1С и SQL Server

Для небольших систем сервер 1С и SQL Server могут работать на одной машине. Это упрощает инфраструктуру и снижает расходы. Но по мере роста нагрузки такой вариант становится менее удобным.

Разделение ролей стоит рассмотреть, если:

• сервер регулярно испытывает нехватку памяти;
• SQL Server и рабочие процессы 1С конкурируют за CPU, память или диски;
• база быстро растет, а окна обслуживания становятся короче;
• появились тяжелые отчеты и обмены;
• нужно отдельно масштабировать СУБД и сервер 1С;
• требования к резервному копированию и доступности стали выше.

Раздельное размещение не всегда ускоряет систему само по себе. Но оно дает больше контроля: можно отдельно настраивать ресурсы SQL Server, отдельно масштабировать сервер 1С, проще анализировать нагрузку и планировать обновления.

Общая схема размещения компонентов разобрана в статье «Серверная инфраструктура 1С».

Практический чек-лист настройки SQL Server для 1С

• Проверены версия, редакция и ограничения SQL Server.
• Проверена совместимость с используемой версией платформы 1С.
• До создания базы выбран подходящий collation.
• Проверен уровень совместимости базы данных.
• Настроен max server memory с учетом Windows, 1С и других служб.
• Решение по MAXDOP принято с учетом рекомендаций 1С, архитектуры SQL Server и других баз экземпляра.
• Проверен cost threshold for parallelism.
• Файлы tempdb имеют одинаковый размер и контролируемый прирост.
• Начальный размер tempdb соответствует обычной нагрузке.
• Проверено реальное размещение файлов данных, журнала, tempdb и резервных копий.
• Для файлов задан предсказуемый прирост и настроен контроль свободного места.
• Выбрана модель восстановления в соответствии с RPO и RTO.
• При Full настроены регулярные резервные копии журнала.
• Резервные копии хранятся вне рабочего сервера.
• Восстановление регулярно проверяется на тестовой среде.
• Обслуживание индексов выполняется по состоянию объектов, а не вслепую.
• Настроены обновление статистики и контроль планов запросов.
• DBCC CHECKDB выполняется в подходящее технологическое окно.
• Настроен мониторинг памяти, дисков, журнала транзакций, ошибок, блокировок и автоувеличения.
• После изменения настроек сравнивается производительность одинаковых рабочих операций.

Заключение

SQL Server не ускоряет 1С автоматически. Стабильность клиент-серверной базы зависит от редакции СУБД, памяти, параллелизма, tempdb, дисковой подсистемы, журнала транзакций, резервного копирования и регулярного обслуживания.

При этом настройки нельзя копировать с другого сервера как универсальный шаблон. Значения max server memory, MAXDOP, число файлов tempdb и размер автоувеличения должны учитывать конкретную версию SQL Server, архитектуру сервера и фактическую нагрузку 1С.

После первоначальной настройки SQL Server необходимо наблюдать в рабочей эксплуатации: анализировать ожидания, блокировки, запросы, рост файлов и время выполнения ключевых операций.

Что почитать дальше

• Серверная инфраструктура 1С — размещение платформы, СУБД, сети, резервного копирования и мониторинга.
• Почему 1С тормозит на сервере — пошаговая диагностика клиента, кластера, СУБД и прикладного кода.
• Как обновить платформу 1С на сервере — подготовка, резервное копирование и проверка после обновления.
• Сетевые порты сервера 1С — соединения между кластером и SQL Server.

Когда стоит обратиться к специалистам

Небольшую тестовую базу можно развернуть самостоятельно. Но изменение параметров рабочего SQL Server затрагивает производительность, журнал транзакций, резервное копирование и возможность восстановления.

IPWAY оказывает услуги по поддержке и сопровождению 1С: помогает настроить сервер платформы, Microsoft SQL Server, резервное копирование, мониторинг и диагностику производительности.

Для размещения базы в подготовленной инфраструктуре также доступна аренда сервера с лицензиями 1С.

Кратко

• SQL Server нужно настраивать под конкретную базу и нагрузку 1С.
• Редакцию выбирают по ограничениям конкретной версии, а не только по названию Express или Standard.
• max server memory должен оставлять ресурсы Windows, серверу 1С и другим процессам.
• MAXDOP = 1 часто используется для баз 1С, но не должен применяться вслепую к любому экземпляру.
• Число файлов tempdb и их размер подбираются по процессорам, нагрузке и признакам конкуренции.
• Разные буквы дисков не всегда означают независимое физическое хранилище.
• Автоувеличение не заменяет предварительное планирование размера файлов.
• При модели Full нужны регулярные резервные копии журнала транзакций.
• Индексы и статистику обслуживают по состоянию базы, а не универсальным расписанием.
• Ошибки DBCC CHECKDB в первую очередь устраняют восстановлением из проверенной резервной копии.
• При замедлении нужно анализировать ожидания, запросы, блокировки и нагрузку за тот же период.