Steps for Configuration of Mirroring setup



Steps to configure mirroring.

Step 1 : Connect to DB.

Step 2: Right click on DB --- > go to properties


Step 3: Click on Mirroring (In select a Page)


Step 4:- Click on Configure Securities:




 Step 5: Configuration DB mirroring security wizard will open & Click on NEXT



Step 6: Select yes if witness server is there



Step 7: 
  • Connect to Principle server
  • Add Port number , if do not want to use default
  • Provide Endpoint name

Step 8 :
  • Connect to Mirror server
  • Add Port number , if do not want to use default
  • Provide Endpoint name

Step 9 : 
  • Connect to Witness server , if any
  • Add Port number , if do not want to use default
  • Provide Endpoint name

Step 10 : Provide service account name who has read write access on other servers (Principle , mirror , witness if any)


Step 11: Summary of configuration settings and click on finish


 Step 12 : All three action executed successfully.



Step 13 :- This window will ask you to start mirroring. Before click on start mirroring cross verify that you have restore database in NORECOVERY MODE on mirror server. 
Many times you may face issue in this step. Check the errors & resolve it


Step 14 :- Final output of Mirroring setup 
This Window allows you to perform manual failover of DB, pause mirroring & remove mirroring.

  



Thats it :)



Overview of database mirroring


What Is Mirroring
  • Database mirroring is a primarily software solution for increasing database availability
  • Mirroring is implemented on a per-database basis and works only with databases that use the full recovery model.
  • The simple and bulk-logged recovery models do not support database mirroring
  • Database mirroring maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine.
  • One server instance serves the database to clients (the principal server). The other instance acts as a hot or warm standby server (the mirror server)

Prerequisites : 

  • For a mirroring to be established, the partners and the witness (if any) must be running on the same version of SQL Server.
  • The two partners, that is the principal server and mirror server, must be running the same edition of SQL Server
  • The database must use the full recovery model
  • Verify that the mirror server has sufficient disk space for the mirror database
  • Take full backup of database & restore it on mirror database with NORECOVERY option.Also , log backups that were created after that backup was taken must also be applied to mirror database , again WITH NORECOVERY.

Restrictions : 

  • Only user databases can be mirrored. You cannot mirror the mastermsdbtempdb, or model databases
  • A mirrored database cannot be renamed during a database mirroring session
  • Database mirroring is not supported with either cross-database transactions or distributed transactions

Benefits of Database Mirroring:

  • Increases data protection.
  • Increases availability of a database.
  • Improves the availability of the production database during upgrades.

How Database Mirroring Works:

  • The principal and mirror servers communicate as partners in a database mirroring
  • The two partners : the principal role and the mirror roleone partner performs the principal role, and the other partner performs the mirror role. 
  • The partner that owns the principal role is called as the principal server and The partner that owns copy of principle database is called as Mirroring Server.
  • Database mirroring involves redoing every insert, update, and delete operation that occurs on the principal database onto the mirror database as quickly as possible.
  • Redoing is accomplished by sending a stream of active transaction log records to the mirror server, which applies log records to the mirror database, in sequence, as quickly as possible.
  • A database mirroring session runs with either synchronous or asynchronous operation

A. synchronous  operation
  • A transaction is committed on both partners
  • Increase in  transaction latency.
B. Asynchronous operation
  • The transactions commit without waiting for the mirror server to write the log to disk
  • This maximizes performance
Operating Modes

 High-safety mode
  • It supports synchronous operation
  • When session starts the mirroring Server synchronizes  mirroring DB  with principle DB ASAP.
  • As soon as the databases are synchronized, a transaction is committed on both partners
High-performance mode
  • It supports asynchronous operation
  • When session start The mirror database might lag somewhat behind the principal database.
  • It does not wait for mirroring server to acknowledge to principle server for commit. This means that transactions commit without waiting for the mirror server to write the log to disk.
