Release 2 (9.2) for Windows
Part Number A95490-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Database Getting Started Release 2 (9.2) for Windows Part Number A95490-01 |
|
This chapter describes multiple Oracle homes and Optimal Flexible Architecture for Oracle9i for Windows.
This chapter contains these topics:
When you install an Oracle database, you are installing one of the largest applications that your computer can support. Using multiple Oracle homes and OFA provides many advantages when administering large databases. The following advantages are most important:
This section includes the following topics:
|
Note: All Oracle7 products and all Oracle8 release 8.0.3 products are non-multiple Oracle home products. Oracle9i Database Installation Guide for Windows has a list of products supporting single or multiple Oracle homes. |
An Oracle home corresponds to the environment in which Oracle products run. This environment includes the following:
C:\orant or C:\oracle\ora92)PATH variable pointing to binary files of installed productsOracle homes also have a name associated with them, which you specify along with their location during installation.
The main benefit of using multiple Oracle homes is that you can run multiple releases of the same products concurrently. For example, you can test an Oracle9i release 2 (9.2) database patch before you run your production database Oracle9i release 2 (9.2) against it.
Modifications to multiple Oracle home functionality have occurred since it was introduced in Oracle8 release 8.0.4. This section helps you determine capabilities of your Oracle home depending on the release you are using.
Releases of Oracle for Windows NT prior to Oracle8 release 8.0.4 support only single Oracle homes, allowing you to install and run Oracle products in a single Oracle home. Different releases of Oracle products can be installed in the same Oracle home provided they have different first or second-digit release numbers. For example, you can install Oracle7 release 7.2 products and Oracle7 release 7.3 products or Oracle7 release 7.x and Oracle8 release 8.x products in the same Oracle home. However, you cannot install multiple third-digit releases of the same products. For example, you cannot install Oracle7 release 7.3.2 and Oracle7 release 7.3.3 products on the same computer; one installation will overwrite the other.
You can install one or more releases of Oracle products in multiple Oracle homes. For example, with multiple Oracle homes, you can install Oracle8 release 8.0.x and Oracle8i release 8.1.3 products or Oracle7 release 7.x and Oracle8 release 8.0.x products in different Oracle homes on the same computer.
You can also install different releases of Oracle products in the same Oracle home provided they have different first or second-digit release numbers. For example, you can install Oracle7 release 7.2 products and Oracle8 release 8.0.x products in the same Oracle home.
These releases have the same multiple Oracle home functionality as Oracle8 releases 8.0.4 to 8.0.6, but the following restrictions apply:
You can use an Oracle9i release 2 (9.2) listener to spawn a connection to a database from Oracle9i release 2 (9.2), Oracle8i release 8.1.x, Oracle8 release 8.0.x, or Oracle7 release 7.3.x. Some restrictions apply, however, in using Oracle9i release 2 (9.2) listeners with earlier releases of the database:
You can use one listener for spawning connections to databases for multiple Oracle homes. Simply add each system identifier to the SID_LIST section in the ORACLE_BASE\ORACLE_HOME\network\admin\listener.ora file.
Because the SID is unique to a system across different Oracle homes, the listener can spawn the database thread for a specific SID in the correct Oracle home, and the ORACLE_HOME parameter (used in UNIX environments only) is not needed in the listener.ora file.
|
Note: There may be multiple |
This section describes differences among multiple Oracle home environments since they were first introduced in Oracle8 release 8.0.4.
If you have Oracle8 release 8.0.4 or later 8.0.x Oracle homes on your computer, then note differences in Table 6-1 between the first Oracle home you installed and more recent Oracle homes you may install.
| Element | First Oracle Home | Each Additional Oracle Home |
|---|---|---|
|
Service Names |
OracleTNSListener80 |
Oracle home name included in service names. |
|
Program Groups |
Oracle for Windows NT |
Oracle for Windows - HOME_NAME Oracle home name appended to the program group. |
|
Registry Entries |
Located in |
Subkeys for each Oracle home are added under |
|
System Identifier (SID) name for starter database |
Automatically named |
Only the first starter database on your computer is called |
Oracle8i release 8.1.3, 8.1.4, and 8.1.5 Oracle homes are slightly different from Oracle homes before Oracle8i release 8.1.3. Table 6-2 displays those differences.
| Element | First Oracle Home | Each Additional Oracle Home |
|---|---|---|
|
Service Names |
OracleHOME_NAMETNSListener |
OracleHOME_NAMETNSListener |
|
Program Groups |
Oracle - HOME_NAME |
Oracle - HOME_NAME |
|
Registry Entries |
Located in |
Subkeys for each Oracle home are added in |
|
System Identifier (SID)Foot 1 name and |
Automatically named ORCL for Oracle8i releases 8.1.3 and 8.1.4. |
For Oracle8i releases 8.1.3 and 8.1.4, the second database you create on your computer has a SID of |
Unless you specify otherwise at installation time, the Oracle home in which you installed products most recently is the first directory listed in your PATH (primary home). As such, it has priority over the other Oracle home entries in your PATH.
If you start a product from the command prompt, then the release of the product started is the one in the Oracle home listed first in your PATH, unless you specifically start a different release of the product by one of the following methods:
PATH so that the first entry points to binary files for the product release you want to useYou can change the value of PATH by using one of the following methods:
You can assign a new value at the system level. The new value exists until you change the value of PATH again.
You can assign a new value at the command prompt. The new value reverts to its previous value when you quit the session.
Oracle Home Selector is a graphical user interface tool that enables you to edit your environment path to make an appropriate Oracle home directory your primary home. This tool can be used only when you have multiple, active Oracle home directories on a single computer.
The Oracle Home Selector window appears.
The Control Panel window appears.
The System Properties window appears.
The system variables appear.
PATH in the Value field and choose Set.In some cases on Windows 98, Oracle Home Selector fails to switch entries in the PATH environment variable as desired. This occurs where the PATH is defined in multiple places in the file autoexec.bat.
For example, if the following lines exist in autoexec.bat:
PATH C:\windows PATH D:\oracle\ora817;D:\oracle\ora816;%PATH%
then an attempt to switch the order of D:\oracle\ora817 with D:\oracle\ora816 in the PATH using Oracle Home Selector fails.
To work around this limitation, modify autoexec.bat so that the PATH is defined in one location in the file. Using the previous example, modify autoexec.bat to read:
PATH D:\oracle\ora817;D:\oracle\ora816;C:\windows
If you then attempt to use Oracle Home Selector to switch the order of Oracle homes in the PATH, it will succeed.
At the command prompt, enter:
C:\> set PATH=PATHNAME;%PATH%
where PATHNAME is the full path to binary files for the products you want to use. This change is valid for the current session only. If you want to change the value of your PATH permanently, then use Oracle Home Selector or change the value of PATH at the system level. Both methods are described earlier in this section.
If you have to exit Oracle Universal Installer unexpectedly after you have entered the name and path for an Oracle home (for example, because there is no more disk space in the path you specified), then you cannot specify a different path until you delete the HOMEID key and the IDx key corresponding to that Oracle home from the registry. To do this:
ORACLE_HOME_NAME for each HOMEID subkey in key HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE until you find the value that matches the name of the Oracle home you must delete.HOMEID you just located.IDx subkey in key HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\ALL_HOMES, where x has the same value as ID in HOMEID. For example, if subkey HOMEID for the home name you want to delete is HOME1, then the appropriate IDx subkey is ID1.
| See Also:
Chapter 9, "Configuration Parameters and the Registry" for more information on registry keys and subkeys |
Variables set in the environment always override the value of equivalent variables set in the registry. The following section describes consequences of setting two of the most commonly-used environment variables, ORACLE_HOME and TNS_ADMIN.
Oracle Corporation recommends that you never set the ORACLE_HOME environment variable, because it is not required for Oracle products to function properly. If you set the ORACLE_HOME environment variable, then Oracle Universal Installer will unset it for you. Oracle products find the value of ORACLE_HOME at the location specified by the ORACLE_BASE\ORACLE_HOME\bin\oracle.key file. If you must set ORACLE_HOME in the environment for another reason, then you must take care to run software only from that Oracle home when the variable is set.
When you run an Oracle application from the command prompt, the first executable by that name found in the directory path runs. For example, C:\> sqlplus. Alternately, if you specify a full directory path, then the specified application runs. For example, C:\oracle\ora82> sqlplus.
If you modify the value of PATH using any of the four methods described in the previous section, then you can choose which release of an application is run from the command prompt. In sum, modifying the value of PATH indicates from which Oracle home to run executables at the command prompt, when no full directory path is specified.
Once an Oracle application starts, it looks for all environment variables first in the current environment and second in the registry key for the Oracle home from which the application is running.
The application knows where it is running from by calling Windows to obtain the executable's path name and then parsing the path name to get the directory from which it is running. In the ORACLE_BASE\ORACLE_HOME\bin directory where the executable resides, there is a file called oracle.key. This file specifies where in the registry to look for variables when applications from that particular Oracle home are run.
For example, if you run C:\oracle\ora82\bin\sqlplus.exe, then sqlplus.exe looks in C:\oracle\ora82\bin\oracle.key to find out where to look for its registry variables. If the oracle.key file does not exist (for version 7 and some version 8 Oracle homes), then Oracle uses HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE to locate the registry variables.
In a typical case, there are no Oracle variables (that is, ORACLE_HOME) set in the environment. Any applications run from an Oracle8 release 8.0.5 or later Oracle home look in the oracle.key file in that Oracle home and find their variables (including ORACLE_HOME) in the correct registry key. Likewise for Oracle9i release 2 (9.2), the Oracle home that gets priority depends on the PATH, but regardless of the PATH setting, all software works correctly.
If you set ORACLE_HOME in the environment, then software run from another Oracle home will not work reliably. Conflict occurs when you set ORACLE_HOME to point to one Oracle home directory, then attempt to run applications from a second Oracle home. These applications first check for any environment variable settings (such as ORACLE_HOME), before checking the registry through the oracle.key file. Because ORACLE_HOME is set, the applications in the second Oracle home attempt to use files in the first Oracle home, causing a conflict.
For example, suppose you have Oracle8 release 8.0.5 installed in C:\orant and Oracle9i release 2 (9.2) installed in C:\oracle\ora92. Suppose further that ORACLE_HOME is set to C:\orant in the environment. If you run an application from C:\oracle\ora92\bin, then that application first looks in the environment for all variables before looking at its oracle.key file. So an application run from your Oracle9i release 2 (9.2) Oracle home runs with ORACLE_HOME=C:\orant. Therefore, anything that the application uses ORACLE_HOME for will be looked for in C:\orant, where it may not exist. Examples include message files (*.msb), SQL scripts (.sql), and any other files opened by the application and based off ORACLE_HOME.
Note that the same behavior occurs on UNIX. If you run an application from Oracle home number 1 with ORACLE_HOME=OracleHome number 2 in the environment, then the same behavior can be observed.
Oracle software looks for TNS_ADMIN in one location in the registry (depending upon the type of Oracle home installed). If you installed software into the default Oracle home, then any software running from that Oracle home will look in HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE. If you installed a new-style (8.0.4 or later) multiple Oracle home, then the Oracle software looks in HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEID. (Key ALL_HOMES is used by the installer and plays no role when translating variables.)
The environment always overrides the registry, so if TNS_ADMIN is set in the environment, then that takes precedence over the TNS_ADMIN setting in the registry. No variables should be set in the environment by Oracle Home Selector except for PATH.
Oracle Optimal Flexible Architecture (OFA) is a set of file naming and placement guidelines for Oracle software and databases. It can also be thought of as a set of good habits to adopt when organizing Oracle directories and files on your computer. All Oracle products on CD-ROM are OFA-compliant; that is, Oracle Universal Installer places Oracle products in directory locations that follow OFA guidelines. Although using OFA is not a requirement, Oracle Corporation recommends that you use it if your database will grow in size, or if you plan to have multiple databases.
The aim of OFA is to prevent an entire class of problems that can occur when you have different releases of Oracle software and multiple, growing databases on your computer. OFA is designed to provide significant benefits:
For example, Oracle Universal Installer now separates Oracle software executables from database files. Previously, database files were placed in ORACLE_HOME\database, a subdirectory of the Oracle home directory that also contained Oracle software.
Using OFA, Oracle Universal Installer puts Oracle software in ORACLE_BASE\ORACLE_HOME and database files in ORACLE_BASE\oradata. Now when you upgrade a database to the latest release, the new Oracle software executables will be placed in a different Oracle home directory. After you judge the upgrade successful, you can easily remove the old Oracle home directory and reclaim space, because the database does not reside there.
An OFA-compliant database has the following benefits:
File system organization simplifies locating specific database files and adding database files as the database grows.
Disk contention decreases, because Oracle administration files, binary files, and datafiles that used to be on one disk can now reside in separate directories on separate disks.
By spreading files across more than one disk, disk failures impact as little data as possible.
Multiple releases of application software can run simultaneously, enabling testing and use of a new release of an application before abandoning the previous release. Transferring to a new release after an upgrade is simple for the database administrator and transparent for the user.
An OFA-compliant database has the following characteristics:
Categories of files are separated into independent subdirectories so that files in one category are minimally affected by operations on files in other categories.
Database files are easily distinguishable from all other files. Files of one database are easily distinguishable from files of another database. Datafiles, redo log files, and control files are easily identifiable. Datafiles are clearly associated with a particular tablespace.
You can add, move, or delete Oracle home directories without having to revise applications that refer to them.
The ability to distinguish administrative information about one database from that of another ensures a reasonable structure for the organization and storage of administrative data.
Tablespace free space fragmentation and I/O request contention are minimized, while administrative flexibility is maximized.
I/O loads are tuned across all disks, including disks storing Oracle data in raw devices, if needed.
OFA has necessitated changes to the Oracle database directory tree. This section lists the differences.
When you install an Oracle8i release 8.1.3 or earlier release, all subdirectories are located under a top-level ORACLE_HOME directory that by default is C:\orant.
When you install an Oracle8i release 8.1.4 or later OFA-compliant database, all subdirectories are no longer under a top-level ORACLE_HOME directory. There is now a new top-level directory called ORACLE_BASE of form X:\oracle, where X is any hard drive. If you install an OFA-compliant database using Oracle Universal Installer defaults, then ORACLE_BASE is C:\oracle.
ORACLE_BASE contains \ORACLE_HOME directories, \oradata directories (for database files), and \admin directories (for database administration files).
In Oracle8i release 8.1.3 and earlier releases, database files have the SID in the database filename. For example, the first control file is named ctl1SID.ora.
Beginning with Oracle8i release 8.1.4, database files no longer have the SID in the database filename. For example, the first control file is named control01.ctl. There is no need for the presence of the SID in the filename, because all the database files for a particular database are placed in \oradata under a directory called DB_NAME that is named for that database.
In Oracle8i release 8.1.3 and earlier releases, all database files have the same .ORA extension.
In an OFA-compliant release, the convention of having .ora as the filename extension for database files is no longer used. Database filenames now have more meaningful extensions. These are:
OFA uses directory naming conventions that make it easy to identify the precise Oracle home and database name that is associated with a set of files. This section describes the naming conventions used for top-level directories of an OFA-compliant database directory tree:
ORACLE_BASE is the root of the Oracle directory tree. If you install an OFA-compliant database using Oracle Universal Installer defaults, then ORACLE_BASE is X:\oracle where X is any hard drive. For example, C:\oracle.
If you are installing Oracle9i for Windows on a computer with no other Oracle software installed, then you can change ORACLE_BASE before running Oracle Universal Installer. Most users will not need or want to do this.
Do not change the value of ORACLE_BASE after you run Oracle Universal Installer for the first time. If there is an existing ORACLE_BASE and you change it, then there will be a conflict of Oracle base directories. If you create another ORACLE_BASE when the original ORACLE_BASE already exists, then certain tools and the database will not be able to find previously created files. They will look for them in the new ORACLE_BASE instead of the original ORACLE_BASE.
The Control Panel window appears.
The System Properties window appears.
The System Variables appear.
ORACLE_BASE.ORACLE_BASE in the Value text box, then click OK to exit.autoexec.bat file, using a text editor.ORACLE_BASE statement.\ORACLE_HOME directory is located beneath X:\ORACLE_BASE and contains subdirectories for Oracle software executables and network files.
If you install Oracle9i for Windows on a computer with no other Oracle software installed and you use default settings, then the first Oracle home directory that you create is called \ora92.
Database administration files are stored in subdirectories of ORACLE_BASE \admin\DB_NAME. Names and brief descriptions of some of these subdirectories are:
\bdump --background process trace files \cdump --core dump files \create --database creation files \exp --database export files \pfile --initialization parameter files \udump --user SQL trace files
Database files are stored in ORACLE_BASE\ORADATA\DB_NAME. Names and brief descriptions of these files are:
control01.ctl --control file 1 control02.ctl --control file 2 control02.ctl --control file 3 oemrep03.dbf --Oracle Enterprise Manager repository tablespace datafile system01.dbf --SYSTEM tablespace datafile rbs01.dbf --RBS tablespace datafile indx01.dbf --INDX tablespace datafile temp01.dbf --TEMP tablespace datafile users01.dbf --USERS tablespace datafile redo01.log --redo log file group one, member one redo02.log --redo log file group two, member one redo03.log --redo log file group three, member one
|
Note: This directory structure allows for disk striping only on UNIX platforms. See "Support for Symbolic Links on Windows NT". |
DB_NAME is the unique name for a particular database and has the same value as parameter DB_NAME in the initialization parameter file (init.ora). When you create a database, DB_NAME can be no more than eight characters long and can contain only the following characters:
The following sections describe various OFA and multiple Oracle homes configurations.
To install an OFA-compliant database, you must specify an Oracle home directory in the Path: field of Oracle Universal Installer. It is of the form:
X:\[PATHNAME]\oracle\HOME_NAME
where:
X:\ is any hard drive. For example, C:\[PATHNAME] is an optional directory path name\oracle is a mandatory directory path name, unless you changed the value of registry key ORACLE_BASE before performing the installationHOME_NAME is the name of the Oracle homeThe following are examples of OFA-compliant Oracle home directories:
C:\oracle\ora81) in the path: field.C:\oracle\ora92) in the path: field.Table 6-3 shows the default OFA database settings.
| Setting | Value |
|---|---|
|
|
|
|
Oracle home 1 |
|
|
Oracle home 2 |
|
C:\oracle\ora81 in the path: field to X:\xyz.C:\oracle\ora92 in the path: field to Y:\abc.Table 6-4 shows the nondefault OFA database settings for example 1.
| Setting | Value |
|---|---|
|
|
|
|
Oracle home 1 |
|
|
Oracle home 2 |
|
The resulting directory tree would look similar to this:
X:\xyz \admin \DB_NAME1 \DB_NAME2 \bin \network \oradata \DB_NAME1 control01.ctl control02.ctl control03.ctl indx01.dbf rbs01.dbf system01.dbf temp01.dbf users01.dbf redo01.log redo02.log redo03.log \DB_NAME2 Y:abc \admin \DB_NAME1 \DB_NAME2 \bin \network \oradata \DB_NAME1 control01.ctl control02.ctl control03.ctl indx01.dbf rbs01.dbf system01.dbf temp01.dbf users01.dbf redo01.log redo02.log redo03.log \DB_NAME2
C:\oracle\ora81 in the path: field to X:\xyz\oracle\abc.C:\oracle\ora92 to X:\pqr.Table 6-5 shows the nondefault OFA database settings for example 2.
| Setting | Value |
|---|---|
|
|
(same for both Oracle homes) |
|
Oracle home 1 |
|
|
Oracle home 2 |
|
The resulting directory tree would look similar to this:
X:\pqr --Oracle home 2 \bin \network X:\xyz \oracle --ORACLE_BASE for both Oracle homes \abc --Oracle home 1 \bin \network \admin \db_name1 \adhoc \bdump \cdump \create \exp \pfile \udump \DB_NAME2 \... \oradata \DB_NAME1 control01.ctl control02.ctl control03.ctl indx01.dbf rbs01.dbf system01.dbf temp01.dbf users01.dbf redo01.log redo02.log redo03.log \DB_NAME2
One of the basic goals of OFA is to increase reliability and performance by distributing I/O loads across different physical drives. Two ways to do that are:
Oracle log files and database files can be separated and treated with different levels of hardware reliability. Oracle log files are highly reliable to start with, because they are stored redundantly. Creating similar reliability for database files may require you to duplicate all of your data, using disk mirrors.
Disk mirroring usually involves two or more identical drives and either a hardware controller or Windows Disk Administrator. If one disk fails, then the other disk(s) can be used to recover data that would otherwise be lost. Using one of the disks to recover lost data may involve "breaking" the mirror. If the mirror breaks, then you must build a new mirror.
Disk mirroring is part of some levels of Redundant Array of Independent Disks (RAID) configurations, provided by the disk controller. The RAID level determines the amount of redundancy. Some RAID levels can use the "hot swapping" feature, which means that you can replace a bad disk with a good one without turning off the computer or losing functionality.
How you set up disks for use in a database depends on the number of disks and the type of hard disk controllers available. If the hard disk controllers support both striping and mirroring, then Oracle Corporation recommends you configure the controllers to support striping.
Some controllers are configured at system startup time by issuing a keyboard sequence that brings up configuration programs written by the controller manufacturer. One goal is to stripe as many drives together as possible by configuring the controllers. Each stripe shows up as one logical device.
Striping provides significant performance advantages. All the space from the striped drives appears as a single logical drive. Furthermore, the space is used by interlacing "stripes" of space from all of the disks in the stripe. This means that a large file uses some space from the first disk, then some from the second disk and so on to the last disk and then starting back at the first disk again. Each file can be spread over all of the striped disks. Data in such a file may be accessed randomly by more than one CPU without contention.
Controllers that support striping usually provide caching as well. This means that data can be written to the controller and cached and saved for a time in storage not on the disk. Data that is read can be cached on the controller in a similar fashion. Read caching is not necessary for Oracle databases, because all database reads are cached already in the System Global Area. The value of the DB_BLOCK_BUFFERS parameter in the initialization parameter file (init.ora) determines the number of buffers that can be used in the SGA. This value also configures Oracle9i database on startup.
A raw partition is a portion of a physical disk that is accessed at the lowest possible level. I/O of a raw partition improves performance by approximately 5% to 10% compared to I/O of a partition containing a file system. Therefore, Oracle Corporation encourages you to use raw partitions for your tablespace files.
You implement OFA on Windows NT and UNIX in the same way. However, differences exist with regard to the following:
Top-level names of the OFA directory tree differ between Windows NT and UNIX. However, main subdirectory and filenames are the same on both operating systems.
On Windows, ORACLE_BASE is associated with an Oracle home directory. ORACLE_BASE is defined in the registry (for example, in HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0).
On UNIX, ORACLE_BASE is associated with a UNIX user's environment.
The goal of OFA is to place all Oracle software under one ORACLE_BASE directory and to spread files across different physical drives as your databases increase in size.
On UNIX, although everything seems to be in one directory on the same hard drive, files can be on different hard drives if they are symbolically linked or have that directory as a mount point.
Windows NT currently does not support symbolic links, so datafiles will not all show up under a single directory like on UNIX. Instead, you may have oradata directories on multiple drives, with datafiles in each one. In this way, you still get OFA benefits, even though datafiles are not all visible in a single directory.
Oracle Corporation recommends that you use one logical drive to store your database administration files and that you place other files, as needed, on other logical drives in an oradata\DB_NAME directory.
In the following example, there are four logical drives for a database named prod:
C:\ contains an Oracle home and database administration files.F:\ contains redo log files. (F:\ drive could also represent two physical drives that have been striped to increase performance.)G:\ contains one of the control files and all tablespace files. (G:\ drive could also use a RAID Level-5 configuration to increase reliability.)H:\ contains the second control file.The directory structure would look similar to this:
C:\oracle --First logical drive \ora92 --Oracle home \bin --Subtree for Oracle binaries \network --Subtree for Oracle Net \... \admin --Subtree for database administration files \prod --Subtree for prod database administration files \adhoc --Ad hoc SQL scripts \adump --Audit files \bdump --Background process trace files \cdump --Core dump files \create --Database creation files \exp --Database export files \pfile --Initialization parameter file \udump --User SQL trace files F:\oracle --Second logical drive (two physical drives, striped) \oradata --Subtree for Oracle database files \prod --Subtree for prod database files redo01.log --Redo log file group one, member one redo02.log --Redo log file group two, member one redo03.log --Redo log file group three, member one G:\oracle --Third logical drive (RAID level 5 configuration) \oradata --Subtree for Oracle database files \prod --Subtree for prod database files control01.ctl --Control file 1 indx01.dbf --Index tablespace datafile rbs01.dbf --Rollback tablespace datafile system01.dbf --System tablespace datafile temp01.dbf --Temporary tablespace datafile users01.dbf --Users tablespace datafile H:\oracle --Fourth logical drive \oradata --Subtree for Oracle database files \prod --Subtree for prod database files control02.ctl --Control file 2
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|