Posts Tagged ‘Operating system’

Checking the Network Setup with CVU
To verify node connectivity among all nodes in your cluster use following syntax as an oracle user,
/mount_point/crs/Disk1/cluvfy/runcluvfy.sh comp nodecon -n node_list [-verbose]

If you have two nodes node1 and node2 and your mountpoint is /dev/cdrom then enter following command.
/dev/cdrom/crs/Disk1/cluvfy/runcluvfy.sh comp nodecon -n node1,node2 -verbose

Checking the Hardware and Operating System Setup with CV
As an oracle user use the following command syntax to start Cluster Verification Utility (CVU) stage verification to check hardware and OS setup:

/mountpoint/crs/Disk1/cluvfy/runcluvfy.sh stage –post hwos –n node_list [-verbose]
If you have two nodes node1 and node2 and your mountpoint is /dev/cdrom then enter following command,
/dev/cdrom/crs/Disk1/cluvfy/runcluvfy.sh stage –post hwos –n node1,node2

Checking the Operating System Requirements Setup with CVU
To check if your system meets the operating system requirement pre-installation tasks use the following syntax,
/mountpoint/crs/Disk1/cluvfy/runcluvfy.sh comp sys -n node_list -p {crs|database}
-osdba osdba_group -orainv orainv_group -verbose

If you have two nodes node1 and node2 and your mountpoint is /dev/cdrom with the OSDBA dba and Oracle inventory group oinstall then enter following command,
/dev/cdrom/crs/Disk1/cluvfy/runcluvfy.sh comp sys -n node1,node2 -p crs -osdba crs -orainv oinstall

Read Full Post »

Configuring Operating System Users and Groups in All Nodes
On windows you don’t need to create separate user to install oracle or don’t need to create groups. OUI automatically do it. However on unix you must create the following operating system groups are required if you are installing Oracle RAC for the first time.

•The OSDBA group (typically, dba) -This is the OS user who has SYSDBA privilege.

•The Oracle Inventory group (typically, oinstall) -This group owns all Oracle software installed on the system.

The following operating system users are required

•A user that owns the Oracle software (typically, oracle).

•An unprivileged user (for example, the nobody user on Linux systems).

Create the required groups and users
Do this steps on all nodes of your cluster.
As a root user,

/usr/sbin/groupadd oinstall
/usr/sbin/groupadd dba
useradd -u 200 -g oinstall -G dba -d /home/oracle -r oracle
Change the password by,
passwd oracle

Verify the user by,
id oracle

Note that in this example in stead of using node1 use your original node name and instead of using node2 use your original node name.

Configuring SSH on All Cluster Nodes
When installing Oracle RAC on UNIX and Linux platforms, the software is installed on one node, and OUI uses secure communication to copy the software binary files to the other cluster nodes. OUI uses the Secure Shell (SSH) for the communication.

So you must have configured SSH on all nodes.

•To configure SSH, you must first create Rivest-Shamir-Adleman (RSA) keys and Digital Signature Algorithm (DSA) keys on each cluster node. After you have created the private and public keys, you copy the keys from all cluster node members into an authorized keys file that is identical on each node.

Generating RSA and DSA Keys
1)Log on as oracle user.

2)See whether .ssh directory exist or not. If does not exist then create one.
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh

3)Create the RSA-type public and private encryption keys by,
/usr/bin/ssh-keygen -t rsa
This command creates the public key in the /home/oracle/.ssh/id_rsa.pub file and the private key in the /home/oracle/.ssh/id_rsa file.

4)Create the DSA type public and private keys.
/usr/bin/ssh-keygen -t dsa
This command creates the public key in the /home/oracle/.ssh/id_dsa.pub file and the private key in the /home/oracle/.ssh/id_dsa file.

5)Repeat step 1 through 4 in all the nodes.

Adding the Keys to an Authorized Key File
1)Go to .ssh directory
$ cd ~/.ssh

2)Add the RSA and DSA keys to the authorized_keys files.
$ cat id_rsa.pub >>authorized_keys
$ cat id_dsa.pub >>authorized_keys

3)Using SCP copy the authorized_keys file to the oracle user .ssh directory on a remote node.
scp authorized_keys node2:/home/oracle/.ssh/

4)Using SSH, log in to the node where you copied the authorized_keys file, using the passphrase you created. Then change to the .ssh directory, and using the cat command, add the RSA and DSA keys for the second node to authorized_keys file.
ssh node2
Enter passphrase for key ‘/home/oracle/.ssh/id_rsa’:
cd ~/.ssh
cat id_rsa.pub >> authorized_keys
cat id_dsa.pub >> authorized_keys

5)If you have more than 2 nodes in your cluster, repeat step 3 and step 4 for each node you intend to add to your cluster. Copy the most recently updated authorized_keys file to the next node, then add the public keys for that node to the authorized_keys file.

6)After updating the authorized_keys file on all nodes, use SCP to copy the complete authorized_keys file from the last node to be updated to all the other cluster nodes, overwriting the existing version on the other nodes. For example,
scp authorized_keys node1:/home/oracle/.ssh/

Configure SSH User Equivalency on Cluster Member Nodes
1)Log on as a oracle user.

