Installing and Configuring Oracle Database 10g on the Solaris Platform

by Roger Schrag
Database Specialists, Inc.

Introduction

This paper will walk you through the steps of installing Oracle Database 10g release 1 (Oracle version 10.1.0) in a Sun Solaris SPARC environment. About 90% of the material presented here applies to other platforms as well. Everything you read in this paper is hands on, roll-up-your-sleeves-and-get-busy material for Oracle users who want to get an Oracle database up and running quickly without reading hundreds of pages of documentation and “readme” files.

These steps are meant to get you up and running as fast as possible, while leveraging best practices in order to set up a scalable, robust database environment that offers high performance. In order to keep the steps reasonably simple this paper does not cover Real Application Clusters (RAC), nor does it cover Oracle Internet Directory (OID), Automatic Storage Management (ASM), or Grid Control.

In this paper we will install the 10.1.0.4 release of Oracle Database 10g. This is the base distribution of Oracle Database 10g release 1 (10.1.0.2) with the 10.1.0.4 patch set applied on top. For this paper we ran our Oracle installations on Sun servers with SPARC processors running Solaris 8.

There are four phases to getting Oracle up and running on your server:

  1. Prepare the server
  2. Install the Oracle software and latest patch set
  3. Create a database
  4. Complete the server configuration
We will walk through these phases one at a time, detailing all the steps involved. The end result will be a very usable database that can be scaled up quite large, and an Oracle installation that follows industry-recognized best practices. Of course, every implementation is unique, and you will need to evaluate each step carefully against your particular requirements. However, this paper will get you off to a very solid start.

Prepare the Server