All database mirroring sessions support only one principal server and one mirror server.
High-safety mode with automatic failover requires a third server instance, known as a witness.
Witness server send packets to each server continuously  at an interval of 10 sec to verifying whether the principal server is up and functioning. If any problem occures say due to network latency then witness server will automatically failover databases.
We can change this witness interval value 

Role Switching: 

Automatic failover
This requires high-safety mode and the presence of the mirror server and a witness. The database must already be synchronized, and the witness must be connected to the mirror server.

Manual failover
This requires high-safety mode. The partners must be connected to each other, and the database must already be synchronized.

Forced service (with possible data loss)
Under high-performance mode and high-safety mode without automatic failover, forcing service is possible if the principal server has failed and the mirror server is available.

More:





Reference :
https://msdn.microsoft.com/en-us/library/ms189852(v=sql.105).aspx


Database Mirroring Terms and Definitions

automatic failover :The process by which, when the principal server becomes unavailable, the mirror server to take over the role of principal server and brings its copy of the database online as the principal database.
failover partners: The two server instances (the principal server or the mirror server) that act as role-switching partners for a mirrored database.
forced service : A failover initiated by the database owner upon the failure of the principal server that transfers service to the mirror database while it is in an unknown state.
High-performance mode : The database mirroring session operates asynchronously and uses only the principal server and mirror server. The only form of role switching is forced service (with possible data loss).
High-safety mode : The database mirroring session operates synchronously and, optionally, uses a witness, as well as the principal server and mirror server.
manual failover : A failover initiated by the database owner, while the principal server is still running, that transfers service from the principal database to the mirror database while they are in a synchronized state.
mirror database : The copy of the database that is typically fully synchronized with the principal database.
mirror server : In a database mirroring configuration, the server instance on which the mirror database resides.
mirror server : In a database mirroring configuration, the server instance on which the mirror database resides.
principal database : In database mirroring, a read-write database whose transaction log records are applied to a read-only copy of the database (a mirror database).
principal server : In database mirroring, the partner whose database is currently the principal database.
redo queue : Received transaction log records that are waiting on the disk of a mirror server.
role : The principal server and mirror server perform complementary principal and mirror roles. Optionally, the role of witness is performed by a third server instance.
role switching : The taking over of the principal role by the mirror.
send queue : Unsent transaction log records that have accumulated on the log disk of the principal server.
session : The relationship that occurs during database mirroring among the principal server, mirror server, and witness server (if present).
After a mirroring session starts or resumes, the process by which log records of the principal database that have accumulated on the principal server are sent to the mirror server, which writes these log records to disk as quickly as possible to catch up with the principal server.
Transaction safety : A mirroring-specific database property that determines whether a database mirroring session operates synchronously or asynchronously. There are two safety levels: FULL and OFF.
Witness : For use only with high-safety mode, an optional instance of SQL Server that enables the mirror server to recognize when to initiate an automatic failover. Unlike the two failover partners, the witness does not serve the database. Supporting automatic failover is the only role of the witness.

More: 




Reference : 
Microsoft web site

Configuration of logshipping

Prerequisites for log shipping


Steps for configuring LogShipping on Primary Server 

Step 1:  Connect to DB and select DB where you want to configure log shipping 



Step 2:  Right click on DB --- > Go to properties


Step 3 : Click on Transaction Log Shipping option.


Step 4:  
  1. Enable Log shipping Configuration for primary database
  2. Click on Backup Settings to configure Log Shipping for primary database.
  3. Click on ADD to add Secondary database settings.


Step 5: Click on Backup Settings 




Schedule Backup Job




Step 6: Add Secondary database settings

a. Initialize Secondary Server tab.



b. Copy File tab


Schedule Copy Job.


c. Restore Transaction log tab


Schedule restore Job



Step 7 : Click on finish.  Log shipping Configured successfully. 


Step 8 :  
On Primary Server :-
In SQL Server Agent : 
LSbackup_DB_NAME job gets created , who takes the log backup of latest transaction log.

On Secondary Server :-
DBA database is in standby/Read-only mode.

