Data Transmission Service:Perte de données due à une incohérence de la sensibilité à la casse des jeux de caractères

Symptômes

Les différentes bases de données gèrent la sensibilité à la casse de manière distincte. En cas d'inadéquation entre les bases de données source et de destination sur ce point, il se peut que certaines données soient absentes de la base de destination une fois la migration ou la synchronisation terminée.

Exemple

Cet exemple s'appuie sur une base de données source Oracle et une base de données de destination MySQL pour illustrer comment une divergence de sensibilité à la casse peut entraîner une perte de données.

Les bases de données Oracle et MySQL présentent des comportements par défaut différents concernant la sensibilité à la casse.

• Oracle : Par défaut, Oracle respecte la casse. Il est ainsi possible d'insérer dans une colonne dotée d'une clé primaire ou unique des valeurs qui ne diffèrent que par leur casse, telles que « a » et « A ».

• MySQL : La sensibilité à la casse dépend du classement (collation). En règle générale, un classement se terminant par « _ci » est insensible à la casse, tandis qu'un classement se terminant par « _cs » y est sensible. Avec un classement « _ci », vous ne pouvez pas insérer dans une colonne dotée d'une clé primaire ou unique des valeurs qui ne diffèrent que par leur casse (par exemple « a » et « A »), car elles sont considérées comme identiques.

Scénario de migration : Vous migrez des données d'une base de données source Oracle vers une base de données de destination MySQL à l'aide de DTS. Dans la configuration de la tâche, vous ne sélectionnez pas l'option Schema Migration. Une fois la migration achevée, vous vérifiez les données présentes dans la base de destination.

create table gb.test
(id int primary key, name varchar2(10))

SQL> select * from test;

    ID NAME
------ ---------
     1 a
     2 A
     3 abc
     4 Abc
     5 aBc
     6 abC

6 rows selected.

insert into test values (1,'a');

insert into test values (2,'A');

insert into test values (3,'abc');

insert into test values (4,'Abc');

insert into test values (4,'aBc');

insert into test values (5,'aBc');

insert into test values (6,'abC');

commit;

create table
test.test (auto_id int primary key auto_increment, name varchar(10), unique
key(name))

mysql> select * from test;
+---------+------+
| auto_id | name |
+---------+------+
|       4 | a    |
|       5 | abc  |
+---------+------+
2 rows in set (0,01 sec)

Cause

Les bases de données source et de destination utilisent des jeux de caractères dont la sensibilité à la casse est incohérente.

Résolution

• Examinez la logique de votre application afin de déterminer s'il est nécessaire de stocker des données qui ne diffèrent que par leur casse, comme « abc » et « Abc ». Si cette exigence n'existe pas, imposez une casse uniforme pour vos données, par exemple en convertissant toutes les chaînes en minuscules avant leur écriture dans la base de données.

• Si votre base de données source est sensible à la casse, veillez à configurer la base de destination avec un classement respectant la casse. Par exemple, sous MySQL, choisissez un classement se terminant par _cs.