Monday, June 25, 2012

Configuring SSH on All Cluster Nodes

Configuring SSH on All Cluster Nodes

Configure SSH without using a password or passphrase between primary and standby server.
For Linux or Unix.

To configure SSH without using a password or passphrase the utility ssh-keygen is run. You have to create
a RSA authentication key to be able to log into a remote site from your account. This should be done as the

Dbvisit software owner, never as root!

Important:
Ensure the home directories (cd $HOME) of the accounts on the primary and standby servers have

the following permissions:
[oracle@RAC1]$ ls –al .
drwxr-xr-x 40 oracle dba 4096 Sep 17 02:46 .
If the permissions are 775 or 777 then ssh may keep asking for a password. Change permission
with: chmod 755 .

1. On the primary server as Dbvisit software owner (do not enter passphrase!):
[oracle@RAC1]$ ssh-keygen
Generating public/private dsa key pair.
Enter file in which to save the key (/oracle/orabase/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /oracle/orabase/.ssh/id_dsa.
Your public key has been saved in /oracle/orabase/.ssh/id_dsa.pub.
The key fingerprint is:
73:c7:f5:7c:ee:bd:62:7f:0d:51:ed:8a:c7:45:f7:d9 oracle@RAC1
In this example RAC1 is the primary server and RAC2 is the standby server
The public/private key pair may either be dsa or rsa
On some implementations of ssh, you have to specify: ssh-keygen –t dsa
On Linux the output may be different:
[oracle@RAC1]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/oracle/orabase/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /oracle/orabase/.ssh/identity.
Your public key has been saved in /oracle/orabase/.ssh/identity.pub.
The key fingerprint is:
a2:88:ad:53:e8:5b:37:a1:82:6d:03:ec:96:c4:6b:df oracle@RAC1
In this example RAC1 is the primary server and RAC2 is the standby server
This will generate 2 files under your home directory:
.ssh/id_dsa
.ssh/id_dsa.pub
Or alternatively generate the following files under your home directory:
.ssh/id_rsa
.ssh/id_rsa.pub
On Linux the files may be called different.
.ssh/identity
.ssh/identity.pub

2. On the standby server as Dbvisit software owner (do not enter passphrase!):
[oracle@RAC2]$ ssh-keygen
Oracle is a registered trademark of Oracle Corporation
Copyright 2000-2008 Avisit Solutions Limited
www.dbvisit.com
Generating public/private dsa key pair.
Enter file in which to save the key (/oracle/orabase/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /oracle/orabase/.ssh/id_dsa.
Your public key has been saved in /oracle/orabase/.ssh/id_dsa.pub.
The key fingerprint is:
73:c7:f5:7c:ee:bd:62:7f:0d:51:ed:8a:c7:45:f7:d9 oracle@RAC2
In this example RAC1 is the primary server and RAC2 is the standby server
The public/private key pair may either be dsa or rsa
On Linux the output may be different:
[oracle@RAC2]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/oracle/orabase/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /oracle/orabase/.ssh/identity.
Your public key has been saved in /oracle/orabase/.ssh/identity.pub.
The key fingerprint is:
a2:88:ad:53:e8:5b:37:a1:82:6d:03:ec:96:c4:6b:df oracle@RAC2
In this example RAC1 is the primary server and RAC2 is the standby server
This will generate 2 files under your home directory:
.ssh/id_dsa
.ssh/id_dsa.pub
Or alternatively generate the following files under your home directory:
.ssh/id_rsa
.ssh/id_rsa.pub
On Linux the files may be called different
.ssh/identity
.ssh/identity.pub

3. On the standby server create a new empty file called .ssh/authorized_keys
[oracle@RAC2]$ cd .ssh
[oracle@RAC2]$ vi authorized_keys
In this example RAC1 is the primary server and RAC2 is the standby server

4. On your primary server copy the contents of file .ssh/id_dsa.pub to the new file .ssh/authorized_keys on
the standby server. The file may be called identity.pub or id_rsa.pub instead of id_dsa.pub.
[oracle@RAC1]$ cat id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBALj5RhJzSDOvRnTID/P2kblmE9qM2zCrzUa0gDL/fbngdcB8EELeJJi
LuhR9uM/XyQr+UySGVeMS1jM0uBfQcs/7p3WAEkxncXzGduxlsyO8iyYfr8Kf7ufGPdJq7n15v0hjUMWSa
w6YcA== oracle@RAC1

5. Ensure the new file .ssh/authorized_keys has the correct permission:
[oracle@RAC1]$ chmod 600 authorized_keys

6. On the primary server create a new empty file called .ssh/authorized_keys
[oracle@RAC1]$ cd .ssh
[oracle@RAC1]$ vi authorized_keys
In this example RAC1 is the primary server and RAC2 is the standby server

7. On your standby server copy the contents of file .ssh/id_dsa.pub to the new file .ssh/authorized_keys
on the primary server. The file may be called identity.pub or id_rsa.pub instead of
id_dsa.pub.
[oracle@RAC2]$ cat id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBALj5RhJzSDOvRnTID/P2kblmE9qM2zCrzUa0gDL/fbngdcB8EELeJJi
Oracle is a registered trademark of Oracle Corporation
Copyright 2000-2008 Avisit Solutions Limited
www.dbvisit.com
LuhR9uM/XyQr+UySGVeMS1jM0uBfQcs/7p3WAEkxncXzGduxlsyO8iyYfr8Kf7ufGPdJq7n15v0hjUMWSa
w6YcA== oracle@RAC2

8. Ensure the new file .ssh/authorized_keys has the correct permission:
[oracle@RAC1]$ chmod 600 authorized_keys
SSH is now setup and configured. To test:
On the primary server:
[oracle@RAC1]$ ssh RAC2 ls -al
The authenticity of host ‘RAC2 (10.1.1.82)’ can’t be established.
RSA key fingerprint is 40:bb:ea:96:48:7d:22:fa:36:a6:8e:e7:37:7c:f4:d3.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘RAC2,10.1.1.82′ (RSA) to the list of known hosts.
total 896
drwxr-xr-x 26 oracle dba 4096 Feb 27 18:49 .
drwxr-xr-x 6 root root 4096 May 30 2006 ..
-rw——- 1 oracle dba 2640 Feb 15 09:39 .ICEauthority
drwx—— 5 oracle dba 4096 May 21 2006 .Trash
-rw——- 1 oracle dba 120 Feb 15 09:39 .Xauthority
-rw-r–r– 1 oracle dba 76 May 24 2006 .alias
-rw——- 1 oracle dba 16019 Jun 1 2006 .bash_history
……
In this example RAC1 is the primary server and RAC2 is the standby server
On the standby server:
[oracle@RAC2]$ ssh RAC1 ls –al
The authenticity of host ‘RAC1 (10.1.1.81)’ can’t be established.
RSA key fingerprint is 40:bb:ea:96:48:7d:22:fa:36:a6:8e:e7:37:7c:f4:d3.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘RAC1,10.1.1.81′ (RSA) to the list of known hosts.
total 896
drwxr-xr-x 26 oracle dba 4096 Feb 27 18:49 .
drwxr-xr-x 6 root root 4096 May 30 2006 ..
-rw——- 1 oracle dba 2640 Feb 15 09:39 .ICEauthority
drwx—— 5 oracle dba 4096 May 21 2006 .Trash
-rw——- 1 oracle dba 120 Feb 15 09:39 .Xauthority
-rw-r–r– 1 oracle dba 76 May 24 2006 .alias
-rw——- 1 oracle dba 16019 Jun 1 2006 .bash_history
……
In this example RAC1 is the primary server and RAC2 is the standby server

Secure shell configuration is now competed.

Saturday, June 9, 2012

DBA checklists



Bellow are some procedures that Oracle DBA might know 
 
 I. Daily Procedure
         1.               Verify all instances are up   
         2.               Look for any new alert log entries   
         3.               Verify DBSNMP is running   :    Which may be security treat
         4.               Verify success of database backup 
         5.               Verify success of database archiving to tape
         6.               Verify enough resources for acceptable performance
         7.               Copy Archived Logs to Standby Database and Roll Forward
         8.               Read DBA manuals for sometime
      
  II.  Nightly Procedures
         
             1.    Collect volumetric data
                  2.   Taking offline/cool full backup if necessary

  III.  Weekly Procedures
               
         1.            Look for objects that break rules
            2.            Look for security policy violations
            3.            Look in SQL*Net logs for errors, issues
            4.            Archive all Alert Logs to history
            5.            Visit home pages of key vendors

  IV.          Monthly Procedures

          1.            Look for Harmful Growth Rates
          2.            Review Tuning Opportunities
          3.            Look for I/O Contention
          4.            Review Fragmentation
          5.            Project Performance into the Future
          6.          Perform Tuning and Maintenance