SQL в питаннях і відповідях: Резервне копіювання і установка

Питання:Наш продукт використовує SQL Server для зберігання даних. Час від часу ми випускаємо нову версію нашого продукту, який включає в себе оновлений сценарій для запуску в базі даних. У процесі тестування останньої версії сценарію поновлення на репрезентативній тестовій базі даних, розмір файлу журналу транзакцій перевищив 40 ГБ. Ми б хотіли попередити таке стрімке зростання журналу. Які у нас є варіанти? Ми не можемо відмовитися від використання моделі повного відновлення для відновлення після збоїв.


Відповідь: По-перше, це чудово, що ви проводите тестування на репрезентативних клієнтських даних. Багато разів я бачив, як постачальники багаторівневих додатків тестували такого роду сценарії лише на невеликих наборах даних, після чого клієнти неминуче стикалися з масою проблем. Я відповім на ваше запитання так, ніби ви користувач. Так ви зможете поглянути на проблему очима своїх клієнтів.


Ви кажете, що вам потрібно дотримуватися моделі повного відновлення. Це означає, ви вже використовуєте резервні копії журналу транзакцій і в загальному випадку у вас немає проблем з неконтрольованим зростанням журналу транзакцій. Це добре, оскільки використання резервних копій журналу транзакцій – єдина процедура, що дозволяє очищати журнал після фіксації транзакцій. (Докладні відомості про це див в статті technet.microsoft.com/magazine/2009.02.logging, В якій пояснюється робота журналу транзакцій і різний вплив моделей відновлення на його поведінку.)


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


Якщо ваш сценарій поновлення запускається кожну годину при тому, що журнал транзакцій збільшується за півгодини до 20 ГБ, то файли журналу транзакцій повинні бути розміром в 20 ГБ. Але це все одно занадто багато, так що доведеться виконувати резервне копіювання журналу транзакцій частіше. Це дозволить частіше очищати журнал транзакцій і не допускати його неконтрольованого збільшення. У нас була аналогічна ситуація у клієнта, і в кінцевому підсумку довелося виконувати резервне копіювання журналу транзакцій щохвилини протягом декількох годин, поки аналогічний сценарій обслуговував велику базу даних.


Потрібно мати на увазі один нюанс: ці “зайві” резервні копії журналів транзакцій є частиною ланцюжка резервних копій журналу і необхідні для відновлення у разі збою. Подбайте, щоб у всіх у них були осмислені імена і щоб жоден з них не віддалявся.


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


Якщо сценарій поновлення містить транзакцію, що займає 15 ГБ в журналі транзакцій, розмір останнього повинен бути не менше 15 ГБ, щоб “умістити” всю цю транзакцію. Якщо це так, то неважливо, як часто виконується резервне копіювання журналу транзакцій, – журнал транзакцій не буде очищатися. Єдиним виходом у цьому випадку є розбиття великої транзакції на кілька дрібних, якщо це можливо.


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


Парадокс конфігурації


Питання: Ми встановлюємо нові сховища з безпосереднім підключенням на одному з наших серверів баз даних і хочемо знати всі доступні нам можливості, щоб створити максимально правильну конфігурацію. Чи не могли б ви розповісти, які варіанти конфігурації можливі, коли справа стосується використання SQL Server?


Відповідь: Є безліч варіантів настройки і параметрів конфігурації сховища, тому я віддаю перевагу, щоб управлінням зберіганням займався виділений адміністратор. Є параметри конфігурації, про які адміністратор SQL Server має обов’язково знати і подбати про правильну їх налаштування.


Перше – рівень RAID. Кожен рівень RAID – це компроміс між продуктивністю і надмірністю. Наприклад, найдешевшої конфігурацією RAID, забезпечує яку-ніяку надмірність, є RAID-5. Але ця конфігурація забезпечує захист від відмови тільки одного з дисків (якщо тільки не використовувати RAID-6 або конфігурацію дисками гарячої заміни) і характеризується невисокою продуктивністю в режимах з переважанням операцій запису при певній кількості дисків в масиві.


