|
Кэш
|
|||
---|---|---|---|
#18+
Не подскажет ли кто - есть ли в SQL сервере какой то механизм кэширования. Например процедура обрабатывается довольно долго а результатом является небольшой рекордсет. Если часто выполняются процедуры с одинаковыми входными параметрами, и при этом изменения проводятся очень редко то хотелось бы чтобы пока этих самых изменений нет, процедура не прогонялась заново, а использовался закешированный результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2000, 12:55 |
|
Кэш
|
|||
---|---|---|---|
#18+
Насколько я понимаю, кэшируются только объекты БД. В любом случае определять надо ли выполнять SP придётся Вам. Пишите в ##table, при внесении изменений удаляйте её (или что-то подобное). ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2000, 16:23 |
|
Кэш
|
|||
---|---|---|---|
#18+
То есть механизма такого нет... Абыдно... В ручную конечно делать можно, но это уже уровень совсем не тот. Да и ##table маловато - все пользователи отключатся и всё пропало... Придется заводить реальные таблицы. Вобщем, встроенный механизм с соответствующими средствами администрирования был бы на мой взгляд весьма ролезен. А в других СУБД есть ли что-нить подобное? Интересно просто. Может кто-нить слышал что-то на эту тему? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2000, 13:32 |
|
Кэш
|
|||
---|---|---|---|
#18+
Доброго времени суток... Вообщето кышируются не данные а план выполнения запроса, тоесть если запрос или процедура довольно часто выполняется, то серверу не прихо дится тратить время на составления плана... вот и все ) С уважением Прайс Николай. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2000, 08:08 |
|
Кэш
|
|||
---|---|---|---|
#18+
Ну что касается процедур то для нее план в любом случае составляется только один раз при ее создании, либо при изменении, или еще при использовании Recompile. Так что тут не о каком кэшировании речь не идет - простая компиляция. А вот насчет запросов - это в смысле при частом использовании абсолютно идентичных запросов или как? Ведь если есть отличие хотя бы в константе предиката Where, то планы могут быть разными. Тут вычитал, что в ORACLE используется механизм материализованных представлений. Это часо не то же кэширование? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2000, 14:21 |
|
Кэш
|
|||
---|---|---|---|
#18+
К ответу Николая. Вообще-то всегда считалось, что SQL Server это "программа кэширования диска, почему-то понимающая язык Transact SQL ...". Я уже не говорю о механизме Read Ahead. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2000, 06:31 |
|
Кэш
|
|||
---|---|---|---|
#18+
2 Dmitry А такой запрос: select GETDATE() Даже не идентичные запросы, а один и тот же - и всегда будет выдавать разный результат. Его тоже надо кэшировать? Вообщем - чего надо, то и кэшируется, нормальный девелопер не должен об этом задумываться. С приветом Сергей ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2000, 07:10 |
|
Кэш
|
|||
---|---|---|---|
#18+
Помнится, когда-то давно я работал с Oracle 7.0 через Delphi 2.0 И там, когда я вызывал Query.Prepare для сложных запросов, а затем много раз вызывал Query.ExecSQL или Query.Open, то разница была очень ощутима. Т.е. когда я просто вызывал Query.ExecSQL или Query.Open без предварительного Query.Prepare, то моя программа работала намного медленнее. Таким образом, я мог явно сообщить Oracle-у, чтобы он синтаксически проанализирвал мой запрос, создал план его выполнения (типа в каком порядке к таблицам обращаться, какие индексы использовать и т.п.) и хранил в кэше эту информацию для многократного повторного использования. Когда я потом перешёл на MS SQL Server, то я был неприятно удивлён, что мой Query.Prepare ему абсолютно по барабану. Видимо какой-то механизм кэширования планов запросов у него есть, но разработчик не может им никак управлять. Там всё автоматически происходит (и не всегда так как нужно). ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2000, 10:37 |
|
Кэш
|
|||
---|---|---|---|
#18+
Ну вообще то всегда рекомендуется делать все опреации именно через хранимые процедуры. Тогда собственно отпадает необходимость и в Query.Prepare, поскольку план уже давно создан и не надо заново тратить время на его создание. Необходимость давать SQL-серверу непосредственно запросы возникает очень редко, например если это не фиксированный запрос, а собирается из кусочков по ходу работы программы. Да и то, вобщем то при желании можно составлять запросы на лету и прямо в хранимой процедуре. А про ORACLE я упомянул про ORACLE8i именно всвязи с тем что не являются ли там некие материализованные представления именно кэшированием данных, а не планов. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2000, 11:02 |
|
Кэш
|
|||
---|---|---|---|
#18+
Я как раз использую для формирования перекркстных запросов хранимые апроцедуры завершающиеся EXEC @sqlStr. Сильно сомневаюсь чтобы оптимизатор анализировал возможное содержимое @sqlStr. Да и после выполнения такой процедуры вряд ли кэшированный план спасет положение - количество возвращаемых столбцов, их имена и типы вообще заранее неизвестны. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2000, 12:27 |
|
|
start [/forum/topic.php?fid=46&msg=32000787&tid=1827603]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
others: | 250ms |
total: | 389ms |
0 / 0 |