I’m glad I picked interviewing as the topic of TSQL Tuesday #93, because people wrote posts chock full of great advice and funny stories. Get ready to learn, be amazed, and laugh out loud as you read these posts, which I’ve indexed by the author’s first name. Don’t blame these authors for the dorky jokes in the cartoons, though. That’s all my fault.
Read on for a few dozen interview stories and some of Kendra’s one-liner cartoons.
On July 2017’s event the proposed topic was aimed for all you to share those little secrets that made your tummy burn after pressing F5.
Since early in the morning I’ve been reading your posts which makes me very happy and feel the topic was certainly well accepted by the community.
In order of published date these are the posts that took part in this month’s event.
Click through to see the 17 entries this month.
GUIs are good for….
They give you the option to script out the configurations you have chosen. If my friend had chosen to script out the restore, rather then clicking “OK” to run it, maybe he would have caught this mistake when reviewing it – rather than overwriting the Live database with 2 week old data and spending a weekend in the office with 3 colleagues fixing it.
Plus if you ever want to ensure that you know something, try and script it out from scratch.
Read the whole thing; good thing that totally didn’t happen to Shane and was just his friend!
So years and years ago, when I was in college, one of my favorite classes was Assembly Language. We were working with Mac Assembly in case anyone is interested (yes I used a Mac at school, one of the big ones that had the monitor built into it). Somewhere around week three or four, we were supposed to print something to the screen. I spent several hours (this was only my second programming class so even Hello World was a challenge) and got my program ready to test. It worked! Sort of.
Hello World was written to the top of the screen! Then a second or so later the bottom half of the screen turned into random ASCII garbage. Then a second or so later the computer rebooted. Well, that’s not good. Time to debug!
So the computer comes back up, I take a look, and I don’t have ANY code. I hadn’t saved (and this was long enough ago there was no auto-save). I had to start ALL over again. In the end, I did manage to re-write my code, got it working and even got an A. I also learned that I needed to save my work before running it. Well, learned my lesson for the first time (of many).
I have attempted to put a sanguine spin on this mishap, based on something Phil Factor once wrote: if you throw away (or lose) the code the first time around, the second time you write it, the code will probably be better. This is because the first time you’re writing a set of code, you’re trying to force the pieces together and get the code working; the second time around, you have a working algorithm in mind, so the code will likely be much cleaner.
Remember that myITU was implemented on an Oracle database. Unlike on SQL Server, all tables in an Oracle database are physically represented as heaps, unless explicitly specified otherwise. That means no indexes. And I didn’t know anything about database performance back then, so I didn’t add any. Effectively any query against the course table would give a full table scans in the EnumerationType and EnumerationValue tables as a side effect. Fast forward to course enrolments…
At ITU, we had implemented a selection algorithm, which considered both the study program you were enrolled into as well as how early you registered for a course. Early birds got the course, so students would be ready when course enrolment was opened at 12pm. And at 12.05 myITU would start failing with 500 Internal Server Errors.
This is a pretty common occurrence, followed up by the “let’s add all the indexes” phase.
A couple of times, I’ve had under-performing VMs running SQL Server. As I hadn’t been involved in the configuration, I thought everything had been provisioned properly. Turns out…not so much. Memory reservations, storage configuration, power profiles, all set up for suboptimal performance.
Lesson learned: Ask your VMWare admin if they’ve perused the best practices guide and review things yourself before going down the rabbit hole of SQL Server configuration & query tuning. If the underlying systems aren’t configured well, you’ll spin your wheels for a long time.
Read on for more lessons.
Use SQL to bring down other things in the company
The request was that support wanted to know immediately when an order was placed. No problem, we can add a trigger that populates a table and then we have a job that runs once a minute to email the support group. Sounds reasonable right? Someone decided to do a little testing…. this person created 100,000 entries…. I guess you can imagine what happens next. Yep, the email server was overloaded. We had to quickly delete these rows and truncate the table that was used to send the emails.
Good ol’ eDOS (e-mail Denial of Service) attacks…
We are here to talk about mistakes we used to make. There is one mistake that I am going to discuss and is something that I used to do 10 years ago, obviously I do not do this anymore.
I USED TO SHRINK DATABASES
There, I said it! Why did I do this? Well I never knew any better. Why shouldn’t you do this?
There are situations where a database shrink operation makes sense. Those cases are quite rare.
Thank you to everyone who participated in T-SQL Tuesday #091 which was on databases and DevOps. As I anticipated, this brought out quite a bit of variety on the posts. This is because DevOps is still… not quite cooked…(?) in many peoples minds. I think with the range of posts we saw here, it’ll be a lot more clear to those who are just getting an introduction to it. Here are the posts (in no particular order) and a few comments on each:
Click through to see all the entrants.
Let me be clear about something: If you don’t have your databases in source control, there’s no point in thinking about anything else. Everything else follows on from this point. Getting your code in source control is the absolute starting point of all deployment pipelines. Some people have very strong views about whether to use git or TFS, but frankly I’m less concerned about the SVN of choice and more concerned about whether all code that is deployed is in source control. But the point is there’s no point in fretting about how to use Octopus Deploy if you haven’t got your code in source control.
The morals of this story are to crawl before you walk, and when you do learn to walk, don’t walk on lava. I like the extended Minecraft metaphor, which sets this post off from many others of its ilk.