8
votes

Rollback et planification dans la base de données?

Si nous utilisons l'horodatage de commande pour le contrôle de la concurrence dans la planification suivante:

Entrez la description de l'image ici

Mon TA dit T2, T3, T5 est exécuté et T4, T1 est Rollback. Je pense que c'est faux. Tout expert pourrait nous aider? (C'est-à-dire que dans ce calendrier, lequel du rendement de la transaction et lequel est fait?

mise à jour: Toutes les transactions après tout travail, commet.


13 commentaires

Je ne comprends pas la question que vous demandez. Montrez-vous une série d'opérations qui se produisent en une seule session? Ou de nombreuses sessions? Si de nombreuses sessions, combien? Quel niveau d'isolement de transaction?


@Justinca Il y a une certaine transaction en une seule session (je pense). Niveau d'isolement non mentionné! C'est okey à considérer en général?


Pourquoi ces transactions seraient-elles annulées? Que sont x et y?


@DavidalDridge: Je pense que X et Y sont des objets de base de données nécessitant une sorte de contrôle pour un accès simultané. Pour cette question particulière, je ne pense pas que cela fait mal de penser à X et Y comme des ensembles distincts de rangées.


Pourquoi votre TA Omit-il T1?


T5 est mentionné deux fois.


En fait, de quelle manière le "temps" se passe-t-il, de gauche à droite ou de haut en bas?


Top to Bas @davidaldridge


OK - seulement pensé à cela après avoir écrit une réponse!


Parce que vous avez marqué Oracle, est-ce supposé qu'une opération "écriture (n)" fait un engagement immédiatement? Ou l'ordre d'une validation n'est-il pas défini?


@RUUDVAN Spécifiquement c'est une ancienne question du concours, peut-être qu'il n'y a pas de supposion pour Oracle, et peut-être commettre chaque écriture :) Ce n'est pas mentionné


Je pense que cela est déroutant de beaucoup de gens parce que vous l'avez marqué comme oracle. Il existe une dizaine d'approches en informatique pour le contrôle de la concurrence et différentes bases de données utilisent différentes stratégies. Dès la première ligne de votre question, il semble que vous soyez intéressé par Contrôle de la concurrence basé sur l'horodatage . Est-ce exact? Peut-être que nous pouvons vous aider davantage avec cela. Mais je recommanderais de sortir l'étiquette Oracle car il ne me semble pas que cela convient ici.


Oui je veux dire votre lien @ruudvan désolé si ce n'est pas clair


5 Réponses :


4
votes

Bien en général, et par défaut, les lecteurs ne bloquent pas les écrivains et les écrivains ne bloquent pas les lecteurs.

La première session à écrire à une ligne détient une serrure dessus jusqu'à ce qu'un commit ou une restauration soit émise, et d'autres sessions seront bloquées par ce verrou de l'écriture, mais peut toujours la lire.

basé sur ce

  • t1 peut écrire (y) car aucune autre session n'a écrit à Y, puis détient une serrure sur Y
  • t2 jamais écrit, alors n'est jamais bloqué.
  • T3 tente d'écrire (y) après T1, il est bloqué.
  • T4 écrit (x) et la lecture de X de T5 n'affecte pas cela.
  • tentative de T5 d'écrire Y est bloquée par le verrou qui tient T1.

    Rien de tout cela ne devrait être provoqué par une restauration, cependant, et suppose qu'aucun engagement explicit ou les retournements ne sont émis.


1 commentaires

Eh bien, c'est délicat de comprendre la question, mais les principes sont très simples ici. Les lecteurs ne bloquent pas les écrivains, les écrivains ne bloquent pas les lecteurs, l'écriture prend une serrure exclusive.



1
votes

Le point est "Les lecteurs ne bloquent pas les écrivains et les écrivains ne bloquent pas les lecteurs", comme indiqué par @davidaldridge. La transaction 3 attendrait ensuite la transacion 1 et la transaction 5 attendrait ensuite la transaction 1 et 3. Ils peuvent soit attendre pendant une longue période, attendre que n secondes ou ne pas attendre du tout, en fonction du jeu de paramètres pour la DB. . À Oracle c'est comme ça que ça marche.

Les gars, puisqu'il s'agit d'une question de concours, je suppose la logique et suivrai.

