Discussion :

[Wurlitzer]

Bonjour,

Je suis en 8.1.7.4 sur une base avec un millier d'utilisateur. J'ai une activité essentiellement transactionnelle.

Ma première question est comment faire pour determiner combien de RBS il me faut et de quelle taille ? J'ai lu quelque part qu'il en fallait : (nbr d'utilisateur) / 3 mais dans mon cas ca commence a faire beaucoup ! !

Par ailleurs, j'ai aussi quelques gros batchs qui tournent en parrallèle des utilisateurs. Pour eux la solution me semble être de créer un gros RBS et de leur affecter par un SET TRANSACTION. J'ai bon ? Mais comment faire pour les utilisateurs normaux eux n'utilisent pas ce gros RBS ?

Merci de votre aide

[Jaouad]

Bonjour,

Je suis en 8.1.7.4 sur une base avec un millier d'utilisateur. J'ai une activité essentiellement transactionnelle.

Ma première question est comment faire pour determiner combien de RBS il me faut et de quelle taille ? J'ai lu quelque part qu'il en fallait : (nbr d'utilisateur) / 3 mais dans mon cas ca commence a faire beaucoup ! !

Par ailleurs, j'ai aussi quelques gros batchs qui tournent en parrallèle des utilisateurs. Pour eux la solution me semble être de créer un gros RBS et de leur affecter par un SET TRANSACTION. J'ai bon ? Mais comment faire pour les utilisateurs normaux eux n'utilisent pas ce gros RBS ?

Merci de votre aide

Bonjour ,
la gestion des RBS sous la 8i est une véritable gestion et peut être source de gros goulot d'étranglement si ceux ne sont pas optimales.

Set transaction et gros RBS:
Effectivement il est mieux de distinguer le batch du transactionnel. Si tu ne peux et que les deux se percute, dans ce càs la il convient de créer un RBS pour les Baths et de l'affecter via le set transaction. Comment s'assurer que le transactionnel ne l'utilise pas c'est impossible. Tu peux limiter cela en faisant un offline online de tes RBS lorsque tu lances les Batchs grâce à la commande SQL :

Code :

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

ALTER ROLLBACK SEGMENT RBS_NAME OFFLINE/ONLINE ;

mais rien ne vas t'assurer que durant ce laps de temps une transaction ne se servirat pas également de ton RBS

Le paramétre transactions_per_rollback_segment ( à 5 par défaut ) vaut pour tous les RBS , donc on ne peut même pas envisager de le mettre à 1

Tuning des RBS :
Il convient de vérifier deux points importants.

Il existe assez de Rollbacks ( au vu du paramétre cité ci dessus ) pour satisfaire toute nouvelles demandes de RBS et ne pas attendre qu'un RBS se libére.

Il existe assez d'initial pour que lors de la premiére connection Oracle ne fasse pas trop d'ordre SQL récursifs pour accroitre sa taille ( ces ordres sont synonymes de ralentissements ).C'est ce que l'on appelle en language commun avoir des "RBS bien taillés"

Cela se vérifie en régle génèral avec les vues de stat et statspack.

jaouad

[jlucch]

Pourquoi cherches tu à empêcher les utilisateurs de travailler dans ton big RBS ??

Je comprends que tes traitements batchs génent dans tes RBS normaux, mais un utilisateur OLTP ne devrait "a priori" pas gèner ton batch ....

[LeoAnderson]

Si, le paramètre transactions_per_rollback_segment limite le nombre de transactions par RBS.
Donc, si 5 OLTP sont sur le BIG RBS, le batch ne pourra pas passer...


Dans ce genre de circonstances, si les besoins l'exigent vraiment, je vous conseillerait d'avoir 2 instances de bases, une pour l'OLTP, l'autre pour les batch, chacune avec leurs RBS dédiés et leurs tuning mémoire ... mais cela a évidemement un coût qui est loin d'être négligeable....