[SQL Server 2000] Questions élémentaires

Marsh Posté le 20-10-2004 à 00:23:10

Bonjour,

je débute avec SQL Server et j'ai quelques questions

tout d'abord, c'est quoi une transaction active ?

Message édité par jcop le 20-10-2004 à 00:24:54

Reply

Marsh Posté le 20-10-2004 à 00:23:10

Reply

Marsh Posté le 20-10-2004 à 11:47:31

Alors...

Démarrer > Programmes > Microsoft SQL Server > Documentation en ligne

Ensuite, tu cliques sur l'onglet "Recherche".
Tu tapes "transaction active" puis "entrée".

Tu trouves alors par exemple ceci :

Accès aux données relationnelles et modification

Transactions imbriquées
Les transactions explicites peuvent être imbriquées. Cette fonctionnalité est avant tout destinée à la prise en charge des transactions dans les procédures stockées appelées par un processus faisant partie d'une transaction, ou par des processus ne disposant pas de transaction active.

L'exemple suivant illustre cette utilisation des transactions imbriquées. La procédure TransProc exécute sa transaction quel que soit le mode de transaction du processus qui l'exécute. Si TransProc est appelée alors qu'une transaction est active, la transaction imbriquée dans TransProc est en grande partie ignorée, et les instructions INSERT qu'elle contient sont validées ou annulées en fonction de la dernière action effectuée dans la transaction la plus externe. Si TransProc est exécutée par un processus pour lequel aucune transaction n'est en cours, l'instruction COMMIT TRANSACTION qui se trouve à la fin de la procédure déclenche la validation effective des instructions INSERT.

SET QUOTED_IDENTIFIER OFF
GO
SET NOCOUNT OFF
GO
USE pubs
GO
CREATE TABLE TestTrans(Cola INT PRIMARY KEY,
Colb CHAR(3) NOT NULL)
GO
CREATE PROCEDURE TransProc @PriKey INT, @CharCol CHAR(3) AS
BEGIN TRANSACTION InProc
INSERT INTO TestTrans VALUES (@PriKey, @CharCol)
INSERT INTO TestTrans VALUES (@PriKey + 1, @CharCol)
COMMIT TRANSACTION InProc
GO
/* Start a transaction and execute TransProc */
BEGIN TRANSACTION OutOfProc
GO
EXEC TransProc 1, 'aaa'
GO
/* Roll back the outer transaction, this will
roll back TransProc's nested transaction */
ROLLBACK TRANSACTION OutOfProc
GO
EXECUTE TransProc 3,'bbb'
GO
/* The following SELECT statement shows only rows 3 and 4 are
still in the table. This indicates that the commit
of the inner transaction from the first EXECUTE statement of
TransProc was overridden by the subsequent rollback. */
SELECT * FROM TestTrans
GO

La validation des transactions internes est ignorée par Microsoft® SQL Server. La transaction est validée ou annulée en fonction de la dernière action effectuée par la transaction la plus externe. Si la transaction externe est validée, les transactions imbriquées dans celle-ci sont également validées. Si la transaction externe est annulée, toutes les transactions internes sont également annulées, qu'elles aient été validées individuellement ou non.

Chaque appel à COMMIT TRANSACTION ou COMMIT WORK s'applique à la dernière instruction BEGIN TRANSACTION exécutée. Si les instructions BEGIN TRANSACTION sont imbriquées, une instruction COMMIT s'applique uniquement à la dernière transaction imbriquée, qui est la transaction la plus interne. Même si une instruction COMMIT TRANSACTION nom_transaction d'une transaction imbriquée fait référence à la transaction externe, seule la transaction interne est validée.

Le paramètre nom_transaction d'une instruction ROLLBACK TRANSACTION ne doit pas faire référence aux transactions internes d'un groupe de transactions nommées imbriquées. Nom_de_référence ne peut faire référence qu'à la transaction la plus externe. Si une instruction ROLLBACK TRANSACTION nom_transaction faisant référence à la transaction externe est exécutée à n'importe quel niveau d'un groupe de transactions imbriquées, toutes les transactions imbriquées sont annulées. Si une instruction ROLLBACK WORK ou ROLLBACK TRANSACTION est exécutée à un niveau d'imbrication quelconque sans que le paramètre nom_transaction soit spécifié, toutes les transactions imbriquées, la plus externe comprise, sont annulées.

