Disco Plus 10g Performance Issue When Moving Table Headings to Page Items

Hello,
We are experiencing an performance anomaly in Discoverer Plus (the latest release: 10.1.2.48.18), and are wondering if anyone else out there has noticed similar behavior. We're having trouble identifying the cause, and have a TAR openned with Oracle support but they are not able to reproduce our issue, and have been slow to offer suggestions or help.
The issue happens when a user drags a table heading up into the page items area in a worksheet. When we move a heading up to the page items it works quickly one time, but then, every time after that, it takes anywhere from a few minutes up to HOURS to move any additional headings up to the page items area.
The problem occurrs on approximately 3 out of every 5 of our workbooks. We've tried different sizes of workbooks, with large (several million records) and small (a few thousand records) datasets, and none of this seems to affect the issue at hand. The problem only occurs in Discoverer Plus, not Desktop. We've also spent some time researching caching and memory configuration, and believe that we have setup all of the recommended options for maximum performance on our systems.
I would just like to know if anyone else out there in the community has experienced the same issue, and if anyone has any advice for us.
Thank you,
-Scott

Hi,
I found the following on Best Practices of Orcle Discoverer 10g by
Mike Donohue - Product Management - Oracle Business Intelligence
Performance Parameters and Page Items
Page Items provide very responsive, interactive manipulation of data
At a cost:
Forces retrieval of all Detail values
Incremental increases of memory as indices are built
Parameters reduce result set, improve performance
Use Page Items only when needed 2 to 3 with < 12 values each
Performance Parameters and Page Items - example
Loc(3), Dept(10), ProdType(50), Prod(1,000), Date(365)
547,500,000 potential rows/combinations (3*10*50*1000*365)
Use parameters for Loc, Dept, ProdType, and 90 day date range
90,000 potential rows/combinations (1000*90)
Reduce data retrieved by ~ 6000 X
Improve performance by several orders of magnitude
I hope this will help you!

Similar Messages

Performance issue when moving from 4.6c to 6.0

Looks like we took a performance hit when moving from 4.6c to 6.0 on the same hardware.
For example, our PGI on outbound deliveries now takes several seconds longer in 6.0 then it did in 4.6c. We've noticed other SAP area's are taking longer as well. With an ST05 sql trace on the PGI in 6.0, we see more tables being accessed, same tables being access differently taking longer. All leading to more time to do a PGI in 6.0.
Has anyone else noticed this increase in Response time when upgrading to 6.0 ?
Thanks,
David

Hello.
Yes, in our system we noticed the same thing at start. The general performance seemed to get worse after upgrading. In fact, database became bigger and more memory is consumed. However, it was tuned up by our system administrator and now seems ok.
Run the optimizer statistics and see if it get's better.
Regards.
Valter Oliveira.

Oracle Retail 13 - Performance issues when open, save, approving worksheets

Hi Guys,
Recently we started facing performance issues when we started working with Oracle Retail 13 worksheets from within the java GUI at clients desktops.
We run Oracle Retail 13.1 powered by Oracle Database 11g R1 and AS 10g in latest release.
Issues:
- Opening, saving, approving worksheets with approx 9 thousands of items takes up to 15 minutes.
- Time for smaller worksheets is also around 10 minutes just to open a worksheet
- Also just to open multiple worksheets takes "ages" up to 10-15 minuts
Questions:
- Is it expected performance for such worksheets?
- What is your experience with Oracle Retail 13 in terms of performance while working with worksheets - how much time does it normally take to open edit save a worksheet?
- What are the average expected times for such operations?
Any feedback and hints would be much appreciated.
Cheers!!

Hi,
I guess you mean Order/Buyer worksheets?
This is not normal, should be quicker, matter of seconds to at most a minute.
Database side tuning is where I would look for clues.
And the obvious question: remember any changes to anything that may have caused the issue? Are the table and index statistics freshly gathered?
Best regards, Erik Ykema

Performance issues when creating a Report / Query in Discoverer

