Qu'est-ce que le recommandé de la taille des lots pour SqlBulkCopy?

Qu'est-ce que le recommandé de la taille des lots pour SqlBulkCopy? Je suis à la recherche d'une formule générale, je peux l'utiliser comme un point de départ pour l'optimisation des performances.

InformationsquelleAutor Jonathan Allen | 2009-04-22
  1. 88

    J'ai un utilitaire d'importation assis sur le même serveur physique que mon instance de SQL Server. En utilisant une mesure IDataReader, il analyse les fichiers plats et les insère dans une base de données à l'aide de SQLBulkCopy. Un fichier typique est d'environ 6M de lignes éligibles, avec une moyenne de 5 colonnes de décimales et de textes courts, d'environ 30 octets par ligne.

    Compte tenu de ce scénario, j'ai trouvé un lot de 5 000 à être le meilleur compromis de la vitesse et de la consommation de mémoire. J'ai commencé avec 500 et expérimenté avec les plus grands. J'ai trouvé 5000 à 2,5 x plus rapide, en moyenne, de 500. L'insertion de 6 millions de lignes prend environ 30 secondes avec une taille de lot de 5 000 et environ 80 secondes avec une taille de lot de 500.

    De 10 000 n'a pas été sensiblement plus rapide. Le déplacement jusqu'à 50 000 amélioration de la vitesse de quelques points de pourcentage, mais ça ne vaut pas l'augmentation de la charge sur le serveur. Au-dessus de 50.000 ont montré aucune amélioration dans la vitesse.

    Ce n'est pas une formule, mais c'est un autre point de données pour vous à utiliser.

    • Une chose à considérer est de savoir si la table est vide et des index. Dans ces cas, vous pourriez voulez télécharger tout dans un lot comme indiqué ici: technet.microsoft.com/en-us/library/ms177445(v=sql.105).aspx "Si vous en vrac importer des données dans une table vide avec index et que vous spécifiez la taille du lot, la table n'est pas vide après le premier lot. Dès le second lot, les données sont entièrement connecté. Pour des tables indexées vides, envisagez d'effectuer l'importation en bloc en un seul lot."
    • SqlBulkCopy flux de données à partir de la source (par exemple, le DataTable) de Sql, de sorte que "l'augmentation de la charge sur le serveur", a-t-elle sur une grande taille de lot? (par exemple de 50 000)
    InformationsquelleAutor Alric
  2. 27

    C'est un problème que j'ai également passé du temps dans la recherche. Je suis à la recherche pour optimiser l'importation de gros fichiers CSV (16 GO, plus de 65 millions de disques, et la croissance) dans une base de données SQL Server 2005 à l'aide d'une application console C# (.Net 2.0). Comme Jeremy a déjà souligné, vous aurez besoin de faire quelques modifications de votre situation particulière, mais je vous conseillerais d'avoir un premier lot de 500, et les valeurs d'essai à la fois au-dessus et au-dessous.

    J'ai reçu la recommandation de tester des valeurs entre 100 et 1000 pour la taille des lots à partir de ce MSDN post sur le forum, et était sceptique. Mais quand je l'ai testé pour des tailles de lots entre 100 et 10 000, j'ai trouvé que 500 est la valeur optimale pour mon application. La valeur de plus de 500 pour SqlBulkCopy.BatchSize est également recommandé ici.

    D'optimiser davantage votre SqlBulkCopy opération, découvrez cette MSDN conseils; je trouve que l'utilisation de SqlBulkCopyOptions.TableLock contribue à réduire le temps de chargement.

    • Je pense l'exécution de la copie en bloc de commande dans le serveur lui-même serait probablement plus rapide.
    InformationsquelleAutor MagicAndi
  3. 14

    Comme d'autres l'ont dit, cela dépend de votre environnement spécialement la ligne du volume et de la latence du réseau.

    Personnellement, j'aimerais commencer avec un réglage sur la BatchSize propriété de 1000 lignes et voir comment cela fonctionne. Si cela fonctionne, puis je continuer à doubler le nombre de lignes (par exemple à 2000, 4000, etc.) jusqu'à ce que je obtenir un délai d'attente.

    Sinon, si un délai d'attente se produit à 1000, puis je baisse le nombre de lignes de moitié (par exemple, 500) jusqu'à ce que cela fonctionne.

    Dans chaque cas, je continue à doubler (en cas de succès) ou la diminution de moitié (si échec), la différence entre chacune des deux dernières tentatives de tailles de lots en attendant de trouver un sweet spot.

    L'autre facteur à considérer est combien de temps faut-il pour copier un unique lot de lignes. Délais d'attente va se produire si le lot de lignes copiées dépasse la BulkCopyTimeout propriété qui par défaut est de 30 secondes. Vous pouvez essayer de doubler la BulkCopyTimeout propriété à 60 secondes. Cela permet une plus longue période de temps pour un plus grand ensemble de lots de lignes à copier. Par exemple, un lot de 50 000 lignes peut prendre environ 40 secondes, à peine dépasser les 30 secondes limite de temps pour qu'il se cogner jusqu'à 60 secondes peut améliorer les performances.

    InformationsquelleAutor Ray Vega
  4. 4

    Tout ceci dépend de votre mise en œuvre.

    Ce genre de vitesse pouvez-vous attendre de votre réseau?
    Êtes-vous à l'aide dans les Formulaires ou ASP.Net?
    Avez-vous besoin d'alerter l'utilisateur de progrès?
    Quelle est la taille totale du travail?

    Dans mon expérience dans la gestion de copie en bloc sans une taille de lot spécifié sera la cause de problèmes de délai d'attente. Je voudrais commencer avec quelque chose comme 1000 enregistrements et de faire quelques ajustements à partir de là.

    • Vitesse: Variable, WebForms: Oui, ASP.NET: Oui, les grandes Tables: Oui, tables Étroites, Oui. Des milliers de lignes: oui. Des Millions de lignes: oui. Si vous pouvez penser à un scénario, je suis probablement le faire.
    • Je dois tenir ma précédente réponse. Je ne pense pas qu'il y a une balle d'argent.
    InformationsquelleAutor Jeremy