MS SQL Server і кешуючий дискові контролери + FAQ, MS SQL Server, Бази даних, статті

sql.ru

За матеріалами статті Microsoft Knowledge Base “INF: SQL Server and Caching Disk Controllers”.
Інформація в цій статті ставиться до Microsoft SQL Server версій: 4.2x, 6.0, 6.5, 7.0, 2000.

Використання дискових контролерів, кешуючий запис (такий механізм називається відкладеної
записом – write back caching), може істотно підняти ефективність SQL Server. Дискові
контролери (кешуючий запис) і дискові підсистеми можуть бути безпечні для SQL Server,
якщо вони спеціально розроблені для використання в критичною до втрати даних середовищі, якими
є сучасні системи управління базами даних (DBMS – СУБД) використовують транзакційні
механізми обслуговування інформації. Ці їх особливості повинні запобігати втрату кешованих
дані, якщо відбувається відмова системи. Досягти цього тільки шляхом використання джерел безперебійного
живлення (ДБЖ – UPS) не достатньо, тому що система може відмовити з причин, які не пов’язані з
енергозабезпеченням. Використання більшості кешуючий контролерів і дискових підсистем може
бути безпечно для роботи спільно з SQL Server. Сучасні серверні платформи, як правило,
безпечні. Проте, Ви повинні отримати у свого постачальника серверних рішень інформацію про те, що
дискова підсистема була перевірена та схвалена для використання в транзакционной середовищі RDBMS.
Інструкції SQL Server, модифікують дані, ініціюють запис логічних сторінок. Цей потік
записуваних сторінок, може мати два місця призначення: журнал реєстрації транзакцій або
безпосередньо сама база даних. Що б підвищити ефективність цих операцій, SQL Server затримує
запис в базу даних, розміщуючи сторінки в кеші даних, буферізіруя, таким чином, систему запису
модифікованих сторінок. Запис у журнал транзакцій має дуже маленьку затримку після
отримання інструкції COMMIT. Вони не кешуються також як дані. Оскільки реєстрація
змін сторінок в журналі завжди передує записи сторінок даних, журнал реєстрації транзакцій
іноді називають журналом “write-ahead”.
Цілісність транзакцій – одна з фундаментальних завдань, яке вирішується сучасної СУБД. Транзакції
є не подільними, цілісними модулями інструкцій, які виконуються повністю або
відкочуються повністю назад. Журнал реєстрації транзакцій SQL Server (write-ahead), це життєво
важливий компонент у системі підтримки цілісності транзакцій. Будь СУБД повинна включати систему
підтримки цілісності транзакцій, яка дозволяє відновлювати працездатність бази після
незапланованих відмов системи. На жаль, ідеальну з цієї точки зору систему створити дуже важко і
тому подібні відмови все-таки можуть траплятися. Для багатьох СУБД відмова системи може призвести до
необхідності виконання дуже тривалих, ручних процедур по відновленню цілісності
даних або по заповненню втраченої інформації. Навпаки, механізм відновлення даних після
збою в SQL Server повністю автоматизований і працює без втручання оператора. Наприклад, SQL
Server може підтримувати критичне додаток, промислову прикладну програму, і пережити
відмова системи через миттєвого коливання напруги в електромережі. Після відновлення електроживлення,
апаратні засоби сервера перезавантажать програмне забезпечення операційної системи і SQL Server.
Після запуску, SQL Server автоматично виконає процес відновлення, заснований на даних в
журнал реєстрації транзакцій. Цей процес повністю проходить без втручання оператора. Всякий
раз, після перезавантаження своїх робочих станцій, користувачі можуть переконатися, що їхні дані не постраждали,
включаючи останню транзакцію, яку вони ввели. Механізм підтримки цілісності транзакцій SQL
Server і автоматичного відновлення являє собою дуже потужний засіб підтримання високої
продуктивності системи в будь-який час (time-and-labor).
Якщо дисковий контролер, кешуючий дані, не розроблений для використання в транзакционной середовищі
СУБД, це може поставити під загрозу здатність SQL Server відновлювати дані, що може призвести
до руйнування бази даних. Це може статися, якщо контролер втручається в роботу журналу реєстрації
транзакцій SQL Server, і буферизует їх у власному апаратній кеші контролера, але не може зберегти
ці записані в його кеш сторінки в момент відмови системи. Більшість сучасних дискових контролерів
мають опцію кешування запису, але не всі вони дозволяють цю опцію відключати. Навіть якщо сервер
використовує UPS, це не гарантує, що кешування запису буде захищене. Безліч типів системних
відмов відбувається з причин, не залежних від UPS. Наприклад, помилка парності пам’яті, зависання
операційної системи або апаратний збій, який провокує перезавантаження системи, можуть спричинити
за собою неминуче переривання роботи системи. Відмови пам’яті і апаратних засобів введення / виводу, можуть
привести до того, що інформація в кеші контролера буде втрачена.
Інша можлива проблема, пов’язана з використанням кешуючого запис контролера, може
проявлятися під час завершення роботи операційної системи. Іноді необхідно періодично
перезавантажувати операційну систему або перезавантаження ОС потрібна для внесення змін до її конфігурацію.
Навіть якщо оператор буде слідувати рекомендації про те, що до початку перезавантаження операційної системи
необхідно дочекатися, щоб дискові операції припинилися, кешування запису може все ще виконуватися
контролером. Коли виповнюється комбінація клавіш CTRL + ALT + DEL, або натиснута кнопка RESET, операції
кешування запису можуть бути перервані, що потенційно може призвести до пошкодження бази даних.
При проектуванні апаратних засобів кешування запису, фірмою виробником дискових контролерів
повинні прийматися до уваги всі можливі причини втрати “брудних” даних кеша, щоб убезпечити
бази даних. У числі заходів, які можуть бути зроблені розробником такого контролера, можна назвати:
переривання сигналу RST шини контролера, який дає команду на негайний скидання кеша контролера;
наявність власного акумулятора в контролера; наявність дзеркальної або ERC пам’яті (error checking correcting).
При придбанні дискового контролера, для сервера СУБД, переконайтеся у Вашого постачальника, що цей контролер
має перераховані опції або будь-які інші особливості, що дозволяють уникнути втрати даних з власного
кешу контролера.

