Create the database. Make sure that you can successfully start the database on all nodes after creation.
Create and set the database.
Allocate a database
Create a database on the shared disk. The shared disk must be activated.
The files are allocated as follows:
Files | Locations | Note | |
Initialization parameter file (PFILE) | Arbitrary | Recommend to allocate on a local disk of each node | |
Server parameter file (SPFILE) | Share | See “Parameter file” below. | |
Password file | Share | - | |
Control files | Share | - | |
Data files | Share | - | |
Redo log files | Share | - | |
Archived redo log files | Arbitrary | Recommend to be multiplexed, allocating on a shared disk and a local disk. | |
Flash Recovery Area | Share | - | |
log files | audit_file_dest | Local | To be gathered surely for trouble investigation, allocate them on a local disk of each node. |
background_dump_dest | Local | ||
core_dump_dest | Local | ||
diagnostic_dest | Local | ||
user_dump_dest | Local | ||
Note
Note that there is sufficient space to archive for archived redo log files if they are located on shared disks. If there is insufficient space, and data updating processing through monitoring SQL hangs, an oracle resource might fail. Moreover, userApplication failover will fail and operating of Oracle database will completely stop.
Information
Check if the Oracle user has privileges to write in a shared disk before creating the database.
If you use ASM (Automatic Storage Management) for Oracle 10g or later, it is necessary to register the ASM as an RMS resource. See “2.5.2 ASM (Automatic Storage Management)”.
Create a database (Scalable operation with Oracle9i RAC)
Create a database on any one of the nodes. The database must be accessible from the standby nodes.
See
Refer to the Oracle RAC manual.
Create a database (Standby operation)
Operation node
Create a database on the operating node. The database must be accessible from the standby nodes.
See
Refer to the Oracle manual.
Standby node
Set up the standby nodes in the same configuration (directory creation, file copy, and links) as the operating node.
Under <$ORACLE_HOME>/dbs
Under <$ORACLE_BASE>/admin/<$ORACLE_SID>
Under <$ORACLE_BASE>/diag (Oracle 11g)
Under <$ORACLE_HOME>/network/admin
The access privilege to the directories and files must be also the same as that on the operating node.
If you set where archived redo log is output on the operating node, it is necessary to set the same on the standby nodes.
See
The required files on the operating node can be backed up in the tar format with the “cloracpy” command. See “4.4 cloracpy - Create Backup File for Oracle Database Setup”.
Example
In Mutual standby, N:1 standby and other Standby operation, create a database on the operating node. The database must be accessible from the standby nodes.
Mutual standby
2:1 standby
Parameter file
The initialization parameter setting of LOCAL_LISTENER must be compatible with that of listener.ora and tnsnames.ora. You should also pay close attention to set up Oracle network.
If you use server parameter file, allocate it on a shared disk. If it is not allocated on the shared disk, the settings will be inconsistent between operating and standby nodes.
After you allocate server parameter file on a shared disk, configure the settings in an operating and a standby both nodes for referring the server parameter file.
Example
Method of making a symbolic link file to the server parameter file
$ ln -s <the mount point of a shared disk>/spfile<$ORACLE_SID>.ora <$ORACLE_HOME>/dbs/spfile<$ORACLE_SID>.ora
Method to write the path of the server parameter file in initialization parameter file
(initialization parameter file: $ORACLE_HOME>/dbs/init<$ORACLE_SID>.ora)
spfile = <the mount point of a shared disk>/spfile<$ORACLE_SID>.ora
Note
If you create a database using DBCA (Database Configuration Assistant) in the Oracle 10g or later environment, you might not be able to specify where the server parameter file is stored. If this occurs, move the server parameter file to the shared disk after creating the database as follows:
Mount the shared disk if it is not mounted. Start userApplication that is created at “2.2.3 userApplication Creation”.
Move the server parameter file to the shared disk.
#mv <$ORACLE_HOME>/dbs/spfile<$ORACLE_SID>.ora <shared disk>/spfile<$ORACLE_SID>.ora
Configure the settings for referring the server parameter file. (see Example above)
Execute step 3 on both of the operating node and standby nodes.
You can also use the cloracpy command to execute it on the standby nodes after the operating node.
Network setup
The files are allocated as follows:
Files | Locations | Note |
listener.ora | Arbitrary | For placement of the file, refer to the below "information". |
tnsnames.ora | Arbitrary | Same as above |
<LISTENER>.log | Local |
|
Information
Allocate listener.ora file and tnsnames.ora file on either a local disk or a shared disk. To which allocate them, refer to the following.
Local disk
When allocate those files on a local disk, it is necessary to edit them of each node. Therefore, the maintenance efficiency decreases compared with the case allocated on a shared disk. In one side, it is possible to gather the files surely when the trouble is investigated because the influence of the state of the mount of a shared disk is not received.
Shared disk
When allocate those files on a shared disk, it only has to edit them on a shared disk. Therefore, the maintenance efficiency improves compared with the case allocated on a local disk. In one side, when the mount is not done, a shared disk might not be able to gather the necessary files for the trouble is investigated.
When allocate those files on a shared disk, make a symbolic link file under the “$ORACLE_HOME/network/admin/” of each node.
In the case of listener.ora
$ ln -s <the mount point of a shared disk>/listener.ora <$ORACLE_HOME>/network/admin/listener.ora
In the case of tnsnames.ora
$ ln -s <the mount point of a shared disk>/tnsnames.ora <$ORACLE_HOME>/network/admin/tnsnames.ora
listener.ora
If you use Oracle listener switching operation using a logical IP address for standby operation, specify the logical IP address for the IP address of the Oracle listener.
Example
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <logical IP address>)(PORT = 1521))
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ora9i)
(ORACLE_HOME = /opt/oracle/product/9.0.1)
(SID_NAME = ora9i)
)
)Note
In Oracle 10g or later environment, operating system authentication (OS authentication) of Listener must be enabled. There are two methods to enable it:
Not define the “LOCAL_OS_AUTHENTICATION_<LISTENER_NAME>” parameter in listener.ora file. (default)
If the parameter is defined, its value should be “ON”.
LOCAL_OS_AUTHENTICATION_<LISTENER_NAME> = ON
tnsnames.ora
If the Oracle listener is monitored through tnsping, set up the “tnsnames.ora” file. Then, specify the network service name set for tnsnames.ora in the environment setting of the Oracle listener of PRIMECLUSTER Wizard for Oracle. In that case, ORACLE_SID, host (logical IP address), and port number must be the same as those of the Oracle listener.
Example
Network service name =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <logical IP address>)(PORT = 1521))
(CONNECT_DATA = (SID = ora9i))
)SYSTEM user password
PRIMECLUSTER Wizard for Oracle accesses and monitors Oracle as the Oracle SYSTEM user. Therefore, the SYSTEM user's password must be registered in PRIMECLUSTER Wizard for Oracle. See “4.3 clorapass - Register Password for Monitoring” to register the password.
Note
The Oracle “TWO_TASK” environment variable must not be changed.
It is used to add a connect identifier to connect to Oracle then automatically connect to network. In PRIMECLUSTER Wizard for Oracle, network connection is not supported. Users are supposed to connect to Oracle in local connection (“ / as sysdba”). If network connection is required, specify “@connect identifier” instead of using the “TWO_TASK” environment variable when connecting at the connecting.
The processes other than definition of system environment variables must not be added to login.sql of Oracle DBA users.
SQL can be described in the SQL*Plus profile login.sql. However, it might automatically be executed and affect ongoing operations because Oracle is controlled through SQL*Plus in PRIMECLUSTER Wizard for Oracle.
It is available to setup the system environment variables to login.sql by SET command.
Start the database on all nodes and ensure that no errors occur.
PRIMECLUSTER Wizard for Oracle starts and stops the Oracle instance and Oracle listener after changing from the root user to the Oracle user by using su(1M).
Check if you can start and stop the Oracle instance and Oracle listener manually after changing from the root user to the Oracle user by using su(1M) in both the operating node and the standby nodes. Also, do not go through any users other than the root and Oracle users before logging in as the root user.
When you check on the standby nodes, switch userApplication to the standby nodes.
# su - <Oracle user> $ lsnrctl start <ListenerName> $ lsnrctl status <ListenerName> $ lsnrctl stop <ListenerName> $ sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> STARTUP SQL> SELECT STATUS FROM V$INSTANCE; SQL> SHUTDOWN IMMEDIATE SQL> EXIT $ exit #
Information
If the Oracle user's shell limits are not set properly, the Oracle instance and Oracle listener may fail to start.
PRIMECLUSTER Wizard for Oracle starts the Oracle instance and Oracle listener after changing from the root user to the Oracle user by using su(1M). If the Oracle user's shell limits are not set, the root user's shell limits are inherited. Therefore, make sure that you can start the Oracle instance and Oracle listener after changing from the root user to the Oracle user.