Oracle: attente “enq: TX – row lock contention” sur un insert

On s’attend généralement à rencontrer des attentes de type “enq: TX – row lock contention” lorsque deux sessions concurrentes essaient de mettre à jour une même rangée existante d’une table, via des ordres update ou delete.

Il existe des cas particuliers où ces attentes se rencontrent lors d’insert de nouvelles rangées.

Cas 1: avec un index unique

Dans une session1, on crée une table avec un index unique et on insère une valeur sans faire de commit.

SQL-sess1> create table mytest (id number);
Table creee.

SQL-sess1> alter table mytest add constraint mytest_idx unique (id);
Table modifiee.

SQL-sess1> insert into mytest values (1);
1 ligne creee.

Dans une session2, on insère la même valeur dans la table; la session2 est bloquée.

SQL-sess2> insert into mytest values (1);
-

Sur la session1, on constate l’attente “enq: TX – row lock contention” de la session2.

SQL-sess1> select sid,blocking_session,event from v$session where lockwait is not null;
       SID BLOCKING_SESSION EVENT
----------------------------------------------------------------
       160              162 enq: TX - row lock contention

Sur la session1, on exécute le commit.

SQL-sess1> commit;
Validation effectuee.

Sur la session2, la session sort de son attente avec l’erreur de violation de contrainte.

SQL-sess2> insert into mytest values (1);
insert into mytest values (1)
*
ERREUR a la ligne 1 :
ORA-00001: violation de contrainte unique (SYS.MYTEST_IDX)

Cas 2: avec un index bitmap

Dans une session1, on crée une table avec un index bitmap et on insère une valeur sans faire de commit.

SQL-sess1> create table mytest(id number);
Table creee.

SQL-sess1> create bitmap index mytest_idx on mytest(id);
Index cree.

SQL-sess1> insert into mytest values(1);
1 ligne creee.

Dans une session2, on insère la même valeur dans la table; la session2 est bloquée.

SQL-sess2> insert into mytest values (1);
-

Sur la session1, on constate l’attente “enq: TX – row lock contention” de la session2.

SQL-sess1> select sid,blocking_session,event from v$session where lockwait is not null;
       SID BLOCKING_SESSION EVENT
----------------------------------------------------------------
       160              162 enq: TX - row lock contention

Sur la session1, on exécute le commit.

SQL-sess1> commit;
Validation effectuee.

Sur la session2, la session sort de son attente et effectue son insert.

SQL-sess2> insert into mytest values (1);
1 ligne creee.

SQL Server – Trouver le responsable d’un lock

Comme dans tout SGBD, il se peut qu’une session bloque un objet, empêchant ainsi les autres sessions de travailler dessus, les mettant donc en attente. C’est ce que nous appelons un lock.

Pour trouver le responsable de ce dernier, nous allons dans un premier temps utiliser la procédure stockée “sp_who2”.
Elle nous permettra de voir les différentes sessions bloquées en nous indiquant la fautive :

Résultat sp_who2

On peut constater que la session bloquante initiale est la 57.
Nous pouvons également récupérer le Login utilisé par la session, le DBName (base sur laquelle est lancé la requête), le type de commande…

Pour notre session 57, le champ ProgramName nous indique que cette dernière correspond à l’agent SQL Server et plus particulièrement, un job.

Nous allons voir de quel job il s’agit avec la requête suivante :

select * from msdb..sysjobs where job_id = 0x6E6EB18998743E42BA740122351F7BE7

Résultat requête

Il s’agit d’un job d’import comptable, ce dernier est à l’origine de la succession de locks.

Pour débloquer la situation, il faudra attendre qu’il se termine, ou l’arrêter/tuer la session (avec accord du client). Un rollback sera effectuer et lorsqu’il sera terminé, il n’y aura plus de lock.

Poussez-l’analyse un peu plus loin.
Avec la procédure stockée sp_WhoIsActive, il sera possible de récupérer les requêtes des sessions actives :

résultat sp_WhoIsActive

Il est également possible de voir le login_time de la session et le start_time de la requête :

info sp_WhoIsActive

On peut donc constater que notre session bloquante a lancé sa requête le 01/11/2019 à 06h00 du matin, ce qui correspond avec la planification du job.


Tracer les requêtes lentes sous MongoDB

MongoDB ne déroge pas à la règle comme sur les autres SGBDs il convient parfois pour des raisons d’optimisations d’activer le slow query. Ce dernier étant désactivé par défaut, il nous faut effectuer des manipulations pour le mettre en place.