In SQL Server Agent : 
Two jobs get created

  • LSCopy_SecondaryServer_DBname  -- Copy latest Transaction to secondary server
  • LSRestore_SecondaryServer_DBname -- Restore latest Transaction to secondary server
Run All jobs at below sequence:
  • Backup job
  • Copy Job
  • Restore Job

Log shipping and its configurations

Log shipping 

What is log shipping??
Log shipping is a term used to describe the process of taking a transaction log backup from a primary database, and restoring the transaction log backup on a secondary database.

What is the need for log shipping:

Among the more common reasons:
  • To have a standby database ready in case of a service disruption to the primary database 
  • To have a read-only copy of the primary database available on another server, in order to lighten the load on the primary server 
  • To have multiple copies of the database available in different locations 

 The backup is the easy part. We just need to ensure that your database is running the full
or bulk-logged recovery models.                       

SQL Server provides a GUI interface to assist us in setting up log shipping between a primary database and one or more secondary databases. However, it is only available in certain editions of SQL Server.  In SQL Server 2000, it is available only in the Developer and Enterprise editions. In SQL Server 2005 and above , it is available in all editions except the Express edition. Using the SQL Server log shipping configuration may not always be suitable, for e.g. if the primary and secondary databases are not linked. We can always set up log shipping manually, but we will need to address the above mentioned issues.

NOTE: While it is possible to ship logs from a SQL Server 2000 database to a SQL
Server 2005 instance by setting up log shipping yourself, the database can only be in a
recovery state, not in a read-only state. This is because when SQL Server 2005 makes the
database read-only, it upgrades the database's internal structures too, making it impossible to apply further non-SQL 2005 transaction logs.


Prerequisite to do log shipping:

  1. Database should be Backed up from primary server and Restored to secondary server.
  2. Both servers should be connected
  3. SQL Server agent’s service account must have read/write permission to the below network shares.
    1. \\Primary Server\logshipping.
    2. \\Secondary Server\logshipped. 
Backup / Restoration Database:
  1. Take a full backup of “DBA” database to a local folder in Primary server
  2. Copy the backup file to a local folder in Secondary server
  3. Restore the backup file with “NoRecovery”
  4. Change the database to “Standby mode” while restoring.
Do’s for logshipping:
  1. Always take backup using the below command.
         BACKUP DATABASE mdb TO DISK=<@tmstmp> WITH INIT, COPY_ONLY 
    Note: change the disk name in the above command before execution
  1. Shrink log using DBCC Shrinkfile is possible
  2. Any user created in primary should be in disabled status (except SA and SYSadmins)
  3. Any issue on Logshipping should be fixed within 48 hours.
Don’ts for logshipping:

  1. Don’t run Full backup, Log backup(includes truncate) or differential backup.
  2. Don’t change database settings at source except altering or creating database files.
  3. Don’t enable any user in primary server (except SA and SYSadmins)
CONFIGURATION:

Steps to perform performance tuning in oracle

Introduction to SQL Tuning

An important facet of database system performance tuning is the tuning of SQL statements. SQL tuning involves three basic steps:

  • Identifying high load or top SQL statements that are responsible for a large share of the application workload and system resources, by reviewing past SQL execution history available in the system.
  • Verifying that the execution plans produced by the query optimizer for these statements perform reasonably.
  • Implementing corrective actions to generate better execution plans for poorly performing SQL statements.


Goals for Tuning

The objective of tuning a system is either to reduce the response time for end users of the system, or to reduce the resources used to process the same work. You can accomplish both of these objectives in several ways:

  • Reduce the Workload
  • Balance the Workload
  • Parallelize the Workload


I)  First step is to create the tuning task.

You can create tuning tasks from the following:

-  SQL statement selected by SQL identifier from the cursor cache
-  SQL Tuning Set containing multiple statements
-  Text of a single SQL statement
-  SQL statement selected by SQL identifier from the Automatic Workload Repository.