La fonction @@TRANCOUNT enregistre le niveau d'imbrication de la transaction en cours. Chaque instruction BEGIN TRANSACTION incrémente la valeur de @@TRANCOUNT d'une unité. Chaque instruction COMMIT TRANSACTION ou COMMIT WORK la décrémente de la même valeur. Une instruction ROLLBACK WORK ou ROLLBACK TRANSACTION pour laquelle aucun nom de transaction n'est spécifié annule toutes les transactions imbriquées et remet @@TRANCOUNT à 0. Une instruction ROLLBACK TRANSACTION dans laquelle le nom de la transaction la plus externe d'un groupe de transactions imbriquées est spécifié annule toutes les transactions imbriquées et remet @@TRANCOUNT à 0. Si vous n'êtes pas sûr qu'une transaction est déjà active, utilisez l'instruction SELECT @@TRANCOUNT pour déterminer si sa valeur est de 1 ou plus. Si la valeur de @@TRANCOUNT est 0, aucune transaction n'est active.

Voir aussi

@@TRANCOUNT

COMMIT WORK

BEGIN TRANSACTION

ROLLBACK TRANSACTION

COMMIT TRANSACTION

ROLLBACK WORK

©1988-2000 Microsoft Corporation. Tous droits réservés.

Tu en déduis que ta question est ridicule : une transaction "active", c'est ni plus ni moins qu'une transaction "en cours". C'est pas un type de transaction, mais simplement le fait qu'elle est commencée, et pas encore terminée.

Reply

Marsh Posté le 23-10-2004 à 15:21:43

ok !

autre question :

toutes les sauvegardes sont consignées dans des tables de la base de données msdb. (entre autres, backupset et backupfile)
Or si je compte faire une sauvegarde des journaux de transaction toutes les 1/2 heures, et ceci tous les jours, ces tables vont devenir un peu trop grosses !!!!!!

Est-ce que ça peut poser problème si on supprime des lignes des tables systèmes backupset et backupfile ?

Reply

Marsh Posté le 24-10-2004 à 16:08:49

autre question :

j'ai lu plusieurs docs sur les indexes, mais j'ai jamais compris comment ça fonctionnait !!!
- je sais que ça permet d'optimiser le traitement de certaines requêtes.
- j'ai entendu dire que ça fonctionnait comme un index dans les bouquins. C'est à dire, chaque mot dans l'index est associé à une ou plusieurs pages du livre.
Or je sais que les clés primaires sont automatiquement indexées !
Du coup je comprends plus rien !!!
A quoi ça sert d'indexer une colonne où tous ses champs sont uniques ?

Reply

Marsh Posté le 25-10-2004 à 13:27:33

jcop a écrit :

ok !

autre question :

toutes les sauvegardes sont consignées dans des tables de la base de données msdb. (entre autres, backupset et backupfile)
Or si je compte faire une sauvegarde des journaux de transaction toutes les 1/2 heures, et ceci tous les jours, ces tables vont devenir un peu trop grosses !!!!!!

Est-ce que ça peut poser problème si on supprime des lignes des tables systèmes backupset et backupfile ?

:heink: Les backups se font dans des fichiers indépendants.
Les journaux des transactions, je doute que ce soit très utile de les enregistrer aussi souvent. Toutes les 4 heures à la limite.