2)Start the SSH agent and load the SSH keys into memory.
$ exec /usr/bin/ssh-agent $SHELL
$ /usr/bin/ssh-add

3)Complete the SSH configuration by using the ssh command to retrieve the date on each node in the cluster.
$ ssh node1 date
$ ssh node2 date

Read Full Post »

Maximum size: 4 GB-1 which is power(2,32)-1 bytes.
Maximum size of the file name: 255 characters
Maximum size of the directory name: 30 characters
Maximum number of open BFILEs: Limited by the value of the SESSION_MAX_OPEN_FILES initialization parameter, which itself is limited by the maximum number of open files the OS will allow.

Maximum size: (4 GB – 1) * DB_BLOCK_SIZE initialization parameter/ LOB Chunk size.

So, if db_block_size=8024K then maximum size=32T
SQL> select 4*1024*1024*1024*8*1024/1024/1024/1024/1024 from dual;

As database block size vary from 2K to 32K so BLOB size can vary from 8TB to 128TB.
(8 TB to 128 TB)

Number of LOB columns per table: Limited by the maximum number of columns per table where maximum can be 1000.

Maximum size: 2000 bytes
Minimum and Default Size: 1 byte

Maximum size: 4000 bytes

Same as BLOB in the range of 4T to 128T.

6)Literals (characters or numbers in SQL or PL/SQL)
Maximum size: 4000 characters

Maximum size: 2 GB – 1

Maximum size: 2000 bytes

Maximum size: 4000 bytes

Same as BLOB in the range of 4T to 128T

Maximum size: 999…(in this way 38 9s) * power(10,125)
Minimum size: -999…(in this way 38 9s) *power(10,125)

Maximum size: 2000 bytes

Maximum size: 4000 bytes
Minimum size: 1 byte.

Maximum size: 4000 bytes
Minimum size: 1 byte.

Read Full Post »

You can create a password file using the password file creation utility, ORAPWD. For some operating systems, you can create this file as part of your standard installation.

This section contains the following topics:




Adding Users to a Password File

Maintaining a Password File

See Also:


“Using Password File Authentication”

“Selecting an Authentication Method for Database Administrators”


The syntax of the ORAPWD command is as follows:

ORAPWD FILE=filename [ENTRIES=numusers]

Command arguments are summarized in the following table.
Argument Description
FILE Name to assign to the password file. See your operating system documentation for name requirements. You must supply a complete path. If you supply only a file name, the file is written to the current directory.
ENTRIES (Optional) Maximum number of entries (user accounts) to permit in the file.
FORCE (Optional) If y, permits overwriting an existing password file.
IGNORECASE (Optional) If y, passwords are treated as case-insensitive.
NOSYSDBA (Optional) For Data Vault installations. See the Data Vault installation guide for your platform for more information.

There are no spaces permitted around the equal-to (=) character.

The command prompts for the SYS password and stores the password in the created password file.


The following command creates a password file named orapworcl that allows up to 30 privileged users with different passwords.

orapwd FILE=orapworcl ENTRIES=30

ORAPWD Command Line Argument Descriptions

The following sections describe the ORAPWD command line arguments.


This argument sets the name of the password file being created. You must specify the full path name for the file. If you supply only a file name, the file is written to the current directory. The contents of this file are encrypted, and the file cannot be read directly. This argument is mandatory.

The types of filenames allowed for the password file are operating system specific. Some operating systems require the password file to adhere to a specific format and be located in a specific directory. Other operating systems allow the use of environment variables to specify the name and location of the password file. For name and location information for the Unix and Linux operating systems, see Administrator’s Reference for UNIX-Based Operating Systems. For Windows, see Platform Guide for Microsoft Windows. For other operating systems, see your operating system documentation.

If you are running multiple instances of Oracle Database using Oracle Real Application Clusters, the environment variable for each instance should point to the same password file.

It is critically important to the security of your system that you protect your password file and the environment variables that identify the location of the password file. Any user with access to these could potentially compromise the security of the connection.

This argument specifies the number of entries that you require the password file to accept. This number corresponds to the number of distinct users allowed to connect to the database as SYSDBA or SYSOPER. The actual number of allowable entries can be higher than the number of users, because the ORAPWD utility continues to assign password entries until an operating system block is filled. For example, if your operating system block size is 512 bytes, it holds four password entries. The number of password entries allocated is always a multiple of four.

Entries can be reused as users are added to and removed from the password file. If you intend to specify REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE, and to allow the granting of SYSDBA and SYSOPER privileges to users, this argument is required.

When you exceed the allocated number of password entries, you must create a new password file. To avoid this necessity, allocate a number of entries that is larger than you think you will ever need.

This argument, if set to Y, enables you to overwrite an existing password file. An error is returned if a password file of the same name already exists and this argument is omitted or set to N.

If this argument is set to y, passwords are case-insensitive. That is, case is ignored when comparing the password that the user supplies during login with the password in the password file.

See Also:
Oracle Database Security Guide for more information about case-sensitivity in passwords.

In addition to creating the password file, you must also set the initialization parameter REMOTE_LOGIN_PASSWORDFILE to the appropriate value. The values recognized are:


