Sometimes, usually when I’m editing video, I see myself do something silly. Today was one of those times, and these two bloopers, kind of a spur of the moment thing while I was recording, came out funny.
My son thought this was pretty funny as well.
What skills don’t you get taught about being a good database developer? If you are like most people, there is a whole list of things that are good practices for writing code, but you weren’t aware of. And like most people, you might be confused about what things you ought to start learning because of the huge amount of advice from people that are sure “their” way of building software is the best way.
I ran across a great article that tackles this subject, and talks about a few fairly critical things that many developers don’t learn. Or maybe they learn them, but don’t believe they provide benefits (like version control). It’s amazing how often I find developers, and DBAs, reinventing some process, or struggling through the same tasks over and over because they haven’t bothered to build a repeatable process.
The best quote in the article is this one: Setting up a staging server should be easy. If it is not easy, you already have a problem in your infrastructure…” It’s absolutely true, and if you don’t think this is an issue for your company, I have two words for you.
Disaster recovery.
A staging server is the equivalent of setting up your system again in a DR scenario. If that’s not easy, then the likelihood of you doing it in a timely, efficient, and acceptable-to-your-boss manner in an emergency is pretty low.
Do yourself a favor at get a staging/QA/UA server set up in your environment. In today’s multi-code, hypervisor-ridden technology shop, there’s no good excuse not to.
Steve Jones
(published at http://www.sqlservercentral.com/articles/Editorial/72413/)
It’s that time of the month again, and this month Pat Wright and his SQL Asylum are hosting the T-SQL Tuesday #15 party.
If you want to learn more about the party, read Adam Machanic’s intro post (Blog|Twitter). If you’re interested in hosting from your blog, contact Adam.
I have worked in a number of different sized environments in my career. From single server, 3 person companies, to 1 many-hundred instance, 12,000 person organization. Surprisingly in most cases, the size of the DBA team hasn’t varied tremendously. While it’s often been just me at smaller organizations, at the largest company we only had 3 DBAs to manage hundreds of SQL Server instances.
How did we do it? You probably know: automation.
In every environment I’ve worked, my goal has been to be insurance for when things break. That means that all the routine tasks need to be handle by someone or something else. Preferably by SQL Server itself since it’s usually more reliable at the tedious routine tasks.
In the past, mostly SQL Server 2000 and before, I heavily used custom scripts, an administrative database on each instance, SQL Mail, and SQL Server Agent to perform regular maintenance activities, monitor jobs and processes, and summarize the results for the DBAs. My goal in all automation is to log the things that did happen, and only alert the DBA for items that need his or her attention.
When SQL Server 2008 was being developer, and new features were being introduced, I was pleased to see that a number of changes were made that I thought would help make automation easier. Policy Based Management, and the Powershell links to SMO objects, along with the new XEvents, Change Data Capture, the Data Collector, and more, there are many more hooks and ways to use automation to manage and monitor your SQL Server.
However there also is a tremendous amount of complexity in using these tools. PBM sounds easy, but once you start creating policies, you can easily end up with hundreds of policies that result in an environment that is harder to understand.
The ultimate goal in automation is to handle tasks in a more efficient way, using code and scheduling applications. This should result in less work for the DBA, but it also means that the DBA might count on certain tasks being completed, which might not get done.
No matter what method you choose for implementing automation, you need to ensure you have some independent scripts and checks running to check on your automated tasks. An independent set of automation checks should be available to ensure your tasks run when scheduled, and they perform the tasks that are needed. While you might have a job to defragment indexes, you might have a second job that checks the fragmentation levels and independently notifies the DBA if the levels get too high.
You also need to distill information down to the essence of what is important for the DBA as well. Too much routine information dulls the DBA’s senses, and makes it harder for them to find out what is broken in their environment. While all actions need to be logged to analysis and auditing, only those actions truly requiring the DBA’s attention should be raised on a regular basis.
This sounds like very general advice, without a lot of detail, but the reality is that the balance to strike here will change with each environment. Usually I have had to spend months slowly tuning my automation and monitoring until I eliminate notification of the routine items, and only get notified of the critical “fires”.
Which means that I don’t need a notification every day. The lack of a “look at this” note is hard for many DBAs, myself included, to get used to.
The last piece of advice for implementing automation is this. Don’t try to account for every situation in your system. It results in too many code branches, and too complex an automated system. Handle the 80% of routine tasks and let the 20% anomalies fall through to the DBAs. It means a simpler system to build, and maintain.
You have a job and realize that you’re in over your head. Perhaps you misled a manager that couldn’t really evaluate your technical skills, or maybe you memorized enough answers from Books Online to get through in interview. It could be that you took a test during the interview and used your cell phone to post the questions on SQLServerCentral and someone gave you the answers.
Now you have been given a project and you don’t have the skills to complete it. You can’t ask for training or consulting help since you should know this stuff. What do you do now? Should you continue to deceive your boss and ask for free help on the Internet? Can you muddle through it and hope that you don’t do anything that causes damage to the company?
It’s a tough spot. I realize that you have bills, obligations, perhaps a family to take care of. Losing your job could impact other peoples’ lives. However my advice would be to be honest with your boss. Let him or her know that you need help, and move forward from this point.
No matter what your skill level, you should be making an effort to grow your skills. You should be taking advantage of any help given to you by others to learn more. If you are making an effort, learning to close the gap between your skills and your claims of knowledge, you should be fine. Your boss will be more understanding of you asking for help than he will be if your efforts fail and your deceit is uncovered. Most people are willing to give others second chances, especially when they are working to make amends.
If you’re just coasting, and happy to ask others to write your queries and not improving yourself, then good luck. At some point you will be exposed, and likely fired. And you would deserve it.
Steve Jones
(originally published at http://www.sqlservercentral.com/articles/Editorial/72367/)
Voice of the DBA 