Just another MEME Monday…
"Google if you don’t know. Get yourself googled if you do."
This is my contribution to Tom LaRock's (blog | twitter) Meme Monday (Write a SQL blog post that tells a story in 11 words or less).
I was tagged by one of my favorite girls, Erin Stellato (blog | twitter). So I'm tagging my favorites as well: Donabel Santos (blog | twitter), David Taylor (blog | twitter), and Karla Landrum (blog | twitter).
Yes, baby! I'm back.
Squilish thought for the day: You are.
I encouraged someone to join the SQL community via Twitter. She asked me what handle she should get. I suggested SQLSuperstar because I knew nobody was using that. She said, "But I'm not yet a superstar". I replied, "Well, SQLChicken's not yet a chicken either". 
Moral: You are who you make yourself to be.
Transactions and oh yeah, that First Kiss…
This is kinda a pain to read. I know, I re-read it before publishing. Well blame it on Tim Ford (blog | twitter) and this challenge. Tim asked, what is a transaction? How do you explain it in a non-technical way? He said "non-technical"...he didn't say "non-cheesy". It ain't easy being cheesy so humor me.
Oh that First Kiss
Yes, that darned first kiss. His name was Ricky, the jerkmy first love. I knew it was eventually going to happen. I daydreamed about it, thought a lot about how to do it, asked my friends about it, and pretty much geeked (researched) my way to it. With all the thinking and feeling I did prior to "the event", the whole kissing thing already seemed and felt so real. But experiences like this cannot be "just" imagined...it's atomic...all or nothing. It either happens or it doesnt.
When he asked me to close my eyes, I thought, OMG, am I really going to do this? And the moment I did, I had that momentous FIRST kiss with that jerk my first love.
Everything else faded. Even the voice inside my head (not mine but my mom's) stopped talking. It was actually happening. Just the two of us. We both reveled in the isolation.
And then it was over. That kiss changed me. I was in a consistent heaven state for a long time. It didn't matter where I really was...in school, at home--I was in heaven.
Years have passed. Boyfriends have come and gone. There've been second, third, fourth and more kisses. But still, nothing beats that first kiss. There's something about FIRSTs that just stays with us no matter what. Some durability that's unique to all our FIRSTs.
Okay, enough. I'm stopping.
Yeah, that was kinda a pain to read huh? Come on, humor me. Aren't you tired too of all those debit-credit bank examples to illustrate transactions??
So, how is this dorky kissing event even remotely related to what a transaction is?
Transactions are atomic.
It's all or nothing. It either commits or aborts. Just like that kiss. It doesn't matter if I practiced with a pillow a thousand times (yeah, looking back, that was disgusting). Until the kiss actually happened, it really actually didn't happen. The kissing plans could be rolled back; the actual kiss? No way.
Transactions are isolated.
There could be a million other events going on while that kiss was happening. There could have been a guy wishing he was in Ricky's place (oh-ho!) but nothing else could mess with that transaction...nobody else could take away that first. That transaction owned me!
Transactions are consistent.
That kiss left me in heaven--and if that's not a logical state to be in--I don't know what is. A kiss that special wouldn't have allowed me to be in an illogical state. Happy, yes. Illogical, no.
Transactions are durable.
Even an earthquake couldn't have stopped that kiss the moment it happened. In the past years, I've experienced a lot…but hey, the first kiss will always be the first kiss. I can't destroy it nor recreate it. I can't pretend that it didn't happen because (thank God) it really did.
Conclusion
No conclusion. I'm already feeling so bad I wrote this. It's (r)ICKY and cheesy...but, hey, it's non-technical! And maybe, just maybe, I made it all up...:D
Ricky, please dont get ahead of yourself. I was really just forcing an analogy. And no, it wasn't THAT good.
Of friendships, backups, and false analogies
Of Friendships
Today is a sad day. I had to say goodbye to a friend. It's funny how common sense sometimes eludes even the smartest among all of us. We have friends who treat us like nulls or defaults and we bear it and pretend it is okay. Common sense says we deserve better but we somehow always remain optimistic that one day, these friends will realize that we are not nullable, or that even if we have defaults, it doesn't mean we don't deserve values.
But optimism doesn't change the rules of the game: we can't "just" alter people.
Of Backups
I had to write something related to backups for work the other day. I attempted to discuss it with my husband who doesn't know anything about databases. If you are a member of the SQL Server community, know that someone who's living with me thinks you're an alien. The things we get excited about are reduced to "stuff", the experts we admire are "oh-those-twitter-people", and next to UFC, we're like UFOs.
Anyway, I still like running things past him especially when I am preparing to explain the same concepts to non-technical people. He nods and says uh-huh in the right moments--so good enough. On good days, he even asks questions. To give him a background, I explained the different types of backups to him. He actually asked, "there's more than one??!" I just ignored him, got a paper, and started explaining. I said...
Imagine a long path from point A to point E.
The goals are
-to get from point A to point D and
-to gather maps so you can revisit any point in the path
In each point, there are maps available: a full map, a diff map, or a tran map. (you want to explain file and filegroup backups? Be my guest.)
1) When you walk to point B, you can get a full map. "Nothing else?", he asked. Yup, nothing else. The full map allows you to go back to point B later. You always start with a full map.
2) When you get to point C, you can get a diff map and a tran map. The diff map will bring you back to the same point you picked it at BUT ONLY if you picked a full map previously. A diff map is useless without a full map. And remember, you can't just use any full map. It has to be a full map taken right before you take the diff map.
The tran map will bring you back to the same point and like the diff map, you can only use it to go back to C later if you picked the full map in B. You can also use the tran map to go anywhere between B and C.
"Can I pick all maps?", he asked. I said yes.
3) When you get to point D, you can again get a diff map and a tran map. This is your second diff map and it will bring you to point D later. "Do I need the other diff map I got in C to go back to D?". I said no. But you do need the full map you got in B. Diff maps always work in partnership with a full map. And as I said, it can't be just any full map. It has to be...he said "yeah, yeah, I know. It has to be a full map taken right before this diff map. Right now, it's the one I took in A". The tran map will allow you to go back to D and in between C and D but---you need the previous tran map (in C) and the full map in B. Or you can use it with the full map in B and the diff map in C.
I asked him if he understood so far. He said kinda. I then showed him backup types as described in MSDN and he read the overview. He said "that's actually simpler. Couldn't you just have said it like that?"
Urgh! My teaching and analogy skills need work!
When we were about to sleep, my husband asked me, "So how was I supposed to go back to the starting point so I can use the maps?" Like a sore loser I replied, "Don't ask me; ask MSDN."
SQL Server MVP Deep Dives: What I learned from Chapter 8
Had I taken the marshmallow test when I was a kid, I'd have failed it. I'd probably pass it now because I hate marshmallows (humor me--I think that counts ). I remember reading Harry Potter and the Deathly Hallows. I was doing so well until I got to Chapter 7. Then the excitement and uncertainty just became unbearable so I went ahead and read the last few pages. Urgh! What a knucklehead, right! Who's crazy enough to do that?? Apparently, me. It ruins the whole reading experience. 
I received my SQL Server MVP Deep Dives book from Amazon yesterday. The book's a collection of short articles written by SQL Server MVPs. Short enough for anyone who doesn't know how to delay gratification. In other words, perfect for me. I read around 5 chapters last night and decided to sleep write about "What makes a bulk insert a minimally logged operation?" by Denis Gobo. I don't want to call this a review because it isn't. Let's just call it a short discussion of what I learned.
1. Why would you want a bulk insert to be minimally logged?
Article says for faster imports which I agree with. It also says "so that your log file could be a fraction of the size of a fully logged operation". Gotta be careful with this one...or before you know it, we'd have another DBA myth. I think the author meant so that the operation would consume less space on the log file--which doesn't necessarily mean that the log file would be smaller. If you have a log file with an initial size of 4GB, whether a set of operations consumes 3GB or 1GB of space, the log file's size would still be 4GB, right? So "your log file could be a fraction of the size" can be a bit misleading.
2. The article discusses the conditions that need to be met for a minimally logged bulk copy to be performed.
The last condition was that the TABLOCK hint must be specified." (I encourage you to get the book if you want to know the other conditions. Some are mentioned here.)
I actually thought this statement was wrong. What is minimally logged in the bulk-logged recovery model? Bulk operations. How are bulk operations logged in the simple recovery model? MINIMALLY too. That's what I knew. So I honestly thought the author probably just meant that the TABLOCK hint would make for more minimal logging. But I executed the sample scripts myself and checked the BOL even. It is how the author says it is. Not only does the recovery model have to be simple or bulk-logged, the TABLOCK hint is required and must be specified. Check out the image below when I tried the example discussed in the article:
All log files that I outlined above have the same file sizes and belong to databases with different recovery models. The same bulk import operation without the TABLOCK hint was executed on the databases. As you can see, without the TABLOCK hint, the recovery model didn't even make a difference.
3. I also checked this: sys.sysfiles. There's a table in the article with a column labeled as "Size in KB" and refers to the size of the corresponding (log) file as selected from sys.sysfiles. Actually, the size field is specifically size in 8-KB pages and not just "Size in KB". It's good to review the small stuff as you encounter them. It makes the learning experience better.
So in closing, I actually learned a lot for just 8 pages. Denis Gobo knows how to simplify concepts to make them easy to understand. And the book? I'm certainly looking forward to reading more. So far, I think it's worth all the hype.