Discoverer is slow

Dear all,
Lately, a number of users have been complaining about discoverer been slow. What do i do to tune the discoverer server?

Sorry for the late reply on this but we are still having issues opening and functioning in Plus. I have reviewed Document 747189.1 which state's, Cause: Sun's Java plug-in performs reverse DNS lookups when connecting to the Application Server. Solution: Ensure the external facing IP address of the Discoverer server has a reverse DNS entry in the DNS server. For example:
nslookup <IP address> must resolve to the <machinename.domainname>
and
nslookup <machinename.domainname> must resolve to <IP address>
How is this done? My OAS Administrator says that it is not done on the OAS and that I need to get Systems and/or Network Engineers involved. I am not sure whom to approach first. Any suggestions?
Thanks,
Jerre

Similar Messages

Discoverer Report Slow

Hi All,
I have a problem wherein some specific users are saying that the report is slow at their end.
The exact issue is...we have Discoverer Report present at the US server. Now we have 2 sites CANADA and US from where this report is run. Both sites refer the same server i.e. the US server.
Canadian users are reporting performance problems with this report, but when I run the report at my end there is no such problem.
Please advice what can be the probable reason for this.
Regards,
Ankur

Hi Ankur
Further to what has been said, if you are running Discoverer Plus across a long time it will take longer to run. Typically the query runs within the database but everything else, formatting, layout, page items and so on is done locally by the Java applet in your local cache. What happens if you run a CANADA report from the US site? Does it run ok? If so, then therein lies the answer. The machines in Canada need to therefore be as powerful as you can make them plus your network needs to be as fast as you can too.
Another way way I have seen this solved is by providing something like a Citrix server in the US for the Canadian customers to log into.
Best wishes
Michael

Oracle Discoverer very slow when switching page items

Hi guys,
I'm working on a report(Discoverer Plus) which returns some product information. Parameters are a product id or a product name.
The report has three page items.(typically these would have between 3 and 10 entries in each).
If I run the report for our busiest product id the report completes in about 5secs.
If I then chose something from the page item the report can then take up to 20mins to complete, doesn't seem to matter what I pick.
I notice that if I instead refresh the report and enter a product id with little data, change the page items there and then refresh and enter the the product id of our busiest product that the report will complete in about 5secss, returning the same data as the report that will take 20 mins.
I am new to Discoverer and have discussed this with some colleagues but they are not sure, so I'm left scratching my head.
So I'd appreciate any insight that peeps might have in to this.
I would have thought that once I enter a product ID all data is returned from the DB and indexed for page items, I just can't see what Discoverer is doing for 20 odd mins.
Yours confused!
David

Hi Rod,
I had the Discovery admin check oem and he can see that when the page item is selected that the cpu is busy processing the data for the 15-20 mins, no additional call is made to the database.
I installed Discovery Desktop today and the same report changes tabs almost instantaneously through it, so I'm left scratching my head.
I do see occasional warnings about low heap memory on the AS but on Discovery Desktop with even a 15k memory cache the report only took a few seconds to switch pages.
The admin has advised to raise an SR with Oracle but I'd be interested in any areas to check.
Edited by: dobrien_ie on Jun 1, 2012 3:40 PM

Discoverer report is taking much time to open

Hi
All the discoverer report are taking much time to open,even query in lov is taking 20 -25 min.s.We have restart the services but on result found.
Please suggest what can be done ,my application is on 12.0.6.
Regards

This topic was discussed many times in the forum before, please see old threads for details and for the docs you need to refer to -- https://forums.oracle.com/forums/search.jspa?threadID=&q=Discoverer+AND+Slow&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
Thanks,
Hussein

Discoverer report is taking a very long time

Hi All,
I need help on below discoverer issue.
discoverer report is taking a very long time for rows to be retrieved on export when it is run for India and it is required for month end. For some reason only 250 rows are retrieved at a time and retrieval is slow so it is taking 10 minutes to bring back 10,000 rows.
Regards
Kumar

Please post the details of the application release, database version and OS along with the discoverer version.
I need help on below discoverer issue.
discoverer report is taking a very long time for rows to be retrieved on export when it is run for India and it is required for month end. For some reason only 250 rows are retrieved at a time and retrieval is slow so it is taking 10 minutes to bring back 10,000 rows.Please see these links.
https://forums.oracle.com/forums/search.jspa?threadID=&q=Discoverer+AND+Long+AND+Time&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
https://forums.oracle.com/forums/search.jspa?threadID=&q=Discoverer+AND+Performance&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
https://forums.oracle.com/forums/search.jspa?threadID=&q=Discoverer+AND+Slow&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
Thanks,
Hussein

Discoverer Query is taking too much time