NONE: Setting this parameter to NONE causes Oracle Database to behave as if the password file does not exist. That is, no privileged connections are allowed over nonsecure connections.

EXCLUSIVE: (The default) An EXCLUSIVE password file can be used with only one instance of one database. Only an EXCLUSIVE file can be modified. Using an EXCLUSIVE password file enables you to add, modify, and delete users. It also enables you to change the SYS password with the ALTER USER command.

SHARED: A SHARED password file can be used by multiple databases running on the same server, or multiple instances of an Oracle Real Application Clusters (RAC) database. A SHARED password file cannot be modified. This means that you cannot add users to a SHARED password file. Any attempt to do so or to change the password of SYS or other users with the SYSDBA or SYSOPER privileges generates an error. All users needing SYSDBA or SYSOPER system privileges must be added to the password file when REMOTE_LOGIN_PASSWORDFILE is set to EXCLUSIVE. After all users are added, you can change REMOTE_LOGIN_PASSWORDFILE to SHARED, and then share the file.

This option is useful if you are administering multiple databases or a RAC database.

If REMOTE_LOGIN_PASSWORDFILE is set to EXCLUSIVE or SHARED and the password file is missing, this is equivalent to setting REMOTE_LOGIN_PASSWORDFILE to NONE.

You cannot change the password for SYS if REMOTE_LOGIN_PASSWORDFILE is set to SHARED. An error message is issued if you attempt to do so.
Adding Users to a Password File

When you grant SYSDBA or SYSOPER privileges to a user, that user’s name and privilege information are added to the password file. If the server does not have an EXCLUSIVE password file (that is, if the initialization parameter REMOTE_LOGIN_PASSWORDFILE is NONE or SHARED, or the password file is missing), Oracle Database issues an error if you attempt to grant these privileges.

A user’s name remains in the password file only as long as that user has at least one of these two privileges. If you revoke both of these privileges, Oracle Database removes the user from the password file.

Creating a Password File and Adding New Users to It

Use the following procedure to create a password and add new users to it:


Follow the instructions for creating a password file as explained in “Using ORAPWD”.

Set the REMOTE_LOGIN_PASSWORDFILE initialization parameter to EXCLUSIVE. (This is the default.)

REMOTE_LOGIN_PASSWORDFILE is a static initialization parameter and therefore cannot be changed without restarting the database.

Connect with SYSDBA privileges as shown in the following example, and enter the SYS password when prompted:



Start up the instance and create the database if necessary, or mount and open an existing database.

Create users as necessary. Grant SYSDBA or SYSOPER privileges to yourself and other users as appropriate. See “Granting and Revoking SYSDBA and SYSOPER Privileges”, later in this section.

Granting and Revoking SYSDBA and SYSOPER Privileges

If your server is using an EXCLUSIVE password file, use the GRANT statement to grant the SYSDBA or SYSOPER system privilege to a user, as shown in the following example:


Use the REVOKE statement to revoke the SYSDBA or SYSOPER system privilege from a user, as shown in the following example:


Because SYSDBA and SYSOPER are the most powerful database privileges, the WITH ADMIN OPTION is not used in the GRANT statement. That is, the grantee cannot in turn grant the SYSDBA or SYSOPER privilege to another user. Only a user currently connected as SYSDBA can grant or revoke another user’s SYSDBA or SYSOPER system privileges. These privileges cannot be granted to roles, because roles are available only after database startup. Do not confuse the SYSDBA and SYSOPER database privileges with operating system roles.

See Also:
Oracle Database Security Guide for more information on system privileges
Viewing Password File Members

Use the V$PWFILE_USERS view to see the users who have been granted SYSDBA or SYSOPER system privileges for a database. The columns displayed by this view are as follows:
Column Description
USERNAME This column contains the name of the user that is recognized by the password file.
SYSDBA If the value of this column is TRUE, then the user can log on with SYSDBA system privileges.
SYSOPER If the value of this column is TRUE, then the user can log on with SYSOPER system privileges.

Maintaining a Password File

This section describes how to:


Expand the number of password file users if the password file becomes full

Remove the password file

Expanding the Number of Password File Users

If you receive the file full error (ORA-1996) when you try to grant SYSDBA or SYSOPER system privileges to a user, you must create a larger password file and regrant the privileges to the users.

Replacing a Password File

Use the following procedure to replace a password file:


Identify the users who have SYSDBA or SYSOPER privileges by querying the V$PWFILE_USERS view.

Delete the existing password file.

Follow the instructions for creating a new password file using the ORAPWD utility in “Using ORAPWD”. Ensure that the ENTRIES parameter is set to a number larger than you think you will ever need.

Follow the instructions in “Adding Users to a Password File”.

Removing a Password File

If you determine that you no longer require a password file to authenticate users, you can delete the password file and then optionally reset the REMOTE_LOGIN_PASSWORDFILE initialization parameter to NONE. After you remove this file, only those users who can be authenticated by the operating system can perform SYSDBA or SYSOPER database administration operations.

Expert are always welcome for their valuable comment or suggestion for the above post.

Read Full Post »