Oracle, comment la déclaration de mise à jour fonctionne

Question

Question 1

Quelqu'un peut-il me dire s'il y a une différence entre les suivantes 2 déclarations de mise à jour:

UPDATE TABA SET COL1 = '123', COL2 = '456' WHERE TABA.PK = 1 
UPDATE TABA SET COL1 = '123' WHERE TABA.PK = 1 

où la valeur d'origine de COL2 = '456'

comment cela affecte le UNDO?

Question 2 Qu'en est-il si je mets à jour un enregistrement dans la table TABA en utilisant ROWTYPE comme l'extrait suivant. comment est la performance, et comment cela affecte l'UNDO?

SampleRT TABA%rowtype 

SELECT * INTO SampleRT FROM TABA WHERE PK = 1; 
SampleRT.COL2 = '111'; 
UPDATE TABA SET ROW = SampleRT WHERE PK = SampleRT.PK; 

grâce

Answer 1

Votre question demandant si 1 UNDO (et Redo) est généré lorsque vous utilisez un UPDATE contre une rangée mais pas en train de changer la valeur?

Quelque chose comme?

update taba set col2='456' where col2='456'; 

Si cela est la question, la réponse est que même si vous mettez à jour une colonne à la même valeur alors UNDO (et Redo) est généré.

(Une exception est lorsque vous mettez à jour une colonne NULL vers NULL - cela ne génère pas de fonction REDO).

Answer 2

Pour Question 1:

Le résultat des deux lignes dans mises à jour pour votre table où PK = 1 et COL2 = '456' est identique. (Autrement dit, chaque ligne aura sa valeur COL1 réglée sur '123'.)

Remarque: il peut y avoir des lignes dans votre tableau avec PK = 1 et COL2 <> '456'. Le résultat des deux déclarations pour ces rangées sera différent. Les deux instructions modifieront COL1, mais seul le premier modifiera la valeur de COL2, le second le laissera inchangé.

Answer 3

Pour la question 1:

Il peut y avoir une différence comme déclencheurs peuvent tirer selon les colonnes sont mises à jour. Même si vous mettez à jour column_a à la même valeur, le déclencheur se déclenchera. L'UNDO ne doit pas être différent car si vous développez ou réduisez la longueur d'une colonne de longueur variable (par exemple VARCHAR ou NUMBER), tous les autres octets de l'enregistrement doivent également être mélangés.

Si les colonnes ne changent pas de taille, alors vous pourriez avoir un avantage à ne pas spécifier la colonne. Vous pouvez probablement le tester en utilisant des requêtes de transaction v $ pour voir l'annulation générée.

Pour la question 2:

Je serais plus préoccupé par la mémoire (surtout si vous collectez en vrac SELECT *) et déclenche le tir de UNDO. Si vous n'avez pas besoin SELECT *, spécifiez les colonnes (par exemple, comme suit)

cursor c_1 is select pk, col1, col2 from taba; 
SampleRT c_1%rowtype; 

SELECT pk, col1, col2 INTO SampleRT FROM TABA WHERE PK = 1; 
SampleRT.COL2 = '111'; 
UPDATE (select pk, col1, col2 from taba) 
SET ROW = SampleRT WHERE PK = SampleRT.PK;