Scott Forstie on the Importance of Database Engineers

Paul talks to Scott Forstie, DB2 for i Business Architect, about the importance of Database Engineers and what IBM is doing to make that role easier. Paul also finds out where to go for aggressive food!

Paul: Hi everybody and welcome to another iTalk with Tuohy. So I'm delighted to be joined today by the DB2 for i Business Architect for IBM Scott Forstie. Hi Scott.

Scott: Hello.

Paul: So Scott just when we were chatting before and I realized it has been a year since we spoke, since we did an iTalk.

Scott: An entire year, yes.

Paul: An entire year. We have met many times over the year. We bumped into each other; our paths have crossed a few times at a few conferences and user groups and things like that. What I want to talk to you about today Scott is something that we've touched on in conversation a few times. One of the big things on the platform when we're talking to people about the database, we say one of the great things about database on i is that we don't need database administrators. We don't need DBAs-

Scott: Right. Right.

Paul: Because an awful lot of what DBAs do, we're fortunate that all of that is integrated into the operating system for us but one of the things that we do need is database engineers, so do you want talk a little bit about what exactly a database engineer is and why we need one?

Scott: Sure. Yeah so the database engineer as we love to refer to them as DBE. You know we love acronyms of course. [Laughs] I'm just saying. So that database engineer is intended to be in this role of maybe more of a caretaker of the database. Like you said, we don't need somebody doing some of the administration tasks that so many other databases need but when you ask question like do you know the most expensive database workload what it is. Do you know about the most expensive database queries that are coming through and by which users? Do you understand your index strategy and how healthy it is; should it be changing? Those are some of the kind of prompting questions that you can respond to well oh, my DBE should know that and if you don't have one, then you know this is where we get into a dialog of trying to convince customers to invest in being proactive as far as systems management go including the database.

Paul: Yeah, so the DBE then, it is one of these sort of-how do I-it is one of these new hybrid roles really isn't it?

Scott: Oh yeah.

Paul: Whereas on other platforms like a DBA is this distinct job role. I mean this is what you do from nine to five. Here we are talking about-well okay, maybe if you are one of the large-the large customers you might have somebody who it is their full time job to be a DBE but I think the reality is for most people it is sort of two hours on Friday afternoon.

Scott: Indeed, yes. See that is the kind of scale we need to talk about. It's not a yes or no thing. This is something that you can pick your favorite person on your staff and have them spend a portion of their day or week or month on this topic. You will get immediate benefit. Now tying it back to real business value is what we always try to do because that is usually a pretty strong motivator.

Paul: So tell me some-but it is also a sort of a hybrid as well as Scott in that it is not-it is not sort of-it is not an OPS admin role. Well sorry. It is an OPS admin role because we do talk about things performance and that-

Scott: Right.

Paul: But it's also partly an application role as in at least we need somebody who understands database. [Laughs].

Scott: It's so good that you pointed that out because so many of the DBEs that I've met and I have a goal of actually introducing myself to every DBE because I would like to have this dialogue with them about how do they do their job because I can usually add some new ideas for them and maybe they can give me some critical feedback so when I talk to them, many times they are enabling the application developers to be successful because they can see the database. They understand the data model; they see the activity and they can provide guess what? Good advice.

Paul: Yeah.

Scott: Let's take the-let's do this differently. You know your query needs to change or you can't deploy that without this index in place. Those sorts of things when I talked about being proactive that is the kind of outcome you can see. Now we have taken a step further in the database. You know how it is with advice, Paul. You know if you are only giving advice and never following it, you've missed out on something essential. [Laughs] So we like to take our own advice. We've created what we call services for the database engineer; services in the form of database provided procedures, functions, and views.

Paul: OK.

Scott: These are resources so that a database engineer can start to automate a portion of their job and if we're talking about somebody who is maybe not going to be spending even full-time on this, automation should be part of the conversation.

Paul: OK so what you are saying here is this is sort of a step beyond a lot of what we would have had back in good old System i navigator when we'd go in with some of the tools there and we could look at you know things like the index advisor and all those kind of things-

Scott: Exactly.

Paul: But really they were the case of I have to go and look at them so are you saying that they're now like this plethora of services that you provide over the last-

Scott: Did you say plethora? [Laughs]

Paul: I said plethora.

Scott: Oh, hot diggity dog.

Paul: No but I mean-so you are saying there are now all of these sorts of services. So you are saying effectively you're now trying to put it to stage where people can write scripts that will do analysis of their database for them.

Scott: Exactly. For years, you know team IBM and DB2 for i have been recommending things to clients. Here is an example. Before you make an important change to your IBM i either with your applications or with the IBM i service levels or operating system, you should do the following: Dump the plan cache. You've probably heard this advice.

Paul: Yup.

Scott: This is good advice. How many people have heard that? Well do they do it manually? They don't have too. They can implement this programmatically. I've even shown customers how hey, look at me. I can change the Power down sys command to do this automatically and I can use SQL to generate a unique name for this dataset and capture this information. Why is it important to have it? Well ask your database engineer. Maybe they have been trained to understand that it is important that when you have some sort of performance issue facing you, it's critical to have the same kind of information about when you had no performance issue, right, so you can do comparisons.

