Nouveautés Oracle Database 12c – partie 1 : améliorations pour l’administration

DIGORA souhaite vous présenter quelques-unes des nouveautés d’Oracle Database 12c. Voici le premier d’une série de billets consacré à ces nouveautés. Lorsqu’une nouveauté implique l’Enterprise Edition ou une option payante, nous le préciserons.

Cette partie 1 concerne essentiellement 10 améliorations pour l’administration des bases Oracle 12c :

1. Colonnes invisibles
2. Index multiples sur les mêmes colonnes
3. Génération de Log sur DDL
4. Nouveaux privilèges pour les sauvegardes
5. Exécution de commandes SQL avec RMAN
6. Récupération de tables avec RMAN
7. Limitations de la taille de la PGA
8. Déplacement en ligne d’un fichier de données actif
9. Migration en ligne d’une partition ou sous-partition de table active
10. Temporary undo

1. COLONNES INVISIBLES

Une colonne peut désormais avoir l’attribut VISIBLE ou INVISIBLE. Les colonnes invisibles ne sont pas retournées par Oracle à moins d’être spécifiées explicitement dans les colonnes mentionnées par le SELECT.

Par suite, l’utilisation générique d’une table (telles que SELECT * FROM table ou un DESCRIBE) ne montreront pas les colonnes invisibles. La notion de colonnes invisibles facilitera la migration d’applications, en imitant un peu la méthode “edition-based redefinition” d’Oracle.
 

2. INDEX MULTIPLES SUR LES MÊMES COLONNES

Plusieurs index peuvent être créés sur le même groupe de colonnes à condition qu’une de leurs caractéristiques soit différente telles que :

• B-tree versus Bitmap
• Différentes stratégies de partitionnement
• Unique versus NonUnique

Le fait de pouvoir créer plusieurs index sur le même jeu de colonnes facilite la migration d’applications de façon transparente et en douceur, sans nécessiter la suppression, suivi de la re-création de l’index avec des attributs différents.
 

3. GÉNÉRATION DE LOG SUR DDL

Jusque là, il fallait mettre en place des triggers pour tracer  les actions DDL. En 12cR1, il est désormais possible de tracer ces actions DDL dans des fichiers Log et XML. Cette fonctionnalité sera très utiles pour savoir quand une commande DROP ou CREATE a été exécutée et par qui. Cette fonctionnalité est activée par le paramètre ENABLE_DDL_LOGGING. Ce paramètre peut être positionné au niveau de la base ou de la session. Le fichier XML contiendra les informations suivantes:

• commandes DDL
• adresses IP
• timestamp

Exemple :

SQL> ALTER SYSTEM|SESSION SET ENABLE_DDL_LOGGING=TRUE;

Les commandes DDL suivantes sont concernées par cette fonctionnalité :

• CREATE|ALTER|DROP|TRUNCATE TABLE
• DROP USER
• CREATE|ALTER|DROP PACKAGE|FUNCTION|VIEW|SYNONYM|SEQUENCE

4. NOUVEAUX PRIVILÈGES POUR LES SAUVEGARDES

Tout comme la version 11gR2 a introduit le privilège SYSASM pour effectuer des opérations avec ASM, de même la version 12cR1 introduit le privilège SYSBACKUP qui donne les droits d’effectuer les sauvegardes avec RMAN.

Vous pouvez par suite créer une utilisateur dans la base et lui donner le privilège SYSBACKUP pour qu’ils puissent effectuer toutes les actions liées aux sauvegardes et restore, sans être obligés de lui donner le privilège SYSDBA.

Exemple :

$ ./rman target “username/password as SYSBACKUP”
 

5. EXÉCUTION DE COMMANDES SQL AVEC RMAN

Oracle 12cR1 vous permet désormais d’exécuter des ordres SQL et PL/SQL sans devoir les préfixer du mot clé SQL.

Exemple :

RMAN> SELECT username,machine FROM v$session; RMAN> ALTER TABLESPACE users ADD DATAFILE SIZE 500m;

6. RÉCUPÉRATION DE TABLES AVEC RMAN

Il existe deux types de sauvegarde de bases Oracle : logiques et physiques. Chaque type de sauvegarde comporte des avantages et des inconvénients. Avec les  versions précédentes, il n’était pas possible de restaurer une table ou une partition  à partir d’une sauvegarde physique existante.

Pour pouvoir restaurer un objet particulier, il fallait utiliser une sauvegarde logique (faite avec Data Pump).

Avec Oracle 12cR1, il est possible de restaurer une table ou une partition particulière jusqu’à un point donné dans le temps ou un SCN précisé à partir de sauvegardes RMAN, dans le cas par exemple d’un DROP ou TRUNCATE intempestif d’une table.

Lorsqu’un restore de table ou partition est lancée avec RMAN, voici les actions effectuées :

• Les Backups Sets nécessaires pour récupérer la table ou la partition sont identifiés
• Une base auxiliaire sera configurée pour être récupérée jusqu’à un point donné dans le temps ou jusqu’à un SCN précisé
• La table ou les partitions seront exportées dans un fichier DMP par Data Pump
• En option,  import la table ou les partitions dans la base source
• Changement de nom éventuel lors de la récupération

Voici un exemple de récupération de table jusqu’à un point donné dans le temps avec RMAN (s’assurer d’avoir une sauvegarde de base disponible) :

