Episode 101: Inspecting a new Database

Episode 101: Inspecting a new Database

Episode 101: Inspecting a new Database 560 420 Carlos L Chacon

Listener Cody Ford wrote in and asked if we could share some thoughts on getting familiar with an unfamiliar database.  While we have done episodes in the past on best practices, this episode takes the approach of what we should look for on a server that is new to us–the components we should document and then review for potential updates.

Do you agree with our list?  Let us know on by leaving a comment on the show notes page.

 Episode Quote

“The foremost one there that I usually look at is backups because things happen and there is going to come a time that you need to use your backup”
“We have to make sure that the mail profile is setup that email can flow out of the system.”
“At the end of the day they can do anything they want and that could be good or bad. So we just want to make sure that… they need to get clearance from us.”
“I think as my experience has been the database diagrams are only as helpful as the culture of your environment.”

Listen to Learn

In this episode, we breakdown the sections or components of how we approach a database or instance that is new to us in the following ways:

1. System Availability
2. Admin Setup
3. Security
4. Dependencies
5. Performance Stats

Carlos: Companeros, welcome to the next hundred. This is Episode 101. It’s going to be back with you guys. We’ve got another great episode. Today’s topic comes from Cody Ford.

Steve: Yes, today’s topic is on understanding an unfamiliar database. And his comment was, “How about a podcast on tips and techniques to understand an unfamiliar database.” Such as viewing and understanding dependencies of tables and viewing or creating database diagrams and any other tips to come up to speed on an unfamiliar database besides the knowledge transfer from other employees because you don’t always have that available.

Carlos: Exactly, so that’s going to be our topic today so thanks Cody for that suggestion. I guess one of the things that we will point out now is that, so this is going to be kind of on the investigative side versus the best practices side. So more of I just need to get the information so I need to figure what if anything to change or to be aware of versus here is what I should be changing. Does that make sense?

Steve: Yup.

Carlos: We do have a couple of companero shout outs. First we want to thank Kevin Feasel for all of his help with Episode 100. I know we enjoyed it. I hope you enjoyed it, and so thanks Kevin for taking a little bit of time to chat with us again.

Steve: So we phrase that as “Thanks Kevin for having us on your podcast.”

Carlos: Yes. We want our podcast back.

Steve: Yes, that was a lot of fun.

Carlos: It was a lot of fun so we appreciate that, and of course all the user comments. Those who contributed questions we are appreciative for that. We do have a couple of other shout outs that came to us via LinkedIn.

Steve: Yup, and I think some of these things came from Episode 99 when we started asking people LinkedIn in addition to Twitter. The first one came from Jack Rose and he said, “After hungrily devouring your wonderful SQL Data Partners podcasts for months, Episode 99 finally inspired me to reach out to you as instructed there. Not sure you intended listeners to simply follow you or actually connect personally so I’m trying both. Inspiring work.”

Carlos: Yes, so thanks Jack for listening. We appreciate you’re reaching out. You know, it’s funny the combination and that was purely by accident kind of that combination of both asking for people to reach out on LinkedIn and the Impostor Syndrome. But there was a very high correlation on the number of people mentioned that episode and like, “Well, I’ve thought about reaching out before but now after that episode I’ll do it.”

Steve: Yup, and we have another comment from LinkedIn from Chris Albert.

Carlos: Yes, so he says, “I’ve been listening to the podcast for the last couple of months and love the show. Sad to say I’ve already gone through the whole back catalog of episodes during my commute.” But he’ll keep tuning in, so thanks Chris for tuning in. It is unfortunate that you’ve managed to get through the back catalogs so quickly. Thanks for hanging in there. I know particularly in the beginning they are a little bit rough.

Steve: I know. When I joined the podcast on Episode 50 I had not listened to all of the preview episodes and I went back and listened to all of them as well. And I know it was a little bit sad when I got to the end too. But we’ve got new ones every week so.

