Explain plan on Update statement in function

All,
I have an update statement in a function and my explain plan shows:
"Optimizer"     "Cost"     "Cardinality"     "Bytes"
"UPDATE STATEMENT"     "ALL_ROWS"     "2"     "1"     "7"
"UPDATE user.<table_name>"     ""     ""     ""     ""
"INDEX(UNIQUE SCAN) <table_name>.<PK_column_cons>"     "ANALYZED"     "1"     "1"     "7"
Filtering is on index unique column, but cost is 1 what does that mean?
do i need to change my update statement in function?
Any ideas?
Regards,
~ORA

The cost is the optimizer's measure of how much effort it will take to execute the statement. For any statement the optimizer will evaluate a number of execution plans and choose the one with the lowest cost. I wouldn't worry too much about what it actually "means". However if you want to understand this subject in a lot more detail I would recommend the book Cost-Based Oracle Fundamentals by Jonathan Lewis.
For your update statement the optimizer has chosen to access a single row by the primary key index, which is probably good enough, so you should not need to change it.
The only faster way to access the data would be to use the row's ROWID directly. You would need to have fetched this explicitly in a previous SELECT statement, or you could use it implicitly with the WHERE CURRENT OF syntax for a cursor opened with FOR UPDATE.

Similar Messages

Explain plan for update

Hi
I am new to the sql tuning.
When I wrote this below query and generate the explain plan ,It is showing following 3 steps .
1.very row in table employees is read .
2.Rows were updated.
3.Rows were updated.
Why the oracle is doing the update operation 2 times?Why it is showing 3 stesp where as I ma expecting only 2 steps something like below .
1.very row in table employees is read .
2.Rows were updated.
update employees
set salary = 2300
thanks
sri

Hi ,pleaase find below the explain plan generated .
update feed set feed_name = 2300
Plan
1 Every row in the table FI_OPERATIONS.FEED is read.
2 Rows were updated.
3 Rows were updated.

Explain plan, slow update

We have two schemes in our database. One general and one history. When record in general scheme is modified trigger updates record in history scheme and inserts one new row in history scheme. There are indexes on columns that are used in updates(where part :)) and as i can see(using explain plan for) indexes are used. Problem is that when client application fires update it takes too long(6 sec) to be executed. Actually there is very strange behavior, it executes 5 updates in one second then next one takes 6 seconds. Tables have only around 1000 rows. Is there any way to see whole explain plan including trigger execution, when i issue exp plan for update of general scheme i get only exp plan for update - there are no informations about trigger. Also if anybody has some advice I am more than willing to hear :)

You might want to consider enabling a SQL Trace via DBMS_MONITOR for more recent versions or setting the SQL_TRACE parameter in past versions. Once you have the output you can use TKPROF. Once you have the TKPROF report you can try and find the queries that are taking the most time to execute.
Hope that helps!

Update Statement through function

Hi,
I've got the following select statement that is pulling 29 records:
select distinct aqh.quote_number, aqh.quote_header_id,aqh.quote_version, aql.line_number, msi.inventory_item_id, msi.segment1
,aqh.price_list_id, aqh.quote_expiration_date,aql.line_list_price, qpv.operand
from aso_quote_headers_all aqh, aso_quote_lines_all aql,mtl_system_items msi
,qp_list_headers qlh, qp_list_lines qpl, qp_list_lines_v qpv
where aqh.quote_header_id = aql.quote_header_id
and aql.inventory_item_id = msi.inventory_item_id
and aqh.price_list_id = qlh.list_header_id
and qlh.list_header_id = qpl.list_header_id
and qlh.list_header_id = qpv.list_header_id
and qpl.list_line_id = qpv.list_line_id
and msi.inventory_item_id = qpv.product_id
and aqh.quote_number = :quote_number --56530
i need to update the operand = list_line_price, for all the multiple 29 records. for every quote_number and quote_version_no.
i need help in this to write a function with update statement.
Thanks and Regards

