так объясните как вы переписав запрос используя временные таблицы получите согласованые данные ?
А почему они должны быть несогласованными если их никто не изменяет ?

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

Да даже если нужно согласование то почему вы считает что именно использование временных таблиц может его нарушить ?

да и расчет отчетов - вроде бы тоже штатный режим работы, не так ли?
И что теперь решать вопрос производительности работы отчета путем изменения приоритета запроса ? Не анализом плана выполнения ? Не анализом индексов, схемы данных ? Не анализом узких мест обрудования ?

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

Если речь идет про отчеты т.е. про чтение данных то временные таблицы никаким образом не смогут нарушить согласованность данных. И совместные блокировки на чтения друг другу не мешают.

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

А насчет того что автор чего-то не понял - так это уже ваши предположения.

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

ЗЫ
А оптимизатора способного составить оптимальный план запроса текст которого на 10 листов просто не возможно создать. Имхо. Либо этот оптимизатор будет искать этот план дольше чем собственно времени выполнения запроса

Если можно, приведите Ваши рекомендации для запроса, который я привел выше
Я что-то не увидел нигде в этом топике текста запроса.

За анализом узких мест обычно должно следовать их устранение. А это - трата денег, иногда - значительная. Замена дисковой подсистемы на более навороченную может повлечь за собой замену всего сервера.
Анализ и создание индексов тоже требуют денег ? Пересмотр схемы данных тоже?
А оптимизация дисковой системы не обязательно должна сводится к покупке "навороченного" контроллера. Начинать можно с вынесения базы tempdb на отдельный диск(даже с RAID0). Или с отказа от RAID5 для OLTP системы например.

может я просто чего то не догоняю ...запрос
Если этот запрос содержится где-то на 10-ом уровне вложенности всего запроса, то имеет смысл переписать
create table #tmp(.... ) --
insert #tmp
select * into
from(
select .. table1
union
select .. table2
) AS a

select .... from ....#tmp

Особенно если в плане выполнения будут присутствовать операции Table/Index Spool. Для Derived table создание промежуточной таблицы также может оказаться выгодным. Особенно если Derived table вычисляет какие-то агрегаты, что позволит нам для промежуточной таблицы создать ПК или уникальный индекс

А для блокировок как я уже сказл существуют транзакции и уровни изоляции.

если так переписать то смысла маловато.
Если посмотреть на план всего запроса то операции Table/Index Spool можно смело заменять на занесение данных в промежуточные таблицы. Поскольку эти операции и есть создание этих временных таблиц. Это раз.

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

Создавая на промежуточных таблицах какие-то даже элементарные индексы вроде ПК (к примеру для той же derived table) мы позволяем оптимизатору возможность использовать эти индексы. Это три.

Понятно что речь не идет о занесении в промежуточные таблицы конечных результатов как вы показали для "select .. table1 union select .. table2". А именно вот для этих самых "select * from table(1/2) это тоже тяжелые вложеные запросы""

непонимаю ... или вы на dirty read намекаете ?
Это вы все время намекает на какую-то несогласованность данных.

Дык, Glory, вы то (и я тоже) писали о анализе узких мест оборудования!!!
Я поставил анализ оборудования на 3ее место. После плана выполнеия, индексов и схемы данных. Потому что понятно что начинать нужно с более дешевых способов оптимизации.

запрос идет не 30 минут, а 25.
ну и что это меняет ? принципиально ?
1. Ну для начала 5 минут вашем случае не 5% а 16%.

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


надеюсь вы не станете уверять что любой запрос можно оттюнить до 3х минут
Любой нельзя. А мы уже рассуждаеи об оптимизации любого запроса или все таки еще придерживаемся посылки об оптимизации запросов на 10 страниц ???
Никакой тюнинг запроса не увеличит пропускную способность дисковой системы или объем оперативной памяти.


К тому же я не упускаю из виду сопровождение чужой системы, в которой мы не имеем права/возможности что-либо менять. мы только можем изменять настройки сервера. И в некоторых случаях настройки приоритета были бы очень кстати.
Т.е. ищзменение приоритета запроса в ситеме типа "черный ящик" - это не есть "право/возможность что-либо менять" в ней ????

Именно по этому я попросил соптимизировать мой запрос-пример.
Да где он ваш пример то этот ?

Кстати, почему ни у кого не вызывает вопросов option(maxdop N) или with (index=...)?или SET DEADLOCK_PRIORITY? это ведь тоже способы оптимизации. Причем под оптимизацией давайте понимать оптмизации работы системы в целом, а не отдельных ее частей. никого не будет интересовать, насколько быстро считаются отчеты, если в процессе расчета тормозит остальная работа.
Давайте рассматривать опцию вида set priority low|high как полезную фичу, которая помогает в некоторых жизненных ситуациях.
Согласен.