Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
Pohvaloff
Member

Откуда: Красноярск
Сообщений: 212
собственно SUBJ. Посоветуйте пожалуйста в каких случаях стоит использовать UNIFORM ALLOCATION у TABLESPACE'а, в в каких нет.
29 окт 04, 10:13    [1070423]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17927
Скажем так: НЕ ИСПОЛЬЗОВАТЬ его стоит только тогда, когда у вас в табличном пространстве будут храниться как огромные, так и маленькие объекты.

Если вы знаете свои данные и знаете, что определенные таблицы будут большие - поместите их в ТП с большим UNIFORM, чтоб уменьшить количество экстентов у сегментов и (самое главное) сделать предсказуемыми по размеру свободные куски. А то получится, что в результате фрагментации образовалось много свободных кусков небольшого/среднего размера, а выделить большой очередной экстент из них не получиться :-(

То же самое насчет очень маленьких таблиц - поместите их в ТП с UNIFORM SIZE 16k и сэкономете немного места ;-)

Весь остальной зоопарк - в ТП с AUTOALLOCATE, хотя здесь могут возникнуть те же проблемы по выделению большего экстента, чем свободные. Но, мне кажется, в боевых БД (нет удалений объектов и трункейтов) это не критично.
29 окт 04, 10:34    [1070499]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
run09
Member

Откуда:
Сообщений: 29
Вячеслав Любомудров
Если вы знаете свои данные и знаете, что определенные таблицы будут большие - поместите их в ТП с большим UNIFORM, чтоб уменьшить количество экстентов у сегментов и (самое главное) сделать предсказуемыми по размеру свободные куски.

Предположим таблица 3 Тб. Только вставка. Насколько большим можно делать uniform?
23 ноя 18, 01:37    [21742246]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17927
Да вроде ограничений нет, но больше 100 Mb, на мой взгляд, просто нет смысла
И у тебя один сегмент будет 3Tb? Обычно, с такими объемами юзают Partitioning Option
23 ноя 18, 02:54    [21742257]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
run09
Member

Откуда:
Сообщений: 29
Вячеслав Любомудров
Да вроде ограничений нет, но больше 100 Mb, на мой взгляд, просто нет смысла
И у тебя один сегмент будет 3Tb? Обычно, с такими объемами юзают Partitioning Option

Да, один. partitioning пока что невозможен.
23 ноя 18, 11:40    [21742594]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 16897
run09
Вячеслав Любомудров
Да вроде ограничений нет, но больше 100 Mb, на мой взгляд, просто нет смысла
И у тебя один сегмент будет 3Tb? Обычно, с такими объемами юзают Partitioning Option

Да, один. partitioning пока что невозможен.

Даже на SE можно воспользоваться partitioning views - что-то типа "partitoning для бедных".
Моделька на поиграться
23 ноя 18, 15:34    [21742994]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17927
Ну, тогда, наверное, стоит указать размер UNIFORM SIZE 1GB. Только мне как-то кажется, что пока это влажные фантазии...


Ну и опять же, я неоднократно приводил ссылочку на статью Т.К. в OM про параллельную прямую загрузку -- там AUTOALLOCATE выигрывает тем, что поджимает последние выделенные экстенты до фактического заполнения

На мой взгляд, это ломает всю концепцию выделения экстентов определенными (статическими размерами) кусками, чтоб всегда по максимуму использовать свободное место. Но то такое...
23 ноя 18, 15:57    [21743025]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
run09
Member

Откуда:
Сообщений: 29
Вячеслав Любомудров
Ну, тогда, наверное, стоит указать размер UNIFORM SIZE 1GB. Только мне как-то кажется, что пока это влажные фантазии...


Ну и опять же, я неоднократно приводил ссылочку на статью Т.К. в OM про параллельную прямую загрузку -- там AUTOALLOCATE выигрывает тем, что поджимает последние выделенные экстенты до фактического заполнения

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

Параллельной загрузки не будет. Что вы имеете ввиду под "влажные фантазии" ?

