|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
Есть таблица с данными для отчета. В нее каждый день пишут порядка 500 пользователей по ~1000 записей/ Перед этим они удаляют свои предыдущие записи. Потом система генерации отчетов предоставляет данные в красивом виде. В результате в таблице все время примерно одинаковое количество записей, но из-за массового удаления во первых растет физический размер таблицы, во вторых деградируют индексы. Данные в таблице никакого значения не имеют, перед каждой отправкой в систему генерации отчетности они обновляются. Есть какие нибудь хорошие идеи как обслуживать данную таблицу? Сейчас ее регулярно ночью пересоздают. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 12:12 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
GorOleg но из-за массового удаления во первых растет физический размер таблицы Не удалять вообще. "помечать" удаленными, и раз в месяц(?) чистить/пересоздать. полляма записей в день не должны убить производительность на нормальном сервере). хотя если записи очень большие по размеру.. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 12:16 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
GorOleg Есть таблица с данными для отчета. В нее каждый день пишут порядка 500 пользователей по ~1000 записей/ Перед этим они удаляют свои предыдущие записи. Про временные таблицы слышали ? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 12:34 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
GorOleg, я б таблицу не удалял (ивалядятся хранимки), а очищал (truncate) + (возможно) пересоздание/alter индексов ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 12:54 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
GorOleg, Партиции на каждый день с локальными индексами. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 13:11 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
Надфиль GorOleg но из-за массового удаления во первых растет физический размер таблицы ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 13:28 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
Stax, Это если и запись в таблицу и считывание системой отчетности в одной транзакции. Это я пока на 100% не уверен. Буду экспериментировать ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 13:41 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
GorOleg, Вы меня не так поняли, регулярно ночью , токо вместо create - truncate автор Сейчас ее регулярно ночью ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 14:51 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
честно говоря, не понимаю проблему GorOleg но из-за массового удаления во первых растет физический размер таблицы ??? Если со вставками никто не химичил (не хинтовал), то с чего "растет физический размер таблицы" "из-за массового удаления" ? GorOleg во вторых деградируют индексы. Что это значит? -2-О деградации можно говорить с точки зрения роста индекса для IFS Если IFS = Index Full Scan То согласитесь, что Full Scan это не тот метод доступа, ради которого создают индексы. Может быть, вместо борьбы с деградацией, просто нормальные (подходящие для запросов) индексы создать? IMHO Глядя в хрустальный шар, складывается ощущение, что: 1. Или пытаются боротся с чем-то при отсутствие проблемы т.к. мне сложно представить, что обычной вставке и удалению на Oracle можно помочь ночным пересозданием 2. Или, проблема сама создана тем, что кто-то ранее уже успешно боролся с несуществующей проблемой. хинтовал insert'ы думая, что так будет правильнее и быстрее ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 15:54 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev, Визуально - проблема - запрос к этой таблице начинает со временем выполняться медленнее, на несколько минут (изначально практически мгновенно) (при одних и тех же начальных данных). Для отчетности это много. В плане запроса появляется отличие : Если изначально Cardinality по этому индексу 1, то через месяцы возрастает до 46 Не буду утверждать что именно это приводит к замедлению, но больше отличий не вижу. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 16:26 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
В INSERT'ах, которыми заполняется таблица, хинтов случайно нет ? Первое, что приходит в голову, при "растет физический размер таблицы" Про индексы и кардиналити - ничего не знаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 16:42 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
GorOleg Cardinality по этому индексу 1, то через месяцы возрастает до 46 Как определили? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 16:46 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Если IFS = Index Full Scan То согласитесь, что Full Scan это не тот метод доступа, ради которого создают индексы. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 16:53 |
|
Деградация индексов в таблице из которой много удаляют
|
|||
---|---|---|---|
#18+
GorOleg, если лениво искать причину - тупо move и таблицу и индексы ея ~(оттуда же туда же) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 18:23 |
|
|
start [/forum/topic.php?fid=52&msg=39918424&tid=1881626]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
64ms |
get topic data: |
7ms |
get forum data: |
1ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 156ms |
0 / 0 |