Hi,
I am having performance problems with some queries in Discoverer(Relational). Discoverer is taking around 30 minutes to run the report. But if I run the same query through TOAD it takes only 5 to 6 seconds. Why it is so ?
Structure of Report:
The report is using crosstab with 3 dimensions on the left side and 3 dimensions on the page items.
Why the performance in the discoverer is slow and how can I improve it ?
Thanks & Kind Regards
Rana

Hi all
Russ' comments are correct. When you use crosstabs or page items, Discoverer has to execute the entire query before it can bring back any results. This is a known factor that should be taken into account when end users create workbooks.
The following conditions will greatly impact performance:
1. Crosstabs with many items on the left axis
2. Multiple Crosstab values
3. Page items with a large set of values,
4. Crosstabs or page items that use complex calculations,
5. Multiple page items
Thus, users must avoid building worksheets that use too many of the above. As commented previously, this is well documented in the forums and on the Oracle website and should not come up by surprise. If it does then either suitable training has not been given to the end users or Oracle's own end user documentation has not been read. Section 6 of the Discoverer Plus user guide has the following advice:
Whether you are using Discoverer Plus Relational to perform ad hoc queries, or to create reports for other end users, you want to minimize the time it takes to run queries and reports. By following a few simple design guidelines, you can maximize Discoverer performance.
Where possible:
use tabular reports rather than cross-tabular reports
minimize the number of page items in reports
avoid wide cross tabular report
avoid creating reports that return tens of thousands of rows
provide parameters to reduce the amount of data produced
minimize the number of worksheets in workbooks
remove extraneous worksheets from workbooks (especially if end users frequently use Discoverer’s export option, see Notes below)
Notes:
When end users export data in Discoverer Plus Relational or Discoverer Viewer, they can export either the current worksheet or all the worksheets. In other words, they cannot selectively choose the worksheets to be exported. Remove extraneous worksheets so that extra data is not included when end users export all worksheets.
I hope this helps
Regards
Michael

95 / 5 / 1 usage rule Viewer to Plus to Desktop

Hi,
Russ Proudman wrote this in a Discoverer Discussion post recently:
"At many clients and presentations I strongly recommend the ol' 95 / 5 / 1 rule being that you have 95 users using Viewer, 5 users using Plus and maybe 1 with Desktop (and most likely that's the 1 with Admin as well)."
I am wondering, is this the standard rule for most places? If so, why this rule?
In my last workplace, we used the 5/95/1 rule where only a few used Viewer, most everyone used Plus, and administrators used Desktop. Why? Plus is a superior tool to Viewer. The search options, input parameter options (until 10.1.2.2), and sheet display options are superior to what is shown in Viewer (plus more reasons not listed here). The only users who accessed Viewer worked at remote locations - generally, their homes - where access to Plus was terribly slow.
Interestingly enough, at my current workplace, we follow your rule. I prefer the 5/95/1 rule. We are thinking of going to the 5/95/1 rule for 10.1.2.2 due to issues with linking from one worksheet to another using Managed Links. If we don't, we have to scrap our upgrade altogether. Oracle is not providing a solution for us at this time.
Just curious.
Thanks,
Nancy

I can explain my thinking better with the following:
1. First of all, Disco Viewer takes less bandwidth and memory to run than Plus. You can search the forums for the amounts - as I can't remember - but as Plus is XML and Viewer is HTML the difference of info, packets, etc. going over the intranet at work is a consideration. And then, as mentioned, less memory required to use the Viewer version.
2. Here's my soapbox reason:
At so many clients I'm at the 'right' thing for management to say is that "our users are empowered" meaning that they want their end users to write their own reports, etc. Even if a middle layer to make things easier is installed (ie: NoetixViews, BIS Views), end users - even trained - do not use the product daily and therefore create literally hundreds of programs that are badly written, shared amongst their friends and perform 'dumb' queries when not needed (ie: having an index field but by ignorance causing the search to be a complete table search). They usually follow no standard and results are many times incorrect (ie: trying to cross orgs in Oracle Apps?, using multi-currency in Oracle Apps or regular DB tables?, etc.).
So when it's time to upgrade or a new IT manager comes along and tries to put a stop to the prevalence of reports such as "Marge Report - GL Budgets (do not use after Jan.2.2001", "Marge Report - GL Budgets (this is good but run only on Mondays)", etc. it become a large task.
So I've found over and over again that if a company has a few report writers - and of course, it depends on the company, but something like 5 would be good - who know SQL, who know Disco and have taken training, and use the product daily - then only they should use Plus to create the reports, and the other 94 / 95 out of 100 would only run the pre-existing, corporate made reports by these 5 and with the right combination of parameters, etc., a Viewer report should allow multiple ways of seeing the data (ie: by GL Date, by account, between a dollar amount, etc.).
And that just leaves the 1 or so to be the Admin and the same person who needs Desktop.
3. Having said all that, I've also found that many companies just don't treat Discoverer the same as something like Oracle Apps. If Oracle Apps is slow - they fix it with more hardware, setups, etc. and pay for a team of consultants to do so. If Discoverer is slow because the server has been set up wrong, they're running another large application on the Disco box, or users are writing 'slogging' reports ... then the answer usually is "Discoverer sucks ... let's try [A]" - where [A] seems to be the flavor of the day - ie: insert any of the following: Cognos Impromptu, Brio Query, Business Objects, Hyperion (well Oracle Hyperion now) ... and the new fav ... OBIEE.
So by having a good Disco administrator, some well trained, knowledgeable report writers and lotsa' end users running those pre-written reports ... that's where it all works.
4. One last thing - I realize that a company can roll out Disco Plus to all users and keep the 'power' of the end users low so they can only run pre-written reports as described above. This is okay as yes, Plus is more friendly and looks 'cooler' in my opinion. But then it's just the network and memory issue to watch out for. Most companies I've been at don't do this (only 1 to date) but it's a fairly reasonable request. The problem was they should start with just Viewer and see that end users are just happy to get the data. If they give them Plus first, then no one wants to feel 'down-graded' to Viewer later.
Hope that explains my opinion better. Although it sounds kinda' negative, it sure is what I seem to come across over and over again.
Russ

