Question Ressources pour le DBA accidentel [fermé]


Sur la plate-forme Microsoft, la plupart des programmes au niveau de l'entreprise (SharePoint, l'une des applications System Center, l'une des applications Dyamics, etc.) s'exécutent tous par-dessus SQL Server. Pour les administrateurs de ces programmes, SQL Server est souvent une boîte noire qui est installée en tant que condition préalable à tout programme qui constitue leur objectif principal. En conséquence, très peu de planification (voire aucune) est intégrée au côté SQL de l'installation, ce qui entraîne des problèmes qui se posent plus en amont.

  • Journaux de transaction remplissant les lecteurs
  • Aucun plan de maintenance (ou des plans non informés, tels que des plans qui réorganisent et reconstruisent les index)
  • Croissance automatique non gérée
  • Bases de données et journaux sur les mêmes piles
  • Niveaux RAID mal choisis
  • Aucune sauvegarde (ou plan de récupération)

Alors ... quels types de problèmes les "DBA accidentels" ont tendance à frapper, et quelles ressources aideraient au mieux un DBA accidentel à se familiariser avec les bases de la planification SQL, de l'administration et du réglage des performances?


16
2018-06-08 17:46


origine




Réponses:


Consultez la série d'articles et les chroniques de questions / réponses que j'écris pour TechNet Magazine. Elles sont principalement conçues dans l'optique de la DBA Accidental (nous l'appelons "involontaire").

Principaux conseils pour une maintenance efficace de la base de données a été spécialement conçu pour aider les administrateurs de base de données involontaires à comprendre les problèmes de maintenance de la base de données.

Comprendre la journalisation et la récupération dans SQL Server

Problèmes de sécurité communs à SQL Server et solutions

Comprendre les sauvegardes SQL Server - partie 1 d'une série en 3 parties. La partie 2 utilisera la restauration (dans le numéro de septembre 2009) et la partie 3, la restauration sans sauvegardes (dans le numéro de novembre 2009).

Vous devriez également commander mon blog et le blog de ma femme (nous ne faisons pas de publicité ni rien d’information) - nous bloguons tous les deux énormément sur une variété de niveaux techniques.

Une bonne série de posts à parcourir sont les suivants: éditoriaux pour les résultats de mes enquêtes hebdomadaires. Ils abordent généralement un sujet large qui aiderait les administrateurs de base de données involontaires. Les éditoriaux commencent par «Importance of» ou «Important». En fait, l’enquête de cette semaine parle de DBA involontaire - très à propos!

Nous comprenons très bien le problème des administrateurs de bases de données involontaires - en fait, Kimberly et moi enseignons quelques jours de la classe Masters certifiés SharePoint Microsoft afin que les administrateurs SharePoint sachent quoi faire avec leurs serveurs SQL (nous enseignons également une semaine complète à celle de SQL) .

J'espère que cela vous sera utile.


10



Super truc, merci! - marc_s


Sean, je comprends d'où tu viens.

Nous sommes dans un bateau similaire ici, comme je l’attendrais, il y en a beaucoup d’autres. Nonobstant l'économie d'aujourd'hui.

Malgré les plaintes répétées adressées à la direction (y compris aux cadres supérieurs des entreprises), voici notre situation. La "DBA" autoproclamée (dans une "équipe de développement" distincte située à un autre étage) en sait malheureusement moins qu'une junior manipulant deux livres O'Reilly et un dump d'impression KB. Elle a le travail et est très douée pour verser du miel dans l'oreille de la personne qui verse également du miel dans l'oreille du plus gros muckety-muck.

Certes, il serait idéal de pouvoir apprendre le "commerce" de la DBA, mais encore une fois .. Ce que nous voulons et ce que nous pouvons avoir sont souvent des choses très différentes. :)

