I would like to set Auto-pause delay on for SQL Database. Zone redundancy is disabled.
So I select "Enable auto-pause", set 1 hour and press Apply.
I get a strange error:
Failed to scale from General Purpose: Serverless, Gen5, 4 vCores,
250 GB storage, zone redundant disabled to General Purpose:
Serverless, Gen5, 4 vCores, 250 GB storage, zone redundant disabled
for database: my-dev-sql-db-sandbox.
Error code: .Error message: An unexpected error occured while
processing the request.
In the beginning, you can switch to serverless compute tier only under the vCore model which provides a wide range of configuration controls and offers Hyperscale/Serverless to automatically scale your database based on your workload needs.
When the scaling operation is failing with aforementioned error, this most likely due to a serverless limitation. For instance, enabling auto-pause for a serverless database is not supported if long-term retention (LTR backups) or geo-replication is enabled.
The following features do not support auto-pausing, but do support auto-scaling:
Geo-replication (active geo-replication and auto-failover groups).
Long-term backup retention (LTR).
The sync database used in SQL Data Sync. Unlike sync databases, hub and member databases support auto-pausing.
DNS alias created for the logical server containing a serverless database.
Elastic Jobs, when the job database is a serverless database. Databases targeted by elastic jobs support auto-pausing, and will be resumed by job connections.
In case any of these features are in-use, then auto-pausing must be disabled and the database will remain online regardless of the duration of database inactivity.
For more information regarding Serverless, you can refer to Azure SQL DB documentation: Serverless compute tier - Azure SQL Database | Microsoft Docs
I hope you find this article helpful. If you have any feedback please do not hesitate to provide it in the comment section below.
Related
I have created an azure SQL single database "w3s_singledb" with no elastic pool and SQL server named "singledb2022dec". After logging into "singledb2022dec.database.windows.net" I executed "create database w3s_seconddb" and it was created.
Next, I created Azure Elastic Pool "elasticpool2022dec" and SQL server named "elasticpool2022dec.database.windows.net". After logging into "elasticpool2022dec.database.windows.net" I executed "create database testdb1" and "create database testdb2". Both were created.
I changed all the databases pricing to basic DTU.
I was trying to understand the basic difference between Single Database and Elastic Pool Databases.?
I know Single Database will be used for "When Application needs a Single Database to work on".
And Elastic Pool will be used for "When Application needs multiple databases to work on and need to share Common Resources like CPU and RAM".
I was trying to understand more elaborately.
The basic idea with an Elastic pool is that you can share resources among databases that need resources at different times. Thereby avoiding paying for idle resources.
Example:
3 databases, set up as 3 single database instance, costs 3X
3 databases, set up as an elastic pool with total resources comparable to 2 single databases, costs 2X
Azure SQL databases are throttled, once you’ve reached the limit of the database resources, additional requests will be timed out.
With an elastic pool, you create a shared resource group for your databases. This can be much more cost efficient, especially when your database infrastructure requires multiple databases or multi-tenancy.
If your database resource usage displays a typical pattern with peaks in performance every now and then, an Elastic Pool might be suited for you.
If your database usage requires large amounts of resources for a longer period of time, it might be a better idea to have a dedicated resource tier for your database.
If you want to change the service tier or compute size of an Elastic Pool, keep in mind that all databases within the pool are affected, briefly. But there will certainly be some kind of downtime during the scaling process. If you need to scale out a dedicated database tier, only that database is affected.
I have a need to load data into Azure Hyperscale incrementally.
Source data is in Azure VM that has SQL server installed in it.
Source database is about 6Tb in size and has about 370 tables.
We need a way to get incremental changes in the last X amount of hours and sync them into the same database in Hyperscale.
Ideally, we would extend our database with the availability group setup but since Hyperscale does not support that, we need to find a way to keep these in sync.
Source database does have change data capture enabled.
The best on-line migration option is to use the Azure Database Migration Service (link) where the Online (continuous sync) migration support scenario (link) you need is supported:
The sync will essentially run in the background until completed while being able to access the data that has been migrated. I believe this is a continuous copy scenario and is not incremental. With PaaS database services, you do not have access to perform snapshot replication operations from external data sources. The Hyperscale instance is built upon snapshot replication but it currently only serves the hosted database functionality.
Regards,
Mike
A programmer unintentionally erased the production database.
We use the option of Azure 'Restore Deleted Database', and it worked.
But after restoring the database, is accusing DTU 100% all the time.
We stopped all sites and services that used the database of production, and after starting again, back to accuse DTU 100%.
Before normal was staying with some peaks up to 40%.
Does anyone know a way to solve this problem?
Please send the details of your DB name, server name and subscription id to shantanu dot kurhekar # microsoft dot com
Update :
Worked offline with Jonathan to get this resolved.
When a database on Azure SQL DB service is restored, it is restored using the service tier that was applicable at the restore point with its default performance level. This could be different from the tier the database was at before restore.
http://azure.microsoft.com/blog/2014/10/01/azure-sql-database-point-in-time-restore/
I have the following set up:
Azure service
Azure SQL database
Azure Table Storage
Azure Blob Storage
I am trying to develop a backup strategy for this service.
The thing is, that SQL, Tables and BLOBs should be synced. In the backup all three of those have to be of the same version. (backups taken at the same moment). And the main problem is - I can only afford several minutes downtime, not more than that.
What should I do? May be there is existing solution?
Windows Azure Storage supports geo-replication for Blobs, Tables and Queues. Data in the storage account is made durable by replicating transactions across different storage nodes in the same region (LRS) or a secondary region (GRS). GRS is the default redundancy option when creating a storage account. Refer to http://blogs.msdn.com/b/windowsazurestorage/archive/2013/12/11/introducing-read-access-geo-replicated-storage-ra-grs-for-windows-azure-storage.aspx for more details.
If you want to build a custom backup solution then you could use the techniques suggested in the below 2 blogs
1) http://blogs.msdn.com/b/windowsazurestorage/archive/2010/04/30/protecting-your-blobs-against-application-errors.aspx
2) http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/03/protecting-your-tables-against-application-errors.aspx
I am not sure of the exact use case of why you need to backup azure table and blob. You can backup All the above services without downtime; might be there would be slight glitch or bottleneck performance with SQL database durning back.
The single shot answer is to write a custom script which would read the data from azure table ( or SQL database, or the required service ) make a archive (packaging) and store it back.
The important thing to note here is where would storage backups, broadly speaking generally store the archives in blob. In this case you have thing where you would be storing, if you are storing on-premises you need calculate upon the storage locally, out bandwidth cost and latency of the data transfer from azure.
PS : cloud storage by itself has good leave of availability and durability, you further improve these factors by enabling geo-replication
I read in a few places that SQL Azure data is automatically replicated and the Azure platform provides redundant copies of the data, Therefore SQL Server high availability features such as database mirroring and failover cluster aren't needed.
Has anyone got a chance to investigate deeper into this? Are all those availability enhancements really not needed in Azure? Thanks!
To clarify, I'm talking about SQL as a service and not a VM hosted SQL.
The SQL Database service (database-as-a-service) is a multi-tenant database service, and your databases are triple-replicated within the data center, providing durable storage. The service itself, being large-scale, provides high availability (since there are many VMs running the service itself, along with replicated data). Nothing is needed in terms of mirroring or failover clusters. Having said that: If, say, your particular database became unavailable for a period of time, you'll need to consider how you'll handle that situation (perhaps sync'ing to another SQL Database, maybe even in another data center).
If you go with SQL Database (DBaaS), you'll still need to work out your backup strategy, and possibly syncing with another DC (or on-premises database server) for DR purposes.
More info on SQL Database fault tolerance is here.
Your desired detail is probably contained in this MSDN article of Business Continuity and Azure SQL Database (see: http://msdn.microsoft.com/en-us/library/windowsazure/hh852669.aspx). At the most basic level Azure SQL Database will keep three replicas of your database - one primary and two secondary.
While this helps with BCP / DR scenarios you may also wish to investigate ways to backup your database so you have point-in-time restore capabilities. More information on backup / restore can be found here: http://msdn.microsoft.com/en-us/library/windowsazure/jj650016.aspx