Конфігурування сервера Oracle для надвеликих баз даних, Інші СУБД, Бази даних, статті

Анотація


Ця стаття допоможе читачеві налаштовувати надвеликі бази даних Oracle (Very Large Database, надалі – VLDB) для досягнення високої продуктивності і високої доступності при низьких витратах на експлуатацію. Вона описує рішення вибору розміру блоку даних Oracle, застосування RAID-технологій, використання «лінійних» пристроїв (raw-devices), конфігурування журнальних файлів, розбиття табличних просторів на розділи, вибору параметрів зберігання та налаштування сегментів відкату. Стаття описує технології і пов’язані з ними обмеження, а також технічно детальні методи для оптимізації конфігурації в рамках цих обмежень.


Зміст


1 Введення


VLDB є абревіатурою, прийнятої для позначення надвеликих баз даних (Very Large Database). Словосполучення «надвелика» має різне наповнення для різних людей, але воно завжди пов’язане з відчуттям труднощі, складності, високої вартості і ризику. VLDB є тим, що люди пов’язують з величезними базами даних, підтримка яких межує з мистецтвом. Потрібні велика винахідливість, вміння планувати, наполеглива праця та значні капіталовкладення для того, щоб уникнути дуже серйозних розчарувань при спробі впровадження VLDB.


1.1 Операційна складність

Операційна складність є очевидною проблемою VLDB. Як оператор VLDB Ви повинні постійно оцінювати безліч сильно пов’язаних параметрів. Система буде «карати» спроби застосувати радикальні або випадкові зміни. Величезні об’єкти і тривалі процеси залишають Вам мало простору для маневру при усуненні проблеми.


Це вимагає, в першу чергу, обережності при плануванні усунення проблеми. Стан сотень або навіть тисяч людей залежить від Вашої здатності швидко приймати правильні рішення. Тут потрібен талант і наполеглива праця.


Тривалість багатьох найважливіших процедур, наприклад резервне копіювання і відновлення, пропорційна розміру об’єктів, якими вони маніпулюють. Тому у великих БД ці найважливіші процедури можуть вимагати дуже великих часових інтервалів. З ростом БД вартість помилок збільшується. Операції – подібні реконфігурації диска, перестроювання об’єкта БД, підрахунку числа рядків у таблиці, відкоту транзакції, – можуть виглядати цілком необразливо в невеликих БД, але бути повністю неприйнятними для VLDB. Якщо дія вимагає декількох годин Вашого робочого часу, Ви повинні уникати його виконання.


1.2 Висока продуктивність

Збільшують складність і інші фактори. Розглянемо доступ до даних. Ви можете допустити використання неефективного запиту, який вимагає 2 секунди роботи процесора на високопродуктивної сучасної системі з 20 користувачами, але Ви не зможете допустити такий же час обслуговування в системі з 1,200 користувачами, де йде безперервна боротьба за фіксатори (latches), диски і процесорний час. Запити до VLDB повинні бути оптимізовані виключно добре, інакше система розвалиться.


Більш того, багато VLDB стають «VL» в першу чергу внаслідок великого числа одночасно працюючих користувачів та пакетних завдань, що створюють великий обсяг транзакцій. Великий обсяг транзакцій створює стресові ситуації в підсистемі введення / виводу пов’язані з генерацією redo-інформації і записом у файли даних. Високий рівень паралелізму процесів перевантажує фіксатори і механізми блокувань, розроблені для перекладу доступу до критичних ресурсів в послідовний режим (serialize).


1.3 Висока доступність

Чим більше обдумуєш проблему – тим вона складніше виглядає. VLDB часто є джерелом даних для важливих додатків з високими вимогами доступності. Розробники індустріальних СУБД чують формулу «Сім-днів-по-двадцять-чотири-години», а ми ціпеніючи від монументальної складності цього завдання. Зважаючи електричних і мережевих несправностей, неякісних модулів пам’яті і дискових контролерів, помилок додатків та операційних систем, модернізації ПО і устаткування і просто випадкових помилок оператора, – досягти декількох секунд або хвилин зупинки на рік вкрай складно. Як виявити і виправити логічні руйнування сотень і навіть тисяч гігабайт даних, які утворилися внаслідок помилкового введення оператора?