Hi forum,
Hope you are can help, it involves a performance issues when creating a Report / Query.
I have a Discoverer Report that currently takes less than 5 seconds to run. After I add a condition to bring back Batch Status that = Posted we cancelled the query after reaching 20 minutes as this is way too long. If I remove the condition the query time goes back to less than 5 seconds.
Please see attached the SQL Inspector Plan:
Before Condition
SELECT STATEMENT
SORT GROUP BY
VIEW SYS
SORT GROUP BY
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID GL.GL_CODE_COMBINATIONS
AND-EQUAL
INDEX RANGE SCAN GL.GL_CODE_COMBINATIONS_N2
INDEX RANGE SCAN GL.GL_CODE_COMBINATIONS_N1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES
INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUES_N1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUE_SETS
INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUE_SETS_U1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES_TL
INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUES_TL_U1
INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUE_NORM_HIER_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_LINES
INDEX RANGE SCAN GL.GL_JE_LINES_N1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
TABLE ACCESS BY INDEX ROWID GL.GL_JE_HEADERS
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_DAILY_CONVERSION_TYPES_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_SOURCES_TL
INDEX UNIQUE SCAN GL.GL_JE_SOURCES_TL_U1
INDEX UNIQUE SCAN GL.GL_JE_CATEGORIES_TL_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
INDEX UNIQUE SCAN GL.GL_BUDGET_VERSIONS_U1
INDEX UNIQUE SCAN GL.GL_ENCUMBRANCE_TYPES_U1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
TABLE ACCESS BY INDEX ROWID GL.GL_JE_BATCHES
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
TABLE ACCESS BY INDEX ROWID GL.GL_PERIODS
INDEX RANGE SCAN GL.GL_PERIODS_U1
After Condition
SELECT STATEMENT
SORT GROUP BY
VIEW SYS
SORT GROUP BY
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS
TABLE ACCESS FULL GL.GL_JE_BATCHES
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_HEADERS
INDEX RANGE SCAN GL.GL_JE_HEADERS_N1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
INDEX UNIQUE SCAN GL.GL_ENCUMBRANCE_TYPES_U1
INDEX UNIQUE SCAN GL.GL_DAILY_CONVERSION_TYPES_U1
INDEX UNIQUE SCAN GL.GL_BUDGET_VERSIONS_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_SOURCES_TL
INDEX UNIQUE SCAN GL.GL_JE_SOURCES_TL_U1
INDEX UNIQUE SCAN GL.GL_JE_CATEGORIES_TL_U1
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_LINES
INDEX RANGE SCAN GL.GL_JE_LINES_U1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
TABLE ACCESS BY INDEX ROWID GL.GL_CODE_COMBINATIONS
INDEX UNIQUE SCAN GL.GL_CODE_COMBINATIONS_U1
TABLE ACCESS BY INDEX ROWID GL.GL_PERIODS
INDEX RANGE SCAN GL.GL_PERIODS_U1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES
INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUES_N1
INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUE_NORM_HIER_U1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES_TL
INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUES_TL_U1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUE_SETS
INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUE_SETS_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
Is there anything i can do in Discoverer Desktop / Administration to avoid this problem.
Many thanks,
Lance

