Voice of the DBA

Tag: administration

  • Development, Operations, or Accounting

    These kinds of problems should not happen in the cloud.
    These kinds of problems should not happen in the cloud.

    I think the idea of a platform of services, such as Windows Azure provides, is a great idea. I’d love to be able to stop worrying about hardware in many cases, and even skip some of the infrastructure of networking and managing specific machines. Just having services that I could deploy to that run my database and code, would smooth out some of the hassles of Information Technology in many companies.

    However the services have to work and work well.

    I’ve had concerns with AWS and their outages, though Netflix has run a thriving business on that platform and learned to work within that service. I think the Azure platform is similar, and they’ve had a few outages, I do have concerns over where their outages have occurred. There was an expired certificate, then supposedly maintenance, later revealed to be heat issues.

    These issues bother me. Some are unavoidable, but some aren’t. I’m particularly concerned about the expiration of security certificates. This happened again recently to Azure, and it shouldn’t. I don’t know if this was a problem with the development groups that build applications using certificates, the operations groups that administer systems, or the accounting groups that might need to purchase new certificates, but part of what the “cloud” should bring is expertise and better qualities of service from the people doing the work.

    I can hire semi-competent people that don’t pay attention to details and suffer my own outages. At least then I know I’m to blame and I can replace them. However moving to a service like Azure or AWS means giving up a lot of control. If I can’t count on better services than I get in-house, I’m not sure there are many advantages to moving.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • The Command Shell

    Security holes are all around. Are there any in xp_cmdshell?
    Security holes are all around. Are there any in xp_cmdshell?

    Recently I heard a few people arguing over the use of xp_cmdshell in a particular situation. One person was adamant that there was a security risk in using this feature. Many of you probably feel the same way, and even the SQL Server platform has recognized there could be dangers with this feature and has it disabled by default, as part of the secure by default installation.

    However the security around this procedure has been improved over the years. Non system administrators cannot execute xp_cmdshell by default. Administrators can open up access using a proxy account, but this requires specific configuration changes by administrators. This means that a lot of the danger of using xp_cmdshell for administrative tasks has been removed.

    Or has it? This Friday I wanted to poll you and find out what you think. Many of you are creative in how you use SQL Server and will think of possibilities that many of us would not consider.

    Is there a security risk in allowing xp_cmdshell to be used by members of the sysadmin role?

    I’m not looking for potential issues if a proxy account exists. Instead I’m asking if there are real dangers in allowing administrators to use this tool? I assume you trust your administrators and they will not maliciously use this tool to cause issues in your SQL Server. Let us know how you feel this week.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Toggle Switches

    More toggle switches mean more decisions, but also more control. Are they worth it?
    More toggle switches mean more decisions, but also more control. Are they worth it?

    When SQL Server 7 was released, it was touted as a self-tuning, self optimizing database platform requiring much less attention from a DBA. The product had relatively few tuning options and limited information available about how it processed queries. DBAs were worried about losing their jobs, though as history has shown us, the concerns were overblown. There was plenty of work for DBAs then, and that has continued through the current SQL Server 2012 release.

    However the number of tuning options, and the wealth of information exposed by SQL Server to developers and administrators has grown tremendously over the years. We have DMVs and DMFs, many more tuning options, new hints, isolation levels, and more that enable the DBA to manage SQL Server fairly in a very granular way when they want to do so. From what I understand, there are still less options than other platforms have and often the best advice I seen given from various people is to write more efficient code and let SQL Server still determine the optimal plan for query execution.

    This week, I’m curious how you feel about the tuning and configuration options in SQL Server. The downside of the additional options in other platforms is that there are more choices to make, more DBA decisions, and more administrative overhead in regularly, and constantly tuning these systems.

    Do you want more toggle switches in SQL Server?

    I don’t mean two position switches, like the physical ones used on the Apollo command module, but rather just switches you can use in SQL Server. These could be database or instance level, sp_configure settings, they could be query hints, they could be session options. Do you want more options, or do you think we have a lot to work with already?

    Personally I like the idea that we can change behaviors, but I’d really prefer that the defaults were well set and somewhat self-tuning for most installations.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Customizing SSMS – Bigger Queries

    This is a short series on some customizations in SSMS to make it visually more appealing.

    As a presenter, I’ve learned how to change the way Management Studio (SSMS) looks to make it easier for people to see the screen on a projector. I had wrongly assumed that so many people knew many of these tricks, which is a poor attitude on my part. That should be especially apparent as I saw a presentation recently where the speaker didn’t know how to make things easier to see.

    Here’s another item I saw someone struggle with recently, the query font size.

    The Default View

    When you install SSMS, this is what you often get, and how your queries look:

    ssms_f

    Not easy to read, especially for these old eyes. When someone uses the default settings in SSMS and presents on a big screen, I am usually struggling to see, sometimes even when I sit in the front row.

    Customizing

    You can make SSMS easier to read for yourself in a couple ways. The first is the quickest, but it’s a change for only the current SSMS execution. If you close and re-launch it, things will return back to the previous settings.

    If you look below the query and above the results, there’s a drop down that says 100% in it.

    ssms_g

    If you click that, you’ll get a drop down of some percentages you can choose.

    ssms_h

    These percentages will change the size of the query pane. For example, if I choose 200%, you can see things are much easier to read. The query pane is much better than the results. This is great for quick changes when you are presenting.

    ssms_i

    For permanent changes, this is what I quickly do. Go to the Tools menu at the top of SSMS and select Options. You will get this dialog:

    Capture_002

    I’ve selected “Fonts and Colors” from the left already, but once you do that, there’s a “Size” drop down on the right. Choose that.

    Capture_003

    I usually set that to 14 and it looks good for me. A balance of large size, but still being able to get lots of code on the screen.

    Capture_004

    This make it easier to read your code. In another post I’ll talk about results.