Carlos: That’s right we’re going to keep chugging along here and we make it a commitment for another year so we’re glad that you’re sticking around. Ok, so the URL for today’s episode is going to be sqldatapartners.com/newdb.

Steve: Or sqldatapartners.com/101.

Carlos: Ok, so ultimately again the topic for today is becoming familiar with an unfamiliar database. And there’s really tacks or ways to kind of go about this and I know Cody kind of specifically mentioned an individual database. We’re now going to attack this first from an instance level, right, so this is the scenario again where you’re either new to a new job, maybe for whatever reason that database was stood up another department and now all of a sudden you’re asked to take it over, you’re consulting, you know what have you. So instead of focusing just of the database we’re going to take a look first at a couple of things on the instance level and then we’ll circle back to any kind of specific database things.

Steve: Yup, so the first area that we usually take a look at is system availability because
those are the kind of things that if you’re suddenly responsible for this those are the kind of things you could lose your job over.

Carlos: That’s right. Or get calls in the night about, all those things. And you’re like, “Ok well, let me nip stuff in the bud in the beginning.”

Steve: Yup, so the foremost one there that I usually look at is backups because things happen and there is going to come a time that you need to use your backup. And there is a lot of different ways that people attempt to do backups that aren’t always the greatest when you come to restore time.

Carlos: Exactly, and I guess we should say kind of jumping off here as well there is a lot of way to script a lot of these things out and we’re going to be talking about Database Health Monitor and how this can help us a lot with a lot of this as well. But first we’re going to dig in the why around what we are doing here. And so with the backups, some of the things that we want to know, one is are they happening and then where are they going?

Steve: Right. And that where they are going could be a pretty key thing because sometimes you take a look and say, “Backups are running everyday but they are going to the C Drive.” Not always a good thing to do. Other times they are going to a network share that gets purged every night or moved somewhere that as a DBA you don’t have access to where they are getting moved to.

Carlos: A lot of times that location also depends on how long we can keep those databases around so we may have to do cleanup because of a disk size issue when in reality we need to keep those databases around a little bit longer.

Steve: So part of the why behind keeping them around longer is that there is a lot of things that can happen that you may not catch or may not notice for a few days to a week or even a couple of weeks. And if you’ve only got 3-4 days with the backups and you find a problem that you need to pull some data out of a backup from 2 weeks ago but you don’t know about it until it’s already passed that retention window, you could be in a hot water there.

Carlos: Yeah, you would be in trouble. And the last component that we want to talk about there which kind of goes along with our next component, we’ll jump into file recovery options, so what types of backups are we doing here? When we think about file recovery we are thinking about full, or simple; or bulk log, I don’t see a lot of people using that on the long term. That’s kind of a more short term type thing. So full or simple, what am I doing with those backups for the databases based on the file recovery setting.

Steve: Yes, and I think that there, I mean the thing I see is oftentimes if you just install the database with an application or something like that oftentimes you’re not getting it in the right recovery model to able to meet your expectations on the recovery time or recovery point objectives. And I think when we talk about recovery options you can have your opinion on whether simple recovery or full recovery models are better. But it really comes down to what are the recovery time and point objectives that you’re trying to meet there and do those options that it’s currently configured for meet what you’re looking for.

Carlos: Exactly. A lot of times we’ll see databases in full recovery model but then the transaction log only happens once a day for example, the transaction log backup. And so again, this is information collecting. Now, we are going to get this information. We are going to figure out, “Oh ok, well this sounds like an issue.” We will go and have the discussion to go figure out what it needs to be but this is the first area that you want to check.

Steve: Yeah, and I think an interesting story there that I came across like a few years ago on some confusion over the recovery model option was that somebody had a database that was basically working, this was the company that I work several years ago, but it was basically working as a queue. And the data we get thrown into it and then another process would grab the data out of that and move it somewhere else. It was one of those things that it never get backup because it never had any data in it for a long period of time. However, and it was true because data would very rarely reside in that database for longer than 5 minutes.