Hi Rod,
I've tried the condition (Batch Status||'' = 'Posted') as you suggested, but the qeury time is still over 20 mins. To test i changed it to (Batch Status||'' = 'Unposted') and the query was returned within seconds again.
Ive been doing some more digging and have found the database view that is linked to the Journal Batches folder. See below.
I think the problem is with the column using DECODE. When querying the column in TOAD the value of P is returned. But in discoverer the condition is done on the value Posted. Im not too sure how DECODE works, but think this could be the causing some sort of issue with Full Table Scans. How do we get around this?
Lance
DECODE( JOURNAL_BATCH1.STATUS,
'+', 'Unable to validate or create CTA',
'+*', 'Was unable to validate or create CTA',
'-','Invalid or inactive rounding differences account in journal entry',
'-*', 'Modified invalid or inactive rounding differences account in journal entry',
'<', 'Showing sequence assignment failure',
'<*', 'Was showing sequence assignment failure',
'>', 'Showing cutoff rule violation',
'>*', 'Was showing cutoff rule violation',
'A', 'Journal batch failed funds reservation',
'A*', 'Journal batch previously failed funds reservation',
'AU', 'Showing batch with unopened period',
'B', 'Showing batch control total violation',
'B*', 'Was showing batch control total violation',
'BF', 'Showing batch with frozen or inactive budget',
'BU', 'Showing batch with unopened budget year',
'C', 'Showing unopened reporting period',
'C*', 'Was showing unopened reporting period',
'D', 'Selected for posting to an unopened period',
'D*', 'Was selected for posting to an unopened period',
'E', 'Showing no journal entries for this batch',
'E*', 'Was showing no journal entries for this batch',
'EU', 'Showing batch with unopened encumbrance year',
'F', 'Showing unopened reporting encumbrance year',
'F*', 'Was showing unopened reporting encumbrance year',
'G', 'Showing journal entry with invalid or inactive suspense account',
'G*', 'Was showing journal entry with invalid or inactive suspense account',
'H', 'Showing encumbrance journal entry with invalid or inactive reserve account',
'H*', 'Was showing encumbrance journal entry with invalid or inactive reserve account',
'I', 'In the process of being posted',
'J', 'Showing journal control total violation',
'J*', 'Was showing journal control total violation',
'K', 'Showing unbalanced intercompany journal entry',
'K*', 'Was showing unbalanced intercompany journal entry',
'L', 'Showing unbalanced journal entry by account category',
'L*', 'Was showing unbalanced journal entry by account category',
'M', 'Showing multiple problems preventing posting of batch',
'M*', 'Was showing multiple problems preventing posting of batch',
'N', 'Journal produced error during intercompany balance processing',
'N*', 'Journal produced error during intercompany balance processing',
'O', 'Unable to convert amounts into reporting currency',
'O*', 'Was unable to convert amounts into reporting currency',
'P', 'Posted',
'Q', 'Showing untaxed journal entry',
'Q*', 'Was showing untaxed journal entry',
'R', 'Showing unbalanced encumbrance entry without reserve account',
'R*', 'Was showing unbalanced encumbrance entry without reserve account',
'S', 'Already selected for posting',
'T', 'Showing invalid period and conversion information for this batch',
'T*', 'Was showing invalid period and conversion information for this batch',
'U', 'Unposted',
'V', 'Journal batch is unapproved',
'V*', 'Journal batch was unapproved',
'W', 'Showing an encumbrance journal entry with no encumbrance type',
'W*', 'Was showing an encumbrance journal entry with no encumbrance type',
'X', 'Showing an unbalanced journal entry but suspense not allowed',
'X*', 'Was showing an unbalanced journal entry but suspense not allowed',
'Z', 'Showing invalid journal entry lines or no journal entry lines',
'Z*', 'Was showing invalid journal entry lines or no journal entry lines', NULL ),

Performance issue with COEP table in ECC 6

Hi,,
Any idea how to resonlve performance issue on COEP table in ECC6.0
We are not using COEP table right now. this table occupies 100gb of 900 gb in PRD system.
Can i directly archive/delete the table?
Regards
Siva

Hi Siva,
You cannot archive COEP table alone. It should be archived along with the respective archive object. Just deleting the table is not at all a good idea.
For finding out the appropriate archive object contributing to the entries in COEP, you need to perform CO table analysis using programs RARCCOA1 and RARCCOA2. For further informaton refer to SAP note 138688.
Hope this helps,
Naveen

Performance Issues when editing large PDFs

We are using Adobe 9 and X Professional and are experiencing performance issues when attempting to edit large PDF files. (Windows 7 OS). When editing PDFs that are 200+ pages, we are seeing pregnated pauses (that feel like lockups), slow open times and slow to print issues.
Are there any tips or tricks with regard to working with these large documents that would improve performance?

You said "edit." If you are talking about actual editing, that should be done in the original and a new PDF created. Acrobat is not a very good editing tool and should only be used for minor, critical edits.
If you are talking about simply using the PDF, a lot depends on the structure of the PDF. If it is full of graphics, it will be slow. You can improve this performance by using the PDF Optimize to reduce graphic resolution and such. You may very likely have a bloated PDF that is causing the problem and optimizing the structure should help.
Be sure to work on a copy.

Performance issue when a Direct I/O option is selected

