Archive

Archive for the ‘SQL Server 2016’ Category

Simple Guide to restore SQL Server Backup from Azure Blog Storage using Management Studio

November 6, 2017 Leave a comment

In previous post, we saw

1. How to implement Off-site/Cloud backup in SQL Server 2017 using Azure Blob Storage

2. How to restore SQL Server Backup from Azure Blog Storage using queries

In this post we will see how to restore SQL Server Backup from Azure Blog Storage using SQL Server Management Studio

Step 1: Open SQL Server Management Studio 2017 and connect to SQL Server on which you would like restore the database and right click on “Databases” node and click on “Restore Database…

capture20171030134441904

Step 2: Select Backup media type as “URL” and click on “Add

capture20171030134506048

Step 3: Click “Add” to add the new Azure Storage container

capture20171030134514751

If you are not already signed in, sign in to Azure account and then select the Subscription, Storage account and blob container

Based on you requirement, set up the Expiration date for Shared Access policy, by default, its setup for 1 year from date of setup

Click on “Create Credential” to generate the Shared Access Signature (SAS), once SAS is generated successfully, click “Ok” to continue

capture20171030141847722

Step 4: Please review the selected Azure Storage Container and Shared Access Signature and click “Ok” to continue

capture20171030142950818

Please select the backup file, you wish to restore

capture20171030143011020

Please review the selected backup media and click “Ok” to continue

capture20171030143016568

Step 5: Based on requirement change other options in Files tab or Options tab and click “Ok” to start the restore process

capture20171030143029023

Once restore is completed, we should see this restored successfully message

capture20171030143049123

We should also be able to see the database restored in Object Explorer as well

capture20171031191639786

Hope you find this post helpful !!!

Advertisements

Simple guide to restore SQL Server Backup from Azure Blog Storage

November 1, 2017 1 comment

In previous post, we saw How to implement Off-site/Cloud backup in SQL Server 2017 using Azure Blob Storage, in this post we will see how to restore SQL Server Backup from Azure Blog Storage

Step 1: Create Credential – Please use below query to create Credential to access Azure Blog Storage using Shared Access Signature, This step is optional if you already have created Credential to create backup

