 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Tolik Tentser 2:5020/400 05 Oct 2001 14:19:13 To : Alexey Fisson Subject : Re: ms sql server vs. ibm db2 -------------------------------------------------------------------------------- ax.com> <9pfi9s$gb7$1@gavrilo.mtu.ru> <9phds3$ccf$1@host.talk.ru> ax.com> <9pi7d7$2f6$1@gavrilo.mtu.ru> <9pj6r0$glv$1@news.nsk.su> ax.com> <9pjug3$1j1n$1@gavrilo.mtu.ru> From: "Tolik Tentser" <tt@katren.ru> Hi ! > > Тебя сильно удивит, если ты узнаешь... > > Кстати, все то, что ты там рассказывал про уникальное хранение > > прекомпилированного плана - на других СУБД - тоже давно не новость. RTFM > Я не рассказывал это с точки зрения уникальности DB2. Я привел тот пример на > тему "процедура vs запрос", который знаю, про уникальность там не было. > RTFM, где M - мой message чуть выше. :) MS SQL кэширует схемы процедур Hе схемы - а планы. Что такое план запроса знаешь ? Вот их и кэширует > за него. Может, ты еще скажешь, что он полностью переписывает их логику, как > DB2 запросы? :) Что значит "переписывает логику" ? > Кстати, об уникальности. Дай, мне, пожалуйста ссылку на то место в TFM > другой СУБД, где рассказано о static SQL и о автопреобразовании dinamic SQL > в static. Что есть "автопреобразовании dinamic SQL в static. " ? Построение плана исполнения ? Хранение его в БД ? > DB2 - одна из немногих компилирующих, а не интерпретирующих СУБД. Компилирующих в свой псевдокод ? Как ни странно, то же самое делает не только MSSQL, но даже простейшая IB > Взяв любое ODBC приложение, ты можешь 1 раз запустить его с включенным > static profiling и прогнать все его запросы к БД. После этого все планы всех > запросов статически сохраняются в системных таблицах БД (не в кэше!) и > серверу уже не потребуется эти запросы перепахивать > оптимизатором/планировщиком. MSSQL 6.X делал то же самое буквально для sp, а в семерке от этого отказались и план строится при первом исполнении запроса (или процедуры), а потом - используется повторно, так что ничего нового опять. Кроме более высоких требований к админу, который должен что-то включать, что-то прогонять, а потом не забывать делать все это при обновлениях статистики. -- Bye ... Тенцер А.Л. tolik@katren.ru ICQ 15925834 --- ifmail v.2.15dev5 * Origin: Rinet Corp. News Service, Novosibirsk, Russia (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/5430d1146375.html, оценка из 5, голосов 10
|
|
|