These steps configure your database server so that it will be ready to accept the Oracle software and database. In this section, we will make sure your server meets Oracle’s minimum requirements, create a Unix user and group to “own” the software, and create some directories that will be used by the Oracle software and database. All of the steps in this section are run as the root user.

  1. Make sure that your operating system platform is certified by Oracle Corporation for use with Oracle Database 10g. The 64 bit versions of Solaris 8, 9, and 10 for SPARC are certified for use with Oracle Database 10g, while the 32 bit versions are not. Some special steps and an extra Oracle patch are required to run Oracle Database 10g release 1 with Solaris 10. (These are detailed in Metalink bulletin 169706.1 and will be listed in the next step.) Solaris x86 is a different platform and is not covered in this paper.

    You can verify your operating system version and see whether it is the 32 or 64 bit version with the following commands: 

          $ uname -a
          $ /bin/isainfo -kv

  2. Make sure that your Solaris system has all of the required operating system patches installed. If you are running Solaris 8 or 9, the patch requirements are as follows:

    Patches for Solaris 8
    108528-23: SunOS 5.8: kernel update patch
    108652-66: X11 6.4.1: Xsun patch
    108773-18: SunOS 5.8: IIIM and X I/O Method patch
    108921-16: CDE 1.4: dtwm patch
    108940-53: Motif 1.2.7 and 2.1.1: Runtime lib. patch for Solaris 8
    108987-13: SunOS 5.8: Patch for patchadd and patchrm
    108989-02: /usr/kernel/sys/acctctl & /.../exacctsys patch
    108993-18: SunOS 5.8: LDAP2 client, libc, libthread ... lib. patch
    109147-24: SunOS 5.8: linker patch
    110386-03: SunOS 5.8: RBAC Feature Patch
    111023-02: SunOS 5.8: /kernel/fs/mntfs and ... sparcv9/mntfs
    111111-03: SunOS 5.8: /usr/bin/nawk patch
    111308-03: SunOS 5.8: /usr/lib/libmtmalloc.so.1 patch
    111310-01: SunOS 5.8: /usr/lib/libdhcpagent.so.1 patch
    112396-02: SunOS 5.8: /usr/bin/fgrep patch
    111721-04: SunOS 5.8: Math Library (libm) patch
    112003-03: SunOS 5.8: Unable to load fontset in 64-bit Solaris 8 iso-1 or iso-15
    112138-01: SunOS 5.8: usr/bin/domainname patch

    Patches for Solaris 9
    112233-11: SunOS 5.9: Kernel Patch
    111722-04: SunOS 5.9: Math Library (libm) patch

    You can see if a specific patch has been installed with the following command: 

          $ /usr/sbin/patchadd -p | grep <patch_number>
    You may download necessary Solaris patches from http://sunsolve.sun.com. The revision numbers on the required patches listed above are minimums—you may install a newer version of a patch than what is listed here. For example, patch 108940-53 is required for Solaris 8, but installing patch 108940-65 instead is allowed.

    If you are running Solaris 10, no specific operating system patches are required. However, special extra steps are required during the installation process. See Metalink bulletin 169706.1 for details, but the basic points of interest are as follows:

  3. Make sure that the following software packages have been installed.

    Required Packages
    SUNWarc
    SUNWbtool
    SUNWhea
    SUNWlibm
    SUNWlibms
    SUNWsprot
    SUNWtoo
    SUNWi1of
    SUNWxwfnt
    SUNWi1cs
    SUNWsprox
    SUNWi15cs

    You can use the following command to verify that a package has been installed: 

          $ pkginfo -i <package name>
  4. You will need to perform the installation from an X window environment—you cannot use a character mode environment such as a telnet or SSH session. There is a facility for performing non-interactive installations (“silent” installs), but we won’t be covering that technique here. Your X environment can be the console on the database server, but it does not need to be. You can also use a Windows X emulator like Cygwin. If the database server is in a remote location, you can use SSH to securely forward X traffic from the database server back to your desktop. I ran the installation from a Windows desktop using Cygwin and had no problems

  5. The following executables must be present in /usr/ccs/bin: make, ar, ld, nm.

  6. Make sure that your hardware is sufficient. You’ll need at least 512 Mb RAM, a swap space at least twice the size of physical memory (less swap space is okay if you have 2 Gb or more of RAM), and a bare minimum of 2.7 Gb of disk space. This will let you perform a “typical” Enterprise or Standard Edition software installation from CD ROM and create a starter database. If you will be downloading the Oracle software from http://otn.oracle.com, you will need about 1.4 Gb of additional disk space to stage and unpack the Oracle software. A production implementation will almost always require more RAM and more disk space than the minimums listed here. The following commands will allow you to check physical memory and swap space (blocks of swap space are 512 bytes each): 
          $ /usr/sbin/prtconf | grep size
          $ /usr/sbin/swap -l
  7. The Oracle installer will need access to a directory with at least 400 Mb of free space for writing temporary files during installation. Usually /tmp serves this purpose. If /tmp on your database server has less than 400 Mb of free space, then you will need to locate another directory with sufficient free space for use during the installation.

  8. Make sure that the Solaris kernel has parameters set sufficiently high for Oracle. The Oracle architecture makes extensive use of shared memory segments for sharing data among multiple processes and semaphores for handling locking. Many operating systems, including Solaris, do not by default offer sufficient shared memory or semaphores for maintaining an Oracle database. Happily, you can change kernel parameters in Solaris simply by editing the /etc/system file and rebooting the server.

    Kernel Parameter Setting To Get
    You Started    		 Purpose
    SHMMAX 4294967295 Maximum size of a single shared memory segment
    SHMMIN [1] 1 Minimum size of a single shared memory segment
    SHMMNI 100 Maximum number of shared memory segments in entire system
    SHMSEG [1] 10 Maximum number of shared memory segments one process can attach
    SEMMNS 1024 Maximum number of semaphores in entire system
    SEMMSL 256 Maximum number of semaphores per set
    SEMMNI 100 Maximum number of semaphore sets in entire system
    SEMVMX 32767 Maximum allowed semaphore value
    NOEXEC_USER_STACK [1] 1 Disable certain types of stack buffer overflow exploits
    [1] Applies to Solaris 8 only.

    The first four kernel parameters configure shared memory segments. The recommended settings shown here should be appropriate for almost any Oracle database implementation. The SHMMAX setting may seem excessive, but there is no penalty for setting SHMMAX larger than you actually need.

    The next four kernel parameters configure semaphores. Each Oracle instance requires one semaphore for each process, plus ten extras. Additionally, the largest instance requires a second semaphore for each process. If you will only be setting up one database on your server, the upshot is that you will need two semaphores for each process plus ten extras.

    The recommended settings for the first two semaphore kernel parameters, SEMMNS and SEMMSL, should be appropriate for most Oracle implementations. For systems with large numbers of concurrent database connections, you may need to increase these values. The recommended setting shown here for SEMMNI and SEMVMX should be appropriate for just about any Oracle database implementation.

    Note that these recommended settings assume you have no other applications running on the database server that use shared memory segments or semaphores. You can view current shared memory and semaphore usage on your system with the following command: 

          $ ipcs -Ams

    In general, if your Solaris kernel already has any of these parameters set larger than recommended here, you should not reduce the settings. If you do change any kernel parameter settings in /etc/system, then reboot the server so that the new settings will take effect.

    I added the following lines to the end of my /etc/system file: 

          set shmsys:shminfo_shmmax=4294967295
          set shmsys:shminfo_shmmin=1
          set shmsys:shminfo_shmmni=100
          set shmsys:shminfo_shmseg=10
          set semsys:seminfo_semmns=1024
          set semsys:seminfo_semmsl=256
          set semsys:seminfo_semmni=100
          set semsys:seminfo_semvmx=32767
          set noexec_user_stack=1
  9. Create a Unix group that will be used by the Oracle software owner and database administrators. You can call it anything you like, but the standard is “dba”. Anybody who logs onto the database server with a Unix login that belongs to this group will be able to log onto all databases that run from this Oracle software installation with DBA privileges. If you will be installing Oracle on multiple servers on your network, you might want to keep the groupid the same on all servers. You can create your dba group with a command like: 
          $ groupadd -g 300 dba
  10. If you will be installing multiple copies of the Oracle software on one database server and you will want some Unix logins to be able to log onto some databases with DBA privileges but not others, then you will need to create a different “dba” group for each Oracle software installation. In that case you will also need to create one additional Unix group called “oinstall”. You can create the oinstall group with a command like: 
          $ groupadd -g 301 oinstall
    Remember, you do not need to create an oinstall Unix group if you will only be installing one Oracle software installation on the database server, or if all of the Oracle software installations will share the same dba group.

  11. Create a Unix user that will be the Oracle software owner. You can call it anything you like, but the standard is “oracle”. If you will be installing Oracle on multiple servers on your network, you might want to keep the userid the same on all servers. Note that this user’s home directory will not be the ORACLE_HOME or where the actual Oracle software is installed; this user’s home directory should be in the same place as other users’ home directories.

    The group affiliations for this user will depend on whether or not you created an oinstall Unix group in the previous step. If you did not create an oinstall group, then you should make dba the primary group for the oracle user. In this case, you can create your oracle user with commands like: 

          $ useradd -c 'Oracle software owner' -d /home/oracle \
                    -g dba -m -u 300 -s /usr/bin/ksh oracle
          $ passwd oracle
    If you did create an oinstall group in the previous step, then you should make oinstall the primary group for the oracle user and dba a secondary group. In this case, you can create your oracle user with commands like: 
          $ useradd -c 'Oracle software owner' -d /home/oracle \
                    -g oinstall -G dba -m -u 300 -s /usr/bin/ksh oracle
          $ passwd oracle
    The useradd commands shown here give your oracle user the Korn shell. You could just as easily choose Bash or Bourne instead.

  12. Create mount points for the Oracle software and the Oracle database. Each mount point should correspond to a separate physical device or set of devices. You’ll need at least one mount point. Typically you use one mount point for the Oracle software and one or more mount points for each database. One common convention is to call the mount points /u01, /u02, and so on. Because mount points are typically owned by root and the Oracle installer will run as the oracle user and not as root, you should create some subdirectories now to avoid permission problems later. Create an app/oracle subdirectory below the software mount point, and oradata subdirectories below the mount points to be used for database files. (You can put software and a database on the same mount point if you wish.) Make these subdirectories owned by the oracle user and dba group (or oinstall group if you are going that route), and give them 775 permissions. You can use commands like: 
          $ mkdir /u01/app /u01/app/oracle /u01/oradata
          $ chown oracle:dba /u01/app /u01/app/oracle /u01/oradata
          $ chmod 775 /u01/app /u01/app/oracle /u01/oradata
  13. If you downloaded the Oracle software off of the Internet, then use gunzip and cpio to unpack the distribution. Use commands like: 
          $ gunzip ship_rel10_sol64_db.cpio.gz
          $ cpio -idm < ship_rel10_sol64_db.cpio
    If you have the software on CD ROM, then mount the Oracle Database 10g CD ROM now.

  14. Create the /var/opt/oracle directory and make it owned by the oracle user. After installation, this directory will contain a few small text files that briefly describe the Oracle software installations and databases on the server. These commands will create the directory and give it appropriate permissions: 
          $ mkdir /var/opt/oracle
          $ chown oracle:dba /var/opt/oracle
          $ chmod 755 /var/opt/oracle
