Category: Editorial

  • Yet Another Database

    The “yet another” moniker is used throughout technology. YAAF, YARN, YAML, and more ways that people talk about yet another way to solve some problem or build a platform. That’s one of the amazing things about technology is that we, as a group, are not satisfied with the way things are done. Someone is constantly looking to find a better solution and advance our technology choices in a new direction.

    In the database world, we’ve seen changes as well. Relational databases were the obvious, or perhaps just dominant, choice for most of my career. At some point I saw object databases, XML databases, then streaming databases, none of which gained much popularity. The last few years have seen document databases, graph databases, key value databases, and more. We categorize databases as row-store or column-stores now. There are probably other types I’m forgetting.

    There are also categorizations of OLTP, OLAP, operational, ODS, data warehouses (DW), etc. that people use. I ran across a piece called “Why you need another database“, whose opening line is “Do you really need yet another database?” The answer is, sure, you need an analytical database, but I think the piece is a bit behind the times. Lots of people have built an analytic database in the form of a relational DW, an SSAS cube, or perhaps some other type of NoSQL store (Hadoop is popular) that allows complex querying of data away from the operational, every day OLTP system.

    I would guess many of you have some separate reporting copy of data that allows analysis separately from your online system. This could be a copy of your production database, a data warehouse receiving regular loads, a read-only AG replica, or something else. Some of you might perform analysis in your primary OLTP system, with enough spare capacity to handle the reporting load.

    There are multiple ways in which you may decide to implement an analytical database, but I do agree that most businesses ought to have some way of analyzing the data they collect. The questions in the piece (structure, size, analytics), are good ones, and no matter what your platform, architecture, or technology, make sure that you build something that meets the needs of your organization as a whole, not just the technologists that prefer one platform over another.

    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 2016 Home Lab

    Everyone needs a home lab. At least, everyone that works in technology and wants to grow their career or get better at their craft. I’d hope that’s most of you, but if not, that’s fine. If you’re happy with just cruising along at work, I wish you the best.

    For many people, especially those wanting to learn, they need some lab. There are plenty of free software choices you can make to build a lab. SQL Server, SSMS, Visual Studio Code, Virtual Box, you can get these for free. The thing you’ll need to provide is the hardware. From my own experience, to learn about many features, you’ll want at least 2-3 VMs, or instances that can run different versions, provide some separation, and even a spare instance when you blow one up. If you want to experiment with the AlwaysOn technologies, you might want 4 or 5 spaces. You can do lots of this in Azure, but many people don’t want to commit, or have open ended costs. Or they don’t want to eat up bandwidth.

    I’m not a hardware geek, and honestly don’t care what I run. It just needs to go fast and work well. I rebuilt my desktop, on advice from Glenn Berry, but I just followed advice. I didn’t try to determine if part A was slightly better or worse than part B. I just needed the SSD/MB/CPU/etc. to work.

    I’m sure plenty of you might be considering a lab, or might need to upgrade. I ran across two great posts that give you a few ideas on what might work for you. Allan Hirt showcases a great portable lab, which I may adopt as a traveling companion. However, if you want another desktop that might run a slew of VMs for experimenting with SQL Server features, Glenn Berry from SQLskills has his own post that you can use for advice.

    If you’ve got recommendations or ideas, or questions, please add them to the discussion. If you’re proud of your own setup, let us know. If you have found Azure (or AWS) to be a friendly, cost-effective place for a lab, I’m sure people would love to know that as well.

    Steve Jones

     

  • Developer Deployment Frustrations

    This editorial was originally published on Sept 7, 2012. It is being re-published as Steve is at DevConnections.

    Why don’t developers like SQL Server? Probably a few reasons, but I’m sure this is one that really frustrates them. I found a Connect Item that was titled:  Why is Deploying SQL Server 2008 R2 sooooo FRUSTRATING?!!  There really is a question there, asking for guidance on  which versions of SQL Server are available and recommended for developers to include in their applications.

    When SQL Server MSDE was released, it seemed that Microsoft was looking for it to be included in small applications that might then be upsized to a Standard or Enterprise edition of SQL Server. It seems to me that this is really the market for Express (the evolution of MSDE) and that it ought to be simple for a developer to not only deploy this with their application, but also setup basic maintenance easily.

    I sometimes think that the software developers at Microsoft get lost in their own specialty and forget just how frustrating it can be for the rest of us trying to use their product in new ways. They forget that many of us want to deploy simple solutions easily, and not spend a lot of time working out the nuances of software setup.

    I’d like to see Express not only have a very simple setup that works across multiple versions of Visual Studio, but also baic maintenance plans built in that allow full and log backups (if needed), along with index rebuilds with a simple switch set as a part of setup. A few registry keys or XML config changes could set paths or frequencies.

    Making life simpler for developers is a worthwhile investment for the SQL Server team. It makes them more likely to include it in their applications. If you can add a one-switch replication to sync to a Standard or Enterprise SQL Server, they might think Express is required in every application.

    Steve Jones

     

  • DBA Support

    This editorial was originally published on Oct 28, 2012. It is being republished as Steve is out of the office.

    There was a time when I managed two production databases on SQL Server. Two. I had a development version of one database where we paused development for testing, and only two production databases to manage. Since I had to also handle development, application support and hardware repair/replacement, that seemed like plenty to me. I was the accidental DBA, with database administration being the lowest priority of my day.

    After that I moved on to administer databases in a number of jobs, sometimes as a priority, sometimes not, but in each case, I learned to work more efficiently and effectively. My goal was to automate as much as possible of the routine work so that I could spend my days adding value to the company. I learned to use scripts, alerts, jobs, and more to keep systems running while I was doing other work.

    I’m sure many of you work in a similar manner, or at least I hope you do. This Friday I wanted to ask you at what scale do you need to become efficient, based on the size of your organization. The question this week is:

    How many databases does each DBA in your organization manage?

    I know some of you manage lots of databases in raw numbers, but also let us know if you need to do much with these databases. Is maintenance automated, or is there much active management you need to do in order to ensure these databases are running on a weekly basis. Let us know the size of your load as well, perhaps the amount of data is a better way of measuring the DBA load.

    Steve Jones