|
In this chapter we look at some of the issues involved in installing the Oracle software and database. However, since Oracle runs on over 90 different platforms, we can only give an overview of the process involved here—the specifics for your
operating system can be found in the Oracle Installation and User's Guide manual which comes with the software. In addition, the last-minute System Release Bulletin that comes with the software should be studied, along with the even
later produced README.DOC file that is on the install media.
On most platforms, if a user process connects directly to the database server machine, two things must be known. One is the starting location of the Oracle software directory, and the other is the instance identifier to which the user process will
connect to. This information is provided in different ways on different operating systems, but many use an operating system command file named something such as "orauser" or "oraenv" to set up these operating system variables as soon as
a user logs into the machine.
During the installation process, on most machines, an option is given to install a default database by choosing some menu options. Chapter 11, "Managing the Database," covers how to create a database if you either don't want to or can not use
the menus to give you this starting database. Usually the menus are sufficient to create a practice database, but for production and real systems, more control is needed over the choices available when creating a new database.
Installation of the Oracle tools is usually done at the same time as installation of the Oracle software. For client/server environments, an added complication is that the tools exist on a different machine than that on which the database software
resides. To allow the two machines to communicate between each other, some networking software must be installed on both machines (such as TCP/IP), and on top of that both machines need a flavor of SQL*Net installed so that the Oracle software can
interface to the networking software. Installing SQL*Net software for the network protocol you're using is usually done at the same time as installing the Oracle server software and tools software.
This is one of the areas where there are major differences between different operating systems due to the nature of the process itself.
When you purchase the Oracle software, a number of additional software options are available. However, these options may not be available on all platforms at the same time (for example, at the time of this writing, the Distributed option was not yet
available on the Personal Oracle 7 version of the software).
The standard product (without the addition of the procedural, distributed, parallel, or other options) gives you the SQL language—without this not much can be done on the database. In the near future, the PL/SQL language is also to be included in
the standard, base product. In addition, the database only locks those rows which are actually being modified instead of locking out the entire table. (This was an option that had to be purchased separately in version 6 of the database server.)
The base product also includes the capability to do parallel recoveries in the case of media failure, which means that you can have more than one process running the recover tablespace command. All of these processes can run in parallel and will use
whichever archived and online redo log files are required for the tablespace being recovered. Parallel tablespace backup commands can also be issued, as well as parallel loads of data from operating system files using the SQL*Loader product with the direct
load path option, which is available with that product.
The procedural option gives the you ability to use PL/SQL and to create procedures, functions, packages, and database triggers. At the time of this writing, this was being bundled in as part of the base product, and so was not an additional option for
most platforms.
The base product itself gives you the ability to write distributed queries—queries which in the same transaction or even in the same statement, query tables on one or more databases, usually by using database links (which have already been defined
by the database administrator). In addition, the user can connect to a remote database and make changes to tables on that database.
However, one thing that is not possible without the distributed option is the capability to make changes to tables on more than one database within the same transaction (the same commit unit). The distributed option allows one transaction to make
changes to more than one database. When the changes are committed (or rolled back), the Oracle server software ensures that either all the databases commit, or if anything goes wrong, that they all rollback the work. This is provided without requiring the
developer to put in any more code than the normal commit or rollback statement.
The synchronization mechanism is provided using the 2-Phase Commit algorithm, which synchronizes all the databases involved.
In addition, with the distributed option, one non-Oracle database can take part in a distributed transaction. Usually this involves using the Oracle Gateway products which allow access to non-Oracle data sources.
If any failures do occur with a distributed transaction, the Oracle RECO background process periodically tries to either commit or to rollback the changes on the databases involved. It is better for the database administrator to allow the RECO process
to recover the distributed transaction without getting involved. The Oracle data dictionary tables, DBA_2PC_NEIGHBORS and DBA_2PC_PENDING, give further information on the transactions which have been involved in a distributed failure.
The distributed option is also required if you wish to create Snapshots which are copies of tables (usually) on other databases which are automatically replicated to your database at user defined intervals. In addition, the distributed option includes
the capability to call procedures, functions, and packages, which have been defined on remote databases. So, in theory though not very practically, you can hold the database procedures, functions, and packages on one central database, and all other
databases can make calls to this central copy of the code.
The Oracle parallel server option allows more than one instance to access the same set of database files. This option ensures, for example, that if a row is locked on one instance that it is reported as locked on any other instances accessing the same
database.
The parallel server option is be used where more than one processor is available (either in the same machine or in different machines which have been clustered together).
The parallel query option improves performance of full-table scans. This allows a large query to be executed by multiple processes so that many processes can be used to perform parts of the query, with the results being merged together automatically.
In addition, the parallel query option allows creation of indexes in parallel. This is similar in concept to the parallel query mentioned earlier, where more than one process can be used to build different parts of the index, and the results from each
of these processes is merged together.
The parallel query option normally runs on those machines where more than one processor has been installed so that you can use the processing power of more than one processor to perform the heavy-load work which you require.
Trusted Oracle provides additional security than what is available with the base product and is usually found either in military type applications or those where a high level of security is required. This gives, for example, the ability to control which
rows are accessible to which users. This is not easily done with the base product.
 Tip: Use the v$version view, which is accessible to the system user, to see which versions of the Oracle product you have installed. In addition, the v$compatseg view shows which version of the Oracle server
