Archive for May, 2009
User reported a very slow interacting on his new laptop with Discoverer Plus. Changing tabs, opening workbook wizard e.g. Other laptops / workstation had no problems.
He was the only one who had a ‘modern’ Java version on his laptop : above 1.6. So it had to be Java. And that was right. Note 747189.1 is mentioning the following:
The problem does not exist with JInitiator or with Sun plugin 1.4 or 1.5 and earlier versions of 1.6
* JRE 1.6.0 – works correctly, runs with 1.5.0-like speed
* JRE 1.6.0_01 – works correctly
* JRE 1.6.0_02 – works correctly
* JRE 1.6.0_03 – here the problem is observed for the first time. The issue is then observed in all subsequent versions (e.g., _04, _05, _06, _07 and the new_10)
The problem does not exist when an entry for the Discoverer server exists in the local hosts file on the client PC (C:\WINDOWS\system32\drivers\etc\hosts).
Sun’s Java plug-in performs reverse DNS lookups when connecting to the Application Server. This can be observed with a network sniffer trace (Wire Shark).
There is a change in the DNS handling in Sun plug-in 1.6.0_03 and higher.
Solution: Ensure the external facing IP address of the Discoverer server has a reverse DNS entry in the DNS server.
nslookup <IP address> must resolve to the <machinename.domainname>
nslookup <machinename.domainname> must resolve to <IP address>
An alternative or temporary solution would be to add an entry to the local PC hosts file, as described above.
–> I decided to go for the last option: local host file (one laptap for the time being). It works fine.
Tried to prepare my 10.2.0.4 – Grid Control for an upgrade to 10.2.0.5. See also http://download.oracle.com/docs/cd/B16240_01/doc/install.102/e10953/toc.htm .
Updated for example the shared_pool_size as 128MB as minimum size (see below for other recommended fixed parameter settings), although I think it also will work while setting the sga_target. Changed the sga_max_size, shutdown, startup… unfortunately: ora-27102 – out of memory. Database couldn’t be started anymore, not even in nomount (seems logic..). All the notes are pointing to the kernel-parameter kernel.shmall. But when I recalculate, it should be quite sufficient.
Platform: Suse 9.4, 32-bits. I’m only monitoring for this customer about something more than hundred objects: 25 databases, some application servers, 13 hosts.
Put more memory in the machine: 8GB: Same problem. 83% of the memory appeared to be diskcache, which should be good. Solution for the moment: startup the database with no sga_max_size. Increased the sga_target with 1GB: no problem. Annoying, as I have to bounce the database when I change sga_target.
For the moment no other solution at hand.
Fixed Initalization Parameters (besides 128MB shared_pool)
compatible <currently installed Oracle Database release> (default)
undo_tablespace <any acceptable name>
statistics_level TYPICAL (Note that this value is specific only to Enterprise Manager 10g Repository Database release and later.)
TEMP space (Tablespace)Foot 1 50 MB (extending to 100 MB)
_b_tree_bitmap_plans false (hidden parameter)