Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: параметризация запросов insert  [new]
artii
Member

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


Все правильно я и пытаюсь заставить SQL Server создавать параметризованые планы, в которых будут float-ы вместо различных комбинаций numeric и тем самым добиться повторного использования планов.
15 окт 13, 08:40    [14970694]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31440
artii
Значения в запросах не одинаковые, но это как бы не должно играть ни какой роли, если запрос имеет параметризованный план.
Нут хорошо, дропустим, у вас есть 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 параметризации.

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

Значит, реально параметризации не происходит (может, не происходит для инсёртов), и на каждую новую отличающуюся строку запроса генерится новый план и сохраняется в кеше, так что всё нормально, как и должно быть.
15 окт 13, 08:49    [14970703]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31440
artii
alexeyvg
пропущено...
Это взаимосвязанные вещи. Сама по себе компиляция такого простого запроса не создаёт нагрузки, но мллионы запросов - это миллионы хранящихся в кеше планов, и естественно серверу становится плохо. Поэтому и нужно избавляться от лишних компиляций и лишних планов.


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

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

В некоторых случаях у сиквела это получается, но не понимаю, зачем такие мучения? Не проще просто использовать параметризированные запросы, а не слать сиквелу тексты, надеясь, что он сам из текстов сделает параметризированные запросы?
15 окт 13, 08:56    [14970714]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

Откуда:
Сообщений: 104
alexeyvg
artii
Значения в запросах не одинаковые, но это как бы не должно играть ни какой роли, если запрос имеет параметризованный план.
Нут хорошо, дропустим, у вас есть 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)
15 окт 13, 09:02    [14970723]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

Откуда:
Сообщений: 104
alexeyvg
artii
пропущено...


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

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

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


Я с вами не согласен, что это шаманство. В некоторых случаях грамотная параметризация приводит к сказочной производительности.
В моем случае я хочу добиться снижения издержек при работе с операционым кешем, которые влияют на производительность в худшую сторону.
15 окт 13, 09:06    [14970731]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
alexeyvg
Member

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

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

Я предлагаю параметризировать явно, соответствующими конструкциями клиента. Вот это правильный подходж, а не надежда "параметризации" произвольных текстов.
15 окт 13, 09:22    [14970770]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

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

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

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


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

Как вы предлагаете параметризировать запрос, использовать конструкцию sp_executesql?
Она мне не подходит т.к. есть ситуации, когда я отправляю не под транзакцией пачку запросов за раз и ожидаю, что в случае возникновения ошибки в одном из запросов остальные вставятся и не приведет к откату остальных запросов.
15 окт 13, 09:40    [14970838]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
Crimean
Member

Откуда:
Сообщений: 13148
artii,

вам предлагают с клиента параметризованные запросы формировать
внезапно, да? впрочем, этой возможности 100 лет в обед будет
15 окт 13, 09:41    [14970844]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
alexeyvg
Member

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

Ну и вообще да, можно (и нужно!) слать с клиента не текст, а параметризованные запросы.

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

Ну и есть ещё масса вариантов. Например, сделать ХП, в которую передавать данные как табличный параметр. Что бы не было ошибок, делать проверки в ХП.
Или заливать в временные таблицы балк-ом, потом процедурой переносить в постоянные.
15 окт 13, 09:59    [14970955]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

Откуда:
Сообщений: 104
Crimean
artii,

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


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

Хорошо, я понял про параметризацию запросов на стороне клиента и предлагаю эту тему больше не поднимать.
Хочется все-таки научиться управлять параметризацией на стороне сервера. Если у кого-то есть такой опыт, пожалуйста, напишите,
особенно интересует использование sp_create_plan_guide. Если нет то пусть тема тонет
15 окт 13, 10:05    [14970998]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

Откуда:
Сообщений: 104
Спасибо всем за обсуждение
15 окт 13, 10:07    [14971019]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
kalimba
Member

Откуда:
Сообщений: 297
Раз пошла такая пьянка) У меня такой запрос часто приходит на сервер от стороннего PHP приложения:
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 != ''

Я создаю plan guide:
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)';
\
Но приходящие запросы все равно не параметризуются. Что сделал не так?
15 окт 13, 10:19    [14971077]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
alexeyvg
Member

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

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

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

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

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

Впрочем, если для вас принципиально не говорить про параметризацию, то больше не буду.
15 окт 13, 10:50    [14971223]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31440
kalimba
Я создаю plan guide:
А резуольтат какой, что в @stmt и @params?

Параметр PARAMETERIZATION у базы какое значение имеет?

