It’s late, you’re tired, and all you want is your head to hit the pillow – all DBAs know the feeling. It was a long day to begin with, and just as you drifted off to sleep, your cell phone rings. All of a sudden you need to log back into your datacenter and troubleshoot a critical database that became unresponsive. End users need access to this data before they sit down at their desk in the morning – so sleep isn’t an option.
Ever look at a screen’s output and get that puckered feeling in the pit of your stomach? If you have been working in this profession for any amount of time, you know the feeling I’m talking about. The feeling that makes you think you would rather be living in Montana making woodcarvings at a roadside stand than being a DBA. I’ll be taking a somewhat lighthearted look at the perils of our profession and discuss ways to reduce problem occurrences.
Have you ever built a dimension in SSAS and received a blue informational warning advising you to:
Any business can attest to how important their data is to the functions of their company; without it, everything comes to a halt. But what is sometimes overlooked are the individuals tasked with administering that data and its surrounding environments. In the worst of cases, a business experiences a catastrophic event, like a corrupted server, and slips into panic-mode as no one at the company knows how to correct the issue – or, the sole individual in charge of your databases can’t be reached. Businesses know they can’t afford to have this happen, but:
In effort to clean up database environments, we as DBAs are often asked to either move tables to a different file group or to consolidate multiple filegroups and the number of database files into one. The recommended way of accomplishing this task is to drop and create a clustered index on the new filegroup; however, whenever the clustered index is also a primary key, this process becomes very inefficient and resource-intensive since we have to drop all of the foreign keys, the clustered primary key, and then recreate the clustered primary key and all of its dependencies.
Recently, I had reports from one of my clients that many of their users were experiencing slowness. While investigating, I found the root cause to be a key lookup on a single function execution, completely unrelated to the activities being performed by the users. A key lookup can be a costly operation that requires additional I/O and ultimately negatively impacts performance. As we all know, the disk subsystem is the slowest part of our environments, so eliminating key lookups when you can and decreasing the amount of I/O will have a positive impact on performance.