RMAN> connect target "username/password as SYSBACKUP";
RMAN> RECOVER TABLE username.tablename UNTIL TIME 'TIMESTAMP…'
	AUXILIARY DESTINATION '/u01/tablerecovery'
	DATAPUMP DESTINATION '/u01/dpump'
	DUMP FILE 'tablename.dmp'
	NOTABLEIMPORT    -- this option avoids importing the 
                         -- table automatically
REMAP TABLE 'username.tablename': 'username.new_table_name';    
                         -- can rename table with this option.

7. LIMITATIONS DE LA TAILLE DE LA PGA

Avant Oracle 12cR1, il fallait utiliser un paramètre caché pour contrôler la taille maximum d’une PGA. Par ailleurs, bien que le paramètre PGA_AGGREGATE_TARGET mentionnait une certaine taille, Oracle pouvait réduire ou agrandir la taille consommée en fonction de la charge de travail sans forcément respecter cette valeur spécifiée.

Avec Oracle 12cR1, il est maintenant possible de fixer une limite réelle sur la PGA tout en activant la gestion automatique de la PGA. Le paramètre PGA_AGGREGATE_LIMIT est donc utile pour empêcher Oracle d’utiliser plus de mémoire que la valeur spécifiée dans ce nouveau paramètre.

SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=2G;

SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=o; -- désactive ce paramètre

Note importante :

Lorsque la limite de mémoire fixée par PGA_AGGREGATE_LIMIT est dépassée, Oracle peut  automatiquement terminer une session ou un process le plus concerné par le manque de mémoire PGA.
 

8. DÉPLACEMENT EN LIGNE D’UN FICHIER DE DONNÉES ACTIF

Un fichier de données peut maintenant être déplacé ONLINE, alors qu’il est ouvert et accédé (en lecture et écriture).

De nombreuses opérations de maintenance deviennent alors plus facile :

• déplacer un fichier de données vers un autre répertoire ou un autre disque
• déplacer un fichier de données vers ASM et vice-versa

Cette nouvelle fonctionnalité permet d’atteindre plus facilement la continuité de service et de respecter les SLA.

Voici quelques exemples d’opérations :

--renommer un fichier
SQL> ALTER DATABASE MOVE DATAFILE '/u01/data/users01.dbf' 
                      TO '/u01/data/users_01.dbf';

--déplacer un fichier de données non-ASM vers ASM
SQL> ALTER DATABASE MOVE DATAFILE '/u01/data/users_01.dbf' 
                      TO '+DATA';

--déplacer un fichier de données ASM vers un emplacement non ASM
SQL> ALTER DATABASE MOVE DATAFILE '/u01/data/users_01.dbf' 
                      TO '+DG_DATA';

--déplacer un fichier de données d'un Disk Group ASM vers un autre 
--Disk Group ASM
SQL> ALTER DATABASE MOVE DATAFILE '+DATA/DBNAME/DATAFILE/users_01.dbf '
                      TO '+DATA_02';

--remplacer le fichier du même nom s'il existe au nouvel emplacement
SQL> ALTER DATABASE MOVE DATAFILE '/u00/data/users_01.dbf' 
                      TO '/u00/data_new/users_01.dbf' REUSE;

--copier le fichier vers une nouvelle destination tout en gardant
--l'ancienne copie dans l'ancien emplacement
SQL> ALTER DATABASE MOVE DATAFILE '/u00/data/users_01.dbf' 
                      TO '/u00/data_new/users_01.dbf' KEEP;

La vue dynamique V$VESSION_LONGOPS permet de suivre l’avancement de la commande. Le fichier alert.log de la base contient également des détails sur l’opération en cours.
 

9. MIGRATION EN LIGNE D’UNE PARTITION OU SOUS-PARTITION DE TABLE ACTIVE

La migration d’une partition ou d’une sous-partition vers un autre tablespace ne nécessite plus désormais de procédures complexes. Tout comme nous pouvions migrer une table non-partitionnée dans les versions précédentes, il est maintenant possible de migrer une partion ou une sous-partition vers un nouveau tablespace, que ce soit ONLINE ou OFFLINE. Lorsque la clause ONLINE est spécifiée, toutes les opérations DML peuvent être exécutées sans indisponibilité de la partition ou sous-partition concernée. A l’inverse, aucune opérations de type DML n’est autorisée si la partition ou sous-partition est déplacée en mode OFFLINE.

Voici quelques exemples d’utilisation :

SQL > ALTER TABLE table_name MOVE PARTITION|SUBPARTITION partition_name TO tablespace tablespace_name; 

SQL> ALTER TABLE table_name  MOVE PARTITION|SUBPARTITION partition_name  
        TO tablespace tablespace_name UPDATE INDEXES ONLINE;

Le premier exemple déplace une partition ou une sous-partition vers un autre tablespace en mode OFFLINE.

Le second exemple déplace une partition ou une sous-partition en mode ONLINE tout en mettant à jour les index locaux et globaux de la table. De plus, les ordres DML peuvent continuer d’être exécutés grâce à l’utilisation de la clause ONLINE.

Notes importantes :

• La clause UPDATE INDEXES évitera que les index locaux/globaux de la table ne deviennent inutilisables
• Les restrictions de table ONLINE s’appliqueront dans ce cas également
• Des mécanismes de LOCK sont activés pour réaliser l’opération; il peut se produire des ralentissements et une génération importante de Redo Logs en fonction de la taille de la partition ou de la partition

         SQL> ALTER SYSTEM SET TEMP_UNDO_ENABLE=TRUE;

Consultation des informations sur le TEMPORARY UNDO

SQL> ALTER SYSTEM|SESSION SET TEMP_UNDO_ENABLED=FALSE;