Voice of the DBA

Tag: Database Weekly

  • Constant Azure Improvement

    This week I noticed a number of changes in the Azure platform from their change feed. Actually, every week has a crazy number of changes across the entire platform, but this week a number of these were related to data and databases. That isn’t always the case, but I saw some interesting items.

    We have zone redundancy for the general purpose tier of Azure SQL database, as well as AAD security principals in the master database and a new DMV for backups. I think Azure SQL Database is a great product, though one that has felt quite limited at times. The use of DTUs at first, the high pause period for Serverless and limited options at lower tiers were always annoying.

    The point at times seemed to be to get customers to place a big financial bet that a higher tier would meet their needs. I had hoped that some of that was just a blip in time as technology improved and more features would be deployed to all tiers. After all, the original Azure SQL database was a key-value store.

    That seems to be coming true as I continue to see improvements to the offerings. Azure SQL Serverless now has a 1 hour pause period minimum instead of the original 6 hour time. Now Cosmos DB has also lowered their autoscale offering. Cosmos DB can be provisioned at a lower entry point for autoscale, at 100RU/s instead of 400RU/s, which might get more people to experiment with a PoC over a bit of time and use the database. I know I’m thinking of trying to mess with some data on the platform. I don’t think I’d need 100 RU/s, much less 400, but I can better live the cost for a few months.

    Hyperscale has been an interesting version of Azure SQL Database. I know quite a few customers that aren’t sure if they need it, but they considered experimenting with it. The problem was that once you choose Hyperscale, you can’t go back to another tier. That’s quite a disincentive to experimentation, which seems to be part of the philosophy of choosing the cloud. There is now a preview of the migration of Hyperscale back to the general purpose tier. I’m guessing it took a little time for the Azure team to implement this, which is why there was a restriction, but it looks like that limit will go away.

    The cloud is an amazing place, as I’ve written before. It enables things to happen at a pace, and with ease that I’ve never seen in a data center without a lot of prep work. This week it seems that the Azure cloud advanced quite a bit in the area that I care about, the data platform space.

    There was also the general availability release of the Azure SQL Migration extension for ADS.

    Steve Jones

  • Would You Want to be on the Red Team?

    In the world of cybersecurity, a red team is a team of hackers that try to infiltrate a company, but at the request of the company. The idea is they look for vulnerabilities and issues and find them before criminal hackers do. They are the opposite of the blue team, who is trying to stop the red team and create defensive measures that prevent the red team from accessing data.

    Many large companies use red teams. Microsoft maintains a red team (and a blue team) that are constantly competing to break into their systems and defend them (depending on which side you are thinking about). I’m sure Amazon, Google, and other large companies do the same thing. It’s an interesting idea, though I bet this is a lot of repetitive work where you constantly repeat similar attacks with slight variations. There certainly is some creativity and research as well, and some acting if you social engineer situations, but it’s not the type of work I would want to do. I doubt it’s as exciting as Hollywood movies portray hacking.

    An organization could assemble a red team from external resources and use them to evaluate the security of your software, your infrastructure,  or even your people. There’s an article this week on getting started with a red team. Since companies are seeing more and more attacks against their systems, I would expect more to be proactive and either assemble or hire someone to test them. In fact, I bet there will be lots of cybersecurity people setting up their own companies to help here.

    Many of us might feel we are careful with security, and that we check for issues. I’m sure we do some of that, and many of us know how to secure things well. However, it’s easy to make a change and make a mistake. It’s easy to forget to include a group, or include the wrong group, in a security ACL. It’s easy to forget to check a setting or leave access open while we test and forget to go back and secure it properly.

    Attackers think differently. We can learn to do this, but it might be helpful to have someone else doing the attacking and then giving us a report on what to fix.

    Steve Jones

  • Reusing Tools for New Purposes

    One of the things you learn early on in programming is that you ought to reuse code whenever possible. This often means refactoring code into functions or methods. This ensures that the code is more easily maintained and that the knowledge and work of solving the problem is reused in many places.
    In database code we don’t do this too often. We certainly can reuse some code by encapsulating it in a view, but this often brings performance penalties. We often don’t want to reuse code in stored procedures and functions as embedding this into queries can cause lots of issues. In fact, it seems that much of the way databases optimize query performance isn’t that amenable to reusing code.

    That being said, I ran into an interesting case recently when thinking about maintenance in the cloud. Someone was asking about SQL Agent and the lack of support for it in many PaaS database systems. I understand that, and while there are some ways to do this, they feel complex compared to using a SQL Agent on a local instance, which is usually easy to set up and readily available. One of the speakers taking questions mentioned that they user shouldn’t forget about Azure Data Factory as an automation agent.

    That caught my attention as I hadn’t thought about it before. This week, there was a blog on that very topic and I read through it to see what I thought. While this isn’t as easy as SQL Agent, it does seem to be easier than Azure Automation, and likely more familiar than elastic jobs.  That’s if you already have ADF running in pipelines. In many ways, this feels like using the maintenance plans in SQL Server, though just the call a stored procedure task. Since many people use a solution like Ola’s, this is very easy to implement.

    I like that this pattern reuses skills and a system that you may already be using, transferring the skills from one area (ETL) to another (administration). This might not seem like much, but limiting the tools and technology, reduces complexity and means that each person needs to know less to support your environment. I’m a fan of code re-use, outside of T-SQL), and I think reusing other technology systems, where appropriate, is a good idea..

    Steve Jones

  • Maybe It Is DNS

    There are jokes about how often DNS is a problem. There are stickers, shirts, and mugs you can buy. There’s a classic haiku, which leads into a rant about the struggles of sysadmins. I will admit that I know a little about DNS, but I find myself confused at times and usually seek assistance from others when something doesn’t work. The old days of a single MX record and a few A records to map names to IPs has grown into a much more complex system.

    DNS usually works. In fact, it’s lower on my list of things to check these days, though I do often get a quick DNS check when I ping an address. There are some failures, and these days when large companies have issues, it can affect a lot of people. Akamai had an issue and knocked off a large chunk of the Internet. When Facebook had an issue recently, it not only affected customers, but the engineers that were trying to fix things. Some couldn’t even get into buildings. I guess relying on a single domain might be a bad idea.

    Most of us rely on DNS in our organizations, which means that a rising level of DNS based attacks is disconcerting. These are still behind the issues we have with ransomware and DDoS attacks, but when DNS doesn’t work, a lot of stuff shuts down. I could see a lot of people that work inside a company’s domain for most of their work being unable to accomplish anything.

    I tend to use a number of domains for my daily work. Evernote and Dropbox are essential, but if one were down, I could still do things with local copies. Red-gate.com is certainly important, but as long as SQL Server Central is up, I can do something different. Actually, if both were down, I could still write or create questions. I’m more bothered by slowness in my connection or machine than losing any particular service.

    I haven’t every been too worried about DNS security, but I left sysadmin work when it was a simpler time. These days, I suspect many organizations might want to be sure they are paying attention. If they use a lot of services connected to one domain, I might think about having a secondary domain connected to a few. If I were in charge, a sqlservercentraladmin.com might be one I’d set up.

    Steve Jones