-
Is your database already hosted in Azure? If not, then what are your plans to migrate your database to Azure? Do you have a requirement to migrate without downtime?
Determine the current migration strategy, and what requirements or limitations may exist. For example, the requirement of migrating without downtime will then limit the options available to bring data onto the platform.
-
Are you hosting your SQL databases on Azure using an Infrastructure as a Service approach? Are you planning to modernize onto Azure SQL Database or SQL Managed Instances?
Determine if there are plans to re-platform the solution to use the Platform as a Service (PaaS) alternative, reducing the overall management overhead of the solution. If so, it is important to consider potential compatibility issues of the PaaS approach. It is also worth understanding that there is tooling available to assess the feasibility of migrating databases onto Azure
SQL Server database migration to Azure SQL Database
Migrate your SQL Server database to Azure SQL Database using DMS
-
What size is your database and how many databases are you planning to migrate?
The size of the database will affect the options available in transferring data to Azure. The number of databases (and interdependencies) will determine additional factors including timescales of data transfer, as well as management considerations such as Elastic Pools in Azure SQLDB.
Using the Import/Export service to transfer data to Azure Storage
Elastic pools help you manage and scale multiple Azure SQL databases
-
How much downtime can you afford during data and app migration?
Determine whether there is a clear strategy of Service Level Agreements (Recovery Time Objective and Recovery Point Objective). Consider whether a strategy has been created based upon this criterion, and the suitability of options. For example, whether Backup and Restore can be used as a migration strategy, or whether replication is needed.
Migration from SQL Server to Azure SQL Database using transactional replication
-
Do you have multiple databases that need to speak to each other (MSDTC or linked serversfor example).
Understand the inter-dependencies within the solution, and the ability to rearchitect the solution.
-
Have you implemented any type of data partitioning?
If the database keeps on growing, could you potentially hit some technical limit of the platform? Additionally, consider data access as part of your sharing strategy and using different tiers of storage.
-
Do you use readable secondaries? Have you considered how you might make use of them?
Identify whether High Availability at the database layer has been considered as part of the solution. Determine whether a secondary instance of the database in a read-only format could aid in the load balancing of database activity. You may want to consider the CQRS pattern in this scenario.
-
How much data can you afford to lose in your solution if you have to recover a database?
Determine whether any loss of data is allowed. If this is not allowed, approaches to High Availability will need to be considered.
-
How much downtime can you afford to have?
Determine the allowed recovery time and if backups are the approach
-
Are you running your SQL tier on Azure IaaS? What is your planned approach to High Availability or Disaster Recovery?
Determine the High Availability vs Disaster Recovery strategy. Common options include
- High Availability
- Always on Availability Groups
- Fail-Over Clustering
- Disaster Recovery (Azure Only)
- Availability Groups
- Backup and Restore with Azure Blob
- Transaction Log Shipping
High availability and disaster recovery for SQL Server in Azure Virtual Machines
If the considered option is to use Failover Clustering - Configure SQL Server Failover Cluster Instance on Azure Virtual Machines
If the considered option is to use Availability Groups - Configure Always On Availability Group on Azure Virtual Machines
- High Availability
-
Are you aware of the built-in functionality of Azure SQL Database for Business Continuity and Disaster Recovery?
Identify whether Infrastructure as a Service (IaaS) been chosen without considering all options. Could manageability of the database solution be improved, by using Azure SQL Database?
Learn about automatic SQL Database backups
Recover an Azure SQL database using automated database backups
-
Have you considered Automatic Fail-over Groups in Azure SQL Database for High Availability?
Is High availability being assumed as a part of the solution because it is a Platform as a Service (PaaS) solution? Has there been any consideration to the steps needed to be taken during region failure or RPO?
-
How does the application behave if the database fails over to a secondary site?
Determine whether automatic failover groups, or Always on Availability Groups being used to handle the failover. If they are not, identify how this is being achieved. Additionally, determine how the application handles rollback or failed transactions.
-
How do you monitor your data layer?
Determine whether there is any enterprise monitoring of the data layer. How is it determined that the solution is working appropriately? If this is not being used, consider the associated documentation.
Monitoring database performance in Azure SQL Database Azure SQL DB with Log Analytics
-
How would you know if you had an outage or failure?
Monitoring may be configured, but how much is it used? Determine if a live issue would first be reported by end-users, or whether monitoring systems would pick this up in advance. This also leads towards DevOps, and having a representative environment prior to production, which has representative tests in place.
-
What alerts have been set-up?
Does the monitoring system require an individual to take the initiative and review the details, or will it send proactive notifications such as e-mails?
-
Do you track the performance of queries from the application through to the DB layer?
Determine if proactive measures are being taken to manage database performance, and therefore proactive steps in managing the SLA and Performance of the application.
-
What solutions do your DBAs use to manage the data estate?
Determine whether an enterprise approach is being taken to managing the SQL estate, or whether each database is being maintained on a case-by-case basis. Identify whether there is an opportunity to manage the SQL estate as a fleet, rather than individual machines or databases.
-
How do you determine the current patch level across the estate?
Determine whether there is any automation in place. Unpatched machines presents a risk in the environment, and this is undesirable, especially at the data layer which is generally core to an application.
-
Do you use any IDS/IPS software for threat detection?
Determine the proactive steps being taken in maintaining the security of the data estate.
-
Is your database performance and usage predictable?
Determine whether elastic pools or individual databases should be considered within the solution.
Elastic pools help you manage and scale multiple Azure SQL databases
-
Are you using SQL Server on IaaS? Have you placed your virtual machines into an availability set?
To provide redundancy to your application, it is recommended that you group two or more virtual machines of the same tier in an availability set. This configuration within a datacenter ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available and meets the 99.95% Azure SLA.
Manage the availability of Windows virtual machines in Azure
-
Are you using SQL Server on IaaS? Do you know about the difference between unmanaged and managed disks? Have you leveraged Azure Managed disks?
Identify whether the throughput levels of your underlying disks and compute has been considered to safeguard the performance of your solution. Also be aware of managed disks, and the benefits that this could bring to the reliability of your solution.
Performance best practices for SQL Server in Azure Virtual Machines
-
Are you using SQL Server on IaaS? Have you configured your implementation to the recommendations in the performance best practices documentation?
The associate documentation provides recommended practices in configuring IaaS solutoions, and ensuring suitable performance.
Performance best practices for SQL Server in Azure Virtual Machines
-
Are you aware of the Azure SQL DB best practices? Have you implemented these in your solution?
Security is a top concern when managing databases, and it has always been a priority for Azure SQL Database. Your databases can be tightly secured to help satisfy most regulatory or security requirements.
Azure SQL Database security best practices
-
Is the data stored in your database sensitive? Do you require special data handling?
Identify the encryption and protection requirements of the solution. Leverage the associated documentation in providing a solution to this problem.
Azure SQL Database Discovery and Classification
Always Encrypted (Database Engine)
-
Do you audit access to the servers and the DDL queries that are run?
Determine whether there is an understanding into which users are performing which tasks / queries / functoins? Is this level of detail needed, perhaps for compliance or some form of internal business policy?
-
Who has admin access to the system?
This builds upon the previous question. Limiting admin access is a recommended practice. Admins can bypass security measures and potentially see protected data.
-
Do you encrypt your backups?
Protecting data at rest may be important. Is there a guarantee that backed-up data cannot be restored to another server that is not under your control?
-
Can you define the business impact for a data breach?
Determine whether there is an understanding into the follow-on effects of a data breach. Has the wider business impact been considered, rather than just focusing on the technology challenge and impact?
Azure SQL Database customer implementation technical studies