Carlos: Oh, ok got you.

Steve: And it was SQL Express database and it was set to full recovery model. It had been running for about 4 years without ever having a backup on it and eventually the problem we ran into. You want to guess what the problem was, Carlos?

Carlos: Probably ran out of disk space.

Steve: We ran out of disk space. And this was a database that I never known was in used with this company prior to running out of disk space. But they call me and said, “Well, it’s out of disk space. Why SQL Server is being such a pig?” It’s because it wasn’t configured correctly, so that was one we had to flip over to simple recovery model and then shrink the files down or the log files down. They had plenty of disk space, leave it to simple recovery mode and never had a problem again. That was a scenario where simple recovery model was the right way to do it and it was also an environment where it didn’t really need backups because data was never there longer than 5 minutes.

Carlos: There you go. The other components of system availability are going to be disk space which we kind of just talked about, right? How much do I have left? And then the DBCC CHECKDBs, are they being run on a regular basis. Lots of ways to go about checking that but again that is just information that we want to grab.

Steve: So why is it important to run CHECKDB regularly, Carlos?

Carlos: So we could devote multiple podcasts episodes to this very question, Steve.

Steve: You know, in fact, we have haven’t we?

Carlos: Yeah, we have devoted a couple, that’s right. But ultimately looking for corruption there and I know that I’m just going to leave it as that because if we go further Steve and we’ll take a whole episode just on that one.

Steve: Ok, ok.

Carlos: So the next section then is admin setup. So kind of how are things set up from an administrative type perspective. Some of the things that I’m looking there are: what are the agent jobs, who are the owners and who are the operators of the system? Do we have male setup? Am I going to get notifications for the jobs? Right, so couple of things there. We have to make sure that the male profile is setup that email can flow out of the system. I’m looking at those jobs, what notifications if any do I need on them? Does it matter, right? Again, these are just questions. I’m collecting this information and then I want to be able to go back to the business and say look what needs to get changed here.

Steve: Yup. Another one that I checked around, not just the job owners, but as far as the SQL Server services for SQL Server and SQL Server agent. Who are those running at? That’s one that I’ve seen that sometimes you look and you realize, “Oh, that SQL Server is running as a domain user account of an employee that left 6 months ago.” And recently somebody in the IT Department deleted that domain account and next time you restart SQL Server it may not restart that or it will not restart with that user.

Carlos: Right. You know, it is funny now that I think about that. How many times, how many instances I’ve seen that have actually been the server account is an employee account. For whatever reason, that happens. The other one there in admin setup is server defaults. So again, we are talking about SQL Server settings here, something that you’d see on the advance configuration. Again, what they should be is going to be another question. But I just want to know what has been changed and let me compare to either internal documentation or expectations of a business.

Steve: So that’s where you find out that they’ve turn on auto shrink and auto close and those kinds of features.

Carlos: That’s right, and I guess we should point out that this is a scenario where particularly in the newer versions of SQL Server you can actually set some of that stuff at the database level so there will be a little bit of difference between instance and database. But for the most part I think a lot of those setting are in the older versions of SQL Server at the instance level. But there are things like the shrinking or the closing of connections or whatnot that can still be at the database level.

Steve: Yup. Ok, unto security then. I mean the biggest thing that usually comes up on security is sys admin privileges.

Carlos: And again, so this is the domain or instance perspective, who else has sys admin privileges on there? Because at the end of the day they can do anything they want and that could be good or bad. So we just want to make sure that, again if we’re responsible, if we are the person tied to that server they need to get clearance from us. We need to be ok with that idea that for not pushback on it. I think this is very common particularly when we have third party applications where we’re like, “Oh, just skip sys admin.” Which I know can kind of be a pain sometimes but I think Microsoft, as much gripe or much complaining as we like to do sometimes about some of the security, they have gone to great pains to try to make some of these roles available. I know a lot of times we see for example in monitoring tools. They want DBO, sys admin rights, when view system state, view server state. We’ll get them what they need.