Paul: Yup.

Scott: And we have many procedures related to the SQL plan cache, which has all kinds of very important information in it. How much of it do you want to be capturing? What the cadence of that capture? Those are the follow on discussions you can have because there is lots to choose from as far as these kinds of services.

Paul: So where will people find all of these services documented Scott?

Scott: OK. They're in two places. One is the IBM i Knowledge Center. We decided to make this legitimate. We put it in a book. Now bear with me here. It is in the Database Performance and Query Optimization book so maybe not the ideal book to choose but it is in a book. So there are two chapters in there, one for DB2 for i services. Those are the services for the database engineer, one chapter is called IBM i services. Those are services for anybody wanting to use SQL to work with the IBM i operating system. That's the book. It gets updated every time we ship enhancements for technology refreshers so that's typically two times a year.

Paul: Yup.

Scott: The other location is in IBM i Developer Works. Since I'm the owner of that technology update Wiki, guess what? I can put it there as well and I thought to myself hey I can publish the things immediately in Developer Works. Yes, it is the same things that you'll find in Knowledge Center but having it two places may be more people will discover that these exist and start using them.

Paul: Yup. Cool. Excellent. So since I asked the question earlier and just sort of touched on it, are there ones specifically for the index advisor?

Scott: Yeah. Those are some of the most popular as well. One of things that Mark Anderson and I decided to do a number of years ago was a schema called Sys Tools for Purpose. Sys Tools is on everybody's IBM i. It contains DB2 for i provided examples and some of first examples I wrote were related to index advisor, how you could use SQL to consume index advice for you so you wouldn't have to have eyes on screen. My intention for some of those examples was that users could extract the SQL and see how did he code this and then customize it to their own purposes. What I found out through time is that a lot of customers are out there just calling what we've built.

Paul: Right. [Laughs].

Scott: And that's okay. You know I put some parameters on there to try to make it you know configurable to a lesser extent, not as far I would really want to go but for clients, that's what they've done.

Paul: Yup.

Scott: It doesn't meet everything that a database engineer can and should do but it gets them closer

Paul: Yeah. It's-that actually is one of the things I must say that I quite like in the run SQL scripts in ACS is that all of those services are in there available on the examples if I remember correctly. Yeah.

Scott: Yeah. That is yours truly as well. They made me part of their team so I've been over time putting my favorite examples into the tool-

Paul: Yeah.

Scott: And you know as time allows we put and more in there. For example, the other kind of things the database engineer could do out of these services is very quickly understand which of my database files would benefit the most from a reorganization and just how much. I even put a query in there that shows them the distribution of deleted records within a file.

Paul: Yeah. OK.

Scott: I mean those are database-engineering tasks.

Paul: Yeah.

Scott: And we're trying to bridge the gap between somebody writing their own scripts. Right? Let's have the database provide these things-

Paul: Yeah.

Scott: And then you know like you said, start with Navigator. Learn those tools; become proficient at it and then see which of these services you want to use to automate. I would be remiss if I didn't mention that Doug Mack and the DB2 web query team, they have built a lot of these examples into DB2 web query so if you don't want to roll your own, you could choose to get DB2 web query and just use their reports-

Paul: Yeah.

Scott: The database engineering reports.

Paul: Yeah.

Scott: A lot of options available.

Paul: Cool. OK so that's it. No excuses. DBE has to be. [Laughs] You can use that.

Scott: That's our way of thinking.

Paul: OK so just before we finish up Scott, I remember when we spoke last time one of the things you are telling me about was that when you travel, you like to do food exploration-

Scott: Oh.

Paul: So in the last year, have you had any good food adventures?

Scott: Well I've traveled more in the last year that I ever have in my whole life and so it has been kind of a food spectacular year. When we were both in New Orleans for COMMON, I found like what I think is one of the best places for seafood gumbo and found a way to get there, had a great bowl of gumbo. When I was in China, I went a cooking class on the weekend and learned how to make dumplings. Amazing but probably my best experience was in Rome. When I was there, one of my favorite pasta dishes is arrabiata if you have ever heard of that one.

Paul: Uh-huh. Yup.

Scott: Do you know what that stands for?

Paul: No.

Scott: Angry. Arrabiata is angry pasta.

Paul: OK. [Laughs]

Scott: And what would make your pasta angry? Well it is spicy and my pasta arrabiata in Rome was delicious and spicy.

Paul: Yeah.

Scott: Yeah.

Paul: You've got go all the way to Rome for that. Oh, what a terrible life you lead Scott. [Laughs].

Scott: I took one for the team.

Paul: I can give you angry without going to Rome, I promise.

Scott: Those are some examples.

Paul: OK well listen Scott, thank you so much for taking the time to talk to me.

Scott: I'm always happy to do it.

Paul: OK. So actually I may touch you again real soon because I know as we are recording this that we've got a technology release coming up soon so I may be talking to you sooner than a year's time.

Scott: I hope so. We'll talk soon.

Paul: OK everybody, that's it for this iTalk. Tune in again for the next one. Talk to you all soon.