This install is to prepare for the R12.1.1 upgrade. As mentioned previously, you are required to install the R12.1.1 Upgrade Filesystem as part of the upgrade to R12.1.1.
You must use root, or sudo to run rapidwiz, if you have applmgr and oracle users for the apps stack and the database. If there is only one user, you don’t need root to run the install, but you may need someone with root access to run root.sh after the install.
For Solaris you’ll need the following from edelivery.oracle.com:
These downloaded packs are different for Linux, so be careful to download the right files from edelivery.oracle.com.
When you unzip these, you’ll end up with four directories:
There is no way to avoid installing the 11106 database home. You can throw it away when you’re done, as in our case, we already have the database upgraded to 11203. Oracle really should add another install option along with the rapidwiz -techstack option that would allow us to be able to install the Upgrade Filesystem without the database tech stack, something like, rapidwiz -appstack, hint, hint Max and Elke.
First, start Exceed.
To get the tool bar, start exceed and right mouse click the exceed icon on the status bar and go to tools and select show tool bar.
To use Putty, you load or create a session and on the right hand side expand SSH and there is either X11 or Tunnels depending on your version.
Select X11 forwarding and then go back to session and save it.
Then, set the DISPLAY variable to point back to my PC.
There is no option to just install the apps stack, so rapidwiz will install both the database home, for 12.1.1, the version of the db is 188.8.131.52, and the apps stack, APPL_TOP, OC4J, Forms homes and Developer 10g homes.
I think it’s funny that the RDBMS version is listed as 184.108.40.206 in the first rapidwiz screen, even though it’s really 220.127.116.11.
The bigger issue when installing the Upgrade File System is usually we already have an upgraded RDBMS stack, in our case it’s 18.104.22.168, but we have no other choice but to install 22.214.171.124 and throw it away. It would be great in the future if rapidwiz would give us the option to not install the database stack. Not only does it take up space and we have to remove it when the install is done, but we have to point the apps to the correct RDBMS home by editing the context file and running AutoConfig.
To start rapidwiz, since I don’t have the root login, I can use sudo, as in the following screenshot:
sudo has to be setup by the Unix sysadmin and you have to use the full path name to the rapidwiz executable, as shown above. The examples are from a real client install, so I blanked out the client specific info. In this example, the instance name is VALID and the two application servers are named testdb4, this also is the database server, and bppwebt1 is the second application server.
The next figure shows the technology stack that will be installed. The installed database version is not 9205, but really 126.96.36.199. As mentioned previously, I have to install this, but I’ll throw it away when I’m done, because I already have the database upgraded to 188.8.131.52. In a future post, I’ll talk about how to upgrade the EBS database to 11203.
Use the same port pool as the current database port pool, in our case port pool 0, in order to match the existing port pool.
Name the SID the same and specify the oracle user and group the same as before, so we can hook into the existing 11203 database.
Make sure to match the existing APPS password and GUEST password.
Define the Primary Applications Node
And “Edit Services” so only the services intended to run are specified.
In the above case, we only specified the Concurrent Processing to run on the Primary Apps node. Notice that when you disable the Root Service, all the other services except Batch Processing services become disabled.
Then, add another node, in our case we have two apps nodes. This step has to be performed when running rapidwiz on both nodes, so that each node is aware of the other node.
On the second Apps node we want all the services except Concurrent Processing. If we wanted to setup Parallel Concurrent Processing, we would specify Batch Processing services as well as the other services on the second node.
Now, I have to repeat these steps on the other node.
Second node configuration
We had to create the oravalid user on bppwebt1, even though there is no database home on this node, because rapidwiz needed to write the XML file to the /tmp directory as the oravalid user.
All services except concurrent processing are enabled on bppwebt1.
Click “Add Server” to add the testdb4 server, this screen is after we added the server with the following screenshot:
Disable all but Concurrent Processing on testdb4, by clicking “Edit Services” in the next screen:
and, enable or disable the necessary services. In this case, all services are disabled except “Batch Processing Services”.
After the install finishes, the “Validate System Configuration” window appears, showing the system is installed correctly.
This nest figure illustrates the installed configuration: