2010-11-29 2 views
5

Contexte: base de données Oracle 10.L'utilisation de partitions serait-elle une bonne idée dans une telle situation?

Dans une table assez grande (plusieurs millions d'enregistrements), nous avons récemment commencé à voir des problèmes de performance. La table a des comportements/conditions spéciales.

  • son écriture la plupart du temps une fois, puis n'est jamais changé à nouveau
  • au cours du premier jour ou les dossiers sont classés de 0..N (permet d'appeler cette classe de colonne). les enregistrements peuvent être reclassés plusieurs fois pendant ce premier jour
  • nouvelles entrées sont ajoutées avec la classe 0 signifiant "pas encore classé"
  • chaque heure ou alors un processus classifie les nouveaux reocrds et leur donne une nouvelle classe de 1..N
  • tous les lecteurs ne sont intéressés que dans la classe 1
  • tous les dossiers plus d'un jour changer à peine leur classe,> 1 devient nettoyer un après quelques jours

maintenant, comme la plupart accès est fait en classe 1, cette colonne est souvent impliquée dans les requêtes (class = 1), avec d'autres ons. Nous avons un index sur la colonne de classe, et encore pour certaines autres colonnes.

À ma question: Nous pensons maintenant à partitionner cette table par classe. Autant que je l'ai compris, cela rendrait l'indexation/travail avec les données plus rapide, car la classe = 1 est déjà séparée du reste des données et donc l'accès à celle-ci est implicitement plus efficace. Est-ce correct?

Si vous êtes d'accord que c'est une bonne idée, je vais continuer à lire dans le sujet!

Merci Vive

Mise à jour 2010.11.30

Merci beaucoup pour l'entrée. Je n'étais pas au courant que c'est une option supplémentaire :) merci de le signaler (avant que j'y investisse trop de temps). Mais à côté du problème de licence, il me semble que la partition n'est pas forcément une bonne solution dans ce contexte.

Répondre

4

Quelles opérations connaissent une lenteur et avez-vous pu identifier pourquoi ces opérations sont lentes?

Si vous partitionnez par classe, vous allez ralentir le processus de mise à jour de la classe pour une ligne.Comme cela forcerait une ligne à se déplacer d'une partition à une autre, vous transformeriez une mise à jour en une suppression de la première partition et une insertion dans la deuxième partition. Si votre processus horaire est lent et lent parce qu'il faut du temps pour trouver tous les nouveaux enregistrements, le compromis de performance peut être assez raisonnable. Si votre processus horaire est lent parce qu'il faut du temps pour calculer ce que la nouvelle classe devrait être et pour mettre à jour toutes les lignes, d'un autre côté, ce compromis est probablement une très mauvaise idée. Étant donné que le partitionnement est une option de coût supplémentaire par rapport à la licence d'édition d'entreprise, je vous conseille de ne pas utiliser certains index basés sur les fonctions pour obtenir la plupart des améliorations de performances que vous ciblez à un coût relativement faible . Si, par exemple, vous avez eu deux fonctions basée sur les indices

CREATE INDEX idx_new_entries 
    ON your_table((CASE WHEN class = 0 THEN primary_key ELSE null END)); 

CREATE INDEX idx_class1_entries 
    ON your_table((CASE WHEN class = 1 THEN primary_key ELSE null END)); 

avec quelques vues

CREATE VIEW vw_new_entries 
AS 
SELECT (CASE WHEN class = 0 THEN primary_key ELSE null END) primary_key, 
     <<list of columns>> 
    FROM your_table 
WHERE class = 0 

CREATE VIEW vw_class1_entries 
AS 
SELECT (CASE WHEN class = 1 THEN primary_key ELSE null END) primary_key, 
     <<list of columns>> 
    FROM your_table 
WHERE class = 1 

puis toutes les requêtes sur les nouvelles vues qui filtraient sur le PRIMARY_KEY utiliseraient la fonction fonction index qui, à leur tour, n'indexeraient que les lignes appropriées de la table sous-jacente. Cela peut vous permettre d'améliorer les performances de recherche sans devoir recourir au partitionnement.

-1

Yepp, ça me semble une bonne idée.

Cependant, il existe de meilleures alternatives à cela, mais une solution facile est une partition.

+1

Partitionnement - au moins pour Oracle - est une option coûteuse, et en aucun cas approprié dans toutes les situations. – APC

3

Quelle est la taille de la table en Mo? Quel est le taux de croissance? Est-ce que vous purgez des données ou prévoyez-vous de purger des données? Quels index sont sur la table maintenant? Pouvez-vous nous donner la définition de la table d'échantillon? Le partitionnement est une option de licence supplémentaire. Avez-vous vérifié que quelqu'un va réellement payer pour cela?

et surtout, s'il vous plaît fournir des exemples de requêtes

Ce que vous avez fournies ne sont pas suffisamment d'informations pour fonder une décision sur.

Questions connexes