C'est beaucoup sur l'interprétation et essayant de coller à ce qui est donné. Les informations données ici sont les suivantes: horodatage de commande pour le contrôle de la concurrence. Ensuite, il nous donne: T1, T2 jusqu'à T5. J'assume alors T1 vient en premier, puis T2 et ainsi de suite, car les transactions ont toujours été sérialisées: l'une après l'autre, sur la base de leur horodatage. Je pense que pour que l'on puisse supposer que "T5 Lire (x)" est la première transaction juste à cause de la manière dont le texte est disposé est d'ajouter des informations qui ne sont tout simplement pas là. Il dit que l'horodatage commande et vous donne T1, T2 ... Logic dit que l'un vient après l'autre. Aucun transaction ne revient pas, ils attendent simplement, non seulement parce qu'une transaction pouvait contenir une serrure tandis que d'autres essaient également d'obtenir le verrou qui sera automatiquement un retour. Dans Oracle Transactions Seulement automatiquement la restauration en cas d'impasse. Comme cela ne semble pas être le cas, il n'y a pas de rollback.


1 commentaires

lequel un retour et lequel n'est pas?



1
votes

Je pense que vous confondez tout le monde ici avec l'étiquette Oracle. Je pense que vous voulez que le contrôle de la simultanéité basée sur horodatage algorithme basé sur la première ligne de votre question qui est un algorithme assez commun pour le contrôle de la concurrence dans la théorie des sciences informatiques.

Plus facile à comprendre le lien . P>

En outre, votre utilisation de Rollback n'est pas correcte, car les transactions ne sont pas roulées, mais redémarrées. (Cela arrive aussi dans Oracle) P>

L'algorithme fonctionne comme celui-ci - P>

Chaque fois qu'une transaction commence, elle reçoit un horodatage. C'est donc nous peut dire à quel ordre que les transactions sont censées être appliquées dans. Ainsi donné deux transactions qui affectent le même objet, le transaction qui a le temps précédent est censé être appliqué avant l'autre. Cependant, si la mauvaise transaction est en fait présenté en premier, il est avorté et doit être redémarré p> blockQuote>

basé sur cela, donnons à nos transactions un horodatage comme t = 1,2,3,4,5 ... p>

  • T5 commence à t = 1. li>
  • T2 commence à t = 2. li>
  • T1 commence à t = 3. li>
  • T3 commence à t = 4. li>
  • T4 commence à t = 5 li>
  • T5 a une autre opération à T = 6, mais son horodatage est toujours T = 1 parce que l'horodatage est attribué en fonction de la démarche de la transaction. LI> ul>

    Passer sur, P>

    Chaque objet de la base de données a un horodatage lu, qui est mis à jour chaque fois que les données de l'objet sont lues et une horodatage écrite, qui est mise à jour chaque fois que les données de l'objet sont modifiées. P> blockquote>

    au début X et Y ont leur horodatage de lecture et d'écriture comme 0. p>

    Une demande de lecture est traitée de la manière suivante: p>

      If TS < R-ts(x) or TS < W-ts(x) then
       reject write request
       else
       execute transaction
       Set W-ts(x) to TS. 
    


0 commentaires

1
votes

Au lieu d'essayer de l'expliquer dans mes propres mots, voici un lien MSDN utile qui vous montre la transaction de restauration et comment cela fonctionne.

https://msdn.microsoft.com /en-us/library/ms181299.aspx?f=255&msppperror=-2147217396

Tous les problèmes n'hésitez pas à me demander.


0 commentaires

1
votes

En ce qui concerne les serrures, cela dépend du niveau d'isolation défini sur votre DB.

Microsoft sur les niveaux d'isolation:

Niveaux d'isolement des transactions Contrôle: Si les verrous sont prises lorsque des données sont lues et quel type de serrures sont demandés. Combien de temps les serrures de lecture sont tenues. Si une opération de lecture des lignes de référence modifiée par une autre transaction: Blocs jusqu'à ce que la serrure exclusive de la ligne soit libérée. Récupère la version engagée de la ligne qui existait au moment de la déclaration ou de la transaction. Lit la modification de données non engagée.

Source: https://technet.microsoft .com / fr-US / bibliothèque / ms189122 (v = SQL.105) .aspx

E.g. Si votre niveau d'isolement est réglé sur Repetable Read:

"Spécifie que les instructions ne peuvent pas lire des données modifiées mais non encore engagées par d'autres transactions et qu'aucune autre transaction ne peut modifier les données qui ont été lues par la transaction en cours jusqu'à ce que la transaction en cours soit terminée. < / strong> "

Source: https://technet.microsoft .com / fr-US / bibliothèque / ms173763 (v = SQL.105) .aspx


0 commentaires