Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5      [все]
 Chained rows в вторичных таблицах пространственных индексов  [new]
tim128
Member

Откуда:
Сообщений: 145
Разбирался с большим количеством chained rows в статистике системы, обнаружил что их продуцирует картографический сервер дергая таблицы с пространственными (spatial) индексами. При создании такого индекса создается вторичная (secondary) таблица с именем типа MDRT_32C40$. При построении такого индекса порядка 33% строк оказываются chained. Размер блока 8К, строка такой таблицы содержит два поля number и inline blob. Blob размером всегда 1968 байт. PCTFREE=2 и как поменять его я найти не смог.

Два вопроса:

1. Можно этим таблицам сделать alter table move для ликвидации chained rows или это черевато?

2. Что можно сделать для того чтобы chained rows в таких таблицах не возникали в последствии? Например можно ли изменить PCTFREE такой таблице через ALTER TABLE а не через ALTER INDEX?
9 авг 13, 09:20    [14684893]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Только это migrated а не chained.
9 авг 13, 10:46    [14685450]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
tim128
Member

Откуда:
Сообщений: 145
wurdu
Только это migrated а не chained.


Конечно. Я трактую migrated rows как частный случай chained rows. В статистике отображается количество chained rows fetch. Я анализирую эти фетчи и вижу что данные строки вполне могли бы поместиться в один блок и делаю вывод, что это тот случай, который принято называть "migrated rows". В противном случае стразу можно было смириться.
9 авг 13, 11:16    [14685725]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
xtender
Member

Откуда: Мск
Сообщений: 5749
tim128,

выскажу имхо:
tim128
1. Можно этим таблицам сделать alter table move для ликвидации chained rows или это черевато?
думаю, что можно и ничего страшного, т.к. фактически это же просто как свой indextype c таблицей создать

tim128
2. Что можно сделать для того чтобы chained rows в таких таблицах не возникали в последствии? Например можно ли изменить PCTFREE такой таблице через ALTER TABLE а не через ALTER INDEX?
ну через alter index точно не получится
9 авг 13, 12:03    [14686095]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
tim128
Member

Откуда:
Сообщений: 145
Попробовал alter table move. На свой страх и риск. Индекс сломался. Хорошо ALTER INDEX REBUILD помог.

Попробовал alter table pct_free=10. Но поскольку MOVE не работает чтобы перестроить таблицу приходится запускать ALTER INDEX REBUILD а он опять сбрасывает в pct_free=2.

Может еще идеи будут?
9 авг 13, 14:52    [14687375]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
xtender
Member

Откуда: Мск
Сообщений: 5749
tim128,

sdo_rtr_pctfree?
9 авг 13, 15:36    [14687712]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
Rb-Sr
Member

Откуда:
Сообщений: 296
tim128,

При построении таких индексов можон указывать параметр work_tablespace, весь "временный мусор" во время постоения будет там
9 авг 13, 15:41    [14687754]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
tim128
Member

Откуда:
Сообщений: 145
xtender
tim128,

sdo_rtr_pctfree?


Нет, этот параметр регулирует резерв пространства внутри этого blob-a, который хранится во вторичной таблице.
12 авг 13, 13:26    [14696373]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
tim128
Member

Откуда:
Сообщений: 145
Rb-Sr
tim128,

При построении таких индексов можон указывать параметр work_tablespace, весь "временный мусор" во время постоения будет там


Создадутся таблицы в другом табличном пространстве, но как это повлияет на chained/migrated rows? К тому же work_tablespace судя по доке влияет не на вторичную таблицу с телом индекса, а на другие дополнительные таблички.
12 авг 13, 13:31    [14696409]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
xtender
Member

Откуда: Мск
Сообщений: 5749
tim128,

nfr ghj nj b htxm ;t
12 авг 13, 13:56    [14696638]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
xtender
Member

Откуда: Мск
Сообщений: 5749
tim128
xtender
tim128,

sdo_rtr_pctfree?


Нет, этот параметр регулирует резерв пространства внутри этого blob-a, который хранится во вторичной таблице.
так про то же и речь...
12 авг 13, 13:57    [14696642]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
tim128
Member

Откуда:
Сообщений: 145
xtender,
Нет речь о том что эти блобы размазываются по двум блокам
12 авг 13, 15:38    [14697516]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
tim128
Member

Откуда:
Сообщений: 145
Обратился в техподдержку. Ответили, что легального способа нет, но посоветовали создать DDL триггер на создание таблиц, который подправляет значение PCTFREE. Операция прошла вполне удачно, при значении pctfree=25 все chained_cnt ушли при этом количество blocks даже не изменилось
14 авг 13, 11:58    [14706811]     Ответить | Цитировать Сообщить модератору
 Re: Chained rows в вторичных таблицах пространственных индексов  [new]
sergey.semka
Member

Откуда: Санкт-Петербург
Сообщений: 182
tim128,

Приветствую. С вашего позволения, подниму тему еще раз.
У самого сейчас такая же ситуация...
Но только, видимо, у нас немного критичнее ситуация.
Есть вопрос один - сколько полей в тех таблицах, которые "мигрируют" (или блоки которых сцепляются). На вскидку примерно?...

У меня получается, что количество полей сейчас уже равно 484 штуки на таблицу эту (слава богу, она одна "глючит")...
При этом вот с таким распределением:

Типы полей и их количество в таблице:
COLUMN_DATA_TYPE Count_by_DATA_TYPE
CLOB28
DATE 20
NUMBER 143
VARCHAR2 293
Total Columns:484


Собрал статистику (ручками) по распределению строк в блоках:
Количество блоков на строку Количество строк данного типа
11 090 895
2516 088
3342 930
4186 660
591 100
657 822
727 230
814 976
96 822
10530
11110
Количество строк размещенных в одном блоке на строку: 1 090 895
Количество строк размещенных более чем в одном блоке на строку:1 244 268
Общее количество строк в таблице:2 335 163


