Есть непонятный глюк
При выполнении запроса в транзакции время выполнения 0,5 сек
При выполнении запроса в без транзакции время выполнения 0,003 сек

НачатьТранзакцию();
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ споСпецУсловияСрезПоследних.* ИЗ    РегистрСведений.споСпецУсловия.СрезПоследних(Условие) КАК споСпецУсловияСрезПоследних";
Выборка = Запрос.Выполнить().Выбрать();
ЗафиксироватьТранзакцию();

Народ объясните почему это происходит и как с этим бороться?

(0)А зачем чтение данных пихать в транзакцию?

Чтение происходи в обработке проведения то все плохо.
Если вынести этот запрос в консоль то все хорошо.
А это как пример.

(2)Обработка проведения -сама по себе транзакция.Убери и не мучайся.

У меня в обработке проведения есть код
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ споСпецУсловияСрезПоследних.* ИЗ    РегистрСведений.споСпецУсловия.СрезПоследних(Условие) КАК споСпецУсловияСрезПоследних";
Выборка = Запрос.Выполнить().Выбрать();
Он выполняется 0,5 сек

Если этот код выполнить обработкой тогда 0,003 сек

Если в обработке добавить транзакцию то тоже будет 0,5 сек.

(0)
При выполнении вне транзакции - запрос выполняется в READ UNCOMMITTED. Т.е. никакие блокировки не накладываются.
При выполнении в транзакции - запрос выполняется (в зависимости от режим управления блокировками и для автоматического от типа данных) в READ COMMITTED, REPEATABLE READ или SERIALIZABLE - т.е. на все считываемые данные накладываются S блокировки.

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

Смысл оборачивания в транзакцию можешь пояснить?

(5) в READ UNCOMMITTED насколько я помню только списки читают.

(6) Эксперимент. Изначально код был в обработке проведения, которая выполняется в транзакции.

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

(0) открывай профайлер и смотри.

В сабже это упрощенный пример.

В реальной базе этот запрос выполняется в обработке проведения которая сама по себе транзакция

Если этот код выполнить в не обработки проведения то все быстро.

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

Если этот запрос выполнить в T-SQL на сервере БД то этот запрос выолняется быстро что в транзакции что без.

(11) значит сервер 1с вешает блокировки (управляемые) после выполнения запроса.

(11) какой то бессмысленный набор фраз. уж простите

(11) Во всей ли? На уровне самой конфигурации какой режим блокировки?

При выполнении на QueryAnalizer
SQL:BatchCompleted    BEGIN TRAN "0"    
SQL:BatchCompleted    exec sp_executesql N'SELECT #V8TblAli1_Q_000_T_001._Fld23302RRef AS f_1.....  "2"
SQL:BatchCompleted    Commit TRAN "0"
В кавычках это задержка

При выполнении из 1C обработки из сабж
задержка 537

(14) Управляемый

Вы хотите понять почему платформа работает именно так?
Ответ: потому что ее так написали.
Единственный путь - отправит на хотлайн, тут вам врят ли помогут

(17) В идеале хотелось бы понять почему так.
Но еще больше бы хотелось узнать как это вылечить.
Если перегрузить сервер SQL то эта проблема отпадет на какое то время.

(18) как это вылечить уже пояснили. не делать так. все равно это бессмысленно. так зачем выяснять почему? возможно какие то издержки сервера 1С на управления транзакциями.

(18) SQL или сервер предприятия?

(20) SQL

(21) тогда запустить технологический журнал и его считать. может там что путное покажется

(19) Нельзя не делать так.
Подготовка данных в обработке проведения неизбежна значит не избежны запросы в транзакции.
Постоянно дергать SQL тоже не выход.

*Мне интересна эта тема*

Сравни посимвольно запросы на уровне MSSQL.Только очень внимательно а лучше сравнением двух файлов. Посмотри разницу(если она есть).  
В трассе MSSQL запрос сколько выполняется(duration) в одном и в другом случае? (не в отладчике а именно в трассе)
Ситуация возникает постоянно? Ситуация моделируется? Я уверен что дело соверешенно в другом.

(25) Эмуляция ситуации
В 1С запускаю обработку в сабже.
Задержка(duration) выполнения в трассе 537
Беру из трассы запрос (один к одному) и выполняю его в Query Analizer
Задержка(duration) выполнения в трассе 3

(26) может QA в одной сети с скулем, а 1с сервер в разных?

(26)+ *на одном компе и на разных

(26) из твоих замеров ясно что когда через сервер 1С, тогда дольше. значит дело в сервере 1С. Если через сервер без транзакции, быстрее, значит издержки сервера на транзакцию.

(26) технологический журнал смотрел? можно из него что нить по твоему вопросу получить?

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

(31) я так понял что строка Условие их содержит

(32) А я нет. Я там вижу только явное указание периода.

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

(27) Да Сервер 1С на другом сервере чем Скуль
Выполнение запроса по адо из 1С дает результат с задержкой "3"
(29) Очень странная вещь. Только запросы от 1С в транзакции скуль выполняет медленно.
(30) Журнал не смотрел.
(31) РегистрСведений.споСпецУсловия.СрезПоследних( УСЛОВИЕ )
Набор дает 0-3 записей.

(35) запусти QA на том же компе что и сервер1с стоит. и сравни выполнение. ресурсы что необходимы на транспорт данных тоже отражаются в duration..

(36) Запускал эфект тот же
Есть подозрение что глючат процессы 1С сервера (rphost)
База 300 пользователей на 1С сервере 4 процесса каждый из которых достиг предела по памяти около 2гб.
Сегодня перенесли 1С сервер на новый и включили 15 процессов. Пока веду наблюжение.
Попутно есть вопросы как бороться с ростом отжираемой памяти процессом?
И как расширить количество IP потров для создания большего числа процессов.

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