FAQ на тему використання кешуючий дискових контролерів з MS SQL Server

За матеріалами статті Microsoft Knowledge Base “INF: Using Hard Disk Controller Caching with SQL Server”.
Інформація в цій статті ставиться до Microsoft SQL Server версій: 4.2x, 6.0, 6.5, 7.0

Питання
Чи можливі проблеми при використання кешуючого дискового контролера, що працює в складі
SQL Server, якщо до сервера підключений UPS, щоб уникнути порушення цілісності даних через збій харчування?
Відповідь
Якщо дисковий контролер коли-небудь не зможе записати кешируємой їм дані, призначені для
журналу реєстрації транзакцій SQL Server, механізм відновлення сервера баз даних не зможе працювати правильно.
Питання
Який ефект надає використання кешуючого дискового контролера на ефективність роботи
SQL Server?
Відповідь
Якщо кеш дискового контролера завжди буде записаний на диск так, як це передбачалося роботою
сервера (навіть при отриманні команди з клавіатури на перезавантаження, при збої операційної системи або
при збої жорсткого диска), проблем у роботі СУБД не виникне. З іншого боку, якщо дисковий контролер
не зможе здійснити запис деяких даних журналу реєстрації транзакцій SQL Server і затримає
фізична застосування будь-яких даних журналу реєстрації транзакцій (через використання типу сортування
«Elevator»), і не зможе записати залишилася не застосованої частина даних (ймовірність такого
збігу обставин не виключена); SQL Server ніколи не дізнається, що частина записів журналу реєстрації
транзакцій відсутня. Процедура регенерації даних при старті сервера або навіть послідовне відновлення
повної копії бази з подальшими копіями журналу транзакцій (включаючи копію журналу після збою) не зможе
привести до правильного відновлення бази даних. В найгіршому випадку, процедура регенерації даних,
після втрати даних кеша контролера (що призвела порушення цілісності даних), пройде успішно, а втрата
даних буде виявлена ​​набагато пізніше.
Якщо дисковий контролер розроблений для використання у складі СУБД, він повинен вміти правильно використовувати
метод наскрізний запису на диск (write-through) і надавати можливість вибору для різних дискових масивів
різних методів кешування. Дисковий пристрій, на якому розміщені журнали реєстрації транзакцій,
має завжди бути write-through. Крім того, якщо автоматична регенерація даних при старті СУБД відпрацьовує
належним чином, всі пристрої SQL Server повинні бути очищені після виконання контрольної точки. Якщо
дисковий контролер не підтримує опцію write-through, єдиною альтернативою цьому можна вважати
дуже часте створення резервних копій. Крім того, Вам не доведеться розраховувати на процедуру регенерації
даних при старті сервера і на ті записи журналу транзакцій, які були активні в момент збою. Ви зможете
розраховувати тільки на ті записи, які до цього вдалося зберегти резервної копії.
Питання
Де має виконуватися кешування, на SQL Server або на дисковому контролері?
Відповідь
Відповідь залежить від того, який метод дозволяє СУБД працювати швидше. Наші експерименти показали, що кеш
SQL Server є більш ефективним, ніж буфер системи вводу-виводу операційної системи. Однак, ми
не маємо відомості про те, чи дійсно кешування SQL Server більш ефективно ніж кешування,
використовуване спеціалізованими дисковими контролерами. Кеш SQL Server, по видимому, не працює з
такою ж швидкістю, як апаратний кеш. Однак, кеш СУБД більш інтелектуальний і може працювати більш
продуктивно.
Проведіть моделювання з імітацією типовою робочим навантаженням, встановивши параметри пам’яті SQL Server
в мінімальні значення, необхідні для підтримки необхідного числа користувачів (кеш дискового контролера
повинен бути активним) для вашої інсталяції. Виконайте вимірювання продуктивності цієї конфігурації,
які будуть порівнюватися з конфігурацією без апаратного кеша. Після цього, пробуйте запустити сервер
баз даних з параметрами пам’яті, збільшеними на величину кеша даних в RAM, яка повинна бути порівнянна
з величиною кешу дискового контролера (кеш дискового контролера повинен бути дезактивірован). Для коректного
порівняння, число сторінок в кеші процедур повинна бути однаково в обох модельованих варіантах. Це зажадає
деякого коректування конфігурації, тому що розмір кешу процедур визначається у відсотках від повного
розміру кеша даних, в той час, як розмір повного кеша визначається конфігураційними параметрами пам’яті
і кількістю користувальницьких підключень. Реальний розмір кеша буде складати те, що залишиться після
надання 42КБ кожному користувача підключення. Це залишок буде розділений між процедурним
кешем і кешем сторінок даних згідно процентному співвідношенню, зазначеної в параметрі кешу процедур.

