Discussion :

[hitech_tm]

Bonjour,
Je veut savoir que ce qu’il va ce passé si un bloque SQL(Begin transaction) ne ce termine ni avec un commit ni avec un rollback

[SQLpro]

elle se terminera pas un rollback lors de le déconnexion de l'utilisateur. Mais suivant le niveau d'isolation choisit, les verrous posés sur les ressources seront plus ou moins maintenus.

A +

[hitech_tm]

elle se terminera pas un rollback lors de le déconnexion de l'utilisateur. Mais suivant le niveau d'isolation choisit, les verrous posés sur les ressources seront plus ou moins maintenus.

A +

Et si le serveur SQL ce fermé d'une façon anomalie un coupeur d'électricité par exemple que ce qu'il va ce passé?

[serge0934]

seul le commit rendra tes infos "validées".
Si une coupure arrive avant le commit, tes données ne seront pas sauvegardées mais comme t'as dit SQLPro, certains verrous peuvent subsister sur des objets lorsque tu relanceras.
j'ai pas sql serveur sous la main mais je crois que la table système est syslocks; tu peux regarder aussi sysprocesses qui te dira si un process en bloque un autre => cela arrive souvent quand tu as une appli qui a des interfaces utilisateurs et que l'un d'eux kille l'appli car il trouve que la mise a jour est trop longue => un verrou reste sur une table et les autres user ne peuvent plus y accéder en modification.

[SQLpro]

Et si le serveur SQL ce fermé d'une façon anomalie un coupeur d'électricité par exemple que ce qu'il va ce passé?

Lors du redémarrage du serveur les transactions non encore finalisées vont l'être et ceci grâce au journal de transaction.

A +

[serge0934]

Lors du redémarrage du serveur les transactions non encore finalisées vont l'être et ceci grâce au journal de transaction

çà c'est la théorie...

[SQLpro]

C'est heureusement la stricte réalité !!!

Je ne comprends pas votre remarque...

Est-ce de l'humour ou de la méconnaissance ?

A +

[hitech_tm]

Lors du redémarrage du serveur les transactions non encore finalisées vont l'être et ceci grâce au journal de transaction.

A +

Je n'ai pas bien comparé ce que tu veux dire par les transactions pas encore finalisées vont être.
Par exemple si je lance un grand transfert de donnée et au milieu de transfert le serveur ce bloque que ce qu'il va ce passé.
Normalement avant que je lance le commit rien ne va ce changer a ma base de donnée

[SQLpro]

Ce n'est pas tout à fait comme cela que fonctionne les transactions, même si d'un point de vue externe on peut accepter la version que tu en donne.

Néanmoins la finalisation d'une transaction, n'est ni plus ni moins que le report des données modifiées dans la base afin d'assurer l'intégrité de la base.
Si un tel report n'a pas été finalisée, avant même que les utilisateurs ne puisse utiliser la base, celle-ci répercutera les modifications effectuées dans le journal au niveau des espaces de stockage de données.

A +

[serge0934]

C'est heureusement la stricte réalité !!!

Je ne comprends pas votre remarque...

Est-ce de l'humour ou de la méconnaissance ?

Ce n'est ni l'un ni l'autre.
Je ne parle pas de SQL2005 car je n'ai jamais eu le cas.
En revanche, je n'ai jamais vu une base se restaurer ou redémarrer correctement après un plantus violent. Je parle de bases de prod, avec plus de 1000 tables, des ps des tr des jobs (dts ou autres) et qui sont attaquées par au moins une 50 d'users. Pourtant je fais de la base de données de 1986 (21 ans), j'ai commencé a Atlanta (USA) chez Sybase qui n'était alors qu'une petite filiale de Allied.... SQL serveur n'existait même pas...
j'ai travaillé sur des bases SQL serveur (ou sybase) telles que le Washigton mesum Arts (a l'époque site pilote microsoft sous la version 6.5 NT4), Dupont de nemours (4500 serveurs), Air France, France télécom, Corte Ingles, ...
Les DBA ont toujours restauré des backup...
principaux dommages:
Fichiers de transaction corrompus (le ctrl Z du fichier manquant)
lock entre plusieurs threads
taille du journal

voila mon expérience sur le terrain

[SQLpro]

Code :

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

Fichiers de transaction corrompus (le ctrl Z du fichier manquant)

il faut savoir qu'aujourd'hui il n'y a plus de bug connu sous MS SQL Server capable d'endommager les structures de données.

Code :

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

lock entre plusieurs threads

Cela ne peut pas entraîner de dommage aux données, juste l'utilisateur est avertit que sa transaction est annulée et qu'il doit la repasser.

Code :

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

taille du journal

de la même façon, même si le journal sature les transactions sont abandonnées et après avoir libéré de l'espace, le SGBD doit repartir.

Cela dit il faut à la fois une architecture adéquate et les process d'admin qui suivent...

A +