Как настроить 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С обрабатывает бизнес-логику и взаимодействует с СУБД.

Важно понимать: сам по себе 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 Express. Для рабочей базы 1С эту редакцию стоит рассматривать очень осторожно: у нее есть ограничения по ресурсам и размеру базы, а запас по масштабированию быстро заканчивается.

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

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

Перед установкой: что подготовить на сервере

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

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

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

Collation: почему важно выбрать правильную сортировку

При установке SQL Server нужно обратить внимание на параметр сортировки — collation. Он влияет на правила сравнения и сортировки строк. Для 1С обычно используют русскоязычную сортировку, совместимую с требованиями используемой версии платформы и конфигурации.

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

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

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

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

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

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

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

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

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

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

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

MaxDOP: зачем для 1С часто устанавливают значение 1

Параметр max degree of parallelism, или MaxDOP, определяет, сколько процессоров SQL Server может использовать для параллельного выполнения одного запроса. В обычных SQL-нагрузках параллелизм может быть полезен, но для 1С он не всегда дает ожидаемый эффект.

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

Пример настройки:

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

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

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

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

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

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

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

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

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

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

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

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

Пример логики настройки:

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

Размер файлов зависит от нагрузки. Для небольшой базы это могут быть одни значения, для крупной базы с тяжелыми отчетами и обменами — совсем другие. Нельзя просто скопировать настройку с чужого сервера и считать ее правильной.

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

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

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

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

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

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

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

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

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

Лучше использовать фиксированный прирост в мегабайтах. Например, для рабочих баз часто задают прирост сотнями мегабайт, а не 10% от текущего размера. Конкретное значение зависит от размера базы, скорости роста и доступного места на диске.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для рабочих баз 1С нужен регулярный план обслуживания. В него обычно включают:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Практические рекомендации

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

• проверить редакцию SQL Server и ее ограничения;
• убедиться, что выбран корректный collation;
• ограничить память SQL Server через max server memory;
• установить MaxDOP в значение, подходящее для нагрузки 1С;
• настроить tempdb: несколько файлов данных, одинаковый размер, фиксированный прирост;
• разместить файлы данных, журналы, tempdb и резервные копии с учетом дисковой нагрузки;
• задать фиксированный прирост файлов базы и журнала;
• выбрать модель восстановления осознанно;
• настроить резервное копирование и проверить восстановление;
• настроить регламент обслуживания индексов и статистики;
• развести по времени обслуживание SQL Server, резервное копирование и тяжелые задания 1С;
• настроить мониторинг свободного места, ошибок SQL Server, роста журнала и нагрузки на диски.

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

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

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

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

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

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

Заключение

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

Хорошая конфигурация начинается еще до установки: нужно понимать, где будут размещены файлы базы, сколько памяти можно отдать SQL Server, какая модель восстановления нужна бизнесу и как будет проверяться резервное копирование. Если эти вопросы отложить «на потом», проблемы обычно появляются уже в рабочей эксплуатации.

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

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

Кратко

• SQL Server не ускоряет 1С автоматически: его нужно настраивать под конкретную базу и нагрузку.
• Для рабочей базы 1С обычно не стоит использовать SQL Server Express из-за ограничений редакции.
• После установки SQL Server нужно настроить память, MaxDOP, tempdb, автоувеличение файлов и план обслуживания.
• Файлы данных, журнал транзакций, tempdb и резервные копии лучше размещать с учетом разного характера нагрузки.
• Полная модель восстановления требует регулярных резервных копий журнала транзакций.
• Бэкап нельзя считать надежным, пока не проверено восстановление.
• Индексы и статистику нужно обслуживать регулярно, но в технологическое окно.
• Если 1С тормозит, сначала нужно искать узкое место: CPU, память, диски, блокировки, tempdb, журнал транзакций или фоновые задания.