Voice of the DBA

Tag: Friday Poll

  • The Best DBA Gifts

    It’s a few days after Christmas, which many of us celebrate, though there are certainly other holidays that people enjoy. Whatever your beliefs or tradition, this is a time of year when many of you likely received some gifts for the holiday season. Maybe you got something exciting, maybe something highly desired. Maybe you got a big joint gift for you and your partner. My wife and I used to give ourselves something nice that we’d both enjoy. In the past, we’d gotten new furniture for our bedroom or a big TV.

    The last few years, as my children have become adults, we’ve gone to a family Secret Santa. We have a limit ($40 this year), so I wasn’t expecting anything special, but I am always interested in seeing how creative others are. In the past I got a kid playing guitar and singing a song for me. I’ve also had some creative art projects in the last few years.

    There’s more to the season than gifts, but since many of us are in a slow time over the holidays, I thought I might ask what you wish you would get from work. Today, is there something that would make your job more enjoyable, interesting, exciting, or maybe just bearable in the future.

    You might want equipment, different hours, flex time, more considerate co-workers, better code written or something else. Let us know today, and then maybe think about a plan to convince someone else to help implement it at work. You might find you can get what you want if you ask for it the right way.

    I’ve got a great job, lots of benefits, and I can’t complain about anything. Perhaps the only thing that might make life a little easier next year is a few more article submissions. Maybe one of you out there wants to help me with that gift? I hope so, and I’m happy to help you in any way I can.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • DR Priority

    Those of us that act as DBAs or sysadmins for database systems know that DR is a point of emphasis for us. We usually spend plenty of time ensuring backups are working and practicing restores. The automated scripts and processes that people use are some of the most popular and discussed topics on SQLServerCentral.

    However, we can’t ensure every system is protected at the same level. It’s not cost effective to cluster or build AGs with hot standbys, or even warm standbys, for many databases. Often our organization will ensure some are ready to go and others will have to be dealt with if there are issues.

    William Durkin noticed recently that O’Reilly hadn’t prepared well enough for their learning site. They were affected by the fires and power outages in California and since they host some of their systems in an on-premises data center, there were issues. Certainly we might think they hadn’t prepared well for DR, and perhaps this is a fair view of their service, but perhaps they made the decision not to built out an expensive DR environment for a service that can tolerate some downtime.

    This week, I wonder how some of you look at the systems you support. Perhaps you are the person that has to make decisions, or perhaps your organization doesn’t fund DR well. I’m wondering, how do you decide which systems don’t get enough DR support?

    Certainly there are inexpensive, perhaps crafty ways that some people might plan for DR. I know I’ve cobbled together systems from spare parts to use for testing restores, with the idea that the hardware might need to be an emergency DR server for a single system or two in the event of an incident. If you’ve got ideas on how to be prepared even without organizational support, let us know today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Understanding a Database

    I ran across a post that asked a good question, one which I want to ask you today: how do you learn about a database?

    I’ve run into quite a few databases in my career. Some were third party systems, like Dynamics and JD Edwards World. Some were databases that custom designed and built by developers and database modelers of widely varying skills. Some were well built in order to normalize data and define referential integrity, and other databases were put together in a piecemeal fashion over time, lacking keys and consistent naming. I’ll leave it to you to guess if there were more of the former or the latter.

    When a developer or DBA comes across a database, what’s the way that they can decode what fields and columns mean? Certainly names help at times, especially when the purpose of the database is understood, but all too often the names don’t quite make sense. This is especially true in many vendor databases. The one common theme I’ve seen in many databases is that there is no data dictionary provided by anyone.

    Trying to understand a database has been a trial and error detective task for me in the past. Usually this starts when I need to do some work that is requested by users: write a report, change data, etc. In these cases, I often will ask users to access certain data related to the change from their application while I run Extended Events and note which entities are accessed. I can then start looking for data elements, and note which columns might be mapped to which fields in an application.

    Often I’ve built a data dictionary of sorts outside of the database using something like ErWin, ER/Studio, or another tool. That has been somewhat flawed, as it’s hard to share the information with others. These days I think I’d make extensive use of Extended Properties to document what I learned, so that all my knowledge is available for anyone else that needed to work on the system. They can just look at the properties for various entities.

    If you’ve got other methods, share them with us today. I’m sure there are plenty of DBAs and developers out there that would like some tips and tricks for decoding a database design.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.4MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • The SQL Twilight Zone

    Imagine you’ve just returned from holiday and your data professional world is turned upside down. There’s not a single SQL Server left at work, or maybe there’s no job to work with SQL Server. Now, what do you do?

    I’m hoping that’s not the case for me, as I’m actually writing this a couple weeks ahead of time. When this publishes, I’ll have just returned from a holiday in Hong Kong, which I’m guessing is a completely different reality than the one I normally live and work in. I’m very excited as I’ve ever been, so I likely won’t be refreshed and recharged after a quick, 6 day trip to the other side of the world. Hopefully I slept very little and saw quite a bit.

    In any case, I thought about this recently as I chatted with a few fellow data professionals that had left the SQL Server world behind. They had moved on, some with regrets, some happy, but for all of these individuals, there was no more SQL Server. In today’s SQL twilight zone, imagine that you can’t work with SQL Server any longer, but you do need to keep working.

    On which platform would you want to work?

    Perhaps there’s another platform you work on now, or would like to work on. Maybe you’d want to move away from data and do something else? I’m also curious if some of you would be disappointed or just take a move in stride.

    For me, I am a little torn and I’ve have to think a bit more about what to do. I’ve worked on other platforms in the past, and would be comfortable changing if I had to. My first inclination is to say PostgreSQL, which I’ve always admired a bit. It felt immature back when we started SQLServerCentral, but I liked it better than MySQL. And much better than Oracle or DB/2, especially with the tooling.

    My other choice would be CosmosDB. I think what Microsoft is doing here is fantastic, and while there is work to be done, this is a great way to store some new data. The only concern I would have is are there enough jobs for people that work with CosmosDB? Adoption is growing,  but is it enough to build a career on? I’m not sure. Perhaps, but I’d have to make that decision after more research.

    Let us know today. What platform would you move to, or would you leave databases?

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.3MB) podcast or subscribe to the feed at iTunes and Libsyn.