Bonjour,

Je rencontre des soucis sur un environnement qui m'a causé mardi un problème sur le tablespace UNDOTBS1. Je ne pouvais plus faire d'ordres SQL, à l heure actuel les lenteurs sont consternantes.
Après des échanges avec le support DBA de mon entreprise, ce tablespace est passé de 1Go à 3go et moins de 12H après ils ont été le monté à 6Go et il a déjà un taux d'occupation de 48%

Le soucis est que les instances oracles connectés sont des instances de travail / d'échange la table la plus active est plus table de logs.
Sur cette table de logs il y a
- un trigger pour un increment et 2/3 petites choses
- une vue matérialisée qui reprend les données des 3 derniers jours
- une proc/stock qui purge les données de plus de 30 jours.

Hors actuellement sur l'environnement de test, la table compte un peu moins de 600.000 lignes pour une taille de plus de 1Go, quand en prod sur la meme structure nous sommes à 1.9 Millions de lignes pour 445Mo
J'ai 2 autres domaines marchant sur le meme système et ils ont tous des ratios equivalent à cette prod la (la taille moyenne d'un enregistrement fait donc entre 250 et 500 octets quand sur l'instance à problème c'est 1.9ko)

N'ayant aucun droits dba (pas de requetes possibles sur les v$ / dba_) j'ai du mal à investiguer et vu que le support DBA n'est pas motivé à s'activer ....
Vous avez des idées / des pistes ?

Salut
 
Si, comme son nom semble l'indiquer, il s'agit du tablespace par defaut pour le undo, tu devrais chercher pourquoi le undo grossit autant.
 
En parametrage "classique", le undo va grossir ce qu'il a besoin pour assurer le respect des normes ACID; en gros si tu as une transaction qui commence a updater des trucs en masse, le undo va se charger de garder les valeurs originales quelque part, et faire en sorte de les garder tant que n'importe qui d'autre peut en avoir besoin. En pratique, deux cas reviennent souvent:
1 - tu as un gros process (ou une grosse requete) qui update des trucs en masse et ne commit qu'une fois a la fin. Tant que le commit n'est pas issu, le undo doit tout garder (pour pouvoir annuler les changements au cas ou ca finit par un rollback au lieu du commit) et va donc grossir.
2 - tu as une requete de type select longue (qui s'execute en prenant beaucoup de temps) et a cote de ca, des requetes (grosses ou petites peu importe) qui updatent des donnees. Parce que la requete longue doit retourner les resultats tels qu'ils etaient au moment ou elle a commence (contrainte ACID), tant que la requete select n'est pas terminee, le undo des requetes d'update doit etre conserve meme si celles-ci sont commit (pour pouvoir a tout moment determiner l'etat "original" des donnees de la requete select).
 
En gros. Donc regarde si tu as une requete ou un process qui tourne en continu depuis plusieurs jours; regarde les sessions actives pour ca, ou choppe des AWRs.
Si t'en as un qui fait des updates, regarde si tu peux lui faire faire des commits reguliers.
Si t'as une grosse requete select qui retourne jamais, tue sa session.
 
A+

pfff aucun droit sur les v$session et autres

Il manque peut-être des Commit, parce que l'environnement qui marche bien aurait autocommit on, et celui qui ne va pas n'aurait pas l'autocommit par défaut.
 
Ou bien, il faudrait voir au niveau de la définition de la table, pour voir ses paramètres de STORAGE : INITIAL, MINEXTENTS, et MAXEXTENTS. S'ils ne sont pas définis explicitement au moment de la création de la table, alors ils prennent des valeurs par défaut qui ne sont peut-être pas les bonnes. Il faudrait avoir ces paramètres-là qui soient identiques dans les deux environnements.

Prod :  STORAGE(INITIAL 81920 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
Test : STORAGE(INITIAL 81920 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
 
C'est la meme chose, merci pour la piste.
 
J'ai fait une demande pour avoir des droits etendus pendant 24H histoire de fouiller un peu de mon coté avec plus d'informations, j'espere que ca va m’être accordé.
 
Et oui je pense qu'il y a une transaction quelque part qui n'a pas commit ou qui est toujours ouverte mais voila actuellement je peux pas le savoir