Hi,
whenever you have a problem, post a little sample data (CREATE TABLE and INSERT statements) for all the tables, and the results you want from that data. In the case of a DML operation (like UPDATE) the results will be the contents of the changed table after the DML is finished.
MERGE may be easier to use than UPDATE in this case.
Put your existing query in the USING clause. The only columns it needs to include in the SELECT clause are those that identify which rows to update, and the new values (line_list_price in this case). I assume that the table to be updated has a unique key, which I called primary_key in the example below. This can actually be two or more columns, but it can't include the column being updated (operand).
I assume that all the tables and all the conditions in your original query are necessary to get the columns in the SELECT clause. If not, you can simplify the query.
MERGE INTO     qp_list_lines_v     dst
USING     (
     select distinct aql.line_list_price, qpv.primary_key
     from aso_quote_headers_all aqh, aso_quote_lines_all aql,mtl_system_items msi
     ,qp_list_headers qlh, qp_list_lines qpl, qp_list_lines_v qpv
     where aqh.quote_header_id = aql.quote_header_id
     and aql.inventory_item_id = msi.inventory_item_id
     and aqh.price_list_id = qlh.list_header_id
     and qlh.list_header_id = qpl.list_header_id
     and qlh.list_header_id = qpv.list_header_id
     and qpl.list_line_id = qpv.list_line_id
     and msi.inventory_item_id = qpv.product_id
     and aqh.quote_number = :quote_number --56530
     )     src