Зауваження автора розсилки

Як резюме до обох статей, можна сказати, що грамотне використання апаратних дискових контролерів,
мають власний кеш операцій введення / виводу, безсумнівно, має призвести до істотного підвищення
ефективності роботи СУБД. Накладені технологією обслуговування транзакцій обмеження на опції і
режими кешування, що вбудовуються в апаратні засоби, безсумнівно, повинні прийматися до уваги при
інсталяції, як “заліза”, так і СУБД. Сучасні дискові контролери об’єднують в собі цілий набір
різноманітних можливостей, дають величезні переваги і від яких неможливо відмовитися (RAID,
вивільнення ресурсів центрального процесора, багатоканальність, диски автоматичної підміни, робота
в кластері і т.д.). Останнім часом дуже широке поширення отримали технології NAS і SAN, які
не мислимі без застосування дуже потужних і високоінтелектуальних контролерів дискових масивів. Всі
це говорить про те, що робота сучасної СУБД без кешуючий дискових контролерів стає неможливою.
Представленими Вам статтями було показано, що неправильна конфігурація апаратних засобів може привести
до пошкодження бази даних. Ключовим елементом, захист якого дозволить уникнути подібних руйнувань,
є журнал реєстрації транзакцій. Журнали повинні розташовуватися на окремих дискових масивах і
для цих дисків повинно бути заборонено кешування запису. Крім того, необхідно заборонити використання
сигналів інтерфейсу SCSI на ініціалізацію пристроїв, в результаті якої відбувається втрата даних апаратного
кешу контролера. Кожен контролер, як мінімум, повинен володіти власним, вбудовуваним акумулятором,
для запобігання передчасного знеструмлення кеша. Сучасні апаратні кошти йдуть ще далі.
Можливо дублювання і резервування не тільки самих дисків, але і контролерів, шин і т.п. Сучасні
автономні дискові масиви здатні обслуговувати не один, а кілька серверів, причому використовуючи для цього
цілий набір інтерфейсів, таких, як SCSI, FC, Fast Ethernet і т.п. Давно вже минули ті часи, коли розмір
бази даних не перевищував десятка Гігабайт. Сьогодні, безліч завдань оперує сотнями, а то й тисячами Гігабайт,
для чого великий обсяг кеша даних у СУБД починає мати величезне значення. Для ефективного наповнення
такого кеша даних наявність проміжного, апаратного кеша дає тільки переваги.

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


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

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

Ваш отзыв

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

*

*