| Tuning of the update statement in oracle [message #689106] |
Sat, 23 September 2023 21:57  |
 |
chavva.kiru@gmail.com
Messages: 23
Registered: April 2012
Location: hyderabad
|
Junior Member |
|
|
Dear All,
I have a update statement as below where iam using a same select statement in both update and where exists clause.
It is taking so much of time and indexes are already present.Please let me know how to tune this to work better.
UPDATE APP_XXX.USAGE_DATA_YYYY AA
SET
AA.CUSTOMER_NO=(SELECT CUSTOMER_NO FROM
(
SELECT
X.CTN
,X.CUSTOMER_NO
,( ROW_NUMBER() OVER (PARTITION BY X.CTN ORDER BY date_diff asc) ) QUALIFY
FROM
(SELECT
A.CTN
,A.CUSTOMER_NO
,(B.SBSCRBR_START_DT- A.SBSCRBR_STAT_DT) date_diff
FROM
(Select * from APP_XXX.XXX_LOOKUP_YYYY WHERE CUSTOMER_NO>0) A
INNER JOIN
(select * from APP_XXX.USAGE_DATA_YYYY WHERE CUSTOMER_NO<0) B
ON
A.CTN = B.SBSCRBR_NO
--WHERE
-- A.CUSTOMER_NO > 0
--AND
-- B.CUSTOMER_NO < 0
)X )WHERE
QUALIFY = 1 AND AA.CUSTOMER_NO <0
AND AA.SBSCRBR_NO=CTN),MOD_BY_BATCH_ID =BATCHID
WHERE EXISTS
(SELECT 1 FROM
(
SELECT
X.CTN
,X.CUSTOMER_NO
,( ROW_NUMBER() OVER (PARTITION BY X.CTN ORDER BY date_diff asc) ) QUALIFY
FROM
(SELECT
A.CTN
,A.CUSTOMER_NO
,(B.SBSCRBR_START_DT-A.SBSCRBR_STAT_DT) date_diff
FROM
(SELECT * FROM APP_XXX.XXX_LOOKUP_YYYY WHERE CUSTOMER_NO>0) A
INNER JOIN
(SELECT * FROM APP_XXX.USAGE_DATA_YYYY WHERE CUSTOMER_NO<0) B
ON
A.CTN = B.SBSCRBR_NO
--WHERE
-- A.CUSTOMER_NO > 0
--AND
-- B.CUSTOMER_NO < 0
)X )WHERE
QUALIFY = 1
AND AA.CUSTOMER_NO <0
AND AA.SBSCRBR_NO=CTN);
|
|
|
|
| Re: Tuning of the update statement in oracle [message #689107 is a reply to message #689106] |
Sun, 24 September 2023 00:28  |
 |
Michel Cadot
Messages: 68647
Registered: March 2007
Location: Nanterre, France, http://...
|
Senior Member
Account Moderator |
|
|
Michel Cadot wrote on Wed, 13 May 2020 21:19From one of your previous topics:
Michel Cadot wrote on Tue, 22 October 2019 21:34
From your previous topics:
Michel Cadot wrote on Tue, 01 October 2019 20:09
From your previous topic:
Michel Cadot wrote on Wed, 25 September 2019 08:04
From your previous topics:
Michel Cadot wrote on Wed, 25 September 2019 08:03Michel Cadot wrote on Thu, 06 October 2016 07:30
From your previous topic:
Michel Cadot wrote on Mon, 19 January 2015 07:22
From your previous topic:
Michel Cadot wrote on Thu, 16 August 2012 16:20From your previous topics:
BlackSwan wrote on Wed, 11 April 2012 16:43Please read and follow the forum guidelines, to enable us to help you:
http://www.orafaq.com/forum/t/88153/0/
BlackSwan wrote on Wed, 11 April 2012 20:29...
READ & FOLLOW the Posting Guidelines! http://www.orafaq.com/forum/t/88153/0/
With any SQL question, Post a working Test case: create table and insert statements along with the result you want with these data then we will be able work with your table and data. Explain with words and sentences the rules that lead to this result.
Before, Please read OraFAQ Forum Guide and How to use [code] tags and make your code easier to read.
Make sure that lines of code do not exceed 80 characters when you format.
Indent the code, use code tags and align the columns in result.
Use the "Preview Message" button to verify.
Also always post your Oracle version, with 4 decimals.
Regards
Michel
In addition, Barbara helped you so much in your previous topics providing you codes and examples and you did never feedback and thank her.
Are you the kind of parasite we saw too much in these days?
Or are you a valuable person who deserves to be helped?
|
|
|
|
| Re: Tuning of the update statement in oracle [message #689108 is a reply to message #689106] |
Sun, 24 September 2023 00:56 |
John Watson
Messages: 8931
Registered: January 2010
Location: Global Village
|
Senior Member |
|
|
You cannot expect people to read code that isn't formatted.
Even if it were formatted, the way you are using table aliases makes the code impossible to understand: A, B, X, and so on. Some columns aren't prefixed with an alias at all. You may know what tables mod_by_batch and batchid are in, but I don't.
I see SELECT * in there, a very lazy way to program that will prevent all sorts of optimizations. You should project only the columns you need.
If you fix these basic errors, you may find that the code can then be tuned.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
