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 :

Gestion de l'espace dans les tablespaces (tables partitionnées)


Sujet :

Administration Oracle

  1. #1
    Membre du Club
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2004
    Messages
    46
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Avril 2004
    Messages : 46
    Points : 43
    Points
    43
    Par défaut Gestion de l'espace dans les tablespaces (tables partitionnées)
    Bonjour

    Actuellement en 10g, nous avons élaboré pour notre datawarehouse un système ou les tables partitionnées sont
    stockees dans des tablespaces dédiés a une unité de temps
    ex: 7 partitions-jours = 1 tablespace = 1 datafile
    1 partition-mois = 1 tablespace = 1 datafile

    (ex : P201201 est dans le TS XXX201201 defini sur un datafile nomme 201201 )

    En effet au tout debut de l'implementation, toutes les partitions de toutes les tables étaient dans un meme TS
    et nous avions des problemes de gestion d'espace
    (TS qui grossissaient énormement mais pleins de "trous" car lors des inserts, les blocs en-dessous du HWM n'etaient pas re-utilises)

    Nous avons mis en place un process d'archivage des partitions : drop partition puis drop du TS et création d'un nouveau TS un autre avec lequel on n'a pas de souci
    puisqu'il va etre entièrement rempli avec la nouvelle partition (ou les 7 partitions de la semaine)

    Un autre avantage c'est d'avoir tous les blocs d'une partition dans le meme fichier, donc meilleure performance (lors du partition pruning)

    Mais, cela génere une énorme quantité de fichiers....

    Nous allons migrer en 11g et je voudrais revenir a une organisation avec moins de fichiers, mais sans etre confrontée a nouveau a des pbs d'espace


    Je pense que le process simple "drop partition- create partition - remplir cette partition" sera OK,
    mais il y a des cas + complexes qui necessitent de faire un truncate puis load
    (reprocess de partitions dans le passé ou load jour apres jour de la meme partition )

    Si on fait un truncate partition reuse storage, au reload la partition ne risque -t-elle pas d'etre fragmentée dans le TS ,
    avec donc une perte de performance fors de la lecture ?

    Nous utilisons Datastage - la version précédente utilisait SQL*Loader, la nouvelle fait des bulk inserts.
    Datastage parallelise ses inserts : pour le meme job; n process insèrent en parallele, ce qui crée plusieurs paquets de blocs dans la partition
    c'est pourquoi je m'inquiete de cette fragmentation
    Si on fait un truncate partition drop storage, ou seront localisées les donnees lors du load? Apres le HWM si on a + de données qu'avant ? donc des trous ?
    Ou bien l'espace libere est-il proprement reattribué et réutilisé pour le nouveau load ?

    Merci d'avance à ceux qui ont quelques idées sur ce sujet

    Isa

  2. #2
    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,
    Un autre avantage c'est d'avoir tous les blocs d'une partition dans le meme fichier, donc meilleure performance (lors du partition pruning)
    Non, le nombre de fichier n'a aucun impact sur la performance.
    C'est plutôt le contraire: plus vous en avez plus le checkpoint sera long.

    Si on fait un truncate partition reuse storage, au reload la partition ne risque -t-elle pas d'etre fragmentée dans le TS ,
    avec donc une perte de performance fors de la lecture ?
    Plusieurs choses.
    Premièrement, cette fragmentation n'a aucun impact sur la performance.

    Et il n'y a pas de la place perdue truncate partition reuse storage vu que vous rechargez le même volume de données

    Si on fait un truncate partition drop storage, ou seront localisées les donnees lors du load? Apres le HWM si on a + de données qu'avant ? donc des trous ?Ou bien l'espace libere est-il proprement reattribué et réutilisé pour le nouveau load ?
    Il ne faut pas confondre l'espace alloué dans le tablespace (et là ce qui est libéré peut être utilisé par n'importe quelle table du même tablespace - donc probablement pas de soucis) avec l'espace alloué à la table (dans lequel il y a un high water mark).

    Je ne vois pas quelle fragmentation vous pouvez avoir du moment que vous faites un truncate.
    Votre problème de fragmentation vient probablement d'un temps où vous faisiez des delete avant de charger en direct-path.

    C'est au contraire en multipliant les tablespaces que vous perdez de la place un peu partout.

    Donc en bref, pour les perfs et pour l'espace disque, il vaut mieux tout regrouper. Pour d'autres raisons, vous pouvez quand même être amenés a avoir plusieurs tablespaces, si vous voulez mettre les vieilles partitions sur des disques plus lents par exemple, ou mettre ces anciennes partitions en read-only, ne pas les backuper de la même manière,...

    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

  3. #3
    Membre du Club
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2004
    Messages
    46
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Avril 2004
    Messages : 46
    Points : 43
    Points
    43
    Par défaut
    Merci pour votre réponse.

    c'est vrai qu'au debut on avait pas mal de delete qui ont depuis été remplacés au maximum par des truncate.

    En ce qui concerne la fragmentation, comme nous sommes dans un datawarehouse, avec des lectures de gros volumes, il vaut mieux que les blocks ne soient pas trop dispersés.
    Mais effectivement,ils ne seront pas + dispersés dans un fichier que dans plusieurs

    Comme nous avons une seule table par tablespace, je craignais que l'espace libéré lors du truncate ou drop ne soit justement pas réutilisé s'il est en dessous du HWM.
    D'après vos explications ce n'est pas le cas:
    Donc, si on considère une table avec des partitions de taille homogène, une fois qu'un TS a atteint sa taille maximale (= nombre max de partitions de la table selon la durée de rétention des infos, puisque nos partitions sont time-based),
    les opérations suivantes ne devraient ni augmenter sa taille, ni augmenter sa fragmentation
    --> drop partition "passée" + create "nouvelle" partition + load
    --> truncate partition + load de cette partition (cas de reprocess)

    Correct ?

  4. #4
    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
    Correct.
    Pourquoi une seule table par tablespace ?
    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

  5. #5
    Membre du Club
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2004
    Messages
    46
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Avril 2004
    Messages : 46
    Points : 43
    Points
    43
    Par défaut
    Pas mal de raisons...
    - Pour repondre au probleme initial des TS qui stockaient beaucoup de tables et devenaient énormes,
    - pour améliorer les perfs (on pensait améliorer les lectures en ne mettant pas "tous les oeufs dans le meme panier")
    - pour faciliter l'archivage table par table , partition par partition,
    - pour pouvoir transporter nos tablespaces d'une instance a l'autre si besoin (ciblage de partitions)
    - pour pouvoir donner des parametres de taille de TS different par table (si grosse ou petite)

    Tout cela est géré par des packages Oracle qui créent/ droppent les partitions et les TS automatiquement -donc pas de souci d'administration

    La question n'est pas de savoir si c'etait une bonne ou une mauvaise solution, à l'epoque elle semblait OK, maintenant elle est à revoir en raison du trop grand nombre de fichiers , j'essaie de rassembler les éléments nécessaires pour améliorer sans créer de nouveaux problèmes

Discussions similaires

  1. Réponses: 3
    Dernier message: 25/05/2015, 19h55
  2. fontion : Gestion des espaces dans les noms de dossier
    Par _stephnane_ dans le forum Scripts/Batch
    Réponses: 0
    Dernier message: 10/11/2010, 11h56
  3. Dépendances dans les tablespaces Oracle
    Par learn dans le forum Oracle
    Réponses: 5
    Dernier message: 17/10/2005, 23h19
  4. Gestion des message windows dans les threads
    Par billyboy dans le forum Windows
    Réponses: 5
    Dernier message: 06/10/2003, 18h25

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