[ASE]Schéma de lock ? DOL ou APL [Résolu]

arona · 05/10/2006, 09h37

On me posait la question DOL ou APL pour des tables et la différence entre les deux.
J'ai expliquer que pour une table ayant essentielemnt (voir que cela) des select qui sont réaliser on peut choisir APL, mais si il y'a des insert, upgrade ou delete qui sont fait aussi il vaut mieux prendre DOL sachant que DOL va prendre plus de ressources matériel. A cela on me répond comment fait'on pour voir la contention sur une table (si contention en IO sur quel table cela se situe ..).
Donc pour DOL et APL est ce que les raisons sont valables ?? y'en a t'il d'autres? Et comment voir quel table fait de la contention en IO ?
Merci à vous pour votre aide.

mpeppler · 05/10/2006, 11h32

Ce n'est pas tant une question de contention d'IO (tous les IO se font par page), mais plutôt une question de contention de lock.

En cas de table APL la page est lockée lorsqu'une ligne dans la page est mise à jour - et si il y a mise à jour de plusieurs indexes cela peut vouloir dire que bon nombre de pages doivent être lockées pour faire l'update.

Dans le cas de la table DOL (et en particulier le "datarows locking"), seul un lock de la ligne qui est mise à jour est nécessaire, et les indexes sont lockés via des "latches" (lock logique de courte durée).

La contention des locks peut se voir avec sp_object_stats, ou dans les tables MDA (par example dans master..monOpenObjectActivity, colonnes LockRequests et LockWaits).

A la louche on peut dire qu'une table sur laquelle il y a beaucoup d'update/insert/delete le mode DOL peut être très bénéfique, alors qu'une table accèdée principalement en lecture peut probablement avantageusement profiter du mode APL.

Michael

arona · 05/10/2006, 11h53

Bon au moins j'ai pas dit de bétises, merci pour la proc stock sur les stats

arona · 05/10/2006, 14h06

Et quels autres avantages ou justifications il peu y'avoir a mettre les tables en DOL ??

fadace · 05/10/2006, 19h00

La réorganisation en ligne
Le delete logique (et son pendant négatif : la réorganisation)
La meilleure concurrence en cas de verrous nombreux
...

arona · 09/10/2006, 16h33

C'est grosso modo ce que j'ai dis merci a vous cdlt

05/10/2006, 09h37	#1
arona Membre habitué Inscription : mars 2006 Messages : 293 Détails du profil Informations forums : Inscription : mars 2006 Messages : 293 Points : 140 Points : 140	[ASE]Schéma de lock ? DOL ou APL On me posait la question DOL ou APL pour des tables et la différence entre les deux. J'ai expliquer que pour une table ayant essentielemnt (voir que cela) des select qui sont réaliser on peut choisir APL, mais si il y'a des insert, upgrade ou delete qui sont fait aussi il vaut mieux prendre DOL sachant que DOL va prendre plus de ressources matériel. A cela on me répond comment fait'on pour voir la contention sur une table (si contention en IO sur quel table cela se situe ..). Donc pour DOL et APL est ce que les raisons sont valables ?? y'en a t'il d'autres? Et comment voir quel table fait de la contention en IO ? Merci à vous pour votre aide.
	00

05/10/2006, 11h32	#2
mpeppler Rédacteur/Modérateur Inscription : janvier 2006 Messages : 1 301 Détails du profil Informations personnelles : Âge : 52 Informations forums : Inscription : janvier 2006 Messages : 1 301 Points : 1 505 Points : 1 505	Ce n'est pas tant une question de contention d'IO (tous les IO se font par page), mais plutôt une question de contention de lock. En cas de table APL la page est lockée lorsqu'une ligne dans la page est mise à jour - et si il y a mise à jour de plusieurs indexes cela peut vouloir dire que bon nombre de pages doivent être lockées pour faire l'update. Dans le cas de la table DOL (et en particulier le "datarows locking"), seul un lock de la ligne qui est mise à jour est nécessaire, et les indexes sont lockés via des "latches" (lock logique de courte durée). La contention des locks peut se voir avec sp_object_stats, ou dans les tables MDA (par example dans master..monOpenObjectActivity, colonnes LockRequests et LockWaits). A la louche on peut dire qu'une table sur laquelle il y a beaucoup d'update/insert/delete le mode DOL peut être très bénéfique, alors qu'une table accèdée principalement en lecture peut probablement avantageusement profiter du mode APL. Michael __________________ Michael Peppler Membre de TeamSybase - www.teamsybase.com "A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson
	00

05/10/2006, 19h00	#5
fadace Rédacteur/Modérateur Fabien Celaia Administrateur de base de données Inscription : octobre 2002 Messages : 3 779 Détails du profil Informations personnelles : Nom : Fabien Celaia Âge : 41 Localisation : Suisse Informations professionnelles : Activité : Administrateur de base de données Secteur : Service public Informations forums : Inscription : octobre 2002 Messages : 3 779 Points : 8 124 Points : 8 124	La réorganisation en ligne Le delete logique (et son pendant négatif : la réorganisation) La meilleure concurrence en cas de verrous nombreux ... __________________ Sr DBA Oracle / Sybase / MS-SQL / DB2 / Informix / Postgresql Administrateur SAP Mes articles Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums !
	00

05/10/2006, 11h53	#3
arona Membre habitué Inscription : mars 2006 Messages : 293 Détails du profil Informations forums : Inscription : mars 2006 Messages : 293 Points : 140 Points : 140	Bon au moins j'ai pas dit de bétises, merci pour la proc stock sur les stats
	00

05/10/2006, 14h06	#4
arona Membre habitué Inscription : mars 2006 Messages : 293 Détails du profil Informations forums : Inscription : mars 2006 Messages : 293 Points : 140 Points : 140	Et quels autres avantages ou justifications il peu y'avoir a mettre les tables en DOL ??
	00

09/10/2006, 16h33	#6
arona Membre habitué Inscription : mars 2006 Messages : 293 Détails du profil Informations forums : Inscription : mars 2006 Messages : 293 Points : 140 Points : 140	C'est grosso modo ce que j'ai dis merci a vous cdlt
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email