Version imprimable
Bonjour,
Nous avons migré de la version 8i vers la version 9i et nous rencontrons depuis des ralentissements sur les modifications et les enrgistrements depuis notre applications alors que la consultation se déroule normalement.
Quel pourraient être la raison d'un tel ralentissement, un paramétrage spécifique à la 9i doit il être valorisé?
Merci d'avance pour votre aide.
C'est là tout le probléme des migrations : les perfs !!
Il faut dans un premier temps récupérer le code et comparer les plan d'éxècutions sur la 8i et la 9i.
On peut essayer de reproduire le comportement d'une 8i sur un 9i du point du vue de l'optimiseur grâce au paramétre compatible.
est-ce que les stats ont bien été recalculée et les objets invalides recompilés ?
Oui les stats ontbien été recalculée; en fait on a des tables qui sont lockées et qui le restent ????Citation:
Envoyé par Fred_D
Etes-vous absolument sûr que des tables (et non des lignes) sont verrouillées ?
Si oui, cela signifie très probablement qu'une application utilise LOCK TABLE et que la transaction ne se termine pas car Oracle n'utilise normalement pas le LOCK TABLE en interne.
En fait, il y 1 cas connu où Oracle va utiliser LOCK TABLE. Il faut pour cela:
- qu'une table enfant soit liée à une table parent par une contrainte foreign key
- que la table enfant n'ait pas d'index sur sa foreign key
- que la clé primaire dans la table parent soit modifiée ou qu'une ligne soit supprimée dans la table parent
Si ces conditions sont réunies, alors la table enfant va être verrouillée par un LOCK TABLE jusqu'à ce que la transaction qui modifie la table parent se termine par COMMIT ou ROLLBACK.
Ceci dit, ce comportement existe à priori dans toutes les versions d'Oracle 8, 9 et 10 et la table n'est verrouillée que pendant la transaction sur la table parent.
Est-ce votre cas ?
Je vérifierai demain; mais je crois que cela peux être une explication sérieuse. Merci de votre aideCitation:
Envoyé par pifor
En fait se ne sont pas les tables qui sont lockées se sont des transactions qui sont exclusives et qui, selon notre dba, persistent même si la session est inactive. Selon lui il se pourrait que se soit applicatif, au niveau de Forms.
Ce qui me surprend c'est que nous n'avions pas ce problème avant de migrer sur oracle 9i (nous étions alors sur 8i). Y'a t'il un patch à passer pour travailler avec Forms 6i sur une base oracle 9i.
version forms 6.0.8.22.1
S'il ne s'agit pas de verrouillage de table, il s'agit de verrouillage de ligne qui est soit effectué par l'application explicitement par SELECT FOR UPDATE ou soit implicitement par Oracle à chaque INSERT/UPDATE/DELETE. Je ne pense que beaucoup de choses aient changés à ce niveau dans Oracle 9 par rapport à Oracle 8
.
Peut-être que Forms génère un un verrouillage différent ?
Peut-être que la durée des transactions a changé ? Est-ce qu'il y avait un time-out avant qui générait peut-être un ROLLBACK au bout d'un certain temps ? Ce qui est sûr c'est que les verrous ne sont libérés qu'au COMMIT ou au ROLLBACK.
En fait sur la base 9i le paramètre distributed_lock_timeout est à 60. Ce paramètre n'existe pas sur 8i.
Savez vous quel est le paramètre équivalent sur la 8i. Ou savez vous comment est gérer le time out sur 8i.
Merci d’avance
Je crois que ce paramètre est utilisée par des transactions qui utilisent 2 bases de données différentes. Est-ce votre cas ?
Côté base de données, le time-out est en général géré par la valeur IDLE_TIME du profil Oracle associé aux comptes Oracle.
Exemple:
déconnecte au bout de 5 minutes d'inactivité base de de données les utilisateurs qui ont le profil Oracle "default".Code:
2
3
4
Je ne connais pas Forms mais je me demande s'il n'y a aussi quelque chose de similaire ?
Pour consulter les différentes valeurs IDLE_TIME des profils sur votre base, utiliser:
Pour consulter les profils associés aux comptes, exécuter:Code:select * from dba_profiles where resource_name like '%IDLE%';
Code:select username, profile from dba_users;
Merci de vos réponse. je viens de regarder le paramètre idle_time il est basé sut le profil par défaut et à pour valeur UNLIMITED.