Query is taking 4 minute to update 100000 records.

Hi Experts,
Query is taking 4 minutes to update 100000 records.
Please help me.How to improve the performance of this query.
Please help me.
Thanks.

Most of your time seems to be spent on the nested loop join between the old and new data - and the "actuals" show that this was a bad choice of join mechanism introduced by a very bad estimate of the number of rows returned by the first join to product_SDS.
It would be useful to see the predicate section of the in-memory plan, but my best guess from the information given is that the estimate is bad because Oracle has used the "independent predicates" multiplication of selectivity on
PDS.DTPS_ID ='PROCESSED'
PDS.PD_ID = 4
PDS.DESCP IS NOT NULL
PDS.STCK_CD IS NOT NULL
PDS.UNIT IS NOT NULL
It's possible that a column group (extended_statistics) on some subset of these 5 columns would address the cardinality problem sufficiently well that the optimizer would switch to a hash join. Alternatively it's possible that the estimates are bad because you need a couple of histograms - this might also explain the discrepancy on the indexed access between the estimated 16,739 rows and the actual 128K rows. Columns to consider are: PDS.SO_ID, and PDS,DTOS_ID
Bottom line - the run-statistics row counts suggest you should be doing a hash join between the old and new data - the run time information suggests quite strongly that the optimizer needs some help with statistics
Regards
Jonathan Lewis

Similar Messages

Update query which taking more time

