В какие области знаний администратора баз данных должен вникать разработчик? [закрыто]

Должен признать, что вопрос довольно широкий, поэтому постараюсь немного его сузить. В нашей компании 3-4 разработчика, и на сайтах наших клиентов работает несколько установок на базе SQL Server (размер базы данных до 100 ГБ, до 100 одновременных пользователей, приложения для внутренней сети). Никто из нас не имеет настоящего опыта в управлении / обслуживании / администрировании (независимо от) баз данных. Клиентов даже не так много. До сих пор все работает нормально, но я не могу точно сказать, потому что мы все делаем правильно или просто не попали в области / ситуации, в которых мы не разбираемся.

Итак, я ищу важные вещи, которые вам нужно знать при работе с базой данных с точки зрения администратора баз данных . Вы знаете неопровержимые факты и знаете, что важнее всего в вашей повседневной работе.

По каким предметам я должен собирать более глубокие знания, о чем я должен слышать, и о чем я могу заботиться, пока не столкнусь с этим в первый раз?

Мне известен вопрос инженеров-программистов и администраторов баз данных , но это не совсем то, что я искал. Вокруг также много книг, но я хотел бы услышать это от тех, кто имеет практический опыт.

Я склонен согласиться с @Catcall, восстановление базы данных должно быть первым в списке. Последствия как резервного копирования, так и вариантов восстановления, как правило, наиболее плохо изучены за пределами группы администраторов БД и с наибольшей вероятностью могут привести к катастрофе.

• Убедитесь, что вы определили и согласовали (по техническому и нетехническому управлению) RPO (цель восстановления) и RTO (цель восстановления) для всех баз данных и систем.
• Документируйте процедуры резервного копирования и восстановления в той степени, в которой они могут выполняться нетехническим персоналом.
• Убедитесь, что вся документация хранится как в печатном, так и в электронном виде, как на месте, так и за его пределами. Runbook аварийного восстановления, хранящийся в локальной сети, не очень пригодится, если здания загорятся.
• Часто проверяйте все аспекты процедур восстановления. Резервные копии не имеют значения, это восстанавливает, что имеет значение.

Далее, с точки зрения независимости от базы данных, это понимание того, для чего создан сервер базы данных; обеспечить атомарность, согласованность, изоляцию и долговечность ваших транзакций и данных. Обычно неправильно понимается, часто является причиной проблем с производительностью и основным источником несоответствия данных.

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

Две вещи, с которыми я имею дело каждый день.

1. Аварийное восстановление.

2. Настройка производительности. (Как для отдельных запросов, так и для самой базы данных.)

Ваш план аварийного восстановления должен быть

• Scripted,
• проверено, и
• практикуется.

Я использую сценарии в том смысле, что актер будет следовать, а не в Python. Это должно сказать всем, кто должен быть вовлечен, точно, что делать. (И часто, что именно сказать тоже.)

Настройка производительности для запросов включает понимание ключей, индексов и нормализацию. (Часто проблемы «настройки» на самом деле являются структурными проблемами.)