FCS Date Java SE 6 Update 14 ?

Folks
Does anyone know the FCS date for Java SE 6 Update 14?
We have serious problems with oracle forms and Java SE 6u13, and they are fixed with Java SE 6u14 b05. Thanks
So we are waiting for the FCS.
Thanks
Reinhard

It was released on Friday. We've tried it and it's much faster loading Oracle Forms and we're testing for other fixes (discoverer runs slower on JRE instead of Jinitiator, strange issue where users can't select items with the mouse, have to use keyboard)
What kind of problems are you seeing?

Slow performance of discoverer portlets

Hi,
I am running into slow performance of a particular page in portal, there are multiple sites hosted on the portal but these all have static text and are very quick to load but the one page with discoverer portlets and a web-clippping portlet is taking ages. If I run these reports on their own they are instant. Has anyone had similar problems with 9.0.2 portal and the discoverer reports ? I tried to identify a particular report that may be the culprit by deleting them one by one and to no avail. After a few hours effort I found the design mode was hanging as well. Again, just for this 1 page.
There are 3 tabs on this page with about 4 report portlets and 1 web-clipping portlet.
Thanks for any help,
Brandon

Thanks for the help.
Seems to have been resolved although I'm not sure if thats the end of the story. Will wait and see.....
So far apparently a port conflict of some sort in the discoverer config was causing it to hang and then also other system demands on the network and server housing the discoverer end-user layer were also causing problems.
No error messages unfortunately......

Discoverer report is slow

Hi,
I have created a detail level view joining multiple tables. Based on this view I have created a report which gives the totals.
The estimated time to generate the report is showing as 26 mins when I try to run it for some parameters.
But when I take the query from the SQL inspector of that worksheet and run it in the TOAD for the same parameters, it is just giving the data in 2 mins.
Why is it taking that much time in Discoverer to generate the report. Can you please explain.
Thanks.