RAID-10 забезпечує високу надмірність, але це рішення дорожче. Загальний обсяг масиву складає не більше половини сумарного розміру вхідних в його склад дисків. У TechNet є хороша стаття про різні рівнях RAID – це “біла книга” “Physical Database Storage Design“.


Інша важлива обставина – розмір блоків чергування в RAID, розмір блоків NTFS (розмір кластера) і вирівнювання розділів на диску. Якщо ці параметри задати невірно, можливе значне зниження продуктивності. Найбільш важливо вирівнювання розділів на диску на дискових томах, створених за допомогою Windows Server 2003. При цьому використовується вирівнювання за умовчанням розміром 31,5 КБ, що відрізняється від загальноприйнятого розміру блоку даних RAID рівного 64 КБ (або кратного цій величині). Таким чином, в кожній операції введення / виводу повинно виконуватися читання або запис двох блоків RAID. Ясно, що це сильно знижує продуктивність.


В Windows Server 2008 вирівнювання за умовчанням становить 1 МБ. На томах, які створені в Windows Server 2003 і на яких ОС оновлено до Windows Server 2008, вирівнювання не змінюється і продуктивність не поліпшується. Проблема вирішується тільки переформатуванням томи, але часто виграш в продуктивності варто того.


Детальний обговорення цих питань дійсно виходить за рамки цієї статті, але більш детальна інформація (і посилання для подальшого читання) ви знайдете в моєму блозі “Are your disk partition offsets, RAID stripe sizes and NTFS allocation units set correctly?”


При розгортанні будь-якого нового сховища даних настійно рекомендується проведення навантажувальних випробувань і випробувань на продуктивність до перекладу сховища у виробничу середу. Навантажувальні випробування дозволяють запобігти помилки конфігурації, які можуть привести до втрати даних або простоїв. Перевірка продуктивності допоможе перевірити, чи забезпечує нове сховище необхідну продуктивність вводу / виводу в умовах нормальної робочої навантаження. Microsoft пропонує для цього безкоштовні інструменти, про які можна дізнатися більше в “білій книзі” “Pre-Deployment I/O Best Practices“.


Світло мій, дзеркальце …


Питання: Мені не зовсім зрозуміла роль слідкуючого сервера при настройці дзеркального відображення бази даних. Наскільки потужним він повинен бути? Чи залежить це від кількості баз даних, відмовостійкість яких він забезпечує? Чи має значення, в якому з центрів обробки даних розміщується стежить сервер? Я хочу бути впевненим в максимальній доступності дзеркальних баз даних.


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


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


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


Оскільки стежить сервер не обробляє і не зберігає дані, він не повинен бути потужним. На цьому сервері можна встановити будь-яку версію SQL Server, навіть SQL Server Express Edition. Також немає обмежень на число сеансів дзеркального відображення баз даних, в яких конкретний екземпляр SQL Server може виступати в якості слідкуючого сервера.


Слідкуючий сервер краще розміщувати в окремому від основного або дзеркального серверів центрі обробки даних. Однак у більшості компаній немає трьох центрів обробки даних, тому питання розміщення слідкуючого сервера, зводиться до вибору: разом із дзеркальним або з основним сервером.


Коли є тільки два центра даних, що стежить сервер повинен завжди перебувати з основним сервером. Причина пов’язана з формуванням кворуму. Якщо стежить і дзеркальний сервери розміщуються разом, і мережеве з’єднання з основним сервером порушується, виникає кворум між слідкуючим і дзеркальним сервером, що ініціює перехід.


У відсутність кворуму цілком “здоровий” основний сервер може перейти в автономний режим. У цьому випадку передбачається, що на дзеркалі почнеться перехід. Для запобігання подібної ситуації основною і стежить сервер розміщують разом, щоб зберегти їх кворум у разі відмови мережі. Основна база даних залишається доступною.


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


У сеансі дзеркального відображення бази даних можна створити два стежать сервера. Єдиний спосіб додатково підвищити надмірність ролі слідкуючого сервера – розмістити примірник слідкуючого сервера SQL Server на відмовостійких кластерів. Докладніше про конфігурації дзеркального відображенні бази див. “білу книгу” “Database Mirroring in SQL Server 2005“.

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


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

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

Ваш отзыв

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

*

*