Давайте попробуем разобраться, как добиться наибольшей производительности при работе и обращениям к БД Oracle. Например, начнем с того, как вообще строится сервер БД. Как правило он имеет массив хард дисков (винчестеров, венеков и т. д.!) Они могут быть IDE или SCSI. В свою очередь, они могут быть в RAID массивах или без таковых. Все это только для примера при выборе оборудования. В руководстве Oracle, как правило рекомендуют размещать каждое табличное пространство на отдельном диске. Как, например SYS, TEMP, INDEX и т.д. В наших с вами условиях это не всегда получается и приходится исходя из возможностей строить максимум из минимум доступного! При построении такой БД, как правило, неизбежны конфликты при обращении к жесткому диску (disk contention). Такого рода конфликт может возникать, когда один или несколько пользователей, работают с одним и тем же жестким диском сервера. Если, к примеру две таблицы большого объема имеют в запросах объединения, то их табличные пространства следует размещать на разных хард драйвах! Хотя я что-то опять размечтался! То же касается и индексов и сегментов отката! Идеальная картинка будет именно тогда когда, все эти разделы (табличные пространства) расположены на разных дисках системы. Кстати у меня эта заветная мечта так и не осуществилась - хотя у меня в системе три сервера, на двух из которых стоит Oracle. Кто знает может вам повезет больше! :) Это первое минимальное требование. Но в принципе, если все спланировать и на двух SCSI драйвах, то тоже работает и не плохо! Далее, при создании схем не забывайте про то, где будет данный пользователь размещать свои объекты БД. Если что-то пошло не так можно применить следующий ход:
ALTER USER <ПОЛЬЗОВАТЕЛЬ> DEFAULT TABLESPACE <ДРУГОЕ ТАБЛИЧНОЕ ПРОСТРАНСТВО>
TEMPORARY TABLESPACE TEMP (или другое на выбор)
Собственно кроме определения самого типа приложения (typing the application) сразу классифицируйте таблицы по уровням активности. Очень активные таблицы (hot table), размещают как можно ближе к дискам SCSI, а таблицы типа warm table и cold table, можете раскидывать по IDE RAID-ам. Чем больше DML - операций тем, больше фрагментация в табличных пространствах. Тем больше вам головной боли как DBA! Далее можно посмотреть в сторону блоков и экстентов! Как вы уже поняли я думаю в Oracle блоки собраны в экстенты, которые образуют физическую среду хранимых табличных пространств. Следовательно чем эффективнее управление экстентами, тем выше производительность системы в целом! Так же неоправданное увлечение динамическим выделением памяти приводит к большим накладным расходам и снижению производительности операций ввода-вывода. По этому по мере возможности применяйте статическое предварительное выделение памяти для сегментов БД (таблиц, индексов и т.д.). То есть при указании задаваемых табличных пространств с последующим предварительным выделением памяти для таблиц можно с несколько большей гибкостью комбинировать в одном и том же табличном пространстве таблицы с разными требованиями по отношению к экстентам. Можно привести такой пример:
CREATE TABLESPACE TS1 DATAFILE '/data1/file1.dat' SIZE 256M DEFAULT STORAGE (INITIAL 100M NEXT 100M MINEXTENTS1); CREATE TABLE T1 (a number(9), ..., z number(9)) TABLESPACE TS1; CREATE TABLE T2 (a number(9), ..., z number(9)) TABLESPACE TS1;
Здесь выделение памяти производится предварительно для всего табличного пространства. Вернее для двух таблиц вместе.
А вот в этом случае:
CREATE TABLESPACE TS1 DATAFILE '/data1/file1.dat' SIZE 256M; CREATE TABLE T1 (a number(9), ..., z number(9)) TABLESPACE TS1 STORAGE (INITIAL 100M NEXT 10M MINEXTENTS 1); CREATE TABLE T2 (a number(9), ..., z number(9)) TABLESPACE TS1 STORAGE (INITIAL 100M NEXT 10M MINEXTENTS 1);
Подход несколько иной, так как здесь выделяется память для каждой таблицы отдельно! Второе выделение памяти для таблиц позволяет обеспечить более гибкое управление не только ростом табличного пространства, но и связанным с ним изменением производительности работы. А вот как поступать в каждом случае, это уже решать вам! Основное нужно четко представлять чего вы хотите от вышей БД прежде всего. Какого типа она будет! Думайте! Удачи! :-)))