Install the Oracle Software and Latest Patch Set

These steps install the Oracle software and latest patch set on your server. As of this writing, Oracle release 10.1.0.2 is the only version of Oracle Database 10g release 1 (for Solaris SPARC) available for download from Oracle Technology Network or on CD ROM. However, the current patch set is 10.1.0.4. Therefore, we will install Oracle release 10.1.0.2 and apply patch set 10.1.0.4 on top of the installation. Before proceeding with the steps in this section, you should check Oracle Technology Network (http://otn.oracle.com) and Oracle Metalink (http://metalink.oracle.com) to see if any newer releases and/or patch sets are available.

The Oracle Universal Installer will suggest creating a database at the same time that it installs the Oracle software. It will be better to hold off on database creation until after the latest patch set has been applied—this will allow us to avoid having to patch the newly created database when installing the patch set.

In this section, we will prepare the oracle Unix user’s environment, run the Oracle Universal Installer twice (once to install the base release and once to install the latest patch set), and tidy up a few minor loose ends. All of the steps in this section, except where noted, are run as the oracle user.

  1. Edit the oracle user’s login file on the database server so that the environment will be configured automatically on login. If you are using Bourne or Korn shell, then edit .profile. If you are using Bash shell, then edit .bash_profile. You can also use C shell and edit .cshrc, but the syntax will be different from the examples you see here. For now, we will hardcode certain things. But after we create a database, we will come back and eliminate all hardcodings. Here is what I added to my .profile for the install: 
          umask 022
          #
          # Substitute your Oracle software mount point in the line below.
          export ORACLE_BASE=/u01/app/oracle
          #
          # Ensure that ORACLE_HOME and TNS_ADMIN are not set.
          unset ORACLE_HOME
          unset TNS_ADMIN
          #
          # If your /tmp directory has less than 400 Mb free, then edit
          # and uncomment the following three lines.
          # TEMP=/mount_point_with_400_mb_free
          # TMPDIR=/same_mount_point
          # export TEMP TMPDIR
          #
          # The documentation does not mention how PATH should be set.
          # The following PATH setting worked for me:
          export PATH=/usr/bin:/usr/local/bin:/usr/ccs/bin
  2. Log out and log back in as the oracle user from an X window so that the environment is set correctly. If you will be performing the installation from a PC or other workstation instead of using the database server’s console directly, you may wish to forward X window traffic over an SSH connection. This offers increased security (in the case of a public network) and convenience. If you will be performing the installation from a Windows PC, you can use PuTTY to forward your X window traffic by selecting the “Enable X11 forwarding” checkbox in PuTTY’s SSH Tunnels configuration screen.

  3. Make sure your DISPLAY variable is set. If you are forwarding X window traffic over an SSH connection or working from the server’s console directly, the DISPLAY variable will probably already be set for you. If your DISPLAY variable has not been set already, then you will need to set it manually to the IP address of your X server plus the X server and screen numbers. You can set your DISPLAY variable with a command like: 
          $ export DISPLAY=myworkstation:0.0
  4. If you are not using the console of the database server or forwarding X window traffic over an SSH connection, then ensure that the X server on your workstation will allow your database server to open windows on your display. The easiest way to do this is to issue an xhost command from a session on your workstation. (Don’t get confused and issue the command in a window that is logged onto your database server.) You can issue a command like: 
          $ xhost +mydatabaseserver
  5. Ensure that the mount point you plan to use for the Oracle software has sufficient free space. For a basic Enterprise Edition and patch set installation, allow 1.8 Gb for the software mount point as a bare minimum. You will need more space if you plan to install non-default options or components from the Oracle Database 10g Companion CD ROM.

  6. Double check that you are logged in as oracle and not root. Then change to your home directory and start the Oracle Universal Installer with these commands: 
          $ cd
          $ <full path to CD ROM>/runInstaller
    We’ll walk through the installer prompts one at a time:

    1. The Welcome window appears. Click Next.
    2. If the Specify Inventory Directory and Credentials window appears, verify that the inventory directory is set to the oraInventory subdirectory of the directory referenced by the ORACLE_BASE environment variable you set in the login script. In the Operating System Group Name field, select the oinstall group (or the dba group if you did not create the oinstall group). Click OK. You won't see this window if you have previously installed Oracle software on the database server.
    3. If the Unix Group Name window appears, enter the name of your dba group and click Next. You won’t see this window if you have previously installed Oracle software on the database server, or if your dba group is called “dba”. (You won’t see this window the next time you run the installer because Oracle saves this information in the /var/opt/oracle/oraInst.loc file.)
    4. The Specify File Locations window appears. Leave the Source field unchanged. Oracle provides a suggested Name and Path for the Oracle home (software installation) that is about to be created. You can name this Oracle home anything you like. For the path, you will probably want to go with the suggestion provided but you don’t have to. Beginning in Oracle 10g the standard for Oracle home location has changed to /<mount-point>/app/oracle/product/10.1.0/db_<N>. The new component at the end, such as db_1 or db_2, allows you to install multiple copies of the same Oracle version on one server in a standardized way. Note that we will refer back to this path frequently, calling it the Oracle home or simply $ORACLE_HOME. When you are satisfied with the name and path for your Oracle home, click Next.
    5. The Select Installation Type window appears. We will perform a “typical” install to get a basic set of Oracle software installed. You can rerun the installer again later and choose Custom to install additional products individually. For now, choose Standard Edition or Enterprise Edition. The Enterprise Edition of Oracle Database 10g has some very sophisticated features missing from Standard Edition, and the opportunity to purchase additional options that might be valuable to a large enterprise. However, the Enterprise Edition is much more expensive than Standard Edition. It is very important that you choose the edition that matches your license, as this will be difficult to fix later. Click Next.
    6. At this point Oracle performs a minimum requirements check. If you performed all of the preparation steps correctly, all checks should be successful and you can simply click the Next button. If there are any problems, you can correct the problem and click Retry.
    7. If you have any existing Oracle databases on your server that are at a version prior to what you are now installing, the installer will ask if you would like to run the Database Upgrade Assistant at the end of the installation to migrate or upgrade these older databases to the current version. Make your decision and click Next. (We won’t be covering the Database Upgrade Assistant here.)
    8. The Select Database Configuration window appears. We could have Oracle create a database at the same time the software is installed, but this would not be a good idea because we would have to immediately patch the database when we apply the patch set. We will choose the “Do not create a starter database” option instead. After we have applied the patch set, we will use the Database Configuration Assistant to create a database. Click Next.
    9. The Summary window appears. Review all of the selections you have made to confirm they are correct. Click Install.
    10. During the installation a Setup Privileges window will appear. The installation will be paused at this point, waiting for you to run a script as root. The script will be called root.sh and can be found in the Oracle home directory (the directory you specified as the Path in the File Locations window). You should open another window, log in to the database server as root, review the root.sh script thoroughly, run the script, and click OK in the Setup Privileges window.
    11. The End of Installation window appears. URLs for various features, such as Ultra Search and iSQL*Plus, will be displayed. Note these URLs for future reference. Click Exit to exit the installer.
    12. You can run the installer again and perform a custom installation to install any individual products that did not get installed as part of the “typical” installation.
    13. It is important to note that the default Enterprise Edition install loads certain extra cost options, such as OLAP and table partitioning, onto your database server. If you are not licensed to use these options, then you should deinstall them. To deinstall products, restart the installer and click the Deinstall Products button on the Welcome window.

  7. The root.sh script that you ran as root during the installation process started a cluster services daemon that runs as the root user. We will need to stop this daemon before we can apply the Oracle patch set. Oracle only needs the cluster services daemon on database servers that use Oracle’s Automatic Storage Management (ASM) or Real Application Clusters (RAC). Since we will not be using either of these facilities, there will be no need to have this daemon run at all. We cannot simply kill the daemon, because the root.sh script added a “respawn” entry to the inittab. (If we kill the daemon, the operating system will restart it.)

    To stop the cluster services daemon and prevent it from restarting immediately or when the server is rebooted in the future, we will need to restore the inittab to is previous state. Luckily, the root.sh script preserved a backup copy before editing the inittab. First, doublecheck that the backup copy of inittab is identical to the real inittab except for the one entry added by the root.sh script: 

          $ diff /etc/inittab.orig /etc/inittab
    Next, run the following commands very carefully as root: 
          $ mv /etc/inittab.orig /etc/inittab
          $ /etc/init.d/init.cssd stop
          $ mv /etc/rc3.d/S96init.cssd /etc/rc3.d/_S96init.cssd
          $ mv /etc/rc3.d/K96init.cssd /etc/rc3.d/_K96init.cssd
  8. At this point we are ready to patch the Oracle software installation. Log onto Oracle Metalink (http://metalink.oracle.com) and download the latest patch set for Sun Solaris SPARC. As of this writing, release 10.1.0.4 (patch number 4163362) is the latest.

  9. Use a command like the following to unpack the patch set: 
          $ unzip p4163362_10104_SOLARIS64.zip
  10. Double check that you are logged in as oracle and not root, and that your DISPLAY environment variable is still set correctly. Then change to the directory where you unpacked the patch set and start the Oracle Universal Installer with these commands: 
          $ cd <location of unpacked patch set>/Disk1
          $ ./runInstaller
    Once again, we’ll walk through the installer prompts one at a time:

    1. The Welcome window appears. Click Next.
    2. The Specify File Locations window appears. Leave the Source Path field unchanged. For the Destination, use the dropdown list on the Name or Path fields to select the Oracle home where you just installed Oracle software in the previous steps. Do not go with a different Destination Name or Path, even if the installer has defaulted these fields this way. Click Next.
    3. The Summary window appears. Click Install.
    4. During the installation a Setup Privileges window will appear. Once again the installation will be paused at this point, waiting for you to run a root.sh script as root. As before, the script can be found in the Oracle home directory. You should open another window, log in to the database server as root, and review the root.sh script thoroughly before running it. The script will detect that Oracle cluster software has already been installed and cnfigured, but it might complain that the daemon is not running. You can ignore messages along the lines of “Oracle Cluster Registry for cluster has already been initialized” and “Giving up: Oracle CSS stack appears NOT to be running”. Click OK in the Setup Privileges window after running the script.
    5. The End of Installation window appears. Click Exit to exit the installer.

  11. In $ORACLE_HOME/bin (the bin directory under your Oracle home) you will find a shell script called oraenv. This script can be called from .profile or .bash_profile to set up a user’s environment automatically whenever they log onto the database server. We will customize the oraenv script because there are a few variables that the script should set but doesn’t. Make a backup copy of the oraenv script and then edit it, adding the following lines to the very end:
    12.       # Begin customizations
          ORACLE_BASE=`dirname $ORACLE_HOME`
          ORACLE_BASE=`dirname $ORACLE_BASE`
          case "$ORACLE_BASE" in
            */product) ORACLE_BASE=`dirname $ORACLE_BASE` ;;
            *)         ;;
          esac
          DBA=$ORACLE_BASE/admin
          # Substitute the locale and character set you plan to use for your
          # database in the line below. Some common choices are:
          #   NLS_LANG=american_america.WE8ISO8859P1 (Unix default)
          #   NLS_LANG=american_america.AL32UTF8     (Unicode 3.1)
          #   NLS_LANG=american_america.UTF8         (Unicode 3.0)
          #   NLS_LANG=american_america.WE8MSWIN1252 (Windows)
          NLS_LANG=american_america.WE8ISO8859P1
          export ORACLE_BASE DBA NLS_LANG
          # End customizations
  12. In the same directory you’ll also find a shell script called coraenv that can be called from .cshrc. If you use C shell, you will want to back up and edit coraenv with similar changes to the oraenv script.

  13. The root.sh script copied oraenv and coraenv from $ORACLE_HOME/bin to your local bin directory. You just updated these scripts in $ORACLE_HOME/bin. Copy the updated versions to your local bin directory.

