Discussion :

[shaoling]

Bonjour,

Alors voilà, je suis actuellement en 3ème année en école supérieure d'informatique (SUPINFO) et je souhaiterai devenir DBA Oracle.
Durant l'année, nous avons l'opportunité de pouvoir faire des stages à temps partiel (à raison de 2 jours par semaine) et à temps complet durant l'été.

Évidemment, il serait préférable pour moi de faire des stages en relation avec mon futur métier, mais il se trouve qu'il n'en existe pas beaucoup (région marseillaise) ...

J'aurai voulu savoir, comment être vous devenu DBA Oracle ? Quel est votre parcours ?
Pensez-vous que je peux y aller au culot pour demander à être stagiaire ? (banque, ou tout autre entreprise) car en général les entreprises recherchent des DBA, non des stagiaires pour gérer leurs bases de données...

Forcément, j'ai l'intention de passer la certification OCA, mais dur dur sans avoir d'expérience... Le seul moyen que je vois est de "m'entrainer" à la maison sur une machine virtuelle ...

Merci d'avance pour vos commentaires et conseils que vous pourrez m'apporter

[Invité]

DBA, c'est un métier d'expérience.
Honnêtement, ce n'est pas le genre de poste où j'emploierais un stagiaire.
Ça demande un certain temps pour connaitre les environnements même quand on a un peu d'expérience. Alors un stagiaire, le temps qu'il soit un minimum autonome, il est déjà parti!
Je te conseillerais de commencer par chercher à faire des développements orientés BD, genre des gros jobs de purge qui demandent quand même de bonnes connaissances BD pour faire ça comme du monde.
J'ai commencé par des jobs comme ça, des développements PL/SQL assez pointus et je me suis retrouvé progressivement DBA Oracle, avant de passer du côté obscur chez MS SQL Server.

[Oishiiii]

Bonsoir,

C'est vraiment très difficile de devenir DBA.

Certes tu n'as pas d'expérience, donc il faut montrer que tu es compétent en obtenant des certifications. Passes en plusieurs si tu en as la possibilité : OCA, SQL Expert, PL/SQL, etc
Avec les vouchers SUPINFO ça devrait aller.

Ensuite, il est clair que le plus important c'est les stages (y compris à temps partiel) !! Il faut que ça soit orienté BDD, pas forcément administration dès le début.

En bossant bien, et avec les stages qui vont bien, il n'est pas impossible de trouver un stage de fin d'études (6 mois) comme "apprenti DBA", pour finir DBA.

Devenir formateur SUPINFO, en commençant par donner des cours de SQL au première année sera clairement un "plus".

Effectivement, commencer comme développeur PL/SQL pour devenir plus tard DBA semble être assez courant.

[shaoling]

Super, je vous remercie pour ces renseignements et témoignages.

Je sais que ça peut paraitre délicat, mais quel genre de boites seraient susceptibles de recruter des stagiaires pour faire du développement PL/SQL ? En effet, les annonces/offres de stages à ce sujet ne courent pas les rues, il faudrait donc que je me déplace et y aille au culot. La plupart des offres de stages que je peux voir son orientées développement web (en attendant je fais ça...), admin sys/réseaux (pas ma branche du tout), ou alors la plupart du temps ce sont des stages de fin d'études de 6 mois (ingénieur développement J2EE, .NET, etc.).

Merci bien.

[a.presles]

Un DBA doit avoir des competances ORACLE et SYSTEM. A mon avis le meilleur chemin est de faire du developpement comme dit précédement. Et de s'interessé au problematique system et stockage.
Il y a deux sorte de DBA les DBA etudes et les DBA production. Souvent les DBA etudes n'existe pas et les DBA production font une partie du travail de DBA etude. Donc il est important que le DBA ai des bonnes notion de developpement.
en étant developper dans une petite entreprise tu fais vite du boulot de DBA etude se qui t'amene souvent au problematique des DBA productions.
En tout cas je n'embaucherai jamais un DBA sortant de l'ecole, je préfére un ancien developper.

[shaoling]

Quel est le rapport entre un développeur et un DBA ?
Un développeur peut faire un très mauvais DBA, et l'inverse est d'autant plus vrai.

[orafrance]

Un DBA peut développer, le contraire est moins évident Et le rapport c'est qu'un DBA qui a commencé par du dév aura plus de facilité à réviser le code en cas de problème de perfs