Ceci pour deux raisons :
-> Pendant le backup, la base est down, donc niveau uptime c'est mauvais. Deplus, elle ne peut se lancer que si aucune transaction n'est en cours. Elle attends donc un certain temps en bloquant toute nouvelle demande, puis fini par shooter tout traîtement qui n'a pas terminé. Seulement à la fun du backup elle redonne la main.
Imagine donc que le timeout avant de butter les transactions actives soit de 5 minutes, et que le backup soit de 5 minutes... Alors toutes les 30 minutes, ta base est inutilisable pendant 10 minutes ! Uptime de 66%, c'est maigre...
-> Si ton serveur crash mettons lors d'un gros traîtement à 19h. Ton dernier backup complet date du matin à 1h. Alors tu as :
(19h - 1h) * 2 = 36 backups de ton journal des transactions... Ca veut dire que tu as 36 fichiers à rejouer afin de retrouver un état stable de ta base ! Vu la lenteur de re-jeu d'un journal des transactions, ça veut dire que tu y passes au moins toute la nuit, laissant donc de côté tout traîtement batch qui aurait dû tourner la nuit. Vu le système de transactions de SQL Server, impossible de les faire tourner en pleine journée sans bloquer tous les utilisateurs ni y passer la journée !

Généralement, on fait un backup COMPLET 1 fois par semaine.
Un backup DIFFERENCIEL 1 fois par jour.
Un backup des logs en même temps que le différenciel (au cas où ce dernier foire), et on peut à la limite en re-sheduler un au bout de 12 heure. Il faut savoir que le backup des transactions ne sert absolument à rien : tant que le serveur n'est pas définitivement mort, les transactions sont récupérables même après un restore d'un backup (c'est un peu le but...)

Reply

Marsh Posté le 25-10-2004 à 13:32:44

jcop a écrit :

autre question :

j'ai lu plusieurs docs sur les indexes, mais j'ai jamais compris comment ça fonctionnait !!!
- je sais que ça permet d'optimiser le traitement de certaines requêtes.
- j'ai entendu dire que ça fonctionnait comme un index dans les bouquins. C'est à dire, chaque mot dans l'index est associé à une ou plusieurs pages du livre.
Or je sais que les clés primaires sont automatiquement indexées !
Du coup je comprends plus rien !!!
A quoi ça sert d'indexer une colonne où tous ses champs sont uniques ?

- Elles sont uniques, mais sont-elles dans l'ordre ? NON (sauf dans le cas d'un INDEX CLUSTERED (paramètre par défaut pour une clé, ok...)
- Un index, ça marche comme un arbre (binaire ou non).

Imagine un arbre à 26 dimensions.

Noeud 1 : choix : A, B, C, D, ..., Z
Au noeud 2, tu as les mêmes choix, pour chaque entrée.

Tu cherches la clé "TOTO".

Alors au noeud 1, tu cherches "T", au noeud 2 tu cherches "O", etc.
En 4 lectures de l'index tu as trouvé la ligne correspondant à ta clé, quelque soit le nombre de lignes de ta base.

Dans une base sans index, en cluster, le système va devoir faire une recherche dicotomique (ou similaire). Ben trouver 1 ligne par dicotomie en 4 coups quand t'as 25 000 000 de lignes, bah je t'assure que tu peux chercher dans tes placards le soir en rentrant chez toi, parceque ta femme n'a pas qu'un seul amant...

Reply

Marsh Posté le 09-11-2004 à 02:50:25

ok merci pour les réponses !!!

faire des backup log database ça ne sert à rien ?! ça peut servir si le fichier du journal des transaction devient endommagé, non ?

Citation :

tant que le serveur n'est pas définitivement mort, les transactions sont récupérables

si les transactions sont récupérables, c'est donc que le fichier .ldf n'est pas endommagé ?

sinon t'es sûr que pendant le backup la base est down ?
Dans une doc il est mis : "Vous pouvez sauvegarder une base de données même si elle est en ligne et active"

Reply

Marsh Posté le 09-11-2004 à 10:14:02

La base n'est pas down, mais nécessite un accès exclusif aux éléments backupés. Donc si tu backup une table utilisée, le backup attends que tout le monde se déconnecte de la base (comme si tu fais un "LOCK" dans une requête). Puis fait son boulot, et enfin redonne l'accès.

Pour peu que tu utilises une appli transactionnelle qui fait des transactions de plusieurs minutes, tu peux passer un très long moment avant de pouvoir backuper toutes les tables.

Reply

[SQL Server 2000] Questions élémentaires - Help !

Sujets relatifs:

Leave a Replay