Database Reference
In-Depth Information
With the setup of the software complete, you should execute the root.sh script as demonstrated in the interactive
installation session. The only difference between the two install types is that the root.sh script won't print any
output on script, but rather in a log file. The part of the installation requiring some more attention is a script called
configToolAllCommands ”. It contains commands for all the post-installation configuration assistants to be run. More
specifically, it will perform these tasks:
Update the central inventory.
Call the network configuration assistant to create a default network configuration.
Invoke the ASM configuration assistant to start the ASM instance and create the defined
disk group.
As the command output from the runInstaller command states, you will need a response file to complete the
configToolAllCommands step. Create the response file as shown here, and substitute the values for the passwords
(which need to match with the ones specified above):
[grid@server1 ~]$ ls -l cfgrsp.properties
-rw-------. 1 grid oinstall 87 Mar 8 23:08 cfgrsp.properties
[grid@server1 ~]$ cat cfgrsp.properties
oracle.assistants.asm|S_ASMPASSWORD= randomSysThrowawayPassword
oracle.assistants.asm|S_ASMMONITORPASSWORD= randomASMSNMPThrowawayPassword
Now run the configuration assistant as the installation owner-grid in this case:
[grid@server1 ~]$ cd /u01/app/grid/product/12.1.0.1/grid/cfgtoollogs/
[grid@server1 cfgtoollogs]$ ./configToolAllCommands RESPONSE_FILE=~/cfgrsp.properties
Once completed, the operation will have produced a log file which indicates success or failure of each
component. Should one of the components have failed you can check for logs in the $GRID_HOME/cfgttoollogs/
cfgfw/ directory. Testing showed that the configToolAllCommand execution occasionally can fail if the Oracle
environment variables for the Oracle Restart home were not set. If you get strange error messages in the log file review
the environment variables and run the script again. When finished you might want to remove the response files now
as they might contain sensitive information.
Automatic installation of Oracle Restart using RPM
Most platforms have their proprietary way of deploying software packages, and keeping track of them. Red Hat
Linux is based on the Red Hat Package Manager or RPM. Although there are alternatives to RPM, non-RPM Linux
distributions such as Debian were never officially supported by Oracle for non-free versions of the database. Attempts
to run Oracle on Debian for example have been made, but any success is negated by the lack of support.
Unfortunately Oracle binaries don't lend themselves to installation using RPM. The whole RPM process is more
geared toward compiling and installing software from source. Since you can't download and compile Oracle source
code a slightly different approach was needed to make Oracle installable with RPM. To do so a post-installation
routine is executed calling OUI in silent mode with a response file to perform the installation. The downside to this
approach is quickly identified: the RPM containing the Oracle Restart installation code hardly contains a file. System
administrators used to verifying the contents of a packages using the --verify option to an RPM query will notice that
the files inside the Oracle home are not registered in the RPM database. The examples in this chapter will not include
a de-installation section for the RPM, as a hint the reader should consider invoking the $ORACLE_HOME/deinstall/
deinstall tool to remove the software cleanly.
 
Search WWH ::




Custom Search