Contexte

Lors d'un changement de charset depuis un charset monobyte (comme le MSWIN1252 ou le WE8ISO9959P1) vers un charset multi-bytes (comme le AL32UTF8 ou l'UTF8) un phénomène d'agrandissement des tailles en octets des chaines de caractères converties vont probablement entrainer des rejets si une opération classique d'export/import est jouée. Par exemple lorsqu'une table est créée, la taille d'un champs caractère est fixée définitivement. Un VARCHAR(50) dans un CS mono-byte aura une taille de 50 octets (bytes). Si pour une ligne donnée, les 50 octets sont occupées totallement par une chaine de caractères dont au moins un des caractères n'est pas dans les caractères ANSI de base (€, §,@,...) ces caractères auront une taille de 2 octets (voir plus) dans un CS comme l'UTF8.

l'export (datapump naturellement !) depuis une base source (en MS1252 par exemple) va générer un fichier dump, ce fichier s'il est pris tel-quel et qu'un import est joué sur une base cible en UTF8, il sera interprété par l'import en créant les tables avec des colonnes dont la taille en octet sera telle que défini dans la base source (VARCHAR2(50) BYTES par exemple) et ceci même si on positionne un NLS_LENGTH_SEMANTICS à CHAR en cible. L'import créra donc des tables ayant des colonnes dont la tailles max sera insuffisantes pour stocker tous les caractères des chaines sources converties dans le CS cible. Les lignes seront rejetées.

Vous pouvez avoir une idée des "dégats" en lancer l'utilitaire CSSCAN disponible dans le répertoire $ORACLE_HOME/rdbms/admin/scripts

Voici donc comment faire pour s'en sortir en intervenant sur le script de création des tables pour forcer ces creates à incorporer des VARCHAR2(x) CHAR en définition de colonne.

L’objectif de cet article est de décrire précisément la procédure à exécuter pour effectuer la bascule du jeu de caractère MSWIN1252 (ou WE88859Px) en UTF8 sur une nouvelle base de données

Pré-requis :

La base de données de destination est disponible et le jeu de caractères est déjà en UTF8.

Les schémas sont supprimés sur la base de données de destination.

Toutes les manipulations sont effectuées à partir d’un export DATAPUMP « FULL » de la base de données source.

Dans cet article nous allons voir comment créer un catalogue pour l'utilitaire RMAN. Ce catalogue va héberger les références des fichiers sauvegardés, leurs significations et dates. Ces informations seront également stockées dans le control file de la base de données mais seront très utiles en cas de crash complet ou de corruption de ce control file, il est donc prudent et recommandé d'héberger ce catalogue sur une autre machine (si les bases sont sur des VM, il faudra trouver une autre VM allouée sur un host physique différent).

Les sauvegardes L0 et L1 sont respectivement des sauvegardes complètes et incrémentales, toutes les deux sont des sauvegardes à chaud (base ouverte) elles ne sont possibles que si la base de données est en mode ARCHIVELOG. L'unique sauvegarde à chaud possible en mode NOARCHIVELOG est l'export (datapump de préférence).

Allons-y !

Préparation du Catalogue RMAN

Il faut soit créer une base spécifique pour héberger le catalogue RMAN soit en utiliser une déja existante et créer un utilisateur/schéma pour abriter les objets du catalogue. Cette base devra être sauvegardée autrement que via RMAN (via un export datapump par exemple)

SQL> connect SYSTEM @RMAN
Enter password:
Connected.
SQL> CREATE TABLESPACE RMAN DATAFILE 'RMAN.dbf' SIZE 128M AUTOEXTEND ON NEXT 16M MAXSIZE 1024M LOGGING EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO FLASHBACK ON;

Tablespace created.

SQL> CREATE USER RMAN IDENTIFIED BY RMAN
  TEMPORARY TABLESPACE TEMP
  DEFAULT TABLESPACE RMAN
  QUOTA UNLIMITED ON RMAN;

User created.

SQL> GRANT RECOVERY_CATALOG_OWNER TO RMAN;

Grant succeeded. 

On va ensuite initialiser le catalogue en lançant l’utilitaire RMAN en ligne de commande :

La console oracle OEM fonctionne (emctl status dbconsole sur le serveur de base de données nous dit running) mais impossible d'avoir la mire de login depuis un client avec IE. Internet Explorer semble bloquer le site de la console malgré l'avoir passé en site de confiance et malgré avoir désactivé la vérification du certificat serveur rien n'y fait ?

Sur votre poste client windows, ouvrez une fenêtre de commande en tant qu'administrateur et essayez ceci :

certutil -setreg chain\EnableWeakSignatureFlags 8 
 

Cela permet d'accépter les site dont les certificats ne répondent pas aux critères de sécurité windows et la console oracle 11g en fait partie. Microsoft a publié un avis de sécurité indiquant que l'utilisation des certificats RSA dont la longueur de clés est inférieure à 1024 bits sera bloquée : http://support.microsoft.com/kb/2661254/fr

source: Oracle® Database - SQL Language Reference - 11g Release 1 (11.1) - B28286-05
source: Oracle® Database - Administrator's Guide - 11g Release 1 (11.1) - B28310-04

Lorsque que l’on utilise une instruction DML (insert/update/delete/merge) via une sous requête, plutôt que d’avoir une erreur puis un rollback il est possible de gérer certaines erreurs via une table de journalisation d’erreur :

• En fixant la limite du nombre de lignes en erreur ou en positionnant cette limite à UNLIMITED
• En utilisant la fonctionnalité de logging des erreurs DML.

Voyons comment utiliser cette fonctionnalité :

Les erreurs gérées :

• Valeurs trop large pour la colonne
• Violations de contrainte (NOT NULL, unique, referential, et check constraints)
• Erreurs levées pendant l’exécution d’un trigger
• Erreurs résultant d’une conversion de type entre la colonne cible et la sous-requête
• Erreur de mapping de Partition
• Certaines erreurs sur des opérations de MERGE (ORA-30926: Unable to get a stable set of rows for MERGE operation.)

Les erreurs non gérées :

Certaines erreurs ne sont pas enregistrées par la gestion intégrée des erreurs et entrainent l’arrêt de l’opération de DML et son rollback

• Violation de contraintes différées.
• Une opération d’INSERT, d’UPDATE ou de MERGE en direct-path qui lève une violation de contrainte unique ou d’index unique.
• Il n’est pas possible de tracer les erreurs dans un table de trace pour les colonnes de type LONG, LOB, ou object . Toutefois, la table en cible de l’opération DML peut contenir ce type de colonne :

   

  • Si vous créez ou modifiez la table de journalisation d'erreur correspondant afin qu'elle contienne une colonne d'un type non pris en charge, et si le nom de la colonne correspond à une colonne non pris en charge dans la table cible de l'opération DML, l'instruction DML échoue au moment du parse.
  • Si la table de journalisation d'erreur ne contient pas tous les types de colonnes non pris en charge, alors toutes les erreurs DML sont enregistrés jusqu'à ce que la limite d'erreurs soit atteinte.
  • Pour les lignes sur lesquelles des erreurs se produisent, les valeurs correspondantes au colonnes dans la table de journalisation des erreurs sont enregistrées avec les informations de commande.