Блог

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

Чи потрібна проактивність адміністратору баз даних (DBA)? Відповідь однозначна – ТАК. Проактивний підхід до результативності та обслуговуванню баз даних допомагає адміністраторам уникнути проблеми та запобігти трансформації дрібних недоліків у повномасштабну катастрофу.

Далі мова піде про повсякденну роботу адміністратора баз даних та рекомендації щодо покращення продуктивності бази даних.

Обслуговування баз даних

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

Резервне копіювання

Жодний керівник не готовий втратити дані. Тому перед плануванням резервного копіювання та відновлення баз даних архіважливо визначити такий показник, як RPO (recovery point object/цільова точка відновлення).

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

Забезпечення вдалого резервного копіювання – одна з найважливіших задач DBA. Створюючи резервну копію адміністратору варто використовувати параметр CHECKSUM, за допомогою якого можна перевірити наявність пошкоджень. Ще одним варіантом перевірки резервної копії є функція RESTORE VERIFYONLY.

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

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

Відновлення

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

Перевірка цілісності

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

Попередження (Agent Alerts)

Для оперативного реагування на збій бази даних адміністратори повинні налагодити сповіщення.

Microsoft пропонує для вирішення цієї задачі свій продукт The SQL Server agent, який призначений для сповіщення про помилки SQL серверу з небезпекою від 17 до 25, включаючи помилки ядра бази даних та ресурсів, а також 823, 823, 825, 829 помилки.

PostgreSQL пропонує свої продукти для відстеження стану бази даних: pgAnalyze и pgwatch2. PgAnalyze – це програмне забезпечення, яке розроблено для покращення видимості запитів. Інструмент можна використовувати для визначення причини повільної роботи запиту, а також для постійного моніторингу бази даних, щоб отримати уявлення про її наявний стан.  pgwatch2 – гнучке рішення для моніторингу, яке використовує панелі управління Grafana.

Індексація

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