ON     (src.primary_key     = dst.primary_key)
WHEN MATCHED THEN UPDATE
SET     dst.operand     = src.list_line_price;You can use a MERGE statement like this in a PL/SQL procedure or function. (If you put this in a function, then you can only call the function from PL/SQL; you can't use a function that performs DML in a SQL query.)
As posted above, the statement will use a single, given quote_number. (You mentioned another column, quote_version_number, that does not appear in your original query. It's unclear what you want with that column.)
You can replace the bind variable :quote_number with an argument to the procedure, as Achyut suggested. It will still only work on a single, given quote_number.
If you want it to work on all quote numbers at once, then omit the last condition (the one that references quote_number), or change it to
AND   aqh.quote_number IS NOT NULLdepending on your needs.
If you want more help, post some sample data and the desired results.

Update statement using function

Environment: Win7 and SQL server 2008 R2
Tools: SQL management tool 2008 R2
Problem: I have been trying to update id numbers in the staging table. T-SQL statement updates all id number in the staging table, but what if the we have multiple records for the same person who we are assigning the ID to his/her record. It should generate
one pn_id per ssn regadless if there are several records for the same individual. for example, my code assigns the following id:
Student table (ID, ssn, name, subject, grade, year)
(288258466,192160792 , Sally Johnson, Math, A, 2014 )
(176268917, 192160792, Sally Johnson, Spanish, B+, 2014 )
(900303787, 770616858, Jessica Simpson, Spanish, B, 2014 )
(704099635, 770616858, Jessica Simpson, IT, A, 2014 )
(704099640, 444718562, Douglas Mike, IT, A, 2014 )
(288258450, 31883459, Susan Jesson, IT, A, 2014 )
(176268960, 260518681, Veronica Floris, IT, A, 2014 )
The expected results should be as the following in the staging table
Student table (ID, ssn, name, subject, grade, year)
(288258466,192160792 , Sally Johnson, Math, A, 2014 )
(288258466, 192160792, Sally Johnson, Spanish, B+, 2014 )
(900303787, 770616858, Jessica Simpson, Spanish, B, 2014 )
(900303787, 770616858, Jessica Simpson, IT, A, 2014 )
(704099640, 444718562, Douglas Mike, IT, A, 2014 )
(288258450, 31883459, Susan Jesson, IT, A, 2014 )
(176268960, 260518681, Veronica Floris, IT, A, 2014 )
My code:
UPDATE a
SET pn_id = (Select dbo.gen_id())
from [dbo].[Staging_Table] a
where SSN in (Select SSN from [dbo].[staging_Table]
group by SSN having count(SSN) > 1)
GO
I also tried the following code but no success
;with cte
As
Select * , ROW_NUMBER() Over(Partition BY ssn Order by ssn) As MyCount
from dbo.Staging_Table
Select * into #a from cte where MyCount=1
UPDATE a
SET pn_id = (Select dbo.fn_gen_id())
from staging_table a
Full join #a b on a.ssn = b.ssn
Drop table #a
please help.

I ran some tests and Sandra is correct, you don't always get the same value for all occurrences of the same SSN.
After thinking about this, I think I understand why this happens.
With functions, SQL is allowed to assume that multiple calls to a function in a single command with the same parameter values always return the same result. That's why functions cannot use side-effecting functions and is not allowed to make changes
to any table except table variables declared in the function.
And SQL is allowed to rearrange the processing of a command in any manner it believes is most efficient as long as it returns the same result. So even though the query I gave says first get a set of distinct SSN's and then calls the function only once
for each SSN, it is valid for SQL to instead call the function once for each row in the original table since this function has no parameters and is therefore should return the same value on each call. But since the function being called apparently (we've
not seen the code of the function) returns different values on different calls, the same SSN could be assigned different values, but SQL would still be working correctly.
Note that it would also be valid for SQL to notice that this function has no parameters and therefore should return the same value every time it is called within the same command and so just call the function once per execution of the command. This
would mean that every SSN would get the same ID. As far as I can determine currently SQL does not do that but a different version in the future with a different optimizer might.
Tom

Will a explain plan consider a function in a select statement.

Hi gurus,
I have a question regarding explain plan.
I ran a query, which returns me explain plan with multiple CPU costs around 300K.
now i use a function, and the number of lines displayed in explain plan reduces from 12 to 8 lines.
What i dont understand is.. Is the explain plan considering the function in the select statement ?
ex.
explain plan for
select column1,
         column2,
         function(value1)
from case
where case_no = 1will a explain plan consider the functions in a select statement ?
Thank you.

What i dont understand is.. Is the explain plan considering the function in the select statement ?Maybe there are tweaks which reveal more information from the explain plan, but a straightforward way won't necessarily expose any function call:
SQL> create or replace function get_dname (i_deptno integer)
   return varchar2
as
   l_dname   dept.dname%type;
begin
   select   dname
     into   l_dname
     from   dept
    where   deptno = i_deptno;
   return l_dname;
end get_dname;
Function created.
SQL> explain plan
   for
      select   ename, deptno, get_dname (deptno) dname
        from   emp
       where   deptno = 10
Explain complete.
SQL> select   * from table (dbms_xplan.display ())
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     5 |    45 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP |     5 |    45 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("DEPTNO"=10)
13 rows selected.
SQL> truncate table plan_table
Table truncated.
SQL> explain plan
   for
      select   ename, deptno
        from   emp
       where   deptno = 10
Explain complete.
SQL> select   * from table (dbms_xplan.display ())
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     5 |    45 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP |     5 |    45 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("DEPTNO"=10)
13 rows selected.

Problems with explain plan and statement

Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AM

tobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

SQL Update statement taking too long..

Hi All,
I have a simple update statement that goes through a table of 95000 rows that is taking too long to update; here are the details:
Oracle Version: 11.2.0.1 64bit
OS: Windows 2008 64bit
desc temp_person;
Name                                                                                Null?    Type
PERSON_ID                                                                           NOT NULL NUMBER(10)
DISTRICT_ID                                                                     NOT NULL NUMBER(10)
FIRST_NAME                                                                                   VARCHAR2(60)
MIDDLE_NAME                                                                                  VARCHAR2(60)
LAST_NAME                                                                                    VARCHAR2(60)
BIRTH_DATE                                                                                   DATE
SIN                                                                                          VARCHAR2(11)
PARTY_ID                                                                                     NUMBER(10)
ACTIVE_STATUS                                                                       NOT NULL VARCHAR2(1)
TAXABLE_FLAG                                                                                 VARCHAR2(1)
CPP_EXEMPT                                                                                   VARCHAR2(1)
EVENT_ID                                                                            NOT NULL NUMBER(10)
USER_INFO_ID                                                                                 NUMBER(10)
TIMESTAMP                                                                           NOT NULL DATE
CREATE INDEX tmp_rs_PERSON_ED ON temp_person (PERSON_ID,DISTRICT_ID) TABLESPACE D_INDEX;
Index created.
ANALYZE INDEX tmp_PERSON_ED COMPUTE STATISTICS;
Index analyzed.
explain plan for update temp_person
2 set first_name = (select trim(f_name)
3                    from ext_names_csv
4                               where temp_person.PERSON_ID=ext_names_csv.p_id
5                               and   temp_person.DISTRICT_ID=ext_names_csv.ed_id);
Explained.
@?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 3786226716
| Id | Operation                   | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT            |                | 82095 | 4649K| 2052K (4)| 06:50:31 |
|   1 | UPDATE                     | TEMP_PERSON    |       |       |            |          |
|   2 |   TABLE ACCESS FULL         | TEMP_PERSON    | 82095 | 4649K|   191   (1)| 00:00:03 |
|* 3 |   EXTERNAL TABLE ACCESS FULL| EXT_NAMES_CSV |     1 |   178 |    24   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - filter("EXT_NAMES_CSV"."P_ID"=:B1 AND "EXT_NAMES_CSV"."ED_ID"=:B2)
Note
   - dynamic sampling used for this statement (level=2)
19 rows selected.By the looks of it the update is going to take 6 hrs!!!
ext_names_csv is an external table that have the same number of rows as the PERSON table.
ROHO@rohof> desc ext_names_csv
Name                                                                                Null?    Type
P_ID                                                                                         NUMBER
ED_ID                                                                                        NUMBER
F_NAME                                                                                       VARCHAR2(300)
L_NAME                                                                                       VARCHAR2(300)Anyone can help diagnose this please.
Thanks
Edited by: rsar001 on Feb 11, 2011 9:10 PM

Thank you all for the great ideas, you have been extremely helpful. Here is what we did and were able to resolve the query.
We started with Etbin's idea to create a table from the ext table so that we can index and reference easier than an external table, so we did the following:
SQL> create table ext_person as select P_ID,ED_ID,trim(F_NAME) fst_name,trim(L_NAME) lst_name from EXT_NAMES_CSV;
Table created.
SQL> desc ext_person
Name                                                                                Null?    Type
P_ID                                                                                         NUMBER
ED_ID                                                                                        NUMBER
FST_NAME                                                                                     VARCHAR2(300)
LST_NAME                                                                                     VARCHAR2(300)
SQL> select count(*) from ext_person;
COUNT(*)
     93383
SQL> CREATE INDEX EXT_PERSON_ED ON ext_person (P_ID,ED_ID) TABLESPACE D_INDEX;
Index created.
SQL> exec dbms_stats.gather_index_stats(ownname=>'APPD', indname=>'EXT_PERSON_ED',partname=> NULL , estimate_percent=> 30 );
PL/SQL procedure successfully completed.We had a look at the plan with the original SQL query that we had:
SQL> explain plan for update temp_person
2 set first_name = (select fst_name
3                    from ext_person
4                               where temp_person.PERSON_ID=ext_person.p_id
5                               and   temp_person.DISTRICT_ID=ext_person.ed_id);
Explained.
SQL> @?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 1236196514
| Id | Operation                    | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT             |                | 93383 | 1550K|   186K (50)| 00:37:24 |
|   1 | UPDATE                      | TEMP_PERSON    |       |       |            |          |
|   2 |   TABLE ACCESS FULL          | TEMP_PERSON    | 93383 | 1550K|   191   (1)| 00:00:03 |
|   3 |   TABLE ACCESS BY INDEX ROWID| EXTT_PERSON    |     9 | 1602 |     1   (0)| 00:00:01 |
|* 4 |    INDEX RANGE SCAN          | EXT_PERSON_ED |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("EXT_PERSON"."P_ID"=:B1 AND "RS_PERSON"."ED_ID"=:B2)
Note
   - dynamic sampling used for this statement (level=2)
20 rows selected.As you can see the time has dropped to 37min (from 6 hrs). Then we decided to change the SQL query and use donisback's suggestion (using MERGE); we explained the plan for teh new query and here is the results:
SQL> explain plan for MERGE INTO temp_person t
2 USING (SELECT fst_name ,p_id,ed_id
3 FROM ext_person) ext
4 ON (ext.p_id=t.person_id AND ext.ed_id=t.district_id)
5 WHEN MATCHED THEN
6 UPDATE set t.first_name=ext.fst_name;
Explained.
SQL> @?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 2192307910
| Id | Operation            | Name         | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | MERGE STATEMENT      |              | 92307 |    14M|       | 1417   (1)| 00:00:17 |
|   1 | MERGE               | TEMP_PERSON |       |       |       |            |          |
|   2 |   VIEW               |              |       |       |       |            |          |
|* 3 |    HASH JOIN         |              | 92307 |    20M| 6384K| 1417   (1)| 00:00:17 |
|   4 |     TABLE ACCESS FULL| TEMP_PERSON | 93383 | 5289K|       |   192   (2)| 00:00:03 |
|   5 |     TABLE ACCESS FULL| EXT_PERSON   | 92307 |    15M|       |    85   (2)| 00:00:02 |
Predicate Information (identified by operation id):
   3 - access("P_ID"="T"."PERSON_ID" AND "ED_ID"="T"."DISTRICT_ID")
Note
   - dynamic sampling used for this statement (level=2)
21 rows selected.As you can see, the update now takes 00:00:17 to run (need to say more?) :)
Thank you all for your ideas that helped us get to the solution.
Much appreciated.
Thanks

Explain plans for PL/SQL code?

Hi!
I am pulling SQL statements (select, insert, update, delete, etc.) from PL/SQL code and producing explain plans. Some of the delete statements have "WHERE CURRENT OF" in them which produces an ORA-3001 error (feature not implemented) error. How can I do an explain plan of these statements? Can I replace "WHERE CURRENT OF" with "=" to get a plan? How far off will the plan be? Any suggestions, ideas, etc. greatfully appreciated!
This is Oracle 9.2.0.4/5 on AIX if it makes a difference.
Thanks!
Dave Venus

WHERE CURRENT OF shouldn't be a problem. Here above an example on 9.2.0.4 on AIX5.2 :
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
SQL> create table TBL_USER_PROFILE_CATEGORY
2 as
3 select 654 id_category, 1103 id_user from dual union all
4 select 654 id_category, 1104 id_user from dual union all
5 select 18 id_category, 1103 id_user from dual union all
6 select 629 id_category, 1103 id_user from dual union all
7 select 110 id_category, 1103 id_user from dual union all
8 select 110 id_category, 1104 id_user from dual union all
9 select 18 id_category, 1104 id_user from dual union all
10 select 37 id_category, 1103 id_user from dual union all
11 select 24 id_category, 1103 id_user from dual union all
12 select 7   id_category, 104 id_user from dual union all
13 select 37 id_category, 1104 id_user from dual union all
14 select 22 id_category, 1103 id_user from dual union all
15 select 22 id_category, 1104 id_user from dual union all
16 select 25 id_category, 1104 id_user from dual union all
17 select 25 id_category, 1103 id_user from dual ;
Table created.
SQL>
SQL> alter table TBL_USER_PROFILE_CATEGORY add primary key (id_category, id_use
Table altered.
SQL>
SQL> CREATE OR REPLACE
2 PROCEDURE P$UPDATE_TBL_USER_PROFILE_CAT(p_id_cat_old IN NUMBER) AS
3    p_id_category number;
4    p_id_user     number;
5    cursor mycur is select id_category, id_user
6                    from TBL_USER_PROFILE_CATEGORY
7                    where id_category = p_id_cat_old
8                    for update of id_category;
9 BEGIN
10    open mycur;
11    LOOP
12       FETCH mycur INTO p_id_category, p_id_user;
13       EXIT WHEN mycur%NOTFOUND;
14       BEGIN
15 DELETE FROM TBL_USER_PROFILE_CATEGORY
16 WHERE CURRENT OF mycur;
17       END;
18     END LOOP;
19     CLOSE mycur;
20     COMMIT;
21 EXCEPTION WHEN OTHERS THEN rollback;
22 END;
23 /
Procedure created.
SQL>
SQL> exec P$UPDATE_TBL_USER_PROFILE_CAT(654)
PL/SQL procedure successfully completed.
SQL> select * from TBL_USER_PROFILE_CATEGORY;
ID_CATEGORY    ID_USER
         18       1103
        629       1103
        110       1103
        110       1104
         18       1104
         37       1103
         24       1103
          7        104
         37       1104
         22       1103
         22       1104
         25       1104
         25       1103
13 rows selected.
SQL> Please, paste here what's your code...
Nicolas.

Explain plan changing after partition exchange

I currently have a data warehouse where I use partition exchange to refresh the data. I'm finding that after a partition exchange of exactly the same data. explain plan changes.
database 11.2.0.2
To demonstrate what I'm doing I simplified the steps.
first I gather stats on the table that will be exchanged and run explain plan
exec dbms_stats.gather_table_stats( ownname=> 'IDW_TARGET', tabname=> 'PROGRAM_DIM' );
Select
FROM IDW_TARGET.ITD_MONTHLY_SUMMARY_FACT A,
IDW_TARGET.GL_PERIOD_DIM B,
IDW_TARGET.PROGRAM_DIM C,
IDW_TARGET.RPT_ENTITY_DIM D
WHERE ASST_SEC_CONCISE_NAME = 'abc'
AND A.GL_PERIOD_KEY = B.KEY
AND A.PROGRAM_KEY = C.KEY
AND A.RPT_ENTITY_KEY = D.KEY
AND B.PERIOD_YEAR >= 2006;
** uses FTS on fact table and runs in 20 seconds. **
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 25M| 71G| 47105 (1)| 00:09:26 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 25M| 71G| 47105 (1)| 00:09:26 | | | Q1,03 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 25M| 71G| 47105 (1)| 00:09:26 | | | Q1,03 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 5 | PX RECEIVE | | 4551 | 1773K| 103 (0)| 00:00:02 | | | Q1,03 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 4551 | 1773K| 103 (0)| 00:00:02 | | | | S->P | BROADCAST |
| 7 | PARTITION RANGE SINGLE | | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
| 8 | TABLE ACCESS FULL | RPT_ENTITY_DIM | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
|* 9 | HASH JOIN | | 25M| 61G| 46999 (1)| 00:09:24 | | | Q1,03 | PCWP | |
| 10 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 11 | PX RECEIVE | | 184 | 35696 | 5 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10001 | 184 | 35696 | 5 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 13 | PARTITION RANGE SINGLE | | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 14 | TABLE ACCESS FULL | GL_PERIOD_DIM | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 15 | HASH JOIN | | 25M| 57G| 46992 (1)| 00:09:24 | | | Q1,03 | PCWP | |
| 16 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 17 | PX RECEIVE | | 4085 | 6829K| 1334 (1)| 00:00:17 | | | Q1,03 | PCWP | |
| 18 | PX SEND BROADCAST | :TQ10002 | 4085 | 6829K| 1334 (1)| 00:00:17 | | | | S->P | BROADCAST |
| 19 | PARTITION RANGE SINGLE| | 4085 | 6829K| 1334 (1)| 00:00:17 | 1 | 1 | | | |
|* 20 | TABLE ACCESS FULL | PROGRAM_DIM | 4085 | 6829K| 1334 (1)| 00:00:17 | 1 | 1 | | | |
| 21 | PX BLOCK ITERATOR | | 71M| 45G| 45650 (1)| 00:09:08 | 1 | LAST | Q1,03 | PCWC | |
| 22 | TABLE ACCESS FULL | ITD_MONTHLY_SUMMARY_FACT | 71M| 45G| 45650 (1)| 00:09:08 | 1 | 141 | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
3 - access("A"."RPT_ENTITY_KEY"="D"."KEY")
9 - access("A"."GL_PERIOD_KEY"="B"."KEY")
14 - filter("B"."PERIOD_YEAR">=2006)
15 - access("A"."PROGRAM_KEY"="C"."KEY")
20 - filter("ASST_SEC_CONCISE_NAME"='abc'')
drop table PELPROGRAMDIMALLDATA; -- Start fresh here and drop the partition that will be exchanged
create table PELPROGRAMDIMALLDATA as select * from PROGRAM_DIM; -- going to use exact same data for partition exchange (only one parition)
alter table PELPROGRAMDIMALLDATA add constraint CON_342 unique ("VALUE" ) using index ;
alter table PELPROGRAMDIMALLDATA add constraint CON_343 primary key ("KEY" ) using index ;
exec dbms_stats.gather_table_stats(ownname=>'IDW_TARGET', tabname=>'PELPROGRAMDIMALLDATA');
alter table PROGRAM_DIM exchange partition ALL_DATA with table PELPROGRAMDIMALLDATA excluding indexes;
** rebuild indexes **
** explain plan for same statement uses nested loop**
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 2637K| 7514M| 33428 (1)| 00:06:42 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 2637K| 7514M| 33428 (1)| 00:06:42 | | | Q1,03 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 2637K| 7514M| 33428 (1)| 00:06:42 | | | Q1,03 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 5 | PX RECEIVE | | 4551 | 1773K| 103 (0)| 00:00:02 | | | Q1,03 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 4551 | 1773K| 103 (0)| 00:00:02 | | | | S->P | BROADCAST |
| 7 | PARTITION RANGE SINGLE | | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
| 8 | TABLE ACCESS FULL | RPT_ENTITY_DIM | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
|* 9 | HASH JOIN | | 2637K| 6511M| 33324 (1)| 00:06:40 | | | Q1,03 | PCWP | |
| 10 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 11 | PX RECEIVE | | 184 | 35696 | 5 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10001 | 184 | 35696 | 5 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 13 | PARTITION RANGE SINGLE | | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 14 | TABLE ACCESS FULL | GL_PERIOD_DIM | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
| 15 | NESTED LOOPS | | 2642K| 6035M| 33318 (1)| 00:06:40 | | | Q1,03 | PCWP | |
| 16 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 17 | PX RECEIVE | | | | | | | | Q1,03 | PCWP | |
| 18 | PX SEND ROUND-ROBIN | :TQ10002 | | | | | | | | S->P | RND-ROBIN |
| 19 | PARTITION RANGE SINGLE | | 420 | 702K| 220 (0)| 00:00:03 | 1 | 1 | | | |
| 20 | TABLE ACCESS BY LOCAL INDEX ROWID| PROGRAM_DIM | 420 | 702K| 220 (0)| 00:00:03 | 1 | 1 | | | |
|* 21 | INDEX RANGE SCAN | PROGRAM_DIM_IX20 | 420 | | 3 (0)| 00:00:01 | 1 | 1 | | | |
| 22 | PARTITION RANGE ALL | | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | 9 | Q1,03 | PCWP | |
| 23 | PARTITION LIST ALL | | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | LAST | Q1,03 | PCWP | |
| 24 | TABLE ACCESS BY LOCAL INDEX ROWID | ITD_MONTHLY_SUMMARY_FACT | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | 141 | Q1,03 | PCWP | |
| 25 | BITMAP CONVERSION TO ROWIDS | | | | | | | | Q1,03 | PCWP | |
|* 26 | BITMAP INDEX SINGLE VALUE | ITD_MONTHLY_SUMMARY_SK09 | | | | | 1 | 141 | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
3 - access("A"."RPT_ENTITY_KEY"="D"."KEY")
9 - access("A"."GL_PERIOD_KEY"="B"."KEY")
14 - filter("B"."PERIOD_YEAR">=2006)
21 - access("ASST_SEC_CONCISE_NAME"='abc')
26 - access("A"."PROGRAM_KEY"="C"."KEY")
exec dbms_stats.gather_table_stats( ownname=> 'IDW_TARGET', tabname=> 'PROGRAM_DIM' );
** explain plan for same statement uses full table scan**
see first explain plan
Since the stats were not gathered after the partition exchange I would imagine that they would still be used.
Edited by: user12198207 on Feb 7, 2012 8:13 AM
Edited by: user12198207 on Feb 7, 2012 9:47 AM

Locking stats did not make any difference. Also, I deleted the stats at the global level leaving just partition stats and it continued to use the nested loop which takes 15+ minutes instead of 20 seconds with the FTS.
In my original situation it listed the stats at the global level as stale after the partition exchange. But after I removed many of the steps and use just what's described in this posts.
select * from dba_tab_statistics
where table_name='PROGRAM_DIM';
shows stale stats=no for both global and partition. Kind of unexpected. Further digging in shows that is just determined by a case statement.
from dba_tab_statistics view ddl
case
when t.analyzetime is null then null
when ((m.inserts + m.deletes + m.updates) >
t.rowcnt *
to_number(DBMS_STATS.GET_PREFS('STALE_PERCENT',
u.name, o.name))/100 or
bitand(m.flags,1) = 1) then 'YES'
else 'NO'
end

How to set autotrace to explain plan ONLY

Hi,
I would like to see explain plan for a long running statement.
Now if I do following:
set autotrace on explain
UPDATE ......-- my statement
I get the plan, but the rows are updated also :-(
Is there a way to tell ORACLE, please show me the explain plan but dio not execute the statement?
Thanks

ONLY FOR queries you can use
set autotrace traceonly explain
And actually query isn't executed. For other DML you cannot use that.
The other way can be explaining the query and then selecting the plan_table output:
SQL> explain plan for update t set code = 3;
Explained.
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 931696821
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |      |     3 |     9 |     3   (0)| 00:00:01 |
|   1 | UPDATE            | T    |       |       |            |          |
|   2 |   TABLE ACCESS FULL| T    |     3 |     9 |     3   (0)| 00:00:01 |
Note
PLAN_TABLE_OUTPUT
   - dynamic sampling used for this statement
13 rows selected.
SQL> see http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_xplan.htm
Gints Plivna
http://www.gplivna.eu

Update statement taking too long to execute

Hi All,
I'm trying to run this update statement. But its taking too long to execute.
    UPDATE ops_forecast_extract b SET position_id = (SELECT a.row_id
        FROM s_postn a
        WHERE UPPER(a.desc_text) = UPPER(TRIM(B.POSITION_NAME)))
        WHERE position_level = 7
        AND b.am_id IS NULL;
        SELECT COUNT(*) FROM S_POSTN;
        214665
        SELECT COUNT(*) FROM ops_forecast_extract;
        49366
SELECT count(*)
        FROM s_postn a, ops_forecast_extract b
        WHERE UPPER(a.desc_text) = UPPER(TRIM(B.POSITION_NAME));
575What could be the reason for update statement to execute so long?
Thanks

polasa wrote:
Hi All,
I'm trying to run this update statement. But its taking too long to execute.
What could be the reason for update statement to execute so long?You haven't said what "too long" means, but a simple reason could be that the scalar subquery on "s_postn" is using a full table scan for each execution. Potentially this subquery gets executed for each row of the "ops_forecast_extract" table that satisfies your filter predicates. "Potentially" because of the cunning "filter/subquery optimization" of the Oracle runtime engine that attempts to cache the results of already executed instances of the subquery. Since the in-memory hash table that holds these cached results is of limited size, the optimization algorithm depends on the sort order of the data and could suffer from hash collisions it's unpredictable how well this optimization works in your particular case.
You might want to check the execution plan, it should tell you at least how Oracle is going to execute the scalar subquery (it doesn't tell you anything about this "filter/subquery optimization" feature).
Generic instructions how to generate a useful explain plan output and how to post it here follow:
Could you please post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your statement. Please use the {noformat}[{noformat}code{noformat}]{noformat} tag before and {noformat}[{noformat}/code{noformat}]{noformat} tag after or the {noformat}{{noformat}code{noformat}}{noformat} tag before and after to enhance readability of the output provided:
In SQL*Plus:
SET LINESIZE 130
EXPLAIN PLAN FOR <your statement>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Note that the package DBMS_XPLAN.DISPLAY is only available from 9i on.
In 9i and above, if the "Predicate Information" section is missing from the DBMS_XPLAN.DISPLAY output but you get instead the message "Plan table is old version" then you need to re-create your plan table using the server side script "$ORACLE_HOME/rdbms/admin/utlxplan.sql".
In previous versions you could run the following in SQL*Plus (on the server) instead:
@?/rdbms/admin/utlxplsA different approach in SQL*Plus:
SET AUTOTRACE ON EXPLAIN
<run your statement>;will also show the execution plan.
In order to get a better understanding where your statement spends the time you might want to turn on SQL trace as described here:
When your query takes too long ...
and post the "tkprof" output here, too.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Explain Plan in SQL Developer 1.5.1

How do I run Explain Plan against a Stored Package using SQL Developer 1.5.1?
I'm not familiar with this tool and need to examine a specific package.
Thanks.

AFAIK, you can only get an explain plan for SQL statements, not PL/SQL code...
K.

Explain Plan from TKPROF trace file.

Hello,
My procedure is taking time for that i have trace on in procedure fo find explain plan of particular query.
Using below statement Trace is on.
EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE = TRUE';
EXECUTE IMMEDIATE 'ALTER SESSION SET TIMED_STATISTICS = TRUE';Now for getting expalin plan from TKPROF i have used below statement but for some query i have found explain paln and some case i cant found explain plan.
tkprof mf_ora_23773.trc mf_ora_23773.txt explain =abc/abc
can u please help me to analyze where i m wrong?
Thanks.

First of all, you should best avoid using the explain= clause on the tkprof command line.
This will run explain plan on the statement in the trace file, and that explain plan can even be wrong, as there is no information on datatypes in the trace file.
The real explain plan data is flushed to the trace file, when the program issues commit or rollback. Oracle always issues an implicit commit when the program disconnects, so when you run the program to completion you should have explain plan output in your trace files.
You won't get explain plan output if you don't have access to the objects in the SQL statement. Also recursive SQL won't produce explain plan result.
One would need to see part of your trace file to verify your assertion the explain clause doesn't always work.
Sybrand Bakker
Senior Oracle DBA

Explain plan inside a procedure

I'm using execute immediate statement to process data. I would like to have additional information about explain plan for these statements, for example:
create or replace procedure p
is
v_stmt varchar2(4000) := 'select count(*) from dual where dummy = :1';
v_plan varchar2(4000);
begin
execute immediate v_stmt using 'X';
-- here I would like to retrieve into v_plan variable an explain plan used for v_stmt
end;
Is it possible to do? If so, how?
thank you

Just trace/tkprof the session that executes the process.
You'll have the execution plan and lots more of information:
ORACLE-BASE - SQL trace, 10046, trcsess and tkprof in Oracle
Oracle related stuff: Basic SQL statement performance diagnosis - HOW TO, step by step instructions

Explain plan on Update statement in function

Similar Messages

Maybe you are looking for