Hi
I am running an update query which takeing more time any help to run this fast.
update arm538e_tmp t
set t.qtr5 =(select (sum(nvl(m.net_sales_value,0))/1000) from mnthly_sales_actvty m
where m.vndr#=t.vndr#
and m.cust_type_cd=t.cust_type
and m.cust_type_cd<>13
and m.yymm between 201301 and 201303
group by m.vndr#,m.cust_type_cd;
help will be appreciable
thank you
Edited by: 960991 on Apr 16, 2013 7:11 AM

960991 wrote:
Hi
I am running an update query which takeing more time any help to run this fast.
update arm538e_tmp t
set t.qtr5 =(select (sum(nvl(m.net_sales_value,0))/1000) from mnthly_sales_actvty m
where m.vndr#=t.vndr#
and m.cust_type_cd=t.cust_type
and m.cust_type_cd13
and m.yymm between 201301 and 201303
group by m.vndr#,m.cust_type_cd;
help will be appreciable
thank youUpdates with subqueries can be slow. Get an execution plan for the update to see what SQL is doing.
Some things to look at ...
1. Are you sure you posted the right SQL? I could not "balance" the parenthesis - 4 "(" and 3 ")"
2. Unnecessary "(" ")" in the subquery "(sum" are confusing
3. Updates with subqueries can be slow. The tqtr5 value seems to evaluate to a constant. You might improve performance by computing the value beforehand and using a variable instead of the subquery
4. Subquery appears to be correlated - good! Make sure the subquery is properly indexed if it reads < 20% of the rows in the table (this figure depends on the version of Oracle)
5. Is tqtr5 part of an index? It is a bad idea to update indexed columns

Query is taking too much time

hi
The following query is taking too much time (more than 30 minutes), working with 11g.
The table has three columns rid, ida, geometry and index has been created on all columns.
The table has around 5,40,000 records of point geometries.
Please help me with your suggestions. I want to select duplicate point geometry where ida=CORD.
SQL> select a.rid, b.rid from totalrecords a, totalrecords b where a.ida='CORD' and b.idat='CORD' and
sdo_equal(a.geometry, b.geometry)='TRUE' and a.rid !=b.rid order by 1,2;
regards

I have removed some AND conditions That was not necessary. It's just that Oracle can see for example that
a.ida='CORD' AND
b.idat='CORD' AND
a.rid !=b.rid AND
sdo_equal(a.geometry, b.geometry)='TRUE'
ORDER BY 1,2;if a.ida does not equal 'CORD', the whole set of conditions evaluates to FALSE, so Oracle will not bother evaluating the rest of the conditions because it's all AND'ed together, and TRUE AND FALSE = FALSE.
So if you place your least expensive conditions first (even though the optimizer can and will reorder conditions) this will give you a small performance benefit. Too small to notice, but on 5.4 million records it should be noticable.
and I have set layer_gtype=POINT.Good, that will help. I forgot about that one (Thanks Luc!).
Now i am facing the problem to DELETE duplicate point geometry. The following query is taking too much time. What is too much time? Do you need to delete these duplicate points on a daily or hourly basis? Or is this a one-time cleanup action? If it's a one-time cleanup operation, does it really matter if it takes half an hour?
And if this is a daily or even hourly operation, then why don't you prevent the duplicates from entering the table in the first place? That will save you from having to clean up afterwards. Of course, this might not be possible with your business requirements.
Lastly: can you post an explain plan for your queries? Those might give us an idea of what is taking so much time. Please enclose the results of the explain plan with
[ c o d e ]
<code/results here>
[ / c o d e ]
that way the original formatting is kept and it makes things much easier to read.
Regards,
Stefan

Using Materilaized view in a query .. query is taking time????

Hi I have a query :-
SELECT rownum as id, u.last_name, u.first_name,u.phone phone, u.empid,u.supervisor id
FROM emp_view u -- using view
CONNECT BY PRIOR u.empid = u.supervisor_id
START WITH u.sbcuid = 'ph2755';
here emp_view is a view .
------ The above query is taking 3 sec to execute.
Then I created Materialuized view emp_mv and the the MV query is same as emp_view view query.
After this i executed following sql
SELECT rownum as id, u.last_name, u.first_name,u.phone phone, u.empid,u.supervisor id
FROM emp_mv u -- using materialized view
CONNECT BY PRIOR u.empid = u.supervisor_id
START WITH u.sbcuid = 'ph2755';
this query is taking 15 sec to execute..... :(
can anyone please tell me why MV query is taking time????

Hi,
In your first case you query a view, meaning that you query the underlying tables. These probably have indexes and stats are updated.
In you second case you query a materialized view, meaning that you query the underlying base table of that mview.
This probably do not have the same indexes to support that query.
But of course, I'm just guessing based on the little information provided.
If you want to take this further, please search for "When your query takes too long" and "How to post a tuning request".
These two threads holds valuable information, not only on how to ask this kind of question, but also how to start solving it on your own.
Regards
Peter

Time Machine Backups Taking 20 Minutes

Hi everyone.
Starting yesterday, my time machine backups are taking 20 minutes, when they used to only take 5. I'm backing up to an AirPort Extreme, via a wireless home network. Here's the latest code from the Console.
3/10/12 10:26:11.581 AM com.apple.backupd: Starting standard backup
3/10/12 10:26:11.600 AM com.apple.backupd: Attempting to mount network destination URL: afp://Michael%20Payne@Extreme%20Pleasantville._afpovertcp._tcp.local/Time%20Mac hine%20Backups
3/10/12 10:26:20.103 AM com.apple.backupd: Mounted network destination at mountpoint: /Volumes/Time Machine Backups using URL: afp://Michael%20Payne@Extreme%20Pleasantville._afpovertcp._tcp.local/Time%20Mac hine%20Backups
3/10/12 10:26:25.308 AM com.apple.backupd: QUICKCHECK ONLY; FILESYSTEM CLEAN
3/10/12 10:26:28.358 AM com.apple.backupd: Disk image /Volumes/Time Machine Backups/Michael’s MacBook Pro.sparsebundle mounted at: /Volumes/Time Machine Backups 1
3/10/12 10:26:28.366 AM com.apple.backupd: Backing up to: /Volumes/Time Machine Backups 1/Backups.backupdb
3/10/12 10:29:15.785 AM com.apple.backupd: 328.7 MB required (including padding), 11.01 GB available
3/10/12 10:29:15.786 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:30:15.939 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:31:16.045 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:32:16.319 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:33:25.124 AM com.apple.backupd: Copied 2103 files (4.0 MB) from volume Macintosh HD.
3/10/12 10:33:25.490 AM com.apple.backupd: 326.2 MB required (including padding), 11.01 GB available
3/10/12 10:33:25.491 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:34:27.545 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:35:28.849 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:36:30.823 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:37:32.956 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:38:34.958 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:39:36.563 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:40:37.309 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:41:38.786 AM com.apple.backupd: Waiting for index to be ready (100)
3/10/12 10:42:57.782 AM com.apple.backupd: Copied 740 files (1.3 MB) from volume Macintosh HD.
3/10/12 10:43:02.358 AM com.apple.backupd: Starting post-backup thinning
3/10/12 10:44:05.835 AM com.apple.backupd: Deleted /Volumes/Time Machine Backups 1/Backups.backupdb/Michael’s MacBook Pro/2012-03-08-223328 (1.8 MB)
3/10/12 10:44:05.835 AM com.apple.backupd: Post-back up thinning complete: 1 expired backups removed
3/10/12 10:44:06.002 AM com.apple.backupd: Backup completed successfully.
3/10/12 10:44:21.968 AM com.apple.backupd: Ejected Time Machine disk image.
3/10/12 10:44:22.204 AM com.apple.backupd: Ejected Time Machine network volume.
It looks like it's a problem with the Indexing. I'm in the process of doing a verification now, but is there anything else I can do to get it back to the 5 minutes or so it takes? If you care, here is a code from a more successful backup that didn't take nearly as long.
3/8/12 10:27:07.728 PM com.apple.backupd: Starting standard backup
3/8/12 10:27:08.081 PM com.apple.backupd: Attempting to mount network destination URL: afp://Michael%20Payne@Extreme%20Pleasantville._afpovertcp._tcp.local/Time%20Mac hine%20Backups
3/8/12 10:27:08.643 PM com.apple.backupd: Mounted network destination at mountpoint: /Volumes/Time Machine Backups using URL: afp://Michael%20Payne@Extreme%20Pleasantville._afpovertcp._tcp.local/Time%20Mac hine%20Backups
3/8/12 10:27:15.446 PM com.apple.backupd: QUICKCHECK ONLY; FILESYSTEM CLEAN
3/8/12 10:27:19.348 PM com.apple.backupd: Disk image /Volumes/Time Machine Backups/Michael’s MacBook Pro.sparsebundle mounted at: /Volumes/Time Machine Backups 1
3/8/12 10:27:19.480 PM com.apple.backupd: Backing up to: /Volumes/Time Machine Backups 1/Backups.backupdb
3/8/12 10:29:02.025 PM com.apple.backupd: 435.2 MB required (including padding), 19.03 GB available
3/8/12 10:31:53.585 PM com.apple.backupd: Copied 1312 files (1.4 MB) from volume Macintosh HD.
3/8/12 10:32:06.643 PM com.apple.backupd: 434.6 MB required (including padding), 19.03 GB available
3/8/12 10:33:28.056 PM com.apple.backupd: Copied 983 files (943 KB) from volume Macintosh HD.
3/8/12 10:33:33.364 PM com.apple.backupd: Starting post-backup thinning
3/8/12 10:35:09.074 PM com.apple.backupd: Deleted /Volumes/Time Machine Backups 1/Backups.backupdb/Michael’s MacBook Pro/2012-03-07-213931 (2.9 MB)
3/8/12 10:35:09.074 PM com.apple.backupd: Post-back up thinning complete: 1 expired backups removed
3/8/12 10:35:09.363 PM com.apple.backupd: Backup completed successfully.
3/8/12 10:35:27.460 PM com.apple.backupd: Ejected Time Machine disk image.
3/8/12 10:35:27.698 PM com.apple.backupd: Ejected Time Machine network volume.
It looks like starting on March 9 is when the problem started happening. I'm using a MacBook Pro with Mac OS X Version 10.7.3.

As an update, the Backup Verification passed.
3/10/12 10:56:09.005 AM com.apple.backupd: Backup verification requested by user.
3/10/12 10:56:09.024 AM com.apple.backupd: Attempting to mount network destination URL: afp://Michael%20Payne@Extreme%20Pleasantville._afpovertcp._tcp.local/Time%20Mac hine%20Backups
3/10/12 10:56:09.715 AM com.apple.backupd: Mounted network destination at mountpoint: /Volumes/Time Machine Backups using URL: afp://Michael%20Payne@Extreme%20Pleasantville._afpovertcp._tcp.local/Time%20Mac hine%20Backups
3/10/12 10:56:10.225 AM com.apple.backupd: Running backup verification
3/10/12 10:56:13.381 AM com.apple.backupd: QUICKCHECK ONLY; FILESYSTEM CLEAN
3/10/12 11:07:43.912 AM com.apple.backupd: Backup verification passed!
3/10/12 11:07:44.483 AM com.apple.backupd: Ejected Time Machine network volume.

Simple query is taking long time

Hi Experts,
The below query is taking long time.
[code]SELECT   FS.*
FROM   ORL.FAX_STAGE FS
         INNER JOIN
               ORL.FAX_SOURCE FSRC
            INNER JOIN
               GLOBAL_BU_MAPPING GBM
            ON GBM.BU_ID = FSRC.BUID
         ON UPPER (FSRC.FAX_NUMBER) = UPPER (FS.DESTINATION)
WHERE       FSRC.IS_DELETED = 'N'
         AND GBM.BU_ID IS NOT NULL
         AND UPPER (FS.FAX_STATUS) ='COMPLETED';[/code]
this query is returning 1645457 records.
[code]PLAN_TABLE_OUTPUT
| Id | Operation           | Name                   | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT    |                        |   625K|   341M| 45113   (1)|
|   1 | HASH JOIN          |                        |   625K|   341M| 45113   (1)|
|   2 |   NESTED LOOPS      |                        |   611 | 14664 |    22   (0)|
|   3 |    TABLE ACCESS FULL| FAX_SOURCE             | 2290 | 48090 |    22   (0)|
|   4 |    INDEX RANGE SCAN | GLOBAL_BU_MAPPING_BUID |     1 |     3 |     0   (0)|
|   5 |   TABLE ACCESS FULL | FAX_STAGE              | 2324K| 1214M| 45076   (1)|
PLAN_TABLE_OUTPUT
Note
   - 'PLAN_TABLE' is old version
15 rows selected.[/code]
The distinct number of records in each table.
[code]SELECT FAX_STATUS,count(*)
FROM fax_STAGE
GROUP BY FAX_STATUS;
FAX_STATUS    COUNT(*)
BROKEN          10
Broken - New    9
Completed    2324493
New             20
SELECT is_deleted,COUNT(*)
FROM FAX_SOURCE
GROUP BY IS_DELETED;
IS_DELETED COUNT(*)
N         2290
Y         78[/code]
Total number of records in each table.
[code]SELECT COUNT(*) FROM ORL.FAX_SOURCE FSRC-- 2368
SELECT COUNT(*) FROM ORL.FAX_STAGE--2324532
SELECT COUNT(*) FROM APPS_GLOBAL.GLOBAL_BU_MAPPING--9
[/code]
To improve the performance of this query I have created the following indexes.
[code]Functional based index on UPPER (FSRC.FAX_NUMBER) ,UPPER (FS.DESTINATION) and UPPER (FS.FAX_STATUS).
Bitmap index on FSRC.IS_DELETED.
Normal Index on GBM.BU_ID and FSRC.BUID.
[/code]
But still the performance is bad for this query.
What can I do apart from this to improve the performance of this query.
Please help me .
Thanks in advance.

<I have created the following indexes.
CREATE INDEX ORL.IDX_DESTINATION_RAM ON ORL.FAX_STAGE(UPPER("DESTINATION"))
CREATE INDEX ORL.IDX_FAX_STATUS_RAM ON ORL.FAX_STAGE(LOWER("FAX_STATUS"))
CREATE INDEX ORL.IDX_UPPER_FAX_STATUS_RAM ON ORL.FAX_STAGE(UPPER("FAX_STATUS"))
CREATE INDEX ORL.IDX_BUID_RAM ON ORL.FAX_SOURCE(BUID)
CREATE INDEX ORL.IDX_FAX_NUMBER_RAM ON ORL.FAX_SOURCE(UPPER("FAX_NUMBER"))
CREATE BITMAP INDEX ORL.IDX_IS_DELETED_RAM ON ORL.FAX_SOURCE(IS_DELETED)
After creating the following indexes performance got improved.
But our DBA said that new BITMAP index at FAX_SOURCE table (ORL.IDX_IS_DELETED_RAM) can cause locks
on multiple rows if IS_DELETED column is in use. Please proceed with detailed tests.
I am sending the explain plan before creating indexes and after indexes has been created.
SELECT FS.*
FROM ORL.FAX_STAGE FS
                INNER JOIN
                ORL.FAX_SOURCE FSRC
              INNER JOIN
                  GLOBAL_BU_MAPPING GBM
                ON GBM.BU_ID = FSRC.BUID
            ON UPPER (FSRC.FAX_NUMBER) = UPPER (FS.DESTINATION)
WHERE      FSRC.IS_DELETED = 'N'
          AND GBM.BU_ID IS NOT NULL
          AND UPPER (FS.FAX_STATUS) =:B1;
--OLD without indexes
PLAN_TABLE_OUTPUT
Plan hash value: 3076973749
| Id | Operation          | Name                  | Rows | Bytes | Cost (%CPU)| Time    |
| 0 | SELECT STATEMENT    |                        | 141K|    85M| 45130 (1)| 00:09:02 |
|* 1 | HASH JOIN          |                        | 141K|    85M| 45130 (1)| 00:09:02 |
| 2 | NESTED LOOPS      |                        | 611 | 18330 |    22 (0)| 00:00:01 |
|* 3 |    TABLE ACCESS FULL| FAX_SOURCE            | 2290 | 59540 |    22 (0)| 00:00:01 |
|* 4 |    INDEX RANGE SCAN | GLOBAL_BU_MAPPING_BUID |    1 |    4 |    0 (0)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | FAX_STAGE              | 23245 |    13M| 45106 (1)| 00:09:02 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
1 - access(UPPER("FSRC"."FAX_NUMBER")=UPPER("FS"."DESTINATION"))
3 - filter("FSRC"."IS_DELETED"='N')
4 - access("GBM"."BU_ID"="FSRC"."BUID")
      filter("GBM"."BU_ID" IS NOT NULL)
5 - filter(UPPER("FS"."FAX_STATUS")=SYS_OP_C2C(:B1))
21 rows selected.
--NEW with indexes.
PLAN_TABLE_OUTPUT
Plan hash value: 665032407
| Id | Operation                        | Name                    | Rows | Bytes | Cost (%CPU)| Time    |
| 0 | SELECT STATEMENT                |                          | 5995 | 3986K| 3117 (1)| 00:00:38 |
|* 1 | HASH JOIN                      |                          | 5995 | 3986K| 3117 (1)| 00:00:38 |
| 2 | NESTED LOOPS                  |                          | 611 | 47658 |    20 (5)| 00:00:01 |
|* 3 |    VIEW                          | index$_join$_002        | 2290 | 165K|    20 (5)| 00:00:01 |
|* 4 |    HASH JOIN                    |                          |      |      |            |      |
|* 5 |      HASH JOIN                  |                          |      |      |            |      |
PLAN_TABLE_OUTPUT
| 6 |      BITMAP CONVERSION TO ROWIDS|                          | 2290 | 165K|    1 (0)| 00:00:01 |
|* 7 |        BITMAP INDEX SINGLE VALUE | IDX_IS_DELETED_RAM      |      |      |            |      |
| 8 |      INDEX FAST FULL SCAN      | IDX_BUID_RAM            | 2290 | 165K|    8 (0)| 00:00:01 |
| 9 |      INDEX FAST FULL SCAN        | IDX_FAX_NUMBER_RAM      | 2290 | 165K|    14 (0)| 00:00:01 |
|* 10 |    INDEX RANGE SCAN              | GLOBAL_BU_MAPPING_BUID |    1 |    4 |    0 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID    | FAX_STAGE                | 23245 |    13M| 3096 (1)| 00:00:38 |
|* 12 |    INDEX RANGE SCAN              | IDX_UPPER_FAX_STATUS_RAM | 9298 |      | 2434 (1)| 00:00:30 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
1 - access(UPPER("DESTINATION")="FSRC"."SYS_NC00035$")
3 - filter("FSRC"."IS_DELETED"='N')
4 - access(ROWID=ROWID)
5 - access(ROWID=ROWID)
7 - access("FSRC"."IS_DELETED"='N')
10 - access("GBM"."BU_ID"="FSRC"."BUID")
      filter("GBM"."BU_ID" IS NOT NULL)
12 - access(UPPER("FAX_STATUS")=SYS_OP_C2C(:B1))
31 rows selected
Please confirm on the DBA comment.Is this bitmap index locks rows in my case.
Thanks.>

My MacBook Pro (purchased in 2011) is taking 10 minutes to boot-up. It's also taking much longer to open files. I have 650 GB out of 700 GB left on my machine so it's not that I've overloaded the memory. Is anyone else having this problem?

My MacBook Pro (purchased in 2011) is taking 10 minutes to boot-up. It's also taking much longer to open files. I have 650 GB out of 700 GB left on my machine so it's not that I've overloaded the memory. Is anyone else having this problem?

Look at this comprehensive trouble shooting document;
https://discussions.apple.com/docs/DOC-3353
I suggest that you start with SMC and PRAM resets.
Then a Safe Boot.
Ciao.

How can I make my adodc connect faster to my SQL Server? It's taking a minute (so long) before I can view thousand of record in my listview.

How can I make my adodc connect faster to my SQL Server? It's taking a minute (so long) before I can view thousand of record in my listview. Please anyone help me.
I'm using this code:
Public Class McheckpaymentNew
Private cn As New ADODB.Connection
Private rs As New ADODB.Recordset
Private Sub McheckpaymentNew_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Try
cn.ConnectionString = "DSN=database; UID=user; PWD=password"
cn.Open()
rs.CursorLocation = ADODB.CursorLocationEnum.adUseClient
rs.CursorType = ADODB.CursorTypeEnum.adOpenStatic
rs.LockType = ADODB.LockTypeEnum.adLockBatchOptimistic
Catch ex As Exception
MsgBox("Failed to Connect!, Please check your Network Connections, or Contact MIS Dept. for assistance.", vbCritical, "Error while Connecting to Database.."
End
End Try
End Sub
End Class

How can I make my adodc connect faster to my SQL Server? It's taking a minute (so long) before I can view thousand of record in my listview. Please anyone help me.
I'm using this code:
Public Class McheckpaymentNew
Private cn As New ADODB.Connection
Private rs As New ADODB.Recordset
Private Sub McheckpaymentNew_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Try
cn.ConnectionString = "DSN=database; UID=user; PWD=password"
cn.Open()
rs.CursorLocation = ADODB.CursorLocationEnum.adUseClient
rs.CursorType = ADODB.CursorTypeEnum.adOpenStatic
rs.LockType = ADODB.LockTypeEnum.adLockBatchOptimistic
Catch ex As Exception
MsgBox("Failed to Connect!, Please check your Network Connections, or Contact MIS Dept. for assistance.", vbCritical, "Error while Connecting to Database.."
End
End Try
End Sub
End Class

Error while querying - You cannot update this record

Hi all,
I have a builded a form and was successful when i enter the data. But when i query the form it is showing me the error FRM-14050 YOU CANNOT UPDATE THIS RECORD.
I have pre-insert, pre-update and pre-query triggers at block level.
In PRE_INSERT iam setting the property to insert allowed and true.
same way for pre-update and pre-query.
Can any one guide me.
Thanks
Sunil

Hi
check your fields name name and match with database fields.
vikas

Sql query is taking more time

Hi all,
db:oracle 9i
I am facing below query prob.
prob is that query is taking more time 45 min than earliar (10 sec).
please any one suggest me .....
SQL> SELECT MAX (tdar1.ID) ID, tdar1.request_id, tdar1.lolm_transaction_id,
2 tdar1.transaction_version
3 FROM transaction_data_arc tdar1
4 WHERE tdar1.transaction_name ='O96U '
5 AND tdar1.transaction_type = 'REQUEST'
6 AND tdar1.message_type_code ='PCN'
7 AND NOT EXISTS (
8 SELECT NULL
9 FROM transaction_data_arc tdar2
10 WHERE tdar2.request_id = tdar1.request_id
11 AND tdar2.lolm_transaction_id != tdar1.lolm_transaction_id
12 AND tdar2.ID > tdar1.ID)
13 GROUP BY tdar1.request_id,
14 tdar1.lolm_transaction_id,
15 tdar1.transaction_version;
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=17 Card=1 Bytes=42)
1 0 SORT (GROUP BY) (Cost=12 Card=1 Bytes=42)
2 1 FILTER
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'TRANSACTION_DATA_ARC
' (Cost=1 Card=1 Bytes=42)
4 3 INDEX (RANGE SCAN) OF 'NK_TDAR_2' (NON-UNIQUE) (Cost
=3 Card=1)
5 2 TABLE ACCESS (BY INDEX ROWID) OF 'TRANSACTION_DATA_ARC
' (Cost=5 Card=918 Bytes=20196)
6 5 INDEX (RANGE SCAN) OF 'NK_TDAR_7' (NON-UNIQUE) (Cost
=8 Card=4760)

prob is that query is taking more time 45 min than earliar (10 sec).Then something must have changed (data growth/stale statistics/...?).
You should post as much details as possible, how and what it is described in the FAQ, see:
*3. How to improve the performance of my query? / My query is running slow*.
When your query takes too long...
How to post a SQL statement tuning request
SQL and PL/SQL FAQ
Also, given your database version, using NOT IN instead of NOT EXISTS might make a difference (but they're not the same).
See: SQL and PL/SQL FAQ

Query is taking more time to execute

Hi,
Query is taking more time to execute.
But when i execute same query in other server then it is giving immediate output.
What is the reason of it.
thanks in advance.

'My car doesn't start, please help me to start my car'
Do you think we are clairvoyant?
Or is your salary subtracted for every letter you type here?
Please be aware this is not a chatroom, and we can not see your webcam.
Sybrand Bakker
Senior Oracle DBA

Query is taking more time to execute in PROD

Hi All,
Can anyone tell me why this query is taking more time when I am using for single trx_number record it is working fine but when I am trying to use all the records it is not fatching any records and it is keep on running.
SELECT DISTINCT OOH.HEADER_ID
,OOH.ORG_ID
,ct.CUSTOMER_TRX_ID
,ool.ship_from_org_id
,ct.trx_number IDP_SHIPMENT_ID
,ctt.type STATUS_CODE
,SYSDATE STATUS_DATE
,ooh.attribute16 IDP_ORDER_NBR --Change based on testing on 21-JUL-2010 in UAT
,lpad(rac_bill.account_number,6,0) IDP_BILL_TO_CUSTOMER_NBR
,rac_bill.orig_system_reference
,rac_ship_party.party_name SHIP_TO_NAME
,raa_ship_loc.address1 SHIP_TO_ADDR1
,raa_ship_loc.address2 SHIP_TO_ADDR2
,raa_ship_loc.address3 SHIP_TO_ADDR3
,raa_ship_loc.address4 SHIP_TO_ADDR4
,raa_ship_loc.city SHIP_TO_CITY
,NVL(raa_ship_loc.state,raa_ship_loc.province) SHIP_TO_STATE
,raa_ship_loc.country SHIP_TO_COUNTRY_NAME
,raa_ship_loc.postal_code SHIP_TO_ZIP
,ooh.CUST_PO_NUMBER CUSTOMER_ORDER_NBR
,ooh.creation_date CUSTOMER_ORDER_DATE
,ool.actual_shipment_date DATE_SHIPPED
,DECODE(mp.organization_code,'CHP', 'CHESAPEAKE'
,'CSB', 'CHESAPEAKE'
,'DEP', 'CHESAPEAKE'
,'CHESAPEAKE') SHIPPED_FROM_LOCATION --'MEMPHIS' --'HOUSTON'
,ooh.freight_carrier_code FREIGHT_CARRIER
,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)
+ NVL(XX_FSG_NA_FASTRAQ_IFACE.get_line_fr_amt ('FREIGHT',ct.customer_trx_id,ct.org_id),0)FREIGHT_CHARGE
,ooh.freight_terms_code FREIGHT_TERMS
,'' IDP_BILL_OF_LADING
,(SELECT WAYBILL
FROM WSH_DELIVERY_DETAILS_OE_V
WHERE -1=-1
AND SOURCE_HEADER_ID = ooh.header_id
AND SOURCE_LINE_ID = ool.line_id
AND ROWNUM =1) WAYBILL_CARRIER
,'' CONTAINERS
,ct.trx_number INVOICE_NBR
,ct.trx_date INVOICE_DATE
,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('LINE',ct.customer_trx_id,ct.org_id),0) +
NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) +
NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)INVOICE_AMOUNT
,NULL IDP_TAX_IDENTIFICATION_NBR
,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) TAX_AMOUNT_1
,NULL TAX_DESC_1
,NULL TAX_AMOUNT_2
,NULL TAX_DESC_2
,rt.name PAYMENT_TERMS
,NULL RELATED_INVOICE_NBR
,'Y' INVOICE_PRINT_FLAG
FROM ra_customer_trx_all ct
,ra_cust_trx_types_all ctt
,hz_cust_accounts rac_ship
,hz_cust_accounts rac_bill
,hz_parties rac_ship_party
,hz_locations raa_ship_loc
,hz_party_sites raa_ship_ps
,hz_cust_acct_sites_all raa_ship
,hz_cust_site_uses_all su_ship
,ra_customer_trx_lines_all rctl
,oe_order_lines_all ool
,oe_order_headers_all ooh
,mtl_parameters mp
,ra_terms rt
,OE_ORDER_SOURCES oos
,XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V
WHERE ct.cust_trx_type_id = ctt.cust_trx_type_id
AND ctt.TYPE <> 'BR'
AND ct.org_id = ctt.org_id
AND ct.ship_to_customer_id = rac_ship.cust_account_id
AND ct.bill_to_customer_id = rac_bill.cust_account_id
AND rac_ship.party_id = rac_ship_party.party_id
AND su_ship.cust_acct_site_id = raa_ship.cust_acct_site_id
AND raa_ship.party_site_id = raa_ship_ps.party_site_id
AND raa_ship_loc.location_id = raa_ship_ps.location_id
AND ct.ship_to_site_use_id = su_ship.site_use_id
AND su_ship.org_id = ct.org_id
AND raa_ship.org_id = ct.org_id
AND ct.customer_trx_id = rctl.customer_trx_id
AND ct.org_id = rctl.org_id
AND rctl.interface_line_attribute6 = to_char(ool.line_id)
AND rctl.org_id = ool.org_id
AND ool.header_id = ooh.header_id
AND ool.org_id = ooh.org_id
AND mp.organization_id = ool.ship_from_org_id
AND ooh.payment_term_id = rt.term_id
AND xla_ael_sl_v.last_update_date >= NVL(p_last_update_date,xla_ael_sl_v.last_update_date)
AND ooh.order_source_id = oos.order_source_id --Change based on testing on 19-May-2010
AND oos.name = 'FASTRAQ' --Change based on testing on 19-May-2010
AND ooh.org_id = g_org_id --Change based on testing on 19-May-2010
AND ool.flow_status_code = 'CLOSED'
AND xla_ael_sl_v.trx_hdr_id = ct.customer_trx_id
AND trx_hdr_table = 'CT'
AND xla_ael_sl_v.gl_transfer_status = 'Y'
AND xla_ael_sl_v.accounted_dr IS NOT NULL
AND xla_ael_sl_v.org_id = ct.org_id;
-- AND ct.trx_number = '2000080';
}

