Voice of the DBA

Tag: Database Weekly

  • Sizing New Servers

    I ran across a post this week from Joe Chang on server sizing. It’s short and talks about some of the issues that you might consider when looking at a single socket v multi-socket systems. What first caught my eye, however, was the opening sentence: “Standardizing on 2 and 4 sockets systems for servers has been an established practice going back to 1996”.

    I think that’s been my experience overall. For most of my early career, we often did purchase 2 or 4 socket systems. A few times I had 8 sockets, but hardware costs and licensing were high. When VMs became the preferred method of building servers, we tended to just ask for 2 or 4 vCPUs. If the system ran slow, we just doubled the vCPUs.

    Time has moved one and hardware has advanced at incredible rates. These days licensing by core has really changed the way that I look at hardware. I couldn’t tell you how many sockets servers have, as I’d likely just ask for a VM with x CPUs (and lots of RAM) allocated. Whether the system was 1, 2, 4, 8, or more sockets wouldn’t be a consideration. In fact, I’ve somewhat given up on trying to track which CPUs have what cores and what the best choice is. I take the simplistic view of a core is a core and the hardware geeks will figure out how to get those into my VM.

    I wonder how many of you actually worry about the hardware in your system beyond gross layout? Do you dig into tracking which CPUs need to be inside a physical box, the type of RAM layout, the drives (beyond size and count)? Or are you like me. Your system is JBOC (just a bunch of cores), JBOR (just a bunch of RAM), and JBOD. If things run slow, after fixing code, I usually JWM (just want more of something).

    Certainly there is a need for someone to pay attention to hardware details, perhaps if for no other reason than to ensure that price/performance is being considered and there are spare parts available. For me, as a data professional, I’ve tended to just look at the performance needed from a system and ask for that. Even in my last position as a DBA, my concern was the SQL Server process and how it worked, limiting my hardware concerns to knowing the CPU count, RAM size, and number of disks. I’ve abstracted away hardware for the most part, focusing on a higher level of the system.

    For those times when I do care about hardware, such as when laptop shopping, a simple query of a few colleagues or a tweet nets me enough information to make a choice. After all, that’s what friends are for.

    Steve Jones

  • Spread the Word about Basic Security

    I went with my daughter the other day to set up her bank account. She’s becoming a young adult and this is one of those items we need to get done, especially in today’s world of electronic banking and money transfers. It’s time she takes another step towards being responsible and accountable for her finances.

    As we went through the process, one of the steps was her setting up an account with the online presence of this bank. I told her to be sure to use a new password, one not in use anywhere. She agreed, but then said she has 3 or 4 passwords that she uses in different places. I told her that’s not enough, and explained why. This week, we have an article about a MySpace security flaw in 2017.

    Most of you don’t use MySpace, but you might have. Even if you haven’t, your kids or parents might use some popular tool, such as Facebook, Snapchat, Instagram, etc. Tomorrow we might discover a similar security issue, or worse, a disclosure of your passwords. If you think it can’t happen, go try a few emails over at https://haveibeenpwned.com. You might be surprised at the results. My kids were.

    It’s not that your bank is necessarily vulnerable to hacking a password. However, if you’ve used the same (or very similar password like PasswordCNNdotcom) for your news reading at CNN, then if that company is hacked, it’s not too difficult to take all emails  and then try PasswordChasedotcom at Chase National Bank’s site.

    Reusing passwords is a bad idea. I do it for demo accounts across virtual machines, and even that bothers me. Everywhere else, I use a password manager and I have hundreds of passwords, separate ones for each site. My wife is annoyed if she needs a password for any of our accounts and I give her something like “4Gbv8A^f8” on my phone, but I’m not going to make simpler ones or reuse them.

    Separate accounts and separate passwords are a mantra I’ve used for years at work and at home. Please spread the word and get those in your life to use separate, strong passwords for their online activities.

    Steve Jones

     

  • Backup Preparations

    I’m sure that many data professionals recognize the importance of having backups in the event of some issue. Many of you will schedule these as soon as you create a database, and then not think much of the process, ignoring it as long as the backup job continues to run.

    As you gain experience, you may even set up backups on new instances and versions without much thought, assuming you know how the process works. That’s probably true of SQL Server, as the backup system and structure hasn’t changed for years. However, do you think backups work the same on other platforms, such as Oracle, PostgreSQL, or MySQL? What about MongoDB or Neo4j? Don’t we just run the backup command to a file and the restore from file sequence if there is an issue?

    Backups aren’t the same on all platforms, and they may function differently enough that you can find you aren’t prepared for a disaster situation. I was considering this over the last week as I read about the challenges of restoring from Azure SQL Database and Amazon RDS. With the popularity of both cloud computing and SQL Server, we have a few different flavors of platforms between on-premises installs, AWS, Azure, and likely other hosted solutions.

    Whenever you work on a new platform, even if it’s a variant of one you have experience working with, there is a chance that the techniques and commands you run to manage backup or restore will change. Since a restore situation is often a stressful event, with the pressure of an RTO upon you, this isn’t the time to learn that your backup preparations are inadequate.

    As much as I might joke about ensuring your resume is up to date in case of a restore problem, I would emphasize that your resume isn’t going to be as helpful if you are negligent and unprepared because you haven’t done everything you could to be ready for a disaster. While your employer might not allocate enough disk space or other resources to ensure their RTO and RPO can be met, you can certainly ensure that your skills, knowledge, and recommendations aren’t the reason that data is lost.

    I periodically practice restores, I’ll take a tail log backup, I’ll ensure that I understand how to export a BACPAC, all to be sure that my skills are up to date. I don’t want to encounter a situation where I need a filegroup, point in time, or striped backup restore and not know what I’m doing. You might want to do the same, taking time every month to ensure that you perform some different restore technique. Just in case disaster strikes next week.

    Steve Jones

  • The Need for DRE

    “Today’s database professionals must be engineers, not administrators”

    That’s a quote from an interview at O’Reilly on Database Reliability Engineering. I don’t want to quibble about whether those of us working in technology are engineers in name or not, but in function, I do think the world is changing to one where we need to do more than be caretakers of systems. We need to be actively involved in ensuring we have very reliable, well-designed systems that use the best practices and patterns of highly available and reliable database systems.

    There is advice to learn and work closer with developers. I like that, and I do think the idea of learning to script and automate tasks is important, perhaps more important all the time, for data professionals. Some of the advice to look towards the quick moving, limited lifetime of many software components today doesn’t make sense. A database, at least some parts of a database, don’t fit within that model. There are valid reasons why a datastore must provide some stability and persistence for an application and won’t fit within a model of multiple systems. Or at least not practically within a model.

    However, there is good advice in the piece to learn more about different types of database services and patterns, and consider other ways of implementing datastores other than a RDBMS. I wouldn’t necessarily abandon a RDBMS for some NoSQL store just because developers think it’s easier, but I would consider whether I actually need to very tight coupling between different parts of the database and complete consistency. I think there are a fair number of domains where a CQRS pattern or some distributed store would work well. The move to microservices might be an enabler for your business if you consider the advantages for OLTP type transactions.

    The flip side of all the power that many stores provide is that many also make reporting and aggregating information more difficult. I would venture that in many cases, a data warehouse (perhaps even a RDBMS-based or columnar store) is necessary, along with the ETL process necessary to keep it up to date. These aren’t simple processes, and take resources to build. For most of us, because we don’t work at extreme scales, I’m not sure it’s worth leaving a relational platform, but I do think that we can learn to evolve and enhance our relational databases faster with DevOps ideas and techniques.

    Steve Jones