Create a Database

These steps create an Oracle database. Everybody will have different needs for their database, but the steps here will yield you a functional database that you can further tailor to your specific needs. In this section we will use the Database Configuration Assistant to create a database, adjust the database in order to better comply with industry-proven best practices, and configure Oracle Net. All of the steps in this section are run as the oracle user.

  1. Set up your environment the same way you did when you ran the Oracle Universal Installer: Log in as the oracle user on the database server from an X window, set your DISPLAY variable appropriately, and make sure that your ORACLE_BASE variable is set correctly based on your login file.

  2. Set the ORACLE_HOME environment variable to point to your Oracle home with a command like: 
          $ export ORACLE_HOME=/u01/app/oracle/product/10.1.0/db_1
  3. Choose a name for your Oracle instance, up to eight characters long. The instance name is easy to change at any time. However, you will want to keep the instance name the same as the database name in order to avoid confusion. Changing the database name later is possible, but not the easiest thing to do. So pick a name for the instance that you like. Set the ORACLE_SID variable accordingly with a command like: 
          $ export ORACLE_SID=dev101ee
  4. Launch the Database Configuration Assistant with the following commands: 
          $ cd $ORACLE_HOME/bin
          $ ./dbca
    We’ll walk through the prompts one at a time:

    1. The Welcome window appears. Click Next.
    2. The Operations window appears. Choose “Create a Database” and click Next.
    3. The Database Templates window appears. Here you choose a template (a set of default specifications) for the database you wish to create. Oracle provides templates called “Data Warehouse,” “General Purpose,” and “Transaction Processing.” Oracle has prebuilt data files available for these three templates, meaning that database creation will go faster than if Oracle has to build the database from scratch. You can also choose Custom and create your own template. We will choose General Purpose here. Click Next.
    4. The Database Identification window appears. Here you specify the global name and the instance name (SID) for the database. It would be nice if these fields defaulted from the ORACLE_SID environment variable, but this may or may not happen. In the Global Database Name field, enter the database name you selected, followed by a period and your domain name. For example, “dev101ee.dbspecialists.com”. The SID field will fill in automatically from the global name. Click Next.
    5. The Management Options window appears. Here you indicate whether or not you wish to have the Enterprise Manager tool configured. Grid Control is Oracle’s enterprise-wide database management tool. This option will be grayed out if Grid Control infrastructure has not already been established. Database Control is a stand-alone management tool specifically configured to manage one database. If Grid Control is not present, the defaults in this window will specify to configure Database Control for this database. This will enable you to perform many database management functions for this database from a web browser. You may optionally configure Database Control to send you alerts via email and to back up the database daily. It does not hurt to choose Database Control configuration at this time—you can always shut it down later. We will not be covering the database backup feature here. Click Next.
    6. The Database Credentials window appears. Every Oracle 10g database has accounts called SYS, SYSTEM, DBSNMP, and SYSMAN. You must provide passwords for each of these accounts, although you can choose to give all four the same password. It is easy to change passwords later, and members of the dba Unix group can access the database without a password and change passwords for any database account. Enter the initial passwords for these accounts and click Next.
    7. The Storage Options window appears. The files that make up an Oracle database can be stored on a regular file system, raw devices, or disks managed automatically by Oracle’s Automatic Storage Management facility. We will not be covering raw devices or ASM here, so select File System and click Next.
    8. The Database File Locations window appears. Here you specify where on the file system the files that make up the database should initially reside. It will be easy to change file locations later, and database files can be spread over multiple directories. The default option on this window is to use the file location specified in the template. This is not a good idea as the location specified by the templates goes against standard conventions. Instead you should select “Use Common Location for All Database Files” and enter a mount point name followed by the oradata subdirectory, such as “/u01/oradata”. The location you enter here should match one of the directories you created in step 12 of the first section above. Click Next.
    9. The Recovery Configuration window appears. A solid backup and recovery plan is absolutely necessary for any database that will hold data of any importance. However, there are many options available and needs vary greatly from one situation to the next. The flash recovery area is used by the “Flashback database” feature and also by Enterprise Manager if you chose to configure automatic database backups. Archiving, meanwhile, is necessary for databases that will be backed up while they are open. Archiving can be enabled easily at a later time. Since we are not covering backup and recovery strategies here, we will uncheck both options and click Next.
    10. The Database Content window appears. This window contains multiple tabs where you may choose what data will be preloaded in the new database. Your options here will vary depending on which Oracle software options you installed and which database creation template you chose. Typically there will be no need for you to specify any custom scripts, and preloading the sample schemas can be helpful in a development database for seeing examples of various techniques. Make your selections and click Next.
    11. The Initialization Parameters window appears. If your database server has only 512 Mb of physical memory, an error window may appear which you can ignore. The error arises from the fact that default settings for memory-related initialization parameters are derived from the amount of physical memory, and a flaw in the algorithm picks a default value that is too small on machines with only 512 Mb of physical memory. Tabs in this window let you set various initialization parameters, and a button lets you view and edit all parameters in a tabular form. Click on the Character Sets tab and select the character set for the database that matches the character set name you put into the oraenv script in an earlier step. It is hard to change the character set of a database, so make sure you are happy with your selection before proceeding. Initialization parameters, on the other hand, are easily changed later. In this window, therefore, you should make sure the character set is correct but not worry too much about the other settings. (Setting the character sets is very different from setting initialization parameters, so the fact that the Character Sets tab appears on a window entitled Initialization Parameters may be confusing.) Click Next.
    12. The Database Storage window appears. Here you can review and edit the details of how the control files, online redo logs, data files, and tablespaces will be created. If you are using one of the templates that was provided, you will not be able to change very many settings. If you want to change the locations of some of the database files, you can do that here or after the database has been created. The default redo log size (10 Mb) is somewhat small, so yu might want to change it. Again, you can do that here or after the database has been created. When you are satisfied with the settings, click Next.
    13. The Creation Options window appears. You may choose to create the database now and/or save the settings as a template. Saving as a template allows you to create the database at a later time or create many similar databases more easily. Click Finish.
    14. A Confirmation window appears. Review all of your selections and click OK.
    15. A progress window appears and database creation proceeds.
    16. When database creation is complete, a window will appear which indicates the name of the database, the location of the parameter file, and the URL for accessing Enterprise Manager. Note this URL for future reference. Depending n what options you selected, additional accounts may have been created on the database besides the basic SYS, SYSTEM, DBSNMP, and SYSMAN. All additional accounts are now locked. You may click the Password Management button to unlock these accounts and set passwords if you wish, but you should only unlock an account if you have a specific reason for doing so. When you are finished, click the Exit button to exit the Database Creation Assistant.

  5. While logged onto the database server as the oracle user, run the following commands to set environment variables so that you will be able to access the database easily (substitute your Oracle instance name): 
          $ export ORACLE_SID=dev101ee
          $ export ORAENV_ASK=NO
          $ . /usr/local/bin/oraenv
  6. If you would like to move any of the data files or online redo logs for this database to another directory, use commands like the following: 
          $ sqlplus /nolog
          SQL> CONNECT / AS SYSDBA
          SQL> SHUTDOWN IMMEDIATE
          SQL> STARTUP MOUNT
          SQL> HOST mv -i /u01/oradata/dev101ee/users01.dbf /u02/oradata/dev101ee/users01.dbf
          SQL> ALTER DATABASE RENAME FILE
            2  '/u01/oradata/dev101ee/users01.dbf' TO
            3  '/u02/oradata/dev101ee/users01.dbf';
          SQL> HOST mv -i /u01/oradata/dev101ee/redo01.log /u02/oradata/dev101ee/redo01.log
          SQL> ALTER DATABASE RENAME FILE
            2  '/u01/oradata/dev101ee/redo01.log' TO
            3  '/u02/oradata/dev101ee/redo01.log';
          SQL> ALTER DATABASE OPEN;
          SQL> EXIT
    Note that this procedure does not work for control files. Relocating database control files will be covered in a later step.

  7. In databases created with supplied templates, all data files have the “auto-extend” feature turned on. This means that when a data file becomes full, it will automatically grow larger as needed. The problem with this is that an application can get out of control and fill up an entire disk partition. It also means that you need to manage your free space at the operating system level. Many DBAs prefer to manage free space at the database level by pre-allocating space to data files and not using the auto-extend feature. You may resize data files and disable auto-extend with commands like: 
          $ sqlplus /nolog
          SQL> CONNECT / AS SYSDBA
          SQL> ALTER DATABASE DATAFILE '/u01/oradata/dev101ee/system01.dbf' AUTOEXTEND OFF;
          SQL> ALTER DATABASE DATAFILE '/u01/oradata/dev101ee/sysaux01.dbf' AUTOEXTEND OFF;
          SQL> ALTER DATABASE DATAFILE '/u01/oradata/dev101ee/undotbs01.dbf' AUTOEXTEND OFF;
          SQL> ALTER DATABASE DATAFILE '/u01/oradata/dev101ee/example01.dbf' AUTOEXTEND OFF;
          SQL> ALTER DATABASE DATAFILE '/u01/oradata/dev101ee/users01.dbf' AUTOEXTEND OFF;
          SQL> ALTER DATABASE TEMPFILE '/u01/oradata/dev101ee/temp01.dbf' AUTOEXTEND OFF;
          SQL> ALTER DATABASE DATAFILE '/u01/oradata/dev101ee/system01.dbf' RESIZE 500m;
          SQL> ALTER DATABASE DATAFILE '/u01/oradata/dev101ee/sysaux01.dbf' RESIZE 300m;
          SQL> ALTER DATABASE DATAFILE '/u01/oradata/dev101ee/undotbs01.dbf' RESIZE 50m;
          SQL> ALTER DATABASE TEMPFILE '/u01/oradata/dev101ee/temp01.dbf' RESIZE 50m;
  8. Oracle uses a server parameter file or “spfile” to store the initialization parameters—settings that affect the instance. The default parameter settings provided by the Database Configuration Assistant are not bad, but you may want to make some changes. Unfortunately, you cannot edit the spfile. Instead, you must export the contents of the spfile to a plain text file called a “pfile”. You can then edit the pfile and convert it back to an spfile for use on your database. (This might sound confusing, but is actually pretty straightforward.)

    Shut down the database and export the contents of the spfile into a pfile that you can edit with commands like: 

          $ sqlplus /nolog
          SQL> CONNECT / AS SYSDBA
          SQL> CREATE PFILE='/home/oracle/dev101ee-params.txt'
            2  FROM SPFILE;
          SQL> SHUTDOWN IMMEDIATE
  9. Make a backup copy of the pfile you created in the previous step and edit the pfile to change parameters as you wish, based on your needs and your server’s capabilities. You can always change parameters again in the future, so you are not locking yourself into anything right now. Here is the pfile that I ended up with: 
          *.background_dump_dest='/u01/app/oracle/admin/dev101ee/bdump'
          *.compatible='10.1.0.4.0'
          *.control_files='/u01/oradata/dev101ee/control01.ctl','/u01/oradata/
          dev101ee/control02.ctl','/u01/oradata/dev101ee/control03.ctl'
          *.core_dump_dest='/u01/app/oracle/admin/dev101ee/cdump'
          *.db_block_size=8192
          *.db_domain='dbspecialists.com'
          *.db_file_multiblock_read_count=16
          *.db_name='dev101ee'
          *.job_queue_processes=10
          *.open_cursors=300
          *.os_authent_prefix=''
          *.pga_aggregate_target=400    #Should be 16% of Server Physical memory,so for 2GB should be 327M, for 4 GB should be 655M
          *.processes=50
          *.remote_login_passwordfile='EXCLUSIVE'
          *.sga_target=240m
          *.undo_management='AUTO'
          *.undo_tablespace='UNDOTBS1'
          *.user_dump_dest='/u01/app/oracle/admin/dev101ee/udump'
  10. The database is created with three control files. The control file is a pretty small file that contains crucial configuration and synchronization information that Oracle needs in order to locate all the files that make up the database and keep them consistent. All three copies of the control file are kept identical; whatever Oracle writes to one control file it also writes to the other two. (Think of it like software mirroring.) It is a good idea to move at least one of the control files to another location. With the database shut down, you can go ahead and move the control files around as you wish. Be sure to change the control_files entry in your pfile accordingly.

  11. Remove the existing spfile that the Database Configuration Assistant created, and the bogus pfile that it left behind, with the following commands: 
          $ rm -i $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora
          $ rm -i $ORACLE_BASE/admin/$ORACLE_SID/pfile/init.ora*
  12. Create a symbolic link from the location where Oracle looks for the spfile to the location where you will actually maintain the spfile: 
          $ ln -s $ORACLE_BASE/admin/$ORACLE_SID/pfile/spfile$ORACLE_SID.ora \
                  $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora
  13. Now convert the pfile that you edited back into an spfile that Oracle can use with the following commands: 
          $ sqlplus /nolog
          SQL> CONNECT / AS SYSDBA
          SQL> CREATE SPFILE='$ORACLE_BASE/admin/$ORACLE_SID/pfile/spfile$ORACLE_SID.ora'
            2  FROM PFILE='/home/oracle/dev101ee-params.txt';
  14. You are now ready to restart your database using your newly created spfile. Use the following commands to start the database and view the parameters that are in effect. These settings should match what you put in your pfile a few steps back: 
          $ sqlplus /nolog
          SQL> CONNECT / AS SYSDBA
          SQL> STARTUP
          SQL> SET PAGESIZE 100
          SQL> SELECT   name, value, isdefault
            2  FROM     v$parameter
            3  ORDER BY isdefault, name;
  15. You can follow the above few steps at any time to make further changes to the parameters. However, if you only have a few changes to make, there is a much easier way than exporting the spfile into a pfile, editing the pfile, and converting back to an spfile. You can simply: 
          $ sqlplus /nolog
          SQL> CONNECT / AS SYSDBA
          SQL> ALTER SYSTEM SET parameter = value
            2  SCOPE = SPFILE;
    This will update the setting in your spfile, and the change will take effect the next time you restart the database. Many parameters are dynamic, meaning that you can change them on the fly without restarting the database. For dynamic parameters, you can omit the SCOPE = line above and Oracle will change the parameter setting immediately and in the spfile.

  16. Oracle Net is the networking infrastructure that allows applications running on other servers to access the database. The Oracle Net listener is a process that runs on the database server and monitors a TCP port for requests to access the database. The Oracle Net listener is configured by creating a file called listener.ora in the $ORACLE_HOME/network/admin directory. In the $ORACLE_HOME/network/admin/samples directory you will find an example listener.ora file. Unfortunately, many Oracle security exploits involve the Oracle Net listener, and therefore it is important that you configure it properly and securely. A functional listener.ora file that uses operating system authentication for securing the Oracle Net listener is as follows: 
          #
          # Filename: listener.ora
          # 
          LISTENER =
            (DESCRIPTION_LIST =
              (DESCRIPTION =
                (ADDRESS_LIST =
                  (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.16)(PORT = 1521))
                )
              )
            )
          SID_LIST_LISTENER =
            (SID_LIST =
              (SID_DESC =
                (GLOBAL_DBNAME = dev101ee.dbspecialists.com)
                (ORACLE_HOME = /u01/app/oracle/product/10.1.0/db_1)
                (SID_NAME = dev101ee)
              )
            )
    The permissions on the listener.ora file should be 640.

  17. Start the Oracle Net listener with the following command: 
          $ lsnrctl start
  18. The Oracle client libraries invoked by an application wishing to access the database read configuration files called sqlnet.ora and tnsnames.ora in order to figure out how to find the Oracle Net listener and what connection parameters should be used. In the same directory where the sample listener.ora file is located, you will also find a sample sqlnet.ora and tnsnames.ora. You should create a sqlnet.ora file and a tnsnames.ora file in the same directory where you created your listener.ora file. Set the file permissions to 644. Copy these two files to all application servers or other machines that will access the database. Functional sqlnet.ora and tnsnames.ora files are as follows: 
          #
          # Filename: sqlnet.ora
          #
          NAMES.DEFAULT_DOMAIN = dbspecialists.com
          NAMES.DIRECTORY_PATH= (TNSNAMES)

          #
          # Filename: tnsnames.ora 
          #  
          DEV101EE.DBSPECIALISTS.COM =
            (DESCRIPTION =
              (ADDRESS_LIST =
                (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.16)(PORT = 1521))
              )
              (CONNECT_DATA =
                (SERVICE_NAME = dev101ee.dbspecialists.com)
              )
            )
  19. You can verify that Oracle Net is configured correctly by attempting to access the database from an application server or other remote server, or by using commands like the following on the database server directly: 
          $ sqlplus /nolog
          SQL> CONNECT system@dev101ee
          Enter password: <Enter SYSTEM password>
  20. At this point you are ready to create tablespaces—logical groupings of data files—to hold your application data. You can put all of your data into one tablespace, or you can separate data into multiple tablespaces based on object type, object size, permanence, volatility, I/O volume, or any of a number of other criteria. In the past, choosing storage parameters and allocation schemes for database objects was rather tedious. Now it is quite simple because you can have Oracle do the space allocation and management automatically and it will do a pretty good job. Here is a sample tablespace creation statement for an application called “Flex”: 
          CREATE TABLESPACE flex_data
          DATAFILE '/u02/oradata/dev101ee/flex_data01.dbf' SIZE 500m
          SEGMENT SPACE MANAGEMENT AUTO;
  21. Create application roles if desired. Alternatively, you can use the default roles CONNECT, RESOURCE, and DBA.

  22. Create your application accounts that will own the application schemas. Set the default tablespace to one of your application tablespaces designated to hold tables. Assign quotas on all of the application tablespaces where the account will need to be able to create schema objects. (You can use the keyword UNLIMITED.) You should not set any quota on the SYSTEM, SYSAUX, or TEMP tablespaces. Do not plan to create any application objects in the SYS or SYSTEM schemas, or store any application objects in the SYSTEM, SYSAUX, or TEMP tablespaces. Here is a sample application account creation statement: 
          CREATE USER bob IDENTIFIED BY bob123
          DEFAULT TABLESPACE flex_data 
          QUOTA UNLIMITED ON flex_data;
  23. Grant roles and/or system privileges to the application accounts. Note that if you grant the RESOURCE role to an account, that account will also receive the UNLIMITED TABLESPACE system privilege. This will let the account create objects in any tablespace, regardless of quotas. Think very carefully before granting the DBA role or allowing any accounts th have the UNLIMITED TABLESPACE privilege. Sample statements to grant and revoke privileges are as follows: 
          GRANT connect, resource TO bob;
          REVOKE unlimited tablespace FROM bob;
  24. Review the overall security of your database. Oracle Corporation published a very good ten-page listing of security checks that you should perform against Oracle 9i database. This document does not appear to have been updated for Oracle Database 10g yet, but it still contains a lot of relevant material. Download it from the Oracle Technology Network at http://otn.oracle.com/deploy/security/oracle9i/pdf/9iR2_checklist.pdf. Another checklist, although not all of the recommendations seem appropriate, is available at http://www.sans.org/score/checklists/Oracle_Database_Checklist.pdf.
