Certains comportements natifs d’Oracle semblent parfois incompréhensibles. C’est le cas de la commande « alter tablespace read only » qui jusqu’à présent avait un comportement pour le moins anormal.
Cette commande attendait en effet que toutes les transactions en cours soient terminées, même celles concernant des objets n’appartenant pas au tablespace que l’on souhaitait passer en lecture seule ! Un comportement corrigé aujourd’hui, mais plutôt déconcertant et nécessitant certains éclaircissements.
Dans une session SQL*Plus, je crée 2 tablespaces TBS1 et TBS2 :

SQL> create tablespace TBS1 datafile +DG_DATA size 10M;
Tablespace créé.
SQL> create tablespace TBS2 datafile +DG_DATA size 10M;
Tablespace créé.

Dans cette même session, je crée ensuite une table dans chaque tablespace avec chacune une ligne :

SQL> create table T1 (C1 number) tablespace TBS1;
Table créée.
SQL> create table T2 (C1 number) tablespace TBS2;
Table créée.
SQL> insert into T1(C1) values(1);
1 ligne créée.
SQL> insert into T2(C1) values (1);
1 ligne créée.
SQL> commit;
Validation effectuée.

Mon jeu de test est prêt. Démonstration :
Dans une première session, je fais un insert dans la table T1 du tablespace TBS1 :

SQL> insert into T1(C1) values(2);
1 ligne créée.

J’ouvre en parallèle une seconde session SQL*Plus et je passe le tablespace 1 en read-only :

SQL> alter tablespace TBS1 read only;
... la session est en attente ...

Ce fonctionnement paraît normal.
J’ouvre en parallèle une troisième session SQL*Plus et je passe le tablespace 2 en read-only :

SQL> alter tablespace TBS2 read only;

… la session reste également en attente alors que la transaction en cours n’impacte
que la table C1 du tablespace TBS1 !
Et bien bonne nouvelle, ce bug a (enfin) été corrigé en 11gR2 sous l’impulsion de généreux contributeurs qui, je n’en doute pas, se reconnaitront. Grâce à cette correction, l’ordre va aboutir pour le tablespace 2 :
…

Tablespace modifié.

Seul le tablespace 1, impacté par la transaction en cours, reste en attente, ce qui semble être le comportement le plus compréhensible pour ce type d’opération.
Avant cette correction, il fallait terminer la transaction dans la première session SQL*Plus :

SQL> commit;
Validation effectuée.

pour voir se terminer immédiatement l’ordre dans la seconde session SQL*Plus :

...
Tablespace modifié.
SQL>

A noter son « back-port » sur des versions précédentes et pour certains OS.
Versions corrigées :
– 11.1.0.7,
– 10.2.0.5
Patches disponibles :
– 11.1.0.6 : sur HP-UX_IA64 et Linux_x86_64,
– 10.2.0.4 : (Patch 28) sur Windows_x86/x86_64/IA64,
Solaris_x86_64/SPARC64, Linux_x86/x86_64, HP-UX_IA64, AIX_POWER64,
– 10.2.0.3 : sur Solaris SPARC64,
– 9.2.0.8 : sur HP64.