[IndianaAngus]

Pour ma part j'y est été à l'arrache dans la boite ou je travail (genre menace de démission pour qu'ils me sortent du dev et ca à marché ).
J'ai fait quasiment 8 ans de dév en C/Java/SQL puis j'ai passé la certif SQL Expert et OCA pour donner plus de poids à mon souhait d'évoluer vers ce poste.
Mais honnêtement l'OCA sans experience ou sans une formation adéquat, ca va être très compliqué.

Franchement DBA en sortant de l'école j'y crois pas une seconde même si ca doit surement exister, l'idéal serait un stage en tant que DBA avec quelqu'un qui te prendrai sous son aile pour te faire monter en compétence sur Oracle.
Ca arrive mais ca doit pas courir les rues. C'est vrai qu'en ayant fait du dév, ca aide pas mal pour lire le code SQL et être au courant des problématique de développement.

[shaoling]

Quelles sont les problématiques de développement avec le SQL (hormis parfois de requêtes écrites à l'arrache ?) ?

[13thFloor]

...
Franchement DBA en sortant de l'école j'y crois pas une seconde même si ca doit surement exister, l'idéal serait un stage en tant que DBA avec quelqu'un qui te prendrai sous son aile pour te faire monter en compétence sur Oracle.
Ca arrive mais ca doit pas courir les rues.

Si si, c'est possible. Il suffit d'être dans une structure infra avec une ligne d'activité SGBD/data management. J'ai vécu cela à 2 reprises : on prenait un stagiaire qui effectuait sa dernière année d’école d'ingé avec nous, il montait en compétences (on l'y aider of course), réalisait son sujet de stage qui avait été défini au préalable, allait parfois en clientèle (accompagné, jamais en solo, toujours en équipe) et au terme de son stage on lui faisait une proposition d'embauche et il commençait en tant que dba Oracle. C'est une bonne pratique mais il faut fidéliser le collaborateur.

[Waldar]

Quelles sont les problématiques de développement avec le SQL (hormis parfois de requêtes écrites à l'arrache ?) ?

Le SQL est un langage complet et complexe qui évolue.
Sans aller regarder la solution, savez-vous ce que font les courtes requêtes de ce sujet (je les remets ici pour plus de clarté) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    SELECT 1999 + level AS annee
      FROM dual
connect BY level <= 15;
 
SELECT value(t) n FROM TABLE(sys.odcinumberlist(2000,2005,2010,2011)) t;
 
SELECT annee
  FROM (SELECT 1999 annee, 0 u FROM DUAL) t
 MODEL DIMENSION BY (u)
       MEASURES (annee)
       RULES UPSERT
       ITERATE(10)
       ( annee[ITERATION_NUMBER+1] = annee[ITERATION_NUMBER]+1);
 
SELECT * FROM XMLTable('2000 to 2010');

[shaoling]

Le SQL est un langage complet et complexe qui évolue.
Sans aller regarder la solution, savez-vous ce que font les courtes requêtes de ce sujet (je les remets ici pour plus de clarté)

Un développer est réellement amené à réaliser de telles requêtes ? Pour avoir lu le livre Oracle Press sur la certification SQL Expert, je ne me souviens pas y avoir lu des requêtes de ce style (ainsi que ces fonctions). Néanmoins c'est intéressant et ça peut-être utile de les connaitre :-)

Sinon pour en revenir au sujet, je pense peut-être postuler dès le mois d'octobre dans diverses boites pour un contrat pro, le temps de mes 2 dernières années d'étude.
Donc si jamais vous connaissez des boites, SSII ou autres susceptibles d'être intéressées par un DBA Junior ou DBA Assistant en contrat de professionnalisation sur Paris (pour une éventuelle embauche dès la remise de mon diplôme) je suis tout ouïe :-)

[Waldar]

Oui, non, ça dépend !
Ce que je veux vous montrer, c'est que des requêtes vraiment simples en syntaxe peuvent être inconnues.

Imaginez maintenant que vous travaillez sur le suivi d'une base de données d'un gros ERP mal modélisé (au hasard : SAP), des requêtes qui font 1500 lignes avec 150 tables dans les jointures, et qu'on vous dise : "ça rame, il faut faire quelque chose".
Ça fait aussi partie du boulot du DBA !

[Invité]

Si si, c'est possible. Il suffit d'être dans une structure infra avec une ligne d'activité SGBD/data management. J'ai vécu cela à 2 reprises : on prenait un stagiaire qui effectuait sa dernière année d’école d'ingé avec nous [...]

C'est l'exception qui confirme la règle, non ?
Parce que c'est la première fois que j'entends ça.

[orafrance]

Un développer est réellement amené à réaliser de telles requêtes ? Pour avoir lu le livre Oracle Press sur la certification SQL Expert, je ne me souviens pas y avoir lu des requêtes de ce style (ainsi que ces fonctions). Néanmoins c'est intéressant et ça peut-être utile de les connaitre :-)

Ne serait-ce que pour les problèmes de perfs, c'est important de savoir parfaitement lire une requête pour pouvoir la réécrire. Et outre le SQL, le PL/SQL est un super endroit pour trouver des ignominies et gagner de précieuses minutes

[voran]

Ne serait-ce que pour les problèmes de perfs, c'est important de savoir parfaitement lire une requête pour pouvoir la réécrire. Et outre le SQL, le PL/SQL est un super endroit pour trouver des ignominies et gagner de précieuses minutes

Hello,

En effet, maîtriser le SQL est très utile pour un DBA, mais plutôt pour justifier/expliquer les mauvaise perfs dû à du code SQL perfectible, que pour réécrire le SQL puisque la logique de l'application et les sources ne sont pas toujours accessibles, ou pire lorsque l'on a à faire à hibernate, véritable cauchemar du DBA.
J'ai l'impression que de moins en moins de développeur sont compétents et impliqués par les perfs de leur propre code SQL.

[McM]

Je ne pense pas que ce soit au DBA d'être le responsable de l'optimisation du code sql ou pl des bases. Un bon développeur peut très bien le faire. C'est ce que j'ai fait pendant plusieurs années : Le développeur connait bien mieux les tables, les indexes, les données qu'un DBA qui doit administrer de nombreuses bases.

Pour moi le métier DBA (je le suis devenu depuis 8 mois en plus de mon boulot de dev suite à des licenciements), c'est plutôt de la surveillance de base (sauvegardes, tablespaces, indexes, mises à jour des standby), du scripting unix (et windows) pour faire tout ça, et enfin des imports/exports et des install de nouvelles bases. Et enfin, il y a la sécurité - sujet abordé récemment sur un autre post faisant référence à des dba boîteux

[Invité]

Le développeur connait bien mieux les tables, les indexes, les données qu'un DBA qui doit administrer de nombreuses bases.

Houlà! Ça doit exister mais la plupart des développeurs à l'heure actuelle ne font aucune différence entre une table, une vue ou un synonyme alors, je ne parle même pas du concept d'indexation...

[orafrance]

Le développeur connait bien mieux les tables, les indexes, les données qu'un DBA qui doit administrer de nombreuses bases.

Le souci étant que le développeur n'a pas forcément les compétences pour choisir correctement les indexes à poser et encore moins réviser le modèle de données si besoin

Pour moi le métier DBA (je le suis devenu depuis 8 mois en plus de mon boulot de dev suite à des licenciements), c'est plutôt de la surveillance de base (sauvegardes, tablespaces, indexes, mises à jour des standby), du scripting unix (et windows) pour faire tout ça, et enfin des imports/exports et des install de nouvelles bases. Et enfin, il y a la sécurité - sujet abordé récemment sur un autre post faisant référence à des dba boîteux

Je serais malheureux si ça ne se limiter qu'à ça Lire le code, comprendre sa logique et revoir la méthode employer pour apporter des solutions techniques qui permettent d'améliorer les perfs, ça c'est le pied

[voran]

Le souci étant que le développeur n'a pas forcément les compétences pour choisir correctement les indexes à poser et encore moins réviser le modèle de données si besoin

Si le développeur n'a pas les compétences pour réviser le modèle de données ... je crains le pire pour l'application.
C'est bien un pb de compétence que doit avoir tout bon developpeur, tout comme un bon DBA doit avoir des compétences en SQL.

Je serais malheureux si ça ne se limiter qu'à ça Lire le code, comprendre sa logique et revoir la méthode employer pour apporter des solutions techniques qui permettent d'améliorer les perfs, ça c'est le pied

Tu es un privilégié pour avoir accès au code.