web-dev-qa-db-fra.com

Interroger les données avant une transaction de validation

Ma compréhension est que, dans une fenêtre de MS SQL Server Management Studio, après avoir effectué une "transaction de début" et avoir ensuite apporté des modifications comme ajouter des données à une table, vous pouvez uniquement interroger cette table et ces modifications à partir de la même fenêtre jusqu'à ce que vous fassiez une "commit transaction".

Existe-t-il un moyen d'effectuer une requête à partir d'une autre source avant d'effectuer la "transaction de validation"?

Spécifique à mon objectif actuel et pour ajouter un peu de contexte. Je fais quelques requêtes SQL à partir d'Excel Power Query. J'aimerais vraiment pouvoir faire ces requêtes avant la "transaction de validation" afin que je puisse faire une analyse et déterminer si je dois faire une restauration au lieu d'une validation.

sql-serverssmstransaction
10
Alex

Oui, c'est possible si vous changez le niveau d'isolement des transactions pour la session (c'est ce que vous appelez "fenêtre" dans SSMS) qui interroge les données modifiées. Souvent, ce n'est pas une si bonne idée, car vous pourriez en avoir résultats inattendus . Considérez attentivement les effets secondaires. Je n'ai aucune idée s'il est possible de modifier le niveau d'isolement de transacion dans Excel Power Query.

Par exemple, l'ensemble de requêtes suivant insère des données et affiche la mise à jour correctement même sans validation/restauration.

-- Session 1
begin tran tx_test;
-- Assume the Test table exists and insert is okay
insert dbo.Test(datadate, content) values (getdate(), 'transaction');
select * from Test; -- Shows the new data
-- After select, one would execute one of the following
-- commit;
-- rollback;

Pendant ce temps, la deuxième session exécute une sélection qui ne semble rien faire:

-- Session 2
-- This waits for uncommitted transaction
-- and returns results after 1st session commits/rollbacks
select * from Test;

Créez une troisième session et modifiez son niveau d'isolement:

-- Session 3
set transaction isolation level read uncommitted;
-- This reads the inserted data from the 1st session, even before commit
select * from Test;
14
vonPryz

Dans le cadre des meilleures pratiques, les transactions doivent être aussi courtes que possible et n'attendez jamais l'interaction de l'utilisateur; chaque fois que vous effectuez un type de modification de données ou de schéma dans une transaction, cela verrouille les objets ou les lignes qui ont été touchés/modifiés, ce qui fait attendre les requêtes des autres utilisateurs. C'est à son tour peut créer des effets de chaîne qui peuvent arrêter votre serveur de base de données.

Dans le scénario que vous décrivez, je vous recommanderais plutôt de faire une copie des données pour séparer les tables de simulation où vous pourrez apporter vos modifications et revoir les résultats. Une fois satisfait des résultats, utilisez une transaction pour fusionner les données de cette table dans la ou les tables d'origine.

3
Daniel Hutmacher