Complete the Server Configuration

These steps complete the configuration of your server for smooth Oracle operation. In this section we will change the oracle user’s login script to eliminate hardcoding, create individual operating system accounts for each database user, and configure the server to start the database and listeners automatically whenever the server is rebooted.

  1. Edit the login file (.profile or .bash_profile) for the oracle user to eliminate hardcodings and call the oraenv script to set the environment instead. The following will work with Bourne, Korn, or Bash shell: 
          # Settings for Oracle environment
          ORACLE_SID=dev101ee   # Put your instance name here
          ORAENV_ASK=NO
          export ORACLE_SID ORAENV_ASK
          . oraenv
    Note that this script assumes that the /usr/local/bin directory is on your path. Also, if you use C shell then you should edit .cshrc and have it source coraenv.

  2. Create separate Unix accounts for DBAs and database users who will log onto the database server directly. You should only log in as oracle when installing or patching software. The Unix accounts for DBAs should be members of the dba group, and other users should not be members of the dba group. Give each of these accounts a login file like oracle’s so that their environment initializes correctly when they log in.

  3. Edit the /var/opt/oracle/oratab file to verify that the entry for your database is correct. Lines starting with a pound sign are considered comments and are ignored. Each non-comment line contains the name of one Oracle instance, its Oracle home, and a Y or N. A Y indicates that the database should be started automatically on server reboot, and an N indicates that it should not. The three fields should be separated by colons. A sample /var/opt/oracle/oratab file looks like this: 
          #
          # /var/opt/oracle/oratab
          # ======================
          #
          dev101ee:/u01/app/oracle/product/10.1.0/db_1:Y
  4. To make the database and listeners start up automatically when the server reboots and shut down automatically when the server shuts down, you’ll need to create a dbora file in /etc/init.d and link it to /etc/rc2.d and /etc/rc0.d. You’ll need to do this as the root user. First create a file called dbora in /etc/init.d as follows: 
          #!/bin/sh
          ORA_HOME=/u01/app/oracle/product/10.1.0/db_1
          ORA_OWNER=oracle
          if [ ! -f $ORA_HOME/bin/dbstart ]
          then
            echo "Oracle startup: cannot start"
            exit
          fi
          case "$1" in
             'start') # Start the Oracle databases and listeners
                      su - $ORA_OWNER -c "$ORA_HOME/bin/dbstart"
                      su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl start"
                      su - $ORA_OWNER -c "$ORA_HOME/bin/emctl start dbconsole"
                      su - $ORA_OWNER -c "$ORA_HOME/bin/isqlplusctl start"
                      ;;
             'stop')  # Stop the Oracle databases and listeners
                      su - $ORA_OWNER -c "$ORA_HOME/bin/isqlplusctl stop"
                      su - $ORA_OWNER -c "$ORA_HOME/bin/emctl stop dbconsole"
                      su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl stop"
                      su - $ORA_OWNER -c "$ORA_HOME/bin/dbshut"
                      ;;
          esac
    After creating the dbora file, you need to link it to /etc/rc2.d and /etc/rc0.d: 
          ln -s /etc/init.d/dbora /etc/rc2.d/S99dbora
          ln -s /etc/init.d/dbora /etc/rc0.d/K10dbora
Conclusion

This paper walks you through the intricate details of getting Oracle Database 10g up and running on a database server running SPARC Solaris. It may look complicated, but that’s only because this paper goes down to a nitty-gritty level of detail.

Please keep in mind, though, that the requirements are different for every Oracle implementation. I am extremely confident that if you follow these steps to install Oracle Database 10g release 1 (Oracle version 10.1.0) on a server running SPARC Solaris 8, 9, or 10, the process will go very smoothly for you. However, no single document can address every specific hardware configuration and every set of business needs. Please use this paper as a starting point to get Oracle up and running in your shop. To get the best performance and scalability, each system needs to be considered individually.