INSÉRER prend plus de 5 heures, lors de l'insertion d'un nombre de lignes supérieur au nombre spécifique

8

Lorsque vous insérez moins de 1 350 000 lignes dans la table, cela prend environ 2 minutes, mais lorsque le nombre de lignes insérées est plus grand, le temps nécessaire pour insérer des données augmente à environ 5 heures.

Le problème n'est pas lié aux requêtes ou aux index, car tout fonctionne correctement depuis longtemps et rien n'a changé dans la structure des requêtes, des tables ou des index.

Le problème est apparu pour la première fois il y a environ 2 semaines et il apparaît plusieurs fois les jours, lorsque le nombre de lignes insérées est supérieur à + -1 350 000. Par exemple, un jour, le nombre de lignes insérées est de 1 200 000 et le processus prend 2 minutes, l'autre jour, le nombre de lignes est de 1 450 000 et il faut 5 à 6 heures pour insérer des données.

J'ai essayé de reconstruire des index, mais cela n'a pas aidé.

sql-server Piotr
la source
3
Quelle est la source de l'insert?
Martin Smith, le
4
Pouvez-vous publier quelle est l' attente associée lorsque l'insertion prend si longtemps?
Kin Shah
4
Nous ne pouvons que deviner à moins que vous ne donniez plus d'informations. Je suppose que l'escalade des verrous se produit. Pouvez-vous suivre les attentes et l'escalade des verrous
Shanky
1
Est-ce la première fois que vous essayez d'insérer 1,3 million d'enregistrements? Faites-vous des transactions? Importation en vrac? Quel type de journalisation faites-vous? Si vous faites des insertions plain-jane, je suis d'accord, essayez de faire les insertions par lots.
SQLburn
2
Comment importez-vous les données (bcp, insertion en bloc, SSIS, fichier de commandes)? D'où (stockage local, lecteur identique / différent, stockage réseau, ..)? Quel est le schéma de la table? Quelle est la commande d'importation? Quel est le plan d'exécution (si c'est du T-SQL simple)?
Marian

Réponses:

14

Je suppose - si vous n'êtes pas réellement bloqué - que vous atteignez un seuil au-dessus duquel le fichier de données (et / ou le fichier journal) doit augmenter, et que votre configuration n'est pas optimisée pour prendre en charge cette croissance. Veiller à ce que:

  1. Le taux de croissance de votre fichier de données est raisonnable et sa taille est fixe (pas%!) Suffisamment grande pour accueillir cette transaction et tout ce qui peut se produire simultanément.
  2. Idem pour le fichier journal.
  3. L'initialisation instantanée des fichiers est activée . Cela aidera à accélérer la croissance des fichiers de données, mais pas les croissances des fichiers journaux souvent plus gênantes.
  4. Vous n'insérez pas 1,35 million de lignes individuelles dans une boucle ou autrement en une seule grosse transaction. Il y a quelque chose à dire pour diviser vos transactions en morceaux .
Aaron Bertrand
la source
1
Aaron est sur place avec ses suggestions, comme la croissance de fichiers sur les données ou les fichiers journaux. Assurez-vous également que le nombre de fichiers journaux virtuels est faible.
Namphibian du
4

Serait-ce un problème de mémoire?

Vous pouvez voir ce genre de comportement si un bloc de données auquel vous devez accéder à plusieurs reprises devient trop volumineux pour la mémoire et que vous obtenez une attaque de disque de l'enfer. Si vous devez parcourir un bloc de données trop volumineux pour la mémoire, vous vous retrouvez avec le tout lu à partir du fichier d'échange pour chaque passage, le pousser au-dessus de cette limite peut entraîner une baisse des performances.

Loren Pechtel
la source
3

Essayez-vous / est-il possible de les diviser en lots plus petits? Lorsque j'ai rencontré un problème similaire, les regrouper par 5.000 (avec GO) a vraiment réduit le temps nécessaire pour terminer une telle tâche.

Alex Szabó
la source