Password less authentication between linux servers

Password less authentication between linux servers:-
Source server:-192.168.2.11
Target server:-192.168.2.12

Hostfile entry On both source and target server:

cat /etc/hosts
192.168.2.11 server1.soumya.com server1
192.168.2.12 server2.soumya.com server2

On source server:-

# ssh-keygen -t rsa
# ssh-keygen -t dsa
# cd /root/.ssh
# cat id_rsa.pub >>authorized_keys
# cat id_dsa.pub >>authorized_keys
# scp authorized_keys root@server2:/root/.ssh/

On target server:-
# ssh-keygen -t rsa
# ssh-keygen -t dsa
# cd /root/.ssh
# cat id_rsa.pub >>authorized_keys
# cat id_dsa.pub >>authorized_keys
# scp authorized_keys root@server1:/root/.ssh/


Now lets test if both servers can ssh each other w/o password or not:-

on source server:-
[root@server1 ~]# ssh server2
Last login: Fri May 29 08:32:06 2015 from 192.168.2.50

[root@server1 ~]# ssh server2 date
Fri May 29 08:37:28 IST 2015


on target server:-

[root@server2 ~]# ssh server1
Last login: Fri May 29 08:38:00 2015 from server2.soumya.com

[root@server1 ~]# ssh server1 date
Fri May 29 08:38:14 IST 2015

So we can see both servers can connect each other without prompting for any password.

Happy learning...




Please share your ideas and opinions about this topic.

If you like this post, then please share with others.
Please subscribe on email for every updates on mail.

Switchover of Databases (Primary to standby and standby to primary) in Dataguard oracle 11g.

Switchover of Databases (Primary to standby and standby to primary) in  Dataguard  oracle 11g.

Oracle Version:- Enterprise Edition Release 11.2.0.1
OS:- Rhel 6.4
Primary database:- Prim
Standby database:- Stand


Switchover is a planned event, it is ideal when we might want to upgrade the primary database or change
the storage/hardware configuration (add memory, cpu networking), we may even want to upgrade the
configuration to Oracle RAC .

What happens during a switchover is the following :

1.) Notifies the primary database that a switchover is about to occur
2.) Disconnect all users from the primary database
3.) Generate a special redo record that signals the End of Redo (EOR)
4.) Converts the primary database into a standby database
5.) Once the standby database applies the final EOR record, guaranteeing that no data loss has been lost,
converts the standby database into the primary database.



Before doing the switchover lets run few select queries to find out some info:-
In primary:-

SQL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;

STATUS       INSTANCE_NAME    DATABASE_ROLE
------------ ---------------- ----------------
OPEN         prim             PRIMARY

In standby:-

SQL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;

STATUS       INSTANCE_NAME    DATABASE_ROLE
------------ ---------------- ----------------
MOUNTED      stand            PHYSICAL STANDBY


In primary:-
Archive log destination of Prim:-

SQL> show parameter log_archive_dest_1;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      LOCATION=/u01/app/oracle/flash
                                                 _recovery_area VALID_FOR=(ALL_
                                                 LOGFILES,ALL_ROLES) DB_UNIQUE_
                                                 NAME=prim


SQL> show parameter log_archive_dest_2;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2                   string      SERVICE=stand LGWR ASYNC VALID
                                                 _FOR=(ALL_LOGFILES,PRIMARY_ROL
                                                 E) DB_UNIQUE_NAME=stand

*Archivelog Destination 1 of Primary Database is "/u01/app/oracle/flash_recovery_area" and Archivelog
destination 2 of Primary database is pointing to the service-name of the standby database.


In standby:-
Archive log destination of Stand:-
SQL> show parameter log_archive_dest_1;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      LOCATION=/u01/app/oracle/flash
                                                 _recovery_area VALID_FOR=(ALL_
                                                 LOGFILES,ALL_ROLES) DB_UNIQUE_
                                                 NAME=stand


