Before I started consulting, I was an Oracle engineer in a very large software development organization. The company had a number of major products and the one I worked with was used by hospitals and radiology offices world-wide. (These guys are one of the biggest companies worldwide in the field.) Our product included the hardware and software; you could order it with Sun or HP hardware (Solaris or Linux). It had an Oracle backend and a web-based middle tier built with lots of C++ and Java code.
Any software engineer who has worked on large projects – industry or community – can tell you the importance of solid change control processes. So… since everything for the build had to be checked into clearcase… yes, we checked Oracle 10g into the repo. A 2G tarball. And whenever there was a 1K patch to the oracle install? A brand new 2G tarball. The clearcase guys loved me.
And that was how I started thinking about an automated build process. I don’t need to check B24792-01_1of5.zip into the repository because it’s straight off edelivery. I can skip p7150622_10203_Linux-x86-64.zip since it’s direct from metalink. The only thing missing was a solid, simple, flexible program for automating the oracle install, patchset, CPUs and oneoffs – taking Oracle’s official bits as input.
Anyone else out there who could use a program like this? How about for rapid provisioning of servers? (Like all that grid buzz.) Grid Control does some basic stuff (if you can make it work) and there are advanced kits for the big data centers – but there have to be more people than just me who would love to have this program.
That’s why I’m proposing to write a bit of software called orainstall. It would be script-based and cross-platform and intended for community use. I have some ideas for a design but I’m really interested to hear how you might use something like this and what features might be useful to you. Do you think it’s a good design? I’d also be interested in hearing if you’d be interested to use it or to help test it.
The program would be launched by running the main executable “orainstall”. The syntax could look something like this:
Command line syntax: ./orainstall [-oh ] [-tmp ] Example: ./orainstall ora10203.sf -oh /u01/app/oracle/product/10.2.0/db_1 -tmp /u01/app/oracle/tmp Return Value: 0 - success 1 - invalid stepfile 2 - installation error 3 - patching error
What I’m thinking is that the install process is defined in an input file called the stepfile. The stepfile needs to accomodate a large variety of organizational requirements. Here’s my first draft for what a stepfile would look like:
# This stepfile instructs the oracle auto-installer how to setup the oracle # home. Each line is executed in order from top to bottom. # # There are ten defined directives for this stepfile: # ORACLE_HOME - required # This will cause a search-replace of each response file to explicitly # define the oracle home. It must be defined before any open, install or # patch directives and it can only be defined once per stepfile. # Order of precedence: # 1. command line # 2. stepfile # 3. environment variable # ORAINST_TMP - optional # Top-level temp directory for extracting contents of Oracle installers # and patches. Each installer or patch will be extracted into a # subdirectory of this temp location. It must be defined before any # open or patch directives. It can be defined multiple times in a # stepfile. # Order of precedence: # 1. command line # 2. stepfile # 3. environment variable # 4. "/tmp/orainstall" # OPEN /path/to/zip # Path to a zip file with database installer or major patchset which # requires use if OUI. The file is unzipped into a temporary location. # If several INSTALL directives are encountered in a row then they are # all unzipped into the same location; if there is another directive in # between then the next INSTALL is unzipped into a new temporary # location. # INSTALLPATH Disk1/runInstaller # INSTALLRSP install.rsp # "runInstaller -waitForCompletion -silent -responseFile " # INSTALLPATH is optional - if not specified then the script will search # for it in the most recently created temp location. If there is more # than one runInstaller then it will use the first one it finds; search # order is undefined. # If no path is specified for the response file then orainstall will # search for it in this order: # 1. current working directory (pwd) when orainstall was launched # 2. same directory as orainstall binary (dirname $0) # OPATCH/path/p8000.zip # Path to special "OPatch" update - contents are unzipped directly to # ORACLE_HOME. # PATCH /path/p2345.zip # Path to a patch. Contents are unzipped to a temporary location then # applied by calling "opatch" from the ORACLE_HOME. # NPATCH /path/p1234.zip # Path to a patchset with multiple subpatches which need to be applied # with "napply" (such as a CPU). Contents are unzipped to temp location # then applied properly to the ORACLE_HOME. # CLEAN_TMP # Deletes all files from the current top-level temp directory. # REMOVE /path/to/file # Runs "rm -rf $ORACLE_HOME/path/to/file" - use carefully! Some sites # may require removal of components for security requirements. # # If there are any errors (install or patch) then the process will fail. # #oracle_home /u01/app/oracle/product/10.2.0/db_1 orainst_tmp /u01/app/oracle/installers.tmp open /net/rh5lab12/u10/stage/ora10201/B24792-01_1of5.zip open /net/rh5lab12/u10/stage/ora10201/B24792-01_2of5.zip open /net/rh5lab12/u10/stage/ora10201/B24792-01_3of5.zip open /net/rh5lab12/u10/stage/ora10201/B24792-01_4of5.zip open /net/rh5lab12/u10/stage/ora10201/B24792-01_5of5.zip installpath database/runInstaller installrsp /net/rh5lab12/u10/stage/rsp/database10201.rsp installpath companion/runInstaller installrsp /net/rh5lab12/u10/stage/rsp/companion10201.rsp open /net/rh5lab12/u10/stage/ora10203/p5337014_10203_Linux-x86-64.zip installrsp /net/rh5lab12/u10/stage/rsp/patchset10203.rsp clean_tmp orainst_tmp /u01/app/oracle/patches opatch /net/rh5lab12/u10/stage/patch10203/p6880880_10203_Linux-x86-64.zip patch /net/rh5lab12/u10/stage/patch10203/p5892355_10203_Linux-x86-64.zip patch /net/rh5lab12/u10/stage/patch10203/p6455161_10203_Linux-x86-64.zip npatch /net/rh5lab12/u10/stage/patch10203/p7150622_10203_Linux-x86-64.zip remove /htmldb
The program flow would be pretty basic; it would validate the stepfile then execute it one line at a time. I thought of six things to validate before starting execution:
- can read stepfile
- one oracle_home, defined before open/install/patch, can create/write
- orainst_tmp defined before open/install/patch, can create/write each
- clean_tmp not defined before orainst_tmp
- can read all open/install/patch input files
- free space in oracle_home is greater than size of input files
Maybe there aren’t as many people as I think who would use this. After all – most DBAs don’t install the database software very often; they just want to keep it running! But please let me know if it interests you. I’ll factor in the feedback I receive as I’m developing it.