Purger une base, quelle solution ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

19/10/2011, 15h29
Mohamed.Houri

Citation:

Envoyé par elkamaro

Bonjour et merci pour vos réponses

Cela dit, je butte sur votre dernier conseil a savoir tester les index et dans ce domaine j'ai encore beaucoup de chose a apprendre.

OraFrance, dans les partitionnements que tu as déjà effectués, as-tu eu a redéfinir les index ou a y toucher ? si oui, comment as-tu determiner l'action a entreprendre ?

pour ma part, je pensais tout simplement redefinir les tables avec des partitions et y remettre les index comme il etait au depart sans y toucher, je pensais que le partitionnement n'avait aucune incidence sur les indexes

As-tu eu d'autres soucis/contraintes/imprévus qui se seraient révéler lors de tes opérations de partitionnements.

Je te demande tout cela afin que je sois orienté sur le maximum de tests et de possibilités a entreprendre pour que ma procédure de redéfinition soit en béton.

Je vous remercie

C'est difficile de parler sans cas concret. Mais je peux vous dire d'ores et déjà de faire attention à ne pas créer un index locallement partitioné qui ne contiendra pas la clé de partitionnement. Surtout lorsque vous avez un grand nombre de partitions.

De toute façons lorsque cet index est unique et que vous n'y mettez pas la clé de partitionnement il sera rejeté par Oracle lors de sa création comme je l'ai précisé dans mes interventions précedentes.

Je suppose que pour vous, tous les indexe B-tree seront transformés en indexe B-tree. Vu vos connaissances actuelles des indexes partitionnées, c'est une bonne idée.
20/10/2011, 10h24
elkamaro

Citation:

Envoyé par Dajon

Je pense que cette différence de comportement doit venir de la version d'Oracle. Je suis en

Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options

Bonjour Dajon,

effectivement cela change tout que tu sois en 11g
d'aprés mes recherches, redefinir une table avec des colonnes not null :
- ne fonctionne pas en 10g (ma version), on est obligé de faire des register de ces contraintes (systeme) sinon ca plante avec une erreur ORA-12091
- a partir de la 11g (je ne sais plus quel version exacte), un patch est disponible pour remedier a cela
- à partir d'Oracle 12, cette contrainte sera native
20/10/2011, 10h27
elkamaro

j'ai l'impression que des messages ont disparu dans ce poste :?

Notament celui de Mohamed d'aujourd'hui ??
25/10/2011, 11h28
ccaye

Bonjour,

Désolé j'arrive un peu après la bataille. J'ai déjà eu à faire ce genre de purge.
En effet, je confirme qu'avec une table partitionnée, c'est bcp plus facile.

Et je suis d'accord avec Mohamed sur le gros risque d'en créer après-coup. Il faut identifier tous les appels à cette table pour vérifier que les requêtes utilise soit la clé primaire, soit la clé de partition. Sinon je pense que ton client risque de faire appel à toi assez rapidement ...

Autrement, ce que j'avais fait pour purger un gros volume de données sur des tables :
- Création d'une table temporaire qui stockent les ID de clé primaire des enregistrements à supprimer,
- Désactivation des contraintes d'intégrité,
- Code PL avec un curseur qui boucle sur la table temporaire pour supprimer les enregistrements dans les tables concernées (ne pas oublier les tables ayant des contraintes).
- Commit dans la boucle tous les 50 ou 100 000 enreg
- Réactivation des contraintes.

Puis dans un second temps, les tables avaient été réorganisées, pour toutes les raisons déjà évoquées précédemment dans ce post.

Donc je supprimais mes enregistrements un par un. Cela peut paraître peu performant, mais comme je désactivais les contraintes et que je sélectionnais sur la clé primaire, le temps de réponse était bien meilleur que pour des suppressions "ensemblistes".

Par contre il faut faire TRES attention avec ce genre de script, sous peine de ne pas pouvoir réactiver les contraintes après coup ...
25/10/2011, 13h28
islamov2000
Citation:
Envoyé par boussafi

j'ai tombé une fois sur le meme probleme.
pour cela;j'ai

augmenté le nombre le rollback segment(undo pour Oracle >=9i)
déactivé les containtes apres une étude
déactivé le trigger apres une étude
re-dimentionné les tablespaces apres défragmentation
réintialisé le tablespace TEMP

pour aller vite sur une base de données à haute disponibilité.
as tu pris en consideration mon message:oops:
25/10/2011, 14h54
ccaye

Citation:

Envoyé par boussafi

as tu pris en consideration mon message:oops:

hum... oui en effet ça ressemble :oops:
Mais j'ai qd même proposé mon curseur sur la clé et parlé de la table temporaire !

Citation:

