Oracle Standard Edition High Availability

SEHA

Comme je l’avais indiqué dans un précédent post (ici), à  partir de la version 19c, Oracle Real Application Clusters (RAC) n’est plus supporté en Standard Edition.

Dans ce post, j’avais mentionné la possibilité d’utiliser Oracle Grid Infrastructure pour gérer la disponibilité d’une instance Oracle entre deux serveurs, dans une configuration actif/passif (l’instance Oracle est active sur un seul serveur à la fois), mais cela nécessite un peu de travail de mise en place (écriture d’un script chargé de gérer les actions de démarrage, d’arrêt et de vérification, création d’un type de ressource puis d’une ressource). Fondamentalement, ce n’est pas très compliqué, mais c’est quand même du travail en plus, et c’est toujours mieux s’il existe une fonctionnalité native qui le fait. 

Et bien voilà, c’est fait !

Annoncé en mars 2020, Oracle a officiellement mis à disposition Oracle Standard Edition High Availability sous Linux, Microsoft Windows et Solaris dans le cadre de la Release Update (RU) 19.7 d’Oracle Database 19c (avril 2020).

Oracle SE HA propose une solution de type failover (actif/passif) pour des instances Standard Edition en utilisant une configuration Oracle Grid Infrastructure qu’il convient donc d’installer au préalable (version 19c RU 19.7 ou ultérieure).

Ensuite, il suffit d’installer Oracle Database (version 19c RU 19.7 ou ultérieure) sur les deux noeuds du cluster, en mode « instance seul » (pas « Real Application Clusters » et d’opter pour la Standard Edition 2 :

OUI
OUI

Une fois l’installation terminée, il ne reste plus qu’à créer une base de données avec DBCA (Database Configuration Assistant, méthode recommandée), en sélectionnant bien ASM pour le stockage (stockage partagé entre les deux noeuds du cluster) :

DBCA

Une fois la création terminée, la base de données est automatiquement enregistrée avec Oracle Clusterware (fonctionnalité Oracle Restart) et l’utilitaire srvctl peut être utilisé pour modifier la configuration de la base de données et activer SE HA :

[oracle@clu1 ~]$ srvctl stop database -db db1
[oracle@clu1 ~]$ srvctl modify database -db db1 -node clu1,clu2
[oracle@clu1 ~]$ srvctl start database -db db1
[oracle@clu1 ~]$ srvctl status database -db db1
Instance DB1 is running on node clu1
[oracle@clu1 ~]$ srvctl config database -db db1
Database unique name: DB1
Database name: DB1
Oracle home: /u01/app/oracle/product/19.0.0/dbhome_1
Oracle user: oracle
Spfile: +DATA1/DB1/PARAMETERFILE/spfile.273.1040732475
Password file: 
Domain: 
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: 
Disk Groups: DATA1
Mount point paths: 
Services: 
Type: SINGLE
OSDBA group: dba
OSOPER group: oper
Database instance: DB1
Configured nodes: clu1,clu2
CSS critical: no
CPU count: 0
Memory target: 0
Maximum memory: 0
Default network number for database services: 
Database is administrator managed

Dans la configuration, nous voyons que la base de données est de type SINGLE (pas RAC) et qu’elle est configurée sur deux noeuds.

C’est fini, la base de données est protégée par SE HA. Si l’instance s’arrête inopinément, elle est automatiquement redémarré par Oracle Clusterware (fonctionnalité Oracle Restart déjà existante). Si le serveur sur lequel l’instance est démarrée s’arrête brutalement, l’instance est automatiquement redémarrée sur un autre serveur disponible du cluster. Pour de la maintenance planifiée, ou pour un retour à la normale après une bascule sur un autre serveur, il est possible d’utiliser la commande srvctl relocate :

oracle@clu1 ~]$ srvctl relocate database -db db1 -node clu2
[oracle@clu1 ~]$ srvctl status database -db db1
Instance DB1 is running on node clu2

Il est important de noter que cette commande provoque un arrêt de la base de données sur le serveur d’origine puis un démarrage sur le serveur cible ; cela ne se fait pas à chaud.

Pour la connexion à la base de données à partir des applications, il est conseillé d’utiliser le SCAN (Single Client Access Name) comme nom de serveur dans les adresses réseaux. Ce nom, défini et géré par Oracle Clusterware sur les différents noeuds du cluster, permet de se connecter à l’instance quelle que soit son emplacement, et cela sans devoir modifier la configuration côté client. Ce nom peut être utilisé dans une connexion Easy Connect ou dans un nom de service réseau défini dans le fichier tnsnames.ora.

[oracle@clu1 ~]$ sqlplus system/xxxxxxxxxx@clu-scan/db1

SQL*Plus: Release 19.0.0.0.0 - Production on Wed May 20 06:51:11 2020
Version 19.7.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.
Last Successful login time: Wed May 20 2020 06:50:56 +02:00

Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.7.0.0.0

SQL> exit        
Disconnected from Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.7.0.0.0

[oracle@clu1 ~]$ cat $ORACLE_HOME/network/admin/tnsnames.ora 
DB1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = clu-scan)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = DB1)
    )
  )

[oracle@clu1 ~]$ sqlplus system/xxxxxxxxxx@db1

SQL*Plus: Release 19.0.0.0.0 - Production on Wed May 20 06:50:56 2020
Version 19.7.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.
Last Successful login time: Wed May 20 2020 05:56:35 +02:00

Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.7.0.0.0

SQL> exit
Disconnected from Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.7.0.0.0

Et la licence me direz-vous ?

Oracle Standard Edition High Availability est disponible sans coût supplémentaire par rapport à la Standard Edition 2, et Oracle Grid Infrastructure en lui même ne nécessite pas de licence.

Par ailleurs, cette configuration active/passive peut être utilisée sans licencier le deuxième serveur  en utilisant la règle des 10 jours (voir Data Recovery using Clustered Environments (Failover)). Pour mémoire, cette règle donne le droit d’exécuter une base de données sur un serveur de secours sans licence, dans un environnement de type failover, pendant un total de 10 jours différents au cours de l’année. Il faut noter que la Standard Edition High Availability est soumise à la limitation du nombre de sockets (2 maximum) par serveur et non pas pour la totalité cluster.

Si vous avez plusieurs base de données à protéger, il peut être intéressant de licencier le deuxième serveur, de répartir les bases de données sur les deux serveurs, chaque serveur étant le secours de l’autre (configuration failover croisée). 

OPatchAuto

opatchauto

 

 

Appliquer un patch sur une configuration Real Application Cluster, ou sur une configuration Oracle Grid Infrastructure for a Standalone Server (qui comporte Oracle ASM pour la gestion du stockage et Oracle Restart pour le redémarrage automatique des instances) n’est pas une mince affaire.

Dans les grandes lignes, il faut :

  • Arrêter les différents services
  • Appliquer le patch sur l’installation Oracle Grid Infrastructure (Grid Home) et sur l’installation Oracle Database (Database Home)
  • Effectuer les tâches de post-installation pour chaque base de données (typiquement le chargement des fichiers SQL modifiés, avec datapatch pour les versions postérieures à la version 12.1)
  • Redémarrer les services

Pour faciliter cette opération il est possible d’utiliser OPatchAuto, un outil ligne de commande qui vient avec l’utilitaire OPatch. Cet outil va interroger la configuration existante et automatiser les différentes étapes requises pour appliquer le patch à la configuration, le tout en un seul appel du type opatchauto apply.

La commande apply propose différentes options qui permettent si besoin de dissocier les différentes étapes (d’abord le Grid Home, puis les bases de données), d’effectuer une analyse préalable (sans installation du patch), etc.

OPatchAuto propose aussi d’autres commandes pour reprendre une installation qui échoué (resume) ou annuler l’installation du patch (rollback).

A titre d’exemple, je l’ai utilisé très récemment sur une configuration Oracle Grid Infrastructure for a Standalone Server 19c pour appliquer le Release Update 19.7 sorti en avril 2020. En plus du Grid Home, ma configuration comporte 3 installations Oracle Database (une Standard Edition 2, et deux Enterprise Edition) et 7 bases de données, ce qui en manuel m’aurait pris un peu de temps.