1.4 Подолання труднощів VLDB

Шлях до подолання труднощів, властивих VLDB, лежить у спрощенні БД настільки, наскільки це можливо. Ви оптимізуєте як СУБД, так і сам додаток для зниження будь-яких видів навантаження. Ви вибираєте структури даних, які мінімізують введення / виведення при доступі до даних. Ви створюєте додатки з максимально простими транзакціями. Ви ізолюєте вплив вийшли з ладу компонент на мінімально можливі підмножини даних. Ви робіть одиниці резервного копіювання і відновлення мінімально можливими.


Нижче перераховані деякі аспекти, що дозволяють побудувати хорошу VLDB:



У цій статті ми досліджуємо рішення для фізичної конфігурації БД, необхідні для успішної побудови VLDB.


2 Розмір блоку СУБД Oracle


Іронія життя – в той день, коли Ваш досвід в управлінні сервером Oracle мінімальний, Вам необхідно ввести значення для параметра db_block_size, Яке буде в подальшому незмінне протягом всього життя БД. Важливо те, що значення, яке Ви обрали для розміру блоку даних Oracle, надає сильний вплив на продуктивність системи. Наступні розділи звернуть Вашу увагу на деякі компроміси, які необхідно розглянути перед вибором розміру блоку даних Oracle для Вашої бази даних.


Оптимальний розмір блоку даних Oracle для VLDB лежить в межах від 4KB до 64KB. Найбільш часто використовуваним є значення 8KB і, на другому місці, – 16KB. Сервер СУБД Oracle, встановлений на системі з дуже швидкою реалізацією копіювання великих обсягів пам’яті може ефективно працювати з розміром блоку в 32KB і навіть (як мінімум, теоретично) з 64KB. Я не знайомий з обставинами, які могли б вимагати вибору розміру блоку для VLDB в 2KB і лише в дуже спеціальних випадках розмір в 4KB буде підходящим для VLDB. В [6, Millsap (1996)] я давав розгорнуте технічний опис цього питання, тут ми обмежимося лише висновками 1.


2.1 Зменшення навантаження на введення / виведення

Найбільш важливою характеристикою найскладніших реалізацій VLDB є величезне навантаження на введення / виведення. Власники кращих світових VLDB вкладають великі гроші в засоби, здатні зменшити навантаження на введення / виведення в їх системах. Використання великого розміру блоку даних СУБД Oracle є простою технікою для зменшення деяких видів навантаження на введення / виведення.



2.2 Поліпшення використання простору

Сервер Oracle зберігає невеликий обсяг службової інформації фіксованого розміру в кожному блоці БД незалежно від того, який обсяг даних користувача зберігається в цьому блоці. Таким чином, чим менше блоків знаходиться в БД, тим менше простору буде витрачено на накладні ці витрати. Для дуже малих сегментів виграш від економії на фіксованих накладних витратах може обернутися втратою простору за рахунок невикористовуваних завершальних блоків сегмента, але ці втрати, у свою чергу, незначні в порівнянні з втратами, викликаними неточним завданням параметрів зберігання 2. Використання великого розміру блоку Oracle для дуже великих сегментів зберігає приблизно від двох до шести відсотків загального обсягу бази даних.


Цей виграш веде до підвищення продуктивності і зниження вартості експлуатації, що особливо помітно на зниженні часу резервного копіювання / відновлення.


2.3 Запобігання вузьких місць при паралелізмі

Використання великого розміру блоку даних Oracle збільшує ризик виникнення вузьких місць при спільному доступі за винятком випадків, коли архітектор бази даних розуміє як використовувати параметри зберігання initrans і maxtrans. Значення initrans повинно бути встановлено в максимально очікуване число транзакцій, одночасно маніпулюють блоком даних 3. Таким чином, якщо Ви збільшили розмір блоку даних Oracle в k разів, то Вам необхідно збільшити значення параметра initrans також в k разів. Для того щоб дозволити динамічно рости «таблиці списку входів транзакцій», Вам необхідно встановити значення параметра maxtrans в значення, що перевищує значення initrans 4.


