Столкнулся со странным поведением механизма параметризации у SQL Server.
Проблема в том, что SQL Server создает разные планы для казалось бы одинаковых запросов на insert.

Пример такой

CREATE TABLE A (a int, b float) --создаем тестовую табличку
GO

DBCC FREEPROCCACHE -- чистим операционный кэш, чтобы проще искать результат
GO

-- вставляем строки
insert into A (a, b) values (1, 10000.01)
insert into A (a, b) values (1, 990000.019999)
GO

Смотрим, что у нас лежит в кэше
SELECT text, * FROM sys.dm_exec_cached_plans cp CROSS APPLY sys.dm_exec_sql_text (cp.plan_handle)

а там два разных плана
(@1 int,@2 numeric(12,6))INSERT INTO [A]([a],[b]) values(@1,@2)
(@1 int,@2 numeric(7,2))INSERT INTO [A]([a],[b]) values(@1,@2)

Как заставить SQL Server, чтобы он создавал один план в такой ситуации и использовал его повторно?

Версия сервера
Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

Это помогает, к сожалению, только для запросов select
Я проверял это все для insert такая же картина с двумя планами.

Knyazev Alexey


а так?

так лучше

declare @cmd nvarchar(1024) = 'insert into A (a, b) values ( @p1, @p2 )'
exec sp_executesql @cmd, N'@p1 int, @p2 float', @p1 = 1, @p2 = 10000.01
exec sp_executesql @cmd, N'@p1 int, @p2 float', @p1 = 1, @p2 = 990000.019999


(@p1 int, @p2 float)insert into A (a, b) values ( @p1, @p2 )

