Differences between Azure SQL Database and SQL Server
Azure SQL Database is a PaaS
offering and therefore some of the features differ from the on-premises SQL Server. Some of the important features which
differ from on-premises SQL Server are:
Conventional
database backup and restore statements aren't supported. The backups are automatically scheduled and start within a few minutes of the database
provisioning. The backups are transactionally consistent, which means that you can do a point-in-time restore.
There is no additional cost for backup storage until the backup storage goes beyond 200% of the provisioned database storage.
You can reduce the backup retention period to manage the backup storage cost. You can also use the long-term retention period feature to store the backup in the Azure vault for a much smaller cost for a longer duration.
Other than the automatic backups, you can export the Azure SQL Database
bacpac
or
dacpac
file to Azure storage.
The default
recovery model of an Azure SQL Database is
Full and it can't be modified to any other recovery models as in on-premises recovery models.
The recovery model is set when the master database is created, meaning when an Azure SQL Server is provisioned. The recovery model can't be modified because the master database is read-only.
To view the
recovery model of an Azure SQL Database, execute the following query:
Note
You can use any of the two methods discussed earlier in the chapter to run the query – the Azure portal or SSMS.
You should get the following output:
Azure SQL Server doesn't
have SQL Server Agent, which
is used to schedule jobs and send success/failure notifications. However, you can use the following workarounds:
- Create a SQL Agent job on an on-premises SQL Server or on an Azure SQL VM SQL Agent to connect and run on the Azure SQL Database.
- Azure Automation: It allows users to schedule jobs in Microsoft Azure to automate manual tasks. This topic is covered in detail later in the book.
- Elastic Database Jobs: It is an Azure Cloud Service that allows the scheduled execution of ad hoc tasks. This topic is covered in detail later in the book.
- Use PowerShell to automate the task and schedule the PowerShell script execution with Windows Scheduler, on-premises, or Azure SQL VM SQL Agent.
Change Data Capture (CDC) allows
you to capture data modifications to CDC-enabled databases and tables. The CDC feature is important in
incremental load scenarios, such as incrementally inserting changed data to the data warehouse from an OLTP environment. The CDC requires SQL Server Agent, and therefore isn't available in Azure SQL Database. However, you can use the temporal table, SSIS, or Azure Data factory to implement CDC.
The
auditing features, such as C2 auditing, system health extended event, SQL default trace, and anything that
writes alerts or issues into event logs or SQL error logs, aren't available. This is because of the fact that it's a PaaS offering and we don't have access or control to event logs or error logs.
However, there is an auditing and threat detection feature available out of the box for Azure SQL Database.
You can't
enable mirroring between two Azure SQL Databases, but you can
configure Azure SQL Database as a mirror server. You can also set up a readable secondary for an Azure SQL Database, which is actually better than mirroring.
Table partitioning
using a partition scheme and
partition function is allowed in Azure SQL Database; however, because of the PaaS nature of the SQL database, all partitions should be created on a primary file group. You won't get the performance improvement for having partitions on different disks (spindles); however, you will get performance improvement of partition elimination.
Conventional replication
techniques such as snapshot, transactional, and
merge replication can't be done between two Azure SQL Databases. However, an Azure SQL Database can be a subscriber to an on-premises or Azure VM SQL Server. However, this too has the following limitations:
- Supports one-way transactional replication, not peer-to-peer or bi-directional replication
- Supports only push subscription
- You should have SQL Server 2012 or above at on-premises
- Replication and distribution agents can't be configured on Azure SQL Database
Three-part names (databasename.schemaname.tablename
) are only limited to
tempdb
wherein you
access a
temp table as
tempdb.dbo.#temp
. For example, if there is a temporary table, say,
#temp1
, then you can run the following query to select all of the values from
#temp1:
You can't access the tables in different SQL databases in Azure on the same Azure SQL Server using three-part names. Four-part (ServerName.DatabaseName.SchemaName.TableName
) names aren't allowed at all.
You can use Elastic query to access tables from different databases from an Azure SQL Server. Elastic query is covered in detail later in the book. You can access objects in different schemas in the same
Azure SQL Database using two-part (Schemaname.Tablename
) names.
To explore other T-SQL differences, visit: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-transact-sql-information.
Some features not supported by Azure SQL Database or Azure SQL Server are:
The
SQL Browser is a Windows service
and provides instance and post information to incoming connection requests. This isn't required as the Azure SQL Server listens to port
1433
only.
Azure SQL Database doesn't support
FileStream
or
filetable,
just because of the PaaS nature of the service. There is a
workaround to use Azure Storage; however,
that would require re-work on the application and the database side.
Common Language Runtime (SQL CLR)
SQL CLR allows
users to write programmable
database objects such as stored procedures, functions, and triggers in managed code. This provides significant performance improvement in some scenarios. SQL CLR was first supported and then the support was removed due to concerning security issues.
Resource Governor
allows you to throttle/limit resources (CPU, Memory, I/O) as per different SQL Server workloads. This feature is not available in Azure SQL Database.
Azure SQL Database
comes with different services tiers, each suitable for different workloads. You should first evaluate the performance tier your application workload will fit into and accordingly provision the database for that performance tier.
Global temporary tables
are defined by
##
and are
accessible across all sessions. These are not supported in Azure SQL Database. Local temporary tables are allowed.
Log shipping is the
process of taking log backups
on a primary server, and copying and restoring them on the secondary server. Log shipping is commonly used as a high availability or disaster recovery solution, or to migrate a database from one SQL instance to another. Log shipping isn't supported by Azure SQL Database.
SQL Trace and Profiler
can't be used to
trace the events on Azure SQL Server. As of now, there isn't any direct alternate other than using DMVs, monitoring using Azure Portal, and extended events.
Trace Flags are
special switches used to enable or
disable a particular SQL Server functionality. These are not available in Azure SQL Server.
Azure SQL Database
doesn't support
all of the system stored procedures supported in the on-premises SQL Server. System procedures such as
sp_addmessage
,
sp_helpuser
, and
sp_configure
aren't supported. In a nutshell, procedures related to features unsupported in Azure SQL Database aren't supported.
The
USE statement is
used to switch from one database context to another. This isn't supported in Azure SQL Database.