Steve: Right. But I think it’s far easier when asked what permissions are needed for specific application for someone to respond, “Oh, they just need sys admin privileges.”

Carlos: That’s right because they know you won’t go wrong. There won’t be any problems at that point.

Steve: Yup. But it’s not the greatest thing to do. So I like to look that as how any sys admin log-ins do we really have? Is every single user a sys admin? And then the flip side of that is, do we have just one SA log-in and is that the only log-in in the entire database? I know I’ve seen that a few times. We don’t need users. We just use the SA log-in for everyone.

Carlos: Yeah. Again, so those are the things that we’re going to want to document and then potentially defend or say we anyway to make a change here.

Steve: Yup, and I know that’s oftentimes changing the log-in process especially if everyone is sharing an account can be very challenging to do because sometimes it requires code changes, or configuration file changes or things like that, to straighten out eventually but at least getting the understanding of what it is is a good spot to be because then you know who can hurt the server.

Carlos: Right. Well, even then I think let’s just say in that scenario where the application is using the one account. Now, password change might be a little bit cumbersome but not maybe as cumbersome as changing all of the application connection information but at least creating additional accounts for the people that connect using SQL Server Management Studio and things like that. So that at least you can take the password for that application account and put it somewhere where not everybody has it, so little harder to get to, that type of thing.

Steve: Yup. And the place that it’s harder to get to shouldn’t be in the source code that all the developers have access.

Carlos: That’s also true.

Steve: Yeah. I remember going through a DOD audit for security on a company I was working for a couple of years ago. I mean it took months just to straighten out all of the log-in privileges because prior to that happening nobody there really cared about things being secure on that server. It was simply one SA login and that was good enough for the owners.

Carlos: It’s good enough for me, right?

Steve: Yup.

Carlos: Ok, so the next area we want to take a peek at are dependencies. These are objects in the database that the database is going to use or the application is going to use. And again, we just want to know a bit about them, so the first one is user objects in system databases. A lot of times, we as administrators can be the most guilty of this.

Steve: I know I’ve done that. I’ve connected to a database and with the intension of using a specific database but then accidentally created a store procedure in the master database. And one way I help prevent that is don’t use the master database as your default database.

Carlos: If you don’t have another database and on a new server that can be difficult. I’m
even thinking about some of the community scripts, so sp_whoisactive, the blitz scripts. I mean they’re going to default to the master database and so if you don’t have one that might be something to think about as you start investigating or at least being aware of some of those things. Now, again a little bit easier because you know you’re creating them, you can clean them up but if there are other objects in there we want to know why, right? This is all in an effort because of recovery. If that database is dependent on an object in the master database that doesn’t get restored if we have to move it to a new server then all of a sudden I have problems and may not know why.

Steve: Yup. The next thing to look at there oftentimes are triggers. What are the tables that have lots of triggers or complex triggers on them?

Carlos: Yeah, exactly. And again, this is just information so that I know that when I insert a table, or I do x, then something else is going to happen. There’s another component involved there. I know a lot of times I feel like the admin audit. It seems like there is a pretty popular trigger out there so that when administrators do things like create tables, or create databases, or change users, that information gets audited and put into another table. Why if I have instances where all of a sudden that database is not available, the trigger starts failing and then you have issues. So again, you just want to be aware of what triggers are around.

Steve: Right. So it seems like we really have three layers of triggers to think about there. One is just your traditional triggers that are on the tables when things change, when things are inserted, updated or deleted. Then you have the DDL type triggers like you have just mentioned, administrators adding a table or changing a table. But then you also have the log-in triggers that can be setup on a database. That’s one that I came across not too long ago where I’m wondering why are logins are so slow. Well every time somebody is logging in it was inserting a row into a table and that had been running on a database from more than 10 years. Log-in table had never been purged. So it was one of those I asked, do you really care who log-in into the database 5 years ago or 2 years ago? And then we ended up getting rid of the trigger eventually, but for the short term fix was just truncate the table because they didn’t care about it and things were suddenly fast again.