Hello Friend,
You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
Please check the possbility of finding it through other AR tables.
2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
For example : For ra_cust_trx_types_all use ra_cust_trx_types.
This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
You can also check the same using
SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
If the tables are not analyzed , the CBO will not be able to tune your query.
4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
report.
Thanks,
Neeraj Shrivastava
[email protected]
Edited by: user9352949 on Oct 1, 2010 8:02 PM
Edited by: user9352949 on Oct 1, 2010 8:03 PM

Delete query is taking too much time...

Hi All,
Below delete query is taking at least 1hrs. !!!!
DELETE aux_current_link aux
WHERE EXISTS (
SELECT *
FROM link_trans_cons link2
WHERE aux.tr_leu_id = link2.tr_leu_id
AND aux.kind_of_link = link2.kind_of_link
AND link2.TYPE = 'H');
table aux_current_link has record - 284279 and has 6 normal index.
pls help me.
Subir

Not even close to enough information.
Look here to see if you can tune the operation.
When your query takes too long ...
But for a delete you need to understand that the indexes need to be maintained, you have 6 of them, that requires effort. ALSO, foreign keys need to be checked to make sure you don't violate any enabled foreign keys (so maybe you need an index on a table where a column from this table you deleting from is being referenced).
If you are deleting a HIGH percentage of the table you may be better off doing a create table as select ....query to keep all rows from your table....then drop your current table, rename the new one you made, and add all the indexes to it.
Otherwise, once you've tuned the operation (query), assuming it can be tuned, it's going to take as long as it needs to take.....
Message was edited by:
Tubby

