Dimensionner le sga_target pour fusion de base [Résolu]

[ccaye]

Bonjour,

Je suis en Oracle 10. Actuellement, nous disposons de 30 bases régionales, qui sont dimensionnées avec un sga_target à 200 Mo.

Nous voulons fusionner l'ensemble de ces bases pour avoir une base unique, qui contiendra donc les données des 30 bases.
Comment dimensionner le sga_target ? Est-ce qu'il faut tout simplement faire une multiplication et mettre le paramètre à 200*30 = 6 Go ?

Ou bien est-ce que le fait de mutualiser les bases permet de "mutualiser" la mémoire également, et donc pas nécessairement d'utiliser autant de mémoire ?

Merci pour vos réponses !

[ccaye]

Personne n'a de réponse ? Je ne suis peut-être pas très clair. Comme l'architecture cible du projet n'est pas entièrement défini, je dois proposer différentes solutions, et donc justifier pourquoi une solution serait mieux qu'une autre.

Selon moi, avoir 30 bases utilisent plus le processeurs (car beaucoup plus de processus), et également plus la mémoire. Est-ce vrai ?

[pachot]

Bonjour,

La SGA comprend essentiellement:
- la shared pool qui est un cache pour le code exécuté (requêtes). Là comme c'est 30 fois la m'eme appli, ce sera mutualisé.
- le buffer cache qui est un cache pour les données utilisées fréquemment. Une partie seulement sera mutualisées (tables de références par exemple).

Pourquoi ne pas partir sur 2 Go puis voir s'il faut l'augmenter ? Ça dépends vraiment du comportement de l'application. Il faut savoir au'il est assez facile de voir si la SGA est trop petite (trop d'i/o) par contre il est difficile de voir lorsque c'est sur-dimensionné...

Cordialement,
Franck.

[ccaye]

Bonjour,

Merci pour la réponse. Nous sommes en phase d'étude pour centraliser sur un seul serveur , et en fait il y a 3 options qui se dégagent :
1- 30 bases sur le même serveur,
2- Fusionnées les 30 bases en une seule,
3- Créer 30 schémas dans une instance.

La solution 1 ne me paraît pas la bonne, mais je dois justifier. Donc le SGA est une des raisons permettant de sélectionner la solution 2 il me semble.

Le nb de processus lancés également me paraît justifier de choisir entre les solutions 2 et 3.

Par contre, au niveau des performances, entre la 2 et la 3 cela me semble proche non ? A priori, il faudrait que le SGA soit plus grand pour la 3 à cause du buffer cache non ?

[pachot]

Bonjour,

1- 30 bases sur le même serveur,

Ce n'est effectivement pas une très bonne idée. En dehors de la consommation des ressources, il est difficile de gérer 30 instances sur un seul serveur. Un instance peut se retrouver à prendre toutes la CPU par exemple. Alors qu'au niveau d'une seule instance il y a des outils comme le resource manager qui permet d'éviter cela.

2- Fusionnées les 30 bases en une seule,

C'est probablement le mieux si les modèles de données sont identiques. Mais ça demande une revue du modèle de données. Probablement rajouter une colonne dans toutes les clés. L'option de partitionnement (Entreprise Edition) sera utile pour isoler physiquement les données.

3- Créer 30 schémas dans une instance.

Un inconvénient par rapport au précédent: Pour chaque requête, il va y avoir 30 curseurs différents. C'est pas terrible au niveau de la shared pool.

il faut voir aussi qu'il peut y avoir un juste milieu entre 1 et 30. Par exemple si les bases régionales couvrent le monde entier, il peut être judicieux d'avoir quand même 2 ou 3 bases avec chacune leur ORACLE_HOME, à répartir en fonction des fuseaux horaires. Lorsqu'il y a une maintenance, patch ou upgrade, on peut éviter d'impacter le buisiness en faisant l'Europe la nuit, l'Amérique le matin et l'Asie le soir.

Cordialement,
Franck Pachot.

[ccaye]

Bonjour,

Merci beaucoup pour ces informations claires et précises. Je passe en [Résolu].

Je vais donc appuyer pour la solution 2 (la solution intermédiaire n'est pas justifiée pour d'autres contraintes que celles que je vous ai exposées) : les données des 30 bases sont toutes identiques, en effet j'avais déjà en tête de créer une clé de partitionnement pour isoler les données et optimiser les requêtes.

Cordialement,

christophe