Невдалий вибір параметрів initrans і maxtrans для сегментів бази даних може бути причиною виникнення очікувань сесії користувачів. Сесії, які змінюють блок, який має цю проблему, будуть заважати іншим сесіям отримати входи в структуру даних блоку, яка дозволяють робити реконструкцію даних для досягнення несуперечності читання. Ця ситуація, що має назву ITL-конкуренція, може бути виявлена ​​адміністраторами БД за допомогою подання v$lock. Спостереження будуть показувати сесії, які очікують на блокуванні TX (Черга транзакцій) в режимі блокування 4 (Поділюваний доступ).


Ви в змозі повністю уникнути цих проблем, використовуючи відповідні техніки, описані в стандартній документації компанії Oracle по налаштуванню параметрів initrans і maxtrans для сегментів БД.


2.4 Компроміси

Хоча великий розмір блоку даних Oracle має переваги для VLDB, є певні обмеження на максимальний розмір блоку даних який Ви можете вибрати.



3 Дискова конфігурація


Серцем хорошою СУБД є надійна і продуктивна підсистема вводу / виводу. Тому проектування підсистеми введення / виведення – важлива тема при створенні будь-якої програми з використанням VLDB.


3.1 Структурний аналіз конфігурації

На найвищому рівні абстракції визначення вимог до системи є простою справою, оскільки всі ми бажаємо трьох речей: продуктивності, надійності та низької вартості. Однак коли ми перетворимо ці загальнозначущі цілі у щось конкретне, ми стикаємося з рішеннями, заснованими на компроміси. Для розуміння виниклих конфліктів, Ви повинні зробити дві речі: (1) зрозуміти Ваші цілі і (2) розібратися в Ваших технологіях. Весь фокус полягає в пошуку вірної мікстури з швидкості, надійності і вартості, яка задовольнить специфічні потреби Вашого бізнесу. Це означає що рішення, вірне для Вас, не завжди буде підходящим для Вашого сусіда.


Архітектурні обмеження приходять до нас з двох джерел: (1) це економічні обмеження та (2) це технологічні обмеження. Економічні обмеження Вам повинні бути зрозумілі дуже добре, і я впевнений, Ви не бажаєте мати з ними справу. Однак, навіть якщо уявити, що Ви можете придбати будь-яке обладнання та програмне забезпечення, яке тільки побажаєте, Ви все одно зіткнетеся з обмеженнями технологічними.


Припустимо, наприклад, що Ви маєте OLTP-додаток і Ви оптимізували дискову конфігурацію Вашого сервера Oracle для досягнення максимальної продуктивності при випадковому введенні / виводі на шкоду продуктивності послідовного доступу до даних. Таке рішення може виглядати цілком розумним, оскільки доступ до файлів OLTP-бази даних в переважній більшості заснований на операціях читання з використанням добре певних індексів або хеш-структур, а також довільних (scattered) операціях запису.


Проте перший же досвід реорганізації індексу на дисковому масиві, оптимізованому виключно для доступу в умовах високого паралелізму, зажадає на 300-500 відсотків більше часу, ніж це могло б зайняти в іншій дискової конфігурації. Ваше безкомпромісне рішення про оптимізацію OLTPпроізводітельності безпосередньо знизить доступність Вашої системи внаслідок збільшення тривалості недоступності індексу під час його реорганізації.


Цей приклад, як сотні подібних, вказують нам на важливість і трудомісткість розуміння Ваших вимог і осягнення Ваших технологій. Найбільш важливим Вашим інструментом повинен стати метод структурного аналізу, який допоможе Вам знайти правильні відповіді на Ваші запитання. У цій статті ми буде структурувати аналіз конструкції підсистеми введення / виводу за допомогою розбиття на продуктивність, доступність і вартість:



У статті ми оцінимо кілька інструментів і технік в контексті цих категорій. Їх опис дано в наступних розділах.


3.1.1 Продуктивність