Select query is taking lot of time to fetch data.....

Select query is taking lot of time to fetch data.
    SELECT algnum atanum abdatu abzeit abname abenum bmatnr bmaktx bqdatu bqzeit bvlenr bnlenr bvltyp bvlber b~vlpla
           bnltyp bnlber bnlpla bvsola b~vorga INTO TABLE it_final FROM ltak AS a
                   INNER JOIN ltap AS b ON btanum EQ atanum AND algnum EQ blgnum
                   WHERE a~lgnum = p_whno
                   AND a~tanum IN s_tono
                   AND a~bdatu IN s_tocd
                   AND a~bzeit IN s_bzeit
                   AND a~bname IN s_uname
                   AND a~betyp = 'P'
                   AND b~matnr IN s_mno
                   AND b~vorga <> 'ST'.
Moderator message: Please Read before Posting in the Performance and Tuning Forum
Edited by: Thomas Zloch on Mar 27, 2011 12:05 PM

Hi Shiva,
I am using two more select queries with the same manner ....
here are the other two select query :
***************1************************
SELECT * APPENDING CORRESPONDING FIELDS OF TABLE tbl_summary
    FROM ztftelpt LEFT JOIN ztfzberep
     ON ztfzberep~gjahr = st_input-gjahr
     AND ztfzberep~poper = st_input-poper
     AND ztfzberepcntr = ztftelptrprctr
    WHERE rldnr = c_telstra_projects
      AND rrcty = c_actual
      AND rvers = c_ver_001
      AND rbukrs = st_input-bukrs
      AND racct = st_input-saknr
      AND ryear = st_input-gjahr
      and rzzlstar in r_lstar
      AND rpmax = c_max_period.