Carlos: You know what, that’s another great example because I feel like most of the time when we get in trouble with triggers it’s because we as administrators are trying to outthink ourselves a little bit there. Then that scenario like, “Oh, let me put a trigger for log-in because for whatever reason that was a requirement. I thought about it. I learned about it and let me implement this because I think it’s going to help me. And then it can come back to bite us because if we forget about it the database changes hands ownership. That’s another thing to take a peek at.

Steve: And some of those aren’t entirely obvious until you run into a problem.

Carlos: Oh, exactly, exactly. Another one, and again so this is I guess more at the database level but going through each of those databases and then looking for disabled indexes. So we talked a little bit about the bulk logs scenario so cases when I have large imports, data warehouses. Sometimes the indexes can be disabled until the import finishes and then they can get re-enabled or rebuilt and the index can be used. Every once in a while however in that process the job fails or for whatever reason the indexes aren’t re-enabled. Those are other things that you’re going to take a peek at because basically we are storing data that SQL Server can’t use anymore and do we want to use it? Do we want to get rid of it? You know, those are the kind of questions we want to start asking with disabled indexes.

Steve: Yup, it’s just overhead that’s not used for anything at that point. And maybe you should be using it or maybe you should be getting rid of it. It really depends.

Carlos: Exactly.

Steve: Yup. So then we also want to take a look at non-trusted foreign keys and constraints. And that can cause some interesting trouble where both around data integrity and around performance.

Carlos: Exactly. We think have that foreign key and we think, “Ok, we are straight.” And
again foreign keys are going to help us. They hurt as a little bit on the insert, it has that lookup, so we get that and that’s probably why they got disabled. Again, lots of bulk inserts and things like that. But then when we are trying to do our queries and particularly the big queries where we are joining a lot of tables even though the foreign key is there SQL Server is going to go about giving you that query differently because the foreign key is no longer trusted. And you’re going to get different results based on that and so again that’s the information we’re we want to know about.

Steve: Yes, and sometimes that different result can be a changed in the query plan that goes from like a full table scan on a table versus not even touching that table based off of those trusted foreign keys.

Carlos: Exactly. And then the last one again we want to be aware of is plan guides. So SQL Server is going to look to those plan guides going to implement them in the query plans. So we just want to be aware is there anything that kind of overriding the compiler and indicating, “No, no, you should do it my way.”

Steve: Yup, but the other thing to consider with plan guides too is if somebody went gang busters and added too many plan guides. There are some issues around plan guides and being able to change stored procedure code for store procedures that have plan guides attached to them or created for them. So if you have plan guides that have been added for instance on a vendor supplied database and you’re doing an update from the vendor of that database you may need to go through and disable your plan guides prior to doing the update and then put them back in after doing an update. So plan guides although they, I mean I kind of think of them as the in case of emergency thing where you only use them sparingly. But you’d better make sure that everyone knows about them because they do have other ramifications that might not be entirely apparent when you use them.

Carlos: And I think this is going to increase because on the newer version of SQL Server with the query store if we’ve gone in, so query the whole premise of this is I’m using a plan that’s less efficient. I want to go back and use this other plan. I’m oversimplifying this, right? But basically we’re putting in, I guess not really a plan guide, but we are putting in some information to say, “Hey, use this instead of what you think is right.” And again those are going to be things that we’re going to want to know about. We may have done them, we may have executed them, or somebody else may have but we’re going to want to be aware that a change was made for whatever reason.

Steve: Yup, and you know it sort of brings me back to one of my about SQL Server, and I probably should have answered this as what would I change in SQL Server if I could, but there are two terms that I really despised. The term plan guides and the other one is the term query hints. They should be called plan commands. It’s not like a guide like, “Oh, we recommend you do this.” It’s a command that says, “You will always do it this way.” And the thing with query hints is they’re not hints like, “Oh, you might want to try this.” They are commands that say you will do this. Anyway sorry, side rant there on nomenclature but these guides are not guides. They are commands that say, “It will happen this way.” So just keep that in mind when you’re looking at plan guides.

