Discussion :

[SlashEne]

Tout d'abord je m'excuse si je post sur le mauvais forum, car je ne veux pas parler du language SQL mais de SQL Server, à la limite entre la programmation et l'administration.

Je dois faire une application qui met a jour une base de donnée SQL de 2 Go,
mon premier réflexe a été de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
TRANSACTION BEGIN maTransaction
executer les script de maj
COMMIT TRANSACTION maTransaction
ou un ROLLBACK TRANSACTION maTransaction

Cependant on me dit qu'il est dangereux de faire ca car ca ferait exploser la base question ressource, et qu'il faudrai mieu faire un BACKUP avant et un RESTORE si s'a s'est mal passé.

Je doute vraiment de cet affirmation qu'en pensez vous ?

je ne peux pas tester ca actuellement, mais a mon sens une transaction est optimisé pour des opérations de ce genre la non ???

(je precise que durant la mise a jour, il n'y a aucun utilisateur de la base)

[ylarvor]

Une transaction doit être la plus courte possible.

Pour plus d'info : A quoi servent les transaction ?

http://sqlpro.developpez.com/cours/sqlaz/techniques/

[vmolines]

Une transaction doit être la plus courte possible.

Pour plus d'info : A quoi servent les transaction ?

http://sqlpro.developpez.com/cours/sqlaz/techniques/

Ce n'est pas pour autant qu'il ne faut pas en faire quand on a un gros lot d'opération qui doit être atomique

[SlashEne]

La transaction permet de définir l'atomicité du traitement considéré.
Un traitement atomique est un traitement qui est considéré comme fonctionnant en tout ou rien : soit toutes les opérations relatives aux traitements sont exécutées, soit elles sont toutes annulées et les données reviennent dans l'état antérieur qui précédait juste la transaction.

C'est justement mon cas, je veux que ces scripts soit executé en tout ou rien.

Une transaction doit être la plus courte possible.

Je suppose que l'on dit ca pour pas nuire au performance du serveur vis a vis des autres clients.
Je precise que lorsque mes scripts sont exécuté aucun client n'utilise la base de donnée.

Apparemment l'execution de ces scripts doivent prendre plusieurs minutes... (de 2 a 30 minute suivant la taille de la base)

J'ai pu testé que sur une petite base de 34 Mo, ca a pris 2 minute, et aucun probleme sur la transaction.
Maintenant mon programme tournera "en vrai" avec des bases de 2 Go.

La personne qui me dit d'utiliser les BACKUP/RESTORE plutot que TRANSACTION/ROLLBACK a peur que d'une facon ou d'une autre il y ai tellement de traitement sur la base de donnée que l'execution de ces scripts soit incroyablement long (a cause de la transaction), et que la transactions prennent incroyablement de ressource sur le disque dur, ou dans la base de donnée.

[ylarvor]

C'est justement mon cas, je veux que ces scripts soit executé en tout ou rien.

pourquoi ?

J'ai pu testé que sur une petite base de 34 Mo, ca a pris 2 minute, et aucun probleme sur la transaction.
Maintenant mon programme tournera "en vrai" avec des bases de 2 Go.

vous n'avez plus qu'a creer une base de test de 2 giga. vous testez!

[SlashEne]

Lors de la mise à jour la base est dans un état non cohérent (ce qui arrivera si un seul script de mise a jour échoue), je ne peux pas me permettre de mettre en péril la base de donnée des clients.

C'est pour cela que la mise a jour est en soit une opération atomique.
Si elle foire il faut que les clients puissent continué à utiliser le logiciel comme il était avant, d'ou l'utilité de la transaction.

vous n'avez plus qu'a creer une base de test de 2 giga. vous testez!

avec des centaines et des centaines de table, je ne peux pas remplir la base de donnée à la main.
Je vais peut être essayé de voir si le client qui possède la base de 2 giga peut m'en donné une copie si personne n'a de réponse.

[SQLpro]

Votre demande est parfaitement justifiée. N'ayez crainte la transaction se passera bien à une seule condition :
QUE VOTRE JOURNAL DE TRANSACTION SOIT BIEN DIMENSIONNÉ.

Par exemple pour ce script il se peut que la transaction fasse quelque 300 Mo de données. Si votre fichier de journal n'a pas été proprement dimensionné ou si votre disque arrive a saturation parce que vous n'avez pas bien dimensionné votre JT et fait de la croissance automatique (ce qui est une abbération), alors vous aurez les pires ennuis.

Enfin pensez qu'une transaction ce n'est pas automatique. En d'autre terme ce n'est pas parce que un seul ordre plante que la transaction est annulée. C'est à vous de tester chaque ordre SQL et de décider s'il faut faire un ROLLBACK.

A +

A +