Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Cloud Barriers

By Tony Davis,

As of July 1st, all data transfers into Microsoft Azure cloud will be free (you still have to pay for transferring data out). It seemed to cause a minor ripple rather than tidal wave of interest.

The potential benefits of moving certain applications and databases to the cloud are well understood and Buck Woody, in particular, has done a good job of mapping out the sort of applications that are amenable to the Cloud. Also, Brent Ozar, back in 2010, also set out, at the business rather than application level, the sort of criteria that might dictate whether the cloud was right for you. The two that caught my eye were 1) "no or very little legacy code" and 2) "no DBAs"

The first one makes a lot of sense. The cloud has particular implications for application architecture in order to avoid latency and other issues. Furthermore, certain restrictions on schema design (all tables must have a clustered index), and lack of support for certain key features (CLR and Full Text Search support are close behind native backup in the queue of most-requested features) may make porting existing database applications difficult.

I blinked twice at the second one though. It may well be true for very basic web applications, but when during his Azure Tech Ed presentation, David Robinson asked for DBAs to show their hands, and said "we really need you guys!", it sounded like he actually meant it.

The issue of throttling is a big one in the MS cloud. Resource usage by your database is monitored and if it's using resources to the extent that it could affect the performance of other databases on the same node, it can and will be throttled. Various resource issues can trigger throttling and David lists many of them: excessive lock usage (>1m locks), excessive transaction log usage (>1 GB of the log), uncommitted transactions (>20% of the log for a single transaction), excessive TempDB usage, excessive memory usage (a session using >16MB for >20secs can be terminated).

They seem like fairly generous limits, but it only takes one rogue transaction to push you up against them, and unless you have a good DBA on hand to keep things under control, you could see wildly unpredictable performance in your cloud application.

I'd like to hear the thoughts of DBAs out there on Windows and SQL Azure, and the prospects of moving applications and databases into the clouds. How many DBAs work for companies that have done it or are seriously considering it? What are the deepest concerns?

Cheers,
Tony.

Total article views: 71 | Views in the last 30 days: 1
 
Related Articles
ARTICLE

Stairway to Transaction Log Management in SQL Server, Level 7: Dealing with Excessive Log Growth

This level will examine the most common problems and forms of mismanagement that lead to excessive g...

ARTICLE

Stairway to Transaction Log Management in SQL Server, Level 7: Dealing with Excessive Log Growth

This level will examine the most common problems and forms of mismanagement that lead to excessive g...

BLOG

Four steps to identify and relocate an application portfolio to the cloud

Large enterprises looking for ways to modernize and migrate a portfolio of business applications to ...

FORUM

transaction log

The transaction log on hosting took an excessive size

ARTICLE

The Cloud

Steve Jones likes the Cloud and gives a few reasons why. He also thinks we'll see more data in the c...

Tags
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones