Taking more time while generating webhelp.
I am updating the MBDB manual using RoboHelp. This manual consists of 9 projects that are merged into 1 (or over 16,000 documents total). For each project I open it, add new or make revisions to the documents within and generate the document. It is the generate process that is taking so long. They should take between 5-10 minutes to generate and some of these take 30+ minutes to generate.
Jeff, it would seem that Madhu is perhaps confused about .CPD files, as it was stated "no where using .CPD files".
Madhu, the .CPD file is a file created and used by the RoboHelp HTML application. Sometimes we need to rename or delete it in order to coax a project to work again. In Tools > Options there is a setting to delete the .CPD when RoboHelp HTML starts. You might try enabling that option and see if things change for you.
Cheers... Rick
Similar Messages
-
Taking More Time while inserting into the table (With foriegn key)
Hi All,
I am facing problem while inserting the values into the master table.
The problem,
Table A -- User Master Table (Reg No, Name, etc)
Table B -- Transaction Table (Foreign key reference with Table A).
While inserting the data's in Table B, i need to insert the reg no also in table B which is mandatory. I followed the logic which is mentioned in the SRDemo.
While inserting we need to query the Table A first to have the values in TableABean.java.
final TableA tableA= (TableA )uow.executeQuery("findUser",TableA .class, regNo);
Then, we need to create the instance for TableB
TableB tableB= (TableB)uow.newInstance(TableB.class);
tableB.setID(bean.getID);
tableA.addTableB(tableB); --- this is for to insert the regNo of TableA in TableB.. This line is executing the query "select * from TableB where RegNo = <tableA.getRegNo>".
This query is taking too much time if values are more in the TableB for that particular registrationNo. Because of this its taking more time to insert into the TableB.
For Ex: TableA -- regNo : 101...having less entry in TableB means...inserting record is taking less than 1 sec
regNo : 102...having more entry in TableB means...inserting record is taking more than 2 sec
Time delay is there for different users when they enter transaction in TableB.
I need to avoid this since in future it will take more time...from 2 sec to 10 sec, if volume of data increases mean.
Please help me to resolve this issue...I am facing it now in production.
Thanks & Regards
VBHello,
Looks like you have a 1:M relationship from TableA to TableB, with a 1:1 back pointer from TableB to TableA. If triggering the 1:M relationship is causing you delays that you want to avoid there might be two quick ways I can see:
1) Don't map it. Leave the TableA->TableB 1:M unmapped, and instead just query for relationship when you do need it. This means you do not need to call tableA.addTableB(tableB), and instead only need to call tableB.setTableA(tableA), so that the TableB->TableA relation gets set. Might not be the best option, but it depends on your application's usage. It does allow you to potentially page the TableB results or add other query query performance options when you do need the data though.
2) You are currently using Lazy loading for the TableA->TableB relationship - if it is untriggered, don't bother calling tableA.addTableB(tableB), and instead only need to call tableB.setTableA(tableA). This of course requires using TopLink api to a) verify the collection is an IndirectCollection type, and b) that it is hasn't been triggered. If it has been triggered, you will still need to call tableA.addTableB(tableB), but it won't result in a query. Check out the oracle.toplink.indirection.IndirectContainer class and it's isInstantiated() method. This can cause problems though in highly concurrent environments, as other threads may have triggered the indirection before you commit your transaction, so that the A->B collection is not up to date - this might require refreshing the TableA if so.
Change tracking would probably be the best option to use here, and is described in the EclipseLink wiki:
http://wiki.eclipse.org/Introduction_to_EclipseLink_Transactions_(ELUG)#Attribute_Change_Tracking_Policy
Best Regards,
Chris -
BAM reports taking more time while fetching data from EDS
I have created an external Data Source(EDS) in the BAM, and when i create an object with that EDS, it is taking very long to fetch data from the EDS( more than 20 mins.), but as the Database is installed on my local system, when i fire a query there, it don't take much time. Please help me in this, what could be the possible reason?
Your messaging gateway question would be better addressed in the SQL PL/SQL forum
All Places > Database > Oracle Database + Options > SQL and PL/SQL > Discussions -
Task is taking more time, while creating more number of jobs in PLSQL.
Hi,
I want to know regarding distributing a task to no. of scheduler jobs. On which basis we should have to define no. of jobs and also what will be advantage or disadvantage of increasing the number of such jobs for a particular task ?Hello,
Looks like you have a 1:M relationship from TableA to TableB, with a 1:1 back pointer from TableB to TableA. If triggering the 1:M relationship is causing you delays that you want to avoid there might be two quick ways I can see:
1) Don't map it. Leave the TableA->TableB 1:M unmapped, and instead just query for relationship when you do need it. This means you do not need to call tableA.addTableB(tableB), and instead only need to call tableB.setTableA(tableA), so that the TableB->TableA relation gets set. Might not be the best option, but it depends on your application's usage. It does allow you to potentially page the TableB results or add other query query performance options when you do need the data though.
2) You are currently using Lazy loading for the TableA->TableB relationship - if it is untriggered, don't bother calling tableA.addTableB(tableB), and instead only need to call tableB.setTableA(tableA). This of course requires using TopLink api to a) verify the collection is an IndirectCollection type, and b) that it is hasn't been triggered. If it has been triggered, you will still need to call tableA.addTableB(tableB), but it won't result in a query. Check out the oracle.toplink.indirection.IndirectContainer class and it's isInstantiated() method. This can cause problems though in highly concurrent environments, as other threads may have triggered the indirection before you commit your transaction, so that the A->B collection is not up to date - this might require refreshing the TableA if so.
Change tracking would probably be the best option to use here, and is described in the EclipseLink wiki:
http://wiki.eclipse.org/Introduction_to_EclipseLink_Transactions_(ELUG)#Attribute_Change_Tracking_Policy
Best Regards,
Chris -
Clicking Drill Down Plus Sympol its taking more time
Hi ,
In my drill-down report having 2000 records while initially it takes 25 seconds to render the report after that when i click Plus symbol it takes again 20 secs to display the data.My question is in drill-down report for loading data it will hit one
time to fetch data.So why its taking more time while clicking plus symbol the data already exits in datasets.
So please tell me where i am doing mistake.
Regards,
HariKanHi HariKan,
According to your description, when you preview the drill down report, after you click plus sign, it takes 20 seconds to expand the detail information.
The total time to generate a reporting server report (RDL) can be divided into 3 elements:
TimeDataRetrieval: The time needed for SQL Server to retrieve the data of all datasets in your report.
TimeProcessing: The number of milliseconds spent in the processing engine for the request.
TimeRendering: The time spent after the Rendering Object Model is exposed to the rendering extension.
After you click plus sign, Report rendering occurs after data and layout are combined into an interim format and then passed to a rendering extension. The time includes:
Time spent in renderer.
Time spent in width and height of report items.
Time spent in paging.
Time spent in all expression evaluation.
For more information about report processing, please refer to the following document:
http://blogs.msdn.com/b/robertbruckner/archive/2009/01/05/executionlog2-view.aspx
If you have any more questions, please feel free to ask.
Thanks,
Wendy Fu
Wendy Fu
TechNet Community Support -
Create index is taking more time
Hi,
One of the concurrent program is taking more time , We generate the trace file and found that the create index is taking more time.
Below is from the trace file and such type of index creation is happening lot of time in Oracle standard program.
Can somebody let me know why there is a big difference between cpu and elapse time.
We are seeing the PX Deq: Execute Reply Event as well.look idle time for database.
Please let me know which parameter of the database is affecting this.
CREATE INDEX ITEM_CATEGORIES_N2_BD9 ON ITEM_CATEGORIES_BD9(CATEGORY_SET_ID,
SR_CATEGORY_ID,ORGANIZATION_ID,SR_INSTANCE_ID) PARALLEL TABLESPACE MSCX
STORAGE( INITIAL 40960 NEXT 33554432 PCTINCREASE 0) PCTFREE 10 INITRANS 11
MAXTRANS 255
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 3 0 0
Execute 1 0.35 364.82 131168 117945 60324 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.35 364.83 131168 117948 60324 0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 80 (recursive depth: 2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
reliable message 1 0.00 0.00
enq: KO - fast object checkpoint 1 0.01 0.01
PX Deq: Join ACK 6 0.00 0.00
PX Deq Credit: send blkd 112 0.00 0.01
PX qref latch 7 0.00 0.00
PX Deq: Parse Reply 3 0.00 0.00
PX Deq: Execute Reply 604 1.96 364.42
log file sync 1 0.00 0.00
PX Deq: Signal ACK 1 0.00 0.00
latch: session allocation 2 0.00 0.00
Regards,user12121524 wrote:
CREATE INDEX ITEM_CATEGORIES_N2_BD9 ON ITEM_CATEGORIES_BD9(CATEGORY_SET_ID,
SR_CATEGORY_ID,ORGANIZATION_ID,SR_INSTANCE_ID) PARALLEL TABLESPACE MSCX
STORAGE( INITIAL 40960 NEXT 33554432 PCTINCREASE 0) PCTFREE 10 INITRANS 11
MAXTRANS 255
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 3 0 0
Execute 1 0.35 364.82 131168 117945 60324 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.35 364.83 131168 117948 60324 0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 80 (recursive depth: 2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
reliable message 1 0.00 0.00
enq: KO - fast object checkpoint 1 0.01 0.01
PX Deq: Join ACK 6 0.00 0.00
PX Deq Credit: send blkd 112 0.00 0.01
PX qref latch 7 0.00 0.00
PX Deq: Parse Reply 3 0.00 0.00
PX Deq: Execute Reply 604 1.96 364.42
log file sync 1 0.00 0.00
PX Deq: Signal ACK 1 0.00 0.00
latch: session allocation 2 0.00 0.00
What you've given us is the query co-ordinator trace, which basically tells us that the the coordinator waited 364 seconds for the PX slaves to tell it that they had completed their tasks ("PX Deq: Execute Reply" time). You need to look at the slave traces to find out where they spent their time - and that's probably not going to be easy if there are lots of parallel pieces of processing going on.
If you want to do some debugging (in general) one option is to add a query against V$pq_tqstat after each piece of parallel processing and log the results to a named file, or write them to a table with a tag, as this will tell you how many slaves were involved, how, and what the distribution of work and time was.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan -
Issue with background job--taking more time
Hi,
We have a custom program which runs as the background job. It runs every 2 hours.
Itu2019s taking more time than expected on ECC6 SR2 & SR3 on Oracle 10.2.0.4. We found that it taking more time while executing native SQL on DBA_EXTENTS. When we tried to fetch less number of records from DBA_EXTENTS, it works fine.
But we need the program to fetch all the records.
But it works fine on ECC5 on 10.2.0.2 & 10.2.0.4.
Here is the SQL statement:
EXEC SQL PERFORMING SAP_GET_EXT_PERF.
SELECT OWNER, SEGMENT_NAME, PARTITION_NAME,
SEGMENT_TYPE, TABLESPACE_NAME,
EXTENT_ID, FILE_ID, BLOCK_ID, BYTES
FROM SYS.DBA_EXTENTS
WHERE OWNER LIKE 'SAP%'
INTO
: EXTENTS_TBL-OWNER, :EXTENTS_TBL-SEGMENT_NAME,
:EXTENTS_TBL-PARTITION_NAME,
:EXTENTS_TBL-SEGMENT_TYPE , :EXTENTS_TBL-TABLESPACE_NAME,
:EXTENTS_TBL-EXTENT_ID, :EXTENTS_TBL-FILE_ID,
:EXTENTS_TBL-BLOCK_ID, :EXTENTS_TBL-BYTES
ENDEXEC.
Can somebody suggest what has to be done?
Has something changed in SAP7 (wrt background job etc) or do we need to fine tune the SQL statement?
Regards,
VivdhaHi,
there was an issue with LMT's but that was fixed in 10.2.0.4
besides missing system statistics:
But WHY do you collect every 2 hours this information? The dba_extents view is based on really heavy used system tables.
Normally , you would start queries of this type against dba_extents ie. to identify corrupt blocks and such:
SELECT owner , segment_name , segment_type
FROM dba_extents
WHERE file_id = &AFN
AND &BLOCKNO BETWEEN block_id AND block_id + blocks -1
Not sure what you want to achieve with it.
There are monitoring tools (OEM ?) around that may cover your needs.
Bye
yk -
Deletion of Data Mart Request taking more time
Hi all,
One of the Data Mart process(ODS to Infocube) has failed.
Im not able to delete the request in Infocube.
When delete option executed, its taking more time while im monitoring that job in SM37 and its not getting completed.
The details seen in the Job Log is as shown below,
Job started
Step 001 started (program RSDELPART1, variant &0000000006553, user ID SSRIN90)
Delete is running: Data target BUS_CONT, from 376,447 to 376,447
Please let me know your suggestions.
Thanks,
SowrabhHi,
How many records are there in that request. Usually when you try to delete out a request it takes more time. Depending on the data volume in the request the deletion time will vary.
Give it some more time and see if it finishes. To actually know if the job is doing anything, goto SM50/51 and look at whats happening.
Cheers,
Kedar -
Snapshot Refresh taking More Time
Dear All,
We are facing a Snapshot refresh problem currently in Production Environment.
Oracle Version : Oracle8i Enterprise Edition Release 8.1.6.1.0
Currently we have created a Snapshot on a Join with 2 remote tables using Synonyms.
ex:
CREATE SNAPSHOT XYZ REFRESH COMPLETE WITH ROWID
AS
SELECT a.* FROM SYN1 a, SYN2 b
Where b.ACCT_NO=a.ACCT_NO;
We have created a Index on the above Snapshot XYZ.
Create index XYZ_IDX1 on XYZ (ACCT_NO);
a. The Explain plan of the above query shows the Index Scan on SYN1.
If we query above Select Statement,it hardly takes 2 seconds to exedute.
b. But the Complete Refresh of Snapshot XYZ is almost taking 20 Mins for just truncating and inserting 500 records and is generating huge Disk Reads as SYN1 in remote table consists of 32 Million records whereas SYN2 contains only 500 Records.
If we truncate and insert inot a table as performed by the Complete refresh of Snapshot,it hardly takes 4 Seconds to refresh the table.
Please let me know what might be the possible reasons for the Complete refresh of Snapshot taking more time.Dear All,
While refreshing the Snapshot XYZ,I could find the following.
a. Sort/Merge operation was performed while inserting the data into Snapshot.
INSERT /*+ APPEND */ INTO "XYZ"
SELECT a.* FROM SYN1 a, SYN2 b Where b.ACCT_NO=a.ACCT_NO;
The above operation performed huge disk reads.
b. By Changing the session parameter sort_area_size ,the time decreased by 50% but still the disk reads are huge.
I would like to know why Sort/Merge Operation is performed in the above Insert?
Edited by: Prashanth Deshmukh on Mar 13, 2009 10:54 AM
Edited by: Prashanth Deshmukh on Mar 13, 2009 10:55 AM -
PGI Taking more time approximate 30 to 45 minutes
Dear Sir,
While doing post goods issue against delivery document system is taking lots of time, this issue is very very urgent can any one resolved or provide suitable solution for solving this issue.
We creates every day approximate 160 sales order / delivery and goods issue against the same by using transaction code VL06O system is taking more time for PGI.
Kindly provide suitable solution for the same.
Regards,
Vijay SanguriHello Vijay,
I've just found the SAP Note 1459217 which definitively refers to your issue. Please have a look on it (see below the respective SAP note text).
In case you have question let me know!
Best Regards,
Marcel Mizt
Symptom
Long runtimes occur when using transaction VL06G or VL06O in order to post goods issue (PGI) deliveries.
Poor response times occur when using transaction VL06G or VL06O in order to PGI deliveries.
Poor performance occurs with transaction VL06G / VL06O.
Performance issues occur with transaction VL06G / VL06O.
Environment
SAP R/3 All Release Levels
Reproducing the Issue
Execute transaction VL06O.
Choose "For Goods Issue". (Transaction VL06G).
Long runtimes occur.
Cause
There are too many documents in the database that need to be accessed.
The customising settings in the activity "set updating of partner index" are not activated.
(IMG -> Logistics Execution -> Shipping -> Delivery List -> Set Updating Of Partner Index).
Resolution
If there are too many documents in the database to access, archiving them improves the performance of VL06G.
The customising settings in the activity "set updating of partner index" can be updated to improve the performance of VL06G. (IMG -> Logistics Execution -> Shipping -> Delivery List -> Set Updating Of Partner Index). In this transaction, check the entries for the transaction group 6 (= delivery). The effect of these settings is that the table VLKPA (SD index: deliveries by partner functions) is only filled with entries based on the partner functions listed (for example WE = ship-to party). In transaction VL060 the system is checking this customising in order to access the table VBPA or VLKPA.
If you change the settings of the activity "updating of partner index", run the report RVV05IVB to reorganize the index seleting only partner index in the delivery section of the screen. (see note 128947).
Flag the checkbox "display forwarding agent" (available in the display options section of the selection screen). When the list is generated, use the "set filter" functionality (menu path: edit -> set filter) in order to select the deliveries correspondng to one forwarding agent. -
Post Goods Issue (VL06O) - taking more time approximate 30 to 45 minutes
Dear Sir,
While doing post goods issue against delivery document system is taking lots of time, this issue is very very urgent can any one resolved or provide suitable solution for solving this issue.
We creates every day approximate 160 sales order / delivery and goods issue against the same by using transaction code VL06O system is taking more time for PGI.
Kindly provide suitable solution for the same.
Regards,
Vijay SanguriHi
See Note 113048 - Collective note on delivery monitor and search notes related with performance.
Do a trace with tcode ST05 (look for help from a basis consultant) and search the bottleneck. Search possible sources of performance problems in userexits, enhancements and so on.
I hope this helps you
Regards
Eduardo -
Log applying service is taking more time in phy. Standby
Hi Gurus,
My Database version as follows
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
We have datagaurd setup as well - Huge archive logs are generating in our primary database - Archive logs are shipping to standby with no dealy - But applying the archive logs are taking more in our physical standby database - Can you please help me why it was taking more time to apply archivlogs (sync) in standby ? - What could be possible reasons..?
Note : Size of standby redo logs are same as redo log file of primary database - Also standy by redo one or more than online redo log primary.
I also confirmed from network guy for network issue - He said that network is good.
Please let me know if any other information required? - Since i need to report my higer leve stating this is cause for delay in applying archive logs.
ThanksNo we don't have delay option in log_archive_dest
here is alert log
edia Recovery Waiting for thread 1 sequence 42017 (in transit)
Thu Sep 19 09:00:09 2013
Recovery of Online Redo Log: Thread 1 Group 6 Seq 42017 Reading mem 0
Mem# 0: /xyz/u002/oradata/xyz/stb_redo/redo0601.log
Mem# 1: /xyz/u200/oradata/xyz/stb_redo/redo0601.log
Thu Sep 19 09:00:49 2013
RFS[1]: Successfully opened standby log 5: '/xyz/u002/oradata/xyz/stb_redo/redo0501.log'
Thu Sep 19 09:00:54 2013
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 7: '/xyz/u002/oradata/xyz/stb_redo/redo0701.log'
Thu Sep 19 09:00:58 2013
Media Recovery Waiting for thread 1 sequence 42018 (in transit)
Thu Sep 19 09:00:58 2013
Recovery of Online Redo Log: Thread 1 Group 5 Seq 42018 Reading mem 0
Mem# 0: /xyz/u002/oradata/xyz/stb_redo/redo0501.log
Mem# 1: /xyz/u200/oradata/xyz/stb_redo/redo0501.log
Media Recovery Waiting for thread 1 sequence 42019 (in transit)
Thu Sep 19 09:01:08 2013
Recovery of Online Redo Log: Thread 1 Group 7 Seq 42019 Reading mem 0
Mem# 0: /xyz/u002/oradata/xyz/stb_redo/redo0701.log
Mem# 1: /xyz/u200/oradata/xyz/stb_redo/redo0701.log
Thu Sep 19 09:01:08 2013
RFS[1]: Successfully opened standby log 5: '/xyz/u002/oradata/xyz/stb_redo/redo0501.log'
Thu Sep 19 09:01:22 2013
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 6: '/xyz/u002/oradata/xyz/stb_redo/redo0601.log'
Thu Sep 19 09:01:26 2013
RFS[1]: Successfully opened standby log 5: '/xyz/u002/oradata/xyz/stb_redo/redo0501.log'
Thu Sep 19 09:01:26 2013
Media Recovery Log /xyz/u002/oradata/xyz/arch/ARCH1_42020_821334023.LOG
Media Recovery Waiting for thread 1 sequence 42021 (in transit)
Thu Sep 19 09:01:30 2013
Recovery of Online Redo Log: Thread 1 Group 5 Seq 42021 Reading mem 0
Mem# 0: /xyz/u002/oradata/xyz/stb_redo/redo0501.log
Mem# 1: /xyz/u200/oradata/xyz/stb_redo/redo0501.log
Thu Sep 19 09:01:51 2013
Media Recovery Waiting for thread 1 sequence 42022 (in transit)
Thu Sep 19 09:01:51 2013
Recovery of Online Redo Log: Thread 1 Group 6 Seq 42022 Reading mem 0
Mem# 0: /xyz/u002/oradata/xyz/stb_redo/redo0601.log
Mem# 1: /xyz/u200/oradata/xyz/stb_redo/redo0601.log
Thu Sep 19 09:01:57 2013
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 5: '/xyz/u002/oradata/xyz/stb_redo/redo0501.log'
Thu Sep 19 09:02:01 2013
Media Recovery Waiting for thread 1 sequence 42023 (in transit)
Thu Sep 19 09:02:01 2013
Recovery of Online Redo Log: Thread 1 Group 5 Seq 42023 Reading mem 0
Mem# 0: /xyz/u002/oradata/xyz/stb_redo/redo0501.log
Mem# 1: /xyz/u200/oradata/xyz/stb_redo/redo0501.log -
Dear Gurus/Masters/All,
I request your valuble assistance in tuning one of my SQL.
We are using oracle 10.2.04 version and OS is HP-UX 11.23(ia64) version
In my production environment one SQL is taking more time to complete the task. According to EXPLAIN PLAN, i observed that one of it's WHERE condition execution is causing the issue.
I took the explain plan of the WHERE condition which is causing the issue. It is going for full table scan to satisfy the criteria. But a normal index exists on this column.
Main Query WHERE condition and Explain Plan.
SELECT column list ....
FROM
SIEBEL.S_ADDR_PER T1,
SIEBEL.S_PTY_PAY_PRFL T2,
SIEBEL.S_INVLOC T3,
SIEBEL.S_ORDER T4,
SIEBEL.S_ORG_EXT T5,
SIEBEL.S_POSTN T6,
SIEBEL.S_PARTY T7,
SIEBEL.S_PROJ T8,
SIEBEL.S_CON_ADDR T9,
SIEBEL.S_ORG_EXT T10,
SIEBEL.S_USER T11,
SIEBEL.S_DOC_QUOTE T12,
SIEBEL.S_ACCNT_POSTN T13,
SIEBEL.S_INS_CLAIM T14,
SIEBEL.S_USER T15,
SIEBEL.S_ORG_EXT T16,
SIEBEL.S_ASSET T17,
SIEBEL.S_ORDER_TNTX T18,
SIEBEL.S_ORG_EXT_TNTX T19,
SIEBEL.S_PERIOD T20,
SIEBEL.S_DEPOSIT_TNT T21,
SIEBEL.S_ADDR_PER T22,
SIEBEL.S_PAYMENT_TERM T23,
SIEBEL.S_ORG_EXT_X T24,
SIEBEL.S_ORG_EXT T25,
SIEBEL.S_INSCLM_ELMNT T26,
SIEBEL.S_INVOICE T27
WHERE
T25.BU_ID = T10.PAR_ROW_ID (+) AND
T26.INSCLM_ID = T14.ROW_ID (+) AND
T27.ELEMENT_ID = T26.ROW_ID (+) AND
T27.LAST_UPD_BY = T15.PAR_ROW_ID (+) AND
T4.QUOTE_ID = T12.ROW_ID (+) AND
T3.CG_ASSSET_ID = T17.ROW_ID (+) AND
T27.BL_ADDR_ID = T22.ROW_ID (+) AND
T8.BU_ID = T5.PAR_ROW_ID (+) AND
T27.PER_PAY_PRFL_ID = T2.ROW_ID (+) AND
T27.REMIT_ORG_EXT_ID = T16.PAR_ROW_ID (+) AND
T27.PROJ_ID = T8.ROW_ID (+) AND
T27.BL_PERIOD_ID = T20.ROW_ID (+) AND
T27.PAYMENT_TERM_ID = T23.ROW_ID (+) AND
T12.BU_ID = T19.PAR_ROW_ID (+) AND
T27.ACCNT_ID = T25.PAR_ROW_ID (+) AND
T27.ORDER_ID = T18.ROW_ID (+) AND
T4.SRC_INVLOC_ID = T3.ROW_ID (+) AND
T27.ORDER_ID = T4.ROW_ID (+) AND
T27.ACCNT_ID = T24.PAR_ROW_ID (+) AND
T18.PR_DEPOSIT_ID = T21.ROW_ID (+) AND
T27.BL_ADDR_ID = T9.ADDR_PER_ID (+) AND T27.ACCNT_ID = T9.ACCNT_ID (+) AND
T27.BL_ADDR_ID = T1.ROW_ID (+) AND
T25.PR_POSTN_ID = T13.POSITION_ID (+) AND T25.ROW_ID = T13.OU_EXT_ID (+) AND
T13.POSITION_ID = T7.ROW_ID (+) AND
T13.POSITION_ID = T6.PAR_ROW_ID (+) AND
T6.PR_EMP_ID = T11.PAR_ROW_ID (+) AND
(T27.INVC_TYPE_CD = :1)
ORDER BY
T27.INVC_DT;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2576210427
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 39M| 71G| | 624M (1)|278:42:59 |
| 1 | SORT ORDER BY | | 39M| 71G| 150G| 624M (1)|278:42:59 |
| 2 | NESTED LOOPS OUTER | | 39M| 71G| | 610M (1)|272:11:24 |
| 3 | NESTED LOOPS OUTER | | 39M| 70G| | 515M (1)|229:48:41 |
| 4 | NESTED LOOPS OUTER | | 39M| 69G| | 483M (1)|215:41:04 |
| 5 | NESTED LOOPS OUTER | | 39M| 68G| | 483M (1)|215:41:04 |
| 6 | NESTED LOOPS OUTER | | 39M| 67G| | 483M (1)|215:41:04 |
| 7 | NESTED LOOPS OUTER | | 39M| 66G| | 406M (1)|181:17:50 |
| 8 | NESTED LOOPS OUTER | | 39M| 65G| | 343M (1)|153:12:57 |
| 9 | NESTED LOOPS OUTER | | 39M| 64G| | 311M (1)|139:04:56 |
| 10 | NESTED LOOPS OUTER | | 39M| 63G| | 185M (1)| 82:37:56 |
| 11 | NESTED LOOPS OUTER | | 39M| 54G| | 108M (1)| 48:11:29 |
| 12 | NESTED LOOPS OUTER | | 39M| 53G| | 108M (1)| 48:11:29 |
| 13 | NESTED LOOPS OUTER | | 39M| 51G| | 76M (1)| 34:03:51 |
| 14 | NESTED LOOPS OUTER | | 39M| 49G| | 76M (1)| 34:03:51 |
| 15 | NESTED LOOPS OUTER | | 39M| 46G| | 76M (1)| 34:03:51 |
| 16 | NESTED LOOPS OUTER | | 39M| 44G| | 76M (1)| 34:03:51 |
| 17 | NESTED LOOPS OUTER | | 39M| 40G| | 65M (1)| 29:25:49 |
| 18 | NESTED LOOPS OUTER | | 39M| 39G| | 65M (1)| 29:25:49 |
| 19 | NESTED LOOPS OUTER | | 39M| 38G| | 65M (1)| 29:25:49 |
| 20 | NESTED LOOPS OUTER | | 39M| 34G| | 65M (1)| 29:17:44 |
| 21 | NESTED LOOPS OUTER | | 39M| 32G| | 65M (1)| 29:17:08 |
| 22 | NESTED LOOPS OUTER | | 39M| 31G| | 65M (1)| 29:09:04 |
| 23 | NESTED LOOPS OUTER | | 39M| 30G| | 2043K (9)| 00:54:42 |
| 24 | NESTED LOOPS OUTER | | 39M| 30G| | 2043K (9)| 00:54:42 |
| 25 | NESTED LOOPS OUTER | | 39M| 25G| | 2015K (7)| 00:53:57 |
| 26 | NESTED LOOPS OUTER | | 39M| 22G| | 2015K (7)| 00:53:57 |
| 27 | NESTED LOOPS OUTER | | 39M| 16G| | 2015K (7)| 00:53:57 |
|* 28 | TABLE ACCESS FULL | S_INVOICE | 39M| 9G| | 2015K (7)| 00:53:57 |
| 29 | TABLE ACCESS BY INDEX ROWID| S_PROJ | 1 | 188 | | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | S_PROJ_P1 | 1 | | | 1 (0)| 00:00:01 |
| 31 | TABLE ACCESS BY INDEX ROWID | S_PAYMENT_TERM | 1 | 156 | | 1 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | S_PAYMENT_TERM_P1 | 1 | | | 1 (0)| 00:00:01 |
| 33 | TABLE ACCESS BY INDEX ROWID | S_INSCLM_ELMNT | 1 | 77 | | 1 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | S_INSCLM_ELMNT_P1 | 1 | | | 1 (0)| 00:00:01 |
| 35 | TABLE ACCESS BY INDEX ROWID | S_INS_CLAIM | 1 | 134 | | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | S_INS_CLAIM_P1 | 1 | | | 1 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | S_PERIOD | 1 | 19 | | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | S_PERIOD_P1 | 1 | | | 1 (0)| 00:00:01 |
| 39 | TABLE ACCESS BY INDEX ROWID | S_USER | 1 | 25 | | 2 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | | 1 (0)| 00:00:01 |
| 41 | TABLE ACCESS BY INDEX ROWID | S_ORDER_TNTX | 1 | 26 | | 2 (0)| 00:00:01 |
|* 42 | INDEX UNIQUE SCAN | S_ORDER_TNTX_P1 | 1 | | | 1 (0)| 00:00:01 |
| 43 | TABLE ACCESS BY INDEX ROWID | S_DEPOSIT_TNT | 1 | 45 | | 1 (0)| 00:00:01 |
|* 44 | INDEX UNIQUE SCAN | S_DEPOSIT_TNT_P1 | 1 | | | 1 (0)| 00:00:01 |
| 45 | TABLE ACCESS BY INDEX ROWID | S_ORDER | 1 | 101 | | 2 (0)| 00:00:01 |
|* 46 | INDEX UNIQUE SCAN | S_ORDER_P1 | 1 | | | 1 (0)| 00:00:01 |
| 47 | TABLE ACCESS BY INDEX ROWID | S_INVLOC | 1 | 47 | | 1 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | S_INVLOC_P1 | 1 | | | 1 (0)| 00:00:01 |
| 49 | TABLE ACCESS BY INDEX ROWID | S_DOC_QUOTE | 1 | 21 | | 1 (0)| 00:00:01 |
|* 50 | INDEX UNIQUE SCAN | S_DOC_QUOTE_P1 | 1 | | | 1 (0)| 00:00:01 |
|* 51 | TABLE ACCESS FULL | S_ORG_EXT_TNTX | 1 | 94 | | 0 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_PTY_PAY_PRFL | 1 | 74 | | 1 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | S_PTY_PAY_PRFL_P1 | 1 | | | 1 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 84 | | 2 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 57 | | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | | 1 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 256 | | 2 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_ACCNT_POSTN | 1 | 32 | | 3 (0)| 00:00:01 |
|* 65 | INDEX RANGE SCAN | S_ACCNT_POSTN_U1 | 1 | | | 2 (0)| 00:00:01 |
| 66 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 21 | | 1 (0)| 00:00:01 |
|* 67 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | | 1 (0)| 00:00:01 |
| 68 | TABLE ACCESS BY INDEX ROWID | S_USER | 1 | 25 | | 2 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | | 1 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | | 2 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 72 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 1 | 24 | | 2 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | S_ASSET_P1 | 1 | | | 2 (0)| 00:00:01 |
| 74 | TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 1 | 36 | | 3 (0)| 00:00:01 |
|* 75 | INDEX RANGE SCAN | S_CON_ADDR_U1 | 1 | | | 2 (0)| 00:00:01 |
|* 76 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | 12 | | 1 (0)| 00:00:01 |
| 77 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 1 | 37 | | 2 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 1 | | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
28 - filter("T27"."INVC_TYPE_CD"=:1)
30 - access("T27"."PROJ_ID"="T8"."ROW_ID"(+))
32 - access("T27"."PAYMENT_TERM_ID"="T23"."ROW_ID"(+))
34 - access("T27"."ELEMENT_ID"="T26"."ROW_ID"(+))
36 - access("T26"."INSCLM_ID"="T14"."ROW_ID"(+))
38 - access("T27"."BL_PERIOD_ID"="T20"."ROW_ID"(+))
40 - access("T27"."LAST_UPD_BY"="T15"."PAR_ROW_ID"(+))
42 - access("T27"."ORDER_ID"="T18"."ROW_ID"(+))
44 - access("T18"."PR_DEPOSIT_ID"="T21"."ROW_ID"(+))
46 - access("T27"."ORDER_ID"="T4"."ROW_ID"(+))
48 - access("T4"."SRC_INVLOC_ID"="T3"."ROW_ID"(+))
50 - access("T4"."QUOTE_ID"="T12"."ROW_ID"(+))
51 - filter("T12"."BU_ID"="T19"."PAR_ROW_ID"(+))
53 - access("T27"."PER_PAY_PRFL_ID"="T2"."ROW_ID"(+))
55 - access("T27"."BL_ADDR_ID"="T1"."ROW_ID"(+))
57 - access("T27"."BL_ADDR_ID"="T22"."ROW_ID"(+))
59 - access("T8"."BU_ID"="T5"."PAR_ROW_ID"(+))
61 - access("T27"."REMIT_ORG_EXT_ID"="T16"."PAR_ROW_ID"(+))
63 - access("T27"."ACCNT_ID"="T25"."PAR_ROW_ID"(+))
65 - access("T25"."ROW_ID"="T13"."OU_EXT_ID"(+) AND "T25"."PR_POSTN_ID"="T13"."POSITION_ID"(+))
67 - access("T13"."POSITION_ID"="T6"."PAR_ROW_ID"(+))
69 - access("T6"."PR_EMP_ID"="T11"."PAR_ROW_ID"(+))
71 - access("T25"."BU_ID"="T10"."PAR_ROW_ID"(+))
73 - access("T3"."CG_ASSSET_ID"="T17"."ROW_ID"(+))
75 - access("T27"."BL_ADDR_ID"="T9"."ADDR_PER_ID"(+) AND "T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
filter("T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
76 - access("T13"."POSITION_ID"="T7"."ROW_ID"(+))
78 - access("T27"."ACCNT_ID"="T24"."PAR_ROW_ID"(+))
117 rows selected.SQL> EXPLAIN PLAN FOR
2 SELECT * FROM SIEBEL.S_INVOICE T27 WHERE T27.INVC_TYPE_CD=:1;
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 1810797629
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 39M| 9G| 2016K (8)| 00:53:59 |
|* 1 | TABLE ACCESS FULL| S_INVOICE | 39M| 9G| 2016K (8)| 00:53:59 |
Predicate Information (identified by operation id):
1 - filter("T27"."INVC_TYPE_CD"=:1)
13 rows selected.Edited by: KODS on Feb 13, 2013 1:08 PMDear Ivan,
Please find the details below.
select * from dba_indexes where index_name = 'S_INVOICE_U1';
OWNER INDEX_NAME INDEX_TYPE TABLE_OWNER TABLE_NAME TABLE_TYPE UNIQUENESS COMPRESSION PREFIX_LENGTH TABLESPACE_NAME INI_TRANS MAX_TRANS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE PCT_THRESHOLD INCLUDE_COLUMN FREELISTS FREELIST_GROUPS PCT_FREE LOGGING BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR STATUS NUM_ROWS SAMPLE_SIZE LAST_ANALYZED DEGREE INSTANCES PARTITIONED TEMPORARY GENERATED SECONDARY BUFFER_POOL USER_STATS DURATION PCT_DIRECT_ACCESS ITYP_OWNER ITYP_NAME PARAMETERS GLOBAL_STATS DOMIDX_STATUS DOMIDX_OPSTATUS FUNCIDX_STATUS JOIN_INDEX IOT_REDUNDANT_PKEY_ELIM DROPPED
SIEBEL S_INVOICE_U1 NORMAL SIEBEL S_INVOICE TABLE UNIQUE DISABLED CRMSBL_AEM_INDEX 2 255 65536 1 2147483645 10 NO 3 902796 196739390 1 1 125598294 VALID 196739390 196739390 10-02-13 1 1 NO N N N DEFAULT NO YES NO NO NO
select * from dba_ind_columns where index_name = 'S_INVOICE_U1' order by column_position;
INDEX_OWNER INDEX_NAME TABLE_OWNER TABLE_NAME COLUMN_NAME COLUMN_POSITION COLUMN_LENGTH CHAR_LENGTH DESCEND
SIEBEL S_INVOICE_U1 SIEBEL S_INVOICE INVC_NUM 1 200 50 ASC
SIEBEL S_INVOICE_U1 SIEBEL S_INVOICE INVC_TYPE_CD 2 120 30 ASC
SIEBEL S_INVOICE_U1 SIEBEL S_INVOICE CONFLICT_ID 3 60 15 ASC -
Oracle 11g: Oracle insert/update operation is taking more time.
Hello All,
In Oracle 11g (Windows 2008 32 bit environment) we are facing following issue.
1) We are inserting/updating data on some tables (4-5 tables and we are firing query with very high rate).
2) After sometime (say 15 days with same load) we are feeling that the Oracle operation (insert/update) is taking more time.
Query1: How to find actually oracle is taking more time in insert/updates operation.
Query2: How to rectify the problem.
We are having multithread environment.
Thanks
With Regards
Hemant.Liron Amitzi wrote:
Hi Nicolas,
Just a short explanation:
If you have a table with 1 column (let's say a number). The table is empty and you have an index on the column.
When you insert a row, the value of the column will be inserted to the index. To insert 1 value to an index with 10 values in it will be fast. It will take longer to insert 1 value to an index with 1 million values in it.
My second example was if I take the same table and let's say I insert 10 rows and delete the previous 10 from the table. I always have 10 rows in the table so the index should be small. But this is not correct. If I insert values 1-10 and then delete 1-10 and insert 11-20, then delete 11-20 and insert 21-30 and so on, because the index is sorted, where 1-10 were stored I'll now have empty spots. Oracle will not fill them up. So the index will become larger and larger as I insert more rows (even though I delete the old ones).
The solution here is simply revuild the index once in a while.
Hope it is clear.
Liron Amitzi
Senior DBA consultant
[www.dbsnaps.com]
[www.orbiumsoftware.com]Hmmm, index space not reused ? Index rebuild once a while ? That was what I understood from your previous post, but nothing is less sure.
This is a misconception of how indexes are working.
I would suggest the reading of the following interasting doc, they are a lot of nice examples (including index space reuse) to understand, and in conclusion :
http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth.pdf
"+Index Rebuild Summary+
+•*The vast majority of indexes do not require rebuilding*+
+•Oracle B-tree indexes can become “unbalanced” and need to be rebuilt is a myth+
+•*Deleted space in an index is “deadwood” and over time requires the index to be rebuilt is a myth*+
+•If an index reaches “x” number of levels, it becomes inefficient and requires the index to be rebuilt is a myth+
+•If an index has a poor clustering factor, the index needs to be rebuilt is a myth+
+•To improve performance, indexes need to be regularly rebuilt is a myth+"
Good reading,
Nicolas. -
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
Maybe you are looking for
-
The connections are very slow and when I log into the server monitor instead of showing an ip address for the client, it lists it as "broadcasthost" instead of an ip address. How do I get the connection to show the ip address correctly? Any help is a
-
Hi, We have this plant which does not do any inhouse manufacturing. whta they do is inbound procurement against Sales orders or Forecast and Sell it to customers(trade). However they need MRP also for this senario to calculate the requirement dates n
-
Says I'm missing files for ps Should I uninstall then reinstall?
Some of the application components are missing from the application directory, Please reinstall the application. I tried to but it says I already have it installed so do I need to uninstall it?
-
Creating Customized Table and Modify Table Maintenance Screen
Hi, I have already created customized table and generate the table maintenance screen, however i encountered 1 problem which is i cannot add new PAI and PBO module in the flow logic. Every time i wanna add new module, i will be getting error message
-
Uninstall Norton Virus & Utilities from OS X (10.2.8)
What is the procedure for doing this? Which are the key Norton files to delete? Regards Graham