Un petit coup de opatchauto apply et 90 minutes plus tard c’était bouclé (à peu près le temps qu’il faut pour revoir un vieil épisode de Columbo en VOD 🙂).

Statut du support des différentes versions d’Oracle

Les dates annoncées de fin de support des différentes versions d’Oracle Database sont les suivantes :

VersionSupport PremierSupport Étendu
19c30/04/202430/04/2027
18c08/06/2021N/A
12.2.0.130/11/2020
(prolongé par une période Limited Error Correction jusqu’au 31/03/2022)
N/A
12.1.0.231/07/201831/07/2021
11.2.0.401/01/201531/12/2020
N/A : Non Applicable

La version 11.2.0.4 a bénéficié d’un support étendu gratuit particulièrement long qui s’est terminé le 31/12/2018 (les patchs sortis après le 01/01/2019 nécessitent un support étendu payant pour pouvoir être téléchargés). La version 19c est présentée comme la version de support long terme de la famille 12.2. C’est la cible de migration conseillée pour toutes les versions antérieures.

Source : Oracle Support Document 161818.1 (Oracle Database (RDBMS) Releases Support Status Summary)

Mise à jour le 25/06/2020 (prolongement d’un an du support de la version 19c).

Support Oracle 12.2

Oracle a annoncé récemment que la version 12.2 d’Oracle Database allait être supportée 16 mois au delà de la fin de support premier initialement prévue le 30/11/2020, soit jusqu’au 31/03/2022, et cela sans coût supplémentaire.

Durant cette période, intitulée Limited Error Correction, Oracle s’efforcera de fournir des correctifs pour les anomalies de niveau 1, ainsi que des correctifs de sécurité par le biais des Release Update trimestriels habituels.

Cette annonce laisse du coup plus de temps pour migrer vers une version plus récente, typiquement la version 19c qui est la version de support long terme courante (support premier jusqu’au 31/03/2023)

Source : Oracle Database (RDBMS) Releases Support Status Summary (Doc ID 161818.1)

Oracle Real Application Clusters (RAC) plus supporté en Standard Edition à partir de la version 19c

Jusqu’à maintenant (versions 11g, 12c et 18c), Oracle Real Application Clusters (RAC) était supporté en Standard Edition (Standard Edition 2 dorénavant) du moment que la configuration respectait le nombre total de sockets autorisés (4 en Standard Edition, 2 en Standard Edition 2). Cette possibilité est intéressante car elle permet d’avoir une solution de haute disponibilité pour un coût raisonnable.

Malheureusement, à partir de la version 19c, Oracle Real Application Clusters (RAC) n’est plus supporté en Standard Edition.

Pour migrer en 19c, les clients qui utilisent Oracle Real Application Clusters en Standard Edition n’auront que deux possibilités :

  1. Passer en Entrerprise Edition pour pouvoir continuer à utiliser RAC, mais avec une augmentation significative du coût des licences
  2. Abandonner RAC et passer en mono instance

Dans cette deuxième hypothèse, il est intéressant de noter qu’il est possible d’utiliser Oracle Grid Infrastructure pour gérer la disponibilité d’une instance Oracle entre deux serveurs, dans une configuration actif/passif (l’instance Oracle est active sur un seul serveur à la fois). Dans cette configuration, s’il y a plusieurs instances à protéger, il est tout à fait possible de répartir les instances sur les deux serveurs et de faire en sorte que chaque serveur soit le secours de l’autre.

Remarque : sur plate-forme Windows, il est aussi possible d’utiliser Oracle Fail Safe (solution de haute disponibilité intégrée à Microsoft Failover Cluster).

Nouveau (avril 2020) : Oracle a introduit une solution Standard Edition High Availability avec la version Oracle Database 19c, Release Update (RU) 19.7. Voir le post à ce sujet ici.

ORA-12899: value too large for column lors du rafraîchissement d’une vue matérialisée