andrey_anonymous ,
занятный трюк. Увы, схему изменить не получится
23 ноя 18, 16:17    [21743066]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17927
Ну просто с такими объемами обычно идут не на форум (мало ли кто там попадется) обсуждать, а к тому, кто вам эту систему впарил

Например, простые вопросы -- используете ли вы BIGFILE, ASM и прочие фишки именно для хранения больших данных
Может ли вылезти проблема именно на уровне OS?
Количество пользовальских (точнее серверных) оракловых процессов (каждый процесс открывает сам все датафайлы, к которым он обращается) тоже может ограничить.
Таки мало сведений
23 ноя 18, 16:30    [21743098]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
run09
Member

Откуда:
Сообщений: 29
Вячеслав Любомудров
Ну просто с такими объемами обычно идут не на форум (мало ли кто там попадется) обсуждать, а к тому, кто вам эту систему впарил

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

Сейчас ASM. Я кстати, как раз и планирую сделать bigfile
26 ноя 18, 12:38    [21744779]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17927
Я просто не понимаю, как может один сегмент быть 3 Тб
Может таки это отдельный LOB-сегмент?
Ты действительно адекватно оцениваешь ситуацию?
26 ноя 18, 12:44    [21744792]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
run09
Member

Откуда:
Сообщений: 29
Вячеслав Любомудров,
Ну, да, обычный сегмент (без lob), живущий своей долгой жизнью лет 20...
26 ноя 18, 13:02    [21744833]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
Vadim Lejnin
Member

Откуда:
Сообщений: 6422
run09
Вячеслав Любомудров
Ну просто с такими объемами обычно идут не на форум (мало ли кто там попадется) обсуждать, а к тому, кто вам эту систему впарил

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

Сейчас ASM. Я кстати, как раз и планирую сделать bigfile


использование bigfile - имеет определенные засады, перед использованием рекомендую ознакомится
26 ноя 18, 13:12    [21744855]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17927
Лет 20 -- это с Oracle7
Я примерно с того времени использую Oracle (чуть раньше)
Но даже последнее место работы -- мы используем финансовые (которых тупо нельзя забыть) проводки за последних 20 лет
Так там даже на 2Тб не получается всех документов (включая сканы в PDF)

Ты либо выдаешь желаемое за действительное (ну или когда будет), либо нехочу озвучивать
26 ноя 18, 13:13    [21744857]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17927
Vadim Lejnin
run09
пропущено...

Сейчас ASM. Я кстати, как раз и планирую сделать bigfile


использование bigfile - имеет определенные засады, перед использованием рекомендую ознакомится
Вадим, проясни
Действительно интересно
Пока не юзаю, но иметь по 30 файлов на ТП уже накаляет
Хотя, мне кажется, тут имеет приоритет место хранения
26 ноя 18, 13:16    [21744865]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
run09
Member

Откуда:
Сообщений: 29
Вячеслав Любомудров
Лет 20 -- это с Oracle7
Я примерно с того времени использую Oracle (чуть раньше)
Но даже последнее место работы -- мы используем финансовые (которых тупо нельзя забыть) проводки за последних 20 лет
Так там даже на 2Тб не получается всех документов (включая сканы в PDF)

Ты либо выдаешь желаемое за действительное (ну или когда будет), либо нехочу озвучивать


не совсем понимаю вашего удивления.

SQL> select sum(bytes)/1024/1024/1024/1024 from dba_segments where segment_type='TABLE' group by segment_name having sum(bytes)/1024/1024/1024/1024 > 1;

SUM(BYTES)/1024/1024/1024/1024
------------------------------
                    2.80991192
                    1.31701565
26 ноя 18, 14:14    [21744984]     Ответить | Цитировать Сообщить модератору
 Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
master_yoda
Member

Откуда:
Сообщений: 82
run09
Предположим таблица 3 Тб. Только вставка. Насколько большим можно делать uniform?

Для небольших БД лучше не надо UNIFORM, автомат вполне адекватен. Оно Вам надо потом по ночам таблицы/индексы туда-сюда двигать?

