Colonne cachée (HIDDEN COLUMN)

Bonjour,

Je viens d'effectuer l'ajout d'un champ dans une table existante via la syntaxe suivante :

Code:

---

ALTER TABLE TABLE_TEST ADD (TST_FLG_PMO NUMBER(1) DEFAULT 0);

---

Le champ est bien créé mais je me suis rendu compte avec un outil (SSMA outil de migration Oracle vers Sql Server) que cela avait créé un champ supplémentaire caché :

Code:

---

1 2 3 4 5 6

CREATE TABLE SCHEMA.TABLE_TEST ( ... TST_FLG_PMO NUMBER(1, 0) DEFAULT 0, SYS_NC00109$ RAW(126) );

---

Ce champ, est mentionné dans la table USER_TAB_COLS (mais pas dans USER_TAB_COLUMNS). Après avoir effectué des tests, cet ajout est lié à "DEFAULT 0".

Ce qui me surprend, c'est que ce n'est pas la première fois que nous ajoutons des champs de ce type dans notre schéma et que ce champ caché n'existe pas toujours ...
Est-ce que cela est lié à un paramétrage spécifique de la base ?
D'avance merci pour vos réponses.

Bonjour,

Tu es sûr de n'avoir fait que l'alter table et que tu n'as pas créé un index de fonction sur cette colonne en plus ?
Parce que pour moi ce sont des colonnes créées lors d'index de fonction

Bonjour,
Merci pour ton retour.
Oui, je suis sûr de n'avoir créé que ce champ.
D'ailleurs sous Sql Developer, j'arrive à reproduire la situation.

Code:

---

1 2 3 4

SELECT * FROM dba_IND_COLUMNS WHERE column_name ='SYS_NC00109$'     select * from dba_indexes where index_name = 'xxx'

---

Depuis la version 11 d'Oracle une amélioration a été mise en place : si tu ajoutes une colonne sur une table (avec un ALTER TABLE donc) et que cette colonne a une valeur par défaut, alors Oracle ne va pas faire un UPDATE de tous les enregistrements (ça prends trop de temps, ça génère trop de redo logs), il va créer une metadata où est renseignée cette valeur par défaut : c'est immédiat. Visiblement, comme tu l'as constaté, Oracle implémente cette optimisation via une colonne cachée.

Merci pour vos réponses.

@McM : je n'ai aucune ligne en retour.

@Ikebukuro : Est-ce que tu sais si cette metadata est définitive ou provisoire ou bien est-il possible de faire différemment ? Dans le cas de mon test, ça plante la migration des données de ma table étant donné que la structure est différente.

Encore merci.
Cordialement.

Citation:

---

Envoyé par HanSolo44

@Ikebukuro : Est-ce que tu sais si cette metadata est définitive ou provisoire ou bien est-il possible de faire différemment ? Dans le cas de mon test, ça plante la migration des données de ma table étant donné que la structure est différente.

---

Pour moi c'est définitif, vu que c'est une optimisation Oracle, je ne pense pas que tu ais la main sur comment Oracle gère la Default Value d'une nouvelle colonne.
Après, peut-être, je dis bien peut-être, que tu pourrais désactiver cela via un paramètre caché, que je ne connais pas, le temps de ta migration mais je ne le sens pas bien.

Plus simple : si cette colonne cachée te gêne, tu peux la supprimer (avec un user ayant les bons droits) et ensuite faire un update + commit de la colonne avec la default value, non?

Citation:

---

Envoyé par HanSolo44

Bonjour,

Je viens d'effectuer l'ajout d'un champ dans une table existante via la syntaxe suivante :

Code:

---

ALTER TABLE TABLE_TEST ADD (TST_FLG_PMO NUMBER(1) DEFAULT 0);

---

Le champ est bien créé mais je me suis rendu compte avec un outil (SSMA outil de migration Oracle vers Sql Server) que cela avait créé un champ supplémentaire caché :

Code:

---

1 2 3 4 5 6

CREATE TABLE SCHEMA.TABLE_TEST ( ... TST_FLG_PMO NUMBER(1, 0) DEFAULT 0, SYS_NC00109$ RAW(126) );

---

---

Voici un article que j'ai écris il y a déjà quelques années qui explique votre cas. C'est arrivé en 12cR1 où ce qu'on appelle communément ''DDL optimisation'' a été étendu à l'ajout de colonnes ayant une valeur par défaut mais pouvant être nulles (voir partie IV)

https://houri-mohamed.developpez.com...misations-ldd/

Il existe un paramètre caché qui gouverne cette technique: _add_col_optim_enabled

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

SQL> select n.ksppinm ,c.ksppstvl ,n.ksppdesc from sys.x$ksppi n ,sys.x$ksppcv c where n.indx=c.indx and n.ksppinm = '_add_col_optim_enabled';   KSPPINM KSPPSTVL KSPPDESC ---------------------- ---------- ----------------------------------- _add_col_optim_enabled TRUE Allows new add column optimization

---

Mais dans votre cas, il me semble que vous héritez d’une situation ou ce genre de colonnes existe déjà. Cela ne servirait donc à rien de changer ce paramètre.

Je vous mets ici un autre article concernant une cas pratique que j’ai rencontré et qui pourrait éventuellement surgir dans votre cas si le paramètre compatible n’est pas à la bonne valeur

https://hourim.wordpress.com/2018/03...-12cr2-really/

Bien à vous
Mohamed

Bonjour Mohamed,

Merci beaucoup pour votre réponse et pour vos articles. C'est super bien expliqué.
C'est exactement la situation que je rencontre et cela pose un souci lors de l'utilisation de l'outil "Sql Server Migration Assistant" car je travaille à partir d'un schéma cible sur lequel j'effectue (uniquement) la migration des données. Dans le schéma de la table cible, cette colonne cachée n'est pas présente d'où mon problème.
Vos articles sont très explicites et avec toutes ces explications, on se sent moins seul ;)
Bonne continuation.
Cordialement
Philippe