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 :

Tablespaces et performances : Best practices


Sujet :

Administration Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    140
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 140
    Par défaut Tablespaces et performances : Best practices
    Bonjour
    Un nouveau projet est en cours de conception et implémentation.
    Ma question concerne la gestion des tablespaces.
    Certes nous devrions séparer les data (tbsdata) des indexes (tbsidx)
    Mais y a t il d'autres subtilités à prendre en compte dans l'organisation des tablespaces afin
    de gagner en maintenance et performances sachant que nos tables sont partitionnées voir sous-partitionnées ?
    Je pense aussi au :
    - sous-partitionnement par hachage ?
    - au bigfile ?
    - à 3 catégories de tablespaces : petites tables ,moyennes et grosses tables ?
    Votre avis ,merci .

  2. #2
    Membre averti
    Homme Profil pro
    Consultant en technologies
    Inscrit en
    Novembre 2012
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Consultant en technologies
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Novembre 2012
    Messages : 21
    Par défaut
    Autoextend ON ?

  3. #3
    Membre confirmé
    Homme Profil pro
    Consultant
    Inscrit en
    Mai 2006
    Messages
    147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Mai 2006
    Messages : 147
    Par défaut
    Bonjour
    Idéalement il faut dispatcher les données sur différents disques pour éviter les contentions.

    Le tablespace permet de faire un lien entre les segments(structure logique) et les fichiers .dbf(structure physique).

  4. #4
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Suisse

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

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 822
    Billets dans le blog
    1
    Par défaut
    Bonjour,
    Citation Envoyé par devkais Voir le message
    Idéalement il faut dispatcher les données sur différents disques pour éviter les contentions.
    Pour cela on le fait plutôt par striping. Donc la séparation en tablespaces est plutôt une question d'administration pour ce qui se gère au niveau tablespace: transport de tablespace, backup/restauration, attributs (extent size).
    Donc l'idée de base, c'est de séparer par application (pour pouvoir mettre offline un tablespace sans interrompre plusieurs applis) et éventuellement mettre les grosses tables à part.
    Cordialement,
    Franck.

  5. #5
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    140
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 140
    Par défaut
    Citation Envoyé par pachot
    ... et éventuellement mettre les grosses tables à part.
    Franck.
    Pourriez-vous développer ce concept ?

  6. #6
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    140
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 140
    Par défaut
    Bonjour
    Hormis la séparation entre tablespaces DATA et tablespces INDEX que peut-on préconiser ?

  7. #7
    Membre expérimenté Avatar de Laurent_du_78
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    138
    Détails du profil
    Informations personnelles :
    Âge : 59
    Localisation : France, Yvelines (Île de France)

    Informations forums :
    Inscription : Juin 2007
    Messages : 138
    Par défaut
    Bonjour, en plus des points déjà cités (séparation index et table, stripping etc ...)
    - utiliser : ASSM SEGMENT SPACE MANAGEMENT AUTO
    - extent uniforme : EXTENT MANAGEMENT LOCAL UNIFORM SIZE xx, adapter la taille des extents des tables.

  8. #8
    Membre expérimenté

    Profil pro
    Administrateur de base de données
    Inscrit en
    Septembre 2008
    Messages
    169
    Détails du profil
    Informations personnelles :
    Âge : 55
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Septembre 2008
    Messages : 169
    Par défaut
    comme le dit pachot si vos bases de données sont sur une baies de disque
    La performance I/O est a obtenir par un bon slicing des disques de la baie.
    La separation des data et index en differents tablespace a peu d'interet.
    Mieux vaut utiliser les tablespace pour des séparations fonctionnel (ex: par applications, par schémas).

  9. #9
    Membre confirmé
    Homme Profil pro
    Consultant
    Inscrit en
    Mai 2006
    Messages
    147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Mai 2006
    Messages : 147
    Par défaut
    Citation Envoyé par a.presles Voir le message
    La separation des data et index en differents tablespace a peu d'interet.
    Je ne suis pas d'accord car cela facilite les opérations de maintenance et apporte beaucoup au niveau perfs

  10. #10
    Membre Expert

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Juin 2012
    Messages
    612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2012
    Messages : 612
    Par défaut
    Citation Envoyé par devkais Voir le message
    Je ne suis pas d'accord car cela facilite les opérations de maintenance et apporte beaucoup au niveau perfs
    Autant sur la simplification de certaines opérations de maintenance je suis d'accord, autant le gain au niveau des performances (sauf configuration stockage spécifique) me laisse dubitatif.
    Pourriez-vous détailler comment vous obtenez des gains de performance ? Quelle est votre architecture ?

  11. #11
    Membre confirmé
    Homme Profil pro
    Consultant
    Inscrit en
    Mai 2006
    Messages
    147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Mai 2006
    Messages : 147
    Par défaut
    Bonjour ,il est possible dans certains cas d'avoir un gain en perfs en séparant les tables et les indexes dans des tablespaces différents ayant une taille d'extent(index) < taille d'extent (data).
    Sinon en général avec les baies modernes le striping permet de minimiser les contentions IO par une répartition automatique des blocs de donnés sur les différents disques.
    Enfin avoir un tbs index et un autre tbs data n'a aucun inconvénient et permet aussi d'avoir une bonne organisation logique

  12. #12
    Membre émérite
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2007
    Messages
    419
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Novembre 2007
    Messages : 419
    Par défaut
    bonsoir,
    c'est vrai que cela n'a aucun inconvénient, mais il n'y a aucune justification non plus.cette conception est tombée en désuétude à partir de la 8i mais certains fournisseurs de logiciels, progiciels insistent encore lourdement sur cette séparation qui ne trouve aucun fondement si on n'a pas les mêmes points de montage pour les deux types de données.
    pour des raisons d'administration? séparation par schéma serait plus judicieux.
    quand à LMU... oracle se débrouille mieux en auto allocate. pour éviter les contentions I/O c'est effectivement le dispatching sur plusieurs disques qui fait la différence.
    mais puisque vous en êtes à la conception, testez et faites vous une idée! le partitionnement est une notion très fonctionnelle, à tester aussi.

  13. #13
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Suisse

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

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 822
    Billets dans le blog
    1
    Par défaut
    Bonjour,
    A ceux qui séparent tablespace table et index, je leur demande en général où ils mettent les vues matérialisées (qui sont des tables mais redondantes commes les index) et où ils mettent les IOT (qui sont des tables, mais stockées commes des index).
    Cordialement,
    Franck.

  14. #14
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    140
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 140
    Par défaut
    Bonjour Franck,
    Donc selon vous ,pour une nouvelle base à créer UN SEUL tablespace applicatif suffit ?
    merci pour votre retour.
    Z.

  15. #15
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Suisse

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

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 822
    Billets dans le blog
    1
    Par défaut
    Il faut d'abort isoler les applis s'il y en a plusieurs sur la base (consolidation)
    Ensuite on séparer les tablespaces pour isoler d'autres choses: de très gros objets pour lesquels on veut une taille d'extend particulière, des données d'archives qu'on veut mettre dans un filesystem monté sur des disques moins chers, des tables chargées en nologging pour lesquelles on veut faire un backup après chargemetn sans backuper toute la base, etc.

    Sur le fait de mettre à part les données qu'on peut reconstruire (indexes, mviews) pourquoi pas. Mais pourquoi ? il faut les backuper aussi. Il est rare qu'on puisse se permettre de passer des heures à reconstruire tous les index. Sans parler des plantages à cause des tempfiles trop petits. Et des changement de plans d'exécution une fois que tout est reconstruit.

  16. #16
    Membre éclairé
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mai 2014
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Santé

    Informations forums :
    Inscription : Mai 2014
    Messages : 31
    Par défaut ASM ou filesystem
    Bonjour à tous,

    Petite question... est-ce que les datafiles sont sur un système de fichiers ou sur ASM?

    Parce que si le tout est sur ASM, dans mon cas, je crée des tablespaces différents pour les tables, les index et les LOB mais je place tous les tablespaces dans le même diskgroup.

    J'ai aussi l'habitude de séparer les applications en donnant des tablespaces différents pour chaque.

    Et pour terminer, le flash_recovery_area est sur un autre diskgroup.

    Bonne journée.

    Sylvain

  17. #17
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    140
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 140
    Par défaut
    Citation Envoyé par struchon Voir le message
    Bonjour à tous,

    Petite question... est-ce que les datafiles sont sur un système de fichiers ou sur ASM?
    Bonjour ,
    Les datafiles sont sur un FS.
    Mais rien n'empêche de basculer vers ASM s'il le faut ...nous sommes déjà au début
    Z.

Discussions similaires

  1. Best practice pour bonnes performances
    Par grabriel dans le forum Langage
    Réponses: 0
    Dernier message: 15/04/2010, 15h56
  2. Réponses: 4
    Dernier message: 23/05/2006, 14h22
  3. [9i] AutoExtend Tablespace et performances
    Par nuke_y dans le forum Oracle
    Réponses: 11
    Dernier message: 09/03/2006, 14h20

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