Meme Monday Archives

November 7, 2011

Meme Monday: #SQLFamily

Tom LaRock’s (blog | Twitter) topic for November’s Meme Monday is Write about what #sqlfamily means to you”.

It’s no secret that the SQL Server community is unique in many ways. We are a very visible and vocal bunch. We’re a lot of fun. We will rally around each other in good times and bad. Most of us will help one another be it 2PM or 2AM. Name me many other technical disciplines that have Twitter hash tags, numerous web sites and forums, a ton of bloggers, etc. that genuinely want to help and not want to charge you $200/hr for answering a simple question – you probably can’t. In fact, I see a lot of other folks who are, say, Oracle or Exchange admins wondering where they can get the same level of interaction we have as SQL Server folks.

Kalen Delaney wrote this in her 2011 PASS Summit wrapup:
A couple of them also mentioned how amazed they were that all the “big names” they met were so open and friendly, and it was easy to be included in whatever group activities were taking place. They said they felt no sense of any kind of cliques or exclusive groups among the speakers, non-speakers, and first timers. In other words, it felt like a real community! In reality, there are some cliques and some of the “big names” don’t even get along well with each other, but isn’t that true in any community?

I honestly couldn’t say it better myself. We may be a community, but don’t let that lull you into a false sense of security. Kalen’s last sentence is all too true: we’re not all bestest (sic) buddies – but that’s OK. We’re as functional/dysfunctional as any “normal” family can be, too. Some recent Twitter threads really prove this … but I digress.

Being part of a family is both good and bad. We all have different comfort levels and interactions. I’ll be honest: I’m still reluctantly on Twitter (despite how active I may seem), and I would never be on it if I didn’t feel I needed to be. The SQL Server community is very visible on it, so it makes sense to be on Twitter; it’s almost stupid not to be at this point if you’re involved with SQL. It’s worth it just for #sqlhelp alone. But I still don’t own a smartphone and don’t plan on it.

Despite the amount of public speaking I may do or how out there I may be by my various community activities and interactions, I am a very private person. I absolutely believe in a proverbial separation of church and state – that is, my private and professional life. That’s not to say I don’t consider many in the SQL community friends; I do. But I also think there’s a fine line of people you work with knowing too much about you, too. Everyone has their own comfort level with things like that and may not agree with me, but that’s just the way it is.

Despite me being a bit more laid back and not as out there socially as others, I’m glad the SQL Server community has always welcomed me with open arms and is a large part of why I’m able to do what I do day-to-day. In many ways, I owe a lot of my success to the SQL Server community. I don’t feel like Steve Perry (formerly of the rock band Journey) who famously said in an episode of Behind the Music “I never felt like I was really part of the band” (see about 1:05). Far from it – I’m glad I’m in the band. And oh, I’ll be the bass player 🙂

People know when you’re genuine or full of horse manure. I try to do the best job possible, be it on a client site, blog post, training class, or speaking engagement. It’s always humbling to have someone come up to you at a conference or in a break at a session thanking you for a book, blog, or session from years ago that they were able to use and find helpful. THAT’S why I do what I do, and it’s what makes the SQL Server community great and unique. For the most part, we all try to give back in one way or another within our means. For example, I’m not funded for SQL Saturdays – that all comes out of my own pocket. I pick and choose based on my schedule and cost, but I participate because I want to. That’s what a community, or on this case, #SQLfamily does for each other. And I don’t think those of us that care would want it any other way.

June 7, 2011

Dumb SQL Questions

Meme Monday, started by Thomas LaRock (Twitter | Blog), is an interesting and fun thing. This month, the topic is dumb SQL Server questions. There are a ton, but this week I’m going to focus on three I hear all the time.

Question 1: My Windows/backup guys make a full backup of the system with SQL Server. Isn’t that the same as making a SQL Server backup of the databases?
In most cases, the answer is no. SQL Server is NOT a flat file-based database. While a Windows-level backup of a SQL Server database can be done properly if it interfaces with VDI/VSS, chances are most backup programs won’t handle that or may skip the SQL files since they are in use. Plus, at that point, you would most likely have to attach files – it’s probably not a backup you could use in the traditional RESTORE sense or use transaction log backups with. Some software may do proper SQL Server backups, but you have to ask. Some hardware-based solutions do properly interface with SQL Server, so while out of control of the DBA, can make valid backups that are logged in SQL Server. You would need to check with your vendor.

At the end of the day, as a DBA, you’re responsible for your SLAs, RTOs, and RPOs. A big part of that is ensuring the right backup strategy. Leaving it to your Windows or backup guys could be a potenital excellent career limiting move.

Question 2: Isn’t SQL Server failvoer clustering the same as Oracle RAC?
No, no, a thousand times no. While maybe not a dumb question, it’s the one I hear the most in clustering discussions/talks and it’s clear people don’t do their homework and are making some pretty big assumptions. SQL Server’s failover clustering is built on top of Windows failover clustering. A single server (node) can own a given clustered instance’s resources at a single time. Shared disk is the single point of failure. Scale up is how you would get scalability.

RAC allows you to scale processing, but you still have one copy of the data on disk – single point of failure, and if you have an underpowered storage solution, I don’t care how many processing servers you have – you’re not going to scale if your I/O sucks. Plus, while I know it works, the lock manager Oracle has coded is a complex piece of technology.

Both solutions are not going to necessarily be straightforward to implement. Microsoft has made clustering a lot easier over the years.

At the end of the day – both are valid approaches and are proven technologies.

Question 3: Can’t SQL Server have zero downtime and no data loss?
To achieve zero downtime, if you never patch SQL Server or any other components (including Windows) and never have anything unexpected happen, sure – you can have no interruption in service. Outside of that, no way. Someone recently tweeted they need a maximum of 8 seconds of downtime. That is darn near, if not, impossible. You have to be realistic about your tolerances and what is actually achievable. With the best processes and technologies, you’re looking at anywhere from 30 seconds to a few minutes in a best case scenario.

As for data loss, it’s going to be an “it depends”. If you’re using some kind of synchronous method (i.e. high safety database mirroring), you won’t have data loss for that database since it must be on the mirror as well. But there are complexities – how in your application can you tell where you are at data wise? What happens if your application uses multiple databases – how will you keep them in sync and then tell where they are at data wise?

Failover clustering will always be consistent to the point of failover because the stop and the start means that anything that is incomplete won’t be written will be rolled back due to the recovery process, but you need to account for figuring this out in your application.

Popular Posts

Categories