DECLARE
  my_task_name VARCHAR2(30);
  my_sqltext CLOB;
  BEGIN
  my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
                           sql_id =>'604y8n0jfdr6u',
                           scope => 'COMPREHENSIVE',
                           time_limit => 600,
                           task_name => 'sql5_604y8n0jfdr6u',
                           description => 'Task to tune a query');
END;

II)  Execute the tuning task.

Begin
dbms_sqltune.Execute_tuning_task (task_name =>'sql5_604y8n0jfdr6u');
end;

III)  You can check the status of the tas using following query:

select * from dba_advisor_log where task_name like'%604y8n0jfdr6u%';

IV)  View the Recommendation

set long 100000
set linesize 5000
set pages 4000
select dbms_sqltune.report_tuning_task('sql5_604y8n0jfdr6u') from dual;

OUTPUT:


Output will gives you recommendation. Test that recommendation on lower environment . If successful then perform on productions.

DBMS_SQLTUNE.REPORT_TUNING_TASK('sql5_604y8n0jfdr6u')
--------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name   : sql5_604y8n0jfdr6u
Tuning Task Owner  : SYS
Workload Type      : Single SQL Statement
Scope              : COMPREHENSIVE
Time Limit(seconds): 600
Completion Status  : COMPLETED
Started at         : 06/21/2017 12:11:59
Completed at       : 06/21/2017 12:20:14

-------------------------------------------------------------------------------
Schema Name: Scott
SQL ID     : 604y8n0jfdr6u
SQL Text   : select * from table1
-------------------------------------------------------------------------------
FINDINGS SECTION (2 findings)
-------------------------------------------------------------------------------

1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
  A potentially better execution plan was found for this statement.

  Recommendation (estimated benefit: 63.54%)
  ------------------------------------------
  - Consider accepting the recommended SQL profile.
    execute dbms_sqltune.accept_sql_profile(task_name =>
            'sql5_604y8n0jfdr6u', task_owner => 'SYS', replace => TRUE);

  Validation results
  ------------------
  The SQL profile was tested by executing both its plan and the original plan
  and measuring their respective execution statistics. A plan may have been
  only partially executed if the other could be run to completion in less time.

                           Original Plan  With SQL Profile  % Improved
                           -------------  ----------------  ----------
  Completion Status:            COMPLETE          COMPLETE
  Elapsed Time (s):             .261283           .115704      55.71 %
  CPU Time (s):                 .258624           .109908       57.5 %
  User I/O Time (s):                  0                 0
  Buffer Gets:                    88828             32377      63.55 %
  Physical Read Requests:             0                 0
  Physical Write Requests:            0                 0
  Physical Read Bytes:                0                 0
  Physical Write Bytes:               0                 0
  Rows Processed:                  7633              7633
  Fetches:                         7633              7633
  Executions:                         1                 1

  Notes
  -----
  1. Statistics for the original plan were averaged over 4 executions.
  2. Statistics for the SQL profile plan were averaged over 9 executions.

2- Index Finding (see explain plans section below)
--------------------------------------------------
  The execution plan of this statement can be improved by creating one or more
  indices.

  Recommendation (estimated benefit: 82.5%)
  -----------------------------------------
  - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.  If you choose to create the
    recommended index, consider dropping the index "SCOTT"."AVRPP_FK_I"
    because it is a prefix of the recommended index.
 create index SCOTT.IDX$$_2075701 on CRAMMER.TABLE_O
("RPPLANID","TABLE2RELATION","TABLE2DIMOBJECT","TABLEID");

  - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.
   create index SCOTT.IDX$$_207570002 on
   SCOTT.TABLE2_R("TABLE22OBJECTTWO","TABLE22OBJECTONE");

  - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.
    create index SCOTT.IDX$$_207570003 on SCOTT.TABLE_ALL_O("EMP");

  - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.
    create index SCOTT.IDX$$_207570004 on SCOTT.NODE123_O("NODE123ID");


CONT.....

Reference :-

Oracle Support