SQL Server 2016 – SQLXpertise

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

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…”

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

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

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

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

Please select the backup file, you wish to restore

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

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

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

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

Hope you find this post helpful !!!

Simple guide to restore SQL Server Backup from Azure Blog Storage

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:

We can also see the database restored in Object Explorer

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

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:

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

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

Having an offsite backup is always important and helpful.

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

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

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

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

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

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

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

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

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

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

How to monitor Stretch databases ?

We can now see the Icon for the database has changed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 !!!

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: