ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Деградация индексов в таблице из которой много удаляют
15 сообщений из 15, страница 1 из 1
Деградация индексов в таблице из которой много удаляют
    #39918309
GorOleg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorOleg
Гость
Есть таблица с данными для отчета. В нее каждый день пишут порядка 500 пользователей по ~1000 записей/
Перед этим они удаляют свои предыдущие записи. Потом система генерации отчетов предоставляет данные в красивом виде.

В результате в таблице все время примерно одинаковое количество записей, но из-за массового удаления во первых растет физический размер таблицы, во вторых деградируют индексы.

Данные в таблице никакого значения не имеют, перед каждой отправкой в систему генерации отчетности они обновляются.

Есть какие нибудь хорошие идеи как обслуживать данную таблицу? Сейчас ее регулярно ночью пересоздают.
...
Рейтинг: 0 / 0
24.01.2020, 12:12
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918311
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Надфиль
Гость
GorOleg
но из-за массового удаления во первых растет физический размер таблицы

Не удалять вообще. "помечать" удаленными, и раз в месяц(?) чистить/пересоздать. полляма записей в день не должны убить производительность на нормальном сервере). хотя если записи очень большие по размеру..
...
Рейтинг: 0 / 0
24.01.2020, 12:16
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918324
123йй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
123йй
Участник
GorOleg
Есть таблица с данными для отчета. В нее каждый день пишут порядка 500 пользователей по ~1000 записей/
Перед этим они удаляют свои предыдущие записи.

Про временные таблицы слышали ?
...
Рейтинг: 0 / 0
24.01.2020, 12:34
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918334
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
GorOleg,
я б таблицу не удалял (ивалядятся хранимки), а очищал (truncate)
+ (возможно) пересоздание/alter индексов

.....
stax
...
Рейтинг: 0 / 0
24.01.2020, 12:54
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918344
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Надфиль
Гость
GorOleg,

Партиции на каждый день с локальными индексами.
...
Рейтинг: 0 / 0
24.01.2020, 13:11
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918356
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
Надфиль
GorOleg
но из-за массового удаления во первых растет физический размер таблицы
Не удалять вообще. "помечать" удаленными
О деградации можно говорить с точки зрения роста индекса для IFS, неудаление записей ничего не меняет для IFS.
...
Рейтинг: 0 / 0
24.01.2020, 13:28
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918371
GorOleg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorOleg
Гость
Stax, Это если и запись в таблицу и считывание системой отчетности в одной транзакции. Это я пока на 100% не уверен. Буду экспериментировать
...
Рейтинг: 0 / 0
24.01.2020, 13:41
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918401
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
GorOleg,

Вы меня не так поняли, регулярно ночью , токо вместо create - truncate

автор Сейчас ее регулярно ночью

.....
stax
...
Рейтинг: 0 / 0
24.01.2020, 14:51
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918424
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
честно говоря, не понимаю проблему

GorOleg

но из-за массового удаления во первых растет физический размер таблицы

???
Если со вставками никто не химичил (не хинтовал), то с чего "растет физический размер таблицы" "из-за массового удаления" ?

GorOleg

во вторых деградируют индексы.

Что это значит?

-2-О деградации можно говорить с точки зрения роста индекса для IFS

Если IFS = Index Full Scan
То согласитесь, что Full Scan это не тот метод доступа, ради которого создают индексы.
Может быть, вместо борьбы с деградацией, просто нормальные (подходящие для запросов) индексы создать?

IMHO

Глядя в хрустальный шар, складывается ощущение, что:
1. Или пытаются боротся с чем-то при отсутствие проблемы
т.к. мне сложно представить, что обычной вставке и удалению на Oracle можно помочь ночным пересозданием
2. Или, проблема сама создана тем, что кто-то ранее уже успешно боролся с несуществующей проблемой.
хинтовал insert'ы думая, что так будет правильнее и быстрее
...
Рейтинг: 0 / 0
24.01.2020, 15:54
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918439
GorOleg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorOleg
Гость
Leonid Kudryavtsev,
Визуально - проблема - запрос к этой таблице начинает со временем выполняться медленнее, на несколько минут (изначально практически мгновенно) (при одних и тех же начальных данных). Для отчетности это много.
В плане запроса появляется отличие : Если изначально Cardinality по этому индексу 1, то через месяцы возрастает до 46

Не буду утверждать что именно это приводит к замедлению, но больше отличий не вижу.
...
Рейтинг: 0 / 0
24.01.2020, 16:26
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918450
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
В INSERT'ах, которыми заполняется таблица, хинтов случайно нет ?
Первое, что приходит в голову, при "растет физический размер таблицы"
Про индексы и кардиналити - ничего не знаю.
...
Рейтинг: 0 / 0
24.01.2020, 16:42
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918458
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
GorOleg
Cardinality по этому индексу 1, то через месяцы возрастает до 46

Как определили?
...
Рейтинг: 0 / 0
24.01.2020, 16:46
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918465
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
Leonid Kudryavtsev
Если IFS = Index Full Scan
То согласитесь, что Full Scan это не тот метод доступа, ради которого создают индексы.
IFS это index full scan. Переход от "если" к "То" не осилил.
...
Рейтинг: 0 / 0
24.01.2020, 16:53
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918518
Фотография orawish
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
orawish
Участник
GorOleg,

если лениво искать причину -
тупо move и таблицу и индексы ея ~(оттуда же туда же)
...
Рейтинг: 0 / 0
24.01.2020, 18:23
| Ответить | Цитировать | Написать  
Деградация индексов в таблице из которой много удаляют
    #39918556
GorOleg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorOleg
Гость
andrey_anonymous
GorOleg
Cardinality по этому индексу 1, то через месяцы возрастает до 46

Как определили?


План запроса посмотрел.
...
Рейтинг: 0 / 0
24.01.2020, 20:57
| Ответить | Цитировать | Написать  
15 сообщений из 15, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Деградация индексов в таблице из которой много удаляют
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&tid=1881626]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 47ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 54ms
get tp. blocked users:
 2ms
others: 12ms
total:  158ms
созд. / загр.: 158ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]