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

Oracle Discussion :

Tablespace SYSTEM grandit très vite


Sujet :

Oracle

  1. #1
    Membre du Club
    Inscrit en
    Février 2003
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : Février 2003
    Messages : 80
    Points : 47
    Points
    47
    Par défaut Tablespace SYSTEM grandit très vite
    Bonjour,
    J'ai un soucis avec le tablespace SYSTEM. Malgré un flux constant et un archivage, la partie "donnée" de ma BD ne grandit pas mais l'ensemble oui.
    Le coupable le tablespace SYSTEM

    Ma base Oracle est est un v11.2 qui fonctionne sur du Solaris.
    Dans OEM on voit pour mon tablespace SYSTEM:
    30.08 : 2278 MB
    31.08 : 2298 MB
    02.09 : 2308 MB
    chaque jour on gagne entre 10 et 20 MB.


    select segment_name, segment_type, tablespace_name, (bytes/1048576) "size (MB)" from dba_segments
    where tablespace_name = 'SYSTEM'
    order by bytes desc
    La requête nous montre qu'il s'agit de C_OBJ# les autres ne bougent pas.
    C_OBJ# passe de 559MB à 567MB puis à 575MB

    select table_name, tablespace_name, num_rows, blocks from dba_tables
    where table_name in ( 'TAB$', 'CLU$', 'ICOL$', 'IND$', 'COL$' )
    order by num_rows desc
    Autre donnée : il s'agit bien de IND$ et COL$ qui changent énormément.
    +700 blocs (sur 70,000 blocks soit +1%) en 3 jours.

    Une idée du pourquoi ? est ce vraiment normal car les données de ma base de données restent vraiment au même niveau (ce qui rentre est compensé par l'archivage ) ?

  2. #2
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    C_OBJ# est un cluster qui contient parmi autres les tables col$ et ind$ du méta dictionnaire.

  3. #3
    Membre du Club
    Inscrit en
    Février 2003
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : Février 2003
    Messages : 80
    Points : 47
    Points
    47
    Par défaut
    oui et une idée pourquoi mon dictionnaire grandirait à ce point ?
    Y a t'il un manière d'y remédier ?

    on a grandit en un mois de près de 1/2 Go !

  4. #4
    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 Daeron Voir le message
    oui et une idée pourquoi mon dictionnaire grandirait à ce point ?
    Y a t'il un manière d'y remédier ?

    on a grandit en un mois de près de 1/2 Go !
    Que donne la requête suivante:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    select owner,segment_name,segment_type  
      ,bytes/(1024*1024) size_m  
      from dba_segments  
      where tablespace_name = 'SYSTEM' 
     and    bytes/(1024*1024) > 1  
     order by size_m desc
    Cela peut être du au calcul des histogrammes, à l'AUDIT, etc..
    Bien Respectueusement
    www.hourim.wordpress.com

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

  5. #5
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    Citation Envoyé par Mohamed.Houri Voir le message
    Que donne la requête suivante:
    ...Cela peut être du au calcul des histogrammes, à l'AUDIT, etc..
    Non ce n’est ni l’audit ni les histogrammes dans ce cas (des autres objets sortirais leurs têtes si c'était le cas).
    Je pense que Col$ sont tous les colonnes et Ind$ tous les colonnes qui composent les indexes. Vous devez investiguer.

  6. #6
    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 mnitu Voir le message
    Non ce n’est ni l’audit ni les histogrammes dans ce cas (des autres objets sortirais leurs têtes si c'était le cas).
    Je pense que Col$ sont tous les colonnes et Ind$ tous les colonnes qui composent les indexes. Vous devez investiguer.
    Conseillez le vivement de nous montrer le contenu du select que j'ai proposé plus haut.En suite d'affiner sa recherche avec le select suivant
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    select owner,table_name  
     from dba_tables  
    where cluster_name = 'C_OBJ#...?'
    On aura une vue beaucoup plus claire
    Bien Respectueusement
    www.hourim.wordpress.com

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

  7. #7
    Membre du Club
    Inscrit en
    Février 2003
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : Février 2003
    Messages : 80
    Points : 47
    Points
    47
    Par défaut
    Voici le résultat des requêtes :

    SELECT segment_name as Seg_Name , segment_type as Seg_Type, tablespace_name as TS_Name, (bytes/1048576) "Size_MB" FROM dba_segments
    WHERE tablespace_name = 'SYSTEM'
    ORDER BY bytes desc

    Seg_Name Seg_Type TS_Name Size_Mb
    C_OBJ# CLUSTER SYSTEM 575
    IDL_UB1$ TABLE SYSTEM 248
    C_COBJ# CLUSTER SYSTEM 216
    I_OBJ5 INDEX SYSTEM 112
    I_OBJ2 INDEX SYSTEM 91
    OBJ$ TABLE SYSTEM 88
    SOURCE$ TABLE SYSTEM 72

    select table_name, tablespace_name, num_rows, blocks from dba_tables
    where table_name in ( 'TAB$', 'CLU$', 'ICOL$', 'IND$', 'COL$' )
    order by num_rows desc
    Jour 0
    SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME size (MB)
    C_OBJ# CLUSTER SYSTEM 559
    IDL_UB1$ TABLE SYSTEM 248
    C_COBJ# CLUSTER SYSTEM 216

    Jour +4
    SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME size (MB)
    C_OBJ# CLUSTER SYSTEM 567
    IDL_UB1$ TABLE SYSTEM 248
    C_COBJ# CLUSTER SYSTEM 216

    Jour +6
    SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME size (MB)
    C_OBJ# CLUSTER SYSTEM 575
    IDL_UB1$ TABLE SYSTEM 248
    C_COBJ# CLUSTER SYSTEM 216

  8. #8
    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 Daeron Voir le message
    Voici le résultat des requêtes :




    Seg_Name Seg_Type TS_Name Size_Mb
    C_OBJ# CLUSTER SYSTEM 575
    IDL_UB1$ TABLE SYSTEM 248
    C_COBJ# CLUSTER SYSTEM 216
    I_OBJ5 INDEX SYSTEM 112
    I_OBJ2 INDEX SYSTEM 91
    OBJ$ TABLE SYSTEM 88
    SOURCE$ TABLE SYSTEM 72



    Jour 0
    SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME size (MB)
    C_OBJ# CLUSTER SYSTEM 559
    IDL_UB1$ TABLE SYSTEM 248
    C_COBJ# CLUSTER SYSTEM 216

    Jour +4
    SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME size (MB)
    C_OBJ# CLUSTER SYSTEM 567
    IDL_UB1$ TABLE SYSTEM 248
    C_COBJ# CLUSTER SYSTEM 216

    Jour +6
    SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME size (MB)
    C_OBJ# CLUSTER SYSTEM 575
    IDL_UB1$ TABLE SYSTEM 248
    C_COBJ# CLUSTER SYSTEM 216
    Et la requête suivante?
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    SELECT owner,table_name  
     FROM dba_tables  
    WHERE cluster_name = 'C_OBJ#';
    Bien Respectueusement
    www.hourim.wordpress.com

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

  9. #9
    Membre du Club
    Inscrit en
    Février 2003
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : Février 2003
    Messages : 80
    Points : 47
    Points
    47
    Par défaut
    SELECT owner,table_name
    FROM dba_tables
    WHERE cluster_name = 'C_OBJ#';
    => ils appartiennent tous à SYS

  10. #10
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    Le cluster C_OBJ# grandi parce que les tables clustérisées grandissent. Quelles sont ces tables ? J'avais compris que c'est le IND$ et COL$ est ce bien ça ?

    @Mohamed
    Un peu de recherche sur google et vous allez trouver que l'audit c'est AUD$ et que les histogrammes sont dans le cluster C_OBJ#_INTCOL#.
    De plus je pense que le contenu du cluster en question C_OBJ# est invariant par rapport a une version et peut être bien une édition donnée d'Oracle.

  11. #11
    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 mnitu Voir le message
    Le cluster C_OBJ# grandi parce que les tables clustérisées grandissent. Quelles sont ces tables ? J'avais compris que c'est le IND$ et COL$ est ce bien ça ?

    @Mohammed
    Un peu de recherche sur google et vous allez trouver que l'audit c'est AUD$ et que les histogrammes sont dans le cluster C_OBJ#_INTCOL#.
    De plus je pense que le contenu du cluster en question C_OBJ# est invariant par rapport a une version et peut être bien une édition donnée d'Oracle.
    @marius,

    Oui vous avez raison pour AUD$ et C_OBJ#_INTCOL; je l'ai déjà lu plusieurs fois. Ceci dit rien n'empêche de conseiller à Daeron la méthode à suivre (les deux ou trois selects). Ainsi, au lieu de lui dire Quelles sont ces tables vous auriez tout aussi bien fait de lui dire que vaut le select suivant
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    SELECT owner,table_name  
     FROM dba_tables  
    WHERE cluster_name = 'C_OBJ#';
    Bien Respectueusement
    www.hourim.wordpress.com

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

  12. #12
    Membre du Club
    Inscrit en
    Février 2003
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : Février 2003
    Messages : 80
    Points : 47
    Points
    47
    Par défaut
    Je n'ai pas très bien saisi. Mes tables sont en mode cluster et il y en a bien qui grandissent : c'est bien cela ?
    Comment savoir laquelle exactement un select count(*) sur mes plus grandes tables suffirait ?

  13. #13
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    @Mohamed,

    J’aurais le certainement fais si vous n’aurez pas déjà donné la requête juste avant. Polémiquer sur ça c’est juste parce qu’on n’a rien à se mettre sous les dents.

    Allez bonne soirée
    Marius

  14. #14
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Bonjour Daeron,

    Citation Envoyé par Daeron Voir le message
    Je n'ai pas très bien saisi. Mes tables sont en mode cluster et il y en a bien qui grandissent : c'est bien cela ?
    Non. Ici c'est les tables du dictionnaire qui sont en cluster. Ce ne sont pas les données des tables qui grossissent, mais les meta-données.

    On pourrait supposer qu'il y a beaucoup de DDL, beaucoup de création de tables. Mais 10 MB de meta-données tous les jours, c'est énorme.

    La première chose que je ferais, c'est de voir s'il y a beaucoup de nouveaux objets créés dans la base, et lesquels: Voici comment voir les objets créés sur les dernières 24 heures:

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    select owner,object_name,object_type,created from dba_objects where created > sysdate-1 order by created desc;

    Sinon, voici comment voir quels sont les objets qui prennent le plus de place dans le dictionnaire, dans ce fameux cluster C_OBJ$:


    Code SQL : 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
    select num_blocks,owner,object_name,object_type,object_id,created from (
      select * from (
        select count(distinct relative_fno||'.'||block_id) num_blocks,object_id from (
                    select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.ICOL$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.IND$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.COL$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.CLU$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.TAB$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.LOB$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.COLTYPE$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.SUBCOLTYPE$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.NTAB$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.REFCON$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.OPQTYPE$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.ICOLDEP$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.VIEWTRCOL$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.LIBRARY$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.ASSEMBLY$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.ATTRCOL$
          union all select obj# object_id,dbms_rowid.rowid_relative_fno(rowid) relative_fno,dbms_rowid.rowid_block_number(rowid) block_id  from sys.type_misc$
        ) group by object_id having count(distinct relative_fno||'.'||block_id) > 2
        order by num_blocks desc
      ) where rownum <100
    ) join dba_objects using(object_id) order by num_blocks desc,object_id
    /

    L'idée: on regarde toutes les tables qui stockent leurs lignes dans ce cluster, avec le nombre de blocks qui contiennent au moins une de leurs lignes, et on affiche les 100 plus gros. S'il y a des objets dont les meta-données couvrent plus de quelques blocks, alors il faudra investiguer...

    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  15. #15
    Membre du Club
    Inscrit en
    Février 2003
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : Février 2003
    Messages : 80
    Points : 47
    Points
    47
    Par défaut
    @Pachot:
    Effectivement ! j'ai trouvé un grand début de piste :
    L'agrandissement a lieu tous les jours à 22h15, les coupables ne sont pas l'applicatif mais des tâches d'oracle :

    auto optimizer stats collection

    sql tuning advisor

    En fait ce dernier, le sql tuning advisor dure plus de 30 minutes pour un résultat finalement que l'on exploite peu. Je me proposai de le désactiver purement et simplement.
    Reste la question de pourquoi ce batch est-il aussi volubile.

    Pour le nombre d'objet on a dans l'ordre pour les plus grands en tête

    • avec 8 blocs XDB$COMPLEX_TYPE
    • 6 blocs AQ_MNTR_MSGS_QUEUE
    • 5 blocs XDB$ELEMENT
    • 5 blocs AQ_MNTR_MSGS_SUBS
    • et avec 4 blocs KUPC$DATAPUMP_QUETAB et XDB$SIMPLE_TYPE et KUPCS$SATAPUMP_QUETAB_1 et AQ$_KUPC$DATAPUMP_QUETAB_1_P


    Merci encore de votre aide !

  16. #16
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Bonjour,
    Pour le nombre de blocs, il n'y a rien de particulier. Il faut donc voir ce que ces jobs créent de si gros.
    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  17. #17
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    Citation Envoyé par pachot Voir le message
    ...
    Sinon, voici comment voir quels sont les objets qui prennent le plus de place dans le dictionnaire, dans ce fameux cluster C_OBJ$:
    ...
    T’es certain que cette requête est bonne ? Parce que chez moi ça ramène aussi des vues

  18. #18
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par mnitu Voir le message
    T’es certain que cette requête est bonne ? Parce que chez moi ça ramène aussi des vues
    Oui. Et les vues sont aussi des objets dont les metadonnées sont dans le dictionnaire... normal.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  19. #19
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    Oui t'as raison, j'avais oublié qu'on s'en occupe de métadonnées!

  20. #20
    Membre du Club
    Inscrit en
    Février 2003
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : Février 2003
    Messages : 80
    Points : 47
    Points
    47
    Par défaut
    Merci à tous effectivement depuis que j'ai arrété le SQL TUNNING la base semble grandir moins. On va voir si ca tiens dans le temps.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. ORA-01950: pas de privilèges sur le tablespace 'SYSTEM'
    Par sajedose dans le forum Administration
    Réponses: 3
    Dernier message: 31/03/2008, 21h01
  2. ORA-01652 sur tablespace SYSTEM
    Par genio dans le forum Administration
    Réponses: 2
    Dernier message: 24/04/2007, 15h30
  3. ORA-01536: space quota exceeded for tablespace 'SYSTEM'
    Par stegaud dans le forum Administration
    Réponses: 1
    Dernier message: 19/04/2007, 18h33
  4. Lire un WAV, oui, mais très vite
    Par tut dans le forum Linux
    Réponses: 1
    Dernier message: 10/12/2006, 07h48
  5. Réponses: 3
    Dernier message: 23/09/2006, 14h05

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