Voice of the DBA

Category: Editorial

  • Don’t Explain Too Much

    sketch
    Leave out the details when communicating with management.

    I was reading a note recently from a DBA working at a software company. Their management wanted to ensure clients had a simple backup solution and were leaning towards Windows OS backup instead of SQL Server backups. They were planning on running databases in simple mode instead of taking transaction log backups, which were seen as too complex. While this can work, I’m not sure this is the type of discussion that should even come up.

    Management should be concerned with the higher level goals. Clients need a simple scripted backup. Period. The implementation of that isn’t something that management should be discussing with developers. This is the perfect example of where the software development goes off the track with micro management. Managers becoming deeply involved in technical decisions and implementations is a sure way to ensure that less than optimal decisions are being made.

    What should happen? Technical developers should get the goals of management (a simple backup process for clients, every day). They should then recommend a solution, but with a minimal of technical details. Managers should have no idea that transaction log backups are being made or a part of the process. Developers should write scripts, tools, or processes that allow an administrator to accomplish a goal in an easy to execute fashion, but shouldn’t need to explain how every detail works to the end user.

    Keep it simple and effective. That’s a mantra that’s worked well for me throughout my career.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Regulators, Mount Up

    Warren G - Regulate
    More auditing of regulation compliance is coming for data professionals working in health care.

    I have an encryption talk that I give and usually find a few people in the audience that have implemented encryption. In almost every case this has been because of PCI or HIPAA regulations that dramatically reduce penalties if data is encrypted. Whether you agree with the regulations or not isn’t important. There are rules that some of us have to follow because of our data and my guess is that the number and scope of those rules will increase in the future, not just in these industries, but others as well.

    If you are covered by HIPAA law, you may have gotten some increased scrutiny this year. There are audits underway from the Office of Civil Rights (OCR) for 115 organizations that will help them to ensure they comply with regulations. Penalties aren’t supposed to be assessed unless there are serious violations, but starting in 2013, the  Health Information Technology for Economic and Clinical Health (HITECH) Act requires that the auditing program will be enforced with surprise audits.

    For those managing health care data, you should be sure that you are complying with HIPAA regulations. If you’re not, you ought to make sure your boss is aware that next year you could have a surprise audit and should be ensuring that you meet the laws regulations. The OCR has released their audit protocol, and you should be sure that you understand what is being evaluated.

    If you aren’t regulated by PCI or HIPAA, you might still check over the protocol as much of it is good practice for securing any data. It can be general, but if you abide by the spirit of the criteria, I’d bet that will pass an audit by your security group.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Targeted Learning

    do not disturb
    Targeted learning means the event isn’t all fun and games.

    I received an email just after I arrived in Seattle for the last SQL in the City 2012 stop. It was from Simon Doubt, who was also coming to Seattle for the PASS Summit, but who hadn’t planned on just attending the conference. Simon had actually come to the Pacific Northwest with a plan: The OLAP Sprint.

    After a few years of attending the Summit and being inspired, taught, and excited by the immersion, it was time to up the ante. The idea was simple, even if the execution would be a challenge. Simon wanted to do more than attend a variety of talks and have interesting conversations. In seven days in Seattle he planned on learning to build an OLAP solution.

    You can read about his journey and it’s an interesting one. It was a success, and while it hasn’t created an OLAP expert, I’m sure that Simon has gained a lot of things from his focused effort. It’s a starting point to learn more. It’s an accomplishment of a fairly difficult task, and it’s a great story that should help a career move forward. This is certainly something I’d put on my resume.

    Throughout the week as I read each entry, I noticed this was a way to tackle the week long conference not as a break from work, but as an exciting new project. The posts showed someone that was taking advantage of the resources at a conference to grow their knowledge and skills. This is a great example of what a plan can do for you, and how you can show your boss that the money spent on this type of training is worthwhile.

    Not everyone will have a plan, and I’d guess most don’t, but the next time you ask for funding think about including a plan of what you are looking to accomplish in a week. Whether you’re attending a conference or an Immersion event, having a plan, with a few specific goals can show that you are using the money you get wisely.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Review Your Indexing

    index cards
    How often do you re-examine your indexes?

    In the latest versions of SQL Server, there are some amazing new features. Many of them allow us to expand the capabilities of SQL Server, but some are added to allow us to dive more deeply into how the system works. A couple of the newer DMVs are fantastic tools to allow us to find indexes that are unused, duplicate, or unneeded. If you’re not using sys.dm_db_index_usage_stats or sys.dm_db_missing_index_details, you should dig into a little and learn how these work. However running a diagnostic query to find unused indexes and then dropping those indexes is a bad idea. You need to ensure that those indexes aren’t rarely, or lightly used.

    I thought about this recently while giving a talk on maintenance. Indexes require routine maintenance, and many of us schedule rebuilds or reorganizes in our databases to ensure that fragmentation doesn’t become an issue. That’s a good start, but there’s more you can do.

    Every month or two you should schedule time to analyze your indexes. Capture a workload from a Trace and analyze it with the Database Tuning Advisor. Take the results and compare them to your current indexing schema. Make a judgement or two on which indexes are used by different queries and spend a few hours testing changes to your systems. You might need new indexes, you might want to remove old indexes that aren’t being used, or you might decide to add a column or include to an existing index.

    There are lots of articles on SQLServerCentral and blogs on indexing that can help you learn more about what changes might improve performance, but ultimately you will really need to test any changes on your own systems. With a little practice, you can build a short routine that allows you to take a few hours every month and analyze a few indexing changes, perform a little testing, and perhaps greatly improve the performance of your applications.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.