Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Would partitioning a SQL Server database across separate page blobs (Azure Data Disks) have a performance impact when querying partition 1 if partition 2 is under heavy load?
I understand the page blobs aren’t necessary separate physical disks, so I’m wondering about the performance.
Context edit: Basically I want to partition old (archive) data away from the live data (so everything over 3 months old) to reduce the database and index size. But this archive data must still be queryable.
This is definitely an “it depends” answer and will take some testing on your part.
The 2012 Scalability Targets show a blob at about 60 MB/sec while the VM sizes show an Extra Large instance gets 800 Mb/sec – the target throughput is obviously dependent on your usage, so you may or may not be able to get close to that figure and if you can, you’re probably saturating your allotted bandwidth so absolutely no point going any further.
I’d be inclined to go with a basic configuration of each database instance getting 1 drive for data, 1 drive for logs. If you still have any headroom on your network then you can look at partitioning further as appropriate.
Alternatively, you could perhaps look at using Data Compression if your issue is with how fast you’re able to retrieve data from the blob underlying your azure drive…