Ночи доброй.
Циничная мордочка как бы говорит нам, что все не так просто.

Как хотя бы выполнить такой запрос:

exec sp_executesql N'INSERT INTO #tt2 (_Q_003_F_000_TYPE, _Q_003_F_000_RTRef, _Q_003_F_000_RRRef, _Q_003_F_001) SELECT
T1.Q_002_F_000_TYPE,
T1.Q_002_F_000_RTRef,
T1.Q_002_F_000_RRRef,
T1._Q_000_F_000
FROM #tt1 T1 WITH(NOLOCK)

при условии, что #tt1 создана в сеансе сервера 1С и недоступна мне, простому смертному, запускающему EM под другим сеансом?

Можно как то EM-ом подключиться к существующему сеансу?

И напоследок, как построить годный план запроса для конструкции вида
exec sp_executesql

не переписывая запрос и его параметры.

Я не вижу ваших ников под заголовком. Это меня демотивирует...

Запрос валит 42 гиговый сервер клиента влет, поэтому тренируюсь на кошках (на нашем серваке, пока выходные).

ладно, хрен с ней, с #tt1

Как построить годный план запроса? Чтобы он не был одним куском со 100% времени выполнения.

А то там порядка 50 параметров, я заколебусь их константировать.

Отвечать пойдеееееет.
Отвечать пойдет
Salvador Limones

Salvador Limones , к доске!

приятно поговорить с умным собеседником?

(0) в EI вроде были средства для перехвата профайлера в сеансе сервера если я не путаю

(8) Ты про что?

1. Сначала рекомендую техножурналом отловить строку кода (контекст), где вызывается проблемный запрос MSSQL.
2. Станет понятно какой пользователь его вызывает и какая строка кода.
3. Правильнее всего подключиться к сеансу этого пользователя и попросить его повторить те предполагаемые действия, которые связаны с вызовом найденной строки кода.
4. Уже в большинстве случаев станет понятно как воспроизводить проблему

Если (11) невозможно сделать, то можно попробовать половить запросы SDBL. Если они SELECTовые и самодостаточны, то можно попробовать сконвертировать их в обычные запросы и выполнить в консоли запросов для воспроизведения.

(1)
можно если sql2000
путем превращения локальной временной таблицы в глобальную.
в более новых нельзя.

(11) Все уже давно отловлено.

Мне нужен план запроса.

(14) Так если ты можешь ВОСПРОИЗВЕСТИ проблемный запрос, то значит и можешь увидеть план запроса.

(16) построй план запроса вот для такой мелочи

exec sp_executesql N'SELECT TOP 1000 [_IDRRef]
     ,[_Version]
     ,[_Marked]
     ,[_IsMetadata]
     ,[_Code]
     ,[_Description]
 FROM [empty].[dbo].[_Reference14]
 Where _Marked=@p1',N'@P1 varbinary(1)',0x00

ППЦ, дополз

Или я дятел, или этого не может быть

Потому что этого не можут быть

Запрос вида

ЛЕВОЕ СОЕДИНЕНИЕ СчетФактуры КАК СчетФактуры
       ПО ВзаиморасчетыОстаткиИОбороты.Регистратор = СчетФактуры.Регистратор

преобразуется в

INNER JOIN #tt4 T17 WITH(NOLOCK)
ON 1=1

что бред.

Имеем Cross join и полный пизнес...

Из за чего такое может быть?

Воот, еще подтверждуха, что я не гоню. Когда в запрос

ВЫБРАТЬ
   Регистраторы.Регистратор КАК Регистратор,
   СчетФактураВыданныйДокументыОснования.Ссылка КАК СчетФактура
ПОМЕСТИТЬ СчетФактуры
ИЗ
   Регистраторы КАК Регистраторы
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.СчетФактураВыданный.ДокументыОснования КАК СчетФактураВыданныйДокументыОснования
       ПО Регистраторы.Регистратор = СчетФактураВыданныйДокументыОснования.ДокументОснование

ИНДЕКСИРОВАТЬ ПО
   Регистратор
;

добавляю  ПЕРВЫЕ 1 - ничего в аут не уходит.

(2)
SELECT usecounts, cacheobjtype, objtype, text, query_plan, value as set_options
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle)
cross APPLY sys.dm_exec_plan_attributes(plan_handle) AS epa
where text like '%#tt1%'and attribute='set_options'

Выдает список запросов, в нем ищешь свой запрос, открываешь план запроса в хмл виде, сохраняешь, изменяешь расширение на sqlplan, два раза щелкаешь и он открывается в management studio в нормальном виде.

Перед вами, господа соучастники, поток нетрезвого сознания, как наглядный пример вреда алкоголя (ромикс, приди!)

(23) Хм. А если сначала во временную Ссылка, документОснование и потом ее сjoin-нить?
Меня несколько смущает данное внутреннее...
+ как получаются Регистраторы?

(25) Главное не мешать человеку думать, а там и решение найдется

(24) Спасибо тебе, добрый человек

Так. Проблема в том, что SQL не кэширует этот план запроса. Как быть?

(26) Та же херь.

Вообще я ошибся, вчера уже мозг скорее всего не работал...
Все нормально соединяет
LEFT OUTER JOIN #tt4 T13 WITH(NOLOCK)
ON (T1.Recorder_TYPE = T13._Q_001_F_000_TYPE AND T1.Recorder_RTRef = T13._Q_001_F_000_RTRef AND T1.Recorder_RRRef = T13._Q_001_F_000_RRRef)

ms sql profiler рулит и педалит....

О сколько нам открытий чудных несет метод тыка.

Так... Ничего не понимаю. Добавил еще одну таблицу временную, в нее все кидаю из ОстаткиИОбороты регистра и затем уже выполняю соединение со счет фактурами.

Все окей, только.... сервер 1С также виснет, а запросы в SQL останавливаются на выполнении закидки ОстаткиИОбороты во временную. Все нормально запрос отрабатывает, за 4 секунды, а потом все умирает... сервер 1С сжирает 8 гигов и крутиться возле границы памяти... Когда снимаю клиента в консоли сервера 1С, SQL профайлер дает бредовый выполненный запрос вида

SELECT
T1._Q_001_F_000RRef,
T1._Q_001_F_001RRef,
T1._Q_001_F_002RRef,
T1._Q_001_F_003_TYPE,
T1._Q_001_F_003_RTRef,
T1._Q_001_F_003_RRRef,
T1._Q_001_F_008,
T1._Q_001_F_010,
T2._Document516_IDRRef,
T1._Q_001_F_004,
T1._Q_001_F_006,
T1._Q_001_F_005,
T1._Q_001_F_007,
T1._Q_001_F_009,
T1._Q_001_F_011,
T1._Q_001_F_012,
T1._Q_001_F_013,
T1._Q_001_F_014
FROM #tt6 T1 WITH(NOLOCK)
INNER JOIN _Document516_VT14379 T2 WITH(NOLOCK)
ON 1=1

со временем 230 секунд и в конце

kill 59


Что за херня творицца?

Счаст тестирую конфу, но вряд ли, вряд ли.

_Document516_VT14379 -счаст гляну, чье это и почему он к нему cross join делает.

#tt6 - это нормальная ВТ с ОстаткиИОброты.

Никаких ошибок в конфигурации, и в данных - нет.

(0) будь мужиком, используй exec sp_executesql N'INSERT INTO ##tt2

Счаст буду смотреть различные значения колонки типов
_RecorderTRef

Вдруг че негодное затесалось.

И получилось как у софтпоинтовского МуМу

Какое у тебя значение попало в тип регистратора?

(39) Пока не смотрел