Вячеслав Любомудров
Так там даже на 2Тб не получается всех документов (включая сканы в PDF)


Есть не в единичных экземплярах TABLE SUBPARTITION > 10TB и им не дают отдельное ТП, живут все вместе.

Вячеслав Любомудров
Vadim Lejnin
пропущено...
использование bigfile - имеет определенные засады, перед использованием рекомендую ознакомится
Вадим, проясни
Действительно интересно
Пока не юзаю, но иметь по 30 файлов на ТП уже накаляет


А если несколько ТП по 300+ файлов? :)

К тому что из документации стоит добавить почему НЕ использовать Bigfile если они 8-16TB+:
  • не все бэкап схемы могут корректно работать с большими файлами
  • время на бэкап одного файла может быть больше окна бэкапа, в случаях когда полный бэкап требует несколько окон. Желания не возникло проверять восстановление прерванного на активный день multi section backup
  • если обработка, например передача DBMS_FILE_TRANSFER прервётся, то надо начинать заново. Для большого файла это время.
  • ребелансинг большой дискгруппы может занимать много, очень много времени

    Из документации:
    автор
    Considerations with Bigfile Tablespaces
    Bigfile tablespaces are intended to be used with Automatic Storage Management or other logical volume managers that support dynamically extensible logical volumes and striping or RAID.

    Avoid creating bigfile tablespaces on a system that does not support striping because of negative implications for parallel execution and RMAN backup parallelization.

    Avoid using bigfile tablespaces if there could possibly be no free space available on a disk group, and the only way to extend a tablespace is to add a new datafile on a different disk group.

    Using bigfile tablespaces on platforms that do not support large file sizes is not recommended and can limit tablespace capacity. Refer to your operating system specific documentation for information about maximum supported file sizes.

    Performance of database opens, checkpoints, and DBWR processes should improve if data is stored in bigfile tablespaces instead of traditional tablespaces. However, increasing the datafile size might increase time to restore a corrupted file or create a new datafile.
  • 27 ноя 18, 23:31    [21746716]     Ответить | Цитировать Сообщить модератору
     Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
    Вячеслав Любомудров
    Member

    Откуда: Владивосток
    Сообщений: 17927
    master_yoda
    run09
    Предположим таблица 3 Тб. Только вставка. Насколько большим можно делать uniform?

    Для небольших БД лучше не надо UNIFORM, автомат вполне адекватен. Оно Вам надо потом по ночам таблицы/индексы туда-сюда двигать?
    Зачем что-то куда-то двигать?
    А вот то, что при AUTOALLOCATE максимальный размер экстента 256M (да и то, вроде только для размера блока 32K) уже увеличивает кол-во экстентов как минимум в 4, а скорее в 16 (для 64M экстента) раз по сравнению с гигабайтными экстентами
    master_yoda
    Вячеслав Любомудров
    Так там даже на 2Тб не получается всех документов (включая сканы в PDF)


    Есть не в единичных экземплярах TABLE SUBPARTITION > 10TB и им не дают отдельное ТП, живут все вместе.
    Даже не знаю, поздравить или посочувствовать

    master_yoda
    Вячеслав Любомудров
    пропущено...
    Вадим, проясни
    Действительно интересно
    Пока не юзаю, но иметь по 30 файлов на ТП уже накаляет


    А если несколько ТП по 300+ файлов? :)

    К тому что из документации стоит добавить почему НЕ использовать Bigfile если они 8-16TB+:
  • не все бэкап схемы могут корректно работать с большими файлами
  • время на бэкап одного файла может быть больше окна бэкапа, в случаях когда полный бэкап требует несколько окон. Желания не возникло проверять восстановление прерванного на активный день multi section backup
  • если обработка, например передача DBMS_FILE_TRANSFER прервётся, то надо начинать заново. Для большого файла это время.
  • ребелансинг большой дискгруппы может занимать много, очень много времени

    Из документации:
    автор
    Considerations with Bigfile Tablespaces
    Bigfile tablespaces are intended to be used with Automatic Storage Management or other logical volume managers that support dynamically extensible logical volumes and striping or RAID.

    Avoid creating bigfile tablespaces on a system that does not support striping because of negative implications for parallel execution and RMAN backup parallelization.

    Avoid using bigfile tablespaces if there could possibly be no free space available on a disk group, and the only way to extend a tablespace is to add a new datafile on a different disk group.

    Using bigfile tablespaces on platforms that do not support large file sizes is not recommended and can limit tablespace capacity. Refer to your operating system specific documentation for information about maximum supported file sizes.

    Performance of database opens, checkpoints, and DBWR processes should improve if data is stored in bigfile tablespaces instead of traditional tablespaces. However, increasing the datafile size might increase time to restore a corrupted file or create a new datafile.
  • Согласен, что с бэкапом (а особенно, с восстановлением) возможны траблы. Это, наверное, единственное на данное время существенное ограничение
    28 ноя 18, 15:11    [21747492]     Ответить | Цитировать Сообщить модератору
     Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
    Vadim Lejnin
    Member

    Откуда:
    Сообщений: 6422
    Вячеслав Любомудров,
    C bigfile основные засады уже перечислили
    + встречался целый пучок BUG связанных с ними
    и не дай бог создать bigfile на файловой системе, незабываемые ощущения гарантированы :)
    28 ноя 18, 15:26    [21747519]     Ответить | Цитировать Сообщить модератору
     Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
    master_yoda
    Member

    Откуда:
    Сообщений: 82
    Вячеслав Любомудров
    master_yoda
    Для небольших БД лучше не надо UNIFORM, автомат вполне адекватен.

    А вот то, что при AUTOALLOCATE максимальный размер экстента 256M (да и то, вроде только для размера блока 32K) уже увеличивает кол-во экстентов как минимум в 4, а скорее в 16 (для 64M экстента) раз по сравнению с гигабайтными экстентами

    Разве это проблема для "небольшой" 3ТБ БД?

    Вячеслав Любомудров
    с бэкапом (а особенно, с восстановлением) возможны траблы. Это, наверное, единственное на данное время существенное ограничение

    Технически бэкапы можно сделать достаточно быстрыми, 10T/час это реально, т.е. это больше HW задача. бОльшая проблема, что не смотря на 2019 на носу, всё ещё очень много костылей вокруг 2^32.

    Потому и
    Vadim Lejnin
    + встречался целый пучок BUG связанных с ними


    Уж лучше датафайлы скриптом добавлять, чем разбираться с чудесами, или переносить объекты в "нормальное" ТП, когда вылез BUG при достижении 2, 16, 32Т.
    BigFile тоже имеет лимит в 2^32 блоков ~32TB для 8к блока.
    28 ноя 18, 19:10    [21747815]     Ответить | Цитировать Сообщить модератору
     Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
    Vadim Lejnin
    Member

    Откуда:
    Сообщений: 6422
    master_yoda
    ....

    Уж лучше датафайлы скриптом добавлять, чем разбираться с чудесами, или переносить объекты в "нормальное" ТП, когда вылез BUG при достижении 2, 16, 32Т.
    BigFile тоже имеет лимит в 2^32 блоков ~32TB для 8к блока.


    +++
    Я добавлял сразу 4/10/20, да хоть сотню затравок файлов
    и путь они потихоньку подрастают
    ну и полюбил в последнее время OMF
    28 ноя 18, 20:16    [21747873]     Ответить | Цитировать Сообщить модератору
     Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
    run09
    Member

    Откуда:
    Сообщений: 29
    master_yoda
    Разве это проблема для "небольшой" 3ТБ БД?



    Ну,в сумме получается около 10 tb. А с какого момента, по вашему мнению, могут начаться проблемы и какие?
    29 ноя 18, 00:09    [21747961]     Ответить | Цитировать Сообщить модератору
     Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
    Вячеслав Любомудров
    Member

    Откуда: Владивосток
    Сообщений: 17927
    master_yoda
    Вячеслав Любомудров
    пропущено...

    А вот то, что при AUTOALLOCATE максимальный размер экстента 256M (да и то, вроде только для размера блока 32K) уже увеличивает кол-во экстентов как минимум в 4, а скорее в 16 (для 64M экстента) раз по сравнению с гигабайтными экстентами

    Разве это проблема для "небольшой" 3ТБ БД?
    Ну, ~50000 экстентов (64M) против ~3000 (1G) разница таки есть

    Но в битовых картах бит отвечает за один UNIFORM экстент (например 1G) или за 64K при AUTOALLOCATE

    С 11gR2 в каждом из 126 блоков битовых карт при 8K блоке юзается по 63488 бит, т.е. описывается UNIFORM экстентов или по 64K для AUTOALLOCATE. Т.е. в случае UNIFORM SIZE 1G одного битмап блока хватит почти на 60T, а для AUTOALLOCATE только для чуть меньше 4G
    Т.е. тот же запрос к тому же DBA_EXTENTS будет просто летать для UNIGORM SIZE 1G и жутко тормозить для AUTOALLOCATE (вот только кому он нужен, этот запрос )

    Кстати, я так понимаю, для ТП, сделанных в 11gR2 используется 1M (128 блоков при 8K) для заголовков файла, но раньше-то использовалось только 64K (8 * 8K), всякие 1st level BMB, 2nd, 3rd. И, похоже, там ничего не меняется при миграции. Т.е. чтоб заюзать это упрощение необходимо перестроить ТП К сожалению, совершенно нет времени все это проверить, а потом забуду

    PS. Я не умничаю, просто самому интересно стало. Здесь интересно написано
    29 ноя 18, 14:55    [21748674]     Ответить | Цитировать Сообщить модератору
     Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
    master_yoda
    Member

    Откуда:
    Сообщений: 82
    run09
    Ну,в сумме получается около 10 tb. А с какого момента, по вашему мнению, могут начаться проблемы и какие?


    Вряд ли вопросы изначально обсуждаемые в этом топике будут важнее чем тюнинг запросов и логики приложения.

    Одной информации о 10ТБ мало, проблемы это фукнция от даунтайма, размера и нагрузки. Пока с нагрузкой можно справиться при помощи железа - это не проблема, а денег мало :) 15 лет назад ~1ТБ база казалась пределом комфорта, сейчас комфортные ~15ТБ

    На железе не стоит экономить, all flash или, если RAC не нужен, NVME, 4x10Gb+ и т.п. Лицензии дороже железа на много.
    30 ноя 18, 00:54    [21749268]     Ответить | Цитировать Сообщить модератору
     Re: когда стоит использовать UNIFORM ALLOCATION у TABLESPACE'а  [new]
    run09
    Member

    Откуда:
    Сообщений: 29
    Вячеслав акцентирует внимание на Storage, уменьшая кол-во экстентов и их management в заколовках.
    oracle
    Normally it is recommended that the entire Segment should be contained in Single Extent so that Full Table Scan or Fast Full index Scan just have to traverse a single Extent But as such, it is not a must.Even if the Segment is spread over Hundred or Thousands Of Extents and if the extents are of even size with proper ‘db_file_multiblock_read_count’ defined, the Full Table Scan or Fast Full Index Scan still can improve performance


    Размер экстента поидее всегда должен быть multiple of DB_FILE_MULTIBLOCK_READ_COUNT. Этот параметр, с свою очередь, завязан на MAX IO SIZE на уровне OS, в случае же ASM это AU_SIZE дисковой группы (который должен совпадать с max_sectors_kb ядра Linux ? )

    Но так ли это важно для OLTP базы со средним размером I/O Large read = 18 Mb/sec с редкими пиками Direct Reads в 80 MB/sec. И на весь I/O в среднем 120 IOPs ?

    master_yoda, т.е. иными словами, - не стоит "экономить" на спичках (с размерами и кол-ом) экстентов на современном железе?
    30 ноя 18, 13:35    [21749916]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
    Все форумы / Oracle Ответить