Index slow query

Question

Ma question est similaire à celle posée dans ce fil: How to avoid this very heavy query that slows down the application?

Nous avons vérifié pour les index manquants sur les clés étrangères et trouvé quelques-uns. L'ajout des index manquants a eu l'effet inverse en ce sens qu'il a ralenti la requête encore plus. Une information importante est que notre client a une seule installation d'Oracle avec notre schéma répliqué dessus 21 fois. Chaque schéma contient juste 1 000 tables. Demandons-nous trop à Oracle avec un si grand nombre de tables (et bien sûr d'index)? Je ne sais pas ce que leur matériel est mais ma question est de savoir si c'est une approche raisonnable ou serait-il préférable de diviser les utilisateurs en différents SID?

Voici la requête en cours d'exécution par Hibernate. Le client nous dit que cette requête consomme environ 45% du processeur lors de son exécution (même si je ne sais pas pour combien de temps).

Toutes les suggestions sont appréciés, Steve

SELECT NULL AS table_cat, 
     owner AS table_schem, 
     table_name, 
     0 AS non_unique, 
     NULL AS index_qualifier, 
     NULL AS index_name, 
     0 AS TYPE, 
     0 AS ordinal_position, 
     NULL AS column_name, 
     NULL AS asc_or_desc, 
     num_rows AS CARDINALITY, 
     blocks AS pages, 
     NULL AS filter_condition 
    FROM all_tables 
WHERE table_name = 'BOOKING' 
     AND owner = 'FORWARD_TN' 
UNION 
SELECT NULL AS table_cat, 
     i.owner AS table_schem, 
     i.table_name, 
     DECODE (i.uniqueness, 'UNIQUE', 0, 1), 
     NULL AS index_qualifier, 
     i.index_name, 
     1 AS TYPE, 
     c.column_position AS ordinal_position, 
     c.column_name, 
     NULL AS asc_or_desc, 
     i.distinct_keys AS CARDINALITY, 
     i.leaf_blocks AS pages, 
     NULL AS filter_condition 
    FROM all_indexes i, 
     all_ind_columns c 
WHERE  i.table_name = 'BOOKING' 
     AND i.owner = 'FORWARD_TN' 
     AND i.index_name = c.index_name 
     AND i.table_owner = c.table_owner 
     AND i.table_name = c.table_name 
     AND i.owner = c.index_owner 
ORDER BY non_unique, 
     TYPE, 
     index_name, 
     ordinal_position 

Answer 1

Vous n'êtes pas frapper tout type de problème de capacité avec 1000 tables. C'est encore relativement petit dans le monde Oracle. Juste faire une vérification rapide de notre installation E-Business Suite et il a 23 000 tables. Une requête utilisant une tonne de CPU est presque toujours un problème de plan d'exécution. Quelques points à examiner

Avez-vous recueilli des statistiques sur l'optimiseur? Sans eux, l'optimiseur peut prendre une très mauvaise décision sur la façon d'exécuter la requête.

L'étape suivante consiste à regarder le plan d'exécution lui-même. Si le gestionnaire d'entreprise est en cours d'exécution, il a probablement cette requête sur la première page pour consommer des ressources. Vous pouvez simplement cliquer dessus et voir ce qu'il fait. Sans cela, vous devez utiliser sql_trace ou expliquer le plan pour voir ce qui se passe.

Answer 2

Vous pouvez facilement être frappé par excessive parse time sur le serveur Oracle si toutes vos instructions utilisent un SQL littéral légèrement différent (c'est-à-dire aucune variable de liaison) pour chacune des 22 000 tables. Si tel est le cas, il suffit de basculer vers des variables de liaison et la consommation du processeur devrait considérablement diminuer.

Votre client peut-il indiquer dans quelle fonction Oracle le temps CPU est-il dépensé? Oracle offre les statistiques nécessaires. Comme la consommation du processeur est considérée comme une partie importante de la consommation de l'instance entière, votre client peut exécuter un rapport statspack (ou ASH s'il a concédé sous licence le pack de diagnostic). Cela devrait montrer où exactement le temps CPU est passé.

Answer 3

Notre client en revue leur configuration Oracle et a changé la configuration aux valeurs suivantes: optimizer_index_caching = 90 OPTIMIZER_INDEX_COST_ADJ = 15 optimizer_mode = 'CHOISIR'

Ils signalent que cela semble avoir fixé leur problème de vitesse.