|
Как работает result cache
|
|||
---|---|---|---|
#18+
У меня есть некоторые пробелы в понимании работы result cache. В доке и гугле этого не нашел. Да и непонятно, что именно нужно искать. В общем, если кратко. Есть Oracle 12.1, и древнющая легаси БД, к которой подключается 100500 разных приложений. Все это работает 24 х 7. Есть таблица параметров. В ней примерно 400 строк. Меняются они довольно редко, большая часть не менялась ни разу за последние 15 лет. В AWR отчете я вижу, что какое-то приложение делает примерно миллион запросов к этой таблице в сутки. Конкретно этот запрос создает примерно 3% всей нагрузки на процессор. У меня была идея обойтись малой кровью и сделать Код: plsql 1.
Ожидаемый результат: запрос должен пропасть из SQL ordered by CPU Time, и, по идее, в V$RESULT_CACHE_OBJECTS должна появиться строка для каждого закэшированного значения. Фактический результат: кэш заработал, но не сразу (а почему-то несколько дней спустя). После каждого обновления таблицы result cache инвалидируется (что ожидаемо), но начинает работать снова через несколько часов. дополнительные подробности как проверялСначала я потренировался на DEV бд, как это работает. Сделал скрипт вроде такого: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
В таком виде - работает хорошо, все ок. После выполнения alter table parameter_table result_cache (mode force) этот кусок кода работает в десятки раз быстрее, проц грузит меньше. Проверял V$RESULT_CACHE_OBJECTS - там отображается мой запрос. Но на самом деле, приложение обращается к таблице не напрямую, а через функцию. То есть там что-то вроде Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Я пробовал на DEV среде вызывать функцию: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
С функцией тоже все работает. После того, как выполнили ALTER TABLE на проде, я начал мониторить, есть ли какой-то результат или нет. Сначала проверил через час после выполнения скрипта. Эффекта никакого. Снижения нагрузки на проц нет, в V$RESULT_CACHE_OBJECTS пусто. Проверил через сутки. То же самое. Потом на пару недель забросил это дело, занимался другими вещами. А когда вернулся к этой таблице опять, оказалось, что кэширование результата работает, но как-то неравномерно. Время от времени кто-то обновляет таблицу параметров, из-за чего кэш инвалидируется на какое-то время, а потом опять начинает работать. Ну то есть таблица была обновлена утром в районе 7 часов, запись в V$RESULT_CACHE_OBJECTS появилась в 12:40, запросы выполняются все время без перерыва. Почему так? Чего ораклу не хватает? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2022, 18:48 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Никанор Кузьмич Есть таблица параметров. В ней примерно 400 строк. И Вы пытаетесь ускорить точечный запрос к такой таблице? Он же и так должен "летать" Код: plsql 1. 2. 3. 4.
CREATE INDEX parameter_table_i1 on parameter_table(parameter_name,parameter_value) IMHO Никанор Кузьмич Но на самом деле, приложение обращается к таблице не напрямую, а через функцию. То есть там что-то вроде А почему не закешировать результат ф-ции? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2022, 19:10 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Никанор Кузьмич Сначала я потренировался на DEV бд, как это работает. Сделал скрипт вроде такого: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
В таком виде - работает хорошо, все ок. После выполнения alter table parameter_table result_cache (mode force) этот кусок кода работает в десятки раз быстрее, проц грузит меньше. Проверял V$RESULT_CACHE_OBJECTS - там отображается мой запрос. Вот прямо в таком виде и запускали? И оно сработало 100 000 раз? Но почему у вас нет обработчика исключительной ситуации NO_DATA_FOUND? Приведите ТОЧНЫЙ код программы, который вы выполняли, а не ваши "вспышки памяти" об этом коде. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2022, 19:37 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Что показывает запрос: Код: plsql 1.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2022, 19:45 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev А почему не закешировать результат ф-ции? и все это накладывается на бардак в процессах разработки и деплоя, а также на отсутствие трети команды разработки. Потому что верхние рукамиводители сказали, что оракл - это дорого, поэтому мы с него будем уходить. 4 из 11 девелоперов на следующий день встали и ушли. А мне теперь разгребать. Вариантов решения проблемы много, включая наилучший - найти и переписать нужные куски приложения так, чтобы спамить перестали. Просто я упорядочил возможные решения по уровню геморройности и иду от простого к сложному. Leonid Kudryavtsev И Вы пытаетесь ускорить точечный запрос к такой таблице? Он же и так должен "летать" ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2022, 19:51 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Никанор Кузьмич в процессах разработки и деплоя, а также на отсутствие трети команды разработки. Потому что верхние рукамиводители сказали, что оракл - это дорого, поэтому мы с него будем уходить. 4 из 11 девелоперов на следующий день встали и ушли. А мне теперь разгребать. Зато вам теперь будут платить зарплату минимум за двоих! Разве нет? Начальственные иномарки ваша контора теперь же тоже заменяет на изделия отечественного автопрома!? Разве нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2022, 20:00 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Никанор Кузьмич См. ниже скриншот - два отчета за сутки, когда работало и когда нет. 9,5 мс на запрос до против 0,4 на запрос после. Зачем вы показываете разные отчеты? Покажите одинаковые отчеты. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2022, 20:05 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
SQL*Plus Но почему у вас нет обработчика исключительной ситуации NO_DATA_FOUND? SQL*Plus Приведите ТОЧНЫЙ код программы, который вы выполняли, а не ваши "вспышки памяти" об этом коде. Код: plsql 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. 27. 28. 29. 30.
... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2022, 20:11 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
SQL*Plus Зато вам теперь будут платить зарплату минимум за двоих! Разве нет? SQL*Plus Начальственные иномарки ваша контора теперь же тоже заменяет на изделия отечественного автопрома!? Разве нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2022, 20:15 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Никанор Кузьмич Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
1. Лично я бы, предложил отложить result cache в сторону и начать с начала. С реального запроса и реального плана его выполнения. Построить индекс включающий все необходимые поля, что бы данные брались только из индекса ( vers_company, vepa_par_name, vapa_usr_name, vepa_vers_key, vepa_par_value ) совсем желательно, построить такой индекс, что бы и сортировка из плана исчезла 2. Если я правильно понимаю логику, то result cache'у придется заполняться для каждого пользователя отдельно . Т.е. практический эффект будет только когда все пользователи войдут в систему, т.е. только при их 2-ом и последующих входах. Объем получившегося кэша мне вообще представить сложно. Если система настолько высоконагружена, то можно предположить, что и разных пользователей там много. Т.е. кол-во записей в кэше будет намного больше исходной таблицы (примерно 400 строк). Смысл такой "оптимизации" мне не совсем очевиден. IMHO могу быть не прав ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 11:26 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Никанор Кузьмич Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
1. Лично я бы, предложил отложить result cache в сторону и начать с начала. С реального запроса и реального плана его выполнения. Построить индекс включающий все необходимые поля, что бы данные брались только из индекса ( vers_company, vepa_par_name, vapa_usr_name, vepa_vers_key, vepa_par_value ) совсем желательно, построить такой индекс, что бы и сортировка из плана исчезла 2. Если я правильно понимаю логику, то result cache'у придется заполняться для каждого пользователя отдельно . Т.е. практический эффект будет только когда все пользователи войдут в систему, т.е. только при их 2-ом и последующих входах. Объем получившегося кэша мне вообще представить сложно. Если система настолько высоконагружена, то можно предположить, что и разных пользователей там много. Т.е. кол-во записей в кэше будет намного больше исходной таблицы (примерно 400 строк). Смысл такой "оптимизации" мне не совсем очевиден. IMHO могу быть не прав мне казалось кэш общий.. но вообще странно с нагрузкой на проц бороться кешированием. Согласен что надо смотреть на план. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 11:41 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Melkomyagkii_newbi мне казалось кэш общий.. не очень понимаю, смысл слова "общий". вообще про кэш в Oracle знаю мало (но на моих ф-циях - все нормально работает) но запрос-то отбирается данные в зависимости от user_name, т.е. если поменялся user_name, запрос все равно перевыполнить придется. Т.е. нам надо count(user_name) * count(paramenter_name) записей в кэше. При большом кол-ве различных user_name, это может оказаться значительно больше исходных 400 строк. IMHO могу ошибаться ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 11:54 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
SQL*Plus Что показывает запрос: Код: plsql 1.
? Код: plsql 1. 2. 3. 4. 5. 6.
Leonid Kudryavtsev Если я правильно понимаю логику, то result cache'у придется заполняться для каждого пользователя отдельно . Т.е. практический эффект будет только когда все пользователи войдут в систему, т.е. только при их 2-ом и последующих входах. Leonid Kudryavtsev Объем получившегося кэша мне вообще представить сложно. Если система настолько высоконагружена, то можно предположить, что и разных пользователей там много. Т.е. кол-во записей в кэше будет намного больше исходной таблицы (примерно 400 строк). Смысл такой "оптимизации" мне не совсем очевиден. Но, вообще говоря, мой вопрос был скорее теоретический о тонкостях работы кэша, а ситуация приведена только в качестве примера. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 12:01 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Melkomyagkii_newbi мне казалось кэш общий.. не очень понимаю, смысл слова "общий". вообще про кэш в Oracle знаю мало (но на моих ф-циях - все нормально работает) но запрос-то отбирается данные в зависимости от user_name, т.е. если поменялся user_name, запрос все равно перевыполнить придется. Т.е. нам надо count(user_name) * count(paramenter_name) записей в кэше. При большом кол-ве различных user_name, это может оказаться значительно больше исходных 400 строк. IMHO могу ошибаться да, не обратил внимания на запрос ТС, думал вы описали особенность самого result cache. Никанор Кузьмич, возможно у запросов есть несколько чаилд курсоров и они долго переключаются между вариантом с кэшем и без? Ну и мне до сих пор не очень понятно как result cache помогает cpu экономить для простой выборки(без агрегатов и прочих вычислений) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 12:40 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Никанор Кузьмич SQL*Plus Что показывает запрос: Код: plsql 1.
? Код: plsql 1. 2. 3. 4. 5. 6.
Максимальный размер Result Cache = 80 МБ. На один результат не более 5%. 80 МБ * 5% = 4 МБ. Не так уж много, но для вашей таблички должно было хватить. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 13:22 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Никанор Кузьмич Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
1. Лично я бы, предложил отложить result cache в сторону и начать с начала . С реального запроса и реального плана его выполнения. Построить индекс включающий все необходимые поля, что бы данные брались только из индекса ( vers_company, vepa_par_name, vapa_usr_name, vepa_vers_key, vepa_par_value ) совсем желательно, построить такой индекс, что бы и сортировка из плана исчезла Leonid Kudryavtsev 2. Если я правильно понимаю логику, то result cache'у придется заполняться для каждого пользователя отдельно . Т.е. практический эффект будет только когда все пользователи войдут в систему, т.е. только при их 2-ом и последующих входах. Объем получившегося кэша мне вообще представить сложно. Если система настолько высоконагружена, то можно предположить, что и разных пользователей там много. Т.е. кол-во записей в кэше будет намного больше исходной таблицы (примерно 400 строк). Смысл такой "оптимизации" мне не совсем очевиден. IMHO могу быть не прав Нет, Result Cache один на все сессии. Вы же знаете, что разные сессии используют одни и те же курсоры для одинаковых команд. То же самое и с Result Cache: используется для одинаковых команд с одинаковыми значениями Bind Variables. На каждое сочетание значений Bind Variables имеется один результат в этом кэше. Причем, если для данного сочетания ничего не возвращается, то для него все равно хранится информация "ничего не выбрано". Бывает, что такими "ничего не выбрано" заполняется почти все пространство кэша. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 13:36 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Melkomyagkii_newbi Ну и мне до сих пор не очень понятно как result cache помогает cpu экономить для простой выборки (без агрегатов и прочих вычислений) Таблицу умножения с помощью Result Cache оптимизировать не удаётся. Код: plsql 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
Без Result Cache 5,95 секунды, а с Result Cache 7.53 секунды. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 13:56 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Для более сложных вычисляемых выражений ускорение есть. LN( SQRT(m * n) ) Код: plsql 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50.
с кэшем - 7.72 с ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 14:04 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
SQL*Plus Для более сложных вычисляемых выражений ускорение есть. Логично, я про то и говорю - странно на обычном запросе экономить cpu с помощью кеширования. Выбрать из shared пула будет менее cpu intensive чем с buffer cache? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 14:09 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Никанор Кузьмич, Что возвращает такой запрос Код: plsql 1.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 16:47 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
SQL*Plus, Возвращает ENABLED. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 17:01 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Никанор Кузьмич То есть на DEV среде данные начинают кэшироваться сразу, а на проде - через какой-то довольно длительный интервал. Почему так? Чего ораклу не хватает? Сравните версии Oracle Database. Код: plsql 1.
Они одинаковые? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 18:16 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Обе одинаковые - 12.1.0.2. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 18:48 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
Никанор Кузьмич, Сколько тебе написали советов, но, к сожалению, именно по теме alter table ... result_cache (mode force) ничего. Это не самая стабильно работающая вещь в oracle и если хочешь досконально разобраться иди на metalink и/или создавай запросы к поддержке. Самое лучшее - ручками задать result_cache для запросов или получать данные вызовом функций с result_cache. Если такое возможно, естественно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2022, 22:26 |
|
Как работает result cache
|
|||
---|---|---|---|
#18+
AlexFF__| Сколько тебе написали советов, но, к сожалению, именно по теме alter table ... result_cache (mode force) ничего. AlexFF__| Это не самая стабильно работающая вещь в oracle Да? Не могу сказать, что много пользовался этой фичей, но вроде до этого она не выглядела нестабильной. В общем, всем спасибо за участие и поддержку :) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.02.2022, 01:43 |
|
|
start [/forum/topic.php?fid=52&msg=40134081&tid=1879487]: |
0ms |
get settings: |
17ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
38ms |
get topic data: |
3ms |
get forum data: |
1ms |
get page messages: |
421ms |
get tp. blocked users: |
0ms |
others: | 307ms |
total: | 795ms |
0 / 0 |