Discussion :

[orafrance]

mouais... je crois que le métier change c'est tout... comme je disais, il faut être pluri-disciplinaire pour réduire le nombre de postes. L'admin est de plus en plus simple, donc en plus on fait de la conception (conseil sur le MCD), de l'exploit (dév des scripts d'exploit) et de l'architecture.

A mon avis, les postes de DBA sont très différents selon le contexte, ce que tu décris pour 10000 users en ligne, je ne l'ai pas vécu. Par exemple, je suis intervenu chez un client avec plus de 80 instances sur plus de 30 serveurs (donc bien sûr énormément de contraintes) mais c'est pas moi qui m'occuper de la partie physique (resize de tbs, création de base, etc...). Mon job était diagnostiquer les problèmes pour améliorer les perfs par exemple mais je ne manipulais pas... une fois que je savais quoi faire, je demandais à l'équipe de "DBA" (plutôt admin systéme en fait) de le faire

[Pomalaix]

Il y a un bon bout de temps maintenant, quelqu'un avait demandé en quoi consistait le métier de DBA (mais le sujet a disparu depuis).
Pour ma part, je distingue 3 types de DBA, qui bien entendu se mélangent plus ou moins dans les faits, selon la répartition des rôles dans la société
- le DBA système
- le DBA applicatif
- le DBA études

Le DBA système a la responsabilité transversale de toutes les bases de données de l'entreprise. Il s'occupe en particulier de l'installation du noyau Oracle, de la gestion de l'espace de stockage et le l'exploitation des bases. Du fait qu'il a de nombreuses bases dans son giron, il n'a pas le temps de s'intéresser au contenu des bases et à l'aspect fonctionnel des applications.

Le DBA applicatif a un périmètre plus ciblé : 1 ou quelques bases, liées à des applications qu'il connaît très bien, et dont il maîtrise parfaitement la structure de données. De ce fait, il peut prendre en charge finement la structuration physique des bases (index bitmap, vues matérialisées, partitionnement, etc) la gestion des droits, l'analyse des performances et l'optimisation ciblée, le traitement des erreurs...
Il travaille en collaboration étroite avec les utilisateurs, pour qui il est un peu "monsieur technique" pour les applications considérées.
Un tel DBA applicatif peut par exemple être celui qui sera dédié aux applications de consolidation financière entre les filiales d'un groupe international, ou être celui qui s'occupera spécifiquement de l'entrepôt de données.

Le DBA études intervient sur des systèmes en construction. Il peut gérer de manière autonome les bases de test et de développement, prendre en charge l'optimisation SQL, conseiller l'équipe de développement sur les normes de codage et d'implantation, sur les bonnes pratiques en général liées au SGBD.

Qu'on soit dans l'un ou l'autre de ces trois rôles, les architectures multiniveau qui s'imposent obligent à la polyvalence et à la compréhension globale d'une architecture et des interdépendances entre éléments.

Il me semble aussi qu'il y a de plus en plus de place pour des aiguilleurs, c'est à dire des gars qui ont cette vision globale, et qui maîtrisent justement les charnières, les jonctions, les points de collaboration, et qui savent identifier l'intervenant technique nécessaire, sans avoir pour autant la compétence d'intervenir eux-mêmes en tous points.

[Marc Musette]

mon expérience me laisse penser qu'un dba applicatif est plutôt un développeur orienté SQL et de ce fait amené à quelques tâches dba

quant au dba étude... c'est un beau boulot mais quelle société a l'opportunité financière de s'offrir de tels services ?

restriction financièreobligent, et vu l'explosion du nombre d'applications et de db utilisées, le dba Oracle est de plus en plus cloitré dans un rôle de dba système avec en plus, toute la difficulté de tourner sur des environnements de plus en plus diversifiés (windows, unix, mainframe, linux ...)

il y a dix ans , quinze ans, le dba pouvait jouer les trois rôles en même temps (applic centrale sur mainframe, support au développeur, connaissance approfondie de l'os) le dba faisait partie de l'équipe système, avait son mot à dire sur le design de la grosse applic construite en cobol) les choses étaient plus simples : une machine , un langage , une db avec un administrator guide de 400 pages

aujourd'hui, le db applicatif est obligatoirement issu du développement ; idem pour le dba études

[orafrance]

aujourd'hui, le db applicatif est obligatoirement issu du développement ; idem pour le dba études

Bien sûr, et c'est logique... en revanche, DBA et développeur c'est pas pareil... j'ai été DBA applicatif et DBA étude et dans les deux cas, les développements se limitaient aux scripts d'exploitation

Je t'assure que des sociétés ont bien les moyens de s'offrir les services d'un DBA appli ou étude et c'est bien mieux pour monter des bases de données "intelligentes". Malheureusement, j'ai vu trop de projets qui se passer des services d'un bon technico-fonctionnel pour monter la base et après on galère pour offrir des perfs acceptables

[Pomalaix]

aujourd'hui, le db applicatif est obligatoirement issu du développement ; idem pour le dba études

J'en ai au moins un contre exemple : j'ai été pendant près de 2 ans DBA applicatif dans un grand groupe (80 000 personnes), où je m'occupais d'une application en perpétuelle évolution desservant 300 utilisateurs répartis en Europe et aux USA.
Et je n'ai jamais été développeur de ma vie