Mais tout d’abord il faut savoir que contrairement à une grande partie de ses concurrents, nous pouvons l’activer uniquement sur certaines bases (ce qui évite de consommer des ressources inutilement).

(suite…)

Apache Cassandra 4.0 est dans les starting-blocks

Mais qu’attendre de cette nouvelle version ?

Tout d’abord il faut savoir qu’Apache Cassandra 4.0 se veut comme la version “la plus stable de l’histoire”. Il y a eu plus de 1000 bugs corrigés, des ajouts de nouvelles fonctionnalités, différentes optimisations, le support de JAVA 11 et bien d’autre encore …

Dans cet article nous allons vous parler de deux nouvelles fonctionnalités phares amenées par cette future version:

  • Les tables virtuelles
  • Le journal d’audit
(suite…)

MySQL 8.0.21, une révolution du dump !

MySQL propose depuis de nombreuses années un outil pour réaliser des dumps logiques, le fameux mysqldump que tout le monde connait. Malheureusement trop souvent utilisé à tord et notamment avec de trop grosses volumétries pour cet outil qui n’a pas réellement évolué depuis longtemps. Il est monothreadé, les exports sont longs et les imports encore plus.

Connaissez vous MySQLPump avec un P ?

Avec MySQL 5.7 un nouvel est outil est sortit, mysqlPump, une variante multithread avec des nouveaux filtres, cependant lors de la sortie, une indication a été donnée de ne pas l’utiliser tout de suite car il n’était pas fonctionnelle à 100% (et nous avons vécu ses défauts avec un de nos clients). Les problèmes rencontrés ont été corrigés dans les patchs suivants, sauf erreur de ma part. Mais il n’a pas percé et il est aujourd’hui un inconnu, alors qu’il est toujours présent en version 8.0. Son nom semble être un clin d’œil à l’outil de dump Oracle, EXP et son évolution EXPDP pour Export Data Pump, le fameux P.

(suite…)

Bascules d’un flux de réplication sous Attunity Replicate dans le cas d’une migration Oracle 11G vers 19C

Après avoir configuré notre premier flux de réplication entre notre base 11G et 19C, que celui est opérationnel et que vous n’avez noté aucun problème d’intégrité sur votre base cible 19C, il est maintenant temps que vos applications profitent de la belle 19C.

Pour ce faire, il y aura 2 étapes importantes :

  • La création d’un second flux de réplication à l’identique du premier mais en sens inverse que nous activerons au moment souhaité (attention, vous ne pouvez pas réutiliser vos Endpoint Connections déjà configurés)
  • Procéder à la bascule à proprement parlé dont nous parlerons ci-après
(suite…)

Oracle NID Utility : How to change the oracle database name or the database ID?

A must to know in the dba tool kit

NID utility was introduced in Oracle 10g. Prior to this utility, the alteration of the internal DBID of a database was impossible and alteration of the database name required the recreation of controlfils.

The NID utility allows to change easily the DBID and/or the database name.

The DBID is an internal, unique identifier for a database. RMAN uses this DBID to identify a database. If you restore a database on an other server and you want to backup the new database in your rman catalog, you have to change the DBID in order to register the database. You will not have to use NID if you use the duplicate command instead of the restore command.

Without rman catalog, you just want or need to rename your database ;o)

Note : This article doesn’t deal with how to change the path or your datafile or how to rename your pluggable database.

Overview

There are some steps to perform in order to change an Oracle database name or database id :

  • Prepared actions
  • Use NID
  • Change ORACLE_SID References
  • Post actions
(suite…)

Création d’un flux de réplication unidirectionnel Oracle 11G vers Oracle 19C avec QLIK Replicate

Après l’article traitant de l’installation de l’outil QLIK Replicate, nous allons créer un flux de réplication performant entre la base Oracle 11G en RAC et la base Oracle 19C en RAC. Nous allons mettre en place une supervision de ce flux de réplication ainsi que du serveur Attunity Replicate.

Actions préparatoires à la création du flux de réplication

Nous partirons du fait que la base 11G et la base 19C possèdent la même structure (tablespaces)

2 méthodes vous permettent de populer la base cible (19C) :

  • La méthode automatisée de Attunity Replicate, le FULL LOAD que nous n’utiliserons pas dans cet article car notre volume de données à importer est important (environ 600GO)
  • L’export avec SCN/import via datapump avec transfert du fichier dump.
(suite…)