Вопрос по структуре табличных пространств на Oracle

[Eldar9x]

Axapta 3.0, Oracle 10g. Предполагаемый размер базы данных - сотни гигабайт.
Колеги, поделитесь, пожалуйста, информацией, как вы распределяете датафайлы по табличным пространствам. Интересует количество и размеры датафайлов в каждом табличном пространстве при развертывании аксаптовой базы данных: ТС для самих таблиц, ТС для индексов и ТС для временных таблиц.
Можно, конечно, создать по одному файлу для каждого ТС и поставить autoextend для них. Но правильно ли это или есть более производительная схема?
Спасибо.

[egorych]

Я выделили в отдельный TS таблички - DATABASELOG, SYSDATABASELOG и SYSISERLOG. Ну и индексы для них.
Нужно-ли для индексов отдельное TS - пока не знаю. Еще можно отдельный TS сделать для табличек разработчиков - типа XREF...
По поводу big tablespace консультровался - было сказано, что для производительности в общем не критично - чисто для удобства обслуживания.

[Eldar9x]

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

[egorych]

Цитата:

Сообщение от Eldar9x

то есть в каждом табличном пространстве по одному файлу? А какой стартовый размер файла указывали и какое значение инкремента указывали?

Не, для рабочих таблиц я задал обычный TS - пока 4 файла по 10Г, а вот для лога сделал big tablespace с 1 файлом.
Про индекса - хз как правильней, мож кто подскажет. Хотя, думаю если это все на 1 массиве лежит, то пофих как делать, а втот если есть возможность разнести по разным каналам - то есть смысл повыпендриваться.

[Андре]

Цитата:

Сообщение от egorych

Нужно-ли для индексов отдельное TS - пока не знаю.

Достаточно спорный вопрос.

Идея хранения индексов отдельно от данных появилас в 80-х, когда размер баз данных были не так велики и когда был смысл разносить их по разным дискам. Сейчас, когда есть logical volumes, raid и т.д. - выигрыш от этого сомнителен.

Кроме того, индекс и данные не могут читаться параллельно - даже если они лежат в разных файлах. Индекс указывает где лежат данные, поэтому всегда сначала читается индекс, а потом данные.

С другой стороны, желательно, чтобы все tablespace были locally managed с uniform extends size. А вот из этих соображений индексы есть смысл вынести в отдельный tablespace, так как табличка, например c 50 столбцами, может располагаться в tablespace c 5Mb extends size. А индексам будет достаточно 512Kb extends size.

[ZVV]

Цитата:

Цитата:

Сообщение от Oracle

One popular approach to manual I/O distribution suggests separating a frequently
used table from its index. This is not correct. During the course of a transaction, the
index is read first, and then the table is read. Because these I/Os occur sequentially, the
table and index can be stored on the same disk without contention. It is not sufficient
to separate a datafile simply because the datafile contains indexes or table data. The
decision to segregate a file should be made only when the I/O rate for that file affects
database performance.

[Eldar9x]

это что ж, выходит таблицы и индексы надо сливать в один файл...

[ZVV]

Цитата:

Сообщение от Eldar9x

это что ж, выходит таблицы и индексы надо сливать в один файл...

Почему так категорично? Там написано просто, что это не так принципиально... И разносить ТС по разным дискам нужно не по принципу таблицы-индексы, а по принципу распределения I/O нагрузки.

Естественно, всё это касается только "Manually Distributing I/O":

Цитата:

Сообщение от Oracle® Database Performance Tuning Guide

If your system does not have an LVM or hardware striping, then I/O must be
manually balanced across the available disks by distributing the files according to each
file's I/O requirements. In order to make decisions on file placement, you should be
familiar with the I/O requirements of the database files and the capabilities of the I/O
system.
....
The decision to segregate files should only be driven by I/O rates, recoverability
concerns, or manageability issues.

Насчёт Количества файлов и их размеров - это больше вопрос стратегий восстановления и вообще управляемости данными файлами, а не производительности. Проще управлять обычно несколькими файлами средних размеров, чем одним огромным.
Насчёт влияние фрагментации датафайлов на уровне ОС - на самом деле она не оказывает обычно существенного влияния на общую производительность. Связано этот с тем, что головки диска и так мечутся туда-сюда по диску при доступе к данным. Дело в том, что в общем случае даже экстенты одного сегмента (таблицы, индекса, etc..) распределены достаточно произвольно в файле данных (или даже по нескольким файлам одного ТС, если их несколько). Если уж вы совсем идеалист, то можно и на уровне ОС переодически дефрагментацию делать, если есть такая возможность.
Но всё равно многие предпочитают не выставлять AUTОEXTEND (особенно на SYSTEM TS ) по тем же причинам, чтоб не получить неожиданного неуправляемого роста какого-то файла (особенно когда на БД работают параллельно разработчики - всего можно ожидать ). Вместо этого проводится постоянный мониторинг использования места в ТС и превентивное принятие мер по их расширению, перемещению, добавлению файлов и т.п..

Как то в общем так.. Если хочется более подробного описания, то по данной проблеме в инете есть море статей, поищите... Кое-что можно найти и в "Oracle® Database Performance Tuning Guide", ссылки из которого я уже приводил...

И ещё, а что вы подразумеваете под "ТС для временных таблиц" в контексте БД Аксапты? Аксапта не создаёт своих временных таблиц в БД, а обрабатывает их на уровне файлов ОС.

[Eldar9x]

Цитата:

что вы подразумеваете под "ТС для временных таблиц" в контексте БД Аксапты? Аксапта не создаёт своих временных таблиц в БД, а обрабатывает их на уровне файлов ОС.

В мастере утсановки серверной части предлагается выбрать два табличных пространства:

Цитата:

Select default tablespace for Axapta system tables and temporary data

и два поля: Default data и Temporary.
Для чего это, непонятно. Может используется как-то в совокупности с обычными временными файлами или еще для чего... В любом случае, интересно было бы узнать

[ZVV]

Цитата:

Сообщение от Eldar9x

В мастере утсановки серверной части предлагается выбрать два табличных пространства:
Select default tablespace for Axapta system tables and temporary data
и два поля: Default data и Temporary.
Для чего это, непонятно. Может используется как-то в совокупности с обычными временными файлами или еще для чего... В любом случае, интересно было бы узнать

Первое - это собственно ТС для размещения всех таблиц (и индексов) по умолчанию. Более тонкую настройку можно в Настройках Oracle в п.м. Администрирование в Аксапте.
Второе - это ТС для произведения всех операций сортировки. Это ТС специального типа - Temporary TableSpace, которое нужно создать в Оракле. Оно может быть задано на уровне БД (Default Temporary Tablespace) либо уточняться для каждого пользователя.

Цитата:

Сообщение от Oracle Concepts

All operations that use sorts, including joins, index builds, ordering, computing aggregates (GROUP BY), and collecting optimizer statistics, benefit from temporary tablespaces.

Используютcя эти 2 параметра, насколько я понимаю, при создании пользователя Oracle для БД Аксапты:

CREATE USER <user> ..... DEFAULT TABLESPACE <permanent_tablespace> TEMPORARY TABLESPACE <temp_tablespace>