Hello Experts,
One of my customers has a performance issue when a Direct I/O option is selected. Reports that there was increase in memory usage when Direct I/O storage option is selected when compared to Buffered I/O option.
There are two applications on the server of type BSO. When using Buffered I/O, experienced a high level of Read and Write I/O's. Using Direct I/O reduces the Read and Write I/O's, but dramatically increases memory usage.
Other Information -
a) Environment Details
HSS - 9.3.1.0.45, AAS - 9.3.1.0.0.135, Essbase - 9.3.1.2.00 (64-bit)
OS: Microsoft Windows x64 (64-bit) 2003 R2
b) What is the memory usage when Buffered I/O and Direct I/O is used? How about running calculations, database restructures, and database queries? Do these processes take much time for execution?
Application 1: Buffered 700MB, Direct 5GB
Application 2: Buffered 600MB to 1.5GB, Direct 2GB
Calculation times may increase from 15 minutes to 4 hours. Same with restructure.
c) What is the current Database Data cache; Data file cache and Index cache values?
Application 1: Buffered (Index 80MB, Data 400MB), Direct (Index 120MB; Data File 4GB, Data 480MB).
Application 2: Buffered (Index 100MB, Data 300MB), Direct (Index 700MB, Data File 1.5GB, Data 300MB)
d) What is the total size of the ess0000x.pag files and ess0000x.ind files?
Application 1: Page File 20GB, Index 1.7GB.
Application 2: Page 3GB, index 700MB.
Any suggestions on how to improve the performance when Direct I/O is selected? Any performance documents relating to above scenario would be of great help.
Thanks in advance.
Regards,
Sudhir

Sudhir,
Do you work at a help desk or are you a consultant? you ask such a varied range of questions I think the former. If you do work at a help desk, don't you have a next level support that could help you? If you are a consultant, I suggest getting together with another consultant that actually knows more. You might also want to close some of your questions,. You have 24 open and perhaps give points to those that helped you.

Error message when moving to a different page

Post Author: EvDev
CA Forum: .NET
I have an ASP.NET 2.0 and Crystal Reports 11.5 project that works fine
when it's being debugged and when it's on our test server, but when we move it
to our production server the user will receive an error message when moving to a
different page of the report. It's an
"Object reference not set to an instance of an object". It seems very
odd for me for something to work on the test server but not on production. Has
anyone seen this before? Thanks

Hi there,
This does seem like a very valid process to be sure
I'm guessing that the fix is shown in "Solution 1" in this doc;
http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_tech_note09186a0080b04158.shtml
Cheers!
Rob

Performance issue when using select count on large tables

Hello Experts,
I have a requirement where i need to get count of data from a database table.Later on i need to display the count in ALV format.
As per my requirement, I have to use this select count inside a nested loops.
Below is the count snippet:
LOOP at systems assigning <fs_sc_systems>.
LOOP at date assigning <fs_sc_date>.
SELECT COUNT( DISTINCT crmd_orderadm_i~header )
 FROM crmd_orderadm_i
 INNER JOIN bbp_pdigp
 ON crmd_orderadm_iclient EQ bbp_pdigpclient "MANDT is referred as client
 AND crmd_orderadm_iguid EQ bbp_pdigpguid
 INTO w_sc_count
WHERE crmd_orderadm_i~created_at BETWEEN <fs_sc_date>-start_timestamp
 AND <fs_sc_date>-end_timestamp
 AND bbp_pdigp~zz_scsys EQ <fs_sc_systems>-sys_name.
endloop.
endloop.
In the above code snippet,
<fs_sc_systems>-sys_name is having the system name,
<fs_sc_date>-start_timestamp is having the start date of month
and <fs_sc_date>-end_timestamp is the end date of month.
Also the data in tables crmd_orderadm_i and bbp_pdigp is very large and it increases every day.
Now,the above select query is taking a lot of time to give the count due to which i am facing performance issues.
Can any one pls help me out to optimize this code.
Thanks,
Suman

Hi Choudhary Suman ,
Try this:
SELECT crmd_orderadm_i~header
INTO it_header " interna table
FROM crmd_orderadm_i
INNER JOIN bbp_pdigp
 ON crmd_orderadm_iclient EQ bbp_pdigpclient
 AND crmd_orderadm_iguid EQ bbp_pdigpguid
 FOR ALL ENTRIES IN date
WHERE crmd_orderadm_i~created_at BETWEEN date-start_timestamp
 AND date-end_timestamp
 AND bbp_pdigp~zz_scsys EQ date-sys_name.
 SORT it_header BY header.
 DELETE ADJACENT DUPLICATES FROM it_header
 COMPARING header.
 describe table it_header lines v_lines.
Hope this information is help to you.
Regards,
José

Oracle 10g performance issues

Hi,
We were using Oracle 9i in Solaris 5.8 and it was working fine with some minor performance issues. We formatted the Solaris server with new Solaris 5.10 and installed Oracle 10g.
Now we are experiencing some performance issues in Oracle 10g. This issue is arising when using through Websphere 5.1.
We have analyzed the schema, index is rebuild, SGA is 4.5 GB, PGA is 2.0 GB, Solaris RAM is 16 GB. Also we are having some Mat Views (possibly this may cause performance issues - not sure) due to refresh.
Also I have changed some parameters in init.ora file like query_rewrite = STALE_TOLERATED, open_cursors = 1500 etc.
Is is something due to driver from which the data is accessed. I guess it is not utilizing the indexes on the table.
Can anyone please suggest, what could be the issue ?

There are a lot of changes to the optimizer in the upgrade from 9i to 10g, and you need to be aware of them. There are also a number of changes to the default stats collection mechanism, so after your upgrade your statistics (hence execution paths) could change dramatically.


Greg Rahn has a useful entry on his blog about stats collection, and the blog al,so points to an Oracle white paper which will give you a lot of ideas about where the optimizer changes - which may help you spot your critical issues.

Otherwise, follow triggb's advice about using Statspack to find the SQL that is the most expensive - it's reasonably likely to be this SQL that has changed execution plans in the upgrade.

Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Performance issues with pipelined table functions

I am testing pipelined table functions to be able to re-use the base_query function. Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline procedure. Am I missing something? The processor function is from [url http://www.oracle-developer.net/display.php?id=429]improving performance with pipelined table functions .
Edit: The underlying query returns 500,000 rows in about 3 minutes. So there are are no performance issues with the query itself.
Many thanks in advance.
CREATE OR REPLACE PACKAGE pipeline_example
IS
 TYPE resultset_typ IS REF CURSOR;
 TYPE row_typ IS RECORD (colC VARCHAR2(200), colD VARCHAR2(200), colE VARCHAR2(200));
 TYPE table_typ IS TABLE OF row_typ;
 FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
 RETURN resultset_typ;
 c_default_limit CONSTANT PLS_INTEGER := 100;
 FUNCTION processor (
 p_source_data IN resultset_typ,
 p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
 RETURN table_typ
 PIPELINED
 PARALLEL_ENABLE(PARTITION p_source_data BY ANY);
 PROCEDURE with_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ);
 PROCEDURE no_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ);
END pipeline_example;
CREATE OR REPLACE PACKAGE BODY pipeline_example
IS
 FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
 RETURN resultset_typ
 IS
 o_resultset resultset_typ;
 BEGIN
 OPEN o_resultset FOR
 SELECT colC, colD, colE
 FROM some_table
 WHERE colA = ArgA AND colB = argB;
 RETURN o_resultset;
 END base_query;
 FUNCTION processor (
 p_source_data IN resultset_typ,
 p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
 RETURN table_typ
 PIPELINED
 PARALLEL_ENABLE(PARTITION p_source_data BY ANY)
 IS
 aa_source_data table_typ;-- := table_typ ();
 BEGIN
 LOOP
 FETCH p_source_data
 BULK COLLECT INTO aa_source_data
 LIMIT p_limit_size;
 EXIT WHEN aa_source_data.COUNT = 0;
 /* Process the batch of (p_limit_size) records... */
 FOR i IN 1 .. aa_source_data.COUNT
 LOOP
 PIPE ROW (aa_source_data (i));
 END LOOP;
 END LOOP;
 CLOSE p_source_data;
 RETURN;
 END processor;
 PROCEDURE with_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ)
 IS
 BEGIN
 OPEN o_resultset FOR
 SELECT /*+ PARALLEL(t, 5) */ colC,
 SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
 SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
 SUM (CASE WHEN colD = colE AND colD != '0' THEN '1' END) de_one,
 SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
 FROM TABLE (processor (base_query (argA, argB),100)) t
 GROUP BY colC
 ORDER BY colC
 END with_pipeline;
 PROCEDURE no_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ)
 IS
 BEGIN
 OPEN o_resultset FOR
 SELECT colC,
 SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
 SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
 SUM (CASE WHEN colD = colE AND colD != '0' THEN 1 END) de_one,
 SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
 FROM (SELECT colC, colD, colE
 FROM some_table
 WHERE colA = ArgA AND colB = argB)
 GROUP BY colC
 ORDER BY colC;
 END no_pipeline;