3.1.2 Доступність


3.1.3 Вартість


3.1.4 Метод аналізу

Декомпозиція на продуктивність, надійність і вартість дає нам важливий інструмент для побудови гарної системи. Він дозволяє нам оцінити компроміси як в межах однієї категорії (наприклад – швидкість виконання випадкового читання за рахунок послідовного читання), так і зрозуміти вплив однієї категорії на іншу (наприклад – сильний зв’язок між швидкістю виконання послідовної записи і тривалістю простою).


Ці категорії також дозволяє нам формалізувати наші міркування про систему. Приміром, розуміння різних складових поняття надійності дає нам можливість вивчати їх незалежно: (1) ми можемо фокусувати зусилля на зниженні частоти відмов або (2) ми можемо спробувати знизити тривалість простоїв внаслідок відмов, які ми запобігти не в силах. І це нагадує нам ще раз, що тривалість простою є частково питанням надійності, а частково – питанням продуктивності.


Наступні розділи допоможуть Вам провести високорівнева аналіз взаємозв’язків продуктивності, доступності та вартості при проектуванні підсистеми введення / виводу для СУБД Oracle. Цей розділ допоможе Вам краще зрозуміти Ваші завдання і технології, допоможе зробити Вам більш поінформовані рішення, щоб Ви отримали найкращий результат від Ваших інвестицій.


3.2 RAID

На другому місці за ненадійності, після людини, в комп’ютерних системах, є жорсткий диск. Для збільшення надійності дисків більшість постачальників рішень сьогодні пропонують дискові масиви, звані RAID – надлишкові масиви недорогих дисків (redundant arrays of inexpensive disks). RAID-масиви являють собою високопродуктивні, стійкі до відмов підсистеми введення / виводу, які використовують менш дорогі технології жорстких дисків ніж ті, що використовуються в традиційних високонадійних великих ЕОМ.


Поняття RAID було введено в 1987 році в статті, опублікованій в Каліфорнійському Університеті [9, Patterson et al. (1988)]. Номери рівнів RAID означають різну організацію простих технологій дисків для досягнення продуктивності і надійності при відносно невисокій вартості.


Найбільш важливими рівнями RAID, які повинен розуміти архітектор VLDB Oracle є 0, 0 +1, 3 і 5. Рисунок 1 дає концептуальне уявлення про ці RAID-конфігураціях. Зверніть увагу, що постачальники RAID можуть обрати для реалізації функцій чергування і віддзеркалення або програмне, або апаратне рішення. Цей вибір впливає на кількість і типи контролерів необхідних для реалізації RAID-масиву.


Продуктивність, пропонована RAID-конфігураціями, вражає. За рахунок рівномірного розподілу фізичного навантаження введення / виводу по всіх дисках, RAID-масиви з чергуванням показують незрівнянне час відповіді і пропускну здатність. Масив з чергуванням з п’яти дисків може показати майже в п’ять разів більшу продуктивність при послідовному введенні / виводі в порівнянні з незалежною конфігурацією дисків того ж розміру.


Так само вражає перевагу RAID-масивів в надійності. Дискова система, що складається із сотні дисків з MTTF рівною 200.000 годин, сконфигурированная без надмірності має середній час до втрати даних (MTTDL) менше ніж 83 дня. Та ж сотня дисків, організована в RAID-масив з наявністю надмірності мають MTTDL близько 26 років [Chen et al. (1992), 161-163]. Середній час відновлення RAID-конфігурацій також чудово. Ви можете вилучити диск з активного RAID-масиву 5 рівня і система, тим не менш, буде продовжувати працювати.


Проте, кожна RAID-конфігурація має свою, унікальну, вартість. Ви можете виявити, що система, яка дійсно задовольняє Вашим потребам занадто дорога, а конфігурація, яку Ви в стані собі дозволити, несе з собою багато компромісних рішень. Архітектори систем на базі СУБД Oracle повинні рухатися в звивистому лабіринті компромісів, приймаючи рішення про спосіб застосування RAID-масивів.


