none
Changing DB Parameters RRS feed

  • Question

  • SQL Azure uses a multi-tenanted architecture... Of course, most web-services are multi-tenanted at some level, aren't they? So at what level does SQL Azure implement this model? For example, I have created a 10GB DB on XYZ server. Am I sharing server XYZ with multiple users, or is it exclusively instantiated for me (so that I may be able change some parameters, such as the query cache size, and the like)? Any extra info on this concept in SQL Azure will be appreciated!

    Also, I must really say you guys have done a great job of SQL Azure. Looking forward to new features!!!
    Tuesday, December 29, 2009 4:14 AM

All replies

  • Hello, you're not sharing server XYZ with other users. Your server is hosted on a seperate VM, but several VMs may be hosted on the same physical machine. However, you are not allowed to modify most of the server configurations. For example, the sp_configure procedure is not supported, which means most of the system paramters cannot be altered. One benifit you get from a cloud database is we do the administration for you. So as a developer, you can focus on your application instead of concern about DBA jobs.
    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, December 29, 2009 7:19 AM
  • Hi Yi-Lun,

    Thanks for the reply... It was very precise! Okay, just a few more queries -- correct me if I'm wrong:

    -- I create a server using the SQL Azure web interface. 
    -- Internally, a separate VM is instantiated, and the requested server is run on that VM.
    -- Although several VMs may be running on the same hardware platform, the particular VM running my server is exclusive for my use.

    Does the server scale dynamically? If so, is there an upper limit to this scaling (in terms of CPU cycles used, not storage)? If there are no limits, aren't you guys planning to charge users based on CPU usage?

    I kinda feel like a nosy kid who just doesn't stop with the questions!!! :) Anyway, thanks a lot for your help!!!
    Tuesday, December 29, 2009 11:00 AM
  • Well, I confirmed with our product team that actually we do not have VMs, or at least you don't need to care about how the databases are deployed. That is, compared to Windows Azure, SQL Azure has an extra abstraction layer. You don't need to concern about CPU and memory usage. What you get is logical databases on shared nodes. But the databases are isolated from each other. Currently there's no limit on scaling. But we do not charge you for CPU usage. Only storage and data transfer are charged.
    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, December 30, 2009 4:44 AM
  • Hi... Now I'm confused!

    To tell you the truth, I really need to understand the technical differences between Amazon RDS and SQL Azure... With just two significant products out there, it can still be so difficult to choose!

    Initially, on the outset, I felt that Amazon RDS had more features, and gave users more control over their DB. Y'know, us geeks would do anything to 'customize' things our way! :)

    So, unlimited scaling... and that too dynamic (it's not like I'd  have to restart my DB instance or something of the sort, right?) -- 1 up to SQL Azure!! This is awesome news.

    Logical databases on shared nodes -- hmmm, interesting. By databases, are you're not referring to the DB server I presume? In that case, my original speculation was more or less accurate -- You have several nodes --> each node hosts multiple databases which may belong to several different users.... Right?

    Wednesday, December 30, 2009 5:22 AM
  • SQL Azure doesn't have a concept of instance. You can purchase multiple servers, but they're logical containers instead of SQL Server instances as you find in on-premises SQL Server. You don't need to care about how the servers are deployed (and we're not releasing any specific deployment information to the public at this time).

    Your data is automatically backuped, and will automatically be restored when disaster occurs. This is what we call high availability.

    As for scalability, we will scale the database automatically according to the network traffic. But more traffics means you need to pay more. So it doesn't mean that scalability comes for free in SQL Azure (Data transfers = $0.10 in / $0.15 out / GB - ($0.30 in / $0.45 out / GB in Asia)). Unlike Windows Azure, you still need to pay for traffics occur between the same data center in SQL Azure. For example, if your Windows Azure application and SQL Azure application are hosted in the same data center, you're required to pay for the requrests your Windows Azure application makes to SQL Azure.

    You will need to purchase for more than 1 server if you exceed the storage quota.
    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Yi-Lun Luo Monday, January 4, 2010 10:25 AM
    • Unmarked as answer by Tony Petrossian Wednesday, June 9, 2010 6:56 AM
    Thursday, December 31, 2009 8:57 AM
  • Correction above: Traffics occur between the same data center are always free. For example, if a Windows Azure application queries a SQL Azure database in the same data center, you won't be charged for network bandwidth.
    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, June 9, 2010 7:14 AM
  • As for scalability, we will scale the database automatically according to the network traffic. But more traffics means you need to pay more. So it doesn't mean that scalability comes for free in SQL Azure (Data transfers = $0.10 in / $0.15 out / GB - ($0.30 in / $0.45 out / GB in Asia)). Unlike Windows Azure, you still need to pay for traffics occur between the same data center in SQL Azure. For example, if your Windows Azure application and SQL Azure application are hosted in the same data center, you're required to pay for the requrests your Windows Azure application makes to SQL Azure.

    You will need to purchase for more than 1 server if you exceed the storage quota.
    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.


    Some corrections:

    (1) We dont provide "autmatic scaling". What we provide is automatic failover in case the node hosting your database is under stress. And this failover is transparent to your application. We wil failover to one of the replica's which are on a separate physical node.

    (2) There is no bandwidth charges for traffic within the same datacenter.

    (3) SQL Azure server is not a physical SQL Server instance. Its a logical container for a group of SQL Azure databases which are partitions inside a SQL Server database. So there is no performance benefit to creating multiple SQL Azure servers. You can create as many databases as you want and scale out and take advantage of the elasticity and flexibility of the platform. Each database you create will most likely be created on a physically separate node so you get the advantage of more physical resources for your database. There can be business reasons to create multiple SQL Azure servers such as separate billing unit etc.

    (4) The SQL Azure database you create is not shared with anyone except you and your authorized users. The database containing your SQL Azure DB can be shared with other users.. however your partition is completely isolated from them.

    (5) As for comparison to Amazon RDS check this article thas has a comprison of the major cloud offerings - http://highscalability.com/blog/2010/5/26/end-to-end-performance-study-of-cloud-services.html

    hopefully that clears up some things..

    Wednesday, June 9, 2010 5:24 PM