DISCOVERER QUICK TIPS (covers 4.1.48, but may cover other levels) :

1) After cloning a DB and APPS code tree, the Discoverer part will not always work. Ensure that the pref.txt file has the correct IP address of the "new" server that runs the Discoverer code, and after the Discoverer services are started, create an "unregisterall.sh" script (like the "registerall.sh" script, but runs all 3 "unreg*" scripts one after the other). Run this, followed by a "registerall.sh", then "applypreferences.sh", and check the errors.txt file for zero length (no errors present). Run checkdiscoverer.sh, also to check all is OK.

2) switch off Query Prediction (QPPEnable – make his zero in the pref.txt), as it can help performance.

3) There are often several levels of heavy hash-joins going on in the PLAN that the CBO sets up for Discoverer report runs.
If not catered for, these overflow into the TEMP TS, and get slowed down ten-fold by excessive disk I/O in there. I would recommend if your DB server has , say 32GB memory, set your pga_aggregate_target to a quarter of this, to 8GB, but also override the AUTO settings, by adding hash_area_size = 200M or even 400M, and the sort_area_size to 100M, or 200M in the init<DB>.ora if still getting disk sorts.

4) Check for orphaned ws processes on the Discoverer server (or on your main DB server if running all under on code-tree),
and kill them regularly. These can occur after a “Memory Heap” error in the user stack. I have user session logging on, so I can detect this with a cron check of the user logs, then locate the process list, and kill them. This stops CPU hogging. I can provide the scripts I use for this if you need them.

5) When stopping Discoverer services each night (If you are not 24x7) for cleanup, ensue that all the following files are removed from /tmp, as they are sometimes missed: /tmp/orb*, /tmp/dc*, /tmp/opm*

1  out of 3 found this valuable. Do you find this valuable? Do you?    

• Post reply

Show Last Reply

Join the BI SIG for a web presentation and discussion on the importance of data modelling. http://bidwsig.org/node/8

Tuesday, March 11. Meeting details will be published no later than 5 March.

3  out of 5 found this valuable. Do you find this valuable? Do you?    

• Post reply