SQL> show parameter log_archive_dest_2;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2                   string      SERVICE=prim LGWR ASYNC VALID_
                                                 FOR=(ALL_LOGFILES,PRIMARY_ROLE
                                                 ) DB_UNIQUE_NAME=prim

*Archivelog Destination 1 of Standby database is "/u01/app/oracle/flash_recovery_area" and archivelog
destination 2 of standby database is pointing to the service-name of the primary database.
(Note: destination 2 in standby database is not mandatory. It is required only if the standby database
would be running in as primary database during switchover or failover. Hence it would be a good practice
to set this parameter to avoid problems during the switchover or failover.)

Pre-Switchover Checks:-

In standby database:-

Verify whether Managed Recovery process is running on the standby database

Use the following query to check if the managed recovery process is running on the standby database.

SQL> select process,status,sequence# from v$managed_standby;

PROCESS   STATUS        SEQUENCE#
--------- ------------ ----------
ARCH      CONNECTED             0
ARCH      CONNECTED             0
ARCH      CONNECTED             0
ARCH      CLOSING              27
RFS       IDLE                  0
RFS       IDLE                 28
MRP0      WAIT_FOR_LOG         28

The above result shows that the Managed Recovery Process (MRP0) is running on the standby database.
If MRP is not running, then start the process with real time enabled using the below query in the
standby database.

SQL>alter database recover managed standby disconnect from session;

Once when the MRP has started on the standby database, make sure that the archive logs generated at the
primary database end are shipped and getting applied to the standby database.

At primary database:-
SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
            27

At standby database:-
SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
            27

In the above case, sequence# 27 is the maximum sequence generated at the primary database and the
same has been applied to the standby database.So both database's log files are in sync.

*Verify primary and standby tempfiles match :-

For each temporary tablespace on the standby, verify that temporary files associated with that
tablespace on the primary database also exist on the standby database. Tempfiles added after initial
standby creation are not propagated to the standby. Run this query on both the primary and target
physical standby databases and verify that they match.

In primary database:-
SQL> select ts#, name ,status from v$tempfile;
      TS# NAME                                     STATUS
---------- ---------------------------------------- -------
         3 /u01/app/oracle/oradata/prim/temp01.dbf  ONLINE

SQL> select ts#,name from v$tablespace;

       TS# NAME
---------- ----------------------------------------
         0 SYSTEM
         1 SYSAUX
         2 UNDOTBS1
         4 USERS
         3 TEMP
         6 EXAMPLE


In Standby database:-
SQL> select ts#, name ,status from v$tempfile;
       TS# NAME                                     STATUS
---------- ---------------------------------------- -------
         3 /u01/app/oracle/oradata/stand/temp01.dbf ONLINE


SQL> select ts#,name from v$tablespace;

       TS# NAME
---------- ----------------------------------------
         0 SYSTEM
         1 SYSAUX
         2 UNDOTBS1
         4 USERS
         3 TEMP
         6 EXAMPLE

*Verify that all datafiles are online on both primary and standby databases:-

On both primary and standby database:-

SQL> select name from v$datafile where status='OFFLINE';

no rows selected

If there are any offline datafiles, then bring them online using the below query
SQL>alter database datafile<datafile name> online;


Switchover Steps:

These steps are performed during the switchover process at the primary database side.

Check if there are any jobs running on the primary database using the below query.

SQL>select * from dba_jobs_running;
no rows selected

If there are any jobs running on the primary database and if it’s execution is not very important,
then terminate the job to continue further.

Block further job submission by setting the job_queue_processes parameter to 0 so that there would be no
jobs running during switchover.

SQL> show parameter job_queue_process;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes                  integer     1000

Set this parameter to the value 0.
SQL> alter system set job_queue_processes=0 scope=spfile;                  

System altered.


*Verify that the primary database can be switched over to the standby

In primary database:-

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO STANDBY

