Приветствую всех,

TS с uniform size 4M, ASSM, в ней таблица ~90ГБ, получилось около 22000 экстентов.
Мне предлагают перенести её в TS с большим размером экстента, чтобы устранить какую-то фрагментацию.
Вообще термин фрагментации по моему больше подходит к старым словарным TS, где экстенты могли иметь разный размер....
Тут же uniform size на TS...
Или под фрагментацей тут понимают просто большое число экстентов?
На таблице есть индекс, он в TS с 2МБ uniform size.

Нужно ли переносить?
Точнее почти уверен, что оно конечно и можно ... но вот зачем?
Как аргументировать(если я прав), что можно ничего не менять?
Если брать фулскан по таблице или индексный доступ - то скорость тут по моему никак не может меняться.

Прошу совета.

Забыл добавить - база 12c, RAC, соответственно ASM, ALLOCATION_UNIT_SIZE = 4MB

mefmanKeklikЗабыл добавить - база 12c, RAC, соответственно ASM, ALLOCATION_UNIT_SIZE = 4MB
сдается мне в современных БД это очень "тонкий тюнинг", который в итоге ничего не даст.
90Гб таблица - на так уж и много сегодня )
Но как обосновать, что смысла нет?

andrey_anonymousKeklikНо как обосновать, что смысла нет?
От обратного.
Предложить предлагающему оценить эффект от его предложения. В цифрах.
Была такая мысль ... но, может есть best practics по этому вопросу?
С другой стороны использовать uniform size на TS совсем не возбраняется, 4МБ экстент - совсем не маленький,
а то что их за 20ть тысяч - так и что?

Видимо надо добавить с чего вообще вопрос возник.
Один из процессов занимает час времени, считают, что должен занимать пол-часа,
и почему-то сразу думают, что дело в базе, а не в программе.

По AWR отчету за этот час, в топе два INSERT'а.

Одну из таблиц я описал, вторая аналогичная.

SQL ordered by Elapsed Time







2мс - время одного insert, по моему это нормальная скорость.

Может ли укрупнение экстентов увеличить эту скорость?
Ведь какое-то время тратится и на поиск-добавление в словарь информации о экстенте, хотя ...

И еще, подскажите как в AWR отчете увидеть общее время, которое отняла база?
Т.е. делаем отчет за час, вот сколько времени в этом часе заняла база, а именно выполнение запросов?
Как увидеть, что например 20 минут, вообще не было к базе обращений, или запрос был на базе, но "лениво" фетчил
данные из курсора, например на экран кто-то данные выводил по мере чтения.... или программа по мере обработки...

Как понять эти метрики?



Откуда взялось 128 минут, если отчет делался за час, как на базе (DB Time) может быть больше часа?

Есть еще такая информация в отчете, опять же как sql execute elapsed time может быть больше часа - 5,310.38 ?
Time Model Statistics


..
..





А здесь 1,071 секунд на Log write система была - значит ли это, что это время вычесть надо из часа,
или это шло параллельно выполнению запроса.
Нет понятно, что параллельно, но как отчет тогда понимать?

Т.е. программа работает час, иногда отправляет запросы к базе - как понять какое время в
этот час программа ждала результатов с базы, а какое-то время вообще не было запросов?

К примеру, выше SQL запрос занял Total 18% - а как узнать от какого времени идут эти 18% ?
Не от всего ведь часа.

Вячеслав ЛюбомудровКонечно, если бы на этапе построения системы было известно, что данная таблица будет занимать десятки гигов, то best practices было бы увеличить uniform size например до 128M и секционировать (или 256M без секционирования)

Но сейчас best practices -- осознать стоит ли овчинка выделки. Нет, если есть достаточно большое окно и хочется чтоб все было "по фэншую" можно и перестроить (и предусмотреть, возможно больший размер блока, и компрессию). Но специально изыскивать резервы -- я бы не стал (если только за отдельную плату )

Скорее всего просто уменьшение количества экстентов не даст даже пол-процента прироста призводительности

Вячеслав спасибо за советы!
В таблице больше 100млн строк и около 500 партиций, но данные перекошены, и
все строки лежат в одной партиции.
Может ли наведение порядка с партициями(с данными) увеличить скорость вставки?

Вот пытаюсь понять стоит ли овчинка выделки.... ещё бы понимать лучше AWR отчет, можете посоветовать по его данным(предыдущий пост)?

