Monday, 3 March 2008

Connect to Discoverer Plus/Viewer is Very Slow in the Connection Phase

OracleAS Discoverer Plus 10.1.2 installation, is really slow in the connection phase, both from APPS links and Standalone connection. After the insert of the login details in the Connect Box it is showing for approx 20 minutes the following page :

Request Progress

Processing your request
The page you have requested is taking some time to process. Please wait...

The Cause is that the Connect descriptor resolve slowly as it did not contain a valid entry.

Having the following entry in the sqlnet.ora :

NAMES.DIRECTORY_PATH= (LDAP, TNSNAMES, EZCONNECT, ONAMES, HOSTNAME)

will delay the authentication, as it will first try to authenticate the connect descriptor through OID, where it does not exist.

A simple configuration gain is to change the way the client looks up the connect descriptor. This connect descriptor must be translated by Oracle Net into the network protocol location of the database (IP address and port number) and the name of the database service.

There are a variety of methods to store this information, such as in a TNSNAMES.ORA (TNSNAMES) file, Oracle Internet Directory (OID - LDAP), Oracle Names (ONAMES) or using the Host Naming Adapter.

The default connect descriptor lookup path is to first look in the local naming file TNSNAMES.ORA, then to try the well-known Oracle Names servers, and then finally to try the Host Naming Adapter. The parameter that influences this lookup order is NAMES.DIRECTORY_PATH parameter in the SQLNET.ORA file.

-- To implement the solution, Update the sqlnet.ora file in the Discoverer ORACLE_HOME from :

NAMES.DIRECTORY_PATH= (LDAP, TNSNAMES, EZCONNECT, ONAMES, HOSTNAME)

to

NAMES.DIRECTORY_PATH= (TNSNAMES)

if the connect descriptor is configured to be resolved via tnsnames.ora, otherwise order the list with the right connect descriptor which is used first.

Tuesday, 26 February 2008

Cumulative Patch for Oracle Discoverer 10.1.2.2

This will be implemented for iAS 10.1.2.2 (Discoverer 10.1.2.54.25) version going forward. This is only for Plus/Viewer. (D40 patches will also be using this cumulative model)
Discoverer Admin/Desktop 10.1.2.54.25 (part of iDS 10.1.2.2) will continue to use the current patching model. Previous versions, iAS 10.1.2.0.2 / 10.1.2.1 (Discoverer 10.1.2.48.18
or 10.1.2.50.05) will continue to use the current patching model.