La longueur des colonnes d’une vue matérialisée est définie lors de la création de la vue matérialisée. Si la longueur d’une colonne d’une table utilisée dans la vue matérialisée change, la taille de la colonne correspondante dans la vue matérialisée n’est pas modifiée ce qui peut conduire à une erreur ORA-12899 si la longueur a été augmentée.

Exemple :

SQL> create table t(x varchar2(4));

Table T created.

SQL> create materialized view mv as select * from t;

Materialized view MV created.

SQL> desc mv
Name Null? Type 
---- ----- ----------- 
X          VARCHAR2(4) 

SQL> select object_name,object_type,status from user_objects where object_name = 'MV';

OBJECT_NAME     OBJECT_TYPE             STATUS 
--------------- ----------------------- -------
MV              TABLE                   VALID 
MV              MATERIALIZED VIEW       VALID

SQL> select mview_name,staleness,compile_state from user_mviews where mview_name = 'MV';

MVIEW_NAME      STALENESS           COMPILE_STATE 
--------------- ------------------- -------------------
MV              FRESH               VALID

SQL> alter table t modify x varchar2(8);

Table T altered.

SQL> desc mv
Name Null? Type 
---- ----- ----------- 
X VARCHAR2(4) 

SQL> select object_name,object_type,status from user_objects where object_name = 'MV';

OBJECT_NAME     OBJECT_TYPE             STATUS 
--------------- ----------------------- -------
MV              TABLE                   VALID 
MV              MATERIALIZED VIEW       INVALID

SQL> select mview_name,staleness,compile_state from user_mviews where mview_name = 'MV';

MVIEW_NAME      STALENESS           COMPILE_STATE 
--------------- ------------------- -------------------
MV              NEEDS_COMPILE       NEEDS_COMPILE

SQL> insert into t(x) values ('Olivier');

1 row inserted.

SQL> commit;

Commit complete.

SQL> exec dbms_mview.refresh('mv')

Error starting at line : 1 in command -
BEGIN dbms_mview.refresh('mv'); END;
Error report -
ORA-12008: error in materialized view refresh path
ORA-12899: value too large for column "OHEURTEL"."MV"."X" (actual: 7, maximum: 4)
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2821
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 3058
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 3017
ORA-06512: at line 1

SQL> desc mv
Name Null? Type 
---- ----- ----------- 
X          VARCHAR2(4) 

SQL> select object_name,object_type,status from user_objects where object_name = 'MV';

OBJECT_NAME     OBJECT_TYPE             STATUS 
--------------- ----------------------- -------
MV              TABLE                   VALID 
MV              MATERIALIZED VIEW       INVALID

SQL> select mview_name,staleness,compile_state from user_mviews where mview_name = 'MV';

MVIEW_NAME      STALENESS           COMPILE_STATE 
--------------- ------------------- -------------------
MV              COMPILATION_ERROR   COMPILATION_ERROR 

Comme le montre cet exemple, après avoir augmenté la longueur d’une colonne de la table sous-jacente, la vue matérialisée a été marquée INVALID et  NEEDS_COMPILE (à recompiler). Lors du rafraîchissement de la vue matérialisée, Oracle a tenté de recompiler la vue mais sans succès ; la longueur de la colonne dans la vue matérialisée est restée inchangée ce qui a provoqué l’erreur ORA-12899.

Pour résoudre ce problème, le plus simple, sans reconstruire complètement la vue matérialisée, consiste à modifier aussi la longueur de la colonne dans la vue matérialisée.

Exemple : 

SQL> alter materialized view mv modify x varchar2(8);

Materialized view MV altered.

SQL> exec dbms_mview.refresh('mv')

PL/SQL procedure successfully completed.

SQL> desc mv
Name Null? Type        
---- ----- ----------- 
X          VARCHAR2(8) 

SQL> select object_name,object_type,status from user_objects where object_name = 'MV';

OBJECT_NAME     OBJECT_TYPE             STATUS 
--------------- ----------------------- -------
MV              TABLE                   VALID  
MV              MATERIALIZED VIEW       VALID  

SQL> select mview_name,staleness,compile_state from user_mviews where mview_name = 'MV';