Хотя уверен, что простое увеличение экстентов, как Вы и пишите, больше пол-процента не даст.
Хотя сама перестройка таблицы может и дать какие-то результаты для SELECT'ов (просто выгрузка, truncate, загрузка).

Viewer Ask TOM. Number Of Extents
Читал я эту ветку.
Том говорит, что если 1000 экстентов - то не парьтесь, его спрашивают - а если 7,237 экстентов на таблицу в 12.8gb ?
А не парьтесь, если нет проблем с производительностью... - а как понять есть ли они ?

Вячеслав ЛюбомудровKeklikВ таблице больше 100млн строк и около 500 партиций, но данные перекошены, и
все строки лежат в одной партиции.Ну и толку с такого секционирования?
KeklikМожет ли наведение порядка с партициями(с данными) увеличить скорость вставки?Вставки -- вряд-ли

Да и вообще -- почему ты решил, что именно здесь проблема?
Не, не я решил, мне это предлагают, чтобы процесс быстрее пошел.

Вспомнил, что в другом проекте есть нагруженная таблица,
Больше 80,000 экстентов по 4МБ, размер 313GB и там основная операция INSERT.
И со скоростью вставки нет никаких проблем, да и вообще никаких проблем нет.

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

Вячеслав ЛюбомудровЕсть подозрение, что у него в UET$ и FET$ по 0 записей
Другое дело x$ktfbue и x$ktfbfe, а это обращение (Current read) к битмап карте заголовка файла
....

[/src][/spoiler]
--UET$ и FET$ по 0 записей
Ну да, TS ведь local managment....
select count(*) from sys.UET$

COUNT(*)
----------
0
1 row selected.

Спасибо за инфу по x$ktfbue и x$ktfbf.
Вроде убедил не трогать, потому что повторюсь, на больших таблицах с большим числом экстентов все
живет без проблем и именно с INSERT в основной нагрузке.

Вячеслав ЛюбомудровDВАпереносить таблицу чтобы уменьшить время инсерта за счет сокращения ожиданий на выделение экстента - вполне оправданная рекомендация. например если у вас таблица с лобами.Собственно, ничто не мешает увеличить NEXT, чтоб при выделении памяти выдавалось сразу несколько UNIFORM экстентов
Хороший совет, спасибо.
Думаю в этом случае, скорость выделения экстента таблицы(точнее экстентов), не будет отличаться если бы uniform бы большим,
т.к. размер юнита в ASM задан в 4МБ.
Т.е. NEXT 128МБ при uniform 128MB и next 128MB при uniform 4МБ - дадут один результат по
скорости выделении экстентов.
Биты переключить в датафайлах TS, да записи добавить в словарь, что у сегмента есть новые экстенты.
Ну да, битов больше - не 1, а 32 - и какая разница в плане скорости?
Или я что-то упустил?

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

DВА-2-пропущено...
Остается только выбрать цель оправданий. Cократить ожидания индивидуального инсерта - это уменьшение размера uniform-экстента и, как следствие, их количество увеличится.

В многопользовательской среде при выделении экстента одним индивидуальным инсертом все остальные инсерты курят в сторонке пока экстент не выделится, а потом валом ломятся его заполнять.
Если у вас экстенты будут выделяться по чуть-чуть и тут же заполняться, то вся могопользовательская работа уйдет в очередь ожидания выделения очередного кусочка, поэтому чем больше экстент, тем лучше, тем реже его аллоцировать.
Я приводил пример гораздо большей и более нагруженной таблицы -
больше 80,000 экстентов по 4МБ, размер таблицы 313GB.
И тоже 4МБ uniform - никаких траблов на INSERT нет.
Все-таки 4МБ - это совсем не мало, раньше основное время в поиске-выделении-удалении экстента был пин-понг между fet$ и uet$,
чего нет у LMTs, - биты найти свободные в датафайле и поменять их недолго и разницы нет 32 бита поменять или 1.
По любому спасибо за информацию, для заведомо больших таблиц лучше использовать uniform по-больше.
А что скажете насчет auto - видел в нескольких проектах, используют и не напрягаются такими тонкостями.

Как увидеть, что есть описываемая проблемя в AWR отчете?
Читал про TT очереди для обработки экстент-запросов на каждом TS - есть они в AWR?
И где там посмотреть очереди на добавление новых экстентов сегменту в словаре?
Проверю на обоих базах.

DВА HW - contention
Спасибо, проверю на следующей неделе....

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