and the second one is
*************************2************************
SELECT * APPENDING CORRESPONDING FIELDS OF TABLE tbl_summary
    FROM ztftelnt LEFT JOIN ztfzberep
     ON ztfzberep~gjahr = st_input-gjahr
     AND ztfzberep~poper = st_input-poper
     AND ztfzberepcntr = ztftelntrprctr
    WHERE rldnr = c_telstra_networks
      AND rrcty = c_actual
      AND rvers = c_ver_001
      AND rbukrs = st_input-bukrs
      AND racct = st_input-saknr
      AND ryear = st_input-gjahr
      and rzzlstar in r_lstar
      AND rpmax = c_max_period.
for both the above table program is taking very less time .... although both the table used in above queries have similar amount of data. And i can not remove the APPENDING CORRESPONDING. because i have to append the data after fetching from the tables. if i will not use it will delete all the data fetched earlier.
Thanks on advanced......
Sourabh

When query is taking too long time

When query is taking too long time,Where and how to start tuning it?
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)
2.Parameter modification need to be done at system/session level
3.The query has to be tuned (using hints )
4.Gathering/deleting statistics
List out any other things that need to be taken into account?
Which approach must be followed and on what basis that approach must be considered?

When query is taking too long time,Where and how to start tuning it?explain plan will be good start . trace also
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)When Oracle executes an SQL statement, it is not constantly executing. Sometimes it has to wait for a specific event to happen befor it can proceed.
Read
http://www.adp-gmbh.ch/ora/tuning/event.html
2.Parameter modification need to be done at system/session levelDepend on parameter , define parameter , trace done on session level for example
3.The query has to be tuned (using hints )Could be help you but you must know how to use .
4.Gathering/deleting statisticsDo it in non working hours , it will impact on database performance , but its good
List out any other things that need to be taken into account?Which account ?
Which approach must be followed and on what basis that approach must be considered?you could use lot of tools , Trace , AWR

Query is taking 4 minute to update 100000 records.

Similar Messages

Maybe you are looking for