The New SQL Azure DBA
Compared to SQL Server here is the list of things that you can be completely ignorant about and still be a SQL Azure DBA:
- Hard Drives: You don’t have to purchase hard drives, hot swap them, care about hard drive speed, the number of drives your server will hold, the speed of SANs or motherboard bus, fiber connection, hard drive size. No more SATA vs. SCSI debate. Don’t care about latest solid state drive news. Everything you know about Hard Drives and SQL Server – you don’t need it.
- RAID: How to Implement RAID, choose a RAID type, divide physical drives on a RAID – don’t care. RAID is for hornets now.
- Backup and Restore: You need to know nothing about Back up SQL Server data files, transaction logs, or how the database model effects your backup. You don’t need a backup plan/strategy – nor answer questions the about risk factor for tsunami in Idaho. No tapes, tape swapping, or tape mailing to three locations including a hollowed-out mountain in the Ozarks.
- Replication: You never have to do any type of replication, or even care about the replication. Merge, Snapshot, Transaction Log Shipping, or having a read-only secondary database with a 60 second failover – don’t care.
- SQL Server I/O: You don’t have to worry about physical disk reads/writes or paging, disk access wait time, managing file groups across tables, sizing database file (.mdfs), shrinking your database (you shouldn’t do this on SQL Server anyways), transaction log growth, index fragmentation, knowing anything about the tempdb or how to optimize it, data files (.mdf, .ldf, .ndf), data Compression, or determine and adjust fill factor. None of this is required for a SQL Azure DBA.
- Hardware: You do not have to buy or make a budget for hardware when using SQL Azure. You don’t have to rack hardware, figuring out rail kits, care about cooling, find the right rack screw, creating name labels for servers using the label maker with dead batteries, sucking down water because the data center air conditioning is drying you like beef jerky. No more racks, wires, or KVMs, or redundant power worries.
- Rebooting: There is no driving cross-town for rebooting , 2:00 AM reboot, 3:30 AM rebooting, sleeping in the data center. No f@#!ing Safe Mode.
- Installing Software: No more installing Windows and the 103 critical updates. No more installing SQL Server or careing about how it is installed. No more midnight installations of Windows upgrades and SQL Server patches. Say with me now: “I don’t care how SQL Azure is installed “– first step of a twelve step program for recovering DBAs.
- Licensing: You do not need to understand SQL Server license types. Nor do you care how much RAM SQL Server 2008 standard edition supports in 32-bit mode versus 64-bit mode
- Database Integrity: DBCC anything. Weird huh – how does the database lose integrity? You don’t have to worry about it with SQL Azure.
- Performance Monitor: You will never have to open it with SQL Azure.
- Dynamic Management Views: sys.dm_db_index_physical_stats and sys.dm_io_virtual_file_stats are a couple that you don’t need to know.
Read the first five again (Hard Dives, RAID, Backup, Replication, SQL Server I/O), think of the books you have read and discussions you have had about these topics for SQL Server. Now look behind you; see that young SQL Azure DBA – why isn’t his bookbag weighting him to the ground?
{6230289B-5BEE-409e-932A-2F01FA407A92}
The only thing that worries me from that list is backup. Shouldn't SQL Azure have backup?
ReplyDeleteYou don't have to backup your data the SQL Azure team at Microsoft takes care of this for you.
ReplyDeleteWhat if I'm about to do an app update and want a safety net? What is the story there?
ReplyDeleteThey're working on that...
ReplyDeleteThe notion that, with SQL Azure, "You don’t need a backup plan/strategy", is just plain wrong!!!
ReplyDeleteWe are using SQL Azure. We applied a script, automatically generated by SQL Server Management Studio 2008 R2, to change the data type of a column in a table. The script wasn't compatible with SQL Azure, and used a backup-table / drop-table / recreate-table approach. When run, the only bit that worked properly was the DROP operation!!! Net result: table gone!!!
I rang Microsoft to ask them to get the table back. After 6.5 hours, they told me that they couldn't. The delay suggests to me that they tried but failed.
Your biggest headache when using SQL Azure is backup management. There's no native support for downloading the .bak file from SQL Azure - there are some data sync tools - and some people have had a go at developing freeware solutions - but all of these approaches are unreliable.
To add insult to injury, you are charged for all transfers into and out of SQL Azure. I.e. they charge you money to backup your own data!!!
Anyone migrating to SQL Azure right now would need to consider this issue very carefully. If you don't need the scalability benefits of the Azure environment, you're better off keeping everything in-house for now until they get the tool support sorted.
Great...So all the years of becoming a really talented DBA is now going to be tossed out the Window to host everything in a Microsoft Datacenter? I hope this all winds up going the way of the models of about 10 years ago where Co-Location host companies for Dot Coms turned into Dot Bombs.
ReplyDeleteIf I need scalability, I can do that in-house. The cost benefit might seem great in terms of ROI, but I somehow doubt that this model is a seemless a platform as they are trying to make it sound.