Presenting – What I’ve Learned

Presenting – What I’ve Learned

So I totally missed the boat on a GREAT T-SQL Tuesday topic – “What’s something you’ve learned while presenting?” But with a twist – something technical, you’ve learned that you didn’t learn. Well, mine is a bit embarrassing… I’ll share that. Also – I totally skimmed the topic and some of the post titles. I made a video as a post about the more general topic of “things I’ve learned through presenting,” but in the professional development sense. Sort of an “encouraging you to go present” sense. I don’t want to waste that video I recorded tonight (on Wednesday, thinking the entire time it was still, you know, Tuesday, about a different topic.)

Clearly – I didn’t learn reading comprehension skills from presenting!!! Anyway, maybe this will encourage you to go submit to speak at your first session. A couple of older blog posts on the topic I wrote are still quite relevant today: Why You Should, How You Should – These are
from 2011. (Before Grammarly, but still, in that weird stream of consciousness style I sometimes write. . .)

A Confession – One Glaring and Obvious Thing Transaction Log Chains and Full Backups

I’ve talked about imposter syndrome before. It’s the stories like this that make it so… I forget when it was – but it was FAR LATER in my career than it should have been. I don’t know where this bad info was “learned” by me – but it was, and it became “gospel truth” to me. Pretty sure it was one of my talks about “I’m a DBA!!! WHERE DO I START!?!??” I was talking about backups. And I talked about log chains and how an out of cycle backup could screw up the log chain. I noticed an eyebrow raise – and then had a question about it. I said I’d research to be 100% sure – but I thought I was. And I did research, and I was wrong. You can take as many non-copy-only full backups or differential backups as you want – you can still restore an earlier full backup and the logs after it and be fine. All those years, I was wrong. And perpetuating a myth – some SQL Server MVP I was!!

So yeah. I learned that because of the audience. I’m sure I’ve learned other things also. Part of presenting is having that dialogue with the audience. You aren’t up there delivering a monologue only – the audience brings experience, knowledge, and great ideas. And you need to be willing to listen, learn, and change. (I still sometimes got stuck in the trap of saying, “well, you can’t do those out-of-cycle fulls because you’ll mess up your log sequence!” only to remind myself or have a colleague raise their eyebrows and make me snap out of it.)

Now you can mess up your differential backups for sure with and out of band full. And if you lose track of which full is which and where they are stored – you could still mess up recovery just because you have a mess of backups running in different ways and different places – but you won’t mess up your log chain just by having an “extra” or “rogue” full backup. As long as you have all of the log backups since the full backup you want to use – you are good. Going to a later diff or full is preferable if you have them; fewer log backups to apply.

A Video – What I’ve Learned (In the Professional Development sense)

So yeah. This was a hastily recorded video while I had time on my hands in a parking lot waiting on my son. And it was totally unrelated to the T-SQL Tuesday event that wasn’t today, since it was Wednesday.

But maybe this will encourage you to speak. I talk about my absolute fright of the prospect of public speaking; the empathy it has taught me; the way it helps me learn the thing I’m presenting about; and the way it’s made me a better consultant (and even a better EMT/Business leader/etc.).

Sharing it because – why waste the electrons I used up recording it in the car tonight. I hope it helps at least one person out there.

A video that has nothing to do with yesterday’s T-SQL Tuesday – but a few things I’ve learned through speaking at events…

Subscribe for Updates

Name

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share This