База даних Oracle – системи вводу-виводу і робота з нею, Інші СУБД, Бази даних, статті

Давайте спробуємо розібратися, як домогтися найбільшої продуктивності при
роботи та звернень до БД 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);


Підхід дещо іншою, тому що тут виділяється пам’ять для кожної таблиці
окремо! Друге виділення пам’яті для таблиць дозволяє забезпечити більш гнучке
управління не тільки зростанням табличного простору, а й пов’язаних з ним
зміною продуктивності роботи. А от що робити у кожному разі, це
вже вирішувати вам! Основне потрібно чітко уявляти чого ви хочете від виший БД
перш за все. Якого типу вона буде! Думайте! Удачи! :-)))


Автор статті: Летючий Сергій

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*