У яких сферах знань про DBA слід розробляти розробник? [зачинено]

Я мушу визнати, що питання досить широке, тому спробую трохи звузити його. У нашій компанії ми є 3-4 розробниками і маємо деякі установки на базі SQL Server, які працюють на сайтах нашого замовника (розміри баз даних до 100 Гб, до 100 одночасних користувачів, додатки інтранет). Ніхто з нас не має справжнього гарного досвіду роботи з веденням / підтримкою / адміністрацією (якими б не були) базами даних. Клієнтів навіть не так багато. Це досі працює нормально, але я не можу точно сказати, чи це тому, що ми робимо все правильно, або якщо ми просто не потрапили в райони / ситуації, в яких ми не досвідчені.

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

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

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

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

• Переконайтесь, що ви визначили та погодили (технічним та нетехнічним управлінням) RPO (мета точки відновлення) та RTO (Мета часу відновлення) для всіх баз даних та систем.
• Документи щодо резервного копіювання та відновлення документів настільки, наскільки їх може дотримуватися нетехнічний персонал.
• Переконайтеся, що вся документація зберігається як у друкованому, так і в електронному вигляді, як в офісі, так і поза нею. Робоча книжка для відновлення після аварій, що зберігається в локальній мережі, не принесе великої користі, якщо будівлі горять.
• Часто перевіряйте кожен аспект процедур відновлення. Резервні копії не мають ніякого значення, це відновлює цю справу.

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

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

Дві речі, з якими я маю справу щодня.

1. Аварійного відновлення.

2. Налаштування продуктивності (І для окремих запитів, і для самих dbms.)

Ваш план відновлення після аварій повинен бути

• сценарій,
• випробувані та
• практикується.

Я використовую сценарій у розумінні того, що слідкував би актор, а не те, що написано на Python. Він повинен сказати всім, хто має потребу в тому, що саме потрібно робити. (І часто саме те, що сказати.)

Налаштування продуктивності для запитів включає розуміння ключів, індексів та нормалізації. (Часто проблеми з «налаштуванням» - це фактично структурні проблеми.)