Oracle 11g - Comment optimiser lent parallèle insert select?

nous voulons accélérer l'exécution de l'insertion parallèles déclaration ci-dessous. Nous nous attendons à insérer autour de 80 millions de disques et prend environ 2 heures pour le terminer.

INSERT /*+ PARALLEL(STAGING_EX,16) APPEND NOLOGGING */ INTO STAGING_EX (ID, TRAN_DT, 
RECON_DT_START, RECON_DT_END, RECON_CONFIG_ID, RECON_PM_ID) 
SELECT /*+PARALLEL(PM,16) */ SEQ_RESULT_ID.nextval, sysdate, sysdate, sysdate, 
'8a038312403e859201405245eed00c42', T1.ID FROM PM T1 WHERE STATUS = 1 and not 
exists(select 1 from RESULT where T1.ID = RECON_PM_ID and CREATE_DT >= sysdate - 60) and 
UPLOAD_DT >= sysdate - 1 and (FUND_SRC_TYPE = :1)

Nous pensons que la mise en cache des résultats de l'existe pas de colonne permettra d'accélérer les insertions. Comment effectuer la mise en cache? Toutes les idées de quelle autre manière à accélérer l'insertion?

Veuillez consulter ci-dessous le plan statistique à partir d'Enterprise Manager. Nous avons également constaté que les états ne sont pas en cours d'exécution en parallèle. Est-ce normal?

Oracle 11g - Comment optimiser lent parallèle insert select?

Edit: btw, la séquence est déjà dans le cache de 1M

l'optimisation de la requête et de l'optimisation de l'insertion sont des choses différentes. afin d'optimiser l'insertion-vous déjà utilisé append nologging - essayez de cache de l'ordre, aussi bien pour gratter un peu plus de temps ALTER SEQUENCE SEQ_RESULT_ID CACHE 1000;
La séquence est déjà dans le cache de 1 million de dollars mais il est encore lent. Plus d'idées?
Le nombre de lignes dans pm et result? Quel est le pourcentage sélectionnez-vous?
h tableau contient 79227256 enregistrements, tandis que la table de résultats contient 24 dossiers. Nous avons la sélection de près de 99% de chaque.
nologging n'est pas un vrai soupçon. Mais cela ne doit pas empêcher la append de travail.

OriginalL'auteur user1928162 | 2013-11-18

  1. 3

    Essayez d'utiliser plus de lier les variables, en particulier là où les boucles imbriquées qui pourrait arriver. J'ai remarqué que vous pouvez l'utiliser dans des cas comme

    CREATE_DT >= :YOUR_DATE instead of CREATE_DT >= sysdate - 60

    Je pense que cela pourrait expliquer pourquoi vous avez 180 millions d'exécutions dans la partie la plus basse de votre plan d'exécution, même si l'autre partie de la requête de mise à jour est toujours à 8 millions de dollars de votre 79 millions de dollars.

    merci. après cela, l'exécution a été, à seulement 11 minutes!
    Je ne comprends pas pourquoi l'ajout d'une liaison variable permettrait d'améliorer cette requête. En général lier les variables moins de l'information à l'optimiseur, et conduire à la pire des estimations. J'ai le sentiment qu'il y est quelque chose d'autre se passe ici. Il serait intéressant de voir la dbms_xplan.display_cursor pour les deux versions de la requête.
    incroyable, a travaillé pour moi aussi. Remplacé le tout avec de lier les variables. merci

    OriginalL'auteur Avias

  2. 5

    Améliorer les statistiques. Le nombre estimé de lignes est de 1, mais le nombre réel de lignes est de plus de 7 millions de dollars et de comptage. Cela provoque le plan d'exécution d'utiliser une boucle imbriquée au lieu d'une jointure de hachage. Une boucle imbriquée fonctionne mieux pour les petites quantités de données et d'une jointure de hachage fonctionne mieux pour les grandes quantités de données. La fixation peut être aussi simple que d'assurer les tableaux ont exactes, à jour des statistiques. Ceci peut être fait par la collecte de statistiques avec les paramètres par défaut, par exemple: exec dbms_stats.gather_table_stats('SIRS_UATC1', 'TBL_RECON_PM');.

    Si ce n'est pas d'améliorer l'estimation de cardinalité essayez d'utiliser un échantillonnage dynamique de l'indice, telles que /*+ dynamic_sampling(5) */. Pour un long temps d'exécution d'une requête, il vaut la peine de passer un peu de temps supplémentaire à l'avant données d'échantillonnage si elle conduit à un meilleur plan.

    Utilisation déclaration de parallélisme au niveau de la place de l'objet au niveau de parallélisme. C'est probablement l'erreur la plus commune avec le parallèle SQL. Si vous utilisez l'objet parallélisme au niveau de l'indicateur doit faire référence à la alias de l'objet. Depuis 11gR2 il n'y a pas besoin de s'inquiéter sur la spécification des objets. Cette déclaration a seulement besoin d'un seul conseil: INSERT /*+ PARALLEL(16) APPEND */.... Notez que NOLOGGING n'est pas un vrai soupçon.

    Ne Énoncé niveau prallelism travail sur insérer avec la liste des colonnes comme INSERT /*+ parallel(16) */ tab (col1,col2) SELECT a1,b2 from tab2; ?? Il ne semble pas fonctionner pour moi. D'un autre côté quand je ne paralléliser le SELECT ainsi, il ne fonctionne pas.
    Je l'ai vu plusieurs fois. Voici un exemple, bien qu'il n'est pas directement exécutable, car SQL Violon n'a pas assez de fonctionnalités: sqlfiddle.com/#!4/be5ddf/2
    Intéressant. Je ne suis pas certain de savoir pourquoi il ne fonctionne pas pour moi alors. Tous les autres Parallèles Lmd fonctionnent bien, sauf quand il y a une liste de colonnes.
    Même avec le même exemple dans mon SQL Violon? Que peut faire une question intéressante.

    OriginalL'auteur Jon Heller

  3. 0

    Je vois 2 gros problèmes:

    1 - indice parallèle (à sélectionner) NE fonctionnent PAS, parce qu'il doit être comme ça +PARALLÈLE(T1,16)

    2 - SÉLECTIONNEZ NE PAS optimale, il serait mieux si éviter d'expression PAS DANS

    OriginalL'auteur usergray