This week, Brent and Richie discuss Azure VM, min server memory, backup solutions, autogrowth in tempdb data files, parameter sniffing, sp_whoisactive, the worst feature in SQL server, why you should never use SQL server for sending or receiving emails, and how many Cubs shirts Richie owns.
You can register to attend next week’s Office Hours, or subscribe to our podcast to listen on the go.
Enjoy the Podcast?
Don’t miss an episode, subscribe via iTunes, Stitcher or RSS.
Leave us a review in iTunes
Office Hours Webcast – 2016-12-28
Should I back up system databases on an Azure VM?
Brent Ozar: Let’s see what we got here for questions. “Should I still be backing up system databases in an Azure VM?” What a great question. I don’t even know if you can. Oh no, I’m thinking Azure SQL DB, of course, in Azure VMs. I have this philosophy that you backup data, not servers. There’s a saying in the cloud, “Treat your servers like cattle, not like pets.” Or as like Richie and I like, to just not have any servers at all. We don’t even like to have cattle. Not that we’re vegetarians, we just don’t like servers up in the cloud. That’s not true. I’m generalizing just to joke here because I know I’m immediately going to get in trouble for saying that. My thing is if something hosed on your system databases, I don’t want to take the time to try to recover that, I just want to failover somewhere else. Maybe that somewhere else means I’m doing log shipping. Maybe it means I’m doing database mirroring. But generally, I don’t want to put anything irreplaceable in the system databases just in case if I lose those VMs.
Is there any advantage to setting min server memory?
Brent Ozar: Next up, Robert says, “Is there any advantage to setting min server memory?” Most people set max server memory and then min server memory there’s kind of some fuzzy questions around. “I’ve been a DBA a long time…” Me too, Robert. “We always leave it at zero with no issues. I realize SQL Server will ramp up to this amount but do I get like a performance boost?” I’m in the same camp that you are, Robert. I just leave it at zero. I’ve never seen a problem that I’ve solved by setting min server memory. The problem with min server memory is SQL Server doesn’t use all of it immediately. SQL Server gradually inches up its memory based on demands. So if you think you’re going to lock down that RAM and nobody else can use it, that’s not how min server memory works. I’ve seen people say, “I want to make sure SQL Server always at least has this much.” Well, I’m the kind of guy that if SQL Server is coming under memory pressure from something, it’s like an app or something that’s starting on the SQL Server and burning memory. I want to find out whenever SQL Server isn’t using the max, that’s usually my bigger concern. Then just immediately alert me on that so I can go track down what app is using that extra memory. But if the app wants to use extra memory, I’d rather have SQL Server up than have Windows crash due to an out of memory exception. So I’m kind of okay with leaving it at zero. If anybody has a problem where setting min server memory has actually fixed the problem—not like made the problem look like it’s not there—but fixed the problem, I’d love to hear about it too, that’d be interesting. I’m always like there’s probably some exception to the rule, I just haven’t hit it yet.
Richie Rump: There’s got to be a reason why it’s there, right?
Brent Ozar: See, that’s one of those things I don’t agree with. I hear people say that all the time for Microsoft. Man, there’s features in that product that should never be there. They’re just a bad idea. Priority boost was the one where it made sense a long, long time ago in weird situations. It should be out of the product now. Auto close and auto shrink, I get it in some ISV situations. But there’s a lot of features that just shouldn’t exist.
Richie Rump: In other words, there’s a reason why it’s there, it just may not be a relevant, current reason why it’s there.
Brent Ozar: Yeah. Just like Julie Citro says, you can still buy candy cigarettes and cigars in some places. That’s true. It’s kind of morphed now. Now it’s an adult joke thing. Now it’s like you get these candy cigarettes and you laugh about them because of what a bad childhood we all had.
Do you like NetBackup for SQL Server?
Brent Ozar: Fellow human says, “Long shot: Do you have any opinions on…?” Boy, do we have opinions. We could go for days on our opinions. “Do you have any opinions on backup solutions, good or bad, from your clients? Specifically, NetBackup for SQL Server.” Man, I’ve heard horror stories about everything.
Richie Rump: First thing I thought—long shot—I’m like, hey, that’s a great X-Men character—Longshot. I really dug Longshot. Longshot was pretty cool.
Brent Ozar: That’s such a good name immediately for a character. What was Longshot’s special power?
Richie Rump: Gosh, I forget. Some energy thingy or other. He was just kind of this cool character, always fought against Mojo. I remember when I was collecting as a kid he was around, but he’s not around anymore. Then I thought long shot and I’m like don’t throw away your shot, because Hamilton is still in my head. So, sorry dude. There’s something else I need to get, maybe a drill, a special Hamilton drill to get it all out.
Brent Ozar: I listen to Adam Savage’s podcast and he was on Hamilton for like six months straight, listening to it on endless repeat. So you got a ways to go.
Richie Rump: Yeah.
Brent Ozar: I would say in terms of backup solutions, I’ve seen so many bad horror stories, even with native backups. It all comes down to the people and process. Do you have regular routines for checking your backups? The horror stories I hear around NetBackup usually involve DBAs saying, “It’s out of my control and I don’t know when it’s going to run the backups.” Like that someone else is managing that for me now. That’s a problem. If you can’t predict when they’re going to happen, you don’t know when they’re going to recover to and you don’t when your server is going to be under performance loads. So generally speaking, I like stuff like NetBackup, TSM, when it takes the backups away from the DBAs to let them focus on something that they love doing and when the people who are taking over the backups have plenty of time on their hands and they can carefully craft backup scenarios. Now otherwise, I kind of just like backing up to a share. Just backup to a file share, let the DBAs manage those backup schedules, and then backup the stuff off the file share.
Should I turn off autogrowth on TempDB?
Brent Ozar: Tempdb data files. Robert says, “It is always a good practice to turn off autogrowth?” I’m one of the weird people who I like to set aside a volume for tempdb, just one volume for tempdb permanently. That’s all it’s going to be for because sooner or later somebody is going to run it out of space and I don’t want it running the whole server out of space or like the OS drive or the user database files. I just like having a tempdb volume. It also usually has different IO patterns than the rest of my databases. Often I’ll use local solid state for that. So with this, I’ll just go ahead and grow out the files to fill out that volume. So say that I have 100 gigs of space on the volume, I’m just going to grow out my tempdb data files to fill it up. If you don’t have that luxury, if you don’t have the luxury of a separate volume just for tempdb, then you may have to leave autogrow on.
Cataract surgery and chitchats
Brent Ozar: Someone says, “I just had cataract surgery. Now I don’t need glasses, it’s the best.” Wow. You know what’s funny—this is going to sound really weird—I always think of cataracts in terms of dogs because I’m so used to being a pet owner and seeing dogs with cataracts.
Richie Rump: Woof, woof.
Brent Ozar: You’re more of a cat guy. I’d expect meow from you.
Richie Rump: Yeah, knowing that I don’t have any dogs, nor have had any dogs and have six cats, yeah, that would be appropriate—but I was more referring to the way you see me. But that’s okay.
Brent Ozar: Oh, loveable pet, drools on the couch sometimes.
Richie Rump: Yeah, I occasionally leave a mess, especially in the cloud.
Brent Ozar: Unconditional love.
How do I call a stored proc on a linked server and populate a temp table?
Brent Ozar: “Using a linked server, when I try to populate a temp table with the exec results I get an error procedure blah blah blah…” What you want to do with this, because he’s got like three sentences in there. Just go post that on Stack Exchange and there’s a few workarounds using OpenQuery and OpenRowSet. I know because I happen to use these all the time. It’s beyond what I can explain quickly in a verbal answer. But OpenQuery and OpenRowSet are tricks that I use to get around building a temp table. If you wanted to see how we use it, open sp_Blitz. Open sp_Blitz and look for the word “OpenQuery,” all one word. I show how I use that to build temp tables, call stored procedures, and populate them into temp tables. Trivial pursuit.
How do I fix a huge transaction log?
Brent Ozar: Next question. “Someone set bulk logged as my recovery model…” First off, I just want to say that Tara Kizer, if she was here, would be proud of you for using the word “model” instead of “mode” because so many people, including yours truly, keep using the word
“mode.” Trying to break that habit. “I have a six-gig database and it has a 330-gig transaction log file.” Oh, sweet potato. Holy… Wow. “If I just set the recovery model to simple, will that commit the transaction so I can shrink the log file or do I have to do a backup of that huge file before I can shrink it?” There’s a couple different questions in here. One is about committing the transaction. The transactions can be committed. It’s just that whenever you’re at either full or bulk logged, SQL Servers is going to keep around that transaction log until you back it up. What you could do, if the business is okay losing point-in-time recovery temporarily, yeah, throw it into simple recovery model. You hear that, Tara? Model. I said it correctly. Throw it into simple recovery model, shrink it to the size that you want, and then turn it back into full or bulk logged, whichever you prefer. But in those full or bulk logged, then you have to start doing transaction log backups.
What’s the worst feature in SQL Server?
Brent Ozar: “What do you think is the worst feature in SQL Server?” Whoa. Worst feature in SQL Server? Query notifications. For me, query notifications sounded amazing when they came out because what your app could do, and I’m so totally not a developer, but what your app could do is it could connect to SQL Server, run a query, and leave the connection open and get a ping back whenever your results changed.
Richie Rump: Oh, cool.
Brent Ozar: This sounds amazing. It sounds like some kind of caching thing. It’s genius. But then here’s the flip of it: your app has to leave the connection open for every query so that suddenly you have a spectacular number of connections open against your SQL Server, all just sitting there waiting to know if anything changed. You multiply that times a whole bunch of app servers and suddenly your SQL Server starts running into connection issues. What people started doing in order to work around that was they would build one query that basically hit all of their tables and got all the databases that they wanted, even just to count * from several different tables to get all the rows in them, so they would know whenever the number of rows change. But of course, the bigger you craft your query, the more notifications you get because people are constantly adding things to tables. So it sounded so awesome and I bet it does solve real pains in specific issues but I’ve just seen enough people get burned by that that I think I would call that the worst one. How about you, Richie?
Richie Rump: Shrink.
Brent Ozar: Oh yeah. Oh, yeah.
Richie Rump: It’s not that it’s bad, it’s just that people don’t know when to use it and you can really screw things up.
Brent Ozar: It’s interesting, people always talk about, “Databases are going to be self-managing. Database administrators are going to be out of a job.” To some extent I think that that’s true, especially when you start moving toward stuff like Azure SQL DB. But Microsoft with every new version gives us interesting new ways to shoot ourselves in the feet and the basic stuff like file size management still isn’t taken care of for you.
Richie Rump: And it’s true in NoSQL as well. You have certain situations where you could really shoot yourself in the foot even though it’s super fast and super everything, things could go kablooey very quickly. When that happens, most of the developers don’t have the knowledge to go in there and figure out what’s going on with this particular work pattern that I’m now thrashing my NoSQL db on. I sat in a session at AWS and they started going into that when DocumentDB starts going awry. I was like, oh, this is good. Then they went off it and I’m like, I need more, come on.
Brent Ozar: I sometimes think about this on the way out here. You wonder if at re:Invent they’re not allowed to tell stories of bad internals or problems just because maybe it’s a marketing conference or an Amazon-owned conference.
Richie Rump: Yeah, but that’s when you get a deeper understanding of the product and how to write your code a little bit differently because you know how the product works. But we’re weird. We’re just strange people. I’m just convinced of that.
Brent Ozar: There are a slew of questions piled up but I have to ask you something just because I’m curious. How many Cub shirts do you own?
Richie Rump: A lot. Let’s just say it’s really increased over the past month or two.
How big should my TempDB log file be?
Brent Ozar: Tempdb setup question. “I’ve got four data files and one log file on one 30-gig drive. I’m not allowed to move it. How much space should I leave for the log file?” I love this question. I actually just divide them evenly because it’s really hard to get a good scientific answer. In this case, if you’ve got four data files—those of you listening to the podcast can’t see me holding up all my fingers, which are also bedazzled and covered in diamonds—that’s not true.
Richie Rump: And pearls.
Brent Ozar: And there’s eggroll juice on there. Four data files and one log file, just divide 30 gigs by five and call it a day.
Brent Ozar: “Is dynamic SQL the best approach to deal with sometimes slow queries due to bad parameter sniffing?” Parameter sniffing is one of those problems that has all kinds of different solutions and there’s no one perfect solution. I’m actually a huge fan of Erland Sommerskog’s epic post—see, we made it 15 minutes before I talked about Erland Sommerskog’s epic post. If you search for “Slow in the App, Fast in SSMS,” Erland has a great rundown of all the different solutions for parameter sniffing and their pros and cons. I keep saying this on every podcast, which has also made me realize I need to write that post. I need to write a post that tells the story a little differently, the way that I want to tell it. Erland’s post is epic but every time I show it to someone they say, “Oh my god, this has a table of contents and it’s 50-pages long.” Can you just give me the TL;DR?
Richie Rump: It’s slow and it’s fast.
Brent Ozar: Option (recompile).
Richie Rump: Yes, option (recompile), will fix it all, man. With some NOLOCKs, you’ll be good.
Brent Ozar: Yes, and NOLOCKs.
When building a 5-year SQL Server plan, what should I consider?
Brent Ozar: “I’m working towards a five-year plan for our SQL infrastructure. What are some big gotchas that you guys usually look out for when planning for the future, apart from constant Microsoft licensing changes?” This is such a good question because I was just having a conversation with Tom Norman. Tom Norman runs the Virtualization Virtual Chapter at PASS. He’s a volunteer who manages a bunch of volunteer presenters who all come in and give different sessions on virtualization. He said, “Hey, you want to talk in 2017?” I said, “I actually don’t have any more virtualization talks. I don’t think virtualization is the future anymore. Virtualization is just the standard.” This is what it is and everybody kind of has to know it. It’s just kind of table stakes. But if I’m looking down further, because like the old Gretzky saying is you want to skate to where the puck is at, this is one of those moments where I feel really sorry for our… [Richie makes hand motions] What?
Richie Rump: The puck is going to be. You want to skate where the puck is going to be, not where the puck is at.
Brent Ozar: Yes, yes. Skate to where the puck is going to be. Now this is one of those moments where I feel really sorry for our transcriptionist. God bless you for typing this, Gretzky is G-R-E-T-Z-K-Y. You want to skate to where the puck is going, which means if I’m looking five years out, for me, it’s one of two things. It’s either cloud—which cloud can either mean infrastructure as a service or platform as a service—or it means containers. Those are the two, and it can mean both. You can totally run containers in the cloud. But five years out, when I plan for a SQL Server infrastructure, I would expect to be some percentage in Google Compute Engine, Amazon Web Services, Microsoft Azure. It’s going to be there. Richie is a great example of this. Richie, as we’re building out applications and we’re building out stuff for the future, when you think about how you’re going to choose where you store data at, what are the things that you think about five years out?
Richie Rump: I’m actually thinking a ton five years out. Is the service going to be up or not? When you’re talking S3 storage, the really question isn’t where we’re going to be five years out, the really question is going to be is my usage, this file, where should it be? Should it be in a database? Should it be in S3? What service would be applicable to that? That’s really more the question than where we’re going to be in five years. If we’re going to say, “We’re going to be in five years in the cloud,” we don’t have the answer for that because they’re constantly changing things in the cloud. We have to build for what is here today, with the exception of we’re in the beta of one of the database products.
Brent Ozar: Aurora.
Richie Rump: Aurora, for Postgres, but that is here. Right? That’s here now because even though we’re in the beta, we could build towards that because we’re using it now. I can’t build towards something that I don’t know where it’s going to be. Storage in the cloud, we could just buy more and that’s that. We’re not using VMs or anything like that so we don’t have to really worry about a lot of that stuff in the cloud. So the questions change in the cloud as opposed to when you’re on prem. They’re different questions that you ask.
Brent Ozar: Capacity management has gotten—both performance capacity and just outright storage capacity—has gotten so much harder in the last six to twelve months because now there’s so many gotchas around what knobs you’re allowed to tune up in the cloud, what knobs you can tune on premises. It’s really fun to watch Argenis Fernandez, he’s a storage guy at Pure Storage. The kinds of things that he talks about, even how the way that you test storage is so rapidly changing, even on premises. The stuff that you can do on premises for storage is so cheap. Intel is now down to $1,000 for a two-terabyte PCI express drive. $1,000 for a two-terabyte drive. Those aren’t desktop class, those are enterprise-grade PCI express drives with sub-millisecond latency. It’s just amazing how fast that is changing and still at the same time, the amount of stuff that people want to shove into the database is just epic, the kind of crap that people want to pour into there for no apparent reason.
Richie Rump: That’s why the question is where should it be? Should it be in the database or should it be somewhere else? Then the question is, is this data going to be accessed frequently or infrequently? That will even choose what data solution that we have, whether that is in Aurora, or in some NoSQL, or in something else. You get so much flexibility in the cloud and not one data platform is going to handle everything because you could very easily spin up another data platform that may handle that one use case better.
Brent Ozar: And six months from now a new option comes out.
Richie Rump: Yeah, and then you’re like dammit, I just got this thing working.
What’s up with user-defined data type security?
Brent Ozar: Fellow human asks, “Why do you have to grant access to user-defined data types? What a weird concept. I asked last week but I wanted Brent’s point of view.” It’s funny, I read that transcript and I didn’t know either. I don’t touch that with a ten-foot pole. The whole security thing is so totally—it’s the one thing that’s in our contracts that we just totally don’t touch. If you want to learn more about what you do is you go grab the book Securing SQL Server by Denny Cherry. I can’t remember if he’s in the third or fourth edition of it but it’s great, brings the subject to life. Has a lot of good stuff.
Brent Ozar: Nathan says, “I have another question. When Microsoft said when using a linked server, setting it up as an open tran, pulls the info back much quicker but it seems to truncate about one percent of the results. Any ideas?” Definitely setup a repro script that you can run every time. If it truncates one percent of the results every time, then go post it on dba.stackexchange.com and you’ll be amazed at the quality of answers you get. I’ve never heard that problem, that’s why I would say go post it. It may totally be real, I’ve just never seen it.
Where can I find all the service packs and CUs?
Brent Ozar: “Is there a database that has all of the SQL Server service packs and CUs?” Yes. Go to sqlserverupdates.com, it lists the most recent ones. I know because I updated it this morning with 2014 service pack 2 cumulative update 3 thanks to an eagle-eyed reader who spotted that it had come out and I’m like okay, screw it, I’m on my Christmas break but why not?
Richie Rump: Hashtag #NeverVacation.
Brent Ozar: #AlwaysAtTheKeyboard.
Richie Rump: Sounds like a good podcast that we probably will never do.
Brent Ozar: When he’s not away from the keyboard.
Have you ever seen an inactive process use 100% CPU?
Brent Ozar: Oh man, lots of good questions this week. Sam asks, “Have you ever had a scenario where an inactive or sleeping process is taking 100 percent CPU? If so, what steps can I use to investigate it further?” I would start with sp_WhoIsActive. Sp_WhoisActive is Adam Machanic’s excellent stored procedure. It has a whole lot of extra parameters that you can call to say what the object has locks on. It will also pull back sleeping SPIDs, all kinds of things. Rollback is another classic example of course too that will use 100 percent CPU just because something is rolling back.
I got this odd DBA interview question…
Brent Ozar: One person says, “I’m going through an interview process for a senior DBA job. I got T-SQL questions with a dataset. The dataset had lots of errors. It had two tons of duplicate records. Was this a test? Should I consider working for this company?” I would ask if they’re hiring for a developer or a DBA position because usually if I’m dealing with bad data that’s something that I hand to Richie. I say, “Richie, you figure out how to make sense of this.”
Richie Rump: Yeah, literally, that’s my gig. As a data developer, T-SQL is my native language. It’s my native tongue. I don’t expect my senior DBAs to understand some of the stuff that I put out. I don’t really want them to be, I want them to be good at hardware. I want them to be good at backups. I want them to be good at finding problems with statistics and things like that and indexes. I don’t really want them to be good at T-SQL. That’s my opinion.
Brent Ozar: We talk about in both of our classes, the Senior DBA and the Performance Tuning class, I start out by laying out the job descriptions of what a DBA is. I break that into production DBA versus development DBA and then database developer. They really are three different roles as you grow your career. When you get started, if it touches SQL Server, you’re expected to know it. But as you mature, especially when you throw the word senior in there, a senior DBA shouldn’t be deduping data. A senior database developer, yes, absolutely. The other thing I would say is before you say, “No, I shouldn’t work for this company,” it’s really hard to do interviews and sometimes people will just google for interview questions because they don’t know what to use and they’ll expect—for example, one of my clients is saying, “I can’t believe that none of my job interview candidates can explain the Halloween Problem.” I’m like, dude, if you called me in cold and asked me to explain the Halloween Problem, I don’t know that I could do it under pressure in an interview either. I just don’t have to deal with that. That’s what the database is for. I can’t tell you how the suspension in my car works internally but I could still—I can’t really do a decent job of driving. But I don’t get into accidents. I haven’t been in accidents.
Richie Rump: That’s what Google is for really, right? Am I here to answer trivia or am I here to manage databases?
Brent Ozar: Why are you here?
Richie Rump: I ask myself every day.
Can SQL Server receive email?
Brent Ozar: I love this question, another ancient history. “SQL used to be able to respond to email. Can SQL Server still send and receive, specifically receive email, using database mail?” Do not do this. SQL Server is the world’s worst email processing software. Just because you can doesn’t mean you should. Go get a finely qualified developer, not like Richie, someone who is actually qualified.
Richie Rump: Yeah, who is good. Then the question is like, how much are you spending for email to process? I mean, holy crap, that must be expensive.
Brent Ozar: Yeah, that’s so so expensive. $7,000 a core Enterprise edition, hideous.
Are XML data types the worst feature?
Brent Ozar: Phil says his vote for the worst feature is the XML data types. I don’t know. I’m kind of mixed about this. I don’t like storing XML in the database. That’s the wrong place for a relational database but I have seen clients where they do need to dump an XML blob in there and they need to query on specific keys and XML indexes were actually really fast. Granted, behind the scenes it’s actually turning your XML into a table and it takes a buttload of space—that’s a scientific metric. Angie asked me one time, “What is an actual buttload?” I’m like that’s true, you can’t actually store that much in your butt. But a buttload, we usually think of it as a large thing. XML data types do make sense in those. I’m not as big of fan on JSON in the database.
Richie Rump: Okay, it’s the same, right? I mean, it’s the same mechanisms here. So JSON versus XML, it’s just different formats but the same underneath mechanisms. So why would you be okay with one versus the other?
Brent Ozar: Because they didn’t do indexes the way that they did with XML.
Richie Rump: Oh, okay. So the next version when they do do the indexes correctly, then you’ll be okay with it?
Brent Ozar: I bet they will because developers want that feature so bad.
Richie Rump: Again, it’s one of those things like, yeah, on the cover as a data developer and an architect, yeah, I kind of agree with you. But again, there’s certain things that you can—in the cloud it’s different—XML, I’m going to shred that off in S3 and I’m done with it. On prem, maybe there’s a case where I may be able to put that in SQL Server and occasionally use it. Yeah, that may be okay. It’s been helpful in some cases. Just look at sp_Blitz and stuff.
Brent Ozar: Yeah, that’s true, sp_BlitzCache especially. Erik Darling has done some wonderful work shredding XML in sp_BlitzCache.
Richie Rump: Yeah, he can’t close his eyelids anymore. It’s pretty amazing.
“Should DBAs learn NoSQL and Hadoop?”
Brent Ozar: We’ll take one last question. There’s so many good ones this week I’m actually going to take the questions from this and do a whole separate blogpost because there’s so many good questions this week that we’re not going to get to. Michella asks—and I wonder if that’s how you pronounce your name—Michella. Because I have a friend of mine who is Mikella and writes kind of the same way. Again, our poor transcriptionist, “How do I type the differences?” Mikella is M-I-K.
“Do you think that we database administrators should start learning NoSQL and Hadoop for the future?” I think if you’re a technical data professional, you should follow the things that you love. Follow the apps, the servers, if there’s something that you go, “Wow, this is amazing. I really want to learn more about this,” you can make a living with almost any product or technology. If you’re passionate about it, it will not seem like work. There’s that cheesy quote, “Do what you love and you’ll never work a day in your life.” That’s totally not true but it will seem like you’re working less. If you love NoSQL, go for that. If you love Hadoop, go for that. But don’t think that as a database administrator you need to know how those technologies work. Even as a consultant, my best value is just to recognize patterns and say, “Here’s where you should be using a NoSQL solution, and if so, here’s the one that I would recommend. Here’s where you should be doing processing in Hadoop rather than doing some kind of scale out processing in SQL Server.” But am I the guy to implement that? Not no, but hell no.
Richie Rump: Yeah, I always do like the C-level test. Can I hold a conversation about that technology at a C-level executive, mainly a technical C-level, like a CIO or CTO. That’s the type of information that I want to be at, maybe a little bit more so I can add a little more value, but at least so I could have that conversation with that C-level executive. That’s the levels that I always kind of want to be at with the newer technology and the stuff happening around the periphery. Now if it’s something that’s really cool, I’m really excited about, then I’m going to jump on in and do that but with Hadoop and NoSQL and all the flavors thereof, you probably are going to be wasting your time unless you want your next job to be in those technologies.
Brent Ozar: When Postgres started catching on in the SQL Server community three, four, or five years ago, I installed it on my Mac, I did Aqua Data Studio, or whatever it was that I was using as a frontend at the time. I played around with it and I’m like, yeah, it’s a database. That’s cool. And then I’m like what am I going do with it?
Richie Rump: Yep.
Brent Ozar: If I can’t personally get on it every day then I don’t really want to dig deeply into it. I want to play with it just to see: Does it work? How does it work? What kind of problems do they face? Same thing with MySQL, I dabble in MySQL just to see how it works but as soon as I realized every time I dip my toes into something else, MySQL, Postgres, ElastiCache, Elasticsearch, all kinds, DynamoDB, I’m like, man, SQL Server is amazing. Our developer tool [inaudible] is fantastic. Management Studio should be sainted, it’s incredible.
Richie Rump: It’s so true. You’re using Postgres and you’re like, “I’ve got to use this crap? What the hell is this?” I mean, damn, this is like command line versus Siri. This is just so manual. It’s like oh, crap.
Brent Ozar: I’m a real designer-y look and feel kind of guy—says the guy with the Apple Watch and all that kind of stuff and the Mac with the Touch Bar, but I come back from using other tools, from using Postgres tools, from using MySQL tools, I come back to SQL Server and I’m like this is just—Management Studio is beautiful, it’s gorgeous. Yeah, sure, it doesn’t look like an Apple product but in terms of the database world, we are some of the luckiest database professionals out there.
Richie Rump: Yeah, I agree wholeheartedly. It’s the same thing with Visual Studio, how I feel about Visual Studio.
Brent Ozar: Yes.
Richie Rump: With its debugging capability and remote debugging and all this other crazy stuff. Once you get it going, it really works really well. I’m starting to feel the same way about Code knowing that I’ve been using a lot of JavaScript and Node and that’s where I’ve kind of gravitated to is Visual Studio Code. It’s really powerful. There’s a lot of stuff to get into. I was a Sublime user as well, as well as an Atom one too. If you haven’t checked into Visual Studio Code, even just as a text editor or a markdown editor or anything like that, check it out. There’s a lot of cool stuff in there that you could use. Even as a DBA, just looking at text files and scripts and stuff like that, it’s a really powerful tool.
Brent Ozar: It’s always funny, I read Hacker News. It’s a non-Microsoft site for the most part. They’re really big on, “What is the biggest framework of the day?” Rails, Python, whatever. Whenever a Visual Studio post comes up and people have a discussion, the elite hacker guys will be like, “I don’t understand why anybody would ever use that.” There’s immediately a barrage of comments like, “No, seriously, you should check it out. It’s actually pretty good.”
All right, thanks, everybody, for hanging out with us this week. We’ll see you guys next year… dun dun dun. Adios, everybody.
Richie Rump: See ya.
