Mise à jour d'une table avec des millions d'enregistrements, cela fait 4 jours

Je suis en train de mettre à jour une table avec des millions d'enregistrements, cela fait 4 jours et la requête est toujours en cours d'exécution.

J'ai vérifié que le moniteur d'activité montre que la requête est en cours d'exécution.

Dans le journal des événements, il n'y a aucune erreur.

En termes de performances:

• Tempdb dans le disque A (850 Go d'espace libre)
• fichier de base de données sur le disque B (750 Go d'espace libre)
• 16 Go de RAM

Veuillez me suggérer que dois-je faire?

La requête

UPDATE
    dbo.table1
SET 
    costPercentage = ISNULL(t2.PaymentIndex, 1.0),
    t2.TopUp_Amt = (ISNULL(t2.PaymentIndex, 1.0) - 1.0)
    * ISNULL(dbo.table1.Initial_Tariff_Amt, 0.00),
    Total_Tariff_Inc_t2 = ISNULL(t2.PaymentIndex, 1.0)
    * ISNULL(dbo.table1.Initial_Tariff_Amt, 0.00)
FROM
    dbo.table2 t2
WHERE
    LEFT(dbo.test1.procodet, 3) = LEFT(t2.ProviderCode, 3) COLLATE database_default 

Il y a un détail intéressant à cette requête que je n'ai pas repéré au début. Grâce à la réponse de Fabricio Araujo, je le vois maintenant: vous accédez à deux tables. Je n'ai jamais vu ce genre d'utilisation de la déclaration de mise à jour auparavant et je ne conseille pas de l'utiliser. Je vous recommande d'utiliser la syntaxe de jointure plus intuitive selon la réponse de Fabricio.

La cause probable est que la jointure entre les deux tables produit un nombre extrême de lignes. Cela peut se produire si l' LEFT(col, 3)expression produit des valeurs en double. S'il produit 10 doublons, cela se traduira par 100000x100000 = 10000000000 lignes dans le résultat de la jointure.

Je ne pense pas que l'indexation joue un rôle ici. SQL Server peut résoudre cette jointure non indexée très bien avec un hachage ou une jointure de fusion. Ne prend pas 4 jours.

L'autre cause probable serait une sous-estimation de la cardinalité des entrées ou des sorties de jointure. SQL Server a peut-être choisi une jointure en boucle.

Comme il s'agit toujours de spéculations, je vous recommande de publier le plan de requête qui éclairera ce problème.

Cette requête vous oblige à analyser chaque ligne du tableau car

• Je suppose que procodet ou ProviderCode ne sont pas indexés
• Même s'ils ont été indexés, vous avez un LEFT qui est une fonction sur un prédicat WHERE
• Et vous avez aussi COLLATE qui est effectivement une fonction sur un prédicat WHERE

"une fonction sur un prédicat WHERE" signifie que les index ne seront pas utilisés

Si vous le regroupez (par exemple sur UPDATE TOP (10000) ... ET costPercentage IS NULL), vous avez besoin d'un index sur costPercentage et cela suppose que vous le définissez.

Les seules solutions que je vois sont

• remplir une nouvelle table par lots, en fonction, par exemple, de la clé primaire
• créer des colonnes indexées et calculées pour masquer les expressions LEFT et COLLATE, puis exécuter la mise à jour

Tout d'abord, changez la requête en:

UPDATE t1
SET 
    costPercentage = ISNULL(t2.PaymentIndex, 1.0),
    t2.TopUp_Amt = (ISNULL(t2.PaymentIndex, 1.0) - 1.0)
    * ISNULL(dbo.table1.Initial_Tariff_Amt, 0.00),
    Total_Tariff_Inc_t2 = ISNULL(t2.PaymentIndex, 1.0)
    * ISNULL(dbo.table1.Initial_Tariff_Amt, 0.00)
FROM
  dbo.table1 t1
  inner join dbo.table2 t2
    on LEFT(t1.procodet, 3) = LEFT(t2.ProviderCode, 3) COLLATE database_default 

Comme indiqué par le premier post de Jeff Moden dans cette discussion , votre requête est très similaire à celle qu'il a mise en garde contre "l'effet Halloween".

Après cela, ces expressions LEFT doivent être indexées. La réponse de gbn vous donne des indications sur la façon de procéder.