Carlos: Yeah, and I think we are going to start seeing more of those in newer versions. And then the last area that we are going to touch on, we can now start taking a peek at some of the performance related things. Now we did mention that non trusted foreign keys can affect performance and whatnot. But here we are actually going to start collecting some of the metrics around performance, and I think ultimately what we are talking about here is establishing baselines.

Steve: Yup, and this can imply instance wide or it can apply to a single database. Either way, depending on what it is you are looking at there. I mean with query stats being able to have a baseline to understand what queries are causing the most wait statistics. What indexes are being used or not being used? What files for that database or instance are being overloaded or have very little I/O on them.
And I think that understanding that can have a huge impact on the way you look at things when you go to troubleshoot that server later.

Carlos: Exactly, and I think with the file stats, I think it is one of those eye opening for me, and let’s say you have an instance and you introduce a new database, right? So obviously the file stats on day one should be zero or near zero, whatever. Well, then you turn that thing on and you want to take a peek at it overtime and you may find out that all of a sudden these thing is going to be, you know, very chatty. It’s going to be a big hog and now you’re going to have store problems. And so again, establishing what those things are. We mention a couple, the queries, the index, and the files stats, wait stats, I guess we should include in there as well as to where I am now and then what I am doing in a week, in a month, in a quarter, you know, that kind of a thing. And of course this is again where the third party tools come into play to capturing that information. For most of this we don’t need to reinvent the wheel. There are things out there already that will do that and Database Health Monitor is one of them.

Carlos: One additional item that I guess we should talk about when it comes to investigating databases and that’s different from the instance level is actually taking a peek at the database diagrams. This could be kind of hit or miss. I think the diagrams are helpful but the tools that we have natively are great at helping us with this.

Steve: Right, and I know that if you use the database, I mean I like to stay away from the database diagrams in SQL Server Management Studio. And I think we talk about this many episodes ago but the reason I don’t like that is that people like to use it, kind of like Visio, to be able to make some changes and diagram things and print it out. But so many times I’ve seen that people don’t realize that when you go into database diagram and start drawing lines that’s actually making changes to the database in adding foreign keys.

Carlos: Right, live editor.

Steve: Yup, live editor and I’ve seen that cause problem so many times. I generally say, stay away from that. What I like to do if I want to look at database diagram is I like to use Visio. And Visio on certain versions, I don’t remember the exact Visio Enterprise or Visio.

Carlos: Yeah, it went through a weird transition where it wasn’t there for a little while. I
guess you could still reverse engineer it but some of the database objects. I think it was 2012. This goes back to our episode on the SQL Server data tools. During that transition this also was also affected by that.

Steve: Right, so with Visio I like to go in and just either on a smaller database take all the tables and import those into Visio so you can see where all the foreign keys are or if it’s larger database just bring in a subset of the tables that might be around specific areas that you’re looking at, bring into Visio. In that way you can visualize it and if you have access to like a large size plotter it’s really kind of handy to be able to print it out and have like a poster size diagram of the database on your wall. And I’m not really big in favor of wasting paper but that’s a really useful way so that when people come to talk to you about a database you can just stand up and go to the diagram on the wall and make sure you’re both discussing the same thing.