Ну и вообще, там же куча исключений...
http://msdn.microsoft.com/ru-ru/library/ms175037(v=sql.105).aspx
15 окт 13, 10:59    [14971278]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
Crimean
Member

Откуда:
Сообщений: 13148
alexeyvg,

+1, 1 раз готовим запрос и описание параметров. а дальше тока параметры заполняем и говорим "execute" на каждую строку данных
p.s.
да, теперь понятно, почему ODBC закапывают.. а там целый пласт вокруг массовой обработки был..
вплоть до настройки отображения буфера данных на параметры..
но - всем же облом разбираться
15 окт 13, 11:07    [14971346]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
kalimba
Member

Откуда:
Сообщений: 297
alexeyvg,

select own_id from warehouse . . catalog_good where model_id = @0 and deleted = @1 and on_sell = @2 and own_id is not null and own_id ! = @3
@0 varchar(8000),@1 int,@2 int,@3 varchar(8000)

База в Simple режиме, про ограничения знаю, но не нашел какое может подходить..
15 окт 13, 11:08    [14971350]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
Shakill
Member

Откуда: мск
Сообщений: 1880
Crimean
да, теперь понятно, почему ODBC закапывают.. а там целый пласт вокруг массовой обработки был..
вплоть до настройки отображения буфера данных на параметры..
но - всем же облом разбираться
наоборот же, OLE DB закапывают
15 окт 13, 11:13    [14971385]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

Откуда:
Сообщений: 104
Crimean
alexeyvg,

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


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

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

Теоретически можно подготовить заголовки, в которых будут параметризация от 1 до N запросов,
Далее, если поступает например 5 запросов, выбирать заголовок, в котором 5 insert-ов, заполнять соотв буфер и делать вставку, если запрос выполняется то вставляется сразу 5 строк. Далее не понятно, что будет с остальными 4-мя строчками, если одна из пяти содержит ошибку откатятся они или останутся в БД. Не хочется с этим связываться, если можно распинать sp_create_plan_guide
15 окт 13, 11:24    [14971447]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

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


+1, как раз Microsoft отказывается от использования OLEDB в своих внутренних разработках в пользу ODBC
15 окт 13, 11:26    [14971465]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

Откуда:
Сообщений: 104
kalimba
Раз пошла такая пьянка) У меня такой запрос часто приходит на сервер от стороннего PHP приложения:
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 != ''

Я создаю plan guide:
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)';
\
Но приходящие запросы все равно не параметризуются. Что сделал не так?


так а какой план-то получается в итоге?
15 окт 13, 11:27    [14971473]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
kalimba
Member

Откуда:
Сообщений: 297
artii,

Всё так же как будто я и не добавлял, т.е. в кэш запросов добавляются новые записи, а не увеличивается usecount у какого-то плана. Да и в свойства оператора SELECT не вижу что plan guide используется (должно быть свойство под Physical Operation, если память не изменяет). Скуль 2012 SP1.
15 окт 13, 11:34    [14971534]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

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

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

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

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

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

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


Нет, я не то чтобы против того, чтобы говорить про параметризацию вообще. Я просто говорю, что в моем случае подсказывать SQL Server какие типы у констант должны быть в плане запросе, на клиентской стороне довольно с трудоемкая задача, которая еще может не выстрелить по быстродействию. Поэтому мой посыл был в том, чтобы сосредоточиться на поиске решения на стороне самого SQL Server, например используя sp_create_plan_guide
15 окт 13, 11:47    [14971659]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
Glory
Member

Откуда:
Сообщений: 104760
artii
просто говорю, что в моем случае подсказывать SQL Server какие типы у констант должны быть в плане запросе,

Ну так и подсказывайте правильно

insert into A (a, b) values (1, 1.0000010000E3)
insert into A (a, b) values (1, 9.90000019999E4)
15 окт 13, 11:51    [14971711]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
artii
Member

Откуда:
Сообщений: 104
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)';
15 окт 13, 11:54    [14971733]     Ответить | Цитировать Сообщить модератору
 Re: параметризация запросов insert  [new]
Crimean
Member

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


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

select SQL_VARIANT_PROPERTY( 1, 'BaseType' )
select SQL_VARIANT_PROPERTY( 1., 'BaseType' )
select SQL_VARIANT_PROPERTY( 1E0, 'BaseType' )
select SQL_VARIANT_PROPERTY( $1, 'BaseType' )


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

p.s.

а уж про хитрые типы данных типа datetime так и вообще страшно говорить ибо его невозможно корректно передать никак, кроме как через параметры. ну не предусмотрели разработчики сервера констант типа "дата-время". строкой приходится писать со всеми втекающими и вытекающими
15 окт 13, 11:57    [14971763]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить