|
|
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Oracle Database 10g Release 10.2.0.4.0 Имеется таблица Код: plsql 1. 2. В таблицу с постоянной скоростью пишутся данные, в dt записывается текущая дата-время. Все записи, старше нескольких часов удаляются ежеминутно. То есть, в таблице не очень много данных, но довольно много блоков (на порядок больше, чем необходимо, чтобы эти данные сохранить), и данные расположены всюду неплотно. Аналогичная ситуация с индексом: листовых блоков (по all_indexes.leaf_blocks) около 10 тыс, что почти в 10 раз меньше, чем блоков в сегменте индекса (100 тыс), и в каждом живом блоке в среднем по 10 записей. При выполнении запроса вида Код: plsql 1. периодически (не всегда!) читаются почти все блоки из сегмента индекса, т.е. не только те 10 тыс, что указаны в all_indexes.leaf_blocks, но и остальные 90 тыс из сегмента индекса. Хотя если использовать запрос с закрытой левой границей (almost_sysdate -1/24 < dt < almost_sysdate), то ничего лишнего не читается. Причём, индекс периодически, раз в несколько дней, переключается из режима чтения "лишних" блоков в режим чтения только блоков с данными, а потом переключается обратно. Вопрос: периодическое чтение пустых блоков - это нормальная ситуация? Почему так происходит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 13:41 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Нет, это ненормально И очень похоже, что таки где-то вставляется запись с нулевой (отрицательной, до н.э.) датой, что оставляет все промежуточные блоки в цепочке Можно попробовать повесить констрейнт, типа дата не меньше чем год/месяц/день назад Можно, конечно, грешить на баг, но 10.2.0.4 достаточно стабильная и описанная ситуация (добавление новых, подтирка старых) достаточно стандартная -- уже кто-нибудь наступил бы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 15:18 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровНет, это ненормально И очень похоже, что таки где-то вставляется запись с нулевой (отрицательной, до н.э.) датой, что оставляет все промежуточные блоки в цепочке Да бог с тобой =) Запись с маленькой датой оставит только блок в котором она есть, остальные блоки, в которых находятся только удаленные записи, будут переиспользованы по возможности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 16:10 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Сейчас точно не найду, но как-то проскакивала информация, что "в целях оптимизации" пустой блок становится недоступен через ссылочку из branch-блока, но цепочка "лево-право" не прерывается в листовых блоках, пока есть значение в конце цепочки. Только при переиспользовании этих пустых блоков указатели "лево-право" перезаписываются в смежные листовые блоки. Вроде, как связано было с возможностью flashback по undo. Врать уже больше не буду , но с определенной версии пришлось запускать ежесуточную перестройку индексов для приложения работающего в таком режиме "очереди" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 16:33 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудров, Ну так алгоритм ТС будет постоянно переиспользовать пустые блоки NLKВ таблицу с постоянной скоростью пишутся данные, в dt записывается текущая дата-время. Все записи, старше нескольких часов удаляются ежеминутно. Так что записи в самом начале делу не помеха. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 16:45 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
У нас затыкалась именно такая же технология -- "очередь", где накладывается в один конец, а вычищается (обрабатывается) с другого Только там была не дата, а ID из последовательности Вот когда обработка некоторых ID затыкалась -- их делали отрицательными (типа, разберемся потом) И начинались тормоза, которые лечились ежесуточным перестроением индекса Естественно, если ничего не трогать (не обновлять ID в отрицательное значение), то ничего и не тормозило, все красиво отрезалось и MIN/MAX не пробегал сотню пустых блоков Вот точно не скажу, вроде как действительно началось именно в 10.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:04 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудров, Т.е. при каких-то условиях, индексные блоки с удаленными записями не использовались повторно в массовых количествах? Весьма интересно. Можешь пример представить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:10 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
NLKпериодически (не всегда!) читаются почти все блоки из сегмента индекса а как читаются? range scan? fast full scan? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:15 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
AlexFF__|Вячеслав Любомудров, Т.е. при каких-то условиях, индексные блоки с удаленными записями не использовались повторно в массовых количествах? Весьма интересно. Можешь пример представить?Они использовались И именно тогда цепочка укорачивалась Но не так быстро, как хотелось бы Пример так быстро не предоставлю, в отпуске, пишу по памяти 2DBA Насколько помню, именно RS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:20 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
NLKВопрос: периодическое чтение пустых блоков - это нормальная ситуация? Почему так происходит?да, скорее всего, у вас просто план плавает с фулскана на rs и обратно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:30 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
DВАNLKпериодически (не всегда!) читаются почти все блоки из сегмента индекса а как читаются? range scan? fast full scan? dbms_xplan.display_cursor показывает INDEX RANGE SCAN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:44 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
xtenderNLKВопрос: периодическое чтение пустых блоков - это нормальная ситуация? Почему так происходит?да, скорее всего, у вас просто план плавает с фулскана на rs и обратно Но dbms_xplan.display_cursor ни разу не показывал фулсканы: в обоих "режимах" работы индекса показывает index range scan, только Buffers и Reads скачут на порядок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:47 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
NLK, analyze index idx_tab_dt validate structure select * from index_stats ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:50 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
NLKолько Buffers и Reads скачут на порядок.так а ожидания-то проверили? может не индекс-то читается, а просто совпадает с удалениями вашими постоянными ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:51 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
AlexFF__|NLK, analyze index idx_tab_dt validate structure select * from index_stats Это ведь блокирующая операция. На боевой БД не дадут это сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 18:15 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
xtenderNLKолько Buffers и Reads скачут на порядок.так а ожидания-то проверили? может не индекс-то читается, а просто совпадает с удалениями вашими постоянными Прошу прощения, я видимо что-то не понял. Имеете в виду, что другой объект (таблица, а не индекс) читается? Или dbms_xplan.display_cursor показывает чтения и для других запросов, выполнявшихся одновременно с проблемным? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 18:19 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
NLK, я про undo ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 18:24 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
NLK, ну и возможная отложенная очистка блоков ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 18:25 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Да скорее всего, все проще NLKАналогичная ситуация с индексом: листовых блоков (по all_indexes.leaf_blocks) около 10 тыс, что почти в 10 раз меньше, чем блоков в сегменте индекса (100 тыс), и в каждом живом блоке в среднем по 10 записей. В индексе из примерно 100к блоков (не будем считать дерево) не пустые только 10к, они и показаны в статистике как leaf_blocks. IRS (dt < almost_sysdate) в таком случае читает все пустые блоки в начале, (almost_sysdate -1/24 < dt < almost_sysdate) читает только нужный диапазон, выключая некоторые пустые блоки, по удаленным записям тоже определяются границы. Только записи в данном случае должны писаться мощными блоками раз некоторое время =) Или, как писал Вячеслав Любомудров, это какой-то баг при котором сводные блоки не используются повторно некоторое время. В любом случае, как ты и сам писал, левая граница поможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 20:22 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
И все-таки для начала я бы зафиксировал план с IRS для надёжности... Затем отребилдил бы индекс, т.к. похоже что сегмент такой большой, потому что изначально не было удаления по расписанию. И только потом, если проблема осталась решал бы её по детальным данным с ожиданиями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 22:30 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Вот навскидку описание изVarious Aspects of Fragmentation (Doc ID 186826.1) Код: plaintext 1. 2. 3. 4. 5. 6. Естественно, если условие будет на ключ (например, дата > sysdate-1), а не просто Код: plsql 1. то начальное (MIN/MAX) значение (та самая нулевая дата) и все пустые блоке в цепочке до действительно нужной даты будут пропущены PS. Правда, если у автора действительно NLKВсе записи, старше нескольких часов удаляются ежеминутното это не та причина. Но это же sql.ru -- читаешь об одном, а отвечаешь про наболевшее Да и есть подозрение, что удаляются только "обработанные" записи, а не скопом DELETE ... WHERE дата < sysdate-6/24 PPS. Тестик надо будет все-таки сделать, самому интересно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 04:33 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
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) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 04:43 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
NLKВ таблицу с постоянной скоростью пишутся данные, в dt записывается текущая дата-время. Все записи, старше нескольких часов удаляются ежеминутно. То есть, в таблице не очень много данных, но довольно много блоков (на порядок больше, чем необходимо, чтобы эти данные сохранить), и данные расположены всюду неплотно. Аналогичная ситуация с индексом: листовых блоков (по all_indexes.leaf_blocks) около 10 тыс, что почти в 10 раз меньше, чем блоков в сегменте индекса (100 тыс), и в каждом живом блоке в среднем по 10 записей. При выполнении запроса вида Код: plsql 1. периодически (не всегда!) читаются почти все блоки из сегмента индекса, т.е. не только те 10 тыс, что указаны в all_indexes.leaf_blocks, но и остальные 90 тыс из сегмента индекса. Хотя если использовать запрос с закрытой левой границей (almost_sysdate -1/24 < dt < almost_sysdate), то ничего лишнего не читается. Причём, индекс периодически, раз в несколько дней, переключается из режима чтения "лишних" блоков в режим чтения только блоков с данными, а потом переключается обратно. Вопрос: периодическое чтение пустых блоков - это нормальная ситуация? Почему так происходит? Предполагаю, что переключение в режим чтения только блоков с данными происходит после (автоматического) пересбора статистики по этой таблице. По мере того, как статистика (интервал , в котором на тот момент были значения dt) перестает соответствовать попаданию в этот интервал almost_sysdate, план портится. xtenderда, скорее всего, у вас просто план плавает с фулскана на rs и обратно +1 Наверное, зафиксировать план, как xtender предложил, будет наиболее разумно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 14:20 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
NLKВ таблицу с постоянной скоростью пишутся данные, в dt записывается текущая дата-время. Все записи, старше нескольких часов удаляются ежеминутно. То есть, в таблице не очень много данных, но довольно много блоков (на порядок больше, чем необходимо, чтобы эти данные сохранить), и данные расположены всюду неплотно. Аналогичная ситуация с индексом: листовых блоков (по all_indexes.leaf_blocks) около 10 тыс, что почти в 10 раз меньше, чем блоков в сегменте индекса (100 тыс), и в каждом живом блоке в среднем по 10 записей.В индексе, в котором данные монотонно сдвигаются "вправо", "левые" высвобождающиеся блоки повторно не используются, поскольку автоматический coalesce происходит только при попытке вставить околоудалённый ключ, чего в монотонно подчищающейся последовательности не происходит. Как следствие RS слева (даже min) катастрофически неэффективен. Выход несложный: после какого-то очередного массового delete надо делать индексу ничего не блокирующий coalesce. Вячеслав ЛюбомудровИ начинались тормоза, которые лечились ежесуточным перестроением индексаСерпом по яйцам не разбираясь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 15:43 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
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 вылезли Когда это все работает асинхронно, в несколько потоков (как наваливающих, так и разгребающих) со своими связанными таблицами... В общем, как правило, работает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:03 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
xtenderотребилдилДостаточно coalesce. Да и сценарий стандартнейший. Не понимаю, почему широко не освещён. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:04 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровЭто не совсем так Они переиспользуютсяНет. В "скользящем окне" левые блоки переиспользуются чуть реже, чем никогда. Поверь моему многодесятилетнему опыту. Только явный coalesce помогает. Вячеслав ЛюбомудровЗдесь нет "массового" удаления, здесь оно непрерывное ОчередьС точки зрения конечного результата - без разницы. Просто в таком случае не просто совместить coalesce с delete. Вячеслав ЛюбомудровВ ранних версиях 10-ки, насколько помню с COALESCE был достаточно страшный баг, когда при его прерывании (на индексе ) можно было потерять данные таблицы .Не верю. coalesce всего лишь команда задействовать встроенные в индекс механизмы. И поэтому никого не блокирует. Только на чуть-чуть в рамках конкретного блока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:25 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
ElicВячеслав ЛюбомудровЭто не совсем так Они переиспользуютсяНет. В "скользящем окне" левые блоки переиспользуются чуть реже, чем никогда.И я тоже какое-то время верил в переиспользование. Но в случае скользящего окна оно не работает. Даже, по-моему, у Льюиса об этом есть. Но не в столь явной форме, что при скользящем окне нужен регулярный coalesce. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:30 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
так версия 10.2, там усе может быть ) насчет данных таблицы хз, но вот данные индекса например при ребилд онлайн запросто теряются, обращаешься к таблице по индексу, а нет там ничего ) кстати и в 11 тоже воспроизводится, и в 12 ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:48 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
ElicВячеслав ЛюбомудровЭто не совсем так Они переиспользуютсяНет. В "скользящем окне" левые блоки переиспользуются чуть реже, чем никогда. Поверь моему многодесятилетнему опыту. Только явный coalesce помогает.И все же это не так У нас ежедневно в родительскую таблицу влетают сотни тысяч записей (и в дочерние соответственно миллионы), но при этом индексы не разрастаются, если вовремя разгребается (удаляется) то, что успело навалиться (вставиться) Это работает много (более 10) лет, 24*7 Проблемы возникают когда где-то происходит затык и "обработчики" сильно отстают от "агентов" (или когда левая граница умышлено "замораживается" через отрицательный ID) ElicВячеслав ЛюбомудровВ ранних версиях 10-ки, насколько помню с COALESCE был достаточно страшный баг, когда при его прерывании (на индексе ) можно было потерять данные таблицы .Не верю. coalesce всего лишь команда задействовать встроенные в индекс механизмы. И поэтому никого не блокирует. Только на чуть-чуть в рамках конкретного блока.Скорее всего, я попутал со SHRINK (но поразило именно то, что упаковывается индекс , а данные можно потерять в таблице ) Предупреждение я увидел здесь (темку вот так сразу найти не удалось), а потом нашел этот баг на металинке В общем, страшновато стало А так один из обработчиков перед началом основной деятельности проверяет, что индексы не перестраивались уже сутки и делает попытку перестроить (а не получилось, ну так и бог с ним, попробуем в следующий раз) -- при нормальной работе это занимает секунды ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:52 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
DВАно вот данные индекса например при ребилд онлайн запросто теряются, обращаешься к таблице по индексу, а нет там ничего ) кстати и в 11 тоже воспроизводится, и в 12 )Если запросто, то где тест-кэйс? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:54 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
DBA прикалывается Естественно, при кривом индексе попасть через него в таблицу нельзя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:56 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудровчерез отрицательный IDИменно это и могло провоцировать автоматический coalesce. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:58 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Именно это, как раз, и создает длиннющую цепочку пустых блоков, если мы идем от MIN ну и дальше по индексу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 17:00 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровИменно это, как раз, и создает длиннющую цепочку пустых блоков, если мы идем от MIN ну и дальше по индексуТы не прав. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 17:48 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Elic, в сапорте тест-кейс :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 18:26 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровПо поводу перестроения тоже свои тараканы -- до 11 нельзя было указать таймаут DDL (а может это и хорошо было), а потом еще какие-то фишки с ONLINE вылезли "Веселые" фишки с ONLINE вылезали еще в 8i ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 23:33 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
DВАElic, в сапорте тест-кейс :)Много пить - вредно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2017, 07:08 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
ElicDВАElic, в сапорте тест-кейс :)Много пить - вредно. фантазировать на мой счет много вредно )) Bug 7329252 : ORA-8102 DURING REBUILD INDEX ONLINE WHEN CONCURRENT W/ UPDATES ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2017, 11:30 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
ElicДа и сценарий стандартнейший. Не понимаю, почему широко не освещён.лень искать, но я хорошо помню, что на асктоме кайт давным-давно писал про то что именно такие кейсы надо периодически ребилдил(он писал про AQ-таблицы - они как раз такой случай), только я никогда не проверял актуальность этого в разных версиях оракла... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2017, 12:05 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Точнее aq - это iot, но как раз постоянно вставляемые справа/удаляемые слева ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2017, 12:10 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
xtenderлень искать, но я хорошо помню, что на асктоме кайтМало ли чего понапишут литературные рабы.xtenderдавным-давно писал про то что именно такие кейсы надо периодически ребилдилСаян, мне вот странно разъяснять такие, вроде как, очевидные вещи. Да если уж на то пошло, coalesce дешевле (по деньгам), чем rebuild online.Index Rebuild, the Need vs the Implications (Doc ID 989093.1)3. An index coalesce is often preferred instead of an index rebuild. It has the following advantages: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 09:30 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
DВАBug 7329252Ната, я надеялся, что ты понимаешь, что тест-case - это не пустопорожние страшилки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 09:33 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
ElicDВАBug 7329252Ната, я надеялся, что ты понимаешь, что тест-case - это не пустопорожние страшилки. Даже не знаю что тебе сказать... если зарегистрированный баг с выпущенным патчем - это пустопорожние страшилки :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 11:17 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
DВАДаже не знаю что тебе сказать... если зарегистрированный баг с выпущенным патчем - это пустопорожние страшилки :)Там слишком мало конкретики, что бы понять, а был ли предмет для боязни. Да и версии какие-то левенькие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 11:28 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
ElicDВАДаже не знаю что тебе сказать... если зарегистрированный баг с выпущенным патчем - это пустопорожние страшилки :)Там слишком мало конкретики, что бы понять, а был ли предмет для боязни. Да и версии какие-то левенькие. Ну я не самый боязливый человек, но меня эта радость преследует периодически у разных заказчиков\работодателей, последний раз буквально полгода назад уже на 11.2 - при интенсивных апдейтах одних и тех же строк и параллельном перестраивание индекса в онлайне, либо перебрасывании партиций с апдейтом индексов в онлайне, в индексе теряются ключи для обновляемых строк. Для бага что я кинула под версию 10.2 тест-кейс элементарный, сама делала, но уже лет 8 назад, с 11.2 воспроизвести искусственно не получилось, видимо не все факторы учла, на на промышленной системе воспроизводился стабильно вплоть до наката патчсета и перехода на другую платформу, на 12 версии коллега показывал простенький тест-кейс, но там уже специфика связанная с недоработкой референс-партиционированных таблиц, баг 25898228, там вообще вся партиция уходит в никуда ) Так что бояться или не бояться дело добровольное, но иметь в виду стоит ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 12:11 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
ElicСаян, мне вот странно разъяснять такие, вроде как, очевидные вещи. Да если уж на то пошло, coalesce дешевле (по деньгам), чем rebuild online.1. Это было давным-давно, тогда coalesce и не было... 2. А ТСу я объяснил почему лучше разок сделать ребилд: я предположил, что т.к. размер сегмента у него минимум в 10 раз больше, чем нужно, то, видимо, удаления они сделали намного позднее, чем он так разросся. Так что помимо самого просто так занимаемого места(которое, например, при IFFS будет зря сканироваться), это значит, что скорее всего ребилд и blevel может понизить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 12:33 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
ЗЫ. от Льюиса со ссылкой на вопрос на этот же форум: https://jonathanlewis.wordpress.com/2011/03/03/index-rebuilds-4/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 12:36 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
он, кстати, еще пишет:автор (Actually, "shrink space compact" seems to be more efficient than "coalesce" in recent versions - but the whole AQ thing introduces some funny effects around the edges anyway.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 12:40 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
Всем привет, поднимаем тему после отпуска =) Алгоритм переиспользования пустых блоков индексов довольно интересен, будет жалко, если обсуждение закончится ничем. Код: plsql 1. 2. 3. 4. 5. 6. 7. Давайте начнем с едиственного кейса в теме от Elic. Я, к сожалению, не понял, что он хотел показать =( В кейсе всталяются 500к записей, потом удаляются, затем справа вставляется еще одна запись. Далее показывается, что INDEX FULL SCAN (MIN/MAX) сканирует всю цепочку листовых блоков, что естественно, скан ищет первую неудаленную запись. Нас же интересует переиспользование этих пустых блоков, хорошо покажет это вставка 250к блоков (половина объемы) справа, т.е. возрастающая последовательность. Я повторил кейс Elic, добавив в конце свои statements (для удобства чтения я опустил результаты, оставив последние значащие). Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. Как видим, количество чтений упало почти в 2 раза с 2819 до 1509, что как раз и показывает переиспользование пустых блоков. Далее уже мой старый тест, там идет вставка и последующее удаление разных диапазонов записей. Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. Результаты: ==================================================================================================== ==== Очищаем таблицу : truncate table TAB_TEST; ==== Вставляем 50000 записей : insert into TAB_TEST select rownum, 'test_' || rownum from dual connect by rownum <= 50000; ==== Удаляем 30000 записей в середине : delete TAB_TEST where id between 10001 and 40000; --Читаются пустые блоки SELECT /* TEST 1.1 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 40001; rows = 2; gets = 126 [INDEX RANGE SCAN] SELECT /* TEST 1.2 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 20001; rows = 1; gets = 43 [INDEX RANGE SCAN] SELECT /* TEST 1.3 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 30001; rows = 1; gets = 85 [INDEX RANGE SCAN] SELECT /* TEST 1.4 */ ID FROM TAB_TEST WHERE ID BETWEEN 20000 AND 30001; rows = 0; gets = 44 [INDEX RANGE SCAN] SELECT /*+ index(T IDX_TEST) TEST 1.5 */ ID FROM TAB_TEST T WHERE ID < 40010; rows = 10009; gets = 164 [INDEX RANGE SCAN] ==== Вставляем 20000 записей в конец : insert into TAB_TEST select rownum + 70000, 'test_' || rownum from dual connect by rownum <= 20000; --Часть пустых блоков переиспользованы повторно SELECT /* TEST 2.1 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 40001; rows = 2; gets = 46 [INDEX RANGE SCAN] SELECT /* TEST 2.2 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 20001; rows = 1; gets = 8 [INDEX RANGE SCAN] SELECT /* TEST 2.3 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 30001; rows = 1; gets = 45 [INDEX RANGE SCAN] SELECT /* TEST 2.4 */ ID FROM TAB_TEST WHERE ID BETWEEN 20000 AND 30001; rows = 0; gets = 39 [INDEX RANGE SCAN] SELECT /*+ index(T IDX_TEST) TEST 2.5 */ ID FROM TAB_TEST T WHERE ID < 40010; rows = 10009; gets = 84 [INDEX RANGE SCAN] ==== Вставляем 20000 записей в конец : insert into TAB_TEST select rownum + 90000, 'test_' || rownum from dual connect by rownum <= 20000; --Пустые блоки переиспользованы повторно SELECT /* TEST 3.1 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 40001; rows = 2; gets = 3 [INDEX RANGE SCAN] SELECT /* TEST 3.2 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 20001; rows = 1; gets = 3 [INDEX RANGE SCAN] SELECT /* TEST 3.3 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 30001; rows = 1; gets = 3 [INDEX RANGE SCAN] SELECT /* TEST 3.4 */ ID FROM TAB_TEST WHERE ID BETWEEN 20000 AND 30001; rows = 0; gets = 3 [INDEX RANGE SCAN] SELECT /*+ index(T IDX_TEST) TEST 3.5 */ ID FROM TAB_TEST T WHERE ID < 40010; rows = 10009; gets = 41 [INDEX RANGE SCAN] ==================================================================================================== ==== Очищаем таблицу : truncate table TAB_TEST; ==== Вставляем 50000 записей : insert into TAB_TEST select rownum, 'test_' || rownum from dual connect by rownum <= 50000; ==== Удаляем 30000 записей в начале : delete TAB_TEST where id between 1 and 30000; --Читаются пустые блоки SELECT /* TEST 4.1 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 40001; rows = 10001; gets = 250 [INDEX FAST FULL SCAN] SELECT /* TEST 4.2 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 20001; rows = 0; gets = 43 [INDEX RANGE SCAN] SELECT /* TEST 4.3 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 30001; rows = 1; gets = 85 [INDEX RANGE SCAN] SELECT /* TEST 4.4 */ ID FROM TAB_TEST WHERE ID BETWEEN 20000 AND 30001; rows = 1; gets = 44 [INDEX RANGE SCAN] SELECT /*+ index(T IDX_TEST) TEST 4.5 */ ID FROM TAB_TEST T WHERE ID < 30010; rows = 9; gets = 123 [INDEX RANGE SCAN] ==== Вставляем 20000 записей в конец : insert into TAB_TEST select rownum + 70000, 'test_' || rownum from dual connect by rownum <= 20000; --Часть пустых блоков переиспользованы повторно SELECT /* TEST 5.1 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 40001; rows = 10001; gets = 212 [INDEX FAST FULL SCAN] SELECT /* TEST 5.2 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 20001; rows = 0; gets = 35 [INDEX RANGE SCAN] SELECT /* TEST 5.3 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 30001; rows = 1; gets = 43 [INDEX RANGE SCAN] SELECT /* TEST 5.4 */ ID FROM TAB_TEST WHERE ID BETWEEN 20000 AND 30001; rows = 1; gets = 10 [INDEX RANGE SCAN] SELECT /*+ index(T IDX_TEST) TEST 5.5 */ ID FROM TAB_TEST T WHERE ID < 30010; rows = 9; gets = 43 [INDEX RANGE SCAN] ==== Вставляем 20000 записей в конец : insert into TAB_TEST select rownum + 90000, 'test_' || rownum from dual connect by rownum <= 20000; --Пустые блоки переиспользованы повторно SELECT /* TEST 6.1 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 40001; rows = 10001; gets = 282 [INDEX FAST FULL SCAN] SELECT /* TEST 6.2 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 20001; rows = 0; gets = 2 [INDEX RANGE SCAN] SELECT /* TEST 6.3 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 30001; rows = 1; gets = 2 [INDEX RANGE SCAN] SELECT /* TEST 6.4 */ ID FROM TAB_TEST WHERE ID BETWEEN 20000 AND 30001; rows = 1; gets = 2 [INDEX RANGE SCAN] SELECT /*+ index(T IDX_TEST) TEST 6.5 */ ID FROM TAB_TEST T WHERE ID < 30010; rows = 9; gets = 2 [INDEX RANGE SCAN] ==================================================================================================== ==== Очищаем таблицу : truncate table TAB_TEST; ==== Вставляем 50000 записей : insert into TAB_TEST select rownum, 'test_' || rownum from dual connect by rownum <= 50000; ==== Удаляем все 50000 записей : delete TAB_TEST; --Читаются пустые блоки SELECT /* TEST 7.1 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 40001; rows = 0; gets = 126 [INDEX RANGE SCAN] SELECT /* TEST 7.2 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 20001; rows = 0; gets = 43 [INDEX RANGE SCAN] SELECT /* TEST 7.3 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 30001; rows = 0; gets = 85 [INDEX RANGE SCAN] SELECT /* TEST 7.4 */ ID FROM TAB_TEST WHERE ID BETWEEN 20000 AND 30001; rows = 0; gets = 44 [INDEX RANGE SCAN] SELECT /*+ index(T IDX_TEST) TEST 7.5 */ ID FROM TAB_TEST T WHERE ID < 30010; rows = 0; gets = 123 [INDEX RANGE SCAN] ==== Вставляем 20000 записей в конец : insert into TAB_TEST select rownum + 70000, 'test_' || rownum from dual connect by rownum <= 20000; --Часть пустых блоков переиспользованы повторно SELECT /* TEST 8.1 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 40001; rows = 0; gets = 89 [INDEX RANGE SCAN] SELECT /* TEST 8.2 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 20001; rows = 0; gets = 33 [INDEX RANGE SCAN] SELECT /* TEST 8.3 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 30001; rows = 0; gets = 50 [INDEX RANGE SCAN] SELECT /* TEST 8.4 */ ID FROM TAB_TEST WHERE ID BETWEEN 20000 AND 30001; rows = 0; gets = 21 [INDEX RANGE SCAN] SELECT /*+ index(T IDX_TEST) TEST 8.5 */ ID FROM TAB_TEST T WHERE ID < 30010; rows = 0; gets = 71 [INDEX RANGE SCAN] ==== Вставляем 30000 записей в конец : insert into TAB_TEST select rownum + 90000, 'test_' || rownum from dual connect by rownum <= 30000; --Пустые блоки переиспользованы повторно SELECT /* TEST 9.1 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 40001; rows = 0; gets = 2 [INDEX RANGE SCAN] SELECT /* TEST 9.2 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 20001; rows = 0; gets = 2 [INDEX RANGE SCAN] SELECT /* TEST 9.3 */ ID FROM TAB_TEST WHERE ID BETWEEN 10000 AND 30001; rows = 0; gets = 2 [INDEX RANGE SCAN] SELECT /* TEST 9.4 */ ID FROM TAB_TEST WHERE ID BETWEEN 20000 AND 30001; rows = 0; gets = 2 [INDEX RANGE SCAN] SELECT /*+ index(T IDX_TEST) TEST 9.5 */ ID FROM TAB_TEST T WHERE ID < 30010; rows = 0; gets = 2 [INDEX RANGE SCAN] И + еще накидал один дополнительно, тут вставляются в таблицу начальные 10000 значений, далее идут вставки в конец по 1000 и удаление сначала также по 1000 (500 итераций). Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. Результаты: 10. blocks=96 lf_blks=74 lf_rows=17123 br_blks=1 br_rows=73 del_lf_rows=7122 [ins_cnt=10000 del_cnt=9999] 20. blocks=96 lf_blks=87 lf_rows=19044 br_blks=1 br_rows=86 del_lf_rows=9043 [ins_cnt=10000 del_cnt=10000] 30. blocks=128 lf_blks=92 lf_rows=20526 br_blks=1 br_rows=91 del_lf_rows=10525 [ins_cnt=10000 del_cnt=10000] 40. blocks=128 lf_blks=92 lf_rows=20648 br_blks=1 br_rows=91 del_lf_rows=10647 [ins_cnt=10000 del_cnt=10000] 50. blocks=128 lf_blks=113 lf_rows=24436 br_blks=1 br_rows=112 del_lf_rows=14435 [ins_cnt=10000 del_cnt=10000] 60. blocks=128 lf_blks=114 lf_rows=24808 br_blks=1 br_rows=113 del_lf_rows=14807 [ins_cnt=10000 del_cnt=10000] 70. blocks=160 lf_blks=141 lf_rows=30302 br_blks=1 br_rows=140 del_lf_rows=20301 [ins_cnt=10000 del_cnt=10000] 80. blocks=160 lf_blks=147 lf_rows=30768 br_blks=1 br_rows=146 del_lf_rows=20767 [ins_cnt=10000 del_cnt=10000] 90. blocks=160 lf_blks=147 lf_rows=31610 br_blks=1 br_rows=146 del_lf_rows=21609 [ins_cnt=10000 del_cnt=10000] 100. blocks=192 lf_blks=148 lf_rows=32154 br_blks=1 br_rows=147 del_lf_rows=22153 [ins_cnt=10000 del_cnt=10000] 110. blocks=192 lf_blks=159 lf_rows=34021 br_blks=1 br_rows=158 del_lf_rows=24020 [ins_cnt=10000 del_cnt=10000] 120. blocks=192 lf_blks=177 lf_rows=37257 br_blks=1 br_rows=176 del_lf_rows=27256 [ins_cnt=10000 del_cnt=10000] 130. blocks=192 lf_blks=177 lf_rows=37554 br_blks=1 br_rows=176 del_lf_rows=27553 [ins_cnt=10000 del_cnt=10000] 140. blocks=192 lf_blks=177 lf_rows=37954 br_blks=1 br_rows=176 del_lf_rows=27953 [ins_cnt=10000 del_cnt=10000] 150. blocks=224 lf_blks=191 lf_rows=40871 br_blks=1 br_rows=190 del_lf_rows=30870 [ins_cnt=10000 del_cnt=10000] 160. blocks=224 lf_blks=205 lf_rows=43230 br_blks=1 br_rows=204 del_lf_rows=33229 [ins_cnt=10000 del_cnt=10000] 170. blocks=224 lf_blks=207 lf_rows=42956 br_blks=1 br_rows=206 del_lf_rows=32955 [ins_cnt=10000 del_cnt=10000] 180. blocks=224 lf_blks=207 lf_rows=42345 br_blks=1 br_rows=206 del_lf_rows=32344 [ins_cnt=10000 del_cnt=10000] 190. blocks=224 lf_blks=207 lf_rows=42732 br_blks=1 br_rows=206 del_lf_rows=32731 [ins_cnt=10000 del_cnt=10000] 200. blocks=256 lf_blks=208 lf_rows=43525 br_blks=1 br_rows=207 del_lf_rows=33524 [ins_cnt=10000 del_cnt=10000] 210. blocks=256 lf_blks=208 lf_rows=43168 br_blks=1 br_rows=207 del_lf_rows=33167 [ins_cnt=10000 del_cnt=10000] 220. blocks=256 lf_blks=208 lf_rows=43211 br_blks=1 br_rows=207 del_lf_rows=33210 [ins_cnt=10000 del_cnt=10000] 230. blocks=256 lf_blks=208 lf_rows=42597 br_blks=1 br_rows=207 del_lf_rows=32596 [ins_cnt=10000 del_cnt=10000] 240. blocks=256 lf_blks=208 lf_rows=42143 br_blks=1 br_rows=207 del_lf_rows=32142 [ins_cnt=10000 del_cnt=10000] 250. blocks=256 lf_blks=208 lf_rows=42607 br_blks=1 br_rows=207 del_lf_rows=32606 [ins_cnt=10000 del_cnt=10000] 260. blocks=256 lf_blks=208 lf_rows=43126 br_blks=1 br_rows=207 del_lf_rows=33125 [ins_cnt=10000 del_cnt=10000] 270. blocks=256 lf_blks=229 lf_rows=47697 br_blks=1 br_rows=228 del_lf_rows=37696 [ins_cnt=10000 del_cnt=10000] 280. blocks=256 lf_blks=238 lf_rows=49974 br_blks=1 br_rows=237 del_lf_rows=39973 [ins_cnt=10000 del_cnt=10000] 290. blocks=288 lf_blks=238 lf_rows=49170 br_blks=1 br_rows=237 del_lf_rows=39169 [ins_cnt=10000 del_cnt=10000] 300. blocks=288 lf_blks=238 lf_rows=48596 br_blks=1 br_rows=237 del_lf_rows=38595 [ins_cnt=10000 del_cnt=10000] 310. blocks=288 lf_blks=238 lf_rows=48443 br_blks=1 br_rows=237 del_lf_rows=38442 [ins_cnt=10000 del_cnt=10000] 320. blocks=288 lf_blks=242 lf_rows=48379 br_blks=1 br_rows=241 del_lf_rows=38378 [ins_cnt=10000 del_cnt=10000] 330. blocks=288 lf_blks=251 lf_rows=48937 br_blks=1 br_rows=250 del_lf_rows=38936 [ins_cnt=10000 del_cnt=10000] 340. blocks=288 lf_blks=252 lf_rows=49602 br_blks=1 br_rows=251 del_lf_rows=39601 [ins_cnt=10000 del_cnt=10000] 350. blocks=288 lf_blks=254 lf_rows=49987 br_blks=1 br_rows=253 del_lf_rows=39986 [ins_cnt=10000 del_cnt=10000] 360. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 370. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 380. blocks=288 lf_blks=262 lf_rows=52799 br_blks=1 br_rows=261 del_lf_rows=42798 [ins_cnt=10000 del_cnt=10000] 390. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 400. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 410. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 420. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 430. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 440. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 450. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 460. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 470. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 480. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 490. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] 500. blocks=288 lf_blks=262 lf_rows=52557 br_blks=1 br_rows=261 del_lf_rows=42556 [ins_cnt=10000 del_cnt=10000] Тут видно, что хотя размер и растет постоянно, но алгоритм переиспользования пустых блоков работает. Для сравнения, размер индекса без удаления записей (т.е. имуляция того, что пустые блоки остаются навсегда) - 2105 lf_blks. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2017, 13:32 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
AlexFF__|но алгоритм переиспользования пустых блоков работает.Но по сравнению с coalesce - "не очень" и по-прежнему неэффективно для запросов "слева". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2017, 14:00 |
|
||
|
RS с левой открытой границей читает пустые блоки индекса
|
|||
|---|---|---|---|
|
#18+
[quot DВА]Elicпропущено...... на 12 версии коллега показывал простенький тест-кейс, но там уже специфика связанная с недоработкой референс-партиционированных таблиц, баг 25898228, там вообще вся партиция уходит в никуда ... А можно узнать подробности: сам тест-кейс, описание бага, как решали проблему, был ли пачсет? Возникла похожая ситуация - после добавления секции слетел глобальный индекс, не видел новую секцию. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2018, 13:29 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1884230]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
48ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
101ms |
get tp. blocked users: |
1ms |
| others: | 255ms |
| total: | 456ms |

| 0 / 0 |