Carlos: I love that idea. I think this also harkens back to the idea of is this a third party app or is this something that we are developing in-house? I think a third party app might, there might be still some use for that but definitely the in-house development. I mean there’s, I don’t know how many conversations I’ve settled just because we pop it up in the database diagram and say, “Ok, this is what I’m talking about. Is that what you’re talking about?” “Oh no, I’m talking about this thing.” “Ok, well, there you go.” Now, I have never had access to the plotter. We always had to go like Kinko’s or whatever and they’re never quite big enough or we are piecing them together, all these legal paper and then we have to tape it together. So I’ve migrated beyond that. I think as my experience has been the database diagrams are only as helpful as the culture of your environment. Meaning, that if you’re willing to use them and look to them and adopt them as like a change management process. They become much more helpful. If it’s something that you don’t care about and you’re not like you’re making changes to the database without a diagram first being updated then it becomes less helpful, right? Almost like source control type thing, type idea. So because of that I’ve kind of moved on even passed Visio and I like the Embarcadero tool. It’s this expensive. It’s like erwin, so erwin was kind of the cream of the crop. Embarcadero kind of came in underneath but lots of the same functionalities. I think one of the things that you suffer from like in Visio is particularly once you get beyond like 10 tables. It becomes very hard to see that in one document and so that ability to kind of section them off into different areas or group them just becomes very very helpful. But again still, it is helpful I think, and the biggest ways in one, data types, relationships, and then understanding where things go, so again that idea of diagramming. This is my table, this is an object. What’s going to go in this object? “Oh, ok you’re describing something that doesn’t quite match that description. Maybe it should go over in this different table or we need to think about that differently.

Steve: Yup, oh yeah, I can think of an interesting story where I was working with a client a few years ago where we are working on some reporting queries and trying to figure out how to use some tuning or how to get the data that they needed in there. And so I went in and I thought, “Well ok, I don’t understand this database. It’s a third party vendor that provided it.” And the first thing I did is I opened it up and start looking at foreign keys and I realized that there was not a single foreign key on over 200+ tables in the entire database.

Carlos: And you’re like, “Ok, yes!”

Steve: So it’s like, ok well the only thing we have at that point is to try and guess what is intended to be treated as a foreign key is just how things are being used in queries. And I found that there are a lot of places that people were joining on values that shouldn’t have been joined on and wondering why they didn’t work. And if there just been foreign keys in the database it would have made a lot more sense to someone trying to get the understanding on what you can join on.

Carlos: Yeah, I know exactly. Ok, so Cody hopefully that’s helpful. So I guess to kind of recap a little bit there if we go back and put in some of those groupings, so first is system availability, then we have admin setup, we take a look at security,
dependencies and then performance. I guess we should add the sixth category in there and that is database diagram type of information. We’ve shared a couple of different stories there about how to do that. But again lot of just depend on your culture and whatnot.

Steve: Yeah, I want to say thanks Cody for the great question that gave us a good topic for this episode. And Carlos, I don’t think we have a next hundred episode entirely booked out yet. Do we?

Carlos: Not yet. We are shy by just, I don’t know, 99 or so.

Steve: Yes, the reason I bring that up is if anybody has any questions, or ideas, or topics that you would like to have us cover in the podcast, let us know, just like Cody did here. I will be happy to consider it for the podcast episodes.

Carlos: That’s right. I guess so speaking of the future, Tracy Boggiano who is going to be speaking at the Companero Conference. She’ll be on next week. And then we have Eugene Meininger–I’m pretty sure I’m saying that last name right. I’ve told myself I would say it right the next time I said it and actually I did that. But he’s going to be on the program as well.

Steve: Speaking of the conference.

Carlos: Yeah, we just have over a hundred days to go and so we’re looking forward to it. You can still register at companeroconference.com. August 4th and 5th we’ll be down in Norfolk and we hope to see you there.

Steve: Yup, I’m certainly looking forward to it.

Carlos: Yes, so again if you want to check out the show notes in today’s episode that will be at sqldatapartners.com/newdb.
Steve: Or sqldatapartners.com/101.

Carlos: And of course we really enjoy you reaching out to us on social media. You can do that on Twitter, or at LinkedIn. I’m @carloslchacon.

Steve: I’m on LinkedIn @stevestedman, and on Twitter @sqlemt. We’ll see you on the SQL trail.

Leave a Reply

Back to top