RE: Multiple Updates statements Vs. Single large update statement

From: Deas, Scott <Scott.Deas_at_lfg.com>
Date: Fri, 15 May 2015 14:04:32 +0000
Message-ID: <C1FB7BA65B13C542B2CB1CE5DB8F74AF19CF3ED6_at_NC2PWEX501.us.ad.lfg.com>

Nik,

You provided the following examples of the statements:
== BEFORE ==

UPDATE T1 set c2 = $1, c3=$2 WHERE c1=$3; UPDATE T1 set c5 = $1, c7=$2, c8=$3, c11=$4 WHERE c1=$5; UPDATE T1 set c22 = $1, c32=$2 WHERE c1=$3; UPDATE T1 SET C10 = $1 , C12 = $2 , C21 = $3 , C31 = $4 , C41 = $5 , C43 = $6 , C44 = $7 , C45 = $8 , C46 = $9 , C47 = $10 , C48 = $11 , C49 = $12 WHERE C1 = $13

• AFTER == UPDATE T1 set c2 = $1, c3=$2, c5 = $3, c7=$4, c8=$5, c11=$6, c22 = $7, c32=$8, C10 = $9 , C12 = $10 , C21 = $11 , C31 = $12 , C41 = $13 , C43 = $14 , C44 = $15 , C45 = $16 , C46 = $17 , C47 = $18 , C48 = $19 , C49 = $20 WHERE C1 = $21;

Can you provide the plans for the first UPDATE statement in the BEFORE, and then the plan for the new AFTER statement? Is there an index over c1, c2, c3, which would allow your first BEFORE update statement to optimally find the block and cache it before subsequent statements run, whereas your new statement is perhaps not using said index and is instead using a sub-optimal index or table scan? Meaning, are the 13 subsequent update statements benefiting from a good plan that the first statement uses, while your new design does not get this benefit? Thanks,
Scott
Notice of Confidentiality: **This E-mail and any of its attachments may contain Lincoln National Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Lincoln National Corporation family of companies. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. Thank You.**

--
http://www.freelists.org/webpage/oracle-l

Received on Fri May 15 2015 - 16:04:32 CEST