Encounters of an Enterprise DB Architect

Issue “Choose Connection” is NOT seen in Discoverer Plus and Discoverer Viewer screen after installation. Symptom Installed Discoverer 10g as an OracleBI standalone installation (i.e., without associating with an OracleAS infrastructure). Associated the standalone Discoverer to Oracle Apps Database. Users are unable to see Choose Connection in the Discoverer Plus and Viewer login screen. Cause Discoverer has not been associated with an infrastructure. This happens when Discoverer 10g is installed as a Standalone without associating it with an OracleAS infrastructure. Quoting from the documentation: “An OracleBI standalone installation is not associated with an OracleAS Infrastructure, and therefore has a limited number of components available. .. .. If Discoverer is not associated with an OracleAS Infrastructure, Discoverer connections are not available to end users. For more information about associating Discoverer with an Oracle Infrastructure install, see Chapter 2, "About Orac...

Long time no blog! The reason being that I was busy performing this Discoverer 10g rehost. Without wasting much of your time, let me get into the details. Background Recently, we rehosted (i.e., moved) our production instance to a new set of production servers. Discoverer 10g is also a part of our prodcution implementation. Discoverer resided on the old production servers. Requirement Move Discoverer 10g from the old production servers to the new ones (a.k.a rehost!). Methodology After scrutinizing all the available Metalink docs, I found out that no Metalink doc existed for my requirement! I had to chart my own course here (not that no one had done this before but lack of documentation - both on the web and Metalink, was a bit of an impediment). After burrowing through all the available documentation, I surmised that I had two methods to achieve my goal: 1. Reinstallation of Discoverer 10g (including OID) 2. Cloning of Discoverer 10g ORACLE_HOME. Steps involved in both the methods is ...

In my previous post, I had talked about extracting controlfiles, datafiles and archivelogs from RMAN backupsets using the package dbms_backup_restore. In this post, I would like to throw light upon using RMAN as an alternate method that could be employed to extract controlfiles from RMAN backupsets. This method uses the RMAN command "restore controlfile from '<FULL_PATH_TO_CONTROLFILE_BACKUP>'". The RMAN method can be used in 3 scenarios. So, make sure that at least any one of the backups is indeed available. Else, you are DOOMED! I. the controlfile autobackup is turned on in RMAN. In this case the file format would be "c<DBID>-<DATE>-<COUNT>". It is turned on using the command: configure controlfile autobackup on; configure controlfile autobackup format for device type disk to '/opt/apps/vision/backup/%F'; II. the controlfile snapshot backup is configured in RMAN. It is turned on using the command: configure snapshot control...

The other day, one of my colleagues posed me this interesting and thought-provoking question/scenario: "Suppose, you were to lose both your production and your RMAN catalog databases irrevertably. You do have a full/incremental RMAN backup, however. How are you going to recover?" How indeed? I scratched my head and shone a torch upon the dark recesses of my memory to come up with an answer. The light (of the torch) did indeed reveal something - that is that a note existed in Metalink which list the method that could be used to delve into a RMAN backup set to extract the controlfile, the datafiles and also the archivelogs and Voilà, I hit the nail right on the head. I did some more digging and found a bunch of "Notes" in Metalink that pointed me to the eventual answer to the above question. The Notes that I am referring to are listed below. A summary of the procedure to be followed in such scenarios is also provided. All the notes mentioned use the package dbms_backu...

This post is for the automation fanatics and enthusiasts. Of course, the others aren't excluded! The defaultsfile option that can be used with adutilities is a handy option to save time during patching or other maintenance activities. Though the defaultsfile gets a mention by almost everyone in the context of reducing downtime, the method of creating it is not, unfortunately. In this post, I'd like to share this using an example - compiling apps schema using adadmin. Note: The full explanation of creating a defaultsfile is mentioned in Chapter 2 (Maintaining Your System) of the Oracle Applications Maintenance Procedures . 1. Run adadmin command as below: adadmin defaultsfile=$APPL_TOP/admin/$TWO_TASK/<DEFAULTS_FILE_NAME> e.g.: adadmin defaultsfile=$APPL_TOP/admin/$TWO_TASK/adadmin_cmpl_apps_schema.txt The above command searches for a file with name adadmin_cmpl_apps_schema.txt in $APPL_TOP/admin/$TWO_TASK directory. If it exists, it uses the values provided in that file. ...

In the last post, I had talked about the pitfalls in configuring PCP in non-RAC instances. I have figured out (is it really the solution? - only time will tell!) workarounds for the 2 pitfalls that I had listed. 1. How would the VNC server failover when using PCP with non-RAC? Ans: The best bet would be to start the vnc server using the virtual hostname instead of the physical hostname (thanks to my colleague Mansoor who suggested it). Once the VNC is started using the virtual hostname, set the display variable to this value and run autoconfig so that the changes are reflected in the concurrent manager and the report server startup scripts. So, when the VIP (and hence, the virtual host) fails over, the VNC would still be running. This solution needs to be tested thoroughly though. Below is the command that I can use: $ vncserver -name <VIRTUAL_HOSTNAME>:<PORT_NUMBER> 2. The web tier 806_ORACLE_HOME tnsnames.ora can be modified to include the FNDFS_<PHYSICAL_HOSTNAME>...

It was a wonderful surprise when I stumbled upon Metalink Note ID: 743716.1 , which details steps for configuring PCP in non-RAC instances. This is very useful while using hardware or software clustering and not Oracle clustering (RAC). We are using Veritas clustering (software clustering) for server failover. We were recently testing server failover and there are two things that I am unable to figure out as of now and which necessitates manual intervention rendering the whole failover mechanism manual: 1. How would the VNC server failover when using PCP with non-RAC? Since, the hostname changes when the failover happens, the display variable would still be pointing to the failed server and not the failover server. The work around to the above problem is obviously to reset the display variable and run autoconfig, which would mean that the failover mechanism is no longer automatic. 2. As soon as the failover happens, we need to make a manual entry in the Web Tier $TNS_ADMIN/tnsnames.ora...