При этом окружение следующее:
  • Oracle SE1
  • Windows Server 2008
  • Размер блока табличного пространства: 8Кб
  • Размер блока ОС (RAID-полка): 64Кб

    С PCTFREE баловались месяц-два назад. Увеличили его, таблицу мувили. На какое-то время это помогло, но только частично.
    Сейчас очень интересную статистику иногда база показывает... Как ее трактовать, сложно подумать...
    (точнее SpootLight показывает.): см. приложенный файлик.

    К сообщению приложен файл. Размер - 60Kb
  • 24 сен 13, 13:27    [14877164]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Да, в предыдущем сообщении не видно, но на "логических чтениях" (где красным подсвечено) там надпись идет:
    иногда 10%, а иногда и 1750% of rows fetches "continue" to another block
    При этом сами "логические чтения" при физических чтениях в 6000blks/s не поднимаются выше 12000blks/s
    В среднем "логические чтения" около 50000blks/s колеблются, но часто ругается на rows fetches "continue" to another block
    Максимально "логических чтений" было замечено со скоростью 117000blks/s.

    Кто-то что-то подсказать может?
    Создавать TAbleSpace с размером блока в 16k и туда таблицу мувить, только так?..
    Или что в таких случаях делают?
    (п.с. не предлагать "денормализацию" или "нормализацию" - полей сколько есть, столько есть - это никак не переделаешь...
    Размеры CLOB обычно от 500 байт до 50Кб, не больше. Но обычно не больше 512Кб.
    24 сен 13, 13:36    [14877221]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Версия Oracle SE1 11g R2, если что.
    24 сен 13, 13:37    [14877229]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka
    Да, в предыдущем сообщении не видно, но на "логических чтениях" (где красным подсвечено) там надпись идет:
    иногда 10%, а иногда и 1750% of rows fetches "continue" to another block
    При этом сами "логические чтения" при физических чтениях в 6000blks/s не поднимаются выше 12000blks/s
    В среднем "логические чтения" около 50000blks/s колеблются, но часто ругается на rows fetches "continue" to another block
    Максимально "логических чтений" было замечено со скоростью 117000blks/s.

    Кто-то что-то подсказать может?
    Создавать TAbleSpace с размером блока в 16k и туда таблицу мувить, только так?..
    Или что в таких случаях делают?
    (п.с. не предлагать "денормализацию" или "нормализацию" - полей сколько есть, столько есть - это никак не переделаешь...
    Размеры CLOB обычно от 500 байт до 50Кб, не больше. Но обычно не больше 512Кб.
    Для начала скажи в чем выражается проблема (показания Spotlitght не являются индикатором проблемы).
    24 сен 13, 13:44    [14877285]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu,

    Проблема в том, что производительность упала весьма существенно.
    Как пример, есть 40 штук контекстных индексов (Oracle Text) - которые при генерации активно юзают ввод-вывод + процессор.
    Так вот процессор ОК - не больше чем не 10% загружен. А вот этот самый IO глючит (о чем SpootLight и показывает).
    Не смотря на то, что буферный кэш весьма нормальный для данного объема данных.
    Мы имеем "тормоза".
    Для примера год назад, эти 40 контекстных индексов перестраивались 35 минут. А сейчас перестраиваются почти 7 часов.
    (данных было 1,8 млн, сейчас 2+ млн.) Плотность (заполненность) данных выросла, естественно, процентов на 30. (от чего и блоки "сцепленными" видимо стали). Ну и плюс количество полей: +50 примерно получилось.
    24 сен 13, 14:00    [14877379]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu,
    При всем уважении, просьба не советовать "собрать статистику" - она собирается.
    Не советовать "раскидать данные по другим таблицам" - это невозможно сделать в данной архитектуре.
    И не советовать что-то типа "возьмите запрос ЧЧЧ" и трассировку с него сделайте.
    Смысла в этом нет - тут проблема на уровне "организации данных", "администрирования СУБД", "табличных пространств", ввода-вывода и т.д.

    Проблема уже локализована - страдает логический ввод-вывод. Точнее "логические чтения".
    Вот когда обращения идут исключительно к "горячим блокам" (данным, которые в кэш БД хранятся, мы видим что-то типа как на картинке. При этом там "красное" - это "47% of rows fetches "continue" to another block".

    К сообщению приложен файл. Размер - 32Kb
    24 сен 13, 14:07    [14877418]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Иногда наблюдаются вот такие вот действия:

    К сообщению приложен файл. Размер - 76Kb
    24 сен 13, 14:07    [14877422]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Или вот такие вот:

    К сообщению приложен файл. Размер - 67Kb
    24 сен 13, 14:08    [14877426]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Просто цифры почти в 10000%of rows fetches "continue" to another block,
    думаю, говорят за себя...
    Но это не предел, однако...
    Когда эти самые "rows fetches "continue" to another block" растут - запросы начинают неимоверно тормозить...на определенных выборках данных.

    Куда копать? Что в таких случаях делают?..
    п.с. я понимаю, что буферный кэш спасает частично эту ситуацию, т.к. иначе все в "физические чтения" упиралось бы.
    Но тем не менее, избавляться от этих "continue fetches" нужно ведь.
    Потому что "тормоза" весьма серьезно нарастают в БД.

    К сообщению приложен файл. Размер - 27Kb
    24 сен 13, 14:13    [14877446]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka, я предлагаю не смотреть на показания Spotlight потому что они не несут никакой смысловой нагрузки. Опять же, насколько я вижу, он подменяет Оракловые названия статистик на какие-то самопальные и я могу лишь предположить что за rows fetches "continue" to another block скрывается "table fetch continued row". Переводить проблему из конкретной и понятной в русло "организации данных", "администрирования СУБД", "табличных пространств", ввода-вывода и т.д" я бы не стал. Поэтому предлагаю для начала сделать тесткейс на примере запроса который тормозит и показать по нему трассировку и статистику по "table fetch continued row". Потому как с таким кол-вом колонок проблемы могут быть разного характера. Я описывал уже в свое время одну из них:
    Индекс вместо полного сканирования.
    24 сен 13, 14:53    [14877719]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    Да, и если проблема действительно как тебе кажется носит глобальных характер, то покажи AWR за проблемный период. Но только не Spotlight. Про перестройку индекса пример уже интересный. Просто fullscan по таблице не тормозит?
    24 сен 13, 15:00    [14877768]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu,

    Нету AWR и не будет....
    потому что данный экземпляр "животной фауны" - это Oracle SE1 11g R2...
    Тут нет ни Enterprise manager, ни AWR...
    Максимум это от Spootlight показания и селекты из каки-то системных View.
    (п.с. таблички что в первом посте прислал - это

    А вообще в моем первом посте не ясно что ли, что записи некоторые располагаются на 11 разных блоках(!) вместо одного.
    Уж куда дальше проблему то описывать?..
    Понятно, что тормоза много от чего могут быть. Но тут что "подменяет spootlight" Тоже хотелось бы узнать.
    Вообще он свою среднюю какую-то ведет... сколько было каких чтений и говорит, что за последние 30 секунд выборки на 70 тысяч процентов превышают по показателю Continued fetch то, что было у него "средним значением"... Он тоже не тупой, он калибруются по статистикам из БД постоянно.

    ps: В "чудесную" табличку CHAINED_ROWS (для тех кто знает) попало 1'851'080 из 2'338'804, что соответствует 79,14% всей "проблемной" таблицы.
    24 сен 13, 15:25    [14877935]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu,

    На сколько я знаю, при количестве полей >255 Oracle всегда делает "chaining rows"...
    Только вот они "intra-block" или на несколько блоков - тут уже другой вопрос...
    У нас получается, что количество полей далеко за 255+...
    К тому же дампирование "блоков" по записям показало, что записи располагаются в большинстве случаев на 2, 3, ... , 11 различных блоках, что, как мне кажется уже само говорит о "проблемах".
    Или я ошибаться?
    24 сен 13, 15:33    [14878020]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Что еще касается таблицы нашей. Нашел такие вот данные: "Segment IO" на эту таблицу:
    Total physical I/O Logical readsPhysical readsPhysical read directPhysical writesPhysical write direct
    158'757'881443'413'984133'709'47824'930'354118'0490


    К сообщению приложен файл. Размер - 22Kb
    24 сен 13, 15:42    [14878101]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Если нужны какие-то скрипты прогнать или какую-то еще статистику собрать - скажите, сделаю...
    Просто голова не достаточно квадратная... чтобы решить данную проблему.
    Помогите, если можете кто-нибудь...

    К сообщению приложен файл. Размер - 50Kb
    24 сен 13, 15:45    [14878134]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    И подобная картинка, но уже по Phisical IO/s

    К сообщению приложен файл. Размер - 44Kb
    24 сен 13, 15:47    [14878147]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    И все же у меня подозрение складывается, что вот эти "продолженные чтения"
    пусть даже "логические" и пусть даже из "буфера БД"...
    Очень сильно сказываются на выборки... т.к. база, вероятно, в табличные пространства
    даже в этом случае "бегает", не довольствуясь одним Кэшем...
    Я правильно мыслю?
    (или на обычные селекты она не должна никуда лезть... Где она вообще узнает, на сколько это "свежий блок"?..
    всегда ли Oracle в табличные пространства на "холодные" блоки смотрит? и в Undo-сегмент?...
    Или она по кэшу сразу может "опознать" что блок содержит последние, нужные ей данные и даже за "сцепленными" она по кэшу бегать будет?...
    ВОт мне кажется загвостка тут как раз в работе с кэшем... и что-то мне подсказывает, что на эти "сцепленные блоки"
    он не может нормально из кэша смотреть... а куда-то за каждым "сцепленным" постоянно лазиет...
    толи в табличное пространство само, убедиться, что блок никто не изменил, то ли в Undo...
    Потому что когда затрагиваются "кэшированные" блоки, "не сцепленныых строк" - запросы "летают"...
    А как только "сцепленные строки" задеваются, не смотря на то, что буферный кэш размером с саму таблицу эту главную,
    и даныне весьма часто "поднимаются запросами" - складывается подозрение, что oracle все равно вынужден бегать и смотреть куда-то
    кроме самого кэша...
    Может кто ссылко скинет, почитать, как там дела обстоят... или расскажет?...как Oracle в таком случае работает с кэш, если есть "сцепленные строки" в разных блоках расположенные...
    24 сен 13, 16:12    [14878361]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    sergey.semka,
    Видимо Том Кайт форум не читает, а без него тут никто ничего не может сказать...
    Блин, ну хоть мысли у кого какие есть?
    24 сен 13, 22:14    [14879899]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    sergey.semka,
    Видимо Том Кайт форум не читает, а без него тут никто ничего не может сказать...
    Блин, ну хоть мысли у кого какие есть?
    24 сен 13, 22:20    [14879916]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka
    wurdu,

    На сколько я знаю, при количестве полей >255 Oracle всегда делает "chaining rows"...
    Только вот они "intra-block" или на несколько блоков - тут уже другой вопрос...
    У нас получается, что количество полей далеко за 255+...
    К тому же дампирование "блоков" по записям показало, что записи располагаются в большинстве случаев на 2, 3, ... , 11 различных блоках, что, как мне кажется уже само говорит о "проблемах".
    Или я ошибаться?
    О проблемах может говорить исключительно тесткейс который эту проблему демонстрирует в виде неудовлетворительного времени выполнения. С этим можно работать. Можно анализировать трассировку и статистики. От того что я тебе объясню как работает buffer cache тебе легче не станет.? Можешь просто выполнить select /*+ full(a) */ count(*) from "проблемная таблица" a и показать trace 10046, а также значение статитсики "table fetch continued row" из v$sesstat для этого запроса?
    25 сен 13, 01:32    [14880260]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    dbms_photoshop
    Member

    Откуда: sqlmdx.net
    Сообщений: 5151
    sergey.semka
    И все же у меня подозрение складывается, что вот эти "продолженные чтения"
    пусть даже "логические" и пусть даже из "буфера БД"...
    Очень сильно сказываются на выборки... т.к. база, вероятно, в табличные пространства
    даже в этом случае "бегает", не довольствуясь одним Кэшем...
    Я правильно мыслю?
    (или на обычные селекты она не должна никуда лезть... Где она вообще узнает, на сколько это "свежий блок"?..
    всегда ли Oracle в табличные пространства на "холодные" блоки смотрит? и в Undo-сегмент?...
    Или она по кэшу сразу может "опознать" что блок содержит последние, нужные ей данные и даже за "сцепленными" она по кэшу бегать будет?...
    ВОт мне кажется загвостка тут как раз в работе с кэшем... и что-то мне подсказывает, что на эти "сцепленные блоки"
    он не может нормально из кэша смотреть... а куда-то за каждым "сцепленным" постоянно лазиет...
    толи в табличное пространство само, убедиться, что блок никто не изменил, то ли в Undo...
    Потому что когда затрагиваются "кэшированные" блоки, "не сцепленныых строк" - запросы "летают"...
    А как только "сцепленные строки" задеваются, не смотря на то, что буферный кэш размером с саму таблицу эту главную,
    и даныне весьма часто "поднимаются запросами" - складывается подозрение, что oracle все равно вынужден бегать и смотреть куда-то
    кроме самого кэша...
    Может кто ссылко скинет, почитать, как там дела обстоят... или расскажет?...как Oracle в таком случае работает с кэш, если есть "сцепленные строки" в разных блоках расположенные...
    Жутковатая каша.
    Можешь конкретизировать вопрос что именно непонятно?

    Вкратце, если блок есть в кеше, то Оракл не будет читать его с диска (за исключением багов).
    В общем виде логика описана здесь: http://jonathanlewis.wordpress.com/2009/06/12/consistent-gets-2/
    Более подробно (но мало текста): http://www.juliandyke.com/Presentations/TransactionInternals.ppt
    Для получения согласованной версии может возникнуть необходимость лезть в undo. Работает, учитывая xid, scn, uba.
    Здесь роль играет организация undo. Детали All About Oracle's In-Memory Undo (06-May-2009) PRESENTATION.
    Если интересует, что именно читается для получения согласованной версии - event 10200. Примерно как здесь: 14673064.
    По поводу этого всего можно не особо париться, если допустить, что среда однопользовательская.

    На самом деле можно долго ковыряться, но при таблице с 400+ столбцами проблема, думаю, будет перманентной.
    Единственный банальный "редезайн" сдвинуть колонки с большим процентов null'ов в конец.
    А почему невозможно вертикально разделить таблицу?
    25 сен 13, 02:19    [14880280]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    chain
    Guest
    sergey.semka
    Собрал статистику (ручками) по распределению строк в блоках:
    Каким именно образом?
    25 сен 13, 02:21    [14880281]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    _Nikotin
    Member

    Откуда: СПб
    Сообщений: 2965
    sergey.semka,

    откати статистику на то время когда всё было нормально
    25 сен 13, 02:35    [14880285]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    chain
    Guest
    _Nikotin,

    Сегмент таблицы он к тому времени, без потери данных, к сожалению, "откатить" не сможет.
    25 сен 13, 02:39    [14880287]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Вячеслав Любомудров
    Member

    Откуда: Владивосток
    Сообщений: 18509
    Ну и DDL таблички бы не помешал
    А то там небось до кучи еще и LOB ENABLE STORAGE IN ROW
    25 сен 13, 02:50    [14880292]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    Смысл в том, что нельзя априори считать что проблема с производительностью связана с chainded/migrated rows. Потому как не предоставлено никакой информации подтверждающей это. Если, например, план запроса поехал, то мы увидим возросший LIO, ну и статистики "table fetch continued row" также вырастут. Но это не значит что LIO вырос потому что chained/migrated rows. Да, в случае с migrated/chained rows требуется больше lio при обращении по rowid, а при chained fullscan начинает работать одноблочными чтениями. Но не факт что это создает проблему в данном случае. Если есть конкретный запрос / запросы то надо показать трассировки по ним + планы + статистику по "table fetch continued row" . Если проблема проявляется периодически с проседанием производительнсти, то нужен statspack + планы просевших запросов.
    25 сен 13, 03:07    [14880298]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Вячеслав Любомудров
    Ну и DDL таблички бы не помешал
    А то там небось до кучи еще и LOB ENABLE STORAGE IN ROW

    Ну конечно, они "IN ROW" все...
    Только у них заполняемость разная, какие-то содержат 50 байт информации, какие-то 500 байт, какие-то 4Кб, максимум 50Кб (но это редкость). Часть вообще пустых.
    Просто они все поисковые... и все такое. По этому их выносить "OUT ROW" будет очень "дорого" на запросах, т.к. они постоянно запрашиваются, правятся, в поисковых запросах участвуют.
    25 сен 13, 14:37    [14882699]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    chain
    sergey.semka
    Собрал статистику (ручками) по распределению строк в блоках:
    Каким именно образом?


    Ну "распределение строк по блокам" можно только запросами с "дампированием" блоков, на которых располагается строка делать...
    Эту статистику только ручками можно собрать. Я о ней говорил.
    25 сен 13, 14:38    [14882708]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    _Nikotin
    sergey.semka,

    откати статистику на то время когда всё было нормально


    Статистика всегда собирается новая, автоматически обновляется...
    А то время, когда "все нормально было" - тогда записей было меньше, полей было меньше, а самое главное "заполняемость строк" бала меньше...
    Так что вопрос излишний...
    25 сен 13, 14:39    [14882725]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    [quot dbms_photoshop]
    sergey.semka

    На самом деле можно долго ковыряться, но при таблице с 400+ столбцами проблема, думаю, будет перманентной.
    Единственный банальный "редезайн" сдвинуть колонки с большим процентов null'ов в конец.
    А почему невозможно вертикально разделить таблицу?


    Разрезать таблицу нельзя, т.к. с ней FORMS работает напрямую... И ему не объяснишь, что за вот той кучкой полей сходи туда-то...

    Редизайн по этому не получится...уже говорил об этом.

    По поводу "сдвинуть колонки с большим процентов null'ов в конец" - сложный вопрос. Потому что данные постоянно "доливаются" и "довбиваются"... от этого и происходит и миграция и сцепление...

    Как я понял, тут поможет исключительно перенос в табличное пространство с 16К...

    А за развернутый ответ спасибо.

    п.с. как работает Oracle с обычными блоками я знаю... просто тут такое подозрение возникло, что когда появляются "сцепленные строки" - вот именно за ними (или анализом их состояния) Oracle вынужден еще куда-то лезть...
    Ибо, зная, что данные "горячие" и подняты в кэш - для тех строк, которые "не сцепленны" - все летает... для "сцепленныех" не смотря на то, что все в кэш БД - начинаются какие-то бешенные тормоза... такое ощущение, что Oracle еще куда-то бегает за каждым "сцепленным" блоком строки... Или кэш блокирует постоянно, бегая в поисках этих "сцепленных блоков".
    В самом блоке есть информация, что с ним еще какой-то блок сцеплен и этот "сцепленный блок" тоже находится в буферном кэш, я про это?
    25 сен 13, 14:46    [14882785]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu
    Смысл в том, что нельзя априори считать что проблема с производительностью связана с chainded/migrated rows. Потому как не предоставлено никакой информации подтверждающей это. Если, например, план запроса поехал, то мы увидим возросший LIO, ну и статистики "table fetch continued row" также вырастут. Но это не значит что LIO вырос потому что chained/migrated rows. Да, в случае с migrated/chained rows требуется больше lio при обращении по rowid, а при chained fullscan начинает работать одноблочными чтениями. Но не факт что это создает проблему в данном случае. Если есть конкретный запрос / запросы то надо показать трассировки по ним + планы + статистику по "table fetch continued row" . Если проблема проявляется периодически с проседанием производительнсти, то нужен statspack + планы просевших запросов.


    При всем моем уважении к вам и вашему профессионализму...
    Повторюсь, у меня по распределению в данной таблице имеется как минимум 111 строк, расположенных на 11(!) разных блоках.
    И 500+ тысяч(!) строк, расположенных на 2 блоках... есть еще на 3 разных блоках и т.д.
    Это не означает, что есть "сцепленные строки"?...

    Я прекрасно знаю, что там "говнокод", что там "кривая структура таблиц", "кривыми руками и кривым софтом написанные запросы имеются"... и много-много-много еще прочего.
    Вот все, перечисленное не изменилось... оно еще с версии 8-го Oracle мигрирует из версии в версию...
    И на 11g R2 Standard Edition ONE все "весьма неплохо" работало до последнего времени. И особых проблем не было.
    Проблемы появились когда - появились эти "сцепленные" строки. И я не с потолка это взял. А смотрел Chained_rows, смотрел "продолженные чтения из статистики", ручками "распределение строк по разным блокам" собрал... и прочее...

    И на сколько я могу предполагать, проблема в этих самых "сцепленных" блоках.
    И у меня основной вопрос, что в таком случае делать, и может ли такая проблема снижать производительность, даже учитывая, что больАя часть данных в кэш базы данных поднимается и не сильно то вытесняется оттуда...

    Как-то так. В общем...
    Кто-нибудь вообще боролся с проблемами "сцепленных блоков" и прочим?...
    Об ошибках в ДНК архитекторов, разработчиков и программистов можете не рассказывать... Сам такие имел когда-то. Таблицу нормализовать или резать невозможно. Слишком много на это завязано.
    Задача встала в том, что с этим что-то нужно сделать. Ибо сейчас все это "тормозить стало".
    И вопрос стоит в том, что это дополнительными ресурсами "закрыть" или еще как-то. Вопрос стоит в "Экстенсивном методе развития", хотя это и не правильно.
    25 сен 13, 14:56    [14882882]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Сергей Арсеньев
    Member

    Откуда:
    Сообщений: 4118
    sergey.semka
    Как я понял, тут поможет исключительно перенос в табличное пространство с 16К...


    Не совсем. У Вас подход - напихать много маленьких строк в один блок. А потом при помощи update увеличить их длину. Попкорн. И чем больше пакет, тем больше из него будет вываливаться. При таком подходе вам pctfree в районе 90% нужен.
    25 сен 13, 15:12    [14883037]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    попкорн11
    Guest
    Народ похоже тему не читает... у товарища таблица с 484 столбцами.
    25 сен 13, 15:15    [14883066]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Сергей Арсеньев
    sergey.semka
    Как я понял, тут поможет исключительно перенос в табличное пространство с 16К...


    Не совсем. У Вас подход - напихать много маленьких строк в один блок. А потом при помощи update увеличить их длину. Попкорн. И чем больше пакет, тем больше из него будет вываливаться. При таком подходе вам pctfree в районе 90% нужен.

    Ну не 90... а 75 был сделан... месяца три еще назад =)
    25 сен 13, 15:21    [14883115]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Сергей Арсеньев
    Member

    Откуда:
    Сообщений: 4118
    попкорн11
    Народ похоже тему не читает... у товарища таблица с 484 столбцами.

    Причем с inline lob. По началу null. А потом ...
    И как тут не быть мигрантам и цепочкам.
    25 сен 13, 15:27    [14883162]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Сергей Арсеньев
    Member

    Откуда:
    Сообщений: 4118
    Сергей Арсеньев,

    Хотя конечно ~500 столбцов в одном блоке редко когда могут уместиться. Тут о 64K блоке с PCTFREE 99% задумаешься. :)
    25 сен 13, 15:30    [14883176]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Elic
    Member

    Откуда:
    Сообщений: 30026
    Сергей Арсеньев
    Хотя конечно ~500 столбцов в одном блоке редко когда могут уместиться.
    Никогда. Он знает правильно
    25 сен 13, 15:42    [14883286]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    happytoday
    Member

    Откуда: Днепр
    Сообщений: 239
    sergey.semka
    И подобная картинка, но уже по Phisical IO/s 14878147


    Меня смущает эта картинка.
    Я бы посмотрел alert.log на предмет "Checkpoint not complete"
    25 сен 13, 16:07    [14883478]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Сергей Арсеньев
    Сергей Арсеньев,

    Хотя конечно ~500 столбцов в одном блоке редко когда могут уместиться. Тут о 64K блоке с PCTFREE 99% задумаешься. :)


    Да, только БД не всегда дает возможность выбирать из больших количеств блоков.
    У нас, например, при нашей архитектуре Oracle блоки больше 16К не позволяет создавать.
    Допустимо: 4, 8, 16.
    Больше размер не сделаешь.
    Это касается и буферного кэша db_cache_16k и самого табличного пространства.
    На сколько понял, это от операционки и железа как-то зависит.

    Да у нас в 32К влезло бы все. И сцепленные блоки если полей больше чем 255, как понимаю, всегда образуются. Только вот с PCTFREE и размером блока соответствующего, Oracle мог бы их попытаться складывать в пределах одного блока.

    Ну что же... сейчас будем эксперименты строить с переносом на 16k tablespace...
    25 сен 13, 16:10    [14883491]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    dbms_photoshop
    Member

    Откуда: sqlmdx.net
    Сообщений: 5151
    sergey.semka
    Разрезать таблицу нельзя, т.к. с ней FORMS работает напрямую...
    Почему бы не обернуть вьюхой?
    sergey.semka
    В самом блоке есть информация, что с ним еще какой-то блок сцеплен и этот "сцепленный блок" тоже находится в буферном кэш, я про это?
    Конечно нет. Иначе бы приходилось эту информацию обновлять если б кусок цепочки уходил из кеша.
    При нормальной раобте, если блок есть в кеше, Оракл на диск лезть не будет (undo не рассматриваем).
    + Кеширование - дело тонкое
    create table fact
    partition by range (dt)
       interval ( numtodsinterval(1, 'DAY') )
       (partition empty values less than (to_date('01-01-2001', 'dd.mm.yyyy')))
    as
    select * from big_tbl where dt = date '2012-09-11';
    
    insert into fact select * from big_tbl where dt = date '2012-09-10';
    
    commit;
    
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-10');
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-11');
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-10',date '2012-09-11');
    
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-10');
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-11');
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-10',date '2012-09-11');
    
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-10');
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-11');
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-10',date '2012-09-11');
    
    SQL> select sql_text
      2        ,elapsed_time
      3        ,executions
      4        ,buffer_gets
      5        ,disk_reads
      6    from v$sql
      7   where sql_text like '%tag$%' and not sql_text like '%v$sql%';
    
    SQL_TEXT                                                                                        ELAPSED_TIME EXECUTIONS BUFFER_GETS DISK_READS
    ----------------------------------------------------------------------------------------------- ------------ ---------- ----------- ----------
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-11')                                2353094          3      174253     174388
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-10')                                1574495          3      200634          0
    select /*+ tag$ */ count(*) from fact where dt in (date '2012-09-10',date '2012-09-11')              4853966          3      374727     174278
    
    Как я уже говорил, если интересует что же именно читается, можешь взять особенно "кривую" строку и потрассировать 10200.
    25 сен 13, 16:10    [14883495]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    happytoday
    sergey.semka
    И подобная картинка, но уже по Phisical IO/s 14878147


    Меня смущает эта картинка.
    Я бы посмотрел alert.log на предмет "Checkpoint not complete"


    Эээээ... было-было что-то такое когда-то...

    *Не вот о таком ли речь идет?*

    автор
    25.09.2013 16:00:19 Wed Sep 25 16:00:19 2013
    Thread 1 cannot allocate new log, sequence 18609
    Private strand flush not complete
    Current log# 9 seq# 18608 mem# 0: E:\ORACLE\ORA11\ORCL\REDO09A.LOG
    Current log# 9 seq# 18608 mem# 1: G:\ORACLE\ORA11\ADD_REDO\REDO09B.LOG
    Thread 1 advanced to log sequence 18609 (LGWR switch)
    Current log# 10 seq# 18609 mem# 0: E:\ORACLE\ORA11\ORCL\REDO10A.LOG
    Current log# 10 seq# 18609 mem# 1: G:\ORACLE\ORA11\ADD_REDO\REDO10B.LOG
    25 сен 13, 16:13    [14883515]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Rb-Sr
    Member

    Откуда:
    Сообщений: 296
    sergey.semka
    Вячеслав Любомудров
    Ну и DDL таблички бы не помешал
    А то там небось до кучи еще и LOB ENABLE STORAGE IN ROW

    Ну конечно, они "IN ROW" все...
    Только у них заполняемость разная, какие-то содержат 50 байт информации, какие-то 500 байт, какие-то 4Кб, максимум 50Кб (но это редкость). Часть вообще пустых.
    Просто они все поисковые... и все такое. По этому их выносить "OUT ROW" будет очень "дорого" на запросах, т.к. они постоянно запрашиваются, правятся, в поисковых запросах участвуют.


    + 7.8.11 Does out of line LOB storage of wide base table columns improve performance?
    7.8.11 Does out of line LOB storage of wide base table columns improve performance?

    Answer: Yes. Typically, a SELECT statement selects more than one column from your base table. Because Oracle Text fetches columns to memory, it is more efficient to store wide base table columns such as LOBs out of line, especially when these columns are rarely updated but frequently selected.

    When LOBs are stored out of line, only the LOB locators need to be fetched to memory during querying. Out of line storage reduces the effective size of the base table making it easier for Oracle Text to cache the entire table to memory. This reduces the cost of selecting columns from the base table, and hence speeds up text queries.

    In addition, having smaller base tables cached in memory enables more index table data to be cached during querying, which improves performance.

    может сто́ит попробовать, если есть возможность?
    25 сен 13, 16:14    [14883521]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    happytoday,

    А что в картинке "не так"?...
    Там просто связь с базой по сети рвалась в этот момент (если про "площадку" речь"...)
    Что тут не так, профессор?..
    25 сен 13, 16:15    [14883526]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    happytoday
    sergey.semka
    И подобная картинка, но уже по Phisical IO/s 14878147


    Меня смущает эта картинка.
    Я бы посмотрел alert.log на предмет "Checkpoint not complete"


    В начале месяца, когда были проблемы с UNDO вот такое вот появлялось пару раз, потом UNDO донастроили и все ОК стало.

    автор
    05.09.2013 17:26:41 Thu Sep 05 17:26:41 2013
    Thread 1 cannot allocate new log, sequence 18387
    Checkpoint not complete
    Current log# 1 seq# 18386 mem# 0: E:\ORACLE\ORA11\ORCL\REDO01.LOG
    Thread 1 cannot allocate new log, sequence 18387
    Private strand flush not complete
    Current log# 1 seq# 18386 mem# 0: E:\ORACLE\ORA11\ORCL\REDO01.LOG
    Thread 1 advanced to log sequence 18387 (LGWR switch)
    Current log# 2 seq# 18387 mem# 0: E:\ORACLE\ORA11\ORCL\REDO02.LOG
    25 сен 13, 16:20    [14883552]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    [quot Rb-Sr]
    sergey.semka
    + 7.8.11 Does out of line LOB storage of wide base table columns improve performance?
    7.8.11 Does out of line LOB storage of wide base table columns improve performance?

    Answer: Yes. Typically, a SELECT statement selects more than one column from your base table. Because Oracle Text fetches columns to memory, it is more efficient to store wide base table columns such as LOBs out of line, especially when these columns are rarely updated but frequently selected.

    When LOBs are stored out of line, only the LOB locators need to be fetched to memory during querying. Out of line storage reduces the effective size of the base table making it easier for Oracle Text to cache the entire table to memory. This reduces the cost of selecting columns from the base table, and hence speeds up text queries.

    In addition, having smaller base tables cached in memory enables more index table data to be cached during querying, which improves performance.

    может сто́ит попробовать, если есть возможность?


    В том то и проблема, что эти поля "рабочие", на них в большинстве случаев весит индекс Oracle Text, но по ним идут и SELECT и UPDATE данных...

    Учитывая, что они не слишком уж заполнены и в бОльшей части они не большие, редко где они имеют по 30Кб данных...
    Как мне объяснили - возникнут тормоза при SELECT/UPDATE...

    Тем более, примерно 45% всех строк таблицы размером <=8k (т.е. в один блок помещаются).
    А если взять размер блока 16к, получаем что примерно 90% строк таблицы в блок 16к поместятся.

    OUT ROW LOB, весьма сильные тормоза дает на тестовой базе в нашем случае.
    25 сен 13, 16:30    [14883605]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Rb-Sr
    Member

    Откуда:
    Сообщений: 296
    [quot sergey.semka]
    Rb-Sr
    пропущено...


    А если взять размер блока 16к, получаем что примерно 90% строк таблицы в блок 16к поместятся.
    А последующие за этим возможные ожидания конуренции за блок рассматриваете?

    П.С. Взяли бы да потестили разные варианты в сторонке.
    25 сен 13, 16:34    [14883620]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    happytoday
    Member

    Откуда: Днепр
    Сообщений: 239
    sergey.semka
    happytoday,
    Там просто связь с базой по сети рвалась в этот момент (если про "площадку" речь"...)


    Чем докажете, что связь по сети рвалась))).
    Пинги с сервером проподали?
    На узел зайти нельзя было?
    Если ответ ДА. Дальше можно не читать.

    И часто у Вас связь с базой по сети рвется?

    А может база просто очень занята была почти 15 минут и не хотела общаться.
    25 сен 13, 16:37    [14883644]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    happytoday
    sergey.semka
    happytoday,
    Там просто связь с базой по сети рвалась в этот момент (если про "площадку" речь"...)


    Чем докажете, что связь по сети рвалась))).
    Пинги с сервером проподали?
    На узел зайти нельзя было?
    Если ответ ДА. Дальше можно не читать.

    И часто у Вас связь с базой по сети рвется?

    А может база просто очень занята была почти 15 минут и не хотела общаться.


    База у заказчика стоит... мы ее просто сопровождаем.
    Соответственно Spootlight удаленно туда коннектится...
    Ну глюк со связью был, интернет пропадал тут... вот и связи не было.
    Слава богу база не "кидает" еще так...
    Хотя, глюки бывают...
    25 сен 13, 16:50    [14883722]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    [quot Rb-Sr]
    sergey.semka
    пропущено...
    А последующие за этим возможные ожидания конуренции за блок рассматриваете?

    П.С. Взяли бы да потестили разные варианты в сторонке.


    "Ожидания конкуренции за блок...."
    Звучит красиво... но почему они должны появиться?... Если у нас почти одна строка на один блок будет...
    И вероятность того, что одну и ту же строку будут править два разных пользователя (сессии) минимальна на самом деле.
    Система, конечно, не "одно пользовательская"... там в лучшие времена бывает 150 пользователей.
    Но обычно что-то около 50 пользователей постоянно.
    Только вот, проблема, конечно есть в самом процессе, не скрою...
    Сначала появляются строки новые.... (полупустые)... а затем их начинают "наполнять"...
    Ну для этого PCTFREE и увеличили...
    25 сен 13, 16:54    [14883740]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    happytoday
    Чем докажете, что связь по сети рвалась))).
    Пинги с сервером проподали?
    На узел зайти нельзя было?
    Если ответ ДА. Дальше можно не читать.

    И часто у Вас связь с базой по сети рвется?

    А может база просто очень занята была почти 15 минут и не хотела общаться.


    Ну чем доказать... вот этим пойдет доказательство?
    + ALERT.LOG


    24.09.2013 15:04:05 Tue Sep 24 15:04:05 2013
    Thread 1 cannot allocate new log, sequence 18604
    Private strand flush not complete
    Current log# 10 seq# 18603 mem# 0: E:\ORACLE\ORA11\ORCL\REDO10A.LOG
    Current log# 10 seq# 18603 mem# 1: G:\ORACLE\ORA11\ADD_REDO\REDO10B.LOG
    Thread 1 advanced to log sequence 18604 (LGWR switch)
    Current log# 11 seq# 18604 mem# 0: E:\ORACLE\ORA11\ORCL\REDO11A.LOG
    Current log# 11 seq# 18604 mem# 1: G:\ORACLE\ORA11\ADD_REDO\REDO11B.LOG
    24.09.2013 15:04:54 Tue Sep 24 15:04:54 2013


    ***********************************************************************

    Fatal NI connect error 12170.

    VERSION INFORMATION:
    TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
    Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Time: 24-SEP-2013 15:04:54
    Tracing not turned on.
    Tns error struct:
    ns main err code: 12535

    TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505

    TNS-00505: Operation timed out
    nt secondary err code: 60
    nt OS err code: 0
    Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=xx.xxx.xx.234)(PORT=55165))
    24.09.2013 15:05:14 Tue Sep 24 15:05:14 2013


    ***********************************************************************

    Fatal NI connect error 12170.

    VERSION INFORMATION:
    TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
    Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Time: 24-SEP-2013 15:05:14
    Tracing not turned on.
    Tns error struct:
    ns main err code: 12535

    TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505

    TNS-00505: Operation timed out
    nt secondary err code: 60
    nt OS err code: 0
    Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=xx.xxx.xx.234)(PORT=55205))
    24.09.2013 15:11:46 Tue Sep 24 15:11:46 2013


    ***********************************************************************

    Fatal NI connect error 12170.

    VERSION INFORMATION:
    TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
    Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Time: 24-SEP-2013 15:11:46
    Tracing not turned on.
    Tns error struct:
    ns main err code: 12535

    TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505

    TNS-00505: Operation timed out
    nt secondary err code: 60
    nt OS err code: 0
    Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=xx.xxx.xx.234)(PORT=55763))
    24.09.2013 15:14:41 Tue Sep 24 15:14:41 2013


    ***********************************************************************

    Fatal NI connect error 12170.

    VERSION INFORMATION:
    TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
    Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Time: 24-SEP-2013 15:14:41
    Tracing not turned on.
    Tns error struct:
    ns main err code: 12535

    TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505

    TNS-00505: Operation timed out
    nt secondary err code: 60
    nt OS err code: 0
    Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.35.14)(PORT=55418))
    24.09.2013 15:16:41 Tue Sep 24 15:16:41 2013


    ***********************************************************************

    Fatal NI connect error 12170.

    VERSION INFORMATION:
    TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
    Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Time: 24-SEP-2013 15:16:41
    Tracing not turned on.
    Tns error struct:
    ns main err code: 12535

    TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505

    TNS-00505: Operation timed out
    nt secondary err code: 60
    nt OS err code: 0
    Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=xx.xxx.xx.234)(PORT=55202))
    24.09.2013 15:45:36 Tue Sep 24 15:45:36 2013


    ***********************************************************************

    Fatal NI connect error 12170.
    24.09.2013 15:45:36
    VERSION INFORMATION:
    TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
    Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Time: 24-SEP-2013 15:45:36
    Tracing not turned on.
    Tns error struct:
    ns main err code: 12535

    TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505

    TNS-00505: Operation timed out
    nt secondary err code: 60
    nt OS err code: 0
    Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.35.14)(PORT=49180))
    24.09.2013 15:53:53 Tue Sep 24 15:53:53 2013
    Thread 1 cannot allocate new log, sequence 18605
    Private strand flush not complete
    Current log# 11 seq# 18604 mem# 0: E:\ORACLE\ORA11\ORCL\REDO11A.LOG
    Current log# 11 seq# 18604 mem# 1: G:\ORACLE\ORA11\ADD_REDO\REDO11B.LOG
    Thread 1 advanced to log sequence 18605 (LGWR switch)
    Current log# 12 seq# 18605 mem# 0: E:\ORACLE\ORA11\ORCL\REDO12A.LOG
    Current log# 12 seq# 18605 mem# 1: G:\ORACLE\ORA11\ADD_REDO\REDO12B.LOG

    25 сен 13, 17:00    [14883785]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Конечно, там есть какая-то херь, под названием:
    Thread 1 cannot allocate new log, sequence 18604
    Private strand flush not complete

    которая, напрягает... только так и не смогли понять что это...
    25 сен 13, 17:01    [14883791]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    happytoday
    Member

    Откуда: Днепр
    Сообщений: 239
    sergey.semka
    *Не вот о таком ли речь идет?*

    автор
    25.09.2013 16:00:19 Wed Sep 25 16:00:19 2013
    Thread 1 cannot allocate new log, sequence 18609




    Лично я от этой надписи в alert.log попытался бы избавиться.

    Например вот что пишут:
    http://habrahabr.ru/post/132107/
    http://my-oracle.it-blogs.com.ua/post-181.aspx
    25 сен 13, 17:10    [14883847]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    happytoday
    sergey.semka
    *Не вот о таком ли речь идет?*

    пропущено...


    Лично я от этой надписи в alert.log попытался бы избавиться.

    Например вот что пишут:
    http://habrahabr.ru/post/132107/
    http://my-oracle.it-blogs.com.ua/post-181.aspx


    Благодарю за наводки...
    попробуем избавиться. Просто до этого "избавиться" не получалось...
    (уже размер увеличивали... но что-то все равно никак).
    25 сен 13, 17:21    [14883909]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    happytoday
    Member

    Откуда: Днепр
    Сообщений: 239
    sergey.semka
    24.09.2013 15:04:05 Tue Sep 24 15:04:05 2013
    Thread 1 cannot allocate new log, sequence 18604
    Private strand flush not complete
    Thread 1 advanced to log sequence 18604 (LGWR switch)
    24.09.2013 15:04:54 Tue Sep 24 15:04:54 2013
    24.09.2013 15:53:53 Tue Sep 24 15:53:53 2013
    Thread 1 cannot allocate new log, sequence 18605
    Private strand flush not complete
    Thread 1 advanced to log sequence 18605 (LGWR switch)


    Я думаю все таки база была очень занята и не хотела общаться)))
    14878147
    25 сен 13, 17:25    [14883932]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    В общем проблема в этом есть....
    Но вот "Checkpoint not complete" возникала, когда проблемы были с UNDO... это все решили.
    А сейчас 3 штуки DBWn... + 6 групп REDO весьма большого объема...
    Но все равно проблема
    "Thread 1 cannot allocate new log, sequence 18387
    Private strand flush not complete"

    регулярно возникает при этом рандомно...

    Везде советуют "увеличить REDO", сделать больше групп... и все такое.
    У нас не так интенсивно работа идет. DBWn вообще простаивают большую часть времени... и их 3 штуки...
    ARCn вообще нет (не включены на этой базе архлоги, не спрашивайте почему).

    Но вот рандомно появляется вот эта проблема:
    "Thread 1 cannot allocate new log, sequence 18387
    Private strand flush not complete"


    при этом "Checkpoint not complete" мы не видим! То есть Checkpoint нормально проходит.

    Вот куда копать - уже даже не знаем... на куче ресурсов написано что-то типа "забейте болт на эти строчки в Alert.log", типа это не страшно. Но "ожидания" то какие-то иногда возникают, если он не может "переключит лог", при этом вообще рандомно все.... то каждый час такая хрень, то двое суток без алертов...
    25 сен 13, 17:51    [14884067]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    happytoday
    sergey.semka
    24.09.2013 15:04:05 Tue Sep 24 15:04:05 2013
    Thread 1 cannot allocate new log, sequence 18604
    Private strand flush not complete
    Thread 1 advanced to log sequence 18604 (LGWR switch)
    24.09.2013 15:04:54 Tue Sep 24 15:04:54 2013
    24.09.2013 15:53:53 Tue Sep 24 15:53:53 2013
    Thread 1 cannot allocate new log, sequence 18605
    Private strand flush not complete
    Thread 1 advanced to log sequence 18605 (LGWR switch)


    Я думаю все таки база была очень занята и не хотела общаться)))
    14878147


    А думать там нечего. Я же говорю, что она не была занята и на площадке клиента с ней работали... все прекрасно...
    Это у нас связь рвалась...
    А вот эти строчки из alert.log - см. предыдущее сообщение мое...
    25 сен 13, 17:53    [14884075]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Rb-Sr
    Member

    Откуда:
    Сообщений: 296
    автор
    Private strand flush not complete
    Необязательно является признаком пролемы (ID 372557.1)
    25 сен 13, 18:02    [14884141]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu
    Можешь просто выполнить select /*+ full(a) */ count(*) from "проблемная таблица" a и показать trace 10046, а также значение статистики "table fetch continued row" из v$sesstat для этого запроса?


    Вот, сделал:
    (в приложенном файлике "статистика" из сессии, которую Toad отображает собирая отовсюду...)

    + Trace 10046

    Trace file c:\oracle\ora11\diag\rdbms\ORCL11GR2\ORCL11GR2\trace\ORCL11GR2_ora_5848_SEMKA_SESSION.trc
    Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
    Windows NT Version V6.1 Service Pack 1
    CPU : 24 - type 8664, 12 Physical Cores
    Process Affinity : 0x0x0000000000000000
    Memory (Avail/Total): Ph:11340M/24565M, Ph+PgF:35841M/49129M
    Instance name: ORCL11GR2
    Redo thread mounted by this instance: 1
    Oracle process number: 37
    Windows thread id: 5848, image: ORACLE.EXE (SHAD)


    *** 2013-09-25 20:57:01.917
    *** SESSION ID:(307.3819) 2013-09-25 20:57:01.917
    *** CLIENT ID:() 2013-09-25 20:57:01.917
    *** SERVICE NAME:(SYS$USERS) 2013-09-25 20:57:01.917
    *** MODULE NAME:() 2013-09-25 20:57:01.917
    *** ACTION NAME:() 2013-09-25 20:57:01.917

    WAIT #3: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747315794390

    *** 2013-09-25 20:57:03.212
    WAIT #3: nam='SQL*Net message from client' ela= 1295225 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747317090418
    CLOSE #3:c=0,e=6,dep=0,type=1,tim=747317090497
    =====================
    PARSING IN CURSOR #5 len=56 dep=0 uid=0 oct=42 lid=0 tim=747317090532 hv=1612264059 ad='0' sqlid='g4bcdt9h1kcmv'
    ALTER SESSION SET TRACEFILE_IDENTIFIER = "SEMKA_SESSION"
    END OF STMT
    PARSE #5:c=0,e=6,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=747317090532
    EXEC #5:c=0,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=747317090591
    WAIT #5: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747317090610

    *** 2013-09-25 20:57:04.563
    WAIT #5: nam='SQL*Net message from client' ela= 1350798 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747318441431
    CLOSE #5:c=0,e=2,dep=0,type=3,tim=747318441508
    =====================
    PARSING IN CURSOR #1 len=54 dep=0 uid=0 oct=3 lid=0 tim=747318446320 hv=2769710936 ad='3c225dbe8' sqlid='2jzct6kkjcvus'
    select /*+ full(a) */ count(*) from MYUSER.MYTABLE a
    END OF STMT
    PARSE #1:c=0,e=4785,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=44169924,tim=747318446320
    WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747318446388
    WAIT #1: nam='SQL*Net message from client' ela= 5938 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747318452364
    CLOSE #1:c=0,e=11,dep=0,type=0,tim=747318452438
    =====================
    PARSING IN CURSOR #4 len=54 dep=0 uid=0 oct=3 lid=0 tim=747318452503 hv=2769710936 ad='3c225dbe8' sqlid='2jzct6kkjcvus'
    select /*+ full(a) */ count(*) from MYUSER.MYTABLE a
    END OF STMT
    PARSE #4:c=0,e=36,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=44169924,tim=747318452502
    EXEC #4:c=0,e=24,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=44169924,tim=747318452577
    WAIT #4: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747318452600
    WAIT #4: nam='reliable message' ela= 115 channel context=17195328704 channel handle=17195203448 broadcast message=17159072480 obj#=281 tim=747318453246
    WAIT #4: nam='enq: KO - fast object checkpoint' ela= 547 name|mode=1263468550 2=65573 0=1 obj#=281 tim=747318453854
    WAIT #4: nam='Disk file operations I/O' ela= 87 FileOperation=2 fileno=169 filetype=2 obj#=281 tim=747318454001
    WAIT #4: nam='Disk file operations I/O' ela= 62 FileOperation=2 fileno=15 filetype=2 obj#=145959 tim=747318454152
    WAIT #4: nam='Disk file operations I/O' ela= 60 FileOperation=2 fileno=4 filetype=2 obj#=145959 tim=747318454296
    WAIT #4: nam='direct path read' ela= 9501 file number=15 first dba=626331 block cnt=5 obj#=145959 tim=747318463868
    WAIT #4: nam='direct path read' ela= 9738 file number=15 first dba=755201 block cnt=7 obj#=145959 tim=747318473760
    WAIT #4: nam='direct path read' ela= 1995 file number=4 first dba=393384 block cnt=8 obj#=145959 tim=747318475859
    WAIT #4: nam='direct path read' ela= 6750 file number=15 first dba=755209 block cnt=7 obj#=145959 tim=747318482695
    WAIT #4: nam='direct path read' ela= 9249 file number=4 first dba=473096 block cnt=8 obj#=145959 tim=747318492050
    WAIT #4: nam='direct path read' ela= 6937 file number=15 first dba=755217 block cnt=7 obj#=145959 tim=747318499095
    WAIT #4: nam='direct path read' ela= 282 file number=15 first dba=755225 block cnt=7 obj#=145959 tim=747318499579
    WAIT #4: nam='direct path read' ela= 24825 file number=4 first dba=482400 block cnt=8 obj#=145959 tim=747318524487
    WAIT #4: nam='direct path read' ela= 10595 file number=4 first dba=482424 block cnt=8 obj#=145959 tim=747318535232
    WAIT #4: nam='direct path read' ela= 10513 file number=4 first dba=490112 block cnt=8 obj#=145959 tim=747318545893
    WAIT #4: nam='direct path read' ela= 7668 file number=15 first dba=760833 block cnt=7 obj#=145959 tim=747318553677
    WAIT #4: nam='direct path read' ela= 3660 file number=4 first dba=490128 block cnt=8 obj#=145959 tim=747318557744
    WAIT #4: nam='direct path read' ela= 23321 file number=15 first dba=536322 block cnt=126 obj#=145959 tim=747318581467
    WAIT #4: nam='direct path read' ela= 3964 file number=4 first dba=384258 block cnt=126 obj#=145959 tim=747318585838
    WAIT #4: nam='direct path read' ela= 14231 file number=15 first dba=536450 block cnt=126 obj#=145959 tim=747318600452
    WAIT #4: nam='direct path read' ela= 3365 file number=4 first dba=384386 block cnt=126 obj#=145959 tim=747318604217
    WAIT #4: nam='direct path read' ela= 7462 file number=15 first dba=536578 block cnt=126 obj#=145959 tim=747318612050
    WAIT #4: nam='direct path read' ela= 13823 file number=4 first dba=396674 block cnt=126 obj#=145959 tim=747318626261
    WAIT #4: nam='direct path read' ela= 11881 file number=15 first dba=536706 block cnt=126 obj#=145959 tim=747318638535
    WAIT #4: nam='direct path read' ela= 14846 file number=4 first dba=398082 block cnt=126 obj#=145959 tim=747318653782
    WAIT #4: nam='direct path read' ela= 2198 file number=15 first dba=536834 block cnt=126 obj#=145959 tim=747318656376
    WAIT #4: nam='direct path read' ela= 19137 file number=4 first dba=398466 block cnt=126 obj#=145959 tim=747318675881
    WAIT #4: nam='direct path read' ela= 24106 file number=4 first dba=399362 block cnt=126 obj#=145959 tim=747318700705
    WAIT #4: nam='direct path read' ela= 17084 file number=4 first dba=472066 block cnt=126 obj#=145959 tim=747318718509
    WAIT #4: nam='direct path read' ela= 7572 file number=15 first dba=537218 block cnt=126 obj#=145959 tim=747318726476
    WAIT #4: nam='direct path read' ela= 17724 file number=4 first dba=472322 block cnt=126 obj#=145959 tim=747318744576
    WAIT #4: nam='direct path read' ela= 3734 file number=4 first dba=472578 block cnt=126 obj#=145959 tim=747318749033
    WAIT #4: nam='direct path read' ela= 2005 file number=15 first dba=537474 block cnt=126 obj#=145959 tim=747318751432
    WAIT #4: nam='direct path read' ela= 1343 file number=4 first dba=472706 block cnt=126 obj#=145959 tim=747318753148
    WAIT #4: nam='direct path read' ela= 13039 file number=15 first dba=537602 block cnt=126 obj#=145959 tim=747318766559
    WAIT #4: nam='direct path read' ela= 3743 file number=4 first dba=472962 block cnt=126 obj#=145959 tim=747318770710
    WAIT #4: nam='direct path read' ela= 11439 file number=15 first dba=537730 block cnt=126 obj#=145959 tim=747318782543
    WAIT #4: nam='direct path read' ela= 5780 file number=4 first dba=473218 block cnt=126 obj#=145959 tim=747318788718
    WAIT #4: nam='direct path read' ela= 7184 file number=15 first dba=537858 block cnt=126 obj#=145959 tim=747318796292
    WAIT #4: nam='direct path read' ela= 4111 file number=15 first dba=537986 block cnt=126 obj#=145959 tim=747318801114
    WAIT #4: nam='direct path read' ela= 12291 file number=4 first dba=473474 block cnt=126 obj#=145959 tim=747318813793
    WAIT #4: nam='direct path read' ela= 1181 file number=15 first dba=538114 block cnt=126 obj#=145959 tim=747318815366
    WAIT #4: nam='direct path read' ela= 14543 file number=4 first dba=474114 block cnt=126 obj#=145959 tim=747318830276
    WAIT #4: nam='direct path read' ela= 3396 file number=15 first dba=538242 block cnt=126 obj#=145959 tim=747318834058
    WAIT #4: nam='direct path read' ela= 12998 file number=4 first dba=474370 block cnt=126 obj#=145959 tim=747318847419
    WAIT #4: nam='direct path read' ela= 5375 file number=15 first dba=538370 block cnt=126 obj#=145959 tim=747318853184
    WAIT #4: nam='direct path read' ela= 12445 file number=4 first dba=474626 block cnt=126 obj#=145959 tim=747318865975
    WAIT #4: nam='direct path read' ela= 9460 file number=15 first dba=538498 block cnt=126 obj#=145959 tim=747318875831
    WAIT #4: nam='direct path read' ela= 3767 file number=4 first dba=474754 block cnt=126 obj#=145959 tim=747318880041
    WAIT #4: nam='direct path read' ela= 14993 file number=15 first dba=538626 block cnt=126 obj#=145959 tim=747318895425
    WAIT #4: nam='direct path read' ela= 1426 file number=4 first dba=474882 block cnt=126 obj#=145959 tim=747318897250
    WAIT #4: nam='direct path read' ela= 8944 file number=15 first dba=538754 block cnt=126 obj#=145959 tim=747318906587
    WAIT #4: nam='direct path read' ela= 11740 file number=15 first dba=538882 block cnt=126 obj#=145959 tim=747318919054
    WAIT #4: nam='direct path read' ela= 10826 file number=4 first dba=475266 block cnt=126 obj#=145959 tim=747318930279
    WAIT #4: nam='direct path read' ela= 4114 file number=4 first dba=475394 block cnt=126 obj#=145959 tim=747318935138
    WAIT #4: nam='direct path read' ela= 12200 file number=15 first dba=539138 block cnt=126 obj#=145959 tim=747318947719
    WAIT #4: nam='direct path read' ela= 8530 file number=4 first dba=475522 block cnt=126 obj#=145959 tim=747318956644
    WAIT #4: nam='direct path read' ela= 3964 file number=4 first dba=475650 block cnt=126 obj#=145959 tim=747318961333
    WAIT #4: nam='direct path read' ela= 18764 file number=15 first dba=539394 block cnt=126 obj#=145959 tim=747318980495
    WAIT #4: nam='direct path read' ela= 15834 file number=15 first dba=539522 block cnt=126 obj#=145959 tim=747318997084
    WAIT #4: nam='direct path read' ela= 23114 file number=15 first dba=539650 block cnt=126 obj#=145959 tim=747319021378
    WAIT #4: nam='direct path read' ela= 22390 file number=15 first dba=539778 block cnt=126 obj#=145959 tim=747319044552
    WAIT #4: nam='direct path read' ela= 3148 file number=15 first dba=539906 block cnt=126 obj#=145959 tim=747319048440
    WAIT #4: nam='direct path read' ela= 9714 file number=4 first dba=476290 block cnt=126 obj#=145959 tim=747319058559
    WAIT #4: nam='direct path read' ela= 3516 file number=15 first dba=540034 block cnt=126 obj#=145959 tim=747319062476
    WAIT #4: nam='direct path read' ela= 21891 file number=4 first dba=477570 block cnt=126 obj#=145959 tim=747319084747
    WAIT #4: nam='direct path read' ela= 5393 file number=15 first dba=540162 block cnt=126 obj#=145959 tim=747319090582
    WAIT #4: nam='direct path read' ela= 20037 file number=4 first dba=477698 block cnt=126 obj#=145959 tim=747319111019
    WAIT #4: nam='direct path read' ela= 12762 file number=4 first dba=495748 block cnt=124 obj#=145959 tim=747319124489
    WAIT #4: nam='direct path read' ela= 3277 file number=4 first dba=495872 block cnt=128 obj#=145959 tim=747319128155
    WAIT #4: nam='direct path read' ela= 919 file number=4 first dba=496000 block cnt=128 obj#=145959 tim=747319129463
    WAIT #4: nam='direct path read' ela= 2668 file number=4 first dba=496128 block cnt=128 obj#=145959 tim=747319132514
    WAIT #4: nam='direct path read' ela= 2141 file number=4 first dba=496384 block cnt=128 obj#=145959 tim=747319135364
    WAIT #4: nam='direct path read' ela= 1873 file number=4 first dba=496512 block cnt=128 obj#=145959 tim=747319137615
    WAIT #4: nam='direct path read' ela= 169 file number=4 first dba=496640 block cnt=128 obj#=145959 tim=747319138163
    WAIT #4: nam='direct path read' ela= 1808 file number=15 first dba=540420 block cnt=124 obj#=145959 tim=747319140352
    WAIT #4: nam='direct path read' ela= 15553 file number=15 first dba=540544 block cnt=128 obj#=145959 tim=747319156277
    WAIT #4: nam='direct path read' ela= 2159 file number=15 first dba=540672 block cnt=128 obj#=145959 tim=747319158818
    WAIT #4: nam='direct path read' ela= 6825 file number=15 first dba=540800 block cnt=128 obj#=145959 tim=747319166030
    WAIT #4: nam='direct path read' ela= 1730 file number=15 first dba=540928 block cnt=128 obj#=145959 tim=747319168145
    WAIT #4: nam='direct path read' ela= 4242 file number=15 first dba=541056 block cnt=128 obj#=145959 tim=747319172778
    WAIT #4: nam='direct path read' ela= 2721 file number=15 first dba=541184 block cnt=128 obj#=145959 tim=747319175892
    WAIT #4: nam='direct path read' ela= 1983 file number=15 first dba=541312 block cnt=128 obj#=145959 tim=747319178248
    WAIT #4: nam='direct path read' ela= 11818 file number=4 first dba=496896 block cnt=128 obj#=145959 tim=747319190809
    WAIT #4: nam='direct path read' ela= 2552 file number=4 first dba=497024 block cnt=128 obj#=145959 tim=747319193741
    WAIT #4: nam='direct path read' ela= 1623 file number=4 first dba=497152 block cnt=128 obj#=145959 tim=747319195791
    WAIT #4: nam='direct path read' ela= 3200 file number=4 first dba=497280 block cnt=128 obj#=145959 tim=747319199426
    WAIT #4: nam='direct path read' ela= 4894 file number=4 first dba=497408 block cnt=128 obj#=145959 tim=747319204786
    WAIT #4: nam='direct path read' ela= 2620 file number=4 first dba=497536 block cnt=128 obj#=145959 tim=747319207815
    WAIT #4: nam='direct path read' ela= 1909 file number=15 first dba=541444 block cnt=124 obj#=145959 tim=747319210491
    WAIT #4: nam='direct path read' ela= 2279 file number=15 first dba=541568 block cnt=128 obj#=145959 tim=747319213139
    WAIT #4: nam='direct path read' ela= 2134 file number=15 first dba=541696 block cnt=128 obj#=145959 tim=747319215645
    WAIT #4: nam='direct path read' ela= 13169 file number=15 first dba=541952 block cnt=128 obj#=145959 tim=747319229573
    WAIT #4: nam='direct path read' ela= 7688 file number=15 first dba=542080 block cnt=128 obj#=145959 tim=747319237593
    WAIT #4: nam='direct path read' ela= 1878 file number=15 first dba=542208 block cnt=128 obj#=145959 tim=747319239807
    WAIT #4: nam='direct path read' ela= 1054 file number=15 first dba=542336 block cnt=128 obj#=145959 tim=747319241202
    WAIT #4: nam='direct path read' ela= 24458 file number=4 first dba=502148 block cnt=124 obj#=145959 tim=747319265994
    WAIT #4: nam='direct path read' ela= 2650 file number=4 first dba=502272 block cnt=128 obj#=145959 tim=747319268978
    WAIT #4: nam='direct path read' ela= 2016 file number=4 first dba=502528 block cnt=128 obj#=145959 tim=747319271661
    WAIT #4: nam='direct path read' ela= 1955 file number=4 first dba=502656 block cnt=128 obj#=145959 tim=747319273958
    WAIT #4: nam='direct path read' ela= 269 file number=4 first dba=502784 block cnt=128 obj#=145959 tim=747319274564
    WAIT #4: nam='direct path read' ela= 1691 file number=4 first dba=502912 block cnt=128 obj#=145959 tim=747319276595
    WAIT #4: nam='direct path read' ela= 2104 file number=4 first dba=503040 block cnt=128 obj#=145959 tim=747319279083
    WAIT #4: nam='direct path read' ela= 2407 file number=15 first dba=542592 block cnt=128 obj#=145959 tim=747319282145
    WAIT #4: nam='direct path read' ela= 997 file number=15 first dba=542720 block cnt=128 obj#=145959 tim=747319283482
    WAIT #4: nam='direct path read' ela= 2351 file number=15 first dba=542848 block cnt=128 obj#=145959 tim=747319286163
    WAIT #4: nam='direct path read' ela= 8152 file number=15 first dba=542976 block cnt=128 obj#=145959 tim=747319294643
    WAIT #4: nam='direct path read' ela= 2445 file number=15 first dba=543104 block cnt=128 obj#=145959 tim=747319297418
    WAIT #4: nam='direct path read' ela= 2173 file number=15 first dba=543232 block cnt=128 obj#=145959 tim=747319299922
    WAIT #4: nam='direct path read' ela= 9208 file number=15 first dba=543360 block cnt=128 obj#=145959 tim=747319309459
    WAIT #4: nam='direct path read' ela= 2046 file number=4 first dba=503296 block cnt=128 obj#=145959 tim=747319312138
    WAIT #4: nam='direct path read' ela= 2235 file number=4 first dba=503424 block cnt=128 obj#=145959 tim=747319314698
    WAIT #4: nam='direct path read' ela= 15829 file number=4 first dba=503680 block cnt=128 obj#=145959 tim=747319331174
    WAIT #4: nam='direct path read' ela= 2269 file number=4 first dba=503808 block cnt=128 obj#=145959 tim=747319333739
    WAIT #4: nam='direct path read' ela= 2831 file number=4 first dba=503936 block cnt=128 obj#=145959 tim=747319336865
    WAIT #4: nam='direct path read' ela= 2038 file number=15 first dba=543492 block cnt=124 obj#=145959 tim=747319339454
    WAIT #4: nam='direct path read' ela= 2324 file number=15 first dba=543616 block cnt=128 obj#=145959 tim=747319342102
    WAIT #4: nam='direct path read' ela= 1059 file number=15 first dba=543744 block cnt=128 obj#=145959 tim=747319343461
    WAIT #4: nam='direct path read' ela= 2308 file number=15 first dba=543872 block cnt=128 obj#=145959 tim=747319346061
    WAIT #4: nam='direct path read' ela= 13479 file number=15 first dba=544000 block cnt=128 obj#=145959 tim=747319359832
    WAIT #4: nam='direct path read' ela= 2296 file number=15 first dba=544128 block cnt=128 obj#=145959 tim=747319362423
    WAIT #4: nam='direct path read' ela= 1903 file number=15 first dba=544256 block cnt=128 obj#=145959 tim=747319364617
    WAIT #4: nam='direct path read' ela= 195 file number=15 first dba=544384 block cnt=128 obj#=145959 tim=747319365104
    WAIT #4: nam='direct path read' ela= 1824 file number=4 first dba=504196 block cnt=124 obj#=145959 tim=747319367221
    WAIT #4: nam='direct path read' ela= 1914 file number=4 first dba=504320 block cnt=128 obj#=145959 tim=747319369423
    WAIT #4: nam='direct path read' ela= 416 file number=4 first dba=504448 block cnt=128 obj#=145959 tim=747319370131
    WAIT #4: nam='direct path read' ela= 1615 file number=4 first dba=504576 block cnt=128 obj#=145959 tim=747319372045

    *** 2013-09-25 20:57:05.505
    WAIT #4: nam='direct path read' ela= 10594 file number=4 first dba=504704 block cnt=128 obj#=145959 tim=747319382932


    ----------------ТУТ ВЫРЕЗАН ОГРОМНЫЙ КУСОК ПОДОБНЫХ СТРОК...
    ----------------ТУТ ВЫРЕЗАН ОГРОМНЫЙ КУСОК ПОДОБНЫХ СТРОК...
    ----------------ТУТ ВЫРЕЗАН ОГРОМНЫЙ КУСОК ПОДОБНЫХ СТРОК...
    ----------------ТУТ ВЫРЕЗАН ОГРОМНЫЙ КУСОК ПОДОБНЫХ СТРОК...

    WAIT #4: nam='direct path read' ela= 9185 file number=169 first dba=55168 block cnt=128 obj#=145959 tim=747370463783
    WAIT #4: nam='direct path read' ela= 2488 file number=169 first dba=55296 block cnt=128 obj#=145959 tim=747370466679

    *** 2013-09-25 20:57:56.594
    WAIT #4: nam='direct path read' ela= 1821 file number=169 first dba=55552 block cnt=128 obj#=145959 tim=747370469280
    WAIT #4: nam='direct path read' ela= 1310 file number=169 first dba=55680 block cnt=128 obj#=145959 tim=747370471008
    WAIT #4: nam='direct path read' ela= 2134 file number=169 first dba=55808 block cnt=128 obj#=145959 tim=747370473531
    WAIT #4: nam='direct path read' ela= 1053 file number=169 first dba=55936 block cnt=128 obj#=145959 tim=747370474998
    WAIT #4: nam='direct path read' ela= 1046 file number=169 first dba=56064 block cnt=128 obj#=145959 tim=747370476453
    WAIT #4: nam='direct path read' ela= 2271 file number=169 first dba=56192 block cnt=128 obj#=145959 tim=747370479132
    WAIT #4: nam='direct path read' ela= 2442 file number=169 first dba=56320 block cnt=128 obj#=145959 tim=747370482028
    WAIT #4: nam='direct path read' ela= 1447 file number=169 first dba=56448 block cnt=128 obj#=145959 tim=747370483889
    WAIT #4: nam='direct path read' ela= 634 file number=169 first dba=56576 block cnt=128 obj#=145959 tim=747370484954
    WAIT #4: nam='direct path read' ela= 1426 file number=169 first dba=56704 block cnt=128 obj#=145959 tim=747370486801
    WAIT #4: nam='direct path read' ela= 1979 file number=169 first dba=56832 block cnt=128 obj#=145959 tim=747370489188
    WAIT #4: nam='direct path read' ela= 755 file number=169 first dba=56960 block cnt=128 obj#=145959 tim=747370490349
    WAIT #4: nam='direct path read' ela= 36795 file number=169 first dba=57088 block cnt=128 obj#=145959 tim=747370527544
    WAIT #4: nam='direct path read' ela= 1289 file number=169 first dba=57216 block cnt=128 obj#=145959 tim=747370529234
    WAIT #4: nam='direct path read' ela= 535 file number=169 first dba=57344 block cnt=128 obj#=145959 tim=747370530169
    WAIT #4: nam='direct path read' ela= 1381 file number=169 first dba=57472 block cnt=128 obj#=145959 tim=747370531956
    WAIT #4: nam='direct path read' ela= 2141 file number=169 first dba=57600 block cnt=128 obj#=145959 tim=747370534482
    WAIT #4: nam='direct path read' ela= 731 file number=169 first dba=57728 block cnt=80 obj#=145959 tim=747370535591
    WAIT #4: nam='direct path read' ela= 477 file number=169 first dba=57824 block cnt=48 obj#=145959 tim=747370536334
    WAIT #4: nam='direct path read' ela= 258 file number=169 first dba=57888 block cnt=48 obj#=145959 tim=747370536785
    WAIT #4: nam='direct path read' ela= 16742 file number=169 first dba=57952 block cnt=48 obj#=145959 tim=747370553715
    WAIT #4: nam='direct path read' ela= 867 file number=169 first dba=58080 block cnt=48 obj#=145959 tim=747370554921
    WAIT #4: nam='direct path read' ela= 568 file number=169 first dba=58144 block cnt=48 obj#=145959 tim=747370555678
    WAIT #4: nam='direct path read' ela= 418 file number=169 first dba=58208 block cnt=48 obj#=145959 tim=747370556283
    WAIT #4: nam='direct path read' ela= 404 file number=169 first dba=58272 block cnt=48 obj#=145959 tim=747370556876
    WAIT #4: nam='direct path read' ela= 407 file number=169 first dba=58336 block cnt=48 obj#=145959 tim=747370557474
    WAIT #4: nam='direct path read' ela= 539 file number=169 first dba=58400 block cnt=48 obj#=145959 tim=747370558202
    WAIT #4: nam='direct path read' ela= 398 file number=169 first dba=58464 block cnt=48 obj#=145959 tim=747370558788
    WAIT #4: nam='direct path read' ela= 395 file number=169 first dba=58528 block cnt=48 obj#=145959 tim=747370559370
    WAIT #4: nam='direct path read' ela= 529 file number=169 first dba=58592 block cnt=48 obj#=145959 tim=747370560090
    WAIT #4: nam='direct path read' ela= 769 file number=169 first dba=58656 block cnt=48 obj#=145959 tim=747370561046
    WAIT #4: nam='direct path read' ela= 4610 file number=169 first dba=58720 block cnt=48 obj#=145959 tim=747370565843
    WAIT #4: nam='direct path read' ela= 1387 file number=169 first dba=58784 block cnt=48 obj#=145959 tim=747370567472
    WAIT #4: nam='direct path read' ela= 1176 file number=169 first dba=58896 block cnt=48 obj#=145959 tim=747370568965
    WAIT #4: nam='direct path read' ela= 752 file number=169 first dba=58960 block cnt=48 obj#=145959 tim=747370569906
    WAIT #4: nam='direct path read' ela= 727 file number=169 first dba=59024 block cnt=48 obj#=145959 tim=747370570784
    WAIT #4: nam='direct path read' ela= 1041 file number=169 first dba=59088 block cnt=48 obj#=145959 tim=747370572087
    WAIT #4: nam='direct path read' ela= 1105 file number=169 first dba=59152 block cnt=48 obj#=145959 tim=747370573409
    WAIT #4: nam='direct path read' ela= 786 file number=169 first dba=59216 block cnt=48 obj#=145959 tim=747370574377
    WAIT #4: nam='direct path read' ela= 526 file number=169 first dba=59280 block cnt=48 obj#=145959 tim=747370575083
    WAIT #4: nam='direct path read' ela= 726 file number=169 first dba=59344 block cnt=48 obj#=145959 tim=747370575991
    WAIT #4: nam='direct path read' ela= 1342 file number=169 first dba=59408 block cnt=48 obj#=145959 tim=747370577512
    WAIT #4: nam='direct path read' ela= 390 file number=169 first dba=59488 block cnt=32 obj#=145959 tim=747370578078
    WAIT #4: nam='direct path read' ela= 858 file number=169 first dba=59552 block cnt=32 obj#=145959 tim=747370579079
    WAIT #4: nam='direct path read' ela= 488 file number=169 first dba=59616 block cnt=32 obj#=145959 tim=747370579736
    WAIT #4: nam='direct path read' ela= 1218 file number=169 first dba=59680 block cnt=32 obj#=145959 tim=747370581102
    WAIT #4: nam='direct path read' ela= 1450 file number=169 first dba=59744 block cnt=32 obj#=145959 tim=747370582704
    WAIT #4: nam='direct path read' ela= 230 file number=169 first dba=59808 block cnt=32 obj#=145959 tim=747370583077
    WAIT #4: nam='direct path read' ela= 1195 file number=169 first dba=59872 block cnt=32 obj#=145959 tim=747370584436
    WAIT #4: nam='direct path read' ela= 19093 file number=169 first dba=59904 block cnt=128 obj#=145959 tim=747370603694
    WAIT #4: nam='direct path read' ela= 1813 file number=169 first dba=60160 block cnt=128 obj#=145959 tim=747370606281
    WAIT #4: nam='direct path read' ela= 1960 file number=169 first dba=60288 block cnt=128 obj#=145959 tim=747370608645
    WAIT #4: nam='direct path read' ela= 646 file number=169 first dba=60416 block cnt=128 obj#=145959 tim=747370609702
    WAIT #4: nam='direct path read' ela= 2458 file number=169 first dba=60544 block cnt=128 obj#=145959 tim=747370612569
    WAIT #4: nam='direct path read' ela= 6580 file number=169 first dba=60672 block cnt=128 obj#=145959 tim=747370619551
    WAIT #4: nam='direct path read' ela= 2102 file number=169 first dba=60800 block cnt=128 obj#=145959 tim=747370622008
    FETCH #4:c=6318040,e=52169755,p=2051281,cr=2051318,cu=3,mis=0,r=1,dep=0,og=1,plh=44169924,tim=747370622376
    STAT #4 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=2051318 pr=2051281 pw=0 time=0 us)'
    STAT #4 id=2 cnt=2346507 pid=1 pos=1 obj=145959 op='TABLE ACCESS FULL MYTABLE (cr=2051318 pr=2051281 pw=0 time=48582132 us cost=556753 size=0 card=2333057)'
    WAIT #4: nam='SQL*Net message from client' ela= 8006 driver id=1413697536 #bytes=1 p3=0 obj#=145959 tim=747370630872
    CLOSE #2:c=0,e=6,dep=0,type=3,tim=747370630923
    =====================
    PARSING IN CURSOR #1 len=55 dep=0 uid=0 oct=42 lid=0 tim=747376894069 hv=2217940283 ad='0' sqlid='06nvwn223659v'
    alter session set events '10046 trace name context off'
    END OF STMT
    PARSE #1:c=0,e=84,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=747376894069
    EXEC #1:c=0,e=499,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=747376894621

    25 сен 13, 21:41    [14884746]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    (в приложенном файлике "статистика" из сессии, которую Toad отображает собирая отовсюду...)

    К сообщению приложен файл (SESSION_STATISTIC.xls - 80Kb) cкачать
    25 сен 13, 21:43    [14884748]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka
    wurdu
    Смысл в том, что нельзя априори считать что проблема с производительностью связана с chainded/migrated rows. Потому как не предоставлено никакой информации подтверждающей это. Если, например, план запроса поехал, то мы увидим возросший LIO, ну и статистики "table fetch continued row" также вырастут. Но это не значит что LIO вырос потому что chained/migrated rows. Да, в случае с migrated/chained rows требуется больше lio при обращении по rowid, а при chained fullscan начинает работать одноблочными чтениями. Но не факт что это создает проблему в данном случае. Если есть конкретный запрос / запросы то надо показать трассировки по ним + планы + статистику по "table fetch continued row" . Если проблема проявляется периодически с проседанием производительнсти, то нужен statspack + планы просевших запросов.


    При всем моем уважении к вам и вашему профессионализму...
    Повторюсь, у меня по распределению в данной таблице имеется как минимум 111 строк, расположенных на 11(!) разных блоках.
    И 500+ тысяч(!) строк, расположенных на 2 блоках... есть еще на 3 разных блоках и т.д.
    Это не означает, что есть "сцепленные строки"?...

    Я прекрасно знаю, что там "говнокод", что там "кривая структура таблиц", "кривыми руками и кривым софтом написанные запросы имеются"... и много-много-много еще прочего.
    Вот все, перечисленное не изменилось... оно еще с версии 8-го Oracle мигрирует из версии в версию...
    И на 11g R2 Standard Edition ONE все "весьма неплохо" работало до последнего времени. И особых проблем не было.
    Проблемы появились когда - появились эти "сцепленные" строки. И я не с потолка это взял. А смотрел Chained_rows, смотрел "продолженные чтения из статистики", ручками "распределение строк по разным блокам" собрал... и прочее...

    И на сколько я могу предполагать, проблема в этих самых "сцепленных" блоках.
    И у меня основной вопрос, что в таком случае делать, и может ли такая проблема снижать производительность, даже учитывая, что больАя часть данных в кэш базы данных поднимается и не сильно то вытесняется оттуда...

    Как-то так. В общем...
    Кто-нибудь вообще боролся с проблемами "сцепленных блоков" и прочим?...
    Об ошибках в ДНК архитекторов, разработчиков и программистов можете не рассказывать... Сам такие имел когда-то. Таблицу нормализовать или резать невозможно. Слишком много на это завязано.
    Задача встала в том, что с этим что-то нужно сделать. Ибо сейчас все это "тормозить стало".
    И вопрос стоит в том, что это дополнительными ресурсами "закрыть" или еще как-то. Вопрос стоит в "Экстенсивном методе развития", хотя это и не правильно.
    Я просто пытаюсь направить тебя в конструктивное русло. На данном этапе вобще не важно сцеплены строки или нет и сколько их там. Да хоть все по 100 раз мигрировали. Важно понять причину снижения производительности. Для этого необходимо создать тесткейс который четко воспроизводит проблему. И с этим начинать работать. Ну уберем migrated rows. Проблема не решиться. Опять Spotlight смотреть?
    25 сен 13, 23:53    [14885193]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka
    wurdu
    Можешь просто выполнить select /*+ full(a) */ count(*) from "проблемная таблица" a и показать trace 10046, а также значение статистики "table fetch continued row" из v$sesstat для этого запроса?


    Вот, сделал:
    (в приложенном файлике "статистика" из сессии, которую Toad отображает собирая отовсюду...)

    + Trace 10046

    Trace file c:\oracle\ora11\diag\rdbms\ORCL11GR2\ORCL11GR2\trace\ORCL11GR2_ora_5848_SEMKA_SESSION.trc
    Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
    Windows NT Version V6.1 Service Pack 1
    CPU : 24 - type 8664, 12 Physical Cores
    Process Affinity : 0x0x0000000000000000
    Memory (Avail/Total): Ph:11340M/24565M, Ph+PgF:35841M/49129M
    Instance name: ORCL11GR2
    Redo thread mounted by this instance: 1
    Oracle process number: 37
    Windows thread id: 5848, image: ORACLE.EXE (SHAD)


    *** 2013-09-25 20:57:01.917
    *** SESSION ID:(307.3819) 2013-09-25 20:57:01.917
    *** CLIENT ID:() 2013-09-25 20:57:01.917
    *** SERVICE NAME:(SYS$USERS) 2013-09-25 20:57:01.917
    *** MODULE NAME:() 2013-09-25 20:57:01.917
    *** ACTION NAME:() 2013-09-25 20:57:01.917

    WAIT #3: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747315794390

    *** 2013-09-25 20:57:03.212
    WAIT #3: nam='SQL*Net message from client' ela= 1295225 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747317090418
    CLOSE #3:c=0,e=6,dep=0,type=1,tim=747317090497
    =====================
    PARSING IN CURSOR #5 len=56 dep=0 uid=0 oct=42 lid=0 tim=747317090532 hv=1612264059 ad='0' sqlid='g4bcdt9h1kcmv'
    ALTER SESSION SET TRACEFILE_IDENTIFIER = "SEMKA_SESSION"
    END OF STMT
    PARSE #5:c=0,e=6,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=747317090532
    EXEC #5:c=0,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=747317090591
    WAIT #5: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747317090610

    *** 2013-09-25 20:57:04.563
    WAIT #5: nam='SQL*Net message from client' ela= 1350798 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747318441431
    CLOSE #5:c=0,e=2,dep=0,type=3,tim=747318441508
    =====================
    PARSING IN CURSOR #1 len=54 dep=0 uid=0 oct=3 lid=0 tim=747318446320 hv=2769710936 ad='3c225dbe8' sqlid='2jzct6kkjcvus'
    select /*+ full(a) */ count(*) from MYUSER.MYTABLE a
    END OF STMT
    PARSE #1:c=0,e=4785,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=44169924,tim=747318446320
    WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747318446388
    WAIT #1: nam='SQL*Net message from client' ela= 5938 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747318452364
    CLOSE #1:c=0,e=11,dep=0,type=0,tim=747318452438
    =====================
    PARSING IN CURSOR #4 len=54 dep=0 uid=0 oct=3 lid=0 tim=747318452503 hv=2769710936 ad='3c225dbe8' sqlid='2jzct6kkjcvus'
    select /*+ full(a) */ count(*) from MYUSER.MYTABLE a
    END OF STMT
    PARSE #4:c=0,e=36,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=44169924,tim=747318452502
    EXEC #4:c=0,e=24,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=44169924,tim=747318452577
    WAIT #4: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=281 tim=747318452600
    WAIT #4: nam='reliable message' ela= 115 channel context=17195328704 channel handle=17195203448 broadcast message=17159072480 obj#=281 tim=747318453246
    WAIT #4: nam='enq: KO - fast object checkpoint' ela= 547 name|mode=1263468550 2=65573 0=1 obj#=281 tim=747318453854
    WAIT #4: nam='Disk file operations I/O' ela= 87 FileOperation=2 fileno=169 filetype=2 obj#=281 tim=747318454001
    WAIT #4: nam='Disk file operations I/O' ela= 62 FileOperation=2 fileno=15 filetype=2 obj#=145959 tim=747318454152
    WAIT #4: nam='Disk file operations I/O' ela= 60 FileOperation=2 fileno=4 filetype=2 obj#=145959 tim=747318454296
    WAIT #4: nam='direct path read' ela= 9501 file number=15 first dba=626331 block cnt=5 obj#=145959 tim=747318463868
    WAIT #4: nam='direct path read' ela= 9738 file number=15 first dba=755201 block cnt=7 obj#=145959 tim=747318473760
    WAIT #4: nam='direct path read' ela= 1995 file number=4 first dba=393384 block cnt=8 obj#=145959 tim=747318475859
    WAIT #4: nam='direct path read' ela= 6750 file number=15 first dba=755209 block cnt=7 obj#=145959 tim=747318482695
    WAIT #4: nam='direct path read' ela= 9249 file number=4 first dba=473096 block cnt=8 obj#=145959 tim=747318492050
    WAIT #4: nam='direct path read' ela= 6937 file number=15 first dba=755217 block cnt=7 obj#=145959 tim=747318499095
    WAIT #4: nam='direct path read' ela= 282 file number=15 first dba=755225 block cnt=7 obj#=145959 tim=747318499579
    WAIT #4: nam='direct path read' ela= 24825 file number=4 first dba=482400 block cnt=8 obj#=145959 tim=747318524487
    WAIT #4: nam='direct path read' ela= 10595 file number=4 first dba=482424 block cnt=8 obj#=145959 tim=747318535232
    WAIT #4: nam='direct path read' ela= 10513 file number=4 first dba=490112 block cnt=8 obj#=145959 tim=747318545893
    WAIT #4: nam='direct path read' ela= 7668 file number=15 first dba=760833 block cnt=7 obj#=145959 tim=747318553677
    WAIT #4: nam='direct path read' ela= 3660 file number=4 first dba=490128 block cnt=8 obj#=145959 tim=747318557744
    WAIT #4: nam='direct path read' ela= 23321 file number=15 first dba=536322 block cnt=126 obj#=145959 tim=747318581467
    WAIT #4: nam='direct path read' ela= 3964 file number=4 first dba=384258 block cnt=126 obj#=145959 tim=747318585838
    WAIT #4: nam='direct path read' ela= 14231 file number=15 first dba=536450 block cnt=126 obj#=145959 tim=747318600452
    WAIT #4: nam='direct path read' ela= 3365 file number=4 first dba=384386 block cnt=126 obj#=145959 tim=747318604217
    WAIT #4: nam='direct path read' ela= 7462 file number=15 first dba=536578 block cnt=126 obj#=145959 tim=747318612050
    WAIT #4: nam='direct path read' ela= 13823 file number=4 first dba=396674 block cnt=126 obj#=145959 tim=747318626261
    WAIT #4: nam='direct path read' ela= 11881 file number=15 first dba=536706 block cnt=126 obj#=145959 tim=747318638535
    WAIT #4: nam='direct path read' ela= 14846 file number=4 first dba=398082 block cnt=126 obj#=145959 tim=747318653782
    WAIT #4: nam='direct path read' ela= 2198 file number=15 first dba=536834 block cnt=126 obj#=145959 tim=747318656376
    WAIT #4: nam='direct path read' ela= 19137 file number=4 first dba=398466 block cnt=126 obj#=145959 tim=747318675881
    WAIT #4: nam='direct path read' ela= 24106 file number=4 first dba=399362 block cnt=126 obj#=145959 tim=747318700705
    WAIT #4: nam='direct path read' ela= 17084 file number=4 first dba=472066 block cnt=126 obj#=145959 tim=747318718509
    WAIT #4: nam='direct path read' ela= 7572 file number=15 first dba=537218 block cnt=126 obj#=145959 tim=747318726476
    WAIT #4: nam='direct path read' ela= 17724 file number=4 first dba=472322 block cnt=126 obj#=145959 tim=747318744576
    WAIT #4: nam='direct path read' ela= 3734 file number=4 first dba=472578 block cnt=126 obj#=145959 tim=747318749033
    WAIT #4: nam='direct path read' ela= 2005 file number=15 first dba=537474 block cnt=126 obj#=145959 tim=747318751432
    WAIT #4: nam='direct path read' ela= 1343 file number=4 first dba=472706 block cnt=126 obj#=145959 tim=747318753148
    WAIT #4: nam='direct path read' ela= 13039 file number=15 first dba=537602 block cnt=126 obj#=145959 tim=747318766559
    WAIT #4: nam='direct path read' ela= 3743 file number=4 first dba=472962 block cnt=126 obj#=145959 tim=747318770710
    WAIT #4: nam='direct path read' ela= 11439 file number=15 first dba=537730 block cnt=126 obj#=145959 tim=747318782543
    WAIT #4: nam='direct path read' ela= 5780 file number=4 first dba=473218 block cnt=126 obj#=145959 tim=747318788718
    WAIT #4: nam='direct path read' ela= 7184 file number=15 first dba=537858 block cnt=126 obj#=145959 tim=747318796292
    WAIT #4: nam='direct path read' ela= 4111 file number=15 first dba=537986 block cnt=126 obj#=145959 tim=747318801114
    WAIT #4: nam='direct path read' ela= 12291 file number=4 first dba=473474 block cnt=126 obj#=145959 tim=747318813793
    WAIT #4: nam='direct path read' ela= 1181 file number=15 first dba=538114 block cnt=126 obj#=145959 tim=747318815366
    WAIT #4: nam='direct path read' ela= 14543 file number=4 first dba=474114 block cnt=126 obj#=145959 tim=747318830276
    WAIT #4: nam='direct path read' ela= 3396 file number=15 first dba=538242 block cnt=126 obj#=145959 tim=747318834058
    WAIT #4: nam='direct path read' ela= 12998 file number=4 first dba=474370 block cnt=126 obj#=145959 tim=747318847419
    WAIT #4: nam='direct path read' ela= 5375 file number=15 first dba=538370 block cnt=126 obj#=145959 tim=747318853184
    WAIT #4: nam='direct path read' ela= 12445 file number=4 first dba=474626 block cnt=126 obj#=145959 tim=747318865975
    WAIT #4: nam='direct path read' ela= 9460 file number=15 first dba=538498 block cnt=126 obj#=145959 tim=747318875831
    WAIT #4: nam='direct path read' ela= 3767 file number=4 first dba=474754 block cnt=126 obj#=145959 tim=747318880041
    WAIT #4: nam='direct path read' ela= 14993 file number=15 first dba=538626 block cnt=126 obj#=145959 tim=747318895425
    WAIT #4: nam='direct path read' ela= 1426 file number=4 first dba=474882 block cnt=126 obj#=145959 tim=747318897250
    WAIT #4: nam='direct path read' ela= 8944 file number=15 first dba=538754 block cnt=126 obj#=145959 tim=747318906587
    WAIT #4: nam='direct path read' ela= 11740 file number=15 first dba=538882 block cnt=126 obj#=145959 tim=747318919054
    WAIT #4: nam='direct path read' ela= 10826 file number=4 first dba=475266 block cnt=126 obj#=145959 tim=747318930279
    WAIT #4: nam='direct path read' ela= 4114 file number=4 first dba=475394 block cnt=126 obj#=145959 tim=747318935138
    WAIT #4: nam='direct path read' ela= 12200 file number=15 first dba=539138 block cnt=126 obj#=145959 tim=747318947719
    WAIT #4: nam='direct path read' ela= 8530 file number=4 first dba=475522 block cnt=126 obj#=145959 tim=747318956644
    WAIT #4: nam='direct path read' ela= 3964 file number=4 first dba=475650 block cnt=126 obj#=145959 tim=747318961333
    WAIT #4: nam='direct path read' ela= 18764 file number=15 first dba=539394 block cnt=126 obj#=145959 tim=747318980495
    WAIT #4: nam='direct path read' ela= 15834 file number=15 first dba=539522 block cnt=126 obj#=145959 tim=747318997084
    WAIT #4: nam='direct path read' ela= 23114 file number=15 first dba=539650 block cnt=126 obj#=145959 tim=747319021378
    WAIT #4: nam='direct path read' ela= 22390 file number=15 first dba=539778 block cnt=126 obj#=145959 tim=747319044552
    WAIT #4: nam='direct path read' ela= 3148 file number=15 first dba=539906 block cnt=126 obj#=145959 tim=747319048440
    WAIT #4: nam='direct path read' ela= 9714 file number=4 first dba=476290 block cnt=126 obj#=145959 tim=747319058559
    WAIT #4: nam='direct path read' ela= 3516 file number=15 first dba=540034 block cnt=126 obj#=145959 tim=747319062476
    WAIT #4: nam='direct path read' ela= 21891 file number=4 first dba=477570 block cnt=126 obj#=145959 tim=747319084747
    WAIT #4: nam='direct path read' ela= 5393 file number=15 first dba=540162 block cnt=126 obj#=145959 tim=747319090582
    WAIT #4: nam='direct path read' ela= 20037 file number=4 first dba=477698 block cnt=126 obj#=145959 tim=747319111019
    WAIT #4: nam='direct path read' ela= 12762 file number=4 first dba=495748 block cnt=124 obj#=145959 tim=747319124489
    WAIT #4: nam='direct path read' ela= 3277 file number=4 first dba=495872 block cnt=128 obj#=145959 tim=747319128155
    WAIT #4: nam='direct path read' ela= 919 file number=4 first dba=496000 block cnt=128 obj#=145959 tim=747319129463
    WAIT #4: nam='direct path read' ela= 2668 file number=4 first dba=496128 block cnt=128 obj#=145959 tim=747319132514
    WAIT #4: nam='direct path read' ela= 2141 file number=4 first dba=496384 block cnt=128 obj#=145959 tim=747319135364
    WAIT #4: nam='direct path read' ela= 1873 file number=4 first dba=496512 block cnt=128 obj#=145959 tim=747319137615
    WAIT #4: nam='direct path read' ela= 169 file number=4 first dba=496640 block cnt=128 obj#=145959 tim=747319138163
    WAIT #4: nam='direct path read' ela= 1808 file number=15 first dba=540420 block cnt=124 obj#=145959 tim=747319140352
    WAIT #4: nam='direct path read' ela= 15553 file number=15 first dba=540544 block cnt=128 obj#=145959 tim=747319156277
    WAIT #4: nam='direct path read' ela= 2159 file number=15 first dba=540672 block cnt=128 obj#=145959 tim=747319158818
    WAIT #4: nam='direct path read' ela= 6825 file number=15 first dba=540800 block cnt=128 obj#=145959 tim=747319166030
    WAIT #4: nam='direct path read' ela= 1730 file number=15 first dba=540928 block cnt=128 obj#=145959 tim=747319168145
    WAIT #4: nam='direct path read' ela= 4242 file number=15 first dba=541056 block cnt=128 obj#=145959 tim=747319172778
    WAIT #4: nam='direct path read' ela= 2721 file number=15 first dba=541184 block cnt=128 obj#=145959 tim=747319175892
    WAIT #4: nam='direct path read' ela= 1983 file number=15 first dba=541312 block cnt=128 obj#=145959 tim=747319178248
    WAIT #4: nam='direct path read' ela= 11818 file number=4 first dba=496896 block cnt=128 obj#=145959 tim=747319190809
    WAIT #4: nam='direct path read' ela= 2552 file number=4 first dba=497024 block cnt=128 obj#=145959 tim=747319193741
    WAIT #4: nam='direct path read' ela= 1623 file number=4 first dba=497152 block cnt=128 obj#=145959 tim=747319195791
    WAIT #4: nam='direct path read' ela= 3200 file number=4 first dba=497280 block cnt=128 obj#=145959 tim=747319199426
    WAIT #4: nam='direct path read' ela= 4894 file number=4 first dba=497408 block cnt=128 obj#=145959 tim=747319204786
    WAIT #4: nam='direct path read' ela= 2620 file number=4 first dba=497536 block cnt=128 obj#=145959 tim=747319207815
    WAIT #4: nam='direct path read' ela= 1909 file number=15 first dba=541444 block cnt=124 obj#=145959 tim=747319210491
    WAIT #4: nam='direct path read' ela= 2279 file number=15 first dba=541568 block cnt=128 obj#=145959 tim=747319213139
    WAIT #4: nam='direct path read' ela= 2134 file number=15 first dba=541696 block cnt=128 obj#=145959 tim=747319215645
    WAIT #4: nam='direct path read' ela= 13169 file number=15 first dba=541952 block cnt=128 obj#=145959 tim=747319229573
    WAIT #4: nam='direct path read' ela= 7688 file number=15 first dba=542080 block cnt=128 obj#=145959 tim=747319237593
    WAIT #4: nam='direct path read' ela= 1878 file number=15 first dba=542208 block cnt=128 obj#=145959 tim=747319239807
    WAIT #4: nam='direct path read' ela= 1054 file number=15 first dba=542336 block cnt=128 obj#=145959 tim=747319241202
    WAIT #4: nam='direct path read' ela= 24458 file number=4 first dba=502148 block cnt=124 obj#=145959 tim=747319265994
    WAIT #4: nam='direct path read' ela= 2650 file number=4 first dba=502272 block cnt=128 obj#=145959 tim=747319268978
    WAIT #4: nam='direct path read' ela= 2016 file number=4 first dba=502528 block cnt=128 obj#=145959 tim=747319271661
    WAIT #4: nam='direct path read' ela= 1955 file number=4 first dba=502656 block cnt=128 obj#=145959 tim=747319273958
    WAIT #4: nam='direct path read' ela= 269 file number=4 first dba=502784 block cnt=128 obj#=145959 tim=747319274564
    WAIT #4: nam='direct path read' ela= 1691 file number=4 first dba=502912 block cnt=128 obj#=145959 tim=747319276595
    WAIT #4: nam='direct path read' ela= 2104 file number=4 first dba=503040 block cnt=128 obj#=145959 tim=747319279083
    WAIT #4: nam='direct path read' ela= 2407 file number=15 first dba=542592 block cnt=128 obj#=145959 tim=747319282145
    WAIT #4: nam='direct path read' ela= 997 file number=15 first dba=542720 block cnt=128 obj#=145959 tim=747319283482
    WAIT #4: nam='direct path read' ela= 2351 file number=15 first dba=542848 block cnt=128 obj#=145959 tim=747319286163
    WAIT #4: nam='direct path read' ela= 8152 file number=15 first dba=542976 block cnt=128 obj#=145959 tim=747319294643
    WAIT #4: nam='direct path read' ela= 2445 file number=15 first dba=543104 block cnt=128 obj#=145959 tim=747319297418
    WAIT #4: nam='direct path read' ela= 2173 file number=15 first dba=543232 block cnt=128 obj#=145959 tim=747319299922
    WAIT #4: nam='direct path read' ela= 9208 file number=15 first dba=543360 block cnt=128 obj#=145959 tim=747319309459
    WAIT #4: nam='direct path read' ela= 2046 file number=4 first dba=503296 block cnt=128 obj#=145959 tim=747319312138
    WAIT #4: nam='direct path read' ela= 2235 file number=4 first dba=503424 block cnt=128 obj#=145959 tim=747319314698
    WAIT #4: nam='direct path read' ela= 15829 file number=4 first dba=503680 block cnt=128 obj#=145959 tim=747319331174
    WAIT #4: nam='direct path read' ela= 2269 file number=4 first dba=503808 block cnt=128 obj#=145959 tim=747319333739
    WAIT #4: nam='direct path read' ela= 2831 file number=4 first dba=503936 block cnt=128 obj#=145959 tim=747319336865
    WAIT #4: nam='direct path read' ela= 2038 file number=15 first dba=543492 block cnt=124 obj#=145959 tim=747319339454
    WAIT #4: nam='direct path read' ela= 2324 file number=15 first dba=543616 block cnt=128 obj#=145959 tim=747319342102
    WAIT #4: nam='direct path read' ela= 1059 file number=15 first dba=543744 block cnt=128 obj#=145959 tim=747319343461
    WAIT #4: nam='direct path read' ela= 2308 file number=15 first dba=543872 block cnt=128 obj#=145959 tim=747319346061
    WAIT #4: nam='direct path read' ela= 13479 file number=15 first dba=544000 block cnt=128 obj#=145959 tim=747319359832
    WAIT #4: nam='direct path read' ela= 2296 file number=15 first dba=544128 block cnt=128 obj#=145959 tim=747319362423
    WAIT #4: nam='direct path read' ela= 1903 file number=15 first dba=544256 block cnt=128 obj#=145959 tim=747319364617
    WAIT #4: nam='direct path read' ela= 195 file number=15 first dba=544384 block cnt=128 obj#=145959 tim=747319365104
    WAIT #4: nam='direct path read' ela= 1824 file number=4 first dba=504196 block cnt=124 obj#=145959 tim=747319367221
    WAIT #4: nam='direct path read' ela= 1914 file number=4 first dba=504320 block cnt=128 obj#=145959 tim=747319369423
    WAIT #4: nam='direct path read' ela= 416 file number=4 first dba=504448 block cnt=128 obj#=145959 tim=747319370131
    WAIT #4: nam='direct path read' ela= 1615 file number=4 first dba=504576 block cnt=128 obj#=145959 tim=747319372045

    *** 2013-09-25 20:57:05.505
    WAIT #4: nam='direct path read' ela= 10594 file number=4 first dba=504704 block cnt=128 obj#=145959 tim=747319382932


    ----------------ТУТ ВЫРЕЗАН ОГРОМНЫЙ КУСОК ПОДОБНЫХ СТРОК...
    ----------------ТУТ ВЫРЕЗАН ОГРОМНЫЙ КУСОК ПОДОБНЫХ СТРОК...
    ----------------ТУТ ВЫРЕЗАН ОГРОМНЫЙ КУСОК ПОДОБНЫХ СТРОК...
    ----------------ТУТ ВЫРЕЗАН ОГРОМНЫЙ КУСОК ПОДОБНЫХ СТРОК...

    WAIT #4: nam='direct path read' ela= 9185 file number=169 first dba=55168 block cnt=128 obj#=145959 tim=747370463783
    WAIT #4: nam='direct path read' ela= 2488 file number=169 first dba=55296 block cnt=128 obj#=145959 tim=747370466679

    *** 2013-09-25 20:57:56.594
    WAIT #4: nam='direct path read' ela= 1821 file number=169 first dba=55552 block cnt=128 obj#=145959 tim=747370469280
    WAIT #4: nam='direct path read' ela= 1310 file number=169 first dba=55680 block cnt=128 obj#=145959 tim=747370471008
    WAIT #4: nam='direct path read' ela= 2134 file number=169 first dba=55808 block cnt=128 obj#=145959 tim=747370473531
    WAIT #4: nam='direct path read' ela= 1053 file number=169 first dba=55936 block cnt=128 obj#=145959 tim=747370474998
    WAIT #4: nam='direct path read' ela= 1046 file number=169 first dba=56064 block cnt=128 obj#=145959 tim=747370476453
    WAIT #4: nam='direct path read' ela= 2271 file number=169 first dba=56192 block cnt=128 obj#=145959 tim=747370479132
    WAIT #4: nam='direct path read' ela= 2442 file number=169 first dba=56320 block cnt=128 obj#=145959 tim=747370482028
    WAIT #4: nam='direct path read' ela= 1447 file number=169 first dba=56448 block cnt=128 obj#=145959 tim=747370483889
    WAIT #4: nam='direct path read' ela= 634 file number=169 first dba=56576 block cnt=128 obj#=145959 tim=747370484954
    WAIT #4: nam='direct path read' ela= 1426 file number=169 first dba=56704 block cnt=128 obj#=145959 tim=747370486801
    WAIT #4: nam='direct path read' ela= 1979 file number=169 first dba=56832 block cnt=128 obj#=145959 tim=747370489188
    WAIT #4: nam='direct path read' ela= 755 file number=169 first dba=56960 block cnt=128 obj#=145959 tim=747370490349
    WAIT #4: nam='direct path read' ela= 36795 file number=169 first dba=57088 block cnt=128 obj#=145959 tim=747370527544
    WAIT #4: nam='direct path read' ela= 1289 file number=169 first dba=57216 block cnt=128 obj#=145959 tim=747370529234
    WAIT #4: nam='direct path read' ela= 535 file number=169 first dba=57344 block cnt=128 obj#=145959 tim=747370530169
    WAIT #4: nam='direct path read' ela= 1381 file number=169 first dba=57472 block cnt=128 obj#=145959 tim=747370531956
    WAIT #4: nam='direct path read' ela= 2141 file number=169 first dba=57600 block cnt=128 obj#=145959 tim=747370534482
    WAIT #4: nam='direct path read' ela= 731 file number=169 first dba=57728 block cnt=80 obj#=145959 tim=747370535591
    WAIT #4: nam='direct path read' ela= 477 file number=169 first dba=57824 block cnt=48 obj#=145959 tim=747370536334
    WAIT #4: nam='direct path read' ela= 258 file number=169 first dba=57888 block cnt=48 obj#=145959 tim=747370536785
    WAIT #4: nam='direct path read' ela= 16742 file number=169 first dba=57952 block cnt=48 obj#=145959 tim=747370553715
    WAIT #4: nam='direct path read' ela= 867 file number=169 first dba=58080 block cnt=48 obj#=145959 tim=747370554921
    WAIT #4: nam='direct path read' ela= 568 file number=169 first dba=58144 block cnt=48 obj#=145959 tim=747370555678
    WAIT #4: nam='direct path read' ela= 418 file number=169 first dba=58208 block cnt=48 obj#=145959 tim=747370556283
    WAIT #4: nam='direct path read' ela= 404 file number=169 first dba=58272 block cnt=48 obj#=145959 tim=747370556876
    WAIT #4: nam='direct path read' ela= 407 file number=169 first dba=58336 block cnt=48 obj#=145959 tim=747370557474
    WAIT #4: nam='direct path read' ela= 539 file number=169 first dba=58400 block cnt=48 obj#=145959 tim=747370558202
    WAIT #4: nam='direct path read' ela= 398 file number=169 first dba=58464 block cnt=48 obj#=145959 tim=747370558788
    WAIT #4: nam='direct path read' ela= 395 file number=169 first dba=58528 block cnt=48 obj#=145959 tim=747370559370
    WAIT #4: nam='direct path read' ela= 529 file number=169 first dba=58592 block cnt=48 obj#=145959 tim=747370560090
    WAIT #4: nam='direct path read' ela= 769 file number=169 first dba=58656 block cnt=48 obj#=145959 tim=747370561046
    WAIT #4: nam='direct path read' ela= 4610 file number=169 first dba=58720 block cnt=48 obj#=145959 tim=747370565843
    WAIT #4: nam='direct path read' ela= 1387 file number=169 first dba=58784 block cnt=48 obj#=145959 tim=747370567472
    WAIT #4: nam='direct path read' ela= 1176 file number=169 first dba=58896 block cnt=48 obj#=145959 tim=747370568965
    WAIT #4: nam='direct path read' ela= 752 file number=169 first dba=58960 block cnt=48 obj#=145959 tim=747370569906
    WAIT #4: nam='direct path read' ela= 727 file number=169 first dba=59024 block cnt=48 obj#=145959 tim=747370570784
    WAIT #4: nam='direct path read' ela= 1041 file number=169 first dba=59088 block cnt=48 obj#=145959 tim=747370572087
    WAIT #4: nam='direct path read' ela= 1105 file number=169 first dba=59152 block cnt=48 obj#=145959 tim=747370573409
    WAIT #4: nam='direct path read' ela= 786 file number=169 first dba=59216 block cnt=48 obj#=145959 tim=747370574377
    WAIT #4: nam='direct path read' ela= 526 file number=169 first dba=59280 block cnt=48 obj#=145959 tim=747370575083
    WAIT #4: nam='direct path read' ela= 726 file number=169 first dba=59344 block cnt=48 obj#=145959 tim=747370575991
    WAIT #4: nam='direct path read' ela= 1342 file number=169 first dba=59408 block cnt=48 obj#=145959 tim=747370577512
    WAIT #4: nam='direct path read' ela= 390 file number=169 first dba=59488 block cnt=32 obj#=145959 tim=747370578078
    WAIT #4: nam='direct path read' ela= 858 file number=169 first dba=59552 block cnt=32 obj#=145959 tim=747370579079
    WAIT #4: nam='direct path read' ela= 488 file number=169 first dba=59616 block cnt=32 obj#=145959 tim=747370579736
    WAIT #4: nam='direct path read' ela= 1218 file number=169 first dba=59680 block cnt=32 obj#=145959 tim=747370581102
    WAIT #4: nam='direct path read' ela= 1450 file number=169 first dba=59744 block cnt=32 obj#=145959 tim=747370582704
    WAIT #4: nam='direct path read' ela= 230 file number=169 first dba=59808 block cnt=32 obj#=145959 tim=747370583077
    WAIT #4: nam='direct path read' ela= 1195 file number=169 first dba=59872 block cnt=32 obj#=145959 tim=747370584436
    WAIT #4: nam='direct path read' ela= 19093 file number=169 first dba=59904 block cnt=128 obj#=145959 tim=747370603694
    WAIT #4: nam='direct path read' ela= 1813 file number=169 first dba=60160 block cnt=128 obj#=145959 tim=747370606281
    WAIT #4: nam='direct path read' ela= 1960 file number=169 first dba=60288 block cnt=128 obj#=145959 tim=747370608645
    WAIT #4: nam='direct path read' ela= 646 file number=169 first dba=60416 block cnt=128 obj#=145959 tim=747370609702
    WAIT #4: nam='direct path read' ela= 2458 file number=169 first dba=60544 block cnt=128 obj#=145959 tim=747370612569
    WAIT #4: nam='direct path read' ela= 6580 file number=169 first dba=60672 block cnt=128 obj#=145959 tim=747370619551
    WAIT #4: nam='direct path read' ela= 2102 file number=169 first dba=60800 block cnt=128 obj#=145959 tim=747370622008
    FETCH #4:c=6318040,e=52169755,p=2051281,cr=2051318,cu=3,mis=0,r=1,dep=0,og=1,plh=44169924,tim=747370622376
    STAT #4 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=2051318 pr=2051281 pw=0 time=0 us)'
    STAT #4 id=2 cnt=2346507 pid=1 pos=1 obj=145959 op='TABLE ACCESS FULL MYTABLE (cr=2051318 pr=2051281 pw=0 time=48582132 us cost=556753 size=0 card=2333057)'
    WAIT #4: nam='SQL*Net message from client' ela= 8006 driver id=1413697536 #bytes=1 p3=0 obj#=145959 tim=747370630872
    CLOSE #2:c=0,e=6,dep=0,type=3,tim=747370630923
    =====================
    PARSING IN CURSOR #1 len=55 dep=0 uid=0 oct=42 lid=0 tim=747376894069 hv=2217940283 ad='0' sqlid='06nvwn223659v'
    alter session set events '10046 trace name context off'
    END OF STMT
    PARSE #1:c=0,e=84,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=747376894069
    EXEC #1:c=0,e=499,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=747376894621

    Здесь мы видим что таблица читалась через direct path read с предварительным checkpoint. Т.е. читалась она целиком с диска, т.к. Оракл считает ее достаточно большой чтобы читать через buffer cache. Почитай про serial direct path reads и _small_table_threshold. По факту из трэйса видно что вся она читалась мультиблочными чтениями. Из статистики что ты приложил видно что table fetch continued row был только 12 раз. Это означает что у тебя практически нет chained rows. Т.е. остаются только migrated, которые ты можешь убрать выполнив alter table move. Intra block конечно останутся, но как бы это вообще не проблема. Но, повторюсь, никакой работы по определению причины проблемы еще проделано не было.
    26 сен 13, 00:06    [14885242]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu
    Из статистики что ты приложил видно что table fetch continued row был только 12 раз. Это означает что у тебя практически нет chained rows. Т.е. остаются только migrated, которые ты можешь убрать выполнив alter table move. Intra block конечно останутся, но как бы это вообще не проблема. Но, повторюсь, никакой работы по определению причины проблемы еще проделано не было.


    Согласен с тем, что тут написали. Целиком и полностью.
    Просто сейчас получается что при "произвольных единичных чтениях" Oracle натыкается на мигрировавшие строки...
    И в виду нашей "говноситуации" избавиться от них мы просто так не сможем.

    Я писал уже, что "table move" делали месяц, два назад. Но в виду уникальности "говнопроцесса" мы получаем следующую логику:
  • Размер блока у нашей таблицы 8Кб.
  • Полей у нас в этой таблице около 500.
  • При вставке новой записи мы вставляем ее с заполнением примерно 10% от максимально возможного у нас заполнения (на вскидку, максимально возможное заполнение 10Кб, а мы заполняем около 1Кб.).
  • Oracle, видя, что строка маленькая - ищет под нее "дырку", куда ее можно сложить... Находит "дырку" например на 2Кб и пишет запись туда.
  • Через какое-то время, запись поднимают и обновляют значения (добавляя еще сколько-то информации). В итоге запись становится размером уже в 3Кб.
  • Так как запись размером в 3Кб не помещается в первоначальное место "2Кб", Oracle ее мигрирует куда-нибудь... сцепляя при этом.
  • И так повторяется несколько раз. В итоге запись может и всего 7Кб, но фрагментирована по всему массиву... и имеет от 2 до 11 различных "сцепленных блоков".
    Ситуацию бы мог спасти PCTFREE, но так как итоговый "средний объем" записи около 10Кб у нас смысла это не даст... ибо мы не можем нормально использовать это, т.к. размер блока априори меньше нужного для хранения "средне-заполненной" записи.
    От этого и move table сильно не спасает....
    Итог, - будем делать табличное пространство на 16Кб. И туда таблицу забрасывать с указанием PCTFREE = 70%.

    А с трассировкой на "конкретной глюк-записе" я попробую ближайшее время эксперименты провести.

    П.с. реальная выборка идет с использованием индексов, а не как в данном примере делали. По этому получается, что Oracle по rowid бегает несколько раз за всеми сцепленными блоками в нашей ситуации. Просто что именно Oracle делает, когда блоки эти "горячие" и в буферном кэш лежат... хотя и запись состоит из 2-7 сцепленных блоков... Когда он по индексу определяет rowid записи... Вероятно, он начинает "метаться" по кэш в поисках всех этих блоков от записи.
  • 26 сен 13, 11:27    [14886372]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka
    Ситуацию бы мог спасти PCTFREE, но так как итоговый "средний объем" записи около 10Кб у нас смысла это не даст... ибо мы не можем нормально использовать это, т.к. размер блока априори меньше нужного для хранения "средне-заполненной" записи.
    От этого и move table сильно не спасает....
    Не совсем понятно. Fullscan показал что chained rows нет. В противном случае они бы читались одноблочными чтениями, т.к. Oracle должен найти вторую часть колонок. Это как раз тот случай когда fullscan сильно деградирует в производительности. При migrated rows при fullscan этого не происходит, т.к. строка мигрирует целиком и Oracle просто пропускает указатели на перемещенную строку. Если же "средний объем" записи около 10Кб, то были бы chained rows, с одноблочными чтениями при fullscan и ростом статистики "table fetch continued row", чего не наблюдается.
    26 сен 13, 12:57    [14886921]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka
    П.с. реальная выборка идет с использованием индексов, а не как в данном примере делали. По этому получается, что Oracle по rowid бегает несколько раз за всеми сцепленными блоками в нашей ситуации. Просто что именно Oracle делает, когда блоки эти "горячие" и в буферном кэш лежат... хотя и запись состоит из 2-7 сцепленных блоков... Когда он по индексу определяет rowid записи... Вероятно, он начинает "метаться" по кэш в поисках всех этих блоков от записи.
    Он не метается. Он просто читает блоки по указателям пока не найдет конечный куда мигрировала строка. Если все в кэше - это будет практически незаметно. Но, еще раз, я пока не вижу никакой связи между migrated rows и падением производительности в данном случае.
    26 сен 13, 13:04    [14886960]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu
    Не совсем понятно. Fullscan показал что chained rows нет.

    Ну они априори есть:

    ANALYZE TABLE tablename LIST CHAINED ROWS;
    показал, что CHAINED_ROWS заполнилась:
    count(*) from CHAINED_ROWS where TABLE_NAME='MYTABLE';
    Возвращает: 1.851.080

    И выборка в режиме:
    SELECT /*+ FULL(p) */
          *
      FROM MYUSER.MYTABLE p
      WHERE ROWID
      IN (SELECT HEAD_ROWID FROM MYUSER.CHAINED_ROWS)
      AND ROWNUM<=10000;
    


    Показывает весьма интересную выборку (продолженные чтения и т.д.).
    См приложенный файл.

    Просто тест с count(*) не дает этих продолженных чтений... тест с count(*) просто пробежал по первым блокам, посчитав их и не стал фетчить "сцепленные"...

    Вот в приложенном файле статистика из такой вот выборки на 10 тыс. произвольных строк из тех, что в CHAINED_ROWS попали...

    К сообщению приложен файл (SESSION_STATISTIC2.xls - 30Kb) cкачать
    26 сен 13, 15:20    [14888055]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    получилось при выборке в селекте 10 тыс строк, мы получили:
    table fetch continued row = 8 637
    26 сен 13, 15:22    [14888072]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    город-герой, Владивосток, лег спать....
    А остальным видать сказать уже и нечего...
    Ну хоть на этом спасибо ответившим...
    Хотя часть проблем так и осталось не решенных...
    26 сен 13, 17:51    [14889119]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    happytoday
    Member

    Откуда: Днепр
    Сообщений: 239
    sergey.semka,

    Как вариант, могу предложить Вам посмотреть в сторону фрагментация MFT NTFS.
    Windows все таки.
    Но это вопрос уже не к Ораклу, а файловой системе
    26 сен 13, 18:09    [14889221]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    happytoday
    sergey.semka,

    Как вариант, могу предложить Вам посмотреть в сторону фрагментация MFT NTFS.
    Windows все таки.
    Но это вопрос уже не к Ораклу, а файловой системе

    Кстати, да... Там хоть и СХД какое-то, но все же... спасибо. Посмотрим.
    26 сен 13, 18:20    [14889258]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Хф
    Guest
    От migrated rows тебе не спастись - строка больше блока.
    Спастись от chained rows можно.


    Поскольку у тебя очень вырожденный случай - возможно это выход.
    Правда, не уверен что это работает на SE1 :)

    Нужно сделать хакан-фактор равным 1

    1. Создаем таблицу
    2. Вставляем одну строку
    3. ALTER TABLE MINIMIZE RECORDS_PER_BLOCK
    4. Заливаем остальные строки
    5. Тестируем производительность
    27 сен 13, 00:32    [14890485]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    dbms_photoshop
    Member

    Откуда: sqlmdx.net
    Сообщений: 5151
    sergey.semka
    получается, что Oracle по rowid бегает несколько раз за всеми сцепленными блоками в нашей ситуации
    Классная теория.
    Пора ставить 12с. Там "table access by index rowid batched" должно решить проблему.
    27 сен 13, 00:33    [14890489]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    хф
    Guest
    Хф
    От migrated rows тебе не спастись - строка больше блока.
    Спастись от chained rows можно.


    некорректно термины использовал. с точностью до наоборот :)
    27 сен 13, 02:58    [14890655]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka
    wurdu
    Не совсем понятно. Fullscan показал что chained rows нет.

    Ну они априори есть:

    ANALYZE TABLE tablename LIST CHAINED ROWS;
    показал, что CHAINED_ROWS заполнилась:
    count(*) from CHAINED_ROWS where TABLE_NAME='MYTABLE';
    Возвращает: 1.851.080

    И выборка в режиме:
    SELECT /*+ FULL(p) */
          *
      FROM MYUSER.MYTABLE p
      WHERE ROWID
      IN (SELECT HEAD_ROWID FROM MYUSER.CHAINED_ROWS)
      AND ROWNUM<=10000;
    


    Показывает весьма интересную выборку (продолженные чтения и т.д.).
    См приложенный файл.

    Просто тест с count(*) не дает этих продолженных чтений... тест с count(*) просто пробежал по первым блокам, посчитав их и не стал фетчить "сцепленные"...

    Вот в приложенном файле статистика из такой вот выборки на 10 тыс. произвольных строк из тех, что в CHAINED_ROWS попали...
    Проблема в том, что ANALYZE TABLE ... LIST CHAINED ROWS сваливает в кучу и chainded и migrated rows. Поэтому по результатам этой команды нельзя сказать chainded они, migrated или и то и другое.
    Но я не прав с моим тестом с fullscan, т.к. если запрос не затрагивает колонку из другого блока, то и искать вторую часть колонок он не будет. Поэтому тест надо повторить поставив select count(последняя_колонка) from проблемная_таблица.
    + создаем таблицу с chained rows так, чтобы 4-я колонка не была в соседнем блоке

    SQL> create table tst(n1 char(2000), n2 char(2000), n3 char(2000)) nologging;
    
    Table created.
    
    SQL>
    SQL> insert /*+ append */   into tst select 1,1,1 from dual connect by level <= 10000;
    
    10000 rows created.
    
    SQL> commit;
    
    Commit complete.
    
    
    SQL> alter table tst add n4 char(2000) default '1';
    
    Table altered.
    
    SQL> alter system flush buffer_cache;
    
    System altered.
    

    + тест с count(n4) показывает одноблочные чтения и table fetch continued row

    QL> set timing on
    SQL> select count(n4) from tst;
    
     COUNT(N4)
    ----------
         10000
    
    Elapsed: 00:00:07.16
    
    
    SQL> select EVENT, TOTAL_WAITS from v$session_event where sid = (select sid from v$mystat where rownum = 1) and total_waits != 0;
    
    EVENT                                                            TOTAL_WAITS
    ---------------------------------------------------------------- -----------
    Disk file operations I/O                                                   2
    enq: KO - fast object checkpoint                                           1
    db file sequential read                                                10047
    db file scattered read                                                    38
    direct path read                                                          79
    SQL*Net message to client                                                  9
    SQL*Net message from client                                                8
    events in waitclass Other                                                 19
    
    8 rows selected.
    
    Elapsed: 00:00:00.03
    SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row';
    
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    table fetch continued row                                              9999
    

    + тест с select count(*) показывает мультиблочные чтения и отсутствие table fetch continued row

    SQL> set timing on
    SQL> select count(*) from tst;
    
      COUNT(*)
    ----------
         10000
    
    Elapsed: 00:00:02.06
    SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row';
    
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    table fetch continued row                                                 0
    
    Elapsed: 00:00:00.00
    SQL> select EVENT, TOTAL_WAITS from v$session_event where sid = (select sid from v$mystat where rownum = 1) and total_waits != 0;
    
    EVENT                                                            TOTAL_WAITS
    ---------------------------------------------------------------- -----------
    Disk file operations I/O                                                   2
    enq: KO - fast object checkpoint                                           1
    db file sequential read                                                   41
    db file scattered read                                                    38
    direct path read                                                         157
    SQL*Net message to client                                                 11
    SQL*Net message from client                                               10
    events in waitclass Other                                                  1
    
    8 rows selected.
    
    27 сен 13, 07:47    [14890747]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    И все-таки повторюсь вот тесткейс который может быть у тебя Индекс вместо полного сканирования.. Если ты апдейтишь поле-поля начиная с 255 колонки, то у тебя будут образовываться chained rows несмотря на то что строка влазит в блок. И никакими pctfree и размерами блока ты это не вылечишь. Такая реализация у Oracle. Но move поможет с этими chained rows.
    27 сен 13, 09:33    [14890962]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    Собственно вот тесткейс когда на пустом месте мы получаем строчку в 245 блоках. Таблица tst содержит 500 колонок number.
    Просто такая реализация.
    SQL> truncate table tst;
    
    Table truncated.
    
    SQL> insert into tst(n1) values(1);
    
    1 row created.
    
    SQL>
    SQL> commit;
    
    Commit complete.
    
    SQL> select blocks from user_segments where segment_name='TST';
    
        BLOCKS
    ----------
             8
    
    SQL> begin
      for i in 255..500  loop
        execute immediate 'update tst set n' ||i ||'=1';
      end loop;
      commit;
    end;
    /
      2    3    4    5    6    7
    
    PL/SQL procedure successfully completed.
    
    SQL> SQL> commit;
    
    Commit complete.
    
    SQL> select blocks from user_segments where segment_name='TST';
    
        BLOCKS
    ----------
           256
    
    	   SQL> select count(*) from tst;
    
      COUNT(*)
    ----------
             1
    
    SQL>  select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row';
    
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    table fetch continued row                                                 0
    
    SQL> select count(n500) from tst;
    
    COUNT(N500)
    -----------
              1
    
    SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row';
    
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    table fetch continued row                                               244
    
    SQL> alter table tst move;
    
    Table altered.
    
    SQL>  select blocks from user_segments where segment_name='TST';
    
        BLOCKS
    ----------
             8
    
    27 сен 13, 10:01    [14891098]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Вячеслав Любомудров
    Member

    Откуда: Владивосток
    Сообщений: 18509
    Оп-па
    Интересненько
    Я всегда считал, что будет только две "подстроки" 1-254 и 255-500, а получается, что любое новое поле (кроме уже существующих) в отдельной операции за пределами 254 создает отдельную "подстроку" ?
    Как-то не очень оптимальный подход. Почему бы не увеличивать второй кусок (255+), а не плодить новые "продолжения"
    27 сен 13, 10:21    [14891188]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Вячеслав Любомудров
    Member

    Откуда: Владивосток
    Сообщений: 18509
    А вот то, что оно продолжение в новый блок пихает, это, скорее всего, особенности ASSM ?
    27 сен 13, 10:22    [14891197]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    Да вот по-моему это не ASSM, а просто оно так устроено.
    27 сен 13, 10:26    [14891230]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    dbms_photoshop
    Member

    Откуда: sqlmdx.net
    Сообщений: 5151
    wurdu
    Собственно вот тесткейс когда на пустом месте мы получаем строчку в 245 блоках.
    Не совсем понятно почему оно возвращает для моего примера (14890669) 0. Ведь для третьей строки необходимо прочитать сцепленный блок, для id1.
    SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row';
    
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    table fetch continued row                                                 0
    
    SQL> select min(ora_hash(id1)) dummy from t;
    
         DUMMY
    ----------
     391485597
    
    SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row';
    
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    table fetch continued row                                                 0
    
    27 сен 13, 11:32    [14891631]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu
    И все-таки повторюсь вот тесткейс который может быть у тебя Индекс вместо полного сканирования.. Если ты апдейтишь поле-поля начиная с 255 колонки, то у тебя будут образовываться chained rows несмотря на то что строка влазит в блок. И никакими pctfree и размерами блока ты это не вылечишь. Такая реализация у Oracle. Но move поможет с этими chained rows.

    И так каждый месяц делать MOVE?..
    А резмер блока в 16Кб и PCTFREE=99% не спасет тоже?...
    27 сен 13, 14:54    [14893221]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka
    wurdu
    И все-таки повторюсь вот тесткейс который может быть у тебя Индекс вместо полного сканирования.. Если ты апдейтишь поле-поля начиная с 255 колонки, то у тебя будут образовываться chained rows несмотря на то что строка влазит в блок. И никакими pctfree и размерами блока ты это не вылечишь. Такая реализация у Oracle. Но move поможет с этими chained rows.

    И так каждый месяц делать MOVE?..
    А резмер блока в 16Кб и PCTFREE=99% не спасет тоже?...
    Это зависит от того chainded или migrated rows (надо проверить) и от того как они chained. Потому как если chained как в моем testcase то ничего не поможет (зато поможет move, что в принципе хорошо).
    27 сен 13, 14:56    [14893244]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu
    Да вот по-моему это не ASSM, а просто оно так устроено.

    Я знаю, что после 255 полей, Oracle сцеплять начинает. Но вот на каждое поле чтобы "сцеплял" - это конечно, крутая гипотеза...
    Просто я знаю, что Oracle даже если сцепляет - то "по возможности старается сохранить эти "сцепленные" блоки в одном блоке.
    Он же не идиот фрагментацию себе устраивать сам...

    Кстати, на твоих тестовых таблицах физические атрибуты хранения, такие как "Percent Free", "Percent Used", "PCT INCREASE", "FreeLists" сколько были?... может быть он в таком тесте (через цикл) не может получать значения... не видит, что блок свободный и выделяет новый?..
    Кто-то в доку ткнуть может по поводу проблемы "сцепления после 255+ поля в таблице" и данный тестовый пример...
    27 сен 13, 15:02    [14893294]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu
    Это зависит от того chainded или migrated rows (надо проверить) и от того как они chained. Потому как если chained как в моем testcase то ничего не поможет (зато поможет move, что в принципе хорошо).

    Мув делали месяца полтора назад. Тогда помогло частично. А в связи с тем, что 255+ полей - всяко там Chained записи идут...
    27 сен 13, 15:03    [14893310]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    sergey.semka
    wurdu
    Да вот по-моему это не ASSM, а просто оно так устроено.

    Я знаю, что после 255 полей, Oracle сцеплять начинает. Но вот на каждое поле чтобы "сцеплял" - это конечно, крутая гипотеза...
    Просто я знаю, что Oracle даже если сцепляет - то "по возможности старается сохранить эти "сцепленные" блоки в одном блоке.
    Он же не идиот фрагментацию себе устраивать сам...

    Кстати, на твоих тестовых таблицах физические атрибуты хранения, такие как "Percent Free", "Percent Used", "PCT INCREASE", "FreeLists" сколько были?... может быть он в таком тесте (через цикл) не может получать значения... не видит, что блок свободный и выделяет новый?..
    Кто-то в доку ткнуть может по поводу проблемы "сцепления после 255+ поля в таблице" и данный тестовый пример...
    Он работает именно так. Никакие параметры хранения ни на что не влияют в данном случае. Любой желающий может воспроизвести тесткейс с любыми параметрами. В доке это не описано. Я так думаю что если завести SR то скажут что не баг.
    27 сен 13, 15:07    [14893348]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu,
    Кстати, по поводу NULL-полей в конце. Мне один весьма уважаемый и компетентный специалист сказал, что в конце как-раз нужно переносить самые "толстые" поля из самых редкоиспользуемых... чтобы Oracle сцеплял их. И именно их скидывал в конец (в сцепленные). Тогда если к ним запроса не будет - они никогда "читаться" не должны...

    Хотя, если всегда запросы будут типа "SELECT *" - мне подсказывает задница, что Oracle все равно будет читать все поля... так что это монописуально становится...
    Учитывая, что есть клиенты от Forms 6i, которые работают тоже с этой табличкой - так Forms всегда делает выборку всех полей и всех их обратно UPDATE, на сколько я представлять....

    Короче, "попкорн жарим" в микроволновке, получается в нашем случае... :(
    27 сен 13, 15:15    [14893441]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Вячеслав Любомудров
    Оп-па
    Интересненько
    Я всегда считал, что будет только две "подстроки" 1-254 и 255-500, а получается, что любое новое поле (кроме уже существующих) в отдельной операции за пределами 254 создает отдельную "подстроку" ?
    Как-то не очень оптимальный подход. Почему бы не увеличивать второй кусок (255+), а не плодить новые "продолжения"


    Вообще в подтверждение твоей теории:
    автор
    Oracle Database can only store 255 columns in a row piece. Thus, if you insert a row into a table that has 1000 columns, then the database creates 4 row pieces, typically chained over multiple blocks.

    Oracle® Database Concepts
    11g Release 2 (11.2)

    Что собственно и логично...
    27 сен 13, 15:24    [14893529]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    wurdu
    Он работает именно так. Никакие параметры хранения ни на что не влияют в данном случае. Любой желающий может воспроизвести тесткейс с любыми параметрами. В доке это не описано. Я так думаю что если завести SR то скажут что не баг.


    А вот тут сказано, что он не так работает...(см. предыдущее сообщение).
    Все же он кусками клеит по 255
    27 сен 13, 15:27    [14893554]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    6124
    Guest
    Вячеслав Любомудров
    Оп-па
    Интересненько
    Я всегда считал, что будет только две "подстроки" 1-254 и 255-500, а получается, что любое новое поле (кроме уже существующих) в отдельной операции за пределами 254 создает отдельную "подстроку" ?
    Как-то не очень оптимальный подход. Почему бы не увеличивать второй кусок (255+), а не плодить новые "продолжения"


    Одна поправка -
    Любое новое поле - которое дальше предыдущих непустых

    попробуй перед циклом
    SQL> begin
      for i in 255..500  loop
        execute immediate 'update tst set n' ||i ||'=1';
      end loop;
      commit;
    end;
    


    сказать
    update tst set n500 = 1;

    Ораклу придется аллоцировать предыдущие 499 полей в блоке данных.

    Пока не знаю объяснения - но могу предположить что связано это с тем, что последние пустые колонки в строке не хранятся - стало быть даже если в таблице > 255 колонок - оракл не знает сколько конкретно будет row_pieces - может 1, может 2, а может и больше.
    Но разбивать сразу по 255 колонок - нецелесообразно - а вдруг их и не будет. С другой стороны,похоже что migrated rows обрабатывать легче чем chained rows (в том числе и migrated row pieces) - поэтому он до последнего (лениво) надеется что пусть будет много указателей на migrated row piece чем потом придется разбивать один row piece еще на промежуточные под-кусочки.

    p.s. все выше - в порядке пятничного бреда. (пока)
    27 сен 13, 15:35    [14893623]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    6124
    Вячеслав Любомудров
    Оп-па
    Интересненько
    Я всегда считал, что будет только две "подстроки" 1-254 и 255-500, а получается, что любое новое поле (кроме уже существующих) в отдельной операции за пределами 254 создает отдельную "подстроку" ?
    Как-то не очень оптимальный подход. Почему бы не увеличивать второй кусок (255+), а не плодить новые "продолжения"


    Одна поправка -
    Любое новое поле - которое дальше предыдущих непустых

    попробуй перед циклом
    SQL> begin
      for i in 255..500  loop
        execute immediate 'update tst set n' ||i ||'=1';
      end loop;
      commit;
    end;
    


    сказать
    update tst set n500 = 1;

    Ораклу придется аллоцировать предыдущие 499 полей в блоке данных.

    Пока не знаю объяснения - но могу предположить что связано это с тем, что последние пустые колонки в строке не хранятся - стало быть даже если в таблице > 255 колонок - оракл не знает сколько конкретно будет row_pieces - может 1, может 2, а может и больше.
    Но разбивать сразу по 255 колонок - нецелесообразно - а вдруг их и не будет. С другой стороны,похоже что migrated rows обрабатывать легче чем chained rows (в том числе и migrated row pieces) - поэтому он до последнего (лениво) надеется что пусть будет много указателей на migrated row piece чем потом придется разбивать один row piece еще на промежуточные под-кусочки.

    p.s. все выше - в порядке пятничного бреда. (пока)

    Кстати, да! Вот видимо это Олег и пытался мне сказать, советуя чтобы я "максимально заполненные поля из минимально использованных в конец запихал в моем случае - чтобы сцепленных блоков меньше было.
    Тогда все становится понятнее. Тогда (в моем случае "попкорна" надо самые толстые и заполненные в конец пихать, чтобы Oracle сразу выделял под эти блоки место и эти "толстые" поля, которые по факту будут "во второй половине сцепки" (т.е. во вторых 255+ полях) как можно реже поднимались через "продолженные чтения".
    27 сен 13, 16:23    [14894009]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    6124
    Guest
    sergey.semka
    Вот видимо это Олег и пытался мне сказать, советуя чтобы я "максимально заполненные поля из минимально использованных в конец запихал в моем случае - чтобы сцепленных блоков меньше было.


    тогда уж

    alter table tst add (end_of_row integer default 1) (только нужно реально move сделать - а то оракл мухлевать научился с добавлением дефолтовых колонок
    27 сен 13, 16:28    [14894039]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    6124,

    Ну в нашем случае 2+ млн записей.
    1) табличное пространство создаем новое на 16К;
    2) Исходную таблицу переименовываем.
    3) Создаем новую таблицу, меняя порядок полей на нужный нам... выставляя Initional Extend... PCTFREE = 99%;
    4) Insert into таблица (поля в нужном порядке) Select (поля в нужном порядке) FROM переименованная таблица Order by PKEY;
    5) Все индексы + триггеры + контекстные перестягиваем на новую таблицу (пересоздаем на ней).

    Просто в случае нашего "попкорна", когда вставляются новые записи с 10% заполенния... а потом туда "довливаются" записи...
    Нам нужно сократить миграцию в 0! иначе получать всегда будем, что по индексам будет бегать искать "перемещенные" строки, нарастать фрагментация и "перемещенные строки"...

    Как-то так.
    27 сен 13, 17:05    [14894281]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    6124,

    Ну если он постепенно "доращивает" указателями... создавая структуру на подобии "связанного списка" - тогда еще больше понятно стало откуда у нас такая "хрень".
    Дело в том, что поля у нас постепенно появляются... одно, потом другое... потом третье...
    (это что касается 255+ полей)... Соответственно, они могут появиться сразу +10 полей, а могут по одному...
    И заполнение тоже отдельными кусками... Типа может добавиться 10 пустых полей в конец, понятно дело...
    Затем заполниться 3-е с конца поле. Потом 7 с конца поле... потом остальные начинают "вдуваться"...
    И еще и в первом куске "наращиваются" объемы заполнения CLOB полей...
    В итоге там все "мигрирует" и "сцепляется" с неимоверной силой... и эти "несчастные" 2,2 млн записей при объеме 8гб информации начинают "вешаться".
    Видимо как-то так...
    27 сен 13, 17:11    [14894308]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    dbms_photoshop
    Member

    Откуда: sqlmdx.net
    Сообщений: 5151
    sergey.semka
    если к ним запроса не будет - они никогда "читаться" не должны
    Тут достаточно убедительно это подтверждается 14890669.
    Касательно null в конце, ноги растут оттуда, что в этом случае он занимает ноль байт, а не один.
    Это перпендикулярные подходы.
    27 сен 13, 18:15    [14894567]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Sergei.Agalakov
    Member

    Откуда:
    Сообщений: 575
    16k блок - это хорошо, но почему бы все-таки не нарезать таблицу вертикально на несколько таблиц, а Forms подсунуть view связывающую все узкие таблички с intead of триггером? Эдакий кластер наоборот. Как-то не верется, что у вас все запросы вида select * из таблицы с 400+ колонками. А так можно будет физически логично сгруппировать колонки обычно используемые вместе в одном запросе, да и pctfree индивидуально назначить - на таблицы со статичными колонками побольше, на часто обновляемые поменьше.
    Больший блок как-то поможет пока вы с вашим подходом еще 100500 колонок не добавите к этой таблице. Все-таки надо озаботиться редизайном, а обратную совместимость с приложением обеспечивать вьюшками.
    27 сен 13, 19:39    [14894815]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    sergey.semka
    Member

    Откуда: Санкт-Петербург
    Сообщений: 182
    Sergei.Agalakov
    16k блок - это хорошо, но почему бы все-таки не нарезать таблицу вертикально на несколько таблиц, а Forms подсунуть view связывающую все узкие таблички с intead of триггером? Эдакий кластер наоборот. Как-то не верется, что у вас все запросы вида select * из таблицы с 400+ колонками. А так можно будет физически логично сгруппировать колонки обычно используемые вместе в одном запросе, да и pctfree индивидуально назначить - на таблицы со статичными колонками побольше, на часто обновляемые поменьше.
    Больший блок как-то поможет пока вы с вашим подходом еще 100500 колонок не добавите к этой таблице. Все-таки надо озаботиться редизайном, а обратную совместимость с приложением обеспечивать вьюшками.


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

    Соответственно с view тоже не прокатит - ибо в специальных настроечных табличках эти "настройщики" прописывают поля, которые нужны, прописывают то, где это все высвечиваться будет - в какой форме, на какой закладке и прочее... Какие вью - какие поля используют и т.д. и т.п. - и все это через Oracle Forms Application Programming Interface (API), Oracle Forms(6i/9i/10g) C/C++ API заносится в Forms, компилируется и один только черт знает откуда там все берется и куда какие поля попадают...
    Однако трассировки показывают, что Forms делает "select ДЛИННЫЙ СПИСОК ВСЕХ ПОЛЕЙ ЧЕРЕЗ ЗАПЯТУЮ from mytablename for update"... Но это уже другая история.

    А на счет "нарезки вертикально" - Oracle по сути это и делает в результате "chained rows" - основная его задача разрезать на куски по 255 полей...
    Просто если все данные "совместно" используются - тогда все будет на JOIN падать... там другие проблемы начнутся....
    Ибо нет полей, которые вообще не правятся... они все время от времени могут меняться... за исключением небольшого набора квази-стабильных полей.
    Вот такая-вот бредятина...

    Выражаю большую благодарность всем, кто откликнулся и просветил...
    Особая благодарность и привет Владику... он же Владивосток: если нужно - могу сказать по какому адресу подъехать и получить свое "пиво" =)
    27 сен 13, 20:12    [14894889]     Ответить | Цитировать Сообщить модератору
     Re: Chained rows в вторичных таблицах пространственных индексов  [new]
    Sergei.Agalakov
    Member

    Откуда:
    Сообщений: 575
    Могу только посочувствовать. Если начальство вменяемое, то объясните ему, что все костыли и пластыри могут вам помочь только на ограниченное время. Пока 'это' еще работает необходимо начать работы по полному редизайну системы.
    Если начальство невменяемое, то с проекта надо сваливать, чтобы не оказаться похороненным под его обломками.
    30 сен 13, 21:23    [14903851]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: 1 2 3 4 5      [все]
    Все форумы / Oracle Ответить