Hi,
The query predication itself may be causing the Discoverer report to run slower, so you should try with QPP switched off.
Also TOAD by default only returns the first 50 rows, whereas a Discoverer crosstab report will have to fetch all the rows before displaying the results to the user.
There could also be differences in the query plans used, have a look at this tread (Performance anamoly in Disco and Toad
Rod West

Web discoverer report run slow after upgrade to AS10.1.2.48.18

We just upgraded our application server to 10.1.2.48.18, our web Discoverer report were running extremly slow on tables that contain large amount of data. We have good speed with those report in the past. The backgroud database was the same as well as the web server.Using desktop version of Discoverer were fine with normal speed.
Does any one know why? How to speed it up?
Thanks!

A few things to check:
Are all machines using the same version of SQL*Net?
Are the reports in different EULs (if so, are the EULs at different versions)?
Do all reports work in Disco Plus or Disco Desktop?
What types of reports are failing (cross tabs, tabular, both)?
For the reports that are failing, how many rows are you expecting?

Any new discoveries on Photoshop CS3 files opening slow in Windows 7?

Any new discoveries on Photoshop CS3 files opening slow in Windows 7?

Extend Dave's advice to also include looking for any network shares that may be mapped (e.g., to a drive letter) but not presently online.
-Noel

Discoverer report runs okay in test system but very slow in live

Hi all
My Discoverer report takes about 5 minutes to run in the test environment. The same report (absolutely the same SQL in the custom folder in the admin edition and the same conditions and sort in the Desktop edition) takes at least 45 mins to run in live.
Has anyone faced a problem like this? How can I speed up my report in the live environment? I am using Discoverer version 4.1.48.06.00
Thanks in advance!
Regards
Aruna

Hey Aruna.
Are you sure the 2 environments are exactly the same (ie: one recently copied to the other)? Reason I'm asking is that if one has many more records, or one has an index, etc. then that would, of course, cause a difference.
What about the time when you're running it? Is the production environment an Apps environment and they're running batch jobs, updating shipping info in the last week of the month, etc?
I would first of all see if the environments are the same by trying something as simple as running the query in TOAD or SQL Navigator or SQL Developer in both environments and then seeing if there's the same difference. If not, then move on to the Discoverer side of things.
If they're still different, then are the Disco environments the same? Have you turned query prediction, etc. off in DEV but not in PROD?
Is the DEV box a hot damn new UNIX box with all the good stuff like oodles of memory, multi-processors, etc? And is the PROD box a Commodore 64? Okay, just kidding on the last test, but you get the idea.
Start at the same relative time (ie: morning). Start TOAD, etc. and see the speed difference there. Then move on to Disco and see the speed difference.
Russ

Discoverer Viewer Report with Page Items Slow Performance

I created a report in Discoverer User that has page items and parameters and runs fine (under 3 minutes) in Discoverer User, but when I try and run it in Discoverer Viewer it takes a long time. It took over 70 minutes before manually terminating it. I made a copy of the report and removed the page items and tried to run it again in Discoverer Viewer and now the report runs in under 3 minutes. Any idea why a report with page items would run in Discoverer user fine, but not discoverer viewer?
I am using Oracle Business Intelligence Plus 10g (10.1.2.55.26)

As long as you can access the middle-tier server where Discoverer Viewer is running, you should be able to run and view Discoverer worksheets.
While it is difficult to even start guessing what the problem might be, if the machine you installed Discoverer on has DHCP addressing, you will run into problems.
Thanks
Abhinav
Oracle Business Intelligence Product Management
BI on Oracle: http://www.oracle.com/bi/
BI on OTN : http://www.oracle.com/technology/products/bi/
Discoverer : http://www.oracle.com/technology/products/discoverer/
BI Software : http://www.oracle.com/technology/software/products/ias/devuse.html
Documentation: http://www.oracle.com/technology/documentation/appserver1012.html
BI Samples : http://www.oracle.com/technology/products/bi/samples/
Blog : http://oraclebi.blogspot.com/

HELP !!! Discoverer Desktop/Plus Slowness

We have a view build on wip_discrete_jobs_v and hr_all_organization_units in APPS. When the view runs it returns at a very good speed. Then we build a disco report, the first time we open the report, it took 10 seconds yesterday. However, when we try to open the same report today from Desktop or Plus, it will takes *15-20 min* to get any result.
I'm not sure where the issue is: Could it be a bug in Disco? Or this is version issue? Or is there anything missing Administrator?
It seems the view itself is good in SQL.
Please advise.
OracleBI Discoverer Administrator - Version 10.1.2.00.00
Discoverer Administrator Client 10.1.2.45.46c
OracleBI Discoverer 10g (9.0.4.00.00)
Oracle Business Intelligence Discoverer Plus 10g (10.1.2.48.18)
Discoverer Model - 10.1.2.48.18
Discoverer Server - 10.1.2.48.18
End User Layer - 5.1.1.0.0.0
End User Layer Library - 10.1.2.48.18

Hi,
The Apps views such as wip_discrete_jobs_v are not really designed for reporting. This view contains calls to security packages and calls to project packages to fetch details project details. The time taken to process a call to these packages is very dependent on your Apps environment, for example, what responsibility you are using and the organisation for that responsibility. Also the number of calls made to these packages can change greatly depending on how the SQL is processed.
Discoverer uses a lot of in-line views and these views can be materialized within the query so that all the information in the view is stored in temporary space. There are also some large tables being queried here, therefore the execution plan can change dramatically depending on the database statistics stored for these tables. So for example, you can find that the query is run from Discoverer, Oracle decides to full scan the tables and materialized a view in the query forcing all the package calls to be made for every row in the table, hence the query takes ages to run.
On the other hand if the SQL is just run from SQL*Plus then a flattened version of the SQL is run without the in-line views and so there are many less calls to the packages, and these calls are quicker because the session hasn't been initialised with a responsibility.
So to summarise, I wouldn't recommend using these Apps views in reporting, it is better to write your own to do exactly what you want and achieve a better, more consistent response time. Secondly, you have no idea what is happening here unless you monitor the SQL being processed in the database, either by monitoring the V$SESSION and V$SQL_TEXT views or by tracing the session so that you can see the actual SQL and all the associated recursive SQL being run by the packages. Only when you understand how Oracle is processing your query will you will able to take action that will reliably improve performance.
Rod West

Discoverer is slow

Similar Messages

Maybe you are looking for