Кілька авторів зробили блискучу роботу, описуючи RAID-конфігурації і оцінюючи RAID-структури з точки зору надійності, продуктивності і вартості ([1, Chen et al. (1994)]; [2, Gui (1993)]; [11, Sun (1995)]; і багато інших). Наступні розділи містять підсумки цих ідей з конкретними рекомендаціями про те, коли і як використовувати кожен тип RAID-масиву для додатків СУБД Oracle.


3.2.1 Визначення

Навчальна література про RAID може іноді ввести в оману, оскільки автори з кон’юнктурних міркувань можуть інтерпретувати визначення так, як їм необхідно. Для того, щоб зробити цю статтю максимально простий, визначимо попередньо деякі терміни.



Читаючи цей документ, важливо пам’ятати що, масив є колекцією дисків, і що чергування полягає в розподілі порцій даних в межах масиву. Малюнок нижче показує один дисковий масив, що складається з п’яти дисків. Кожен диск містить п’ять сегментів чергування, загальне число яких становить 25.

3.2.2 Чергування без надмірності (RAID рівня 0)

RAID 0 є дискової конфігурацією без надмірності з чергуванням. Чергування, сконфигурированное відповідним чином, дає виключно хороший час відповіді при випадковому доступі з високим рівнем паралелізму, і чудову пропускну здатність при послідовному доступі з низьким рівнем паралелізму. Вибір ширини сегмента чергування масиву вимагає уважного розгляду різних обмежень. Ми обговоримо деталі оптимізації розміру сегмента чергування пізніше.


Дискові конфігурації без надмірності корисні в тих випадках, де обмеження на вартість придбання переважують вимоги до надійності системи.



3.2.3 Віддзеркалення (RAID рівня 1)

Віддзеркалення є фундаментальним інструментом архітектора VLDB для зниження частоти відмов дисків. Диски з підтримкою дзеркальних копій – це системи, в яких ідентичні копії Ваших даних записуються на два або більше дисків при кожній операції запису, що дозволяє Вашим додаткам працювати до тих пір, поки ціла хоча б одна з копій. Незважаючи на те, що спостерігається певна втрата продуктивності при виконанні операції запису в масивах з дзеркалювання в порівнянні з конфігураціями без надмірності, дзеркалювання забезпечує найкращу продуктивність операції запису серед дискових конфігурацій, стійких до збоїв. Віддзеркалення особливо корисно для зберігання файлів даних Oracle з високою інтенсивністю записи. Багато архітекторів використовують дзеркалювання для захисту оперативних і архівних журнальних файлів навіть тоді, коли вартісні обмеження не дозволяють використання зеркалирования всієї дискової підсистеми.


Дублювання адаптерів, шин і джерел живлення робить дзеркалювання ще більш нечутливим до відмов обладнання. В продубльований конфігурації з зеркалювання, n-рівнева надмірність використовує n однакових адаптерів. На сьогоднішній день кілька клієнтів компанії Oracle використовують трирівневе дублювання для досягнення гнучкості операції відновлення. Потрійне дзеркалювання забезпечує стійкість до відмов подібно подвійному віддзеркалення і дозволяє адміністратору БД відновлювати СУБД на будь-який час в минулому без використання стримерів. Пізніше ми обговоримо одну техніку потрійного дублювання.











1
Щоб не змушувати Вас шукати зазначений документ компанії Oracle, що до речі є не простою справою, скажу, що одним із спеціальних випадків, коли вибір в 4KB буде відповідним, полягає в наявності величезного числа невеликих сегментів (менше 100KB).
2
Як ми обговоримо пізніше, наближене завдання параметрів зберігання є хорошим компромісним рішенням, що знижує вартість експлуатації, в порівнянні з VLDB з дуже точно заданими параметрами зберігання.
3
Під транзакцією тут розуміється виконання операторів insert, update, delete, або select. . . for update
4
Формально, «таблиця списку входів транзакцій» називається списком цікавляться транзакцій (interested transactions list), або ITL.
5          
Зверніть увагу – striping пишеться з однією літерою p.

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


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

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

Ваш отзыв

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

*

*