|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
Здравствуйте. В AWR в разделе "Top SQL with Top Events" в топе запрос вида INSERT INTO схема.таблица (список колонок) VALUES(сиквенс.NEXTVAL, остальные значения) RETURNING ID INTO :O0 при этом у запроса Executions = 2560 Event = row cache lock Top Row Source = SEQUENCE т.е. выполнений немного за 15 минут. У сиквенса ORDER_FLAG = N CACHE_SIZE = 0 но нулевой кеш не должен был стать помехой при таком небольшом количестве выполнений, мне кажется (все равно его увеличу). Т.е. с одной стороны AWR говорит, что сиквенс стал узким местом, а с другой стороны в этом сомневаюсь. В разделе "Dictionary Cache Stats" dc_sequences был примерно в 2 раза больше обычного, зато dc_rollback_segments - в десятки раз больше. Подскажите, пожалуйста, направление, в котором разбираться. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 14:01 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
140907в этом сомневаюсьИ что ты ожидаешь в качестве ответа? Для форума априори выводы AWR авторитетнее твоих сомнений. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 14:06 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
Event = row cache lock, потому что если у сиквенса CACHE_SIZE = 0, то при каждом получении nextval происходит "row cache lock" для этого сиквенса? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 14:20 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
140907при каждом получении nextval происходитПри каждом nextval nocache происходит апдейт и коммит. 140907Event = row cache lockПочему оно тебя так волнует? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 14:42 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
140907INSERT INTO схема.таблица (список колонок) VALUES(сиквенс.NEXTVAL, остальные значения) RETURNING ID INTO :O0 ... т.е. выполнений немного за 15 минут. Поправка: немного insert. Про "сиквенс.NEXTVAL" этого однозначно сказать нельзя - вставка может выполняться пакетно и последовательность будет дергаться для каждой строки. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 15:06 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
-2-140907Event = row cache lockПочему оно тебя так волнует? Думал, что выделение nextval может приводить к событию " enq: SQ - contention ", т.е. событие "row cache lock" говорит о чем-то другом. Т.е. если кеш равен нулю, то частый nextval приводит к "row cache lock", а если не равен нулю (но недостаточен), то к "enq: SQ - contention"? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 15:16 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
andrey_anonymousПро "сиквенс.NEXTVAL" этого однозначно сказать нельзя - вставка может выполняться пакетно и последовательность будет дергаться для каждой строки. Не понял. В AWR указывается реальное количество произошедших инсертов, и для каждого инсерта дергается сиквенс, т.е. 2560 инсертов - 2560 дерганий сиквенса? В моем случае это инсерт одной строки за транзакцию (правда, коммит происходит намного позже этого инсерта, но ведь сиквенс будет освобожден сразу после получения nextval, его блокировка не привязана к этому коммиту). Т.е. Оракл считает, что 2560 дерганий nocache-сиквенса за 15 минут (т.е. примерно 3 раза в секунду) - это слишком часто? Просто раньше этот сиквенс в топе проблем не появлялся. Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production PL/SQL Release 12.1.0.2.0 - Production CORE 12.1.0.2.0 Production TNS for IBM/AIX RISC System/6000: Version 12.1.0.2.0 - Production NLSRTL Version 12.1.0.2.0 - Production. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 15:33 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
140907Т.е. если кеш равен нулю, то частый nextval приводит к "row cache lock"Нет оснований для домыслов. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 15:50 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
140907andrey_anonymousПро "сиквенс.NEXTVAL" этого однозначно сказать нельзя - вставка может выполняться пакетно и последовательность будет дергаться для каждой строки. Не понял. В AWR указывается реальное количество произошедших инсертов, и для каждого инсерта дергается сиквенс, т.е. 2560 инсертов - 2560 дерганий сиквенса? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 15:51 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
140907Оракл считает, что 2560 дерганий nocache-сиквенса за 15 минут (т.е. примерно 3 раза в секунду) - это слишком часто? Тут сразу две логических ошибки. 1. "2560 дерганий ... за 15 минут" исходит из предположения, что все эти "дергания" происходили равномерно на интервале в 15 минут, что само по себе не факт - все 2560 вызовов могли столпиться в одной секунде из указанного интервала. 2. Oracle ничего не "считает". Если требуется эксклюзивный доступ к ресурсу, то такой доступ запрашивается. В процессе ожидания доступа фиксируется соответствующее событие ожидания. Дальше для Вашего удобства строится отчет. 2560 вызовов за 15 минут - много это или мало? Зависит от уровня конкуренции, располагаемых ресурсов, требований к системе и оценивается администратором, а не сервером. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 16:07 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
Спасибо за инфо. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2019, 22:32 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
Допустим, я у сиквенса сделаю CACHE_SIZE = 1000. Эта тысяча номеров будет храниться в SGA? Стоит ли беспокоиться о том, что кешированные значения сиквенсов занимают оперативную память БД, или их объем настолько мал, что не приведет к вытеснению чего-то полезного? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 15:34 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
140907Эта тысяча номеров будет храниться в SGA?Зачем тысяча? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 15:44 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
1000 - это как пример, хотя если за 147 минут значение LAST_NUMBER увеличилось на 9 102 200 (т.е. в среднем значение запрашивалось 1031 раз в секунду), то в этом случае тысячи даже будет мало? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 15:59 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
1409071000 - это как примерВопрос был не про выбор размера кеша, а зачем хранить 1000 номеров. Сиквенс это одна строчка в таблице seq$. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 16:09 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
140907Стоит ли беспокоиться о том, что кешированные значения сиквенсов занимают оперативную память БД Все будет хорошо. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 16:23 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
CACHE Specify how many values of the sequence the database preallocates and keeps in memory for faster access. Это из документации Оракла. Я понял это как хранение массива значений в памяти. Наверно, в памяти хранится только текущий LAST_NUMBER и порог, и если LAST_NUMBER > порога, то происходит обращение к сиквенсу за новым порогом (с изменением сиквенса). Это все теория, она интересна, но мне главное, чтобы сотня сиквенсов с CACHE_SIZE = 1000 (утрирую) не стала занимать слишком много памяти. Поверю andrey_anonymous. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 16:52 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
1409071в среднем значение запрашивалось 1031 раз в секундуили 10 раз в секунду. 140907Поверюопровергнуть гипотезу о выделении памяти под каждый номер дело полминуты. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 17:29 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
-2-или 10 раз в секунду. 9102200/147/60=1031. Или тут еще какая-то хитрость? -2-опровергнуть гипотезу о выделении памяти под каждый номер дело полминуты. Если у вас есть запрос, поделитесь, пожалуйста. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 17:56 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
140907-2-опровергнуть гипотезу о выделении памяти под каждый номер дело полминуты.Если у вас есть запрос, поделитесь, пожалуйста.Чудак, ты сам не в состоянии сделать петакэш? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 18:18 |
|
Event = row cache lock, Top Row Source = SEQUENCE, Executions = 2560
|
|||
---|---|---|---|
#18+
andrey_anonymous, -2-, Похоже, в памяти не хранятся. Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 20:05 |
|
|
start [/forum/topic.php?fid=52&msg=39793074&tid=1882651]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
72ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
others: | 17ms |
total: | 189ms |
0 / 0 |