Voice of the DBA

Tag: Database Weekly

  • The Android Car

    I’ve been a car guy for most of my life, admiring them, owning quite a few (20+), and enjoying lots of time behind the wheel of a vehicle. I’ve been lucky enough to own my dream car for a few years and even had the chance to drive a few unusual cards. While I haven’t driven a Tesla, I have ridden in one when the pedal was mashed to the floorboard (thanks, @GlennAlanBerry). That’s quite an experience, and one I’d recommend if you don’t have heart issues.

    This week I ran across a note that Volvo’s spin-off brand, Polestar, was unveiling an all electric car. This is their answer to a changing world where it seems every manufacturer wants to combat Tesla with an electric version of something. I might consider the Porsche Macan in an all electric version at some point, but the Polestar 2 is interesting for a reason besides the electric drive train. It’s the first production car that is build around Google’s Android system as the operating system for the car. There are entertainment systems using Android Auto, but this is a step higher.

    What I find interesting, and perhaps disturbing, is this move to more electronic integration for our vehicles, and the potential for issues if the operating system fails. I already think that we’ve built a few too many integrations in mechanical cars at times, where we can’t easily open doors, tow cars, or more if the electrical system fails. While I trust a plane or ship more because they are better maintained by mechanics, I worry about the durability and potential issues with updates for cars that are in daily use by users that might not take the best car of them. After all, people drive every day with small mechanical issues. I worry what this will mean for autos.

    There’s also the trust that we must have in both Google and Volvo to ensure that security is tight, patches are extremely well tested, and perhaps just as important, our privacy is respected. Google already gathers lots of data about us; do we want to give them more about how lifestyle? Will they sell data to insurance companies or others? I don’t know what other data might be captured, but I do worry that there are issues I haven’t considered, especially around security. Maybe even more disconcerting might be the charges for keys, updates, and more that will get added onto already expensive vehicles. What if systems become locked down to the point that only vendor mechanics can work on them?

    I like the idea of better designed and more efficient vehicles, and think that all electric is the future. This despite my longing for a manual transmission in my next car. However, I’m not quite sure I’m ready to trust a phone operating system to run lots of parts of my car. Already I think there ought to be open-source, embedded systems for any mechanical control  and security features that are completely separate from entertainment, without any access to the outside world. While I like DevOps and innovative software, what I worry about is the focus from many companies on features and costs, and not on security and quality.

    Steve Jones

  • The Pros and Cons of Terabyte Phones

    A few years ago I wrote a piece about the growth of storage in many devices and the large quantities of data that can be kept. I speculated that we might see terabyte mobile phone storage in a decade. That was 2014 and this past week Samsung announced they had created a 1TB embedded Universal Flash Storage chip for phones. You can already get a Note9 with 512GB of storage, so this isn’t a huge leap, but it does feel like a milestone.

    For many of us, that seems like a good move. We can keep all the photos, videos, movies, and more that we want on our phones. I take a lot of pictures in life, and lately I’ve struggled with a 32GB phone. I keep debating upgrading, just because I’d like more storage. There are certainly challenges with keeping all this imagery and video backed up, but that’s a separate discussion. I’d like to just be able to capture data and make decisions about how to protect it later. There are also plenty of transient items (movies, Pluralsight courses, and more) that I just want to keep on temporary storage for a limited time.

    More is better, but it also creates potential problems. With a 1TB, or potentially larger, storage on my phone, what about the problem of data loss and theft by insiders? Very few of us work in jobs where we can’t keep our mobile device with us. Many of us also work with sensitive data, and there is a potential for transferring a lot of data to a relatively innocuous device. These days we might not even need to plug in our mobiles with bluetooth file transfer programs. Even if we plug in a phone, that’s innocent and expected? Modern smartphones often need charging during the day.

    It’s not just us, but also contractors, consultants, and non-privileged users that might be able to move data. Certainly someone might act maliciously, but what about the potential for new types of malware? Android is more open and iOS, and there have been viruses. How long before there are some virus programs that try to connect to every SQL Server, Oracle, MySQL, etc. database when plugged into your laptop?

    That might seem far fetched, and certainly our databases grow larger and larger, but much of the data is text, and more ERP/CRM programs are in use that contain known schemas where worms, virii, and other malware might target specific tables. A terabyte can store a lot of text data, especially if it’s usernames and password hashes.

    I don’t know of any mobile to PC infections yet, but I do know there are lots of smart people out there. It’s just a matter of time before someone starts to try and exploit the capabilities of modern mobile devices, especially those with large storage capacities.

    Steve Jones

  • Evolving Our Tools

    This week the next preview version of SSMS v18 was released. This is the sixth preview release, and I’m guessing that this will be one of the last. Six seems like a lot of releases, and I’d like to think that this is getting close to being ready to use by most people, but I’m not sure. I certainly have some some annoying and problematic bugs, so I can’t be sure there won’t be a seventh, eighth, or ninth preview, but it does seem to be fewer issues are being reported.

    With the release of SQL Server 2016, SSMS was decoupled from the database engine, and we saw some SSMS v16 releases. I didn’t use many of those before moving to SSMS v17, which came slightly after SQL Server 2017. I’m glad we’ll start to get the versions separate from the engine as this is confusing to many people. However, I do expect that plenty of people will call this SSMS 2019 or think there’s a SQL Server 2018, etc. If we could get more people to leave the older SSMS versions that came with 2008 R2, 2012, 2014, then I’ll take a little confusion in how we talk about SSMS.

    However, we don’t need to stick with SSMS these days. If you’ve been heads down and just focused on keeping your existing systems running, you might not realize that not only do we have different SSMS choices, but we also have other tools. I’m not talking about SQLCMD, bcp, and Visual Studio, but we have other ways of working with SQL Server. Visual Studio Code has an mssql extension if you write code in that IDE, which might be something you full stack developers need.

    For the SQL Server people, we have a fork of VS Code in Azure Data Studio. This is a lighterweight IDE built for SQL Server work. We also have the mssql-cli tool, giving us way more control over command line work than we have with SQLCMD. I haven’t worked with it much, but it’s on my list for January to play with a bit. I don’t know how well either of these will catch on, but let me know your thoughts. Are you doing more work with either of these tools?

    There are certainly plenty of other choices as well. My company (Redgate) and others make plugins for SSMS that improve how you work with SQL Server. There are even other IDEs, such as DataGrip, that you can use and abandon the Microsoft tools altogether. I’m not sure I would look to leave SSMS entirely, but perhaps I should give some of these a try at some point.

    Tools matter to many professionals. Mechanics treasure their sets of wrenches, chefs love their knives, and we ought to have tools that we know, use, and are comfortable with. This includes both the actual software and the various scripts, code, and helper applications that allow us to work efficiently. If you don’t love your tools, or have a collection, maybe now is the time to start the new year building some skills with the one you use, or try a new one. Wayne Sheffield has a nice series on SSMS and I’m hoping to get some other pieces written for other tools. If you want to tackle one for SQLServerCentral, let me know.

    If you’re looking for a new tool to try for SQL Server work, might I suggest some PoSh and dbatools. It’s an amazing combination for lots of tasks.

    Steve Jones

  • The Worst Data Breech

    I noticed this week that Australia passed a law that requires companies to hand over user information, even if encrypted. Quite a few articles that point out this might require backdoors to be created in communication systems to comply with the law. Companies are required to provide plain text user communication if they can, or build tools to allow this if they do not have the capability. The proponents of the bill argue this is necessary for criminal prosecution.

    Perhaps they are right, but if this capability is required, this means that either companies will have backdoors built into their products that allow them to decrypt things you might have expected to remain encrypted. That’s disconcerting to me, not because Apple, Google, or someone else might read my communications, but because no company has really proven they can protect all the data they store.

    Can you imagine how many malicious actors might spent their efforts trying to find those backdoor encryption keys? What if there aren’t backdoor keys, but companies decide to build some sort of key logger into software that copies data before it’s encrypted. Can you imagine how problematic it might be to secure that data?

    I’m also concerned because this would mean that there could be a few keys that can be used to get access to encrypted data, something like “master keys” in door locks. In this case, the loss of a key might mean problems for huge numbers of people. The other option would be lots of backdoor keys, potentially a different one for each customer/device, in which case we have a large data set that I’m sure will get leaked. At that time, how likely will it be that we’ll be able to implement new keys for large numbers of people?

    I sympathize with law enforcement. In some ways, their jobs are much harder. In others, however, I think they have many more tools, and the need to weaken encryption doesn’t seem to be necessary. Many of us have a need to secure data, to protect it from unauthorized access. At a time when security is proving to be a challenge and record numbers of data breeches are occurring, do we really want tech companies to start building products with less security? I don’t.

    Steve Jones