Pourquoi est-ce une requête de SUPPRESSION si lent sur Oracle?

Je suis à l'écriture de la base de données de scripts de mise à niveau, et suis en cours d'exécution dans une requête qui prend beaucoup plus de temps que je pense qu'il devrait:

DELETE FROM TPM_TASK WHERE TASK_TYPE='System';

Cette requête prend plus d'une heure, et je suis curieux de savoir ce que le coupable est.

Le plan d'exécution est:

DELETE STATEMENT    899.0   887 57793984    35481   1454721 899                             ALL_ROWS                                            
DELETE                                                      1   TPMDBO  TPM_TASK                                                        
TABLE ACCESS (FULL) 899.0   887 57793984    35481   1454721 1   TPMDBO  TPM_TASK    FULL    TABLE   ANALYZED    1

En cours d'exécution:

select count(1) FROM TPM_TASK WHERE TASK_TYPE='System';

Le plan est:

SELECT STATEMENT    92.0    89  14527479    1   7   92                  ALL_ROWS                                            
SORT (AGGREGATE)                1   7   1           AGGREGATE                                                   
INDEX (FAST FULL SCAN)  92.0    89  14527479    35481   248367  1   TPMDBO  TPM_TASK_TASK_TYPE  FAST FULL SCAN  INDEX   ANALYZED

Cette requête est assez rapide et qui me donne 44,202 lignes. Le nombre total de lignes dans la table est 71419. Depuis que je suis la suppression de plus de la moitié des lignes, je suis en train de penser Oracle n'est pas la peine d'utiliser l'index pour les supprimer, ce qui est bien. Une analyse complète de 71 000 lignes devraient encore prendre quelques secondes de toute façon.

Il n'y a pas de déclencheurs sur ce tableau. Il n'y a pas d'autres tables qui ont des contraintes FK sur cette table, il y a cependant quelques points de vue et des fonctions SQL qui utilisent ce tableau. La seule application qui utilise cette base de données est notre serveur web, qui est arrêté lors de la mise à niveau - donc je ne pense pas qu'il soit problèmes de verrouillage de passe. D'autres idées?

  • L'instruction delete, en effet, ne pas utiliser l'index comme vous pouvez le voir par la TABLE ACCESS (FULL) étape (btw: merci de poster les plans avec l'onglet caractères supprimés, actuellement, les colonnes ne s'alignent pas et il est pratiquement impossible de les lire)
  • Mais qui doit être bien droit? La clause where retourne plus de la moitié des lignes, à l'aide de l'index ne serait pas vraiment une énorme perf d'amélioration.
  • Hmm, Aqua Data Studio de vis jusqu'à la mise en forme lorsque vous copiez et collez des plans d'exécution.
  • Si il y a des références principales étrangères à cette table, et les autres tables ont beaucoup de dossiers, les effacez requête sera lente.
InformationsquelleAutor Mike Christensen | 2013-06-07
  1. 8

    Baring à l'esprit les considérations que vous avez donné, la seule chose à laquelle je pense est une sorte de UNINDEXED REFERENCE CONSTRAINT se référant à cette table. Essayez d'exécuter ce script contre la table, elle devrait vous donner un rapport avec tout indexée références qu'il trouve. Il n'y a certainement aucune raison pour laquelle cette opération devrait prendre près de cette longue.

    • Oui, il y a 56 lignes de ce rapport. Donc, vous dites quelque chose de référence TPM_TASK et il n'y a aucun indice sur ce, il a faire un full table scan pour chaque individu supprimer?
    • Oui, c'est exact. Peut-être plus que d'une analyse de la table.
    • Ah, oui, c'était cela! Il y en avait deux tables de référence de la PK de TPM_TASK qui n'ont pas été indexés. J'ai créé un INDEX sur ceux-ci, et puis il suffit de supprimer manuellement les lignes référencé le bientôt-à-être supprimé des lignes dans TPM_TASK (en évitant la suppression en cascade). Après cela, l'instruction delete sur TPM_TASK a pris environ 10 secondes. C'est un fantastique exemple prouvant simplement parce que vous n'avez pas interroger directement sur une colonne ne signifie pas que vous n'avez pas besoin d'un index sur elle.
    • Heureux que j'ai été capable de les aider, je passe beaucoup de temps à l'optimisation des requêtes Oracle et courir dans l'indexation & référencement des questions régulièrement.
    • Excellent! Mais vous avez dit "Il n'y a pas d'autres tables qui ont des contraintes FK sur cette table"?
    • Peut-être moins évident que les contraintes FK. Une sorte de déclencheur sur une table de référence à un autre de la table, par exemple.
    • Je ne dire que! Dans Aqua Data Studio, si vous cliquez sur Dépendances, ces tableaux ne présentent pas. Je ne suis pas sûr si cette fonction est cassé (au moins pour Oracle), ou tout simplement ne pas faire ce que je m'attendais à le faire. Peut-être que je vais leur envoyer un mail et de demander.
    • FYI - je viens de découvrir Aqua Data Studio affiche FK contraintes à partir d'autres objets, mais vous devez faire un clic droit sur le tableau et sélectionnez Propriétés du Tableau, puis aller à la Références onglet.

    InformationsquelleAutor Glitch Desire