Liste des spécifications nécessaires à la création d'une bdd sous Oracle 10g

[adrinhol]

Bonjour à tous,

Je dois prochainement créer une base de données qui va être sollicitée par une (big) application qui est en cours de développement.

On m'a demandé de dresser une liste complète et détaillée de toutes les infos que les développeurs doivent me fournir pour que leur appli tourne correctement avec ma base...

A noter que je ne connais pas le niveau de compétence des développeurs concernant les bases Oracle. A noter également que ce couple application/bdd va remplacer un couple actuellement en production !

Voici la liste que j'ai dressée jusqu'à maintenant :
- DONNEES :
* nom et rôle de chaque tablespace
* nombre et taille de leurs datafiles respectifs
- MEMOIRE :
* quantité SGA
* quantité PGA
- ACCES :
* moyenne prévisionnelle de connexions simultanées
* max potentiel de connexions simultanées
* flux (creux et pics)
- TRANSFERT :
* quantité de données à récupérer
* méthode et durée du transfert
* intervenants (devs ou dba)

J'y ajoute des specs au fur et à mesure, mais si vous voyez des specs inutiles, trop complexes, incomplètes ou surtout absentes de ma liste, n'hésitez pas à m'en faire part !

Merci beaucoup et à très bientôt !

[orafrance]

Je serais curieux de savoir si tu trouveras un seul dév capable de prévoir la consommation PGA, la durée des transferts, les tablespaces, etc...

[7gyY9w1ZY6ySRgPeaefZ]

Oui, ça me semble aussi bien trop proche de la bd comme questionnaire pour avoir des réponses des gens du dev.

orafrance, j'en ai connu des développeurs comme ça - enfin un...

[scheu]

Envoyé par Jerome_Mtl

j'en ai connu des développeurs comme ça - enfin un...

Idem, j'en ai connu un ... mais qui était ancien DBA

Pour la partie tablespaces et paramétrage d'instance, c'est plutôt à toi de décider, en fonction des infos qu'ils peuvent te donner sur les plages horaires sollicitées, le type de traitements (transactionnel, datawarehouse, chargements., ..), des volumétries des tables (approximation du nombre de lignes total, par mois, etc ...)

Si déjà ils peuvent te fournir ces infos là ça sera bien je pense

[orafrance]

Envoyé par scheu

Idem, j'en ai connu un ... mais qui était ancien DBA

moi le contraire... je suis devenu DBA et on aurait pu me poser ces questions quand j'étais dév... par contre savoir à l'avance les pics de flux, encore aujourd'hui j'suis incapable de tirer quelque chose d'une boule de crystal

[adrinhol]

Merci à tous !

Orafrance, pas besoin de boule de cristal : comme je l'ai dit il y a déja une application en prod donc les creux, les pics et les utilisateurs ne devraient pas beaucoup évoluer... et quand je parle de dev je parle peut-être de chef de projet dev (je ne connais pas exactement le rôle de mon interlocuteur)... c'est-à-dire une personne qui connait le projet dans son intégralité et donc la mieux placée pour répondre à de telles questions, enfin j'imagine

Jérome_Mtl, je sais bien que ces questions sont difficiles pour des devs (même chefs de projet) mais mon chef m'a demandé de les poser quand même : "on sait jamais". Et c'est surtout que s'il y un problème on dira : "on a posé les questions mais ils n'ont pas pu y répondre" lol !

Scheu, tu penses qu'avec les infos suivantes : "les plages horaires sollicitées, le type de traitements (transactionnel, datawarehouse, chargements., ..), des volumétries des tables (approximation du nombre de lignes total, par mois, etc ...)" je suis capable de déduire tous les paramétrages nécessaires à la mise en place de la bdd ?

Merci.

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par adrinhol

Et c'est surtout que s'il y un problème on dira : "on a posé les questions mais ils n'ont pas pu y répondre" lol !

Bon chef ! Poser des questions auxquels on n'aura pas de réponses... Subtile (?) façon de ne pas prendre ses responsabilités...

Envoyé par adrinhol

Scheu, tu penses qu'avec les infos suivantes : "les plages horaires sollicitées, le type de traitements (transactionnel, datawarehouse, chargements., ..), des volumétries des tables (approximation du nombre de lignes total, par mois, etc ...)" je suis capable de déduire tous les paramétrages nécessaires à la mise en place de la bdd ?

Ce sont des informations auxquelles les développeurs sont suceptibles d'avoir des réponses et ça t'aiguillera pour faire des choix, oui.

Concernant le developpeur qui connaissait toutes les réponses, c'était un petit jeune motivé qui ira loin. J'étais dba très débutant à l'époque et loin de pouvoir répondre à toutes ses questions !

[13thFloor]

En déduire tous les paramètres utiles, je ne pense pas. Lorsqu'il y aura de l'activité et que la base aura un peu "vécue", tu pourras effectuer quelques réglages pour la rendre optimale à partir des éléments que tu auras constatés et que les développeurs ne peuvent te fournir.
Par exemple :
- nombre de lignes par bloc
- chainage des lignes
- quantité de tris
- type d'accès aux données
- répartition des datas (utile pour le partitionnement ou les histogrammes)
- attentes (merci statspack)
- tablespaces/datafiles les plus utilisés
etc.

Personnellement, j'ai plutôt connu des cas ou les développeurs se tournait vers le dba soit pour que ce dernier leur fournisse quelques règles de base pour le codage de requête et/ou l'indexation en vue de bonne perf, soit pour de la normalisation d'objets.

Si tu veux optimiser de façon proactive, voici quelques éléments :
- définir le jeu de caractère de ta base => le fonctionnel doit te le donner, sinon note Oracle 264294.1
- taille de bloc en fonction de l'activité et de la longueur moyenne des datas et de leur contenu => décisionnel : 8,16,32K, oltp : 1,2,4,8K (depusi la 9i et le multibloc, tu peux gérer plusieurs taille, donc ça devient moins problématique)
- séparation data/index/undo/temp
- tablespaces en locally managed + assm
- au moins 2 controlfiles
- au moins 3 groupes de redo avec au moins 2 membres par groupe si unix
- objectif : pas d'échec de transaction => undo à tailler en fonction de la plus grosse transaction (pour la rétention) et tenir compte de la simultanéité des transactions (pour l'espace)
- redo : à adapter quand la base atteint son régime de croisière => pas trop de switch sauf si criticité des données
- aucun compte avec des droits dba
- pas de mot de passe par défaut
- 2 listeners : un pour les utilisateurs, 1 pour les administrateurs
- repérer les index redondant et ceux ayant une faible cardinalité
- monitorer les index
et tout un tas d'autres choses encore.

[adrinhol]

Ok merci ! J'ai déja pas mal de grain à moudre...
Je reviendrai quand nos amis les devs auront répondu au questionnaire, ou au moins essayé ;-)

Bonne journée !

[pifor]

Envoyé par adrinhol

A noter également que ce couple application/bdd va remplacer un couple actuellement en production !

Ceci devrait permettre d'estimer de façon assez précise le volume de données lors du démarrage de l'application.

Dans votre cas, le plus important, c'est de pourvoir tester, si possible, l'application dans les conditions les plus proches de la production (matériel, logiciel, données (volume, etc.), activité de la base en terme de sessions et d'activité SQL et PL/SQL). En fonction des problèmes rencontrés, vous pourrez ajuster la configuration de la base et le paramètrage de l'instance.

Lectures recommandées:

• Designing and Developing for Performance
• Top Ten Mistakes Found in Oracle Systems