software introduced some of the new releases.
The actual process of installing the Oracle software and creating the first database is relatively easy on most platforms because you can follow the menu options; however, preparation before the actual install pays dividends in the long run.
One of the first things to consider is the amount of disk space required both for the software and for the database itself. In addition, the locations of the program files, database files, redo logs, and control files should be carefully considered so
that disk contention does not occur.
The amount of storage required for the software varies from platform to platform—the Oracle installation and User's Guide manual for your platform should be able to give you an idea for the amount of storage required.
The amount of memory required for Oracle will be split into the memory required for the Oracle software to load (much of which is re-entrant code that can be used at the same time by more than one process), the common memory areas (such as the SGA), and
the private memory areas (such as the PGA for each connection to the database), as well as memory for the client programs which are executing. Though, this may be on a different machine than the one on which the database server is being run.
The default memory allocations (especially for the common SGA area) is not sufficient for most databases.
In addition, some operating system specific issues need to be addressed (such as the number of semaphore sets in UNIX)—most of which will be detailed in the installation and user's guide manual.
Most platforms have a menu driven installation script or, even better, an installation program that makes the installation a one-stop point-and-click operation, such as the program for installing the Oracle software on the Microsoft Windows platform.
Because dependencies exist between different components of the Oracle software, the menu first prompts for the components of software to be installed and works out the dependencies between the different components so that all required components are
installed.
On some platforms, it may be necessary to create an operating system account with a high-level of privileges which will be used to install the software (usually called Oracle7).
The operations of connecting as internal, starting up the instance, shutting down the instance, and creating a database are all privileged operations. They can all be performed from within the SQL*DBA tool (or from the server manager tool if that is
available on your platform). As a result, your operating system account needs to have the necessary operating system privileges in order to perform these operations (UNIX groups on UNIX, or process rights on VMS, for example). The way that Oracle
determines whether these privileges are in effect is different from platform to platform.
At the time of this writing there is no check to ensure that you only install the products for which you are licensed, or that you do not exceed the number of users for which you've bought the license for.
Use the v$license view to determine whether you are exceeding the number of users for which you're licensed.
For those platforms where a hierarchical directory structure exists, the Oracle default home directory has a name such as "Oracle7," and below this you'll find many subdirectories—usually one for each product being installed. Within each
of these product subdirectories, further subdirectories exist for things such as the install scripts, demo files, and so on.
 The directory structure underneath the Oracle home directory should not be changed—Oracle needs to know where to find the different files for the software being installed.
For those platforms that support it, an operating system environment variable exists to define where the starting location is for the Oracle software ($ORACLE_HOME for UNIX, ORA_ROOT for VMS and the ORACLE.INI file for the MS Windows platform). Once
this environment variable exists, Oracle can work out the locations of the subdirectories and gain access to the files it requires.
It is also possible on some platforms to install many different versions of the Oracle software.
In this section, we highlight some points for three of the major platforms for Oracle.
In addition to an installation and user's guide manual being provided for your platform, there is also a generic UNIX technical reference guide which applies to all UNIX platforms on which Oracle can be run. This should be read in conjunction with the
installation and user's guide before starting the install.
The $ORACLE_HOME environment variable is used to locate the home directory for the Oracle software, and the $ORACLE_SID environment variable is used to determine which instance ID the user process will connect into.
The PATH environment variable should include the $ORACLE_HOME/bin directory so that you can access the various Oracle components.
One of the options available for the UNIX platform is to allow Oracle to use raw disk devices—essentially this means that the Oracle software can bypass the buffer manager for the disks and access the disk drives directly giving an increase in
performance. However, you should ensure that the necessary UNIX expertise is on-hand to manage raw disk devices—something that is not to be considered for those sites new to UNIX and new to Oracle.
The ORA_ROOT logical is used to point to the location of the home directory for the Oracle software. In addition, the ORA_SID symbol is used to determine the instance identifier of the instance to which user processes will connect.
This is nowadays one of the easiest platforms on which to install the Oracle tools and software.
The ORACLE.INI file is used to set the various parameters used by Oracle. The parameters ending with path control where the Oracle software on the PC attempts to find the Oracle software. The default location of the database server machine, the network
protocol used to connect that machine, and the instance identifier used when a connection is made to that machine, can be given by the LOCAL parameter in the INIT.ORA file.
In this chapter, you have seen an overview of some of the things to consider when installing the Oracle software. This is one of the areas where major differences exist between different platforms. As mentioned earlier, you
refer to the installation and user's guide manual for your platform to learn the specifics for your platform.
| 
