Tag: administration

  • The Aware DBA

    A long time ago, at least, a long time in the eyes of my kids, I worked for a large organization as a production DBA. We had a generic monitoring tool, but it wasn’t SQL Server specific. I ended up writing my own enhancements for the tool that used its data, as well as gathering other SQL Server specific items into a local database on each instance. From there, I had this data copied to a central location each night and a report generated. This helped us with ISO certification (originally) and later, Sarbanes-Oxley compliance.

    I was reminded of that when I read Pamela Mooney’s post on Things You Should Know About Your Server. She follows the simple method of ensuring each server monitors itself and rolls up that data. This works well, even if I’d never want to do this again. The time I spent building a monitoring system wasn’t really time well spent. These days I’d buy some monitoring software and then query that data, bother the vendor for enhancements and have either a notebook or a smaller set of processes that gathered specific data I might need. Likely I’d use XE and some stored query data, but if I monitor infrastructure, I don’t want to have to worry about building and maintaining monitoring software.

    The main point from Pamela’s post, however, is that she seeks awareness of how the systems work. That’s the key for a successful sysadmin of any system. You should not, and do not want to, check each system every day, but you do want to know how to find out what is “normal” quickly and be aware of changes. We want to quickly narrow down potential and possible problems because of our experience and history with some server/instance/application/etc.

    Most of us get calls on a few systems regularly. We may know those well, but often we’re fire fighting and normal can be an elusive definition. There are often many systems that we rarely get called to examine, but most good DBAs I know have some idea of how almost every system performs. Having a little data available quickly allows us to diagnose whether a problem is real or imaginary, chronic or transient, as well as how to proceed to resolve any issue.

    Awareness is an important skill when dealing with anything on a regular basis in your life. Certainly in parts of life outside of work, but even at work, paying attention and having some idea how how your environment should work will help you catch, diagnose, and solve issues. The best DBAs might do this before the client even calls.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • What’s the Mashup Engine?

    I was testing something the other day and ran sp_who2 on a test instance. I saw this in the program listing:

    2019-04-22 10_52_34-SQLQuery13.sql - Plato_SQL2017.sandbox (PLATO_Steve (57))_ - Microsoft SQL Serve

    I had never seen the Mashup Engine listed in a program list, and I certainly don’t have any program installed by that name.

    Or do I?

    I actually do. It’s embedded in Excel 2016, as part of Power Query. Fellow MVP, Reza Rad, has a good introduction to what this actually is. Apparently it’s the engine that makes it easy for data movement and transformation. Kind of an SSIS light, that’s a part of Power BI as well.

    If you see this on your instance, you’ll know that someone is connecting with another tool. As to which one it is, that might be harder to determine.

  • Enable a Named Instance to Connect on 1433

    My default setup for a few years is to only use named instances, usually with a standard SQL2014 or SQL 2016 as the name of the instance. Recently, I set up a new instance and needed to connect from another machine. I’ve done this lots of times, but in this case, I wanted to both enable TCP/IP as well as move the port.

    This post explains how to get your named instance to listen on 1433.

    First, run the Configuration Manager and check your protocols for the server. You likely see something like this, where TCP/IP is disabled.

    2019-04-15 20_15_55-WS2016 SQL2016 Packt c - VMware Workstation

    Right click TCP/IP and enabled it from the menu.

    2019-04-15 20_16_06-WS2016 SQL2016 Packt c - VMware Workstation

    You’ll have to restart the instance, but wait. Cancel the message that appears. Now open the properties for the TCP/IP service.

    2019-04-15 20_16_29-WS2016 SQL2016 Packt c - VMware Workstation

    At the bottom, there’s an IPAll item. This is likely set for Dynamic ports for your named instance. Remove the 0 and enter 1433 for the TCP Port line. You should get something like this:

    2019-04-15 20_16_52-WS2016 SQL2016 Packt c - VMware Workstation

    When you click OK or Apply, you’ll see this message.

    2019-04-15 20_16_13-WS2016 SQL2016 Packt c - VMware Workstation

    Now restart your database engine service and you should be able to connect over 1433.

  • Changing the Database Collation–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I was testing some changes recently and needed to verify how things worked in a different collation. Here’s the scenario: I had this situation and ran a query.

    2019-02-13 12_22_07-SQLQuery7.sql - Plato_SQL2017.sandbox2 (PLATO_Steve (64))_ - Microsoft SQL Serve

    As you can see, the query rates these two Unicode strings as equal, which makes some sense as this is a Case Insensitive, Accent Sensitive, default US English database.

    I then went to the database properties to change this. When I did so, I picked a case sensitive collation.

    2019-02-13 12_22_55-Database Properties - sandbox2

    I clicked OK, and a few minutes, later I get this:

    2019-02-13 12_25_38-Database Properties - sandbox2

    Hmmm, why is this locked on my workstation? I have a query window open. Changing a collation is potentially a disruptive operation and requires an exclusive lock on the database. This means no other users can be inside the database with a connection.

    The solution? Change the context of my query window. I can change this to master (or any other database) and make the change again.

    While collation isn’t something you often change, if you do find a database that needs this alteration, you will need to drain off any connections before you can make this change.

    SQLNewblogger

    I ran across this while doing testing and realized this was a nice, short piece of information that I should remember. Not because I do this often, but because as I automate changes and use pipelines, I’d need a way to remove all connections before this would deploy.

    An example of a nice short piece of information that I can document about my knowledge, and that might get asked about in an interview.