Andreas' Adventures

Trying to fix the problems I encountered earlier I found out that the removal of the OID security provider is performed by the following steps. During the setup where OID is created as a security provider the ssoreg.sh is run on the OID layer. Remove this with the web-based ORASSO (http://host:port/pls/orasso). But the second step involved the usage of the new osso_newsite.conf file. This is done with the $ORACLE_AS10131_HOME/Apache/Apache/bin/osso1013 . Just comment out the entries in the httpd.conf and the mod_osso.conf, create a new empty_osso.conf in $OH/Apache/Apache/conf/osso/ and rerun the osso1013. This did the trick for me. cu Andreas

This seems to be a very difficult task. Here is my setup on a VMWare instance (RH 4.3): AS 10.1.2.0.2 Infrastructure with OID AS 10.1.3.1 SOA Suite AS 10.1.3.2 Webcenter Now I want to use the OID as the security provider for the SOA Suite. First I register the SOA Suite as a "remote_midtier" in the SSO. Then I go to the AS Control of the SOA Suite and configure the Identity Management for the two OC4J's - home and oc4j_soa. This does only work for the OC4J called home. The OC4J oc4j_soa does not get changed. Then after some restarts the whole system decides to just stop with using any of the two security providers (file-based JAZN and OID). Therefore I cannot login to the AS Control. After several attempts to fix this I parked this problem. This will probably be a reinstall :-( Any ideas are welcome. cu Andreas

Thanks to my friend Robert I now grasped the concept of the VIP in RAC environments. VIP's were created in order to speed up the process of letting the client know that the server died. Imagine that the server crashed without any possibility to inform the client. The client will then initiate a request and has to wait for the TCP timeout. That can easily be 120 seconds. The client should therefore use the VIP in the tnsnames.ora. Performing a request now will immediately give a response. The client can then initiate its TAF faster.

During the last post I mentioned that we needed rsh in order to fallback as the ssh apparently didn't work. Now when the database should be build with the dbca an error was thrown, stating that the user oracle had no user equivalence on its own node. Searching Metalink revealed that the dbca was looking for ssh in /usr/local/bin/ssh . However, ssh on AIX is located at /usr/bin/ssh . Created a softlink solved this problem. This could also be the explanation for the problems I had earlier. When setting up the user equivalance with ssh you use the commandline. As /usr/bin is in the path before /usr/local/bin from the commandline the ssh works just fine. When this is hardcoded in the Universal Insstaller or the dbca you could get these problems. BTW: it seems that this is solved in 10.2.x cu Andreas

Installing RAC does always have some nice surprises. For example the following: Although CRS and cluvrfy did not pose big problems (from what I've heard - didn't do it myself) the node could not be found. SSH works - of course. After some trying the decision was made to open RSH on both nodes. Voila. It works. This was on an AIX 5.3 . So this might be of some help for you out there. cu Andreas

A little gem I found in the Oracle Metalink Notes: Steps to enable OC4J logging: a- Each OC4J instance has a separate logging configuration file: $ORACLE_HOME/10.1.3/j2ee/ /config/j2ee-logging.xml b- By default the log level is set to something like: c- You can set level to the desired value as using following syntax: : Message type: INTERNAL_ERROR, ERROR, WARNING, NOTIFICATION & TRACE Message level: 1-32 (1 most severe, 32 least) d- Each OC4J instance has file: $ORACLE_HOME/10.1.3/j2ee/ /application-deployments/ /orion-application.xml Which contains tag like: to specify the log file name. e- Each OC4J has its own log file in the following path: - Plain Text Log: $LOG_HOME/ora/10.1.3/j2ee/ / _ /application.log - ODL Log: $LOG_HOME/ora/10.1.3/j2ee/ / _ /log.xml

Oracle's RMAN should come back with a prompt or at least the welcome banner when it is started. So I was pretty amazed when I found out that all attempts to start rman on a Suse system did result in - - - nothing at all :-( Of course the first thing I tried was a different login, different database, etc. Then I thought - as I had similar problems on this machine that there might be a problem with a path. However I was 110 % sure that the oraenv did its job. which rman revealed: /usr/X11R6/bin/rman which seems to be RosettaMan, a system to reformat man pages. I didn't know that RMAN was capable of doing this, too ;-)

This is an error I made and I thought sharing this will prevent other from searching in the wrong direction (as I did). When installing the SOA Suite you might want to integrate this with the OID. However there is a small problem when during the setup of the SOA Suite two OC4J's are created. You will have oc4j_home and oc4j_soa for example. When you integrate the OID into the SOA Suite you will need to manipulate the jazn.jar file in the oc4j configuration directory. As you have two oc4j's you need to copy the jazn.xml to the respective directories - otherwise you will get to the SSO page but will never be able to log in.

I recently tried to set some security setting for a group in the OID with the famous jazn.jar . To my surprise everytime - even after reading the documentation ;-) it failed. This problem was solved by using the Java version that Oracle supplies. So just set $ORACLE_HOME/jdk/bin/java early in your path and you could use jazn.jar!

After a while I bumped into RAC again. And as this has bugged me before I again made the mistake to believe that during the setup I have to create some networks for the virtual IP. Well - don't. Virtual just means virtual. They do not exist. Still need to find out how they are used then.