END pipeline_example;
ALTER PACKAGE pipeline_example COMPILE;Edited by: Earthlink on Nov 14, 2010 9:47 AM
Edited by: Earthlink on Nov 14, 2010 11:31 AM
Edited by: Earthlink on Nov 14, 2010 11:32 AM
Edited by: Earthlink on Nov 20, 2010 12:04 PM
Edited by: Earthlink on Nov 20, 2010 12:54 PM

Earthlink wrote:
Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline procedure. Am I missing something? Well, we're missing a lot here.
Like:
- a database version
- how did you test
- what data do you have, how is it distributed, indexed
and so on.
If you want to find out what's going on then use a TRACE with wait events.
All nessecary steps are explained in these threads:
HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
Another nice one is RUNSTATS:
http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701

How to Improve performance issue when we are using BRM LDB

HI All,
I am facing a performanc eissue when i am retriving the data from BKPF and respective BSEG table....I see that for fiscal period there are around 60lakhs records. and to populate the data value from the table to final internal table its taking so much of time.
when i tried to make use of the BRM LDB with the SAP Query/Quickviewer, its the same issue.
Please suggest me how to improve the performance issue.
Thanks in advance
Chakradhar

Moderator message - Please see Please Read before Posting in the Performance and Tuning Forum before posting - post locked
Rob

How to get around a performance issue when dealing with a lot of data

Hello All,
This is an academic question really, I'm not sure what I'm going to do with my issue, but I have some options. I was wondering if anyone would like to throw in their two cents on what they would do.
I have a report, the users want to see all agreements and all conditions related to the updating of rebates and the affected invoices. From a technical perspective ENT6038-KONV-KONP-KONA-KNA1. THese are the tables I have to hit. The problem is that when they retroactively update rebate conditions they can hit thousands of invoices, which blossoms out to thousands of conditions...you see the problem. I simply have too much data to grab, it times out.
I've tried everything around the code. If you have a better way to get price conditions and agreement numbers off of thousands of invoices, please let me know what that is.
I have a couple of options.
1) Use shared memory to preload the data for the report. This would work, but I'm not going to know what data is needed to be loaded until report run time. They put in a date. I simply can't preload everything. I don't like this option much.
2) Write a function module to do this work. When the user clicks on the button to get this particular data, it will launch the FM in background and e-mail them the results. As you know, the background job won't time out. So far this is my favored option.
Any other ideas?
Oh...nope, BI is not an option, we don't have it. I know, I'm not happy about it. We do have a data warehouse, but the prospect of working with that group makes me whince.

My two cents - firstly totally agree with Derick that its probably a good idea to go back to the business and justify their requirement in regards to reporting and "whether any user can meaningfully process all those results in an aggregate". But having dealt with customers across industries over a long period of time, it would probably be bit fanciful to expect them to change their requirements too much as in my experience neither do they understand (too much) technology nor they want to hear about technical limitations for a system etc. They want what they want if possible yesterday!
So, about dealing with performance issues within ABAP, I'm sure you must be already using efficient programming techniques like using Hash internal tables with Unique Keys, accessing rows of the table using Field-Symbols and all that but what I was going to suggest to you is probably look at using [Extracts|http://help.sap.com/saphelp_nw04/helpdata/en/9f/db9ed135c111d1829f0000e829fbfe/content.htm]. I've had to deal with this couple of times in the past when dealing with massive amount of data and I found it to be very efficient in regards to performance. A good point to remember when using Extracts that, I quote from SAP Help, "The size of an extract dataset is, in principle, unlimited. Extracts larger than 500KB are stored in operating system files. The practical size of an extract is up to 2GB, as long as there is enough space in the filesystem."
Hope this helps,
Cheers,
Sougata.

Performance Issue After Moving To 11g From 9i

We have a process that inserts approximately 275,000 records into a table containing 22,000,000+ records. This process consistently runs in 1 hour and 20 minutes in our Oracle 9i Database (Standard Edition). This same process runs in 8+ hours in our Oracle 11g Database (Standard Edition) which is a copy of the Oracle 9i Database.
Both databases run on identical hardware running Windows Server 2000. The Servers each have 2 GB RAM.
We have noticed that the process in 11g slows down significantly after it has been running for about 30 minutes and is continuously consuming memory. We also ran a test in which we dropped all indexes on the table being inserted into except the primary key and the process still ran for 8+ hours again.
We executed another test in which the same process was run however we had it insert into a table that contained 0 records and our performance was better than on the 9i Database.
Any ideas on what might be causing the performance issue?

