SQL в запитаннях і відповідях: Резервне копіювання і установка, Інші СУБД, Бази даних, статті

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


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


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


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


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


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


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


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


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


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


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


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


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

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

Ваш отзыв

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

*

*