Is there any way to stop a SQL Azure DB so that it doesn't charge anything towards our account? I don't want to delete it, just while in testing and it's not being used than we set it to "stopped" like we can do with websites, cloud services, and VMs.
As of 10th February, 2023, The answer is No.
They won't allow it. So the billing will continue for your Azure Database starting the day you create it. There really is no way to pause / stop billing for your Azure SQL Database.
Official Source: feedback.azure.com Please add ability to temporarily turn off/on SQL Azure server to pause billing
Microsoft's official answer appears to be "Yes, you can export your database. Delete the Azure SQL database and that will pause billing. Then when you need it you can create a new database and import your previously expored DB."
I don't believe this is acceptable as an answer for "Allow me to temporarily turn off SQL Server to save on my billing"
This is not an option today - the only choice you have is to reduce the size of the Azure SQL Database which will reduce the cost from the next hour of service. If you really don't want to pay for the DB you could backup the DB to blob storage, delete the database and then restore when required. You could orchestrate this using PowerShell or similar.
Update May 2019: There is a new Azure SQL Database "Serverless" tier coming that might meet some of the requirements around reducing costs by not billing when not in use. Official documentation is available to read.
The Azure SQL Database team is happy to announce that there is now an option that may address your request. We just announced a "serverless" option for Azure SQL DB that will pause your database when it is not in use. You can read more about the feature here:
SQL Database Serverless
The databases get backed up automatically just before a drop. so, you can just drop it when you dont need it and restore it when needed.
Restores will take some time depending on the database size and how much log you generated, so it wont be fast for large databases.
Also, there is an expiration policy on how long the backups are retained (depends on the service tier) so just watch out for that.
https://msdn.microsoft.com/en-us/library/azure/jj650016.aspx
Agree with #Shiva answer.
But if you are simply trying out SQL Server on an Azure VM, you would not want to incur charges by accidentally leaving it running over the weekend or weeks. One solution is to use Automatic Shutdown Feature.
This is now possible and the preview feature is public.
Azure SQL Database serverless
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-serverless
Whereas, at this low scale (scale down requirement (pause) rather than scale up), SQL running within a VM might be a better answer for you...
As is it is not supported however there are a few work arounds. It really depends upon how long you want to stop it and how immediately you want it and the size of the database. If it is for a couple hours then it may not worth it because the billing is hourly and you may have round off issues. If days then you can drop it and restore when needed. If weeks then exporting the database and importing when needed is another option. Also you may want to check backup strategy for the edition you choose before preferring export / restore.
The other thing to note is the immediate need vs planned. If immediate, and the db is big then make sure the SLAs in place works for you
You could export the database to Azure storage and Import it when you want to re-enable it, as suggested here:
Temporarily turn off on sql
Here's what I did with my Azure database (4/20/19)
I scaled the database DTUs as low as possible while still reserving up to 250GB, which turns out to be 10 DTUs with an estimated cost of 1.50 per DTU (estimated at $15 per month). To me, that's almost as good as turning it off and on. I can scale it up to 100 DTUs when I want to get more processing and scale it down when I don't. Even at 100 DTUs for a whole month, the cost was only $75.93 last month on my test database.
NOTE: I am NOT using a VM to run a database, just the standard SQL server you get when you create a database in Azure.
Yes you can, with Azure Serverless SQL Database. While your compute resources will be suspended when the database is not in use, you'll definitely save the costs for compute resources, however the billing will continue for storage resources. You can set the inactive timeout for the database after which the compute resources will be suspended. This timeout can be as low as 1 hour.
Read this: https://azure.microsoft.com/en-in/updates/update-to-azure-sql-database-serverless-providing-even-greater-price-optimization/
Elastic PoolIf you have more than one database you can use the Elastic Pool option to bring your total cost down.
Others also mention the option to Drop your database, and rely on restore. That will also work, if you do not leave it deleted for too long...
Related
I am getting ready to create a brand new mobile application that communicates with CosmosDB and I will probably go the serverless way. The serverless way has some little disadvantages compared to the provisioned throughput (eg. only 50GB per container, no Geo-Redundancy, no Multi-region Writes, etc.).
If I need later on to convert my DB to a provisioned throughput one, can I do it somehow?
I know that I can probably use the change-feed and from that (I guess) recreate a new DB from it (provisioned throughput one) but this might open the Pandora's box especially while a mobile app connects to a specific DB.
As Gaurav mentioned, there is no way to change to Provisioned from Serverless plan once you create an account.
You will need to recreate the account with Serverless as type and follow the below ways to migrate the data,
(i) Data Migration Tool - You can easily migrate from one account to another
(ii) ChangeFeed and Restore - push the changes to the new the instance of Azure Cosmos DB
Once you are synced switch back to the new one.
Based on the documentation available here: https://learn.microsoft.com/en-us/azure/cosmos-db/serverless#using-serverless-resources, it is currently not possible to change a Cosmos DB server less account to provisioned throughput.
I have a VM with SQL Server and an application that uses no more than 50 users. I don't require to have a zero downtime application in case my VM or datacenter had an issue, but what I need at least to assure is that I can make the app available again in less than 30 minutes.
First approach: using an Availability Set with 2 VM's won't work actually because my SQL Server lives in the same VM and I don't think Availability Set will take care of the real time replication of my SQL Server data, it will care only about the web application itself and not the persistent data (if I'm wrong please let me know), so having the above statement AV Set is not for me. Also It will be twice expensive because of the 2 VMs.
Second approach: using Recovery Site with disaster recovery I was reading that wont warranty to have a zero data loss, because there is a minimum frequency of replication and I think is 1 hour, so you have to be prepared to deal with 1 hour of data loss and I don't like this.
Third option: Azure Backup for SQL Server VM, this option could work the only downside is that has a RPO of 15 minutes that is not that much, but the problem is that if by some reason the user generates in the app some critical records we wont be able to get them again into the app because the user always destroy everything right away when they register into the app.
Fourth approach: Because I don't really require a zero downtime app, I was thinking on just having the actual VM using 2 premium disks one for SQL Server data files and other for SQL Server logs. In case of a VM failure I will get notified by users inmediately and what I can do is to create a snapshot of OS disk, and SQL premium disks (total of 3) and then create a new VM using these snapshots, so I will get a new working VM maybe in a different region having the exact very last data inserted into SQL before the failure happened.
Of course I guess I will need on top the VM a load balancer so I can just reroute traffic to the new VM. The failed VM i will just kill it and use the new VM as my new system. If fail happens again I just follow same process so this way I just only pay for one VM and not two.
Is this someone has already tried, does this sound reasonable and doable or Im missing a big thing or maybe I wont get what I expect to get?
You better use Azure SQL (PaaS) instead of VM, there are many different options that you can do for your needs. Running SO + SQL in the same VM is not recommended, changing to a Azure SQL (PaaS) you can decrease your hardware for SO VM and configure your SQL for supporting 50 users. Also you can use Load Balancer as you said, either Traffic Manager (https://learn.microsoft.com/pt-br/azure/traffic-manager/traffic-manager-overview) or Application Gateway (https://learn.microsoft.com/pt-br/azure/application-gateway/overview) to route traffic to your SO VM's where the application is running. Depends on your application you can migrate to Azure Web App (https://learn.microsoft.com/en-us/azure/app-service/).
Azure SQL (Paas) you can have less than 30 minutes for sure, I would say almost zero down time although you don't required it.
Automatic backups and Point-in-time restores
https://learn.microsoft.com/pt-br/azure/sql-database/sql-database-automated-backups
Active geo-replication
https://learn.microsoft.com/pt-br/azure/sql-database/sql-database-active-geo-replication
Zone-redundant databases
https://learn.microsoft.com/pt-br/azure/sql-database/sql-database-high-availability
Finally I don't think having Always-on (https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver15) solution is good, once it is expensive and there are only 50 users. That's why I believe you better thinking of a Saas + PaaS solution for your application and database. Your 4th option sounds fine, but you need to create a new VM, configure IP, install SQL, configure SQL and so on to bring up your SQL.
What users is going to do if it happens when you are not available to fix it immediately? Your 30 minutes won't be accomplished :)
Hello I have 14 Databases for Azure SQL with DTU SO, S1 and S4 (prod)
So I am paying for some unused or not frequently used databases.
10 databases for Dev and test. 2 for production.
So I saw one post for Azure elastic pool. It was mentioned with Azure elastic pool. Can somebody suggest which kind database should I put in elastic pool and tips for cost saving.
Also I have Azure storage account (classic). How should I take its backup weekly. Is it possible.
Help and tips will be appreciated.
Thanks
Regards
KP
To keep it simple, Elastic pool will give you number of dtu's which can be used/distributed around number of databases you have as per their need.
So currently if you have 14 databases in S1 tier then you are have 14*50 =700 dtu's , if some databases are not in use, it's possible the dtu's are greatly underutilized.
In this case if You opt for Elastic pool with 50 dtu's then it will distribute among 14 databases , and as per need they will be used. which means you will save more and balance resources.
I have not verified all the numbers I have mentioned, but that's the principle idea.
I will just add to others answers and comments. For backups take in consideration you have Azure automated backups that provides backups with 7-35 days of retention period. Additionally you can use Azure Long-Term Backup Retention which can store backups with a retention period of 10 years.
About choosing the correct pool size to save money one of the documents shared by Nick above states the following: "SQL Database automatically evaluates the historical resource usage of databases in an existing SQL Database server and recommends the appropriate pool configuration in the Azure portal. In addition to the recommendations, a built-in experience estimates the eDTU usage for a custom group of databases on the server. This enables you to do a "what-if" analysis by interactively adding databases to the pool and removing them to get resource usage analysis and sizing advice before committing your changes".
Additionally, "After adding databases to the pool, recommendations are dynamically generated based on the historical usage of the databases you have selected. These recommendations are shown in the eDTU and GB usage chart and in a recommendation banner at the top of the Configure pool page. These recommendations are intended to assist you in creating an elastic pool optimized for your specific databases".
Let's say I have a mydev.database.windows.net Azure SQL Server and Azure SQL DW database for development. And I have a myprod.database.windows.net for prod. If I want to restore prod to dev (cross server) is that possible? From what I can see in the documentation (see the -TargetServerName switch documentation), it is not possible.
Are there recommended workarounds other than scripting out all the objects then using a Polybase CREATE EXTERNAL TABLE AS SELECT command to export all tables to blobs then import those tables with Polybase?
The recommended approach to cross server restores with Azure SQL Database (not DW) is to export to a bacpac file then restore, but I don't believe that's an option for Azure SQL DW right?
I may start creating prod and dev on the same Azure SQL Server (as long as the customer wants both in the same Azure subscription). I would prefer the servers be separate, but ease of restore is important.
This will depend on the frequency and freshness of the restores today. The simplest approach is to restore one of the snapshots we take in the background to support RPO. This is called geo-restore. Snapshots are taken at least every eight hours. However, in practice you will see these taken more frequently. As RPO improves over time so will the frequency of snapshots.
To perform a geo-restore of production into dev you can go to the portal and begin the provisioning process. In the provisioning blade for SQL DW select your dev server. Under select source choose "backup". This will extend the provisioning blade as you will need to then choose the backup you want to use. The rest should be straight forward.
If you need to do this much more frequently or against an "on demand" (i.e. times of your choosing) snap then you would need to build out custom code as you suggest. However, if you are ok to live with our snapshots then the geo-restore would be a good option.
The team are looking for customer feedback on RPO and backup / restore requirements. If you have a business need for more frequent snapshots to support a business case then the team would love to hear from you. Please post this on our user voice feedback channel or reach out to us directly at sqldwfeedback#microsoft.com if business sensitive.
How do I see if an SQL Azure database is being throttled?
I want to see data like: what percentage of time it was throttled, the count of throttles, the top reasons of throttles.
See https://stackoverflow.com/questions/2711868/azure-performance/13091125#13091125
Throttling is the least of your troubles. If you need performance then you would be best served to build your own DB servers using VM roles. I found that the performance of these is vastly improved over SQL Azure. For fault tolerance you can provision a primary and a failover in a different VM in a different region if necessary. Make sure that the DB resides on the local drive.
I don't believe that information is currently available. However, the team does share reasons why you could be throttled and how to handle it (see here).