Dans quels domaines d'un DBA un développeur devrait-il se plonger? [fermé]

Je dois admettre que la question est assez large, alors je vais essayer de la réduire un peu. Dans notre entreprise, nous sommes 3-4 développeurs et avons des installations basées sur SQL Server exécutées sur les sites de nos clients (tailles de base de données jusqu'à 100 Go, jusqu'à 100 utilisateurs simultanés, applications intranet). Personne d'entre nous n'a vraiment une bonne expérience dans la gestion / maintenance / administration (quoi que) des bases de données. Les clients même pas tant que ça. Cela fonctionne bien jusqu'à présent, mais je ne peux pas dire avec certitude si c'est parce que nous faisons tout correctement ou si nous n'avons tout simplement pas touché des zones / situations dans lesquelles nous ne sommes pas compétents.

Donc, je cherche les choses essentielles que vous devez savoir lors de l'exécution d'une base de données du point de vue d'un DBA . Vous connaissez les faits et savez ce qui compte le plus dans votre travail quotidien.

Dans quels sujets devrais-je acquérir des connaissances plus approfondies, de quoi aurais-je entendu parler et de quoi ne me soucierais-je pas avant d'y faire face pour la première fois?

Je suis conscient de la question des ingénieurs logiciels et des administrateurs de bases de données , mais ce n'est pas tout à fait ce que je cherchais. Il y a aussi beaucoup de livres, mais j'aimerais les entendre de ceux qui ont une expérience pratique.

Je suis enclin à être d'accord avec @Catcall, la récupération de la base de données devrait être en tête de liste. Les implications des options de sauvegarde et de récupération sont généralement les plus mal comprises en dehors d'une équipe DBA et les plus susceptibles d'entraîner une catastrophe.

• Assurez-vous d'avoir défini et accepté (par la direction technique et non technique) RPO (objectif de point de récupération) et RTO (objectif de temps de récupération) pour toutes les bases de données et systèmes.
• Documenter les procédures de sauvegarde et de récupération dans la mesure où elles pourraient être suivies par du personnel non technique.
• Assurez-vous que toute la documentation est conservée sous forme imprimée et électronique, sur site et hors site. Un runbook de récupération après sinistre stocké sur le réseau local ne sera pas très utile si les bâtiments sont en feu.
• Testez souvent tous les aspects des procédures de récupération. Les sauvegardes ne sont pas pertinentes, ce sont les restaurations qui comptent.

Ensuite, d'un point de vue indépendant de la base de données, nous comprenons ce qu'un serveur de base de données est conçu pour faire; fournir atomicité, cohérence, isolement et durabilité à vos transactions et données. Généralement mal compris, il est souvent à l'origine de problèmes de performances et de la principale source d'incohérence des données.

Pour la plate-forme que vous avez choisie, découvrez comment la conformité ACID est mise en œuvre. Recherchez des rubriques telles que la fonction du journal des transactions , la consignation en écriture anticipée , les niveaux d'isolement et les éléments internes de stockage . La compréhension des principaux aspects des bases de données internes rend les autres aspects du travail DBA, l'optimisation des performances et la gestion des ressources par exemple, beaucoup plus faciles à saisir.

Les deux choses dont je m'occupe tous les jours.

1. Reprise après sinistre.

2. L'optimisation des performances. (Tant pour les requêtes individuelles que pour le dbms lui-même.)

Votre plan de reprise après sinistre doit être

• scripté,
• testé, et
• exercé.

J'utilise des scripts dans le sens de quelque chose qu'un acteur suivrait, pas quelque chose d'écrit en Python. Il devrait indiquer à tous ceux qui doivent être impliqués exactement quoi faire. (Et souvent, exactement ce qu'il faut dire aussi.)

Le réglage des performances des requêtes comprend la compréhension des clés, des index et de la normalisation. (Souvent, les problèmes de "réglage" sont en fait des problèmes structurels.)