J'ai le code suivant (plus ou moins) d'importer n'importe où à partir de 500 000 à 4.000.000 lignes: Comme vous pouvez le constater, j'effectue un commit toutes les 100 lignes, et je même ajouté du sommeil. J'avais l'habitude de courir le comité une seule fois toutes les 25.000 lignes, et je n'ai utilisé aucun sommeil. Cependant, à un moment donné, j'ai découvert que j'avais manqué des enregistrements. J'ai commencé à jouer avec ces paramètres (sommeil et nombre de lignes). De cette façon, j'ai réduit le nombre d'enregistrements manquants de 50 000 à environ un 100. Mais je manque toujours des disques! Où vont-ils? Je sais que le SQL est ok, car je reçois immédiatement des erreurs lorsque quelque chose ne va pas là-bas. Je pensais pouvoir empiler beaucoup d'inserts lors d'une transaction? Pourrait appeler Begintransaction d'être un problème? Mise à jour: La prime s'est terminée et je devais l'attribuer. Merci à tous pour vos réponses. Ou des conseils effectivement, comme aucun de vous n'a répondu à ma question. Je ne demandais pas de solution de contournement, même si vos suggestions sont très appréciées. La réponse La générosité a été récompensée pour l'avoir reçu car elle est arrivée la plus proche de répondre à ma question. Malheureusement, il n'a pas fonctionné. Pour l'instant, j'utilise l'importation de Bulk CSV, qui fonctionne bien, mais si quelqu'un a des autres conseils pour la correction de ce problème, faites-le-moi savoir. Comme je préfère utiliser ma méthode d'origine.
4 Réponses :
J'ai déjà eu ce problème. Pour moi, je devais faire un "Nocount défini sur" avant les insertions car SQL Server essayait de me renvoyer "une ligne ajoutée" pour chaque insertion et la file d'attente de messages informatique était pleine et il a juste arrêté d'insérer des données, sans renvoyer des erreurs!
Vous devez donc essayer de faire un «Nocount défini sur» avant les inserts. Je parie que ça va résoudre votre problème.
Cela sonne totalement plausible! Va essayer aujourd'hui!
Avant chaque instruction insert ou une seule fois?
Ne résout pas malheureusement. '14: 57: 10 [119] | Résultat pour la table: Total Lines: 466792Sucifulful: 466789 Échec: 2 '-> Sélectionnez Compte (*) à partir du tableau = 441925
Avez-vous envisagé d'utiliser des Sprates au lieu d'insérer des déclarations? Écrire un nombre quelconque d'enregistrements séquentiellement - un à la fois est une sorte de perte de temps / d'énergie. C'est tout aussi vite que cela devrait être.
Êtes-vous sûr de ne pas utiliser l'insert en vrac ou XML à la place pour insérer plusieurs lignes à la fois?
C'est ce que je fais en ce moment comme solution de contournement. Mais je pense que c'est juste affreux que les archives disparaissent sans aucun préavis ...
@saratis,
Avez-vous envisagé de créer une SPROC simple qui effectue l'action souhaitée en utilisant une fusion? La fusion consomme des frais généraux considérables, cependant, j'ai toujours connu qu'il s'agissait d'un moyen très fiable de synchroniser des enregistrements d'une source de données «maître» à une source de données dépendante. P>
Je suis de la philosophie qui La base de données doit contrôler la manière dont les données sont utilisées et que le code doit contrôler lorsque la base de données fait ce qu'elle fait. Ce que je préfère faire, c'est garder tout ce qui touche des données dans un PROP stocké et appelle les PROC stockés avec code lorsque certaines conditions / événements se produisent. Cependant, votre situation pourrait être suffisamment unique pour que ce ne soit pas exactement une meilleure pratique. P>
L'extrait de code ci-dessous vient de Microsoft comme exemple de la manière d'accomplir une fusion: P>
MERGE Production.UnitMeasure AS target
USING (SELECT @UnitMeasureCode, @Name) AS source (UnitMeasureCode, Name)
ON (target.UnitMeasureCode = source.UnitMeasureCode)
WHEN MATCHED THEN
UPDATE SET Name = source.Name
WHEN NOT MATCHED THEN
INSERT (UnitMeasureCode, Name)
VALUES (source.UnitMeasureCode, source.Name)
OUTPUT deleted.*, $action, inserted.* INTO #MyTempTable;
C'est bien, mais je ne pense pas que cela s'applique à l'importation d'un fichier CSV ou que je me trompe?
Je m'excuse, j'ai échoué à voir dans votre poste original que vous importaiez de CSV. Ce lien pourrait offrir une solution. sqlserverpedia.com/blog / SQL-Server-Bloggers / ... Sélectionnez le CSV dans une expression de table commune puis faites la fusion. Je vais mettre à jour ma réponse pour inclure ce lien aussi.
Vous utilisez dormir () 0,15 secondes pour retarder l'exécution, cependant, question: Que se passe-t-il si l'insert prenne plus de 0,15 seconde? Le script à revenir en arrière et que la table peut être bloquée à cause de la validation précédente.
Essayez ensuite une approche de plusieurs insertions en une seule exécution dans la base de données. Essayez quelque chose comme ceci: pour y parvenir, faites: puis exécuté! < / p>
Exécution du code sans commence et empiler toutes les requêtes d'insertion dans une transaction entraîne la disparition d'environ 40 000 enregistrements ...
Si je répète cette boucle sans transactions, cela fonctionne très bien. Aucun enregistrement perdu ...
Le problème n'est pas causé par le PDO. Ça c'est sûr.
Id Essayez ceci msdn.microsoft.com/en-us/library/ms188365.aspx comme il y a beaucoup de données là-bas
Vous voulez dire Importer un fichier CSV directement dans SQL? Cela signifierait que je devrais lire le fichier CSV, nettoyez-le, écrivez-le à un autre CSV et insérez-le dans de DB. Je pourrais faire ça, mais cela ne se sent pas très efficace.
Êtes-vous certain que votre analyseur de CSV chez vous n'est pas le problème? Si vous simplifiez le problème d'insérer le tableau ("A $ i", "B $ i" "," C $ I ") pour chaque gamme I $ I dans
(0, 50000) et supprimez tout le Code problématique (couchages,Essayez .. attraper et commits intermédiaires), pouvez-vous toujours reproduire le problème? Si oui, pouvez-vous créer un lien vers un complet exemple script ?Exceptions possibles à partir de
$ pdo-> commit (); et$ pdo-> begintransaction (); ne sont pas pris avec ce code, si je le lis correctement.Phi: Comme indiqué, lorsque je laisse la transaction, tout est lent mais bien, pas d'enregistrements manquants, donc aucun problème avec mon analyseur CSV. VYE: Quelles exceptions? Je pensais que ces exceptions augmenteraient alors que j'exécute la requête. En outre, lorsque je ralentis les choses, je perds moins d'enregistrements, des erreurs si non capturées dans SQL ne sont pas le problème.
Le script dans
$ SSQL manque les valeursmots-clés. Est-ce que ce mot manque également du script de votre code de travail?¿Engage et BeginSactioan revient-il toujours vrai? ¿Les enregistrements manquants sont corrélatifs?