Discussion :

[calou_33]

Bonjour,

Lorsque j'insere des données dans ma base je ne commite qu'à la fin de l'insertion de toutes les données pour optimiser mon temps.

Il se peut que j'ai plus d'1 million d'enregistrements à inserer ce qui fait que ma transaction peut rester ouverte en ecriture plus de 12h.
Il n'y a qu'une application (serveur) qui vient écrire dans la base donc laisser une transaction en ecriture ouverte ne me pose pas de probleme car tous les clients ne font que du read only commited et perdre toutes les données ne me pose pas de probleme non plus car si le commit ne se fait pas c'est que théoriquement il y a eu une erreur lors de l'insertion.

Par contre je me demande si au niveau de FB (j'utilise 2.1) cette facon de faire etait optimale? (saturation de je ne sais quoi causé par l'énorme quantité d'enregistrements non commités)

Merci

[qi130]

Il n'y a pas de limite théorique pour ce genre de chose.

Au plus une limite pratique relative à la place occupée par la mémorisation des éléments nécessaires au rollback éventuel.

Naturellement, plus les commits sont espacés, et plus les insertions deviennent lentes.

Il n'y a pas de recette miracle pour déterminer le "pas de commit". Parfois un pas réglé à 5000 ira bien, alors qu'un pas de 100000 marchera mieux dans une autre situation/configuration.

[calou_33]

Bonjour,

Naturellement, plus les commits sont espacés, et plus les insertions deviennent lentes.

Ca c'est etrange car justement j'ai remarqué que moins de fois je commitais et plus rapide etait mes insertions de données.
en fait je fais:

sql:='...'
Startransaction
Prepare
while...
debut
ParamByName('..'):='....'
ExecuteSql
fin
Commit

si je fais un commit dans la boucle while je mets 2 fois plus de temps (ceci testé sur 20000 enregistrements)

[makowski]

Naturellement, plus les commits sont espacés, et plus les insertions deviennent lentes.

pardon ?
c'est quoi cette légende ?

[qi130]

pardon ?
c'est quoi cette légende ?

C'est la légende de la journalisation.