I have set up a SQL Server 2017 Standard Edition instance and I am experimenting with data compression. One thing I noticed is that the SQL Server uses only one core for compression, which on a large table (>300GB) takes a very long time to complete. Incidentally, a SQL 2014 Dev Edition uses all available cores for the same operation and takes a fraction of the time.
Is this expected behavior?
If yes, is it limited to when the table is compressed the first time i.e. via ALTER TABLE?
Will SQL Server SE only ever use 1 core when inserting and/or extracting data from a compressed table?
(IMHO) This is expected behavior and limitation of Standard Edition.
While some of the Enterprise features been unlocked in SQL Server 2016 SP1, Microsoft intentionally keeps plenty optimizations like multi-core maintenance tasks only in Enterprise edition. Because it simply costs 4x more than Standard.
So companies that really need such grade of functionality have to buy premium offering.
According to this document:
Enterprise edition:
The premium offering, SQL Server Enterprise edition delivers
comprehensive high-end datacenter capabilities with blazing-fast
performance, unlimited virtualization, and end-to-end business
intelligence - enabling high service levels for mission-critical
workloads and end-user access to data insights.
Standard edition:
SQL Server Standard edition delivers basic data management and
business intelligence database for departments and small organizations
to run their applications and supports common development tools for
on-premise and cloud - enabling effective database management with
minimal IT resources.
Similar limitations of Standard Edition:
single core index rebuilt
max 25% of RAM can be used by columnstore
etc etc
I have found out that there's two versions of SQL Server types that are very different in terms of pricing...
The Web version from my host provider costs about 13$ per 2 core packs, whereas the Standard edition is right around 200$.
From my standpoint, we expect our database to be around 150-200GB in size, only few tables would take up most of that space.
So my only concern is would the web version of SQL Server support this large database and not cause any performance issues to the end users?
How different is index rebuilding on Web and Standard version?
Can someone help me out with this?
The differences between web and standard version of SQL Server 2016 are listed here : https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016
Main differences between web and standard are the max memory and max number of cores. Both web and standard version don't have the possibility of online indexing, this is only possible in the enterprise edition.
For a database size having a size of around 200GB, the web edition looks to be ok. But this depends also on the workload of the database, are just some users querying this database or is this database used by thousand of users.
I'm currently running an instance of MS SQL Server 2014 (12.1.4100.1) on a dedicated machine I rent for $270/month with the following specs:
Intel Xeon E5-1660 processor (six physical 3.3ghz cores +
hyperthreading + turbo->3.9ghz)
64 GB registered DDR3 ECC memory
240GB Intel SSD
45000 GB of bandwidth transfer
I've been toying around with Azure SQL Database for a bit now, and have been entertaining the idea of switching over to their platform. I fired up an Azure SQL Database using their P2 Premium pricing tier on a V12 server (just to test things out), and loaded a copy of my existing database (from the dedicated machine).
I ran several sets of queries side-by-side, one against the database on the dedicated machine, and one against the P2 Azure SQL Database. The results were sort of shocking: my dedicated machine outperformed (in terms of execution time) the Azure db by a huge margin each time. Typically, the dedicated db instance would finish in under 1/2 to 1/3 of the time that it took the Azure db to execute.
Now, I understand the many benefits of the Azure platform. It's managed vs. my non-managed setup on the dedicated machine, they have point-in-time restore better than what I have, the firewall is easily configured, there's geo-replication, etc., etc. But I have a database with hundreds of tables with tens to hundreds of millions of records in each table, and sometimes need to query across multiple joins, etc., so performance in terms of execution time really matters. I just find it shocking that a ~$930/month service performs that poorly next to a $270/month dedicated machine rental. I'm still pretty new to SQL as a whole, and very new to servers/etc., but does this not add up to anyone else? Does anyone perhaps have some insight into something I'm missing here, or are those other, "managed" features of Azure SQL Database supposed to make up the difference in price?
Bottom line is I'm beginning to outgrow even my dedicated machine's capabilities, and I had really been hoping that Azure's SQL Database would be a nice, next stepping stone, but unless I'm missing something, it's not. I'm too small of a business still to go out and spend hundreds of thousands on some other platform.
Anyone have any advice on if I'm missing something, or is the performance I'm seeing in line with what you would expect? Do I have any other options that can produce better performance than the dedicated machine I'm running currently, but don't cost in the tens of thousand/month? Is there something I can do (configuration/setting) for my Azure SQL Database that would boost execution time? Again, any help is appreciated.
EDIT: Let me revise my question to maybe make it a little more clear: is what I'm seeing in terms of sheer execution time performance to be expected, where a dedicated server # $270/month is well outperforming Microsoft's Azure SQL DB P2 tier # $930/month? Ignore the other "perks" like managed vs. unmanaged, ignore intended use like Azure being meant for production, etc. I just need to know if I'm missing something with Azure SQL DB, or if I really am supposed to get MUCH better performance out of a single dedicated machine.
(Disclaimer: I work for Microsoft, though not on Azure or SQL Server).
"Azure SQL" isn't equivalent to "SQL Server" - and I personally wish that we did offer a kind of "hosted SQL Server" instead of Azure SQL.
On the surface the two are the same: they're both relational database systems with the power of T-SQL to query them (well, they both, under-the-hood use the same DBMS).
Azure SQL is different in that the idea is that you have two databases: a development database using a local SQL Server (ideally 2012 or later) and a production database on Azure SQL. You (should) never modify the Azure SQL database directly, and indeed you'll find that SSMS does not offer design tools (Table Designer, View Designer, etc) for Azure SQL. Instead, you design and work with your local SQL Server database and create "DACPAC" files (or special "change" XML files, which can be generated by SSDT) which then modify your Azure DB such that it copies your dev DB, a kind of "design replication" system.
Otherwise, as you noticed, Azure SQL offers built-in resiliency, backups, simplified administration, etc.
As for performance, is it possible you were missing indexes or other optimizations? You also might notice slightly higher latency with Azure SQL compared to a local SQL Server, I've seen ping times (from an Azure VM to an Azure SQL host) around 5-10ms, which means you should design your application to be less-chatty or to parallelise data retrieval operations in order to reduce page load times (assuming this is a web-application you're building).
Perf and availability aside, there are several other important factors to consider:
Total cost: your $270 rental cost is only one of many cost factors. Space, power and hvac are other physical costs. Then there's the cost of administration. Think work you have to do each patch Tuesday and when either Windows or SQL Server ships a service pack or cumulative update. Even if you don't test them before rolling out, it still takes time and effort. If you do test, then there's a second machine and duplicating the product instance and workload for test.
Security: there is a LOT written about how bad and dangerous and risky it is to store any data you care about in the cloud. Personally, I've seen way worse implementations and processes on security with local servers (even in banks and federal agencies) than I've seen with any of the major cloud providers (Microsoft, Amazon, Google). It's a lot of work getting things right then even more work keeping them right. Also, you can see and audit their security SLAs (See Azure's at http://azure.microsoft.com/en-us/support/trust-center/).
Scalability: not just raw scalability but the cost and effort to scale. Azure SQL DB recently released the huge P11 edition which has 7x the compute capacity of the P2 you tested with. Scaling up and down is not instantaneous but really easy and reasonably quick. Best part is (for me anyway), it can be bumped to some higher edition when I run large queries or reindex operations then back down again for "normal" loads. This is hard to do with a regular SQL Server on bare metal - either rent/buy a really big box that sits idle 90% of the time or take downtime to move. Slightly easier if in a VM; you can increase memory online but still need to bounce the instance to increase CPU; your Azure SQL DB stays online during scale up/down operations.
There is an alternative from Microsoft to Azure SQL DB:
“Provision a SQL Server virtual machine in Azure”
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-provision-sql-server/
A detailed explanation of the differences between the two offerings: “Understanding Azure SQL Database and SQL Server in Azure VMs”
https://azure.microsoft.com/en-us/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/
One significant difference between your stand alone SQL Server and Azure SQL DB is that with SQL DB you are paying for high levels of availability, which is achieved by running multiple instances on different machines. This would be like renting 4 of your dedicated machines and running them in an AlwaysOn Availability Group, which would change both your cost and performance. However, as you never mentioned availability, I'm guessing this isn't a concern in your scenario. SQL Server in a VM may better match your needs.
SQL DB has built in availability (which can impact performance), point in time restore capability and DR features. You have the option to scale up / down your DB based on your usage to reduce the cost. You can improve your query performance using Global query (shard data). SQl DB manages auto upgrades and patching and greatly improves the manageability story. You may need to pay a little premium for that. Application level caching / evenly distributing the load, downgrading when cold etc. may help improve your database performance and optimize the cost.
I'm not sure whether sql server 2012 developer edition can be installed to a Windows Server 2008/2012 for testing and development purpose. On the other hand, it seems express version has a limitation of 10GB database size, does it mean all databases 10GB, or it can create multiple databases, and each database 10GB?
Thanks,
Joe
First Question
Yes, you can. Have a look at this link http://www.mytechmantra.com/LearnSQLServer/Install-SQL-Server-2012-P1.html
Second Question
It is 10 GB per Database. You can have 10 databases of 10GB size each. Which means 100GBs of Databases.
Not sure about the developer edition, but I suppose yes, it doesn't matters if it's installed on a server or on a developer machine, as long as it's used just for testing and development only and not for real production usage.
About the express edition, the limitation is 10GB per database. You can have as many as you want, whose totaling size can be as big as you want, as long as each one, individually, is smaller than 10GB.
We are finding Azure SQL Database very slow. Its probably about 10x slower than the same spend on a SQL on an Azure VM.
However a VM based solution requires maintenance and backups and im concerned I'll loose the VM and data if something horrible goes wrong.
Thus the SQL Azure solution seems safer to me. So I have two specific questions.
Are you seeing this speed difference and if so is there a solution
Is there any nice solution for ensure the SQL on VM is backed up automatically and offsite.
Azure SQL database is slightly slower than SQL Server on Azure Virtual Machine. However, we didn't find it as slow as 10X. May be you should try Premium tier, which delivers more powerful and predictable performance, in case your database is in some other tier.
Regarding SQL Server on Azure Virtual Machine, there is support available for automated backup and patching. Please visit the below link for more details.
http://azure.microsoft.com/blog/2015/01/29/automated-everything-with-sql-server-on-iaas-vms/
While performance analysis, it is worth checking for ASYNC_NETWORK_IO wait type. Make Sure your client application is deployed close to your database in Azure.