IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration Oracle Discussion :

Purger une base, quelle solution ?


Sujet :

Administration Oracle

  1. #41
    Membre expérimenté

    Homme Profil pro
    Inscrit en
    Mars 2010
    Messages
    536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 536
    Points : 1 359
    Points
    1 359
    Par défaut
    Citation Envoyé par elkamaro Voir le message
    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.
    Bien Respectueusement
    www.hourim.wordpress.com

    "Ce qui se conçoit bien s'énonce clairement"

  2. #42
    Membre du Club
    Profil pro
    Inscrit en
    Avril 2003
    Messages
    92
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Avril 2003
    Messages : 92
    Points : 48
    Points
    48
    Par défaut
    Citation Envoyé par Dajon Voir le message

    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
    It's me !!

  3. #43
    Membre du Club
    Profil pro
    Inscrit en
    Avril 2003
    Messages
    92
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Avril 2003
    Messages : 92
    Points : 48
    Points
    48
    Par défaut
    j'ai l'impression que des messages ont disparu dans ce poste

    Notament celui de Mohamed d'aujourd'hui ??
    It's me !!

  4. #44
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    31
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 31
    Points : 26
    Points
    26
    Par défaut
    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 ...

  5. #45
    Membre expérimenté
    Avatar de islamov2000
    Homme Profil pro
    Ingénieur d'études & developpement en informatique
    Inscrit en
    Septembre 2007
    Messages
    814
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études & developpement en informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2007
    Messages : 814
    Points : 1 717
    Points
    1 717
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par boussafi Voir le message
    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
    d'avoir Pensé à voter positivement pour ceux qui vous ont aidés et surtout à mettre si le cas.
    ça encourage.

  6. #46
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    31
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 31
    Points : 26
    Points
    26
    Par défaut
    Citation Envoyé par boussafi Voir le message
    as tu pris en consideration mon message
    hum... oui en effet ça ressemble
    Mais j'ai qd même proposé mon curseur sur la clé et parlé de la table temporaire !

  7. #47
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 452
    Points : 17 820
    Points
    17 820
    Par défaut
    Citation Envoyé par ccaye Voir le message
    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 : 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
    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 : 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
    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

Discussions similaires

  1. Réponses: 15
    Dernier message: 08/08/2012, 17h35
  2. Page web infectée par une iframe quelle solution?
    Par papisdoums dans le forum Sécurité
    Réponses: 12
    Dernier message: 24/04/2009, 15h20
  3. Réponses: 7
    Dernier message: 18/02/2008, 14h33
  4. Quelles solutions pour créer une Bases de données géographiques ?
    Par subzero82 dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 25/11/2007, 21h45
  5. Réponses: 4
    Dernier message: 09/10/2007, 16h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo