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

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

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

Весь остальной зоопарк - в ТП с AUTOALLOCATE, хотя здесь могут возникнуть те же проблемы по выделению большего экстента, чем свободные. Но, мне кажется, в боевых БД (нет удалений объектов и трункейтов) это не критично.

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

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


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

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

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

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

Я просто не понимаю, как может один сегмент быть 3 Тб
Может таки это отдельный LOB-сегмент?
Ты действительно адекватно оцениваешь ситуацию?

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

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

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

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

использование bigfile - имеет определенные засады, перед использованием рекомендую ознакомитсяВадим, проясни
Действительно интересно
Пока не юзаю, но иметь по 30 файлов на ТП уже накаляет
Хотя, мне кажется, тут имеет приоритет место хранения

master_yodarun09Предположим таблица 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 .
Согласен, что с бэкапом (а особенно, с восстановлением) возможны траблы. Это, наверное, единственное на данное время существенное ограничение

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. Я не умничаю, просто самому интересно стало. Здесь интересно написано