MVIEW_NAME      STALENESS           COMPILE_STATE      
--------------- ------------------- -------------------
MV              FRESH               VALID              

Patch des bases de données antérieures à la version 11.2.0.3 avant avril 2019

Une note récente sur le site du support Oracle (2335265.1 – Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links) indique que les bases de données Oracle antérieures à la version 11.2.0.3 devront avoir un niveau de patch minimum avant avril 2019 pour assurer le bon fonctionnement des database links.

Les bases de données en versions 12.2.0.1 et ultérieures, 11.2.0.4 et 12.1.0.2 ne sont pas concernées car elles incorporent déjà le correctif.
Pour les versions précédentes (12.1.0.1, 11.2.0.3 et 11.1.0.7), un niveau minimum de patch précisé dans la note du support Oracle doit être appliqué. Pour les versions encore plus anciennes, une mise à niveau est requise.

A priori, le patch ou la mise à niveau sera nécessaire uniquement pour continuer à utiliser des database links avec les dernières versions de la base de données ou avec des versions patchées. Normalement, un database link entre deux bases de données anciennes ou non patchées devrait continuer à fonctionner sans problème.

Pour toute question, il ne faut pas hésiter à contacter le support Oracle ou consulter le forum dédié à ce sujet (https://community.oracle.com/message/14710245#14710245).

Oracle Database 18c

Oracle 18c

Annoncée lors du dernier Oracle Open World en octobre 2017, la version Oracle Database 18c est disponible depuis la fin de la semaine dernière dans Oracle Cloud et dans les Engineered Systems Oracle (les serveurs commercialisés par Oracle). Pour la version on-premise, installable sur vos propres serveurs, il faudra attendre un peu (2ème semestre 2018).

Oracle Database 18c est la première version de la base de données qui utilise une numérotation de version annuelle. Malgré le grand saut dans la numérotation des versions, cette nouvelle version n’est pas une version majeure mais l’équivalent d’une version 12.2.0.2. Elle apporte néanmoins un certain nombre de nouveautés que vous pouvez découvrir dans la documentation :

Pour les impatients, il est possible de commencer à jouer avec Oracle Database 18c grâce à Oracle Live SQL, un environnement Web gratuit qui permet de tester du code SQL et PL/SQL :

Oracle Live SQL

En parcourant rapidement la documentation, j’ai vu quelques nouveautés intéressantes dans les fonctionnalités relatives au développement :

  • Table temporaire privée
    • Table temporaire stockée en mémoire visible uniquement par la session qui l’a créée
  • Possibilité de réinitialiser une séquence à une valeur donnée (annoncé dans la documentation mais visiblement pas implémenté)
  • Fonction table polymorphique
    • Fonction table dont la structure de retour (liste des colonnes, type de données des colonnes) peut changer en fonction de l’appel
  • Expressions qualifiées dans l’affectation de valeurs à un enregistrement PL/SQL (RECORD) ou l’initialisation d’une collection.
    Exemple :
declare
 type type_table_chiffres is table of varchar2(10) index by pls_integer;
 t_impair type_table_chiffres;
begin
 -- Nouvelle notation pour initialiser la collection.
 t_impair := type_table_chiffres(1 => 'Un', 3 => 'Trois', 5 => 'Cinq');
end;
/

ORA-54032: column to be renamed is used in a virtual column expression

Récemment, deux clients différents en 12.1.0.2 ont rencontré l’erreur ORA-54032 en tentant de renommer une colonne d’une table, alors qu’il n’y avait pas de colonne virtuelle explicite qui utilisait la colonne à renommer.

En version 12.1.0.1 et 12.1.0.2, Oracle considère qu’il s’agit d’un bug (Bug 21070487 – ORA-54032: column to be renamed is used in a virtual column expression (Doc ID 21070487.8)) mais cette erreur se produisait déjà en 11.2.0.4.

Exemple :

SQL> create table t
  2    (
  3    x number,
  4    y number,
  5    z number as (x+y)
  6    );

Table T created.

SQL> select column_name,data_default from user_tab_columns where table_name = 'T';

COLUMN_NAME  DATA_DEFAULT
------------ ------------
X                        
Y                        
Z            "X"+"Y"     

SQL> alter table t rename column x to w;

Error starting at line : 15 in command -
alter table t rename column x to w
Error report -
ORA-54032: column to be renamed is used in a virtual column expression
54032. 0000 -  "column to be renamed is used in a virtual column expression"
*Cause:    Attempted to rename a column that was used in a virtual column
           expression.
*Action:   Drop the virtual column first or change the virtual column
           expression to eliminate dependency on the column to be renamed.

Il est intéressant de noter que le problème ne se pose pas avec les expressions utilisées dans un Function Based Index :

SQL> create table t
  2    (
  3    x number,
  4    y number
  5    );

Table T created.

SQL> create index i on t(x+y);

Index I created.

SQL> select column_name,data_default from user_tab_cols 
  2  where table_name = 'T';

COLUMN_NAME  DATA_DEFAULT
------------ ------------
X                        
Y                        
SYS_NC00003$ "X"+"Y"     

SQL> select column_expression from user_ind_expressions 
  2  where table_name = 'T' and index_name = 'I';

COLUMN_EXPRESSION 
--------------------
"X"+"Y"

SQL> alter table t rename column x to w;

Table T altered.

SQL> select column_name,data_default from user_tab_cols 
  2  where table_name = 'T';

COLUMN_NAME  DATA_DEFAULT
------------ ------------
X                        
Y                        
SYS_NC00003$ "W"+"Y"     

SQL> select column_expression from user_ind_expressions 
  2  where table_name = 'T' and index_name = 'I';

COLUMN_EXPRESSION 
--------------------
"W"+"Y"

La colonne a bien été renommée par Oracle dans l’expression.

En 12.1, la situation est aggravée par le fait que la collecte automatique des statistiques crée des colonnes virtuelles afin d’obtenir des statistiques plus précises lorsqu’il y a une corrélation entre deux colonnes utilisées simultanément dans une clause WHERE. Ces statistiques étendues permettent normalement à l’optimiseur de choisir de meilleurs plans d’exécution, ce qui est a priori une bonne chose.

Mais du coup, les colonnes impliquées dans ces statistiques ne peuvent plus être renommées ; c’est le problème rencontré chez mes deux clients.

Exemple :

SQL> create table t
  2    (
  3    x number,
  4    y number
  5    );

Table T created.

SQL> begin
  2    dbms_stats.gather_table_stats
  3      (
  4      ownname => null,
  5      tabname => 't',
  6      method_opt => 'for columns (x,y) size auto'
  7      );
  8  end;
  9  /

PL/SQL procedure successfully completed.

SQL> select column_name,data_default from user_tab_cols 
  2  where table_name = 'T';

COLUMN_NAME                    DATA_DEFAULT                  
------------------------------ ------------------------------
X                                                            
Y                                                            
SYS_STUYPW88OE302TFVBNC6$MMQXE SYS_OP_COMBINED_HASH("X","Y") 

SQL> select extension_name, extension from user_stat_extensions 
  2  where table_name = 'T';

EXTENSION_NAME                 EXTENSION                     
------------------------------ ------------------------------
SYS_STUYPW88OE302TFVBNC6$MMQXE ("X","Y")                     

SQL> alter table t rename column x to w;

Error starting at line : 52 in command -
alter table t rename column x to w
Error report -
ORA-54032: column to be renamed is used in a virtual column expression
54032. 0000 -  "column to be renamed is used in a virtual column expression"
*Cause:    Attempted to rename a column that was used in a virtual column
           expression.
*Action:   Drop the virtual column first or change the virtual column
           expression to eliminate dependency on the column to be renamed.

Ce problème est corrigé en 12.2, que ce soit pour les colonnes virtuelles créées explicitement dans la table ou implicitement par Oracle lors de la collecte des statistiques. Ce problème est aussi corrigé en 12.1.0.2 par un patch disponible pour différentes plate-formes.

Sinon, il est possible de contourner le bug, en supprimant temporairement la colonne virtuelle explicite ou les statistiques étendues, le temps de renommer la colonne.

Exemple avec une colonne virtuelle explicite :

SQL> create table t
  2    (
  3    x number,
  4    y number,
  5    z number as (x+y)
  6    );

Table T created.

SQL> alter table t rename column x to w;

Error starting at line : 86 in command -
alter table t rename column x to w
Error report -
ORA-54032: column to be renamed is used in a virtual column expression
54032. 0000 -  "column to be renamed is used in a virtual column expression"
*Cause:    Attempted to rename a column that was used in a virtual column
           expression.
*Action:   Drop the virtual column first or change the virtual column
           expression to eliminate dependency on the column to be renamed.
SQL> select column_name,data_default from user_tab_columns where table_name = 'T';

COLUMN_NAME                    DATA_DEFAULT                  
------------------------------ ------------------------------
X                                                            
Y                                                            
Z                              "X"+"Y"                       

SQL> alter table t modify z as (0); -- expression provisoire

Table T altered.

SQL> alter table t rename column x to w; 

Table T altered.

SQL> alter table t modify z as (w+y); -- expression redéfinie avec le nouveau nom

Table T altered.

SQL> select column_name,data_default from user_tab_columns where table_name = 'T';

COLUMN_NAME                    DATA_DEFAULT                  
------------------------------ ------------------------------
W                                                            
Y                                                            
Z                              "W"+"Y"

Exemple avec des statistiques étendues :

SQL> create table t
 2 (
 3 x number,
 4 y number
 5 );

Table T created.

SQL> begin
 2 dbms_stats.gather_table_stats
 3 (
 4 ownname => null,
 5 tabname => 't',
 6 method_opt => 'for columns (x,y) size auto'
 7 );
 8 end;
 9 /

PL/SQL procedure successfully completed.

SQL> alter table t rename column x to w;

Error starting at line : 112 in command -
alter table t rename column x to w
Error report -
ORA-54032: column to be renamed is used in a virtual column expression
54032. 0000 - "column to be renamed is used in a virtual column expression"
*Cause: Attempted to rename a column that was used in a virtual column
 expression.
*Action: Drop the virtual column first or change the virtual column
 expression to eliminate dependency on the column to be renamed.
SQL> select column_name,data_default from user_tab_cols 
 2 where table_name = 'T';

COLUMN_NAME DATA_DEFAULT 
------------------------------ ------------------------------
X 
Y 
SYS_STUYPW88OE302TFVBNC6$MMQXE SYS_OP_COMBINED_HASH("X","Y")

SQL> select extension_name, extension from user_stat_extensions 
 2 where table_name = 'T';

EXTENSION_NAME EXTENSION 
------------------------------ ------------------------------
SYS_STUYPW88OE302TFVBNC6$MMQXE ("X","Y")

SQL> begin
 2 dbms_stats.drop_extended_stats -- suppression des statistiques
 3 (
 4 ownname => null,
 5 tabname => 't',
 6 extension => '(x,y)'
 7 );
 8 end;
 9 /

PL/SQL procedure successfully completed.

SQL> alter table t rename column x to w;

Table T altered.

SQL> begin
 2 dbms_stats.gather_table_stats -- recréation des statistiques
 3 (
 4 ownname => null,
 5 tabname => 't',
 6 method_opt => 'for columns (w,y) size auto'
 7 );
 8 end;
 9 /

PL/SQL procedure successfully completed.

SQL> select column_name,data_default from user_tab_cols 
 2 where table_name = 'T';

COLUMN_NAME DATA_DEFAULT 
------------------------------ ------------------------------
W 
Y 
SYS_STU121KAA_EH6#$T1$TT0VE6RE SYS_OP_COMBINED_HASH("W","Y")

SQL> select extension_name, extension from user_stat_extensions 
 2 where table_name = 'T';

EXTENSION_NAME EXTENSION 
------------------------------ ------------------------------
SYS_STU121KAA_EH6#$T1$TT0VE6RE ("W","Y")

La collecte des statistiques étendues peut être désactivée à l’aide d’un paramètre caché (_optimizer_enable_extended_stats), mais ce serait dommage de se priver d’une fonctionnalité qui peut être bénéfique pour les performances.