Mise à JOUR ou de FUSION de très grandes tables dans SQL Server

J'ai besoin d'effectuer une mise à jour quotidienne d'un très large (300M dossiers) et de larges TABLE1. La source de données pour les mises à jour se trouve dans une autre table UTABLE qui est de 10% à 25% les lignes de TABLE1 mais est étroite. Les deux tables ont record_id comme clé primaire.

Actuellement, je suis en recréant TABLE1 à l'aide de l'approche suivante:

<!-- language: sql -->
    1) SELECT (required columns) INTO TMP_TABLE1 
    FROM TABLE1 T join UTABLE U on T.record_id=U.record_id  
    2) DROP TABLE TABLE1  
    3) sp_rename 'TMP_TABLE1', 'TABLE1'

Cependant, cela prend près de 40 minutes sur mon serveur (60 GO de RAM pour SQL Server). Je veux atteindre 50% de gain de performance - ce que d'autres options puis-je essayer?

  1. MERGE et UPDATE - quelque chose comme le code ci-dessous fonctionne plus rapidement que pour un très petit UTABLE table pleine taille, tout se bloque: 
    <!-- language: SQL -->
MERGE TABLE1 as target  
USING UTABLE as source  
ON target.record_id = source.record_id   
  WHEN MATCHED THEN   
    UPDATE SET Target.columns=source.columns
  2. J'ai entendu que je peux effectuer un lot de FUSION en utilisant ROWCOUNT - mais je ne pense pas que cela peut être assez rapide pour 300 m à la ligne de la table.
  3. Toute requête SQL conseils qui peuvent vous être utiles?
Pouvez-vous poster le plan de requête?
Salut @chris, plan de requête est très simple: 1 Analyse de la Table TABLE1 2 Analyse de la Table UTABLE, 3 la JOINTURE de HACHAGE 4 FUSIONNER. Première et Dernière étape prennent 90% du temps. Cependant j'ai déjà compris comment répondre à ma question, se référer à ma propre réponse.

OriginalL'auteur Sergio Kozlov | 2011-05-14

  1. 8

    En fait, j'ai découvert des recommandations générales pour de telles requêtes: de l'Idée à l'utilisation de SQL de Fusion ou de mise à Jour est très malin, mais il échoue lorsque nous avons besoin de mettre à jour de nombreux enregistrements (c'est à dire 75M) dans un grand et large table (c'est à dire 240M).

    En regardant le plan de requête de la requête ci-dessous, nous pouvons dire que TABLE SCAN de TABLE1 et final MERGE prennent 90% du temps.

    MERGE TABLE1 as Target  
USING UTABLE as source  
ON Target.record_id = source.record_id   
WHEN MATCHED AND (condition) THEN   
    UPDATE SET Target.columns=source.columns

    Afin d'utiliser de FUSION nous avons besoin de:

    1. Réduire le nombre de lignes, nous avons besoin de mettre à jour correctement et de transmettre cette information à SQL Server. Cela peut être fait en faisant UTABLE de petits ou de préciser les autres condition qui se rétrécit de la partie à être fusionnés.
    2. Assurez-vous que la partie à être fusionnés s'inscrit dans la mémoire sinon requête s'exécute de façon plus lente. Faire TABLE1 deux fois moins réduit mon réel moment de la requête à partir de 11 heures et 40 minutes.

    Comme Mark l'a mentionné, vous pouvez utiliser UPDATE de la syntaxe et de l'utilisation WHERE clause partie étroite à être fusionnés cela donnera le même résultat. Veuillez également éviter l'indexation de TABLE1 que cela va entraîner d'autres travaillent à la reconstruction de l'indice au cours MERGE

    OriginalL'auteur Sergio Kozlov

  2. 6

    D'abord j'aimerais savoir où en est votre goulot d'étranglement est - ce qui est votre CPU chevillé ou d'inactivité? En d'autres termes - est votre IO sous-système de mesure de gérer la charge correctement?

    De recréer l'intégralité de la table, c'est beaucoup de IO charge, pour ne pas mentionner, il va prendre beaucoup d'espace pour avoir la table stockée temporairement deux fois.

    Avez-vous besoin pour effectuer une FUSION de ce que je peux voir une simple mise à jour devrait suffire. Exemple:

    UPDATE
    TABLE1
SET
    ColumnX = UTABLE.ColumnX
    ...
FROM
    TABLE1
INNER JOIN
    UTABLE ON TABLE1.record_id = UTABLE.record_id

    Vous pourriez lot les mises à jour à l'aide du nombre de lignes, mais qui ne sera pas accélérer l'exécution, il va seulement aider à réduire l'ensemble de verrouillage.

    Aussi - quel type d'index sur la table? Il peut être plus rapide pour désactiver l'index avant de le mettre à jour, puis de les reconstruire à partir de zéro par la suite (seulement la non-cluster).

    Salut Marc, merci pour la réponse, je n'ai pas d'indices car le voudrais juste lent de FUSION ou de requêtes de mise à JOUR. Comme pour IO - basé sur la Moyenne de la File d'attente du Disque contre - disque est très occupé et il semble que TABLE1 ne s'intègre pas dans la mémoire. Maintenant, je suis expérimenter de pré-filtrage d'entrée avec CTE et seulement ensuite effectuer la FUSION, je vais répondre à ma propre question avec les résultats.
    +1 Grande réponse. Ne peut pas comprendre pourquoi personne ne upvoted encore.

    OriginalL'auteur Mark S. Rasmussen