Welcome to the forums !
Troubleshooting performance issues is difficult when all of the factual data is absent. Pl review these threads to identify information that you need to post in order to help you.
When your query takes too long:
HOW TO: Post a SQL statement tuning request - template posting
When your query takes too long ...
HTH
Srini

Insert performance issue with Partitioned Table.....

Hi All,
I have a performance issue during with a table which is partitioned. without table being partitioned
it ran in less time but after partition it took more than double.
1) The table was created initially without any partition and the below insert took only 27 minuts.
Total Rec Inserted :- 2424233
PL/SQL procedure successfully completed.
Elapsed: 00:27:35.20
2) Now I re-created the table with partition(range yearly - below) and the same insert took 59 minuts.
Is there anyway i can achive the better performance during insert on this partitioned table?
[ similerly, I have another table with 50 Million records and the insert took 10 hrs without partition.
with partitioning the table, it took 18 hours... ]
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4195045590
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 643K| 34M| | 12917 (3)| 00:02:36 |
|* 1 | HASH JOIN | | 643K| 34M| 2112K| 12917 (3)| 00:02:36 |
| 2 | VIEW | index$_join$_001 | 69534 | 1290K| | 529 (3)| 00:00:07 |
|* 3 | HASH JOIN | | | | | | |
| 4 | INDEX FAST FULL SCAN| PK_ACCOUNT_MASTER_BASE | 69534 | 1290K| | 181 (3)| 00:00
| 5 | INDEX FAST FULL SCAN| ACCOUNT_MASTER_BASE_IDX2 | 69534 | 1290K| | 474 (2)| 00:00
PLAN_TABLE_OUTPUT
| 6 | TABLE ACCESS FULL | TB_SISADMIN_BALANCE | 2424K| 87M| | 6413 (4)| 00:01:17 |
Predicate Information (identified by operation id):
1 - access("A"."VENDOR_ACCT_NBR"=SUBSTR("B"."ACCOUNT_NO",1,8) AND
"A"."VENDOR_CD"="B"."COMPANY_NO")
3 - access(ROWID=ROWID)
Open C1;
Loop
Fetch C1 Bulk Collect Into C_Rectype Limit 10000;
Forall I In 1..C_Rectype.Count
Insert test
     col1,col2,col3)
Values
     val1, val2,val3);
V_Rec := V_Rec + Nvl(C_Rectype.Count,0);
Commit;
Exit When C_Rectype.Count = 0;
C_Rectype.delete;
End Loop;
End;
Total Rec Inserted :- 2424233
PL/SQL procedure successfully completed.
Elapsed: 00:51:01.22
Edited by: user520824 on Jul 16, 2010 9:16 AM

I'm concerned about the view in step 2 and the index join in step 3. A composite index with both columns might eliminate the index join and result in fewer read operations.
If you know which partition the data is going into beforehand you can save a little bit of processing by specifying the partition (which may not be a scalable long-term solution) in the insert - I'm not 100% sure you can do this on inserts but I know you can on selects.
The APPEND hint won't help the way you are using it - the VALUES clause in an insert makes it be ignored. Where it is effective and should help you is if you can do the insert in one query - insert into/select from. If you are using the loop to avoid filling up undo/rollback you can use a bulk collect to batch the selects and commit accordingly - but don't commit more often than you have to because more frequent commits slow transactions down.
I don't think there is a nologging hint :)
So, try something like
insert /*+ hints */ into ...
Select
     A.Ing_Acct_Nbr, currency_Symbol,
     Balance_Date,     Company_No,
     Substr(Account_No,1,8) Account_No,
     Substr(Account_No,9,1) Typ_Cd ,
     Substr(Account_No,10,1) Chk_Cd,
     Td_Balance,     Sd_Balance,
     Sysdate,     'Sisadmin'
From Ideaal_Cons.Tb_Account_Master_Base A,
     Ideaal_Staging.Tb_Sisadmin_Balance B
Where A.Vendor_Acct_Nbr = Substr(B.Account_No,1,8)
   And A.Vendor_Cd = b.company_no
      ;Edited by: riedelme on Jul 16, 2010 7:42 AM

Disco Plus 10g Performance Issue When Moving Table Headings to Page Items

Similar Messages

Maybe you are looking for