Personnellement, j’ai rencontré les problèmes suivants, qui (pour faire écho à la question plutôt sournoise de Squillman, mais pas tout à fait incorrects) ont nécessité une grande partie de la recherche sur Google.

  • Tranlogs. Tu as raison. Que diable étaient ces choses? Nous avons donc dû restaurer une base de données et un serveur. Que signifie exactement "rejouer les fichiers journaux", exactement? :)
  • Attendez, que voulez-vous dire par ces bases de données qui deviennent simplement plus grandes Comment pouvons-nous les réduire? Ou du moins maintenir leur croissance?
  • Normalisation des installations sur différents serveurs, (cette image est pour "dev", cette image est pour "prod" et cette petite image a pleuré tout le chemin de la maison, du marché. :)
  • Les scripts de maintenance et comment aider à gérer les bases de données sur une longue période (un peu comme faire pousser des plantes d'intérieur et s'assurer qu'elles ne se transforment pas en kudzu.)
  • Assurez-vous toujours que les programmes vont sur le C: \, la journalisation et / ou les bases de données sur le D: \, ce qui a formulé notre standardisation (C: \ est deux disques en miroir, D: \ est généralement une affaire de RAID5 .)
  • Devoir acheter une licence SQL distincte et un client pour les sauvegardes.
  • Découvrez la gestion des utilisateurs que l'équipe de développement attribue à la base de données SQL elle-même, la gestion des rôles DBO, etc. Assurez-vous de disposer d'un bon modèle de sécurité en ce qui concerne les droits des utilisateurs dans la base de données.
  • Recherche d'un compte de service de domaine pour lequel les services SQL peuvent fonctionner. De quels droits ce compte de service a-t-il besoin, le cas échéant?

(Vous en avez frappé de très bons, dans votre message.)

Comme vous avez un handicap comme certains, assurez-vous de partager les connaissances en SQL au sein de l’équipe, si vous le pouvez. Partagez ce que vous savez, enseignez aux autres la même chose. Être amical. C'est vraiment pénible de devoir porter le chapeau SQL, mais au moins de nombreux yeux et processus de réflexion valent mieux qu'un seul.

Cependant, essayez avant tout de faire appel à un DBA pour faire partie du personnel. :)


5





Le titre de mec de la DBA a été créé il y a environ un an. C'était il y a environ 5 mois. Depuis lors, j'ai lu divers blogs de la 500 000 ft vue à la (frapper parfois le pont dur à 500 pieds) 250 000 vue, au Vue de 500 pi. Également,SQLServerPedia est votre ami; ils ont beaucoup de bonnes choses pour le DBA accidentel.

J'ai été jeté dans des situations qui me mettaient mal à l'aise. Par exemple, je fais des sauvegardes depuis que je me suis vu confier ce travail. Des fulls, des diffs et des t-logs étaient donc disponibles lors de ma première restauration des données de production. Personne d'autre ne semblait paniqué, alors je me suis dit que je ne pouvais pas montrer. comme je me sentais mal. Plus souvent qu'autrement, j'exagère quand je mets mon chapeau de DBA, mais je suppose que ce n'est pas mon travail à plein temps (administrateur réseau), alors je devrais être «mieux vaut prévenir que guérir».


2



SQLServerPedia est en effet une excellente ressource! Merci d'avoir fait remarquer cela. - marc_s


Principaux conseils pour une maintenance efficace de la base de données


1





Commencez par les efforts tactiques. Si votre base de données plante ou ne fonctionne pas correctement, concentrez-vous sur la résolution de ces problèmes.

Commencez ensuite avec des éléments plus stratégiques: sauvegarde et restauration. Sachez comment restaurer vos bases de données à l’intérieur et à l’extérieur et créez des procédures détaillées pour éviter les erreurs coûteuses lors d’une panne de production.

Si vous n'avez pas le matériel nécessaire pour tester les modifications majeures et des tâches telles que la sauvegarde / restauration, déterminez comment l'obtenir.


0





Lorsque j'ai embauché une DBA junior, je lui ai acheté le Compagnon de l'administrateur de Microsoft SQL Server (TM) 2005. C'est le livre que j'aurais aimé avoir quand je débutais.


0