Envoyé par ccaye

Donc je supprimais mes enregistrements un par un. Cela peut paraître peu performant, mais comme je désactivais les contraintes et que je sélectionnais sur la clé primaire, le temps de réponse était bien meilleur que pour des suppressions "ensemblistes".

Ça me paraît fallacieux comme argument, ou au moins à fortement nuancer.

La suppression ensembliste profitera des mêmes bénéfices de désactivation des contraintes, et la suppression via la clef primaire si elle nécessite un premier select je ne vois pas pourquoi elle serait beaucoup plus rapide.

Démonstration avec un test simple, une table d'un million de lignes :

Code:

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
create table t1
(
    col1    number(10) not null,
    col2    number(10) not null,
    constraint pk_t1
      primary key (col1)
);
 
insert /*+ APPEND */ into t1 (col1, col2)
 select level, level
   from dual
connect by level <= 1e6;
 
commit;
 
begin
    dbms_stats.gather_table_stats
    ( ownname          => user
    , tabname          => 'T1'
    , estimate_percent => 100
    , cascade          => true
    , degree           => 4
    );
end;
/
 
create table t1_tmp (col1 number(10));

Je vais faire trois simulations, une où on supprime 1% de la table, puis 15%, puis 50%.
J'utilise un modulo sur la seconde colonne comme critère de choix.

On compare votre méthode et le delete ensembliste de base :

Code:

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
declare
    v$_compteur   pls_integer default 0;
    v$_time       pls_integer;
 
begin
 
    dbms_output.put_line('Scénario  1%');
    v$_time := dbms_utility.get_time();
 
    execute immediate 'truncate table t1_tmp';
    insert into t1_tmp (col1) select col1 from t1 where mod(col2, 100) = 0;
 
    for c in (select col1 from t1_tmp)
    loop
        delete from t1 where t1.col1 = c.col1;
        v$_compteur := v$_compteur +1;
        if v$_compteur = 50000 then
           -- commit;
           v$_compteur := 0;
        end if;
    end loop;
 
    dbms_output.put_line('  - Méthode TMP + PL/SQL : ' || to_char(dbms_utility.get_time() -  v$_time));
    rollback;
 
    v$_time := dbms_utility.get_time();
 
    delete from t1 where mod(col2, 100) = 0;
 
    dbms_output.put_line('  - Méthode ensembliste  : ' || to_char(dbms_utility.get_time() -  v$_time));
    rollback;
 
    dbms_output.put_line('Scénario 15%');
    v$_time := dbms_utility.get_time();
 
    execute immediate 'truncate table t1_tmp';
    insert into t1_tmp (col1) select col1 from t1 where mod(col2, 7) = 0;
 
    for c in (select col1 from t1_tmp)
    loop
        delete from t1 where t1.col1 = c.col1;
        v$_compteur := v$_compteur +1;
        if v$_compteur = 50000 then
           -- commit;
           v$_compteur := 0;
        end if;
    end loop;
 
    dbms_output.put_line('  - Méthode TMP + PL/SQL : ' || to_char(dbms_utility.get_time() -  v$_time));
    rollback;
 
    v$_time := dbms_utility.get_time();
 
    delete from t1 where mod(col2, 7) = 0;
 
    dbms_output.put_line('  - Méthode ensembliste  : ' || to_char(dbms_utility.get_time() -  v$_time));
    rollback;
 
    dbms_output.put_line('Scénario 50%');
    v$_time := dbms_utility.get_time();
 
    execute immediate 'truncate table t1_tmp';
    insert into t1_tmp (col1) select col1 from t1 where mod(col2, 2) = 0;
 
    for c in (select col1 from t1_tmp)
    loop
        delete from t1 where t1.col1 = c.col1;
        v$_compteur := v$_compteur +1;
        if v$_compteur = 50000 then
           -- commit;
           v$_compteur := 0;
        end if;
    end loop;
 
    dbms_output.put_line('  - Méthode TMP + PL/SQL : ' || to_char(dbms_utility.get_time() -  v$_time));
    rollback;
 
    v$_time := dbms_utility.get_time();
 
    delete from t1 where mod(col2, 2) = 0;
 
    dbms_output.put_line('  - Méthode ensembliste  : ' || to_char(dbms_utility.get_time() -  v$_time));
    rollback;
 
end;
/

Résultat :

Scénario  1%
  - Méthode TMP + PL/SQL :   66
  - Méthode ensembliste  :   38

Scénario 15%
  - Méthode TMP + PL/SQL :  561
  - Méthode ensembliste  :  256

Scénario 50%
  - Méthode TMP + PL/SQL : 1889
  - Méthode ensembliste  :  777

Voir 40 message(s) de cette discussion en une page