Имеется база на SQL и её файловая копия. Обычное приложение, режим блокировок = Управляемый.
В базах по одному пользователю, все регл задания отключены.
Одной и той же обработкой записываются данные наборами записей в независимые РС в обоих базах.
На файловой процесс занял 5 минут, на серверной - 2 часа.

Замер производительности показал, что на серверной базе "НаборЗаписей.Записать()" выполняется в 100 раз дольше, чем в файловой.

Какие есть способы ускорить производительность серверной БД?

Переписать код. Например, писать порциями.

Несколько заданий по кускам писать

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

(0) какой объем базы?Какой объем записей?

(3)[ SQL до скорости работы файловой базы]
такого бреда на работе не бывает

(5) Бывает! В одном ТПХ, ты там был, служебка была "Требую увеличить производительность 1С и MSSQL втрое". И это не помешало компании бодро расти, просто поржали отделом и пошли работать дальше.

Транзакции?

(3) задача

В общем случае это недостижимо. В частном - вполне.

(1) какими порциями? Это записи в РС, на каждый набор измерений делается свой набор записей

(8) ну и где счётчики производительности ?

все значения в регистрах не ссылочные, примитивных типов

(11) сабж читал?

(13) мозг включал ?

(13) Так смотрел или нет?Откуда мы знаем,что у тебя происходит.

сорри, счетчики производительности не настраивал, только замер производительности 1С

(17) и даже на сиквеле регламенты не поднял ?

(0) Настрой СКЛ, там разница должна быть не более 20-30%

А потом окажется,что на серваке крутиться еще 100500 сервисов

Может сервер 1С или скуль на пентиуме 486 крутятся? Ты файловую-то сравни на этих двух хостах.

(6) :) а в военное время число пи может достигать 4(с)

(19) [ должна быть не более 20-30%]
нет конечно
есть задачи на которых файловая быстрее в разы, ибо на план запросов влияние в 1С слабое

развернул пустую БД на сервере и в файле. Добавил 1 РС.
Запустил добавление 10 000 записей через отбор к набору записей.

Файловая:   17сек
Серверная:  3мин

а Sql какой?не слон случаем?

(24) ни о чем

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

(24) У меня программер развернул СКЛ, 24 операции в секунду, попросил глянуть тех дира, он обматерился, настроил на 20к операций

(24) А теперь нажми ресет во время исполнения этого кода.

(28) [ программер развернул СКЛ]
о боги
у тебя в команде нет DBA =)

файловую на том же серваке разворачивал? скл и 1с на разны серверах?

не тема, а какой-то наброс

никаких конкретных параметров, никаких описаний среды исполнения - зато есть сакральный вопрос "а почему"

Вангую
mdop<>1

(33) разве мс до сих пор не научился в параллельные запросы?

(34) нет... Если рассматривать МС СКЛ и в контексте данного топика, то и не научится никогда

(0) Не надо сравнивать теплое с мягким. На SQL-базе вы будете работать, причем довольно неплохо, когда файловая будет стоять колом из-за табличных блокировок. Я про количество одновременных подключений, если что.

(0) дык если файловая для вас работает быстрее, нафига вы продолжаете "жрать кактусы"?

Попробуй монопольный режиме. Управляемые блокировки не будут устанавливаться - не будут тратиться на это ресурсы сервера 1с.

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

(34) (35) Включали mdop > 1 на последних проектах, до которых рука надежного админа дотянулась - прирост в тяжелых запросах наблюдается, критичного замедления в каких-то других местах от пользователей не поступали. Так что хз с чем связана рекомендация 1С не включать - может те времена прошли уже.

(39) ну так у него в файловой базе и без упр блокировок шоколадно все
с его вводными

(40) работает 800 человек онлайн. Расчетчик в ЗУПе не поставил отбор и загрузил весь сервак, пользователи в БП страдают.
Есть рекомендация от самого Майкрософт по установке modp в зависимости от количества ядер

(24) У меня на серверной локально 1 миллион записей за 40 секунд

На домашнем компе

(37) файловая база это антоним безопасности

(24) А теперь в непустую, в 10 потоков и по десятку миллионов записей

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

(0) Вы хоть огласите версию БД, а то чет на фоне семи мелодий трудно рассуждать.
...у нас все работает нормально, от УПП, до БП 3 и ЗУП 3.1 :)...

(0) Сколько пользователей было в этих базах, когда вы писали записи?

(48) Извините, криво прочитал топик(

(46) ну не в 100 раз же.

Вангую, что на сервере стоит эмулятор процессора, с миллионом ядер по 2 ГГц, а локальная база на нормальном ПК. Хотя разницу в 30 раз это не объяснит, но все-таки любопытно сравнить частоты ядер.

(51) частоты будут сравнимые, на сервер -20% от рабочей станции, что к результату не имеет ни малейшего отношения

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

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

(54) Ну он же вроде раз записал

(0) >>Как ускорить SQL до скорости работы файловой базы?

Никак
При указанных в (0) условиях (однопользовательские базы) файловый вариант всегда !!! будет работать быстрее чем база на SQL. И ничего с этим поделать невозможно.
Правильной настройкой SQL-сервера можно сделать так, что разница в скорости будет не очень отличаться, но сравняться не удастся никогда

(56) Если задействовать RLS (оставим за скобками нужность этого для однопользовательской базы - допустим, у нас копия центральной базы, где часть данных надо скрыть от пользователя) - файловый вариант быстрее не будет. А еще он не будет быстрее когда таблица превысит размер 4 Гб или размер записи индекс превысит около 2 кБ.

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

ох, тудыть твою раскудахтыть

- у этой неведомой херни еще и регистров не один и даже не два, а целая туева хуча, то их оказывается можно и нужно по разным потокам распихать!

(0) SQL 2017 + оперативной памяти побольше если тормоза в записи можно SSD воткнуть
Нужно знать параметры базы чтобы цифра по точнее озвучить

(60) да но скорости файловой недостич

(61) Отбиваю пять вам и коллеге из (9)

(60) SSD (ну или хороший кеширующий контроллер с батарейкой) нужен в любом случае - запись в журналы-то не кешируются во избежание.