SQL Database connection and retry guidance
Microsoft no longer maintains Enterprise Library 6, and its source code has been made available to
the public. Microsoft does provide example retry logic at
https://azure.microsoft.com/documentation/articles/sql-database-develop-csharp-retry-windows/
.
Either approach is valid.
Please reference the SQL Database best practices and design guidelines available at
https://azure.microsoft.com/documentation/articles/sql-database-connect-central-
recommendations/
for more detailed information and recommendations on connecting to SQL
Database.
Finally, Microsoft’s Patterns & Practices team has published detailed retry guidance for a variety of
Azure services, including SQL Database. Please reference the guidance at
https://azure.microsoft.com/documentation/articles/best-practices-retry-service-specific/
for more
information, including code samples.
There is much more to designing a resilient cloud-based application than implementing basic retry
logic. It may also be necessary to reconsider how an application processes data. For instance, it is
often helpful to implement an eventually consistent solution, potentially using queues and
background tasks to complete requests. It may also be worth considering breaking read and write
operations across separate databases, potentially using the Active Geo-Replication feature in SQL
Database to replicate operations on the write database to the read database.
SQL Server in Azure Virtual Machines
Although SQL Database provides database as a service with enterprise-grade features and virtually no
administration, there are still situations in which running your own SQL Server deployment may be
necessary. A common reason is the requirement to use features that are not available in SQL
Database.
As discussed in Chapter 3, Azure Virtual Machines provides the ability to host and manage your own
virtual machines (VMs). What you use the VM for is largely your responsibility, and this includes using
it to install, configure, and manage your own full SQL Server VM or cluster of SQL Server VMs.
Billing
When running your own SQL Server deployment on Azure Virtual Machines, you must understand
three important cost factors. First is the cost of the Windows VM itself. Recall that Azure VMs are
charged on a per-minute usage model. Second is the SQL Server license cost. When using a SQL
Server image from the Azure Marketplace, you will pay an additional per-minute SQL Server license
cost, which varies according to the version of SQL Server (Web, Standard, or Enterprise) and the target
size of the VM. Finally, you’ll also pay for the Azure Storage cost. Azure Storage (specifically page
blobs) is used as the persistence mechanism for Azure Virtual Machines disks. To summarize, the cost
for SQL Server in Azure Virtual Machines can be represented as Total cost = Windows Server cost +
SQL Server license cost + Azure Storage cost.
If you have your own SQL Server license, you can use that instead of paying the per-minute charge
associated with using a SQL Server license obtained from an Azure Virtual Machines image. In this
case, you pay only for the Windows Server license and any related Azure Storage costs. The ability to
use your own SQL Server license is a feature of License Mobility through Microsoft’s Software
Assurance on Azure program. For more information, see
http://azure.microsoft.com/pricing/license-
mobility/
.
174
CHAPTER 6 | Databases
Do'stlaringiz bilan baham: |