A value of TO STANDBY or SESSIONS ACTIVE (which requires the WITH SESSION SHUTDOWN clause on the switchover command)
indicates that the primary database can be switched to the standby role. If neither of these values is
returned, a switchover is not possible because redo transport is either mis-configured or is not functioning
properly.


*Switchover the primary database to standby

Once when value of switchover_status returns “TO STANDBY” or “SESSIONS ACTIVE” on the primary database,
then perform the switchover using the below query

In primary:-
SQL> alter database commit to switchover to physical standby with session shutdown;

Database altered.

Now the primary database is switched over to the standby database. The execution of the above command
may take some time and the archive logs generated during its execution would be automatically applied to
the standby database. Once when the command is executed with the output as “Database altered”, it means
that the primary database has been switched over to the standby.

Note: Always perform the switchover of the primary database to standby database first and then
switchover the standby database to primary. If not, then you would end up landing with two primary
databases.


*Switchover the standby database to primary
Query the switchover_status column from the v$database view at the standby side to determine whether
the standby database can be switched over to the primary database.

In standby database:-
SQL> select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO PRIMARY

A value of TO PRIMARY or SESSIONS ACTIVE indicates that the standby database is ready to be switched to
the primary role. If neither of these values is returned, verify that redo apply is active and that redo
transport is configured and working properly. Continue to query this column until the value returned is
either TO PRIMARY or SESSIONS ACTIVE.

Once when the value of switchover_status returns “TO PRIMARY” or “SESSIONS ACTIVE” on the standby
database, then perform the switchover using the below query

SQL>alter database commit to switchover to primary with session shutdown;

Now the standby database has been switched over to the primary database.

*Open the new primary database (stand)

The new primary database will be in mount state. Open this new primary database using the below query.

SQL>alter database open;

SQL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;

STATUS       INSTANCE_NAME    DATABASE_ROLE
------------ ---------------- ----------------
OPEN         stand            PRIMARY


*Restart the new standby database
Restart the new standby database (old primary database prim), bring it to the mount stage and
start the managed recovery process.

Shutdown the new standby database (prim)
SQL> shutdown immediate;
ORA-01507: database not mounted

ORACLE instance shut down.

Startup the new standby database (prim) in mount stage
SQL>startup mount;
ORACLE instance started.

Total System Global Area  413372416 bytes
Fixed Size                  2213896 bytes
Variable Size             335546360 bytes
Database Buffers           71303168 bytes
Redo Buffers                4308992 bytes
Database mounted.

Start the managed recovery process on the the new standby database (prim)
SQL>alter database recover managed standby database disconnect from session;
Database altered.

QL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;

STATUS       INSTANCE_NAME    DATABASE_ROLE
------------ ---------------- ----------------
MOUNTED      prim             PHYSICAL STANDBY

*Post-Switchover tasks

Reset the job_queue_processes parameter to its previous value
Set the job queue processes to its original value on the new standby (prim).

SQL> show parameter job_queue

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes                  integer     0

SQL> alter system set job_queue_processes=1000 scope=spfile;

System altered.


Now the roles of the databases have been changed. The primary database (prim) has been changed to
standby database and the standby database (stnd) has been changed to primary database.
The archive logs that get generated in the new primary database (stnd) get shipped automatically to the
new standby database (prim) and they are applied on it automatically.

Maximum archivelog generated at the new primary database (stnd)

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
            34

Maximum archivelog that has been shipped and applied to the new standby database (prim)
SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
            34


*Now if we want the real time apply enabled on new standby database(prim)
Perform the following queries on new standby database(prim)
SQL> alter database recover managed standby database cancel;

Database altered.

SQL> alter database open;

Database altered.

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY WITH APPLY

 

Please share your ideas and opinions about this topic. If you like this post, then please share with others. Please subscribe on email for every updates on mail.

Related Posts Plugin for WordPress, Blogger...