|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
смотрю чужое приложение, где выполняется UPDATE таблицы с полем LOB. update TABLE set ID = new_ID, lob_col = old_LOB. т.е. разработчики пытаются выполнить изменение LOB'a тем же значением. на вопрос ЗАЧЕМ?! искренне отвечают, что да, это гавнокод получился, но менять не хотят - мол, долго. Объем LOB'a > 1Mb, т.е. хранится в сегменте, не в строке таблицы. эти UPDATE они выполняют постоянно. в результате размер данных не меняется, а размер сегмента растет, как на дрожжах. я правильно понимаю, что Oracle просто добавляет, повторяет данные этого LOB'a в сегменте, не заботясь как-то выкинуть то, что было и как-то уменьшить размер сегмента? Можно ли что-то сделать для автоматического уменьшения размера сегмента, чтобы не заставлять разработчиков менять код? LOG сегмент - SECUREFILE. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.04.2021, 11:57 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
receiver, Почитайте про PCTVERSION/RETENTION. https://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_tables.htm#CIHEBABG ... |
|||
:
Нравится:
Не нравится:
|
|||
07.04.2021, 13:55 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
PuM256, спасибо, но К сожалению, PCTVERSION не имеет значения при SecureFile, а в той таблице LOB именно такой. RETENTION определяет связь с UNDO_RETENTION при определении консистентности запросов, но вряд ли приводит к действиям Oracle по удалению данных и физическому уменьшению сегменат LOB ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2021, 15:55 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
receiver PuM256, спасибо, но К сожалению, PCTVERSION не имеет значения при SecureFile, а в той таблице LOB именно такой. RETENTION определяет связь с UNDO_RETENTION при определении консистентности запросов, но вряд ли приводит к действиям Oracle по удалению данных и физическому уменьшению сегменат LOB Да уж, тебе перед RETENTION нужно было почитать про LOB, как он хранится и как реализовано UNDO для него. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2021, 16:43 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
AlexFF__|, сенкс! Но простое совет как остановить рост сегмента, с учетом того, что данные не меняются, было бы более полезным, чем совет "читать документацию" ) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2021, 11:55 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
receiver Но простое совет как остановить рост сегмента, с учетом того, что данные не меняются, было бы более полезным, чем совет "читать документацию" ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2021, 13:58 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
receiver, Расшифровываю - в отличие от обычных колонок, при изменении лоба, для того чтобы обеспечить согласованное чтение, Оракл сохраняет предыдущие значения в том же самом сегменте. Параметр RETENTION (в отличие от PCTVERSION) означает, что сохранять он будет количество версий, нужное для согласованного чтения данных за время, установленное параметром undo_retention. Соответственно, меньше undo_retention - меньше расход пространства (и выше риск отхватить ora-01555). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2021, 15:04 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
receiverт.е. разработчики пытаются выполнить изменение LOB'a тем же значением. .. эти UPDATE они выполняют постоянно. в результате размер данных не меняется, а размер сегмента растет, как на дрожжах. .. я правильно понимаю, что Oracle просто добавляет, повторяет данные этого LOB'a в сегменте, не заботясь как-то выкинуть то, что было и как-то уменьшить размер сегмента? update lob на себя в этом случае это обновление локатора на то же значение. Одно это не будет приводить к росту lob segment в свежих версиях. Какая используется версия в проблемном случае - не указано. DDL - отсутствует. Изучите Recommended Securefile LOB fixes in 11.2.0.4, 12c, 18c and Later (Doc ID 2605308.1) . Если ничего подходящего по симптомам нет, то соберите тест-кейс, на котором продемонстрируете рост lob segment при обновлении его на себя же. receiverМожно ли что-то сделать для автоматического уменьшения размера сегмента, чтобы не заставлять разработчиков менять код? Будет тест-кейс, где будет рост lob при обновлении локатора на себя, то можно с этим работать. Альтернативно выполнить дефрагментацию, в 21c это автоматом: SecureFiles Defragmentation В догонку, приведите вывод dbms_space.space_usage для проблемного lob segment и реальный размер данных через dbms_lob.getlength ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2021, 16:42 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
выполнил совсем простые шаги Код: plaintext 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.
UNDO_RETENTION 900 - по умолчанию скрипт таблицы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Я правильно считаю, что в любом случае сам Oracle не будет заниматься уменшением объема, занимаемого сегментом, не зависимо от UNDO_RETENTION? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2021, 16:28 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
receiver Я правильно считаю, что в любом случае сам Oracle не будет заниматься уменшением объема, занимаемого сегментом ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2021, 20:41 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
receiver выполнил совсем простые шаги update lobs_tab set clob_col = rpad(clob_col, 1000000, '!'); И где тут "обновление на самоё себя"? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2021, 21:48 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
Правильный Вася, если мы имеем ввиду вот такой оператор update lobs_tab set clob_col = clob_col ; то ничего не меняется, и длина строки getlentgh остается 1000000, а размер сегмента остается 3342336 байт, сколько бы раз update не был выполнен. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2021, 22:08 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
receiver если мы имеем ввиду вот такой оператор update lobs_tab set clob_col = clob_col ; то ничего не меняется, и длина строки getlentgh остается 1000000, а размер сегмента остается 3342336 байт, сколько бы раз update не был выполнен. Естественно Oracle не будет обновлять CLOB и посему писать в CLOB UNDO если понимает что в CLOB ничего не изменилось. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2021, 23:39 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
SY, конечно, но это я ответил на вопрос Правильного Васи ) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2021, 13:46 |
|
сегмент LOB растет, хотя объем данных без изменений
|
|||
---|---|---|---|
#18+
задавал и менят параметр RETENTION до одной секунды. alter table lobs_tab modify lob (clob_col) (retention min 1); предполагал, что после этого Oracle будет использовать место, занятое UNDO-данными Большого объекта. но ничего не изменилось. при UPDATE lobs_tab set clob_col = <DATA> ... размер сегмента растет, растет и растет... ( ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2021, 10:14 |
|
|
start [/forum/topic.php?fid=52&tid=1880294]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
130ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
others: | 251ms |
total: | 489ms |
0 / 0 |