CREATE CREDENTIAL [https://XYZ.blob.core.windows.net/YourContainerName]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET =
 'sv=Replace your SAS Key Here';
GO

Step 2: Restore Database from Cloud (Azure Blog Storage) – Please run below query to restore the database using SQL Server Backup stored in Azure Blog Storage, Please change the query to meet your needs

USE [master]

RESTORE DATABASE [SQL2017_DEMO]
FROM
     URL = N'https://XYZ.blob.core.windows.net/YourContainerName/BackupFile.bak'
WITH  FILE = 1,
MOVE N'SQL2017_DEMO' TO N'E:\SQLDATA\SQL2017_DEMO.mdf',
MOVE N'SQL2017_DEMO_log' TO N'E:\SQLDATA\SQL2017_DEMO_log.ldf',
NOUNLOAD,
STATS = 5

GO

Output:

capture20171031191608492

We can also see the database restored in Object Explorer

capture20171031191639786

Hope you find this post helpful !!!

Simple Guide to implement Off-Site/Cloud backup in SQL Server 2017 using Azure Blob Storage in 2 Steps

October 31, 2017 2 comments

In this post we will see how to implement Off-Site/Cloud backup in SQL Server 2017 using Azure Blog Storage

Requirements

1. SQL Server 2017

2. Azure Account

3. Azure Blog Storage with Container provisioned and Shared Access Signature generated

4. SQL Server Management Studio (Optional, if you prefer to run using SQLCMD)

 

Step 1: Create Credential – Please use below query to create Credential to access Azure Blob Storage using Shared Access Signature

CREATE CREDENTIAL [https://sqlxpertise.blob.core.windows.net/sqlbackups]
	WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET =
	'sv=INSERT YOUR SHARED ACCESS SIGNATURE';
GO

 

Step 2: Backup Database to Cloud – Run below query to backup the database to Azure Blob Storage, Please change the query to meet your needs

BACKUP DATABASE SQL2017_DEMO
    TO URL = 'https://XYZ.blob.core.windows.net/sqlbackups/BackupFileName.bak'
    WITH STATS = 10, SKIP, NOREWIND, NOUNLOAD

 

Output:

capture20171030101644076

If we login to Azure Portal and Navigate to the Storage account and sqlbackups container, we can see the backup file

capture20171030104711661

You can also use SQL Server Management studio 2017 to connect to Azure Storage as well to see the backup file

capture20171030104822250

Having an offsite backup is always important and helpful.

Hope you find this post helpful !!!

Monitoring Transaction Replication : Replicating On-Premise SQL Server databases to SQL Azure databases

October 30, 2017 Leave a comment

In previous post, we saw How to setup Transactional Replication to replicate On-Premise SQL Server databases to SQL Azure databases, in this post we will how to monitor the Replication process and make changes to data in On-Premise and verify the changes in SQL Azure database

Replication Monitoring

Step 1: Right click on Replication –> Local Publications –> Launch Replication Monitor

capture20171025144517902

Step 2: We can see the summary of subscriptions, current average performance and current worst performance

capture20171026151048695

Step 3: Expand the Publication to see the list of subscribers, we can see the list of subscribers and each of their Performance, Latency and Last Synchronization time

capture20171026151138103

Step 4: If we need to review the status of each Agent status, we can use Agents tab and see their status

capture20171026151212465

The different types of Agents status available are as follows

capture20171026151221076

Step 5: To view the details of a particular publisher/subscriber, Please right click on the Publication/Subscription and click on “View Details

capture20171026151412435

In details view we can see the completed (Success and Failure) and current sessions, if we click on a particular session, we can also see the steps ran on that session

Details of the publication session

capture20171026151457561

Details of the Subscriber session

capture20171026151512972

On-Premise Data Update verification in SQL Azure database

We will make data changes using below query in On-Premise server

Query to insert a new record and update one record in On-Premise SQL Server database

INSERT INTO dbo.Customers 
( 
CustomerID, 
CustomerName, 
CustomerAddress, 
Comments, 
Value 
) 
VALUES 
( 80001, -- CustomerID - int 
'CustomerName80001', -- CustomerName - char(100) 
'CustomerAddress80001', -- CustomerAddress - char(100) 
'Comments80001', -- Comments - char(185) 
80001 -- Value - int 
);

UPDATE dbo.Customers 
SET Comments = 'Update Comments 80000' 
WHERE CustomerID = 80000; 

After 2 minutes, we ran the below query in SQL Azure database

Query to verify data changes in SQL Azure database

SELECT [CustomerID], 
[CustomerName], 
[CustomerAddress], 
[Comments], 
[Value] 
FROM [dbo].[Customers] 
WHERE CustomerID >= 80000; 

Output: We can see the changes made in On-Premise server is replicated to SQL Azure database

capture20171026151906330

Hope you find this post helpful !!!

Temporal Tables – Part 5- Simple Guide to implement History Tables using SQL Server 2016/2017– Storing History data in Azure using Stretch Database

October 25, 2017 Leave a comment

In previous posts, we saw

Part 1 – How to create Temporal Tables

Part 2 – Accessing History data from Temporal Tables

Part 3 – Modifying Temporal Tables, Disabling System versioning and why we need to disable ?

Part 4 – Managing Temporal Tables and History Data

In this post we will see how to store the history data in Azure using Stretch database

Step 1: Right click on Database name and click on Tasks –> Stretch –> Enable

capture20171023145111550

Step 2: Select the tables which you would like to enable Stretch

capture20171023145132469

Step 3: Click on “Entire Table” hyperlink in Migrate column to customize the criteria for Stretch, by default the Entire table will be stored in SQL Azure

Please specify the name of the Stretch Criteria, Please select the Column based on which you want to apply the filter criteria , select the Condition and then specify the value

capture20171023145208563

capture20171023143520236

After specify the criteria, click on “Check” to validate, once you “Success”, Please click “Done” to continue

Step 4:  Please review the selected tables and click “Next” to continue

capture20171023145217186

Step 5: Please sign in to your Azure account, if you are not already signed in, Please select the Subscription, Azure region

We can create a new SQL Azure server or use an existing server, in this demo I am using an existing server

After providing details, click “Next” to continue

capture20171023145308669

Step 6: Please provide the Public IP Address range for which you need to enable access, If you have only one Public IP Address, Please specify that for both From and To and then click Next to proceed

FYI, If you created a new server, by default this step will enable the Firewall for Azure services

capture20171023145338248

Step 7: Review the settings selected and also review the estimated Pricing, this will change based on the number of tables and size of data you are planning to store in SQL Azure

Please click “Finish” to start the Stretch enabling process

capture20171023145344372

We can review the Stretch deployment process in below screenshot, based on your selecting, the steps shown below can change

capture20171023145350517

Once all the steps are completed, we can see status as “Passed”, if you want to see the verbose details on what happened in each step, we can review the Logs, To access the logs, Please click on Hyperlink, This will be very helpful when there is any error occurred

capture20171023145653549

How to monitor Stretch databases ?

We can now see the Icon for the database has changed

capture20171023145727577

To monitor the progress of Stretch, Please right click on Database Name –> Tasks –> Stretch –> Monitor

capture20171023145943961

In Monitor window, we can see the Source server, Target Azure server, Database and list of tables being stretched and number of rows uploaded

capture20171023145858728

We can also connect to the SQL Azure server and access the history data as shown below

capture20171023150934383

capture20171023150943585

capture20171023151039526

How to disable Stretch for a particular table / database ?

To disable Stretch for a table, right click on table name –> Stretch –> Disable

You have 2 options

1. Bring data back from Azure – This will download all the data from SQL Azure and update your local server

2. Leave data in Azure – This will leave the data as is in SQL Azure server and new data will be stored locally

Please choose the option based on your requirement

capture20171023150056965

In this demo, we are using “Bring data back from Azure” option, Please click “Yes” to confirm the disable process

capture20171023151116898

Depending on the size of the data, the process will run and you will see the below message

capture20171023151124884

After disabling Stretch on all the tables, we can disable the Stretch at the database level by right clicking on Database name –> Tasks –> Stretch –> Disable

capture20171023151619546

FYI, If you try disabling the Stretch in your database, before disabling Stretch in the tables, you will see this below validation message

capture20171023150002544

Once the Stretch disable process is completed, we will see this below completed message

capture20171023151629941

FYI, You can use the Stretch option not just for Temporal History tables, you can use this for any other tables where you want to store historical data or least accessed data remotely for reference or compliance purposes

Hope you find this post helpful !!!

Temporal Tables–Simple Guide to implement History Tables using SQL Server 2016/2017–Part 4–Managing Temporal Tables and History Data

October 24, 2017 1 comment

In previous posts, we saw

Part 1 – How to create Temporal Tables

Part 2 – Accessing History data from Temporal Tables

Part 3 – Modifying Temporal Tables, Disabling System versioning and why we need to disable ?

In this post we will see how to manage Temporal tables and History

To get list of Temporal Tables – Snippet 1

SELECT name,
       object_id,
       temporal_type,
       temporal_type_desc,
       history_table_id,
       is_remote_data_archive_enabled,
       is_external,
       history_retention_period,
       history_retention_period_unit,
       history_retention_period_unit_desc
FROM sys.tables
WHERE temporal_type > 0
ORDER BY name;

 

Output

capture20171023102432733

If we see the output, we can identify the following

1. Type of Temporal Table – System Versioned or History table using “temporal_type” and “temporal_type_desc” columns

2. For System Versioned tables, we can also see the History Table ID

3. History Retention Period can be determined using history_retention_period, history_retention_period_unit and history_retention_period_unit_desc

history_retention_period = -1  = History is kept forever

Positive Integer = Refers to the number of Days/Weeks/Years

history_retention_period_unit will have one of these values

-1 = INFINITE

3 = DAY(S)

4 = WEEK(S)

5 = MONTH(S)

6 = YEAR(S)

By default, when we create temporal tables, if we don’t specify Retention period, it will be created with Infinite period of retention

Modifying Retention Period

Let us see how we can change Retention Period for an existing Temporal Table

Code to alter table to set Retention Period for 2 days – Snippet 2

ALTER TABLE dbo.Demo
	SET (SYSTEM_VERSIONING = ON
			(
				HISTORY_TABLE = dbo.DemoHistory,
				HISTORY_RETENTION_PERIOD = 2 DAYS
			)
		)

If we run query from Snippet 1, we will see below output

capture20171023103757653

To get list of Databases with Retention Enabled – Snippet 3

Once retention period is enabled for any table in the database, SQL Server will set the is_temporal_history_retention_enabled flag = 1 for the database by default and also create background jobs to cleanup the history data

SELECT name,
       database_id,
       is_temporal_history_retention_enabled
FROM sys.databases
WHERE is_temporal_history_retention_enabled = 1
ORDER BY name;

Output

capture20171023104055758

If you want to disable automatic cleanup task, Please use below command

Query to disable cleanup task – Snippet 4

ALTER DATABASE SQL2017_DEMO
     SET TEMPORAL_HISTORY_RETENTION OFF

If we run the query in Snippet 3, we can see the changes

capture20171023104605524

How to cleanup History tables manually ?

If you prefer to cleanup the History tables manually rather than automated, Please follow below steps

1. Make your application offline

2. Run query to disable System versioning on required tables

3. Run query to delete data from History using SysEndTime as Filter criteria

4. Run query to enable System versioning for tables disabled in Step 2

5. Make your application online

If your application has to be on 24/7, better option is to use the in-built automated cleanup task

Hope you find this post helpful !!!

Temporal Tables – Simple Guide to implement History Tables using SQL Server 2016/2017–Part 3–Modifying Temporal Tables, Disabling System Versioning and why we need to disable

October 23, 2017 2 comments

Part 1 – How to create Temporal tables

Part 2 – Accessing History data from Temporal Tables

In this post we will how to modify Temporal Tables, How to disable System Versioning in Temporal tables to update large set data of without affecting history or truncate tables

Modifying Temporal Tables

For adding new columns to Temporal tables, Please use below command

ALTER TABLE dbo.Demo ADD DemoDesc VARCHAR(255) NULL

Screenshot before adding the new column

capture20171022142508566

Screenshot after adding the new column – If we notice, adding the column in the main table automatically modifies the history table as well

capture20171022142736382

Similarly we can modify the tables to drop column or increasing the size of the field, but some of the changes to table are not supported ex. Adding Identify column or changing the data type of the field which is not supported using implicit conversion, in that scenario we need to disable the system versioning to make changes

Disable System Versioning

Screenshot before disabling system versioning

capture20171022143805111

Script to disable system versioning

ALTER TABLE dbo.Demo	SET (SYSTEM_VERSIONING = OFF);

Screenshot after disabling system versioning – If we notice the System versioning is disabled and both Main and history table is displayed as regular tables now

capture20171022143922452

There are other scenarios we need to disable System versioning, if we need to do any of the following operations

1. TRUNCATE TABLE on Main or History table

Msg 13545, Level 16, State 1, Line 1
Truncate failed on table ‘SQL2017_DEMO.dbo.Demo’ because it is not a supported operation on system-versioned tables.

2. Deleting rows from History table

Msg 13560, Level 16, State 1, Line 4
Cannot delete rows from a temporal history table ‘SQL2017_DEMO.dbo.DemoHistory’.

3. Dropping Main or History table

Msg 13552, Level 16, State 1, Line 6
Drop table operation failed on table ‘SQL2017_DEMO.dbo.Demo’ because it is not a supported operation on system-versioned temporal tables.

Hope you find this post helpful !!!

%d bloggers like this: