J'essaie de lire une table à partir d'un serveur Sybase, de traiter les lignes et de produire les résultats à une autre table. (Ci-dessous est mon code)
Le code récupère la table assez rapide et processus également rapide (obtenez-vous à la partie où il envoie dans les 30 secondes). Mais quand je courais exécuté, il est assis là pendant 20 minutes avant la fin de la fin (FYI, j'ai une table que je teste avec 8400 rangées).
Y a-t-il un moyen plus efficace de le faire? Je suis nécessaire sur la manière dont je peux recevoir ou envoyer les requêtes (je peux créer une nouvelle table, mettre à jour une table, etc.) - je ne sais tout simplement pas pourquoi cela est si lent (je suis sûr que les données <1 MB et je suis sûr qu'il ne prend pas le serveur SQL 20 minutes pour analyser 8400 rangées). Toutes idées?
Note: La raison pour laquelle c'est vraiment mauvais pour moi, c'est que je dois analyser une table avec des rangées de 1,2 mm (cette table que je travaille avec maintenant est une table d'essai avec 8400 rangées)
4 Réponses :
J'ai eu ce même problème, finalement compris que je n'étais pas aussi capable de trouver la bonne explication nulle part.
La réponse est que pour des inserts simples non conditionnés Un exemple de ce qui fonctionne, essayez ce qui suit qui crée une seule instruction insertion en tant que système préparé (mais le même concept qu'un objet d'instruction nécessiterait) et résout le problème de l'exécution lente: < Pré> xxx .executeBatch () ne doit pas être utilisé. Ce que le mode de lot fait consiste à faire beaucoup d'instructions individuelles «insert dans le tableau X ...» et c'est pourquoi il fonctionne lentement. Toutefois, si les déclarations d'insertion étaient plus complexes, éventuellement avec des conditions qui affectent chaque ligne différemment, cela peut nécessiter des déclarations d'insertion individuelles et une exécution par lots serait en fait utile.
Cela met fin à des heures de lutte. Merci!
Utilisation de RewriteBatchedStatifs = true dans la chaîne d'URL de connexion fait la même chose!
Sur les bases de données prenant en charge les inserts de lot, le pilote JDBC a été écrit pour prendre en charge la fonctionnalité des RDBMS, le pilote exploite le protocole de fil sous-jacent pour exécuter une déclaration préparée contre la connexion avec le tampon de données connecté contenant toutes les lignes fournies. La SQL individuelle individuelle est une cassette pour la base de données + des combinaisons de pilotes qui ne prennent pas en charge les inserts de lot.
Il y a un nombre maximum de paramètres pouvant être générés de cette manière, cependant. Par exemple, lorsque j'ai essayé cette approche à l'aide de SQL Server, je ne pouvais définir que des paramètres jusqu'à 2100 valeurs.
Travailler efficacement avec des lots Vous devez éteindre efficacement l'option Autocommit et allumez-la après avoir exécuté le lot (ou à l'optimisation de la méthode Connection.commit ())
connection.setAutoCommit(false);
while(rs.next())
{
.....
ps.addBatch();
}
int[] results = ps.executeBatch();
connection.setAutoCommit(true);
Puis-je simplement vous remercier!
Ajouter EG: JDBC: MySQL: // Server: 3306 / db_name? RéécritébatchedStatifs = True
Il a amélioré mes performances de plus de 15 fois
C'était plus de 30 fois pour moi. Merci beaucoup
Il existe une solution commerciale de progressez DataDirect pour traduire des lots JDBC dans le protocole de charge en vrac natif de la base de données pour améliorer considérablement les performances. C'est très populaire avec SQL Server car il ne nécessite pas de BCP. Je suis employé par ce vendeur et écrit un blog sur Comment encadrer les lots JDBC .