1С 7.7 зачем-то при входе в систему использует конструкцию

exec sp_dboption 'db_torg', 'select into/bulkcopy', 'false'.

Здесь подробно описан сей факт: Вход-выход в 1С77 меняет recovery model базы на SQL2000 SP4 на Full

Возникает два вопроса:
1. Для чего подобное может быть сделано и что будет, если "отучить" ее это делать?
2. Какие блокировки накладываются сервером при выполнении этой команды, и, соответственно, может ли эта команда конфликтовать с другими процессами сервера?

Сервер MS SQL 2000

Аналогичные вопросы возникают и к другой конструкции

exec sp_dboption 'db_torg', 'single user', 'false' и хотя назначение этого более понятно, все равно остается вопрос про блокировки.

Чтобы было понятнее, откуда растут ноги у вопросов: во время интенсивной работы порядка 60 пользователей каждый новый вход в БД вызывает на некоторое время сильный ступор всех пользователей; при этом средняя очередь диска на запись зашкаливает за 150 при обычной в районе 10-15. Для полноты картины приведу все "подозрительные" команды, которые отправляет 1С при старте:

select 504,c.name,c.description,c.definition from master.dbo.syscharsets c where c.id = convert(tinyint, databasepropertyex ( db_name() , 'sqlcharset'))

Select * from master..sysdatabases where name='db_torg'

exec sp_dboption 'db_torg', 'select into/bulkcopy', 'false'.

exec sp_dboption 'db_torg', 'single user', 'false'

Select CONNECTUUID from _1SCONNECT(TABLOCKX HOLDLOCK)

declare @P3 int
set @P3=2
declare @P4 int
set @P4=2
declare @P5 int
set @P5=-1
exec sp_cursorprepexec @P1 output, @P2 output, NULL, N'Select * from _1SUSERS(UPDLOCK)', @P3 output, @P4 output, @P5 output
select @P1, @P2, @P3, @P4, @P5

Немного внимательней посмотрел, нашел еще такую группу команд:
Create table #__order (ch char(1))
exec sp_executesql N'insert into #__order values(@P1)', N'@P1 char(1)', ''
...

по всей видимости, это тоже может вызывать тормоза

действительно, на этой команде иногда стопорится запуск 1С:
exec sp_executesql N'insert into #__order values(@P1)', N'@P1 char(1)', '
столбец Duration из профайлера равен 37293, т.е. 37 секунд(!) вставка строки во временную таблицу...
А иногда и вовсе это не случается, 1С отваливается с ошибкой "Ошибка блокировки базы данных"
В чем же может быть дело?

Итак, получается что первоначальная тема топика больше неинтересна, ступор не на db_option, а на exec sp_executesql N'insert into #__order values(@P1)', N'@P1 char(1)', '. Случается при наличии более 30 активно работающих сессий 1С. При этом очередь записи диска взлетает в сразу 10 раз

DmitriyZАлександр Дж., переходите на 8 версию. Это будет менее затратно, чем заставить 7.7 удобоваримо работать на вашем количестве пользователей.
У Вас есть определенное мнение, во что нам станет переход на 8 версию?

Программист 1сКаталоги пользователей почистите. А еще лучше удалите и создайте заново пользователей.
Делается регулярно;
Думаю, я уже заглянул поглубже каталогов пользователей:)

Я же уже написал, где наступает затык.
1С при старте проверяет режим сортировки символов в базе данных путем нехитрой конструкции:

Create table #__order (ch char(1))
exec sp_executesql N'insert into #__order values(@P1)', N'@P1 char(1)', ''
...
exec sp_executesql N'insert into #__order values(@P1)', N'@P1 char(1)', 'я'.

Так вот, оказалось что в-основном (при низкой нагрузке со стороны других пользователей) это происходит быстро (при этом на эране пользователя висит желтая сплеш-заставка со строкой "Установка соединения с сервером базы данных".
А вот если пользователей становится побольше определенного порога с одновременно возрастающей активностью, то сервер зависает на первой вставке в таблицу #__order. Насколько я понимаю, причину этого зависания надо искать определенно не в механизмах 1С, а где-то в блокировках сервера. Еще один вариант - "отучить" 1С делать такую проверку путем патчинга bkend.dll... но не хотелось бы

pailТак это от конфигураций зависит - с какой и на какую переходить, да от требований к процессу перехода.
Вот и я про тоже самое, а Вы мне говорите что мне это обойдется дешевле, хотя даже не знаете, что у меня за конфигурация... Она полностью самописная с большим количеством сложного функционала и разных "велосипедов", все заточено под наши конкретные бизнес-требования.
Для того чтобы сделать такой вывод, надо хотя бы иметь приблизительное представление о количестве трудочасов на реализацию всего этого под 8. Пожалуйста, не предлагайте мне в качестве альтернативы сначала "выправить" бизнес под какую-н типовую УТ или УПП

DmitriyZНу, раз вы спрашиваете, почему 7.7 тормозит на 60 пользователях, значит, вы не слышали ни о "Гибких блокировках" от СофтПоинта, ни о 1С++ и т.д. А люди, которые с этим умеют работать сейчас стоят дорого. Вот я и предположил, что дешевле будет перейти на 8 версию, чем глубоко оптимизировать вашу 7.7

Прочитал свой пост и не могу сделать таких далеких выводов...
Я же написал конкретные вопросы по работе 1С7.7, которые возникли при просмотре в профайлере, как из этого можно сделать вывод что я не знаю ничего про...
Так можно было бы подумать, если бы я написал, что-то типа "у нас было 5 пользователей и все ок, а теперь 60 и все плохо, помогите:)"
Уже более 3 лет число активных пользователей нашей БД перевалило за 60, но описанная проблема производительности не возникала так остро как сейчас. Я понимаю, что вопрос скорее системный: все больше функционала, все больше нагрузки, все больше размер БД, все больше конкурентных процессов... Но это все не к теме топика. В теме топика и моих первых постах озвучены конкретные проблемы, которые и интересуют меня в данный момент. Хотелось бы видеть ответы именно по этим вопросам.

"Гибкие блокировки" от СофтПоинта не внедрял, но сделал по их схеме свое решение, работает вполне сносно
А как можно работать в нашей базе без 1С++ себе вообще не представляю

pailПро "дешевле" я как раз и не говорил ничего - просто поинтересовался.
"менее затратно"=="дешевле". Это была не Ваша фраза, я уже увидел, прошу прощения
pailА на УТ - перевел несколько предприятий. С годами заточенной-перезаточенной 7ки. Да и не типовая уже она, УТ эта.
Потому что перевод этот происходил так:
- подключение 7й базы к УТ. На постоянный односторонний обмен изменениями.
- перенос актуальных "заточек" в новую конфигурацию.
- воспроизведение бизнес-процессов и их итогов в новой базе (все это время - обмен продолжается, работа велась в старой базе).
И только после готовности новой системы к эксплуатации, со всеми данными и всеми процессами - пересаживание в нее пользователей. Процесс не быстрый. Но переход теперь уже состоялся.
"УТ 11" здесь - не более, чем заготовка для перезатачивания.

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

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