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".
Related
At present we have 3 (Dev, QA & Prod) stages in our azure resources. All the three are using SQL Database 'Standard S6: 400 DTUs'. Because of Dev and QA SQL Database our monthly cost is going more than 700 euro's. I am planning to move from DTU to vCore serverless. Below are my queries,
Just going into portal -> Compute and storage -> and changing from DTU to vCore Serverless is the right process?
Do i need to take any other things before doing this operation?
Does my existing Azure SQL DB is going to get affected by this operation?
If things are not fine as per my requirement same way can i come back to DTU mode.
Thanks in advance.
You can have a look at this MS doc for details: Migrate Azure SQL Database from the DTU-based model to the vCore-based model
Just going into portal -> Compute and storage -> and changing from
DTU to vCore Serverless is the right process?
Yes! just change to required option from dropdown and click on Apply.
Migrating a database from the DTU-based purchasing model to the
vCore-based purchasing model is similar to scaling between service
objectives in the Basic, Standard, and Premium service tiers, with
similar duration and a minimal downtime at the end of the migration
process.
Do i need to take any other things before doing this operation?
Some hardware generations may not be available in every region. Check availability under Hardware generations for SQL
Database.
In the vCore model, the supported maximum database size may differ depending on hardware generation. For large databases, check supported
maximum sizes in the vCore model for single
databases
and elastic
pools.
If you have geo-replicated databases, during migration, you don't have
to stop geo-replication, but you must upgrade the secondary database
first, and then upgrade the primary. When downgrading, reverse the
order Also go through the doc once.
Does my existing Azure SQL DB is going to get affected by this
operation?
You can copy any database with a DTU-based compute size to a database
with a vCore-based compute size without restrictions or special
sequencing as long as the target compute size supports the maximum
database size of the source database. Database copy creates a
transactionally consistent snapshot of the data as of a point in time
after the copy operation starts. It doesn't synchronize data between
the source and the target after that point in time.
If things are not fine as per my requirement same way can i come
back to DTU mode.
A database migrated to the vCore-based purchasing model can be
migrated back to the DTU-based purchasing model at any time in the
same fashion, with the exception of databases migrated to the
Hyperscale service tier.
I am new to Azure and we are working on migrating from on-premise to Azure SQL Database.
In the on-premise we have server with 48 cores and 2 TB RAM.
What would be the corresponding configuration on Azure? or How to determine the correct configuration whether to use DTU, vCore (General Purpose/Hyperscale) etc
I have currently chosen a vCore Model with Hyperscale Service tier and instance of 40 vCores.
Any help is appreciated!
This is an incredibly complex question which has far too many facets to be properly answered here. Azure sales support is best qualified to look at your specific technical needs and make suggestions accordingly.
That said, based on your memory needs alone, you are most likely going to be directed toward the M-Series setups rather than the General Purpose.
Single Database:
Elastic Pool:
I would recommend to do the following
Run Data Migration Assistant to validate if the database can in fact migrate to Azure SQL DB
There is an option to assess which tier should your database should go to by capturing data. Then you can use Powershell to convert the data in HTML format
https://learn.microsoft.com/en-us/sql/dma/dma-sku-recommend-sql-db?view=sql-server-ver15
I would not advise going to hyperscale because the performance of Hyperscale is similar to General Purpose as compared to Business Critical. The biggest benefit of Hyperscale is that you can expand database more than 100 TB and add many read replica.
The reason I caution because if you start with General Purpose, you can move it to Business Critical and vice versa. Going to Hyperscale is one way street. You cannot go back!
So I've been getting my feet wet in Azure SQL databases, and one of the question that I can't quite figure out is whether Azure charges per SQL developer on top of the database costs. If there's a team of 5 DB administrators, are they all allowed to build tables/extract data as long as the SQL database pool is being paid for?
It's just confusing because the price is a lot lower than what I'd expect, and I want to make sure I'm not missing any gotcha's that could multiply the cost. How is it possible it's only $606/month for 400 databases with 1TB of total storage?? Am I missing something super obvious??
Seems like we can just add DBA groups to a DB resource group
Pricing calculator for an elastic SQL database pool for 1TB for $606
Also... some additional assumptions and questions (sorry):
-Azure DB bills ONLY on the transactions and storage used in the database
-Elastic pool DB allows for hundreds of DBs to be created for near-zero cost, so does that include backup DBs (Proof of concept/Test/Support DBs)?
How is it possible it's only $606/month for 400 databases with 1TB of total storage??
Under the vCore pricing model that will buy you only a few cores, and a limited amount of RAM. See Resource limits for elastic pools using the vCore-based purchasing model limits for the details. So your 400 databases are sharing a small pool of resources. You may need to scale up the pool based on your workload.
In the General Purpose tier your database files are stored on Azure premium storage, and 1TB of Premium SSD storage costs only $135/month.
Azure DB bills ONLY on the transactions and storage used in the database
Under DTU and VCore models there is no charge for transactions. You've paid for the capacity and may do what you want. Backup storage is extra. See the pricing calculator for details. There are no "charges per SQL developer on top of the database costs".
The price of an elastic pool is based on the number of eDTUs of the pool, if you choose the DTU pricing model. The price of an elastic pool is independent of the number and utilization of the elastic databases within it, the number of transactions, the storage consumed and is also independent of the developers or users using those databases.
If you choose the vCore pricing model, pricing is based on the number of virtual cores, the compute generation you choose (Gen4/Gen5), licensing cost and the storage used by the databases and backups. You can save money if you apply for the Azure Hybrid Benefit or apply to reserve licensing. Again pricing is independent of the number of databases, number of transactions or users using it.
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...
As far as I know the key points to migrate an existing database to SQL Azure are:
Tables has to contain a clustered
index. This is mandatory.
Schema and data migration should be
done through data sync, bulk copy,
or the SQL Azure migration
wizard, but not with the restore option in SSMS.
The .NET code should handle the
transient conditions related with
SQL Azure.
The creation of logins is in the
master database.
Some TSQL features may be not
supported.
And I think that's all, am I right? Am I missing any other consideration before starting a migration?
Kind regards.
Update 2015-08-06
The Web and Business editions are no longer available, they are replaced by Basic, Standard and Premium Tiers.
.CLR Stored Procedure Support is now available
New: SQL Server support for Linked Server and Distributed Queries against Windows Azure SQL Database, more info.
Additional considerations:
Basic tier allows 2 GB
Standard tier allows 250 GB
Premium tier allow 500 GB
The following features are NOT supported:
Distributed Transactions, see feature request on UserVoice
SQL Service broker, see feature request on UserVoice
I'd add in bandwidth considerations (for initial population and on-going bandwidth). This has cost and performance considerations.
Another potential consideration is any long running processes or large transactions that could be subject to SQL Azure's rather cryptic throttling techniques.
Another key area to point out are SQL Jobs. Since SQL Agent is not running, SQL Jobs are not supported.
One way to migrate these jobs are to refactor so that a worker role can kick off these tasks. The content of the job might be moved into a stored procedure to reduce re-architecture. The worker role could then be designed to wake up and run at the appropriate time and kick off the stored procedure.