Нет, это ненормально
И очень похоже, что таки где-то вставляется запись с нулевой (отрицательной, до н.э.) датой, что оставляет все промежуточные блоки в цепочке
Можно попробовать повесить констрейнт, типа дата не меньше чем год/месяц/день назад

Можно, конечно, грешить на баг, но 10.2.0.4 достаточно стабильная и описанная ситуация (добавление новых, подтирка старых) достаточно стандартная -- уже кто-нибудь наступил бы

Сейчас точно не найду, но как-то проскакивала информация, что "в целях оптимизации" пустой блок становится недоступен через ссылочку из branch-блока, но цепочка "лево-право" не прерывается в листовых блоках, пока есть значение в конце цепочки. Только при переиспользовании этих пустых блоков указатели "лево-право" перезаписываются в смежные листовые блоки.
Вроде, как связано было с возможностью flashback по undo.
Врать уже больше не буду , но с определенной версии пришлось запускать ежесуточную перестройку индексов для приложения работающего в таком режиме "очереди"

У нас затыкалась именно такая же технология -- "очередь", где накладывается в один конец, а вычищается (обрабатывается) с другого
Только там была не дата, а ID из последовательности
Вот когда обработка некоторых ID затыкалась -- их делали отрицательными (типа, разберемся потом)
И начинались тормоза, которые лечились ежесуточным перестроением индекса

Естественно, если ничего не трогать (не обновлять ID в отрицательное значение), то ничего и не тормозило, все красиво отрезалось и MIN/MAX не пробегал сотню пустых блоков

Вот точно не скажу, вроде как действительно началось именно в 10.2

AlexFF__|Вячеслав Любомудров,

Т.е. при каких-то условиях, индексные блоки с удаленными записями не использовались повторно в массовых количествах?
Весьма интересно.
Можешь пример представить?Они использовались
И именно тогда цепочка укорачивалась
Но не так быстро, как хотелось бы

Пример так быстро не предоставлю, в отпуске, пишу по памяти

2DBA
Насколько помню, именно RS

Вот навскидку описание изVarious Aspects of Fragmentation (Doc ID 186826.1) Т.е. пока блок не будет переиспользован, он так и останется в цепочке листовых блоков и при просмотре индекса (RANGE / FULL INDEX SCAN) будет читаться.
Естественно, если условие будет на ключ (например, дата > sysdate-1), а не просто
то начальное (MIN/MAX) значение (та самая нулевая дата) и все пустые блоке в цепочке до действительно нужной даты будут пропущены

PS. Правда, если у автора действительно NLKВсе записи, старше нескольких часов удаляются ежеминутното это не та причина.
Но это же sql.ru -- читаешь об одном, а отвечаешь про наболевшее
Да и есть подозрение, что удаляются только "обработанные" записи, а не скопом DELETE ... WHERE дата < sysdate-6/24

PPS. Тестик надо будет все-таки сделать, самому интересно

NLKAlexFF__|NLK,

analyze index idx_tab_dt validate structure
select * from index_stats
Это ведь блокирующая операция. На боевой БД не дадут это сделать.Если есть доступ, можно посмотреть Script to investigate a b-tree index structure (Doc ID 989186.1)

ElicNLKВ таблицу с постоянной скоростью пишутся данные, в dt записывается текущая дата-время. Все записи, старше нескольких часов удаляются ежеминутно. То есть, в таблице не очень много данных, но довольно много блоков (на порядок больше, чем необходимо, чтобы эти данные сохранить), и данные расположены всюду неплотно. Аналогичная ситуация с индексом: листовых блоков (по all_indexes.leaf_blocks) около 10 тыс, что почти в 10 раз меньше, чем блоков в сегменте индекса (100 тыс), и в каждом живом блоке в среднем по 10 записей.В индексе, в котором данные монотонно сдвигаются "вправо", "левые" высвобождающиеся блоки повторно не используются, поскольку автоматический coalesce происходит только при попытке вставить околоудалённый ключ, чего в монотонно подчищающейся последовательности не происходит.
Как следствие RS слева (даже min) катастрофически неэффективен.Это не совсем так
Они переиспользуются, когда до них доходит очередь (а алгоритм там не совсем очевидный) -- сразу после того как [листовой] блок становится полностью пустым, он попадает в список свободных блоков, но из цепочки (лист <-> лист) не удаляется (до переиспользования)
Т.е. пустые блоки посещаются только при движении по листовым ссылкам
Более того, если у тебя в левом конце нет актуального значения, то в этот левый конец никак не попадешь (через путешествие по root->[branch->]...leaf)
Соответственно, обычное "скользящее" окно, если оно небольшое, работает достаточно предсказуемо
ElicВыход несложный: после какого-то очередного массового delete надо делать индексу ничего не блокирующий coalesce.Здесь нет "массового" удаления, здесь оно непрерывное
Очередь
ElicВячеслав ЛюбомудровИ начинались тормоза, которые лечились ежесуточным перестроением индексаСерпом по яйцам не разбираясь?В ранних версиях 10-ки, насколько помню с COALESCE был достаточно страшный баг, когда при его прерывании (на индексе ) можно было потерять данные таблицы . Да и кто юзает новые фичи сразу
По поводу перестроения тоже свои тараканы -- до 11 нельзя было указать таймаут DDL (а может это и хорошо было), а потом еще какие-то фишки с ONLINE вылезли
Когда это все работает асинхронно, в несколько потоков (как наваливающих, так и разгребающих) со своими связанными таблицами... В общем, как правило, работает