Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 15 sur 15
  1. #1
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 819
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 819
    Points : 24 808
    Points
    24 808

    Par défaut Nettoyage du tablespace SYSTEM

    Bonjour et bonne année à tous les oracliens.

    Cadeau de début d'année, je me retrouve ce matin avec une jolie erreur ORA-01653 sur le tablespace SYSTEM !

    J'ai pu augmenter la taille du data_file à 900 000 000 mais y aurait-il des choses à nettoyer dans les tables de SYSTEM, SYS ou autres qui utilisent ce tablespace.

    Est-ce que cette taille vous semble normale ou trop grande ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  2. #2
    Membre chevronné Avatar de jkofr
    Homme Profil pro Jacques Kostic
    Senior Consultant DBA (Trivadis SA)
    Inscrit en
    octobre 2006
    Messages
    484
    Détails du profil
    Informations personnelles :
    Nom : Homme Jacques Kostic
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Senior Consultant DBA (Trivadis SA)
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2006
    Messages : 484
    Points : 686
    Points
    686

    Par défaut

    Hello,

    Peu-etre aud$?

    jko
    OCM 11g, RAC and Performance & Tuning Expert 11g
    RMAN Backup & Recovery, Data Guard and Grid Control

  3. #3
    Futur Membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    juillet 2012
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : juillet 2012
    Messages : 12
    Points : 17
    Points
    17

    Par défaut

    Une petite requête rapidement écrite pour voir éventuellement les objets qui n'auraient pas du être créés dans ce tablespace :

    Code :
    SELECT OWNER||'.'||SEGMENT_NAME FROM dba_segments WHERE TABLESPACE_NAME='SYSTEM' AND OWNER NOT IN ('SYSTEM', 'SYS');
    Cela ne doit pas être ton cas mais ça peut toujours aider un débutant désespéré qui tombe sur ce post.

    Sinon, en tout rigueur ... il est difficile de dire si la taille de system est correcte sans connaitre la volumétrie de ta base.
    Si tu n'as que deux schémas et trois tables ... c'est inquiétant ... si tu répertories (à leur insu bien sur) les informations confidentielles de tous les braves utilisateurs du réseaux social le plus en vogue ... ça se discute.

    Je t'inviterais d'abord à regarder quels sont tes objects les plus volumineux :

    Code :
    SELECT owner, segment_name, segment_type, bytes/1024/1024 FROM dba_segments WHERE tablespace_name = 'SYSTEM' ORDER BY 4;

  4. #4
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 819
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 819
    Points : 24 808
    Points
    24 808

    Par défaut

    Pas bête en effet !

    Grâce au premier résultat affiché ici, et après avoir jeté un œil à la structure et au contenu de la table, je comprends qu'il s'agit de la table qui stocke l'audit de la BDD.
    Y figurent plus de 1 400 000 lignes, les premières datant de 2010 ! Autrement dit, elle n'a jamais été purgée depuis l'installation d'Oracle.

    Je lis aussi sur le lien donné plus haut :
    la table SYS.AUD$ doit être surveillée et purgée par un DELETE (ou mieux un TRUNCATE) explicite de Mr SYS si nécessaire
    Que préconisez-vous comme méthode de purge ? Quelle fréquence ? Conserver quelle ancienneté de lignes d'audit ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  5. #5
    Membre chevronné Avatar de jkofr
    Homme Profil pro Jacques Kostic
    Senior Consultant DBA (Trivadis SA)
    Inscrit en
    octobre 2006
    Messages
    484
    Détails du profil
    Informations personnelles :
    Nom : Homme Jacques Kostic
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Senior Consultant DBA (Trivadis SA)
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2006
    Messages : 484
    Points : 686
    Points
    686

    Par défaut

    Hello,

    pour la période de rétention, cela dépend des besoins du business...

    Avant cela n'était pas supporté de déplacer cette table vers un autre tablespace.
    C'était possible, mais NON supporté.

    Depuis la 11g il existe une procédure pour déplacer cette table AUD$ vers un tablespace dédié.

    Package:
    DBMS_AUDIT_MGMT
    Procédure
    SET_AUDIT_TRAIL_LOCATION

    Bonne soirée.
    jko
    OCM 11g, RAC and Performance & Tuning Expert 11g
    RMAN Backup & Recovery, Data Guard and Grid Control

  6. #6
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 819
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 819
    Points : 24 808
    Points
    24 808

    Par défaut

    Un problème en entraîne un autre...

    La base de prod sur laquelle j'ai rencontré le problème objet de cette de discussion est dupliquée 3 fois sur un serveur de test. Du coup, la partition qui héberge les fichiers des bases de test est pleine.
    Comme j'étais connecté via SQL Developer sur l'une des bases de test quand on m'a signalé que la connexion au serveur de test était impossible, j'ai voulu purger un peu la fameuse table sys;aud$ de tout ce qui est plus ancien que 2012, grâce à cette requête :
    Code SQL :
    1
    2
    DELETE FROM sys.aud$
    WHERE ntimestamp# < '31/12/11 23:59:59'

    Un COUNT(*) préalable avec le même WHERE donnait quand même plus de 600 000 lignes à supprimer.

    Dans SQL Developer, la requête tourne depuis au moins un quart d'heure. À votre avis, elle est plantée ?

    EDIT : La requête a terminé son exécution.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  7. #7
    Membre chevronné Avatar de jkofr
    Homme Profil pro Jacques Kostic
    Senior Consultant DBA (Trivadis SA)
    Inscrit en
    octobre 2006
    Messages
    484
    Détails du profil
    Informations personnelles :
    Nom : Homme Jacques Kostic
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Senior Consultant DBA (Trivadis SA)
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2006
    Messages : 484
    Points : 686
    Points
    686

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    Un problème en entraîne un autre...

    La base de prod sur laquelle j'ai rencontré le problème objet de cette de discussion est dupliquée 3 fois sur un serveur de test. Du coup, la partition qui héberge les fichiers des bases de test est pleine.
    Comme j'étais connecté via SQL Developer sur l'une des bases de test quand on m'a signalé que la connexion au serveur de test était impossible, j'ai voulu purger un peu la fameuse table sys;aud$ de tout ce qui est plus ancien que 2012, grâce à cette requête :
    Code SQL :
    1
    2
    DELETE FROM sys.aud$
    WHERE ntimestamp# < '31/12/11 23:59:59'

    Un COUNT(*) préalable avec le même WHERE donnait quand même plus de 600 000 lignes à supprimer.

    Dans SQL Developer, la requête tourne depuis au moins un quart d'heure. À votre avis, elle est plantée ?
    En général c'est assez long :-)

    Tu peux spider un peux avec du paralèlisme si tu es en enterprise edition:

    Code SQL :
    1
    2
    DELETE /*+ PARALLEL (t, 4) */ FROM sys.aud$ T
    WHERE T.ntimestamp# < '31/12/11 23:59:59'

    Tu peux allez faire un tour dans v$session et suivre les waits associés à ta session...

    jko
    OCM 11g, RAC and Performance & Tuning Expert 11g
    RMAN Backup & Recovery, Data Guard and Grid Control

  8. #8
    Modérateur

    Homme Profil pro Fabien
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    6 844
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabien
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études en décisionnel
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2008
    Messages : 6 844
    Points : 14 183
    Points
    14 183

    Par défaut

    Faudrait regarder le plan d'exécution de la requête pour voir s'il y a utilisation d'un index ou non.
    Il faut aussi regarder sur la table combien elle possède d'index et combien elle possède de lignes.

    En plus les données sont mal typées, j'imagine que ntimestamp# est de type date ou timestamp.
    Mais comme elle est comparée à du varchar, Oracle va convertir toute la colonne avant de faire son filtre.
    Il faut vérifier pour le format de conversion implicite soit correct.
    Et dans ce cas l'index - s'il existe - n'est pas utilisé.

    Donc si l'index n'est pas utilisé, Oracle va lire toute la table, effacer une ligne, et recommencer cette opération 600.000 fois. Ça va prendre du temps !

    Il vaut mieux tuer la transaction, vérifier la présence de l'index afin de le créer s'il n'existe pas, vérifier le type de la colonne ntimestamp# et passer avec un des deux where :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    CREATE INDEX ix_aud_ntimestamp
    ON sys.aud$ (ntimestamp#)
    tablespace <tbs_idx>
    parallel 4;
     
    DELETE FROM sys.aud$
     WHERE ntimestamp# < to_date('01/01/2012', 'dd/mm/yyyy');
     WHERE ntimestamp# < to_timestamp('01/01/2012', 'dd/mm/yyyy');
     
    DROP INDEX ix_aud_ntimestamp;
    Edit : tant pis !

  9. #9
    Membre chevronné Avatar de jkofr
    Homme Profil pro Jacques Kostic
    Senior Consultant DBA (Trivadis SA)
    Inscrit en
    octobre 2006
    Messages
    484
    Détails du profil
    Informations personnelles :
    Nom : Homme Jacques Kostic
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Senior Consultant DBA (Trivadis SA)
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2006
    Messages : 484
    Points : 686
    Points
    686

    Par défaut

    Citation Envoyé par Waldar Voir le message
    Donc si l'index n'est pas utilisé, Oracle va lire toute la table, effacer une ligne, et recommencer cette opération 600.000 fois. Ça va prendre du temps !
    Pas daccord Waldar.
    Il ne vas pas scanner la table 600 000 fois mais une seule fois.

    Concernant l'index, la modification d'objects appartenant à sys n'est pas supportée par Oracle...

    Jko
    OCM 11g, RAC and Performance & Tuning Expert 11g
    RMAN Backup & Recovery, Data Guard and Grid Control

  10. #10
    Modérateur

    Homme Profil pro Fabien
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    6 844
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabien
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études en décisionnel
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2008
    Messages : 6 844
    Points : 14 183
    Points
    14 183

    Par défaut

    Citation Envoyé par jkofr Voir le message
    Il ne vas pas scanner la table 600 000 fois mais une seule fois.
    Je me suis emballé !

    Citation Envoyé par jkofr Voir le message
    Concernant l'index, la modification d'objects appartenant à sys n'est pas supportée par Oracle...
    L'index peut être mis ailleurs que dans sys, comme ça pas de modification sur ce schéma.

  11. #11
    Expert Confirmé Sénior Avatar de mnitu
    Homme Profil pro Marius Nitu
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    4 609
    Détails du profil
    Informations personnelles :
    Nom : Homme Marius Nitu
    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 : 4 609
    Points : 9 028
    Points
    9 028

    Par défaut

    Citation Envoyé par Waldar Voir le message
    ...
    L'index peut être mis ailleurs que dans sys, comme ça pas de modification sur ce schéma.
    Il ne faut pas toucher aux objets appartenant au sys sous menace de châtiment du purgatoire éternel.

  12. #12
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 819
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 819
    Points : 24 808
    Points
    24 808

    Par défaut

    Citation Envoyé par mnitu Voir le message
    Il ne faut pas toucher aux objets appartenant au sys sous menace de châtiment du purgatoire éternel.
    Mais purger sa table AUD$ ne nous précipite pas en enfer j'espère ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  13. #13
    Modérateur

    Homme Profil pro Fabien
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    6 844
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabien
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études en décisionnel
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2008
    Messages : 6 844
    Points : 14 183
    Points
    14 183

    Par défaut

    C'est dangereux Oracle en fait !

  14. #14
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 819
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 819
    Points : 24 808
    Points
    24 808

    Par défaut

    Ben je suppose qu'un oracle peut donner une bonne nouvelle comme prédire une catastrophe !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  15. #15
    Expert Confirmé Sénior Avatar de mnitu
    Homme Profil pro Marius Nitu
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    4 609
    Détails du profil
    Informations personnelles :
    Nom : Homme Marius Nitu
    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 : 4 609
    Points : 9 028
    Points
    9 028

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    Mais purger sa table AUD$ ne nous précipite pas en enfer j'espère ?
    Aucun souci pour ça! J'ai parlai juste de la création des indexes sur des objets appartenant à sys dans des autres schémas que sys.

    [Edit]
    Quoi que ça sera mieux pour la sauvergarde de nos amês d'utiliser si possible les outils d'Oracle :
    Auditing Enhancements (DBMS_AUDIT_MGMT) in Oracle Database 11g Release 2

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •