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 | Arbitrary | See “Password file” below. | |
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 | ||
USER_DUMP_DEST | Local | ||
DIAGNOSTIC_DEST | Local | ||
Allocate each files as shown in the table when you create the database using the multitenant architecture.
Allocate the files of PDB on the shared disk.
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. Afterwards, the service might stop finally on both operating node and standby nodes, because the space of shared disk is insufficient and the failover of userApplication fails on the standby node.
Note that there is sufficient space in the disk of the directory specified by AUDIT_FILE_DEST for the database using the multitenant architecture. The log file in the AUDIT_FILE_DEST directory increases by about 1KB at monitoring interval of the Oracle instance resource(Default: 30 seconds) when the PDB is monitored. Capacity and frequency of the log file are different according to the environment. Check the capacity of the AUDIT_FILE_DEST directory, and backup/delete it regularly.
If you install Oracle database software on the shared disk, locate database files referring to "Appendix D Using Oracle Database Software on shared disks".
Information
Check if the Oracle user has privileges to write in a shared disk before creating the database.
If you use Oracle ASM, it is necessary to register the Oracle ASM as an RMS resource. See “2.4.2 Oracle ASM (Automatic Storage Management)”.
Create a database (Standby operation)
Operating node
Create a database on the operating node. The database must be accessible from the standby nodes.
Note
If multiple Oracle homes are configured on one server, a different Oracle instance name must be assigned for each Oracle home.
Information
Refer to the Oracle Database 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 Database 11g R1/11g R2/12c R1)
Under <$ORACLE_HOME>/network/admin
If the directories which are specified in the initialization parameters, AUDIT_FILE_DEST, BACKGROUND_DUMP_DEST, CORE_DUMP_DEST, USER_DUMP_DEST and DIAGNOSTIC_DEST, do not exist, create them.
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.
Information
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
Mutual standby / N:1 Standby operation
Create a database on an operating node. The database on the shared disk created on the operating node must be accessible from the standby nodes. This is the same as the other operating modes.
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 database 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 both the operating node and the standby 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), 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.4 userApplication with No Oracle Resources”.
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.
Password file
Allocate Password file on either a local disk or a shared disk. Decide which to allocate it to, refer to the following.
Local disk
When allocate Password file on a local disk, it is necessary to edit it of each node. Therefore, the maintenance efficiency decreases compared with the case allocated on a shared disk.
Shared disk
When allocate Password file on a shared disk, it only has to edit on a shared disk. Therefore, the maintenance efficiency improves compared with the case allocated on a local disk.
If you allocate Password file on a shared disk, create a Password file on the operating node and move it on a shared disk.
$ orapwd file=<$ORACLE_HOME>/dbs/orapw<SID> password=password force=y $ mv <$ORACLE_HOME>/dbs/orapw<SID> <shared disk>/orapw<SID>
Make a symbolic link file under the "$ORACLE_HOME/dbs" of all nodes.
$ ln -s <shared disk>/orapw<SID> <$ORACLE_HOME>/dbs/orapw<SID>
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, 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 = ora)
(ORACLE_HOME = /u01/app/oracle/product/db)
(SID_NAME = ora)
)
)Note
Operating system authentication (OS authentication) of Listener must be enabled.
OS authentication is enabled in default. If the following parameter is defined in listener.ora file, OS authentication is enabled.
LOCAL_OS_AUTHENTICATION_<LISTENER_NAME> = ON
If multiple Oracle homes are configured on one server, a different listener name must be assigned for each Oracle home.
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 = ora))
)SYSTEM user password
PRIMECLUSTER Wizard for Oracle accesses and monitors Oracle instances as the Oracle database 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.
Register the password of the SYSTEM user of the CDB when you create the database using the multitenant architecture. The password of Local User of the PDB need not be registered.
Define the full path of the log file
Define the full path of the alert log and the listener log in /opt/FJSVclora/etc/clgetoralog.conf. See the Note in “4.5 clgetoralog - Collect Troubleshooting Information" for details.
Check Oracle database operation
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. Check if you can start and stop the PDBs manually for the database using the multitenant architecture.
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> alter pluggable database all open; *For the database using the multitenant architecture. SQL> select name,open_mode from v$pdbs; *For the database using the multitenant architecture. SQL> shutdown immediate SQL> exit $ exit #
Measure time that the Oracle instance starts and stops. Measure time that all the PDBs starts for the database using the multitenant architecture. Measurements are used in "2.2.7.2 Oracle Resource Creation".
startup
alter pluggable database all open; *For the database using the multitenant architecture.
shutdown immediate
Note
The Oracle “TWO_TASK” environment variable must not be used.
It is used to add a connect identifier to connect to Oracle database then automatically connect to network. In PRIMECLUSTER Wizard for Oracle, network connection is not supported. Users are supposed to connect to Oracle instances 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 SQL*Plus system 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 instance is controlled through SQL*Plus in PRIMECLUSTER Wizard for Oracle.
It is available to setup the SQL*Plus system variables to login.sql by SET of SQL*Plus command.