Discussion :

[bobunny]

Bonjour,

je dois récupérer les données d'une base sous 8.0.5 pour les intégrer dans une base 9i.

Pour tester l'intégrité des données, je voulais savoir savoir s'il existait, ou si quelqu'un a déjà mis en place un type de checksum sur une table?

En, une manière basique de tester l'intégrité d'une table serait de faire un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select count(*)

et de comparer le résultat sur les 2 bases.

Mais je me demandais s'il était possible de faire quelque chose d'un peu plus évolué. C'est pour ça que je pensais à un sorte de checksum. Je ne sais pas si c'est un peu farfelu comme idée, mais je n'en ai pas d'autre

Si quelqu'un avait quelque chose à me proposer, ça serait super cool.

Merci d'avance

[lalystar]

Oracle utilise deux paramètres pour les checksums
- DB_BLOCK_CHECKSUM = true/false : si true calcule une checksum lors de l'écriture d'un bloc sur le disque. La checksum permet de vérifier que ce qui a été écrit dans le bloc est bien ce qu'on lit actuellement.
- DB_BLOCK_CHECKING = true/false : si false fait une vérification de cohérence des blocs uniquement pour le tablespace SYSTEM sinon pour tous les tablespaces.

<edit>Par contre, ca n'est pas possible de faire une requête qui retournerait tous les objets qui posent un problème. Je suppose qu'Oracle t'envoies un message d'erreur élégant quand il détecte une incohérence...
</edit>

Laly.

[rouardg]

Bonjour,

Je ne suis pas spécialiste, mais je voudrais dire 2 choses :

1 ) faire un select count (*) n'est pas une bonne chose, car l'optimiseur peut choisir de faire un Fast Full Scan Index. En clair, pour donner le nombre d'occurrences de la table, il ne va pas lire tous les blocs de la table (et donc détecter les erreurs), mais lire tous les blocs de l'index (ce qui détecterait les blocs corrompus, mais de l'index),

2 ) il existe un utilitaire DBVERIFY qui permet justement de vérifier l'intégrité des blocs de données. Cet utilitaire (dbv.exe) marche aussi bien sur les database files de la base online, que sur les backups.

[bobunny]

En fait je pense que je me suis peut être exprimé.

Ou bien c'est moi qui ne comprend pas tout. En fait vous préconisez de tester l'intégrité des données en testant l'intégrité des blocs.

Par exemple si j'ai une table T_toto sur ma base 8.0.5. Je l'exporte vers une base 9i dont la gestion des tablespace est différente, donc la gestion des blocs aussi.

Sur ma base 8.0.5, je teste ma table en faisant le select count(*) qui je le conviens n'est peut être pas top. Je trouve 1 million de lignes.

Sur ma base 9i, je fais la même chose et je trouve aussi 1 millions de lignes.

A priori, je peux me dire que j'ai les mêmes sur ma base 8.0.5 et ma base 9i.

En fait je voulais juste savoir si on pouvait tester le contenu de la table par un algo ou une fonction quelconque, et ainsi comparer le résultat sur les deux bases. En gros y a t il une alternative à se contenter de compter le nombre de lignes de la table pour chaque base pour se dire qu'on a bien les mêmes infos??

Je parlais de checksum car j'ai vu cette fonction sur Unix, mais c'était juste à titre d'exemple.

[lalystar]

Si tu veux comparer deux tables, le plus simple est de regarder les différences symétriques :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
-- lignes dans T1 mais pas dans T2
select *
from   T1
minus
select * 
from   T2
/
 
-- lignes dans T2 mais pas dans T1
select *
from   T2
minus
select * 
from   T1

Laly.

[SheikYerbouti]

Bonjour,

Je ne suis pas spécialiste, mais je voudrais dire 2 choses :

1 ) faire un select count (*) n'est pas une bonne chose, car l'optimiseur peut choisir de faire un Fast Full Scan Index. En clair, pour donner le nombre d'occurrences de la table, il ne va pas lire tous les blocs de la table (et donc détecter les erreurs), mais lire tous les blocs de l'index (ce qui détecterait les blocs corrompus, mais de l'index),

je ne pense pas qu'un SELECT COUNT(*) utilise un index d'une quelconque manière
d'une part parce que l'optimisateur ne saurait pas lequel choisir et d'autre part parce que, par définition, un index ne stocke pas les valeurs NULL.

[lalystar]

je ne pense pas qu'un SELECT COUNT(*) utilise un index d'une quelconque manière
d'une part parce que l'optimisateur ne saurait pas lequel choisir et d'autre part parce que, par définition, un index ne stocke pas les valeurs NULL.

Si tu as une colonne NOT NULL alors Oracle peut utiliser un index sur cette colonne dans le cadre d'un count(*) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
SQL> select count(*) from EMP_1;
 
  COUNT(*)
----------
        14
 
 
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=21954 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'EMP_1' (TABLE) (Cost=21954 Card=1000000)
 
SQL> alter table EMP_1 modify empno not null;
 
Table altered.
 
SQL> select count(*) from EMP_1;
 
  COUNT(*)
----------
        14
 
 
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=1 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     INDEX (FULL SCAN) OF 'IDX_EMPNO' (INDEX) (Cost=1 Card=1000000)

Par contre, ici Oracle fait un Index - Full Scan avant de compter les résultats. Je pensais qu'il aurait fait un Index - FFS. L'index est non unique mais j'ai le même résultat avec un index unique.

Laly.

[bobunny]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
-- lignes dans T1 mais pas dans T2
select *
from   T1
minus
select *
from   T2
/
 
-- lignes dans T2 mais pas dans T1
select *
from   T2
minus
select *
from   T1

Ca a l'air pas mal ça, mais le pb, c'est que les 2 tables sont sur 2 bases différentes. Si je ne me trompe pas, c'est imossible :

[lalystar]

Non, il suffit de créer un database link entre les deux bases. Cherches sur le forum tu devrais trouver plus d'infos.


Laly.

[bobunny]

OK merci, je vais regarder. Je pense que je vais retenir cette solution.

Merci de vos réponses