Зміст
- 1. Не забудьте перевірити свої резервні копії!
- 2. Не обережність щодо обмежень доступу до безпеки може бути дорогою!
- 3. Не забувайте про послідовне обслуговування вашої бази даних!
- 4. Не чекайте, поки у вашої системи виникнуть проблеми, щоб почати моніторинг рівнів активності бази даних та завантаженості!
- 5. Не вимикайте перевірку сторінки!
- Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя
Джерело: .shock / Dreamstime.com
Винос:
Нехтування цими п'ятьма завданнями може призвести до катастрофи бази даних!
Не всі рутинні, квотні завдання, які виконує DBA, були створені рівними. Нехтування деякими з цих щоденних завдань може призвести до головного болю, тоді як інші можуть призвести до величезних фінансових втрат. Незважаючи на те, що багато дорогоцінного часу DBA потрапляє на обробку помилок та проблем, які виникають в результаті розробників та користувачів, важливо, щоб критичні щоденні завдання не залишалися поза увагою.
Ось 5 гігантських помилок DBA, яких слід уникати, щоб досягти успіху у своїй позиції.
1. Не забудьте перевірити свої резервні копії!
У суєті повсякденних дій деякі речі можуть бути не помічені. Але нехай це не буде одним із них! Незалежно від високої якості ваших методів відновлення після аварій, для вас надзвичайно важливо послідовно виконувати тести, щоб переконатися, що резервні копії працюють. Найгірше, що може статися, - це з’ясувати, що вони не є, коли ви намагаєтесь відновити їх. Користувачі SQL Server повинні використовувати команду BACKUP VERIFYONLY, щоб перевірити, чи працюють резервні копії, а також використовувати параметр CHECKSUM для того, щоб ваша база даних не була пошкоджена. Регулярне відновлення бази даних у незахищених системах також важливо, щоб переконатися, що ваші резервні копії можуть бути відновлені. (Щоб дізнатися більше про відновлення після аварій, див. Відновлення після катастроф 101.)
2. Не обережність щодо обмежень доступу до безпеки може бути дорогою!
Ігнорування загроз безпеці насправді є досить поширеним явищем серед DBA. Незалежно від того, чи дозволяють людям або програмам отримувати доступ до інформації вищого рівня, ніж це необхідно, або пропонують розробникам адміністративні привілеї, ці помилки можуть призвести до втрати даних, крадіжки даних, опромінення даних або навіть пошкодження бази даних. Хоча можна подумати, що надання розробникам прямого доступу до виробничих даних може прискорити процес розробки та налагодження, це, безумовно, не найкраща практика. Розглядаючи катастрофічну помилку, яка може призвести до того, що неправомірна особа отримає занадто багато доступу, DBA повинні переконатися, що користувачі, розробники та навіть адміністратори отримують лише найнижчий рівень дозволу.
3. Не забувайте про послідовне обслуговування вашої бази даних!
Зрештою, база даних не може працювати сама! Надзвичайно важливо, щоб DBA не лінувались і не випускали з уваги регулярне обслуговування бази даних, а просто покладалися на можливості автоматичної настройки та самолікування системи баз даних. Існує багато важливих завдань, які потрібно виконувати послідовно, включаючи проведення базових перевірок цілісності для всіх виробничих баз даних, перевірку індексів на фрагментацію та оновлення статистичних даних про ваші виробничі бази даних. Автоматизувати ці завдання може бути корисно до тих пір, поки будь-які заходи, що споживають великих ресурсів, не проводяться в робочий час у найвищий виробничий час. Незважаючи ні на що, це треба зробити, інакше можуть трапитися дорогі помилки. (Докладніше про обов'язки та відповідальність DBA див. У розділі Кар'єра адміністрації баз даних 101.)
4. Не чекайте, поки у вашої системи виникнуть проблеми, щоб почати моніторинг рівнів активності бази даних та завантаженості!
Як тільки ваша система не працює, гроші починають витрачатися даремно, і люди починають засмучуватися. Тому надзвичайно важливо регулярно контролювати та орієнтувати використання сервера. Перевірка статистичних даних системи допоможе вам зрозуміти стандартне навантаження та побачити шаблони, щоб знати, коли відбуваються якісь зміни чи відхилення. Не забудьте перевірити використання процесора, пам'ять, введення / виведення, блокування та блокування, і слідкуйте за тим, скільки вільного місця ще доступно для ваших даних та файлів журналу.
5. Не вимикайте перевірку сторінки!
У нових базах даних SQL Server є налаштування за замовчуванням, яке перевіряє наявність корупції, перевіряючи контрольну суму на цілій сторінці та записуючи значення у заголовок сторінки. Потім, коли сторінка читається в пам'яті, вона знову перевіряє значення контрольної суми і порівнює два числа. Якщо два числа не збігаються, сторінка пошкоджена, і ви отримаєте сповіщення про помилку. Тому ця настройка є надзвичайно вигідною, і, відключивши її, ви налаштовуєте себе на збій!
Для DBA існує багато дос і незліченна кількість донтів. Існують настільки важливі завдання, що їх пропуск може призвести до повного збою бази даних, і є більш тонкі аспекти, які просто відводять вас від функціональної DBA до успішної. Існує нескінченний спосіб постійно вдосконалюватись і працювати над собою, щоб переконатися, що ваші практики є стандартними. Ваша роль охоплює так сильно і глибоко впливає на успіхи та невдачі вашої компанії. З цієї причини критично важливо, щоб ви, як компетентний спеціаліст DBA, переконалися, що ви навчаєтесь на помилках інших людей у цій галузі та робите все можливе, щоб не зробити жодного з цих великих.
Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя
Ви не можете покращити свої навички програмування, коли ніхто не піклується про якість програмного забезпечення.