GlorykalimbaРеально не работает : (
declare @x decimal (16,7)
set @x = 10000.01
INSERT INTO A (a, b) values (1, @x)
set @x = 990000.019999
INSERT INTO A (a, b) values (1, @x)

Такой вариант, вообще не приводит к параметризации

к формированию не параметризованного плана для конкретного батча.

declare @x decimal (16,7) set @x = 10000.01 INSERT INTO A (a, b) values (1, @x) set @x = 990000.019999 INSERT INTO A (a, b) values (1, @x)

Knyazev Alexey


а так?

Отдельное спасибо за такой вариант, но он мне не совсем подходит, из-за низкой производительности такого подхода.

Я накопал такой вариант, как создание структуры плана для связывания запросов через sp_create_plan_guide.
Попробовал создать структуру плана, но в итоге опять создается два плана.

Пример:

EXEC sp_create_plan_guide
@name = N'update_A',
@stmt = N'insert into A (a, b) values ( @p1, @p2 )',
@type = N'SQL',
@module_or_batch = NULL,
@params = N'@p1 int, @p2 float',
@hints = BULL
GO

DBCC FREEPROCCACHE
GO

insert into A (a, b) values (1, 10000.01)
insert into A (a, b) values (1, 990000.019999)
GO

на выходе опять
(@1 int,@2 numeric(12,6))INSERT INTO [A]([a],[b]) values(@1,@2)
(@1 int,@2 numeric(7,2))INSERT INTO [A]([a],[b]) values(@1,@2)



посмотреть и удалить схемы можно так
SELECT * FROM sys.plan_guides
exec sp_control_plan_guide

Вопрос будет создание схемы аналогом вызова sp_executesql с параметрами?

У меня работа с БД при загрузке данных построена таким образом.
Запросы insert(update) склеиваются в один батч от одного до N шт. При низкой нагрузке в БД могут ехать отдельные запросы при высокой запросы объединяются в один пакет. т.е.
into (..) values ()
into (..) values ()
into (..) values ()
into (..) values ()
into (..) values ()
GO

Такой подход позволяет не ждать ответа от сервера после каждого запроса, если запросы выполняются по одному и SQL Server и приложения стоят на разных машинах. А ожидать ответ только после отправки пачки запросов.

Пока это написал я понял, что я не совсем прав, говоря, что этот подход с sp_executesql будет медленнее, чем описанный выше.
Я предполагал, что sp_executesql будет делаться для каждого insert или update по-отдельности, что конечно же не так и можно переделать приложение, подставляя в вызов sp_executesql 20 строк на вставку, но это как-то не красиво и не спортивно.

Хотелось бы выкрутить руки SQL Server, чтобы он таки нашел нужный план плану у себя к кэше и не создавал новый.

Crimeanp.s.

а вы боретесь со скоростью вставки? ну не планы ради планов же? тогда (1) хранимки и (2) оборачивать по ~ 100..1000..10000 вставок в транзакцию. но с транзакцией будет попадалово с ошибками, да.. и будет вам быстро. ну или примеряйте способы передавать не по 1 записи, а пачками сразу на сиквел - тоже будет быстрее

Вопрос быстродействия уже решен до начала этой темы, путем вызова ХП, в которой все строки вставляются одним запросом.

Но в процессе понимания, что происходило при тормозах на SQ Server единственное, что было не понятно это зачем SQL Server постоянно генерит новые планы для казалось бы одинаковых запросов, к тому же эти планы далеко не такие безобидные и потребляют довольно много памяти в моем случае это было около 1,3 Гб при этом часть из этих планов удаляется в процессе вставки 500 тыс строк.

ShakillartiiПри низкой нагрузке в БД могут ехать отдельные запросы при высокой запросы объединяются в один пакет. т.е.
into (..) values ()
into (..) values ()
into (..) values ()
into (..) values ()
into (..) values ()
GO а зачем так много букв, пишите сразу одной командой insert into (..) values (), (), (), ... и будет один план на пакет

Не знал про такой синтаксис, спасибо, но мне не подходит вариант, запрос откатывает все вставленные строки, если хотя бы одна вызывает ошибку например PK_violation

Гость333artiiзапросы объединяются в один пакет. т.е.
into (..) values ()
into (..) values ()
into (..) values ()
into (..) values ()
into (..) values ()
GO
Каким образом вы определили, что ваше узкое место — это компиляция запросов?

Знаете, я не могу достоверно говорить, как я это определил я просто скажу что произошло

совершенно случайно, я при проявлении этих тормозов, решил очистить процедурный кэш, ну так ради спортивного интереса,
DBCC FREEPROCCACHE
после этого все просто полетело, но через некоторое время все опять начало тормозить

порядок тормозов следующий, запросы при тормозах просасывались по 20 шт за 1 сек, после очистки по несколько тыс за сек

Далее начал смотреть, а что лежит в кэше и увидел , что практически весь процедурный кеш забит запросами к одной таблице, 80% от этих запросов имею UseCount 1 или 2. И этот факт вызвал большие вопросы т.к. запросы в целом одинаковые, т.е. insert содержит одинаковый набор полей в одинаковом порядке с одинаковыми отступами, пробелами и регистром буквенных символов отличаются только значениями полей полей типа float. Эти значения в планах приводятся к параметрам разных вариантов типа numeric(12,6), numeric(7,2) и т.д этих полей порядка 15 и получается, что с высокой вероятностью создается новый план.

После этого я начал пытаться заставить SQL server использовать уже существующие планы, пока правда безуспешно, не считая вариант с параметизацией запросов через sp_executesql

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

alexeyvgЗапросы же не одинаковые. Если хоть байт в тексте отличается, то это другой запрос.
Чтобы уменьшить расходы на компиляцию, нужно либо включить специальную опцию, либо не передавать запросы в виде текста.

Ну и вообще есть способы и в сотни раз увеличить скорость, просто вы говорите, что скорость вас не интересует, что вы выясняете конкретный вопрос поведения SQL Server...

Значения в запросах не одинаковые, но это как бы не должно играть ни какой роли, если запрос имеет параметризованный план.
Для этого собственно и нужна параметризация. Например для запросов Select в простом текстовом виде, если план параметризуется, добиться повторного использования параметризованного плана довольно просто, достаточно привести нужную константу к нужному типу и соотв параметр в плане примет указанный тип. С инсертами сложнее нужно использовать sp_exeutesql, возможно sp_create_plan_guide делает так же как и sp_exeutesql, но мне пока не удается его распинать применительно к инсертам.

Может кто-то уже использовал sp_create_plan_guide в таком же контексте как я и знает как создать правильную схему для планов?

alexeyvgartiiНу и в конце поста я хотел бы акцентировать внимание на вашем вопросе, скорее всего компиляция планов не является узким местом т.к. после очистки кэша все летит и запросы компилируются со свистом, но проблема все-равно где-то в процедурном кэше возможно в поиске готовых планов.Это взаимосвязанные вещи. Сама по себе компиляция такого простого запроса не создаёт нагрузки, но мллионы запросов - это миллионы хранящихся в кеше планов, и естественно серверу становится плохо. Поэтому и нужно избавляться от лишних компиляций и лишних планов.

Все правильно я и пытаюсь заставить SQL Server создавать параметризованые планы, в которых будут float-ы вместо различных комбинаций numeric и тем самым добиться повторного использования планов.

alexeyvgartiiЗначения в запросах не одинаковые, но это как бы не должно играть ни какой роли, если запрос имеет параметризованный план.Нут хорошо, дропустим, у вас есть 2 закешированных плана:
(@1 int,@2 numeric(12,6))INSERT INTO [A]([a],[b]) values(@1,@2)
(@1 int,@2 numeric(7,2))INSERT INTO [A]([a],[b]) values(@1,@2)

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

Это при включённой Forced параметризации.

Чем забивается кеш-то?

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

Планы точно параметризуются

вот пример 10 планов и 15 тыс, у 80% из которых useCount 1 или 2 эти планы и забивают весь кеш

(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(3,1),@8 numeric(2,1),@9 int,@10 int,@11 int,@12 numeric(6,1),@13 numeric(1,1),@14 numeric(1,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(3,2),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(1,1),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [Tab]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)
(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(6,1),@8 numeric(2,1),@9 int,@10 int,@11 int,@12 numeric(6,1),@13 numeric(1,1),@14 numeric(1,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(3,1),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(1,1),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [Tab]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)
(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(3,1),@8 numeric(2,1),@9 int,@10 int,@11 int,@12 numeric(6,1),@13 numeric(1,1),@14 numeric(1,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(5,2),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(1,1),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [Tab]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)
(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(6,1),@8 numeric(6,1),@9 int,@10 int,@11 int,@12 numeric(7,1),@13 numeric(1,1),@14 numeric(1,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(4,1),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(17,12),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [PositionHist]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)
(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(3,1),@8 numeric(2,1),@9 int,@10 int,@11 int,@12 numeric(7,1),@13 numeric(1,1),@14 numeric(4,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(4,1),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(1,1),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [Tab]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)
(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(6,1),@8 numeric(6,1),@9 int,@10 int,@11 int,@12 numeric(7,1),@13 numeric(1,1),@14 numeric(1,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(2,1),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(17,12),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [Tab]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)
(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(6,1),@8 numeric(6,1),@9 int,@10 int,@11 int,@12 numeric(7,1),@13 numeric(1,1),@14 numeric(1,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(2,1),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(6,1),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [Tab]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)
(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(6,1),@8 numeric(2,1),@9 int,@10 int,@11 int,@12 numeric(7,1),@13 numeric(1,1),@14 numeric(2,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(4,2),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(1,1),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [Tab]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)
(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(6,1),@8 numeric(6,1),@9 int,@10 int,@11 int,@12 numeric(7,1),@13 numeric(1,1),@14 numeric(1,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(3,1),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(17,12),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [Tab]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)
(@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 numeric(6,1),@8 numeric(6,1),@9 int,@10 int,@11 int,@12 numeric(7,1),@13 numeric(1,1),@14 numeric(1,1),@15 numeric(1,1),@16 numeric(1,1),@17 numeric(1,1),@18 numeric(3,1),@19 numeric(1,1),@20 numeric(1,1),@21 numeric(1,1),@22 numeric(1,1),@23 numeric(1,1),@24 numeric(17,13),@25 numeric(1,1),@26 numeric(1,1))INSERT INTO [Tab]([created_date],[created_time],[modified_date],[modified_time],[user_created],[user_modified],[Account_ID],[Asset_ID],[Date],[id],[OldDate],[Subacc_ID],[VolBlocked],[VolComBrok],[VolCredit],[VolForward],[VolForwardOut],[VolFree],[VolFreeStart],[VolGO],[VolInOut],[VolRepoIn],[VolRepoOut],[Volume],[VolumeAccrued],[VolVar]) values(@1,@2,@3,@4,@5,@6,@7,@8,@9,@10,@11,@12,@13,@14,@15,@16,@17,@18,@19,@20,@21,@22,@23,@24,@25,@26)

alexeyvgartiiпропущено...


Все правильно я и пытаюсь заставить SQL Server создавать параметризованые планы, в которых будут float-ы вместо различных комбинаций numeric и тем самым добиться повторного использования планов.Вы пытаетесь шаманить. Параметризация по текстам в сиквеле - это шаманство, которое делалось как затычка для "вытягивания" старых унаследованных приложений, или просто приложений с плохим дизайном.

Скажем, в команде INSERT Table VALUES ('A', 12345) что является параметрами, а что - частью запроса, которую нужно учитывать при построении плана: 'A', 12345, оба из них, или ни один из них? Это не такой простой вопрос, как кажется, и правильный ответ на него может сильно влиять на производительность.

В некоторых случаях у сиквела это получается, но не понимаю, зачем такие мучения? Не проще просто использовать параметризированные запросы, а не слать сиквелу тексты, надеясь, что он сам из текстов сделает параметризированные запросы?

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

alexeyvgartiiЯ с вами не согласен, что это шаманство. В некоторых случаях грамотная параметризация приводит к сказочной производительности.Ээээ, я не понял. Разве повышение производительности исключает шаманство???
artiiПланы точно параметризуются

вот пример 10 планов и 15 тыс, у 80% из которых useCount 1 или 2 эти планы и забивают весь кешНу вот видите, как они параметризируются?

Я предлагаю параметризировать явно, соответствующими конструкциями клиента. Вот это правильный подходж, а не надежда "параметризации" произвольных текстов.

Оставим разговор про шаманство.

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

Crimeanartii,

вам предлагают с клиента параметризованные запросы формировать
внезапно, да? впрочем, этой возможности 100 лет в обед будет

А, я понял о чем речь, но если честно такой подход ни чем, на мой взгляд, не лучше вызова sp_sqlexecute.
Там для пачки запросов нужно будет готовить соответствующий заголовок, количество запросов в заголовке будет зависеть от размера пачки. И скорее всего при возникновении ошибки в команде откатятся все остальные строки, хотя это нужно проверять.

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

Спасибо всем за обсуждение

Crimeanalexeyvg,

+1, 1 раз готовим запрос и описание параметров. а дальше тока параметры заполняем и говорим "execute" на каждую строку данных
p.s.
да, теперь понятно, почему ODBC закапывают.. а там целый пласт вокруг массовой обработки был..
вплоть до настройки отображения буфера данных на параметры..
но - всем же облом разбираться

Хорошо, если я делаю описание (в моей терминологии заголовок), для одной строки, потом я просто заполняю буфер для этого описания и делаю вызов. Один вызов одна строка в БД.

В нашем приложении такой подход использовался, но он оказался медленнее, чем если завернуть например 20 запросов в один текстовый батч. Особенно, когда много мелких запросов Add(update) и время их выполнения сравнимо в временем отклика от сервера.

Теоретически можно подготовить заголовки, в которых будут параметризация от 1 до N запросов,
Далее, если поступает например 5 запросов, выбирать заголовок, в котором 5 insert-ов, заполнять соотв буфер и делать вставку, если запрос выполняется то вставляется сразу 5 строк. Далее не понятно, что будет с остальными 4-мя строчками, если одна из пяти содержит ошибку откатятся они или останутся в БД. Не хочется с этим связываться, если можно распинать sp_create_plan_guide

ShakillCrimeanда, теперь понятно, почему ODBC закапывают.. а там целый пласт вокруг массовой обработки был..
вплоть до настройки отображения буфера данных на параметры..
но - всем же облом разбиратьсянаоборот же, OLE DB закапывают

+1, как раз Microsoft отказывается от использования OLEDB в своих внутренних разработках в пользу ODBC

kalimbaРаз пошла такая пьянка) У меня такой запрос часто приходит на сервер от стороннего PHP приложения:


Я создаю plan guide:

\
Но приходящие запросы все равно не параметризуются. Что сделал не так?

так а какой план-то получается в итоге?

alexeyvgartiiА, я понял о чем речь, но если честно такой подход ни чем, на мой взгляд, не лучше вызова sp_sqlexecute.
Там для пачки запросов нужно будет готовить соответствующий заголовок, количество запросов в заголовке будет зависеть от размера пачки. И скорее всего при возникновении ошибки в команде откатятся все остальные строки, хотя это нужно проверять.

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

Откуда там какие то "пачки", что такое "заголовок"? Ничего похожего при параметризации не используется.

Параметризация - это: http://msdn.microsoft.com/ru-ru/library/vstudio/yy6y35y8(v=vs.100).aspx

Там внизу и примеры есть. Как видите, никаких пачек и заголовков там не упоминается.

Впрочем, если для вас принципиально не говорить про параметризацию, то больше не буду.

Нет, я не то чтобы против того, чтобы говорить про параметризацию вообще. Я просто говорю, что в моем случае подсказывать SQL Server какие типы у констант должны быть в плане запросе, на клиентской стороне довольно с трудоемкая задача, которая еще может не выстрелить по быстродействию. Поэтому мой посыл был в том, чтобы сосредоточиться на поиске решения на стороне самого SQL Server, например используя sp_create_plan_guide

2 kalimba

А если попробовать так?

DECLARE @stmt nvarchar(max);
DECLARE @params nvarchar(max);
EXEC sp_get_query_template N'SELECT own_id FROM warehouse..catalog_good WHERE model_id = ''27985529'' AND deleted = 0 AND on_sell = 1 AND own_id IS NOT NULL AND own_id != '''''
,@stmt OUTPUT
,@params OUTPUT

EXEC sp_create_plan_guide N'TemplateGuide1'
,@stmt
,N'TEMPLATE'
,NULL
,@params
,N'OPTION (PARAMETERIZATION FORCED)';

EXEC sp_create_plan_guide N'SQLGuide1'
,@stmt
,N'SQL'
,NULL
,@params
,N'OPTION (RECOMPILE)';

Gloryartiiпросто говорю, что в моем случае подсказывать SQL Server какие типы у констант должны быть в плане запросе,
Ну так и подсказывайте правильно

insert into A (a, b) values (1, 1.0000010000E3)
insert into A (a, b) values (1, 9.90000019999E4)

Вот, это мне и нужно было, а не городить огороды в sp_executesql и прочей пертушкой.
Спасибо

Crimeanartiiподсказывать SQL Server какие типы у констант должны быть в плане запросе, на клиентской стороне довольно с трудоемкая задача, которая еще может не выстрелить по быстродействию

дважды неверно. во-первых восприятие констант самим SQL Server описано. а то, что вы не хотите этим пользоваться на server-side просто добавляет вам проблем, внезапно:
...


Все проще я даже не рассматривал вариант (что там говорить не знал), который описал Glory

Crimeanтак все равно придется же, скорее всего :) хотя.. если скорости будет достаточно без этого то и хватит, да

Всему свое время хочется с простыми текстовыми запросами разобраться.