First Cumulative Patch (for example, let's call it PATCH1) contains 70 bug fixes over 10.1.2.2. Or in other words, PATCH1 = 10.1.2.2 + 70 bug fixes If second Cumulative Patch (PATCH2) request MLR receives 30 bugs, PATCH2 will end up containing 70 + 30 = 100 bug fixes over 10.1.2.2 or, in other words, PATCH2 = 10.1.2.2 + PATCH1 + 30 bug fixes and so on for PATCH3 ... PATCH3 = 10.1.2.2 + PATCH2 + x bug fixes

Opatch is used to install Discoverer Cumulative Patches. The patch readme has all the install/rollback instructions.


Patch 5943426 - CUMULATIVE PATCH I: (AVAILABLE FOR SOLARIS, LINUX 32BIT, WINDOWS 32BIT, AIX 5L 64BIT)

Patch 6129303 - CUMULATIVE PATCH II: (AVAILABLE FOR SOLARIS, LINUX 32BIT, WINDOWS 32BIT, HPUX 64BIT)

Patch 6155500 - CUMULATIVE PATCH III: (AVAILABLE FOR LINUX/INTEL, SOLARIS-64, WINDOWS/NT, AIX 5L 64BIT, HPUX 64BIT, HP/IA64 (HP UX ITANIUM))

Patch 6357481 - CUMULATIVE PATCH 4 : (AVAILABLE FOR LINUX/INTEL, SOLARIS-32, WINDOWS/XP, AIX 5L 64BIT, HPUX 32BIT, HP/IA64 (HP UX ITANIUM))

Patch 6472361 - CUMULATIVE PATCH 5: (AVAILABLE FOR HP ITANIUM IA64, LINUX 32BIT, WINDOWS 32BIT, SOLARIS 64BIT (23), AIX 5L 64BIT)

Patch 6669003 - CUMULATIVE PATCH 6 : (AVAILABLE FOR WINDOWS, SOLARIS-32, LINUX/INTEL, IBM/AIX-5L, HP-32, HP/IA64 (ITANIUM))


Cumulative Patch 7 - ETA not available

Patch 67xxx60 - CUMULATIVE PATCH 7 : (AVAILABLE FOR LINUX 32BIT, AIX 5L 64BIT, SOLARIS-32, WINDOWS 32BIT)

Monday, 21 January 2008

Track Portal Page where Discoverer Portlet are stored

For customers having discoverer portlets it's an easy task to confirm whether they are executing correctly or not discoverer portlets by querying the PTM5_CACHE table on the Infrastructure. But it could be a nightmare if they have hundreads of these portlets and they want to open it through the Portal site. Indeed, how to find which is the Page where they are stored ? Following is a query that query Portal Page containing Discoverer Portlets :

Select Portal.WWPOB_Page$.Name

from Portal.WWPOB_Page$
where (Portal.WWPOB_Page$.ID ,Portal.WWPOB_Page$.SiteID) in
(Select Portal.WWV_Things.CornerID, Portal.WWV_Things.SiteID
from Portal.WWV_Things
where Portal.WWV_Things.Portlet_Inst_GuID in
(Select
Portal.WWPOB_Portlet_Inst$.Portlet_Inst_GuID
from Portal.WWPOB_Portlet_Inst$
where Portal.WWPOB_Portlet_Inst$.Provider_ID =
and Portal.WWPOB_Portlet_Inst$.Portlet_ID = ));


You need to substitute the PORTLET_ID and PROVIDER_ID value with your own value. Those can be obtained with procedure explained above:

1. Login to Portal as the portal or orcladmin user;
2. Navigate to Administer -> Portlets;
3. Select the 'Display Portlet Repository' link;
4. Locate the provider containing your discoverer portlet (this may be under the Portlet Staging Area)
5. When the page with list of portlets (Discoverer Gauges, Discoverer Worksheet, Discoverer List of Worksheets) is displayed, click on the "Edit" link you see on the top right and you will get properties for this portlet (Portlet_id included) ;

To get filter data, pointing to specific workbook, you can query the Infrastructure DB by the following :

Select Distinct CacheTable.Cch_Url, Portal.WWPOB_Page$.Real_Name
from Portal.WWPOB_Page$, Discoverer5.Ptm5_Cache CacheTable
where (Portal.WWPOB_Page$.ID ,Portal.WWPOB_Page$.SiteID) in
(Select Portal.WWV_Things.CornerID, Portal.WWV_Things.SiteID
from Portal.WWV_Things
where Portal.WWV_Things.Portlet_Inst_GuID in
(Select Portal.WWPOB_Portlet_Inst$.Portlet_Inst_GuID
from Portal.WWPOB_Portlet_Inst$ Where Portal.WWPOB_Portlet_Inst$.Ref_Path in
(select Discoverer5.Ptm5_Instance.Ins_Id
from Discoverer5.Ptm5_Instance
where Discoverer5.Ptm5_Instance.Ins_Surrgt_Pk in
(select Discoverer5.Ptm5_Cache.Cch_Ins_Surrgt_Fk
from Discoverer5.Ptm5_Cache
where Discoverer5.Ptm5_Cache.Cch_Ins_Surrgt_Fk = CacheTable.Cch_Ins_Surrgt_Fk
and Discoverer5.Ptm5_Cache.Cch_Surrgt_Pk = CacheTable.Cch_Surrgt_Pk
and Discoverer5.Ptm5_Cache.Cch_Id = CacheTable.Cch_Id
and Discoverer5.Ptm5_Cache.Cch_Url = CacheTable.Cch_Url
and TO_CHAR(CCH_NEXT_UPDATE,'DD-MON-YY') != '02-JUN-01'))))
order by Portal.WWPOB_Page$.Real_Name;

In this case I took out the failing portlets with Update Date = '02-JUN-01'.