pkarklin
Ну, давайте посмотрим... Только в "оригинальную" статью (есть ссылка в приведенной Вами стаье), а не в FAQ по табличным переменным, да еще по 2000 версии.

во первых надо догововорится: вы будете спорить с тем, что временные таблицы вызывают рекомпиляцию на каждый вызов существует рекомендация MS вместо них юзать табличные переменные везде где только можно относится и к mssql2к5 ? или это относилось лишь к версиям до sql2k5 ?

pkarklin
Т.е. Вы считаете, что если Вы по ходу дела (после того, как был создан план выполнения хп) залили во времянку пару-тройку сотен тысяч записей для обработки, то план, составленный на этапе копиляции (когда таблица пуста - читай отсутствует статистика) будет самым верным? IMHO, все с точностью до наоборот!

во вторых думаю вам нужно сначало осознать, что плана выполнения хп просто физически не существует, потому в остальной текст невьехал ...
мое мнение - тысячи рекомпиляций в минуту одних и тех же процедур - немаштабируемо и допускать такое в продакшене не представляется возможным.
в третих список вещей вызывающих рекомпиляцию:
MSDNRecompilations Due to Certain Temporary Table Operations
Use of temporary tables in a stored procedure may cause the stored procedure to be recompiled every time the procedure is executed.

To avoid this, change the stored procedure so that it meets the following requirements:
• All statements that contain the name of a temporary table refer to a temporary table created in the same stored procedure, and not in a calling or called stored procedure, or in a string executed using the EXECUTE statement or sp_executesql stored procedure.
• All statements that contain the name of a temporary table appear syntactically after the temporary table in the stored procedure or trigger.
• There are no DECLARE CURSOR statements whose SELECT statements reference a temporary table.
• All statements that contain the name of any temporary table precede any DROP TABLE statement that references a temporary table.

DROP TABLE statements are not needed for temporary tables created in a stored procedure. The tables are automatically dropped when the procedure has completed.
• No statements creating a temporary table (such as CREATE TABLE or SELECT... INTO) appear in a control-of-flow statement such as IF... ELSE or WHILE.

pkarklin
И что здесь на Ваш взгляд "криминального"? Значения парамтеров положили в табличную переменную. Предположу, что для дальнейшей SET-ориентированной обработки. Если будет приведен полный текст или тынц на оный, можно будет о чем то рассуждать. А так - слив не засчитан.

ну например эта же процедура в Postgres выглядит так:
полный текст тынца от майкрософт можно взять тут:
http://www.tpc.org/results/FDR/tpce/dell_6850_082407_TPCE_SF.zip

pkarklin
Т.е. вот так вот абстрактно "i/o на tempdb"? В каком контексте? М.б. ВЫ о версионности? Могу Вас разочаровать версионность (успешно используем на OLTP системе) не создает какой-либо заметной нагрузки на tempdb. Почему, наверное стоит прильнуть к первоисточнику, например, Inside Microsoft® SQL Server™ 2005: The Storage Engine By Kalen Delaney Там даже и формула для расчета приведена.

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

Alexsalog
Покажите как использовать ref_cursor в случае если в клиентской программе "пользователю" предоставлено поле для запроса, который будет тупо запущен на выполнение и от которого клиентская программа ждет набора записей как если бы это было "select * from...". На скуле это делалось:
Покажите правда - мне это очень нужно поработе. Хотя в современных условиях уже есть слава богу pipeline функции. Но, как бы это Вы сделали до 9-ой версии?
Мои предшественники плодили многоэтажные вью.
нихера не понял, parameters это что, входной текст sql statement'a типа 'drop database ...' ? не страшно ? как это связано с многоэтажными вью !? типа такого:

http://www.oracle.com/oramag/oracle/01-jan/o11sql.html

2locky

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

lockyВкратце: использование временных таблиц - вообще говоря вызывает
рекомпиляцию (не всегда, вроде как).
Вывод: избегайте использования временных таблиц.
не пойму это сарказм или меня услышали ? :)

2pkarklin

то что вы видите это планы sql queries которые встречаются в хп, никакого плана процедурного расширения t-sql и хп. оптимизатору пофигу от куда взялся запрос - из хп, напрямую с клиента или dblink.
по остальному собствено locky уже все что я хотел сказал

pkarklin В кеше присутствует скомпилированный план именно хп, как бача, а не как отдельные планы запросов, ее составляющих. При повторном вызове этой хп будет ипользоваться скомпилированный план. Если Вы отдельно отправите три запроса, находящихся внутри хп, то получите три отдельных плана:


а можно тынц куда нибудь на описание ? пока я вижу 3 плана, трех запросов.
а то выходит, что одни и теже запросы пришедшие с клиента и хп будут фигурировать (их планы) в кеше дважды ?


2SergSuper
по ВТ мне все понятно, я пытался показать, что "вкусности оракла" легко и непринужденно временными таблицами обойти не получается ...