Bill Graziano
SQL Down Under Show 13 - Guest: Bill Graziano - Published: 1 Apr 2006
SQL Server MVP Bill Graziano discusses things he wishes developers knew about SQL Server, agile development, build environments and unit testing along with the recent PASS conference and baseball.
Details About Our Guest
Bill Graziano is a partner with Clear Data Consulting Inc and a Microsoft SQL Server MVP. He also runs, one of the largest SQL Server related websites. Bill spends his day helping clients better use SQL Server. He''s involved in the application development process in performance tuning and database administration. Published numerous articles on and is a regular speaker at SQL Server user groups. Bill's a spotlight speaker at PASS and currently sits on the PASS Board of Directors.
Show Notes And Links
Show Transcript
Greg Low: Introducing Show 13 with guest Bill Graziano.
Our guest today is Bill Graziano. Partner with Clear Data Consulting Inc and a Microsoft SQL Server MVP. He also runs, one of the largest SQL Server related websites. Bill spends his day helping clients better use SQL Server. He''s involved in the application development process in performance tuning and database administration. Published numerous articles on and is a regular speaker at SQL Server user groups. Bill's a spotlight speaker at PASS and currently sits on the PASS Board of Directors. So, welcome Bill.
Bill Graziano: Thank you. Great to be doing this.
Greg Low: That's great. Where I tend to come across Bill, for the listeners, is at various PASS conferences around the world. And so you've been travelling fairly extensively with those?
Bill Graziano: I saw you in Barcelona last month. We had our most recent conference there which was a great success and a great conference. Unfortunately I didn't get to sit in your session though.
Greg Low: That's life. Yeah the few guys from the organisers there, I noticed Paul Nielsen was there. He was one of the ones in the room so it's good.
Bill Graziano: Yeah we typically have Board of Directors meetings at each conference. All the Board of Directors were running around. It was a great conference. We have the one in Seattle coming up in November. And, everybody listening to this it's April 28th 2006. The call for speakers is open so if you would like to speak, now is a great time to submit an abstract. You can go to and submit that. That's my PASS blog that I wanted to get in.
Greg Low: Ah, that's very good, yes indeed. Encourage people to do that. In fact, the one in the US last year, the one we had in Dallas, it was a really enjoyable conference as well, I must admit. I think it was especially good. I recall that one just given the fact we all sat at the SQL MVP summit at the same time so it was just an amazing group of people there for the week.
Bill Graziano: That was really neat. We should all have a great one in Seattle. I would hope we get over 2000 people at this conference which should be our largest yet. We should get a lot of the Microsoft developer teams there because we're in Seattle.
Greg Low: So, listen, Bill. What I might do as a start is get you to just tell us how you came to be involved with SQL server in the first place.
Bill Graziano: Alright. Well, this is actually kind of a two-part question. I actually started years and years ago. I worked for a big consulting firm. It used to be called Anderson Consulting now called Accenture. Started doing EBA...EPA work on side base way back when. And so I was a side base DVA for probably about a year and then moved on and did an awful lot of project management, went to work with a little start up company and seven or eight years after I’d been a side base DVA I left that company and started out on my own. I was trying to find some skill that I could easily market and found a client that I began sort of doing some work for them. Just kept doing more and more SQL server stuff and it was again with all the side base stuff rehashed at that point. That was seven or eight, seven years I've been on my own, now doing probably 80-90 % SQL server work.
Greg Low: What do you find produces most of your work?
Bill Graziano: Most of, in terms of the type of work I do there's an awful lot of performance tuning. I spend a lot of time going in finding a problem; the server’s not responding, so finding out what's causing that. I also spend an awful lot of time working with development teams and how we better use SQL server, how do we better structure the application...
Greg Low: Yeah I must admit most of the SQL consulting work I do at the moment, somebody asked me the other day what sort of things do we spend most of the time, and I must admit most of the time we're walking in the door and somebody's saying this just doesn't run properly or we have a performance problem or we have, that just seems to be a very large number of the jobs. Do you think it's just because the people who are doing the developmental work just don't have sufficient skills or do you think it's still a bit too complicated?
Bill Graziano: Well I think there's a couple of things go into it. One I think, today's environment it's easy to grow data at a rate we never could before. Back in the 80s when I started doing database work it was just so much harder to generate data. It was people piping it in. And now you got systems that generate data for other systems so using gills... from, you know, no data to chicken GB of data in months or maybe even weeks, so what you write to process in the development environment of 100mb or 50mb systems fails when you get bigger. So think the systems scale much quicker and so that doesn't give people that are new to SQL server, you know, you say the way you learn to build the 100GB system is you build the 90GB system and you just work your way down so each little scale you learn a little bit more but people just don't have that time anymore. You're suddenly writing very large systems very quickly.
Greg Low: It's interesting you say that because; the size of the databases when you're talking about things that are automatically generated; I was at a site last week and the sort of work they're doing, they've got electricity metres and in fact they're recording a reading from every metre in the state every 15 min. And I just look at the number of rows that are ending up in those tables and it's just breath taking. And to give you an idea of the, how drastically that's expanded, they used to receive one reading per quarter, and they're now getting a reading every 15 min and you would think who could possibly make use of that amount of data but they have amazing trend analysis they're doing, but also they're looking at being able to go to client and saying over your six stores or something, for example, this is your load across different parts of the day. And if you can rearrange your load we'll change your pricing to different parts of the day. So even in their case this may be an enabling thing that allows them to start charging different amounts for power to different times of the day. The amount of data involved is just breathtaking.
Bill Graziano: The data just keeps coming. The system you write to process three months data might fail on nine months or a year's worth of data. You got a thing you're gonna start seeing a lot of, is this, it's cheap. People are saving a lot more historical data than they ever did before. I've got a client that I'm just finishing up where we just put a brand new system in probably about seven or eight months ago and already I would say it's three fourths the data in there and it's just historical audit trail stuff that nobody ever wants, leaves, and it just grows and grows and grows and gets harder every quarter.
Greg Low: It's funny you mention that actually. Another site I was at the other day was saying they went and talked to the business folk and they said look, can we archive the data off and they said yes, yes, yes, yes, yes but then they say yeah, but we need to be able to get to it immediately.
Bill Graziano: It's definite that archives have changed a little bit. So you can archive it but it has to look like the regular data.
Greg Low: Have you seen much interesting table partitioning from that part of view in SQL server 2005?
Bill Graziano: I personally haven't but I think that's just more, I think that's just a function of some of the clients I'm working with more than the dizz... That's not a compelling feature.
Greg Low: I must admit for these sorts of people it's a completely compelling feature. And it actually avoids a lot of the convoluted things they used to do where they'd have sequences of archive tables and things like that. Break a table up into different file groups and perhaps even have part of it read only and part not and so on. It makes a big difference to them.
Bill Graziano: I think that someone will get to it soon; they just have not gone down that path yet.
Greg Low: The other thing I must admit I find is that invariably when we go out doing performance troubleshooting; again I was at a place where we were doing mentoring work recently and I find what we end up doing when you go into solve the performance problem the developers; you end up having a discussion where they realise then that there's a whole heap of things that they need to go and redevelop. And I wish somebody had told me this six or twelve months ago type discussion.
Bill Graziano: I see that quite a bit too and typically developers are usually pretty sharp folks; but they are really good on how does my client application work officially, and for a lot of them, and I see this in a lot of situations, when they build a development environment they don't have the same sort of scale they had at production. So that query that works you know say on 100 or 1000 rows and breaks down on 10,000,000 or 100,000,000 and it's always a struggle to get the right data sets. And you know the great thing about SQL is even if you get them a reasonable sized data set in some cases you know productions are just fixed to different query plan and fair size development server and are still a little harder to accurately judge the question of performance production.
Greg Low: One of the things I really do enjoy doing in SQL performance tuning is just the percentage improvement that you're often able to have. I know we're sort of looking at making changes to applications. It's very hard to tweak five and six and seven percent changes but it's not at all uncommon to go onto sites with queries that take a minute and make them take less than a second and things like that because it's just not structured properly. I love the look on the people’s face.
Bill Graziano: I am always amazed at some incredibly, I don't want to say simple changes, but small changes can have just a huge, huge impact. I worked with a client once that had a website that was timing out and they were in the process of designing a respecting out a new server, a big 4 processor box. I don't remember how many GB or RAM; and so while we waited for that to get approved we started doing a little tuning and looking at the SQL and discovered that they had a webpage that was using a server side cursor. And it uses that data SQL 7; so every round trip was, every road returned was a round trip. So we changed two lines of client code to use a separate connection and the server went from non responsive and timing out to bang bang bang bang. Two lines of code.
Greg Low: Actually the other one that I find in a similar vein makes an amazing difference is a good use of caching in the middle tier. Particularly with web application with just where good use of the cache object hasn't been made. And I saw a site recently that was a sporting site, and basically they obviously tested the site with a moderately small number of users and figured that most people would be doing read only access and that sort of allowed for a small number of people to be doing much more interactive type things. But then all it took was for someone to put a competition up on the site and it just completely buried the entire thing. And when you have a look at it, most of the problem was simply that things that were endlessly being read from the data base could easily have been cached in the middle tier.
Bill Graziano: I think it's pretty neat when I do a lot of performance tuning. This other client I've been in talking to and we use accrisults to identify that cores are ticking all the time and as we find each one of those and we work through it with the developers their skill level ramps up really quick and within a very short amount of time they start looking at writing new things. They come in and sit down and talk about here's how I want to approach this and here's how I think it might work. You get much more involvement up front from them and how I make this thing perform. That's always pretty neat.
Greg Low: I noticed you did a webcast recently on query tuning on the Microsoft site and you clearly think that the ability to read a query plan is a key skill for a developer?
Bill Graziano: I really do. One of the things, I ask them, how many of you use query analyser management studio and how many of you use visual studio? And so many of them, they're SQL and ... And that just does not give you, I don't think the tools to really evaluate how that course kind of works in run and production. So I'm a big fan of developers, use management studio use core analysers, look at quarter plans, understand the impact this is gonna have. you can, once you've written a six or eight or ten cables joiners store procedures you could run it through and look at the quarter plan and if you've got a good size data set you could stick a quick hot ball and say for table scans that's not gonna be very fast.
Greg Low: It doesn't take very long to recognise table scans. What surprises me is the number of times they're just not aware that it's occurring or that you uncover poor indexing structures or things like that. It's just so common. With profiler traces I find that sort of thing appears all the time. If you look at the number of IOs on different steps and things, I mean the tools are there to make it very, very clear to you what's going on.
Bill Graziano: Well something else I've been curious about. I was involved in a project that did an awful lot of agile development and some of the components that project were designed very well upfront but in other pieces the database kind of grew to meet the requirements. And what they grew was a table design but not necessarily indexing strategy. So then as we got into production we kept discovering new indexes we needed. The data grew like data grows which only uncovered new indexes because nobody had gone back and done any kind of a systematic index, foreign keys index, clauses, things like that.
Greg Low: I must admit even a site I was at only again a couple of weeks ago I was having a look at the number one stored procedure they run all day every day, and the other thing I find is quite fascinating is the number of times I see people that have wrapped quite complex logic in a view and you tend to get views on views or they've just, when they're looking for a column they find a view that offers the column and there's no concept at all of what's going on in the background to produce that view. Sometimes it's just a complete disconnect. I saw one recently where they had a code that I think must have been automatically generated but it basically did like a select distinct from and then a select distinct again and that was from a view and they were selecting one column, but underneath that from memory the view was selecting 76 columns from eight tables with three left out of joins. Just amazingly scary things. But in the end it's just they looked around and said oh we can get that column from that view.
Bill Graziano: Views are interesting because there's a lot of opportunities to do the kinds of things you say where something that looks very simple looks very complex underneath. But at the same time a lot of clients don't use views at all and write the same thing over and over and over again. And I think in my heart it's a little lazy, whatever to type a little less I'm happy to do. Always saves me typing time so I try to use them wherever I can. Views are my, I guess I always think as views as my API into my database. Not gonna build my better views to do what I needed to do.
Greg Low: I must admit it is one of the interesting things that come up when they start discussing things like exposing web servers as directly out of databases. One of the key advantages people see there is the fact that you're exposing a specific contract and as opposed to the common question you get with stored prox. How do I know what comes back from a stored proc and you can kind of know, but you don't necessarily know, and the things that; the folk that are keen on exposing web servers are very keen on; is you have a very specific contract which kind of decouples the logic a bit but anyway. That’s just another area that we'll talk about another day but it kind of fascinates me more the moving of contracts back down in the database end.
Bill Graziano: If you know with web services with the server stroker architecture with CLR and SQL server there's a real opportunity there to really rethink how and where database fits in. I'll be the first to admit there's a whole lot of thinking going on and on and I know I haven’t done.
Greg Low: One of the things you did mention though, you're mentioning agile development before, and I know one of the things you were saying that you’re interested in was trying to fit databases into an agile model.
Bill Graziano: That's an interesting problem because it comes along from when you change your data base design out from under an application that can create a tremendous rework and I've seen some projects that have done that and they've seemed to go pretty well and unfortunately I was only involved from the periphery but I'm really curious as folks go more agile it feels like that really works well on a Windows application it doesn't need a database. But the more you plug it into you take the business object and invoice that you might model with at a very simple level two or three tables and you change something under the search of.. how you.. model five or six tables that's gotta create a whole lot of code rewrites and you don't wonder if more design upfront couldn’t' ... that. And I know there's some agile gurus that have the answer to that but every white paper that I've read and every article that I've read is kind of just worked its way around that issue and not really addressed it, that's something I can really use. I dunno.
Greg Low: What sort of interests me with that I also sort of personally think it's an area where the tools we’re using are just not up to it at the moment. While the tools are very good for what they do I look at how far the tools for doing say dot net development have moved and the ability to which you can do things like constant refactoring of your codes. So I can sort of, I can go off and build some new part of the code and every time I build a new part I can go back and easily look and see if I should somehow be refactoring the code to tidy it up and to rearrange how things are done so to bring it more to, this is what it would have looked like if I'd thought about the whole thing in the first place, and I just look at many of the things we have today with prox and all this sort of area where I look people very often are just completely scared to touch anything because they really don't know what they're going to affect.
Bill Graziano: Yeah it's interesting that intelligence gives you; if you change something in a data model in a different tool, an enterprise architect tool, what's it gonna be down the road?
Greg Low: I mean even if you had a proc, for example, and you want to do things like let's say some sort of change to the perimeter, it's the whole everybody just shudders because it's like they have little idea what that's gonna effect realistically and so I do just sort of wonder if we had tools that would allow the work on the database to be more agile we might be more prepared to make some of those changes.
Bill Graziano: True. Interesting point. When you get true intelligence in the IDE for database object and you very quickly say list my dependencies on this that really might change how we think about that.
Greg Low: I think I suppose one of the things that perennial discussion with things like T SQL is the deferred name resolution; the fact that if I mention an object that does exist it'll check that the columns exist, but if I misspell the name of the object it’ll just presume it's an object it doesn't know about yet. At the moment there isn't really as good way to find out about that until run time.
Bill Graziano: There’s a neat video on channel 9 that Anders Hellsberg did about the language, integrated query, the link stuff, and he talks about intellicence, the name resolution for SQL vs. C sharp. I mean, it makes you a little complacent about how in SQL you start with the column names. If you started with the prom clause, know the tables and then you could intellicence a come. It's an interesting little video to watch.
Greg Low: It's kind of fascinating stuff. I was a software design review in May last year or may have been the year before, were looking at some of the link things and some of the stuff coming further down the track and we did spend the session with Melin Lee and he was sort of showing us a whole lot of things they were trying; in trying to add intellicence into entity SQL; and I must admit after spending an hr with him I came out with a new respect of just how complicated that is. I mean the other languages are really well structured if you look at T SQL if you type select and then go space. I mean there really is almost anything could come next.

Bill Graziano: It's interesting because you look at C Sharp and even VB and those languages are going revision after revision whereas I mean core SQL has been unchanged now for what, 30 years.
Greg Low: I think one of the other things that make it difficult as well is the idea of having an optional line terminator. Because the issues they have is trying to work out where the statements stop and finish.
Bill Graziano: It's interesting; a little utility I've been working on is to simulate the read80 trace stuff for SQL server 2005.
Greg Low: That isn't going to appear in 2005 is it?
Bill Graziano: From what I've heard they will not be able to release that for 2005.
Greg Low: Most people probably, or many, will not have seen or heard of that so maybe you could just describe what that is for a few minutes.
Bill Graziano: The read 80 trace is a little utility that the Microsoft pod support group wrote and it does two things. First thing it does it will generate, you got a column like a replay able mark-up language I think is the word they use, RML file. Lets you take a trace file and get a lot more sophisticated replay of that trace file packet SQL server than you can with profiler. The other thing it will do is, and this is what I use it for, it's for aggregating what DWL statements are taking time on your server. So for example you can feed it a trace file and you can parche that trace file. And let’s say you have two select statements, you know, select star from table where column is one and then column two. But to verbalise those two select statements it can match them up so it will get better perimeters and things like that. And you can go back to them and summarise here's where all my CPU is going here's where all my reads are going and it is a fantastic tool for performance tuning and what we really find is that you might find a few queries that are really slow and you can fix those but it's recording that run 10,000 times in an hr. It's quick to run but simply by running 10,000 times, just so much of that CPU that even a little gain in that has huge impact on performance. It's a fantastic little tool but as I understand it they're not gonna be able to release that for 2005 so I sat down writing my notes. Released a few out there on the internet on the web blog which is like our SQL team and it's still pretty data but you know, I thought of this discussion. I started trying to figure out how to pache object names. And even something as simple as that was you know there are multiples.
Greg Low: Quoting, plus also alias' and the fact that the word “as” is also optional and so on and so on. It is tricky. That would be a good point to take a short break and then we’ll come back after the break.
Bill Graziano: Sounds good.
Greg Low: So welcome back from the break, so Bill what I might get you to do is just spend a few minutes just tell us anything you're willing to share about who you are where you live and what you’re interested in.
Bill Graziano: Gosh that's a big broad open question. Well I live smack dab in the middle of the US in a city called Kansas City. I'm a very active college basketball fan although my toque hawks just lost in the first round of the tournament for the second year in a row so you probably don't follow that down in Australia but.
Greg Low: What we did see the other day was the young autistic guy walking around with President Bush with the guy who won the, was it a school game or?
Bill Graziano: There's a video you can download off ESPN. He was a manager for a basketball team and had never gotten to play a game and then the last game of the season they were hit they put him in and he made four or five baskets in short succession which is amazing.
Greg Low: I was left with the feeling he was the kid who just sat there practicing all his life and never sort of had a chance but he finally got to do it.
Bill Graziano: He might be, it's kind of heart warming, though it's only a couple of minutes long. There's a link to it on ESPN now. Probably a look.
Greg Low: Certainly the little bit of the video they showed on our news was just stunning stuff.
Bill Graziano: It's funny because they edited it well; it looks like he just made basket after basket after basket. You read the article in a little more detail he actually missed half the shots he took but it's still very good. But not made everything he shot. They certainly edited that to make the story as compelling as possible.
Greg Low: So there’s an interest in basketball, what else?
Bill Graziano: Turning into summer here I guess you guys are starting to finish up Summer, but I'm a big fan of sailing, which, considering I live as far away as you can live from the ocean in America, so there's a little lake about 45 min away and I try to get out there as much as I can and go sail. Went with my father when I was little. It's something that he and I can go do together, get to see my family.
Greg Low: That's great. One of the things we were starting to talk about later, when talking about agile development, one of the things I noted in reading some of your material you were saying you've had some success using NANT. And tools you've written yourself.
Bill Graziano: One of the things I really enjoy is looking at the development process and how do you make it work better; there’s often the right little tool. Anytime I cannot type something repetitively or build a tool or utility to do it I'm usually a pretty happy camper there. We were working with a client and they had been writing a pretty big application and they were in a position to begin to move that into test environment and generally the best way to do that, they had a giant share development environment and their approach to build the test system was to copy the development environment and then begin trying to delete obvious test data to leave them what they thought was a clean environment. We ended up trying to start from a bare SQL model, just a script to create the tables, script to create the objects and then to load it, we ended up with a NANT script, ended up being like 3000 lines long.
Greg Low: I suppose a lot of DPA would be listening to this and might not be familiar with build processes and stuff in that regard so maybe just spend a few moments talking about NANT actually.
Bill Graziano: that’s a good point. NANT is a utility that's designed to build software and the big thing that NANT gives you is a very simple scripting language to do things related to building. Compiles, file copies, checking that the files are newer, checking version numbers, those types of things. Also do energy checking. For example we were able to build a task within NANT that said you know if you want to load test data I first have to build the tables, to build the tables I first need to drop and recreate the database. If you do that straightforward little required language it’s got some neat little SQL functionality in that you can imbed SQL tools; so you can say, want to create database statement but the name of the database is gonna be this variable that NANT has been keeping track of. So very, very few things that I found I wanted to do that I couldn't. It was just so much easier than if I'd written it in dot net or any other language you could come up with. You know because it was very easy to copy files to check for assistance to handle errors very gracefully and tell me very clearly where it failed; basically built a script that would drop a database, create the database, build all the objects we needed. We actually had about four apt locations that all share this main database; and many of the applications shared objects, like the customer table was the same across all of them. So we had the ability as we were building one of the later applications, it was automatically build each of the ..., for us. We could say build this application and it would do whatever it needed to do that. We had perimeter sided it all so it was very easy to change which server it built against. We were able to give developers the simple little batch files where they just change the environment for what server they want to do it. They could run the batch column, build themselves a development environment whenever they wanted.
Greg Low: Actually what I've seen people do for that I might add where there are different environments like test and staging environments and so on another neat trick with that is to often have it go out and access it via a DNS name and then actually use things like a set host file or a hosts file or things like that that is different in the different environments automatically redirects off to the appropriate servers. I've actually found that works really, really well and by comparison with things that I see, often people have installed process into different environments when they're doing testing and they’ve always gotta remember to then change this file or change that file and so on; and often think you can with a thing like a DNS entry, for example, you could just point it and say to something server and you could always just have that resolve to the different name and the different environments.
Bill Graziano: That would work well too. Our environment we wanted a way to script this and I don't know if there's an easy way to programmatically change where a DSN points. I have to think about that.
Greg Low: The neat thing is you can have it point to a fixed name and then you can have that name resolve to a different actual name in the different environments.
Bill Graziano: I see what you're saying, sure. That would certainly work.
Greg Low: It's certainly one I've seen successful.
Bill Graziano: I think the key thing in there is to build in that level of indirection. You could write that to run against as many servers as possible. We ended up with having four concurrent projects, each one having development tests QA, in some cases multiple tests, we ended up having about 25 to 30 server instances to manage and keep track of. What was on, what got built to what area.
Greg Low: It can certainly get very complicated. There was a site we were doing work for some months back, early last year and they had about 30 odd different servers and then they had all of those again in each of four different environments. It was kind of a test environment, a staging environment, a UA and you know a production environment and literally they were trying to manage 30 odd servers in each of those environments.
Bill Graziano: It does cascade very, very quickly. But that worked out really, really well for us. We were able to build those environments. The other big variable that we had was we had a lot of time sensitive data. We managed to bring down copies of all our production data as of a certain time and then we'd do a build against July 1st and we'd try ... all the numbers it wouldn't work, we'd change the numbers, we'd do another build against July to try to balance it out. So we even had different days and different environments but that was lots of simulated conversions.
Greg Low: It was one of the challenges in doing testing with SQL or databases in general is that you usually have time and date dependant things much more than they do with somebody develop middle tier objects or something and you know most of the testing is not, they don't have to worry about whether you'll have data in a particular date range or things like that. It's usually more simplistic the testing they are able to do. And I do find that’s one of the challenges being able to have sort of known outputs but you know the dates keep moving on the whole time.
Bill Graziano: They do and that’s exactly the problem we faced was being able to recreate as of a particular date and then try and balance out those numbers.
(Break - Specialist Interviews)
Greg Low: That actually raises an interesting thing. I think one of the other areas I see as complicated is the whole area of sort of unit testing or testing of prox and things like that. There was an interesting article in MSTN magazine a little while back where they were sort of proposing different ways of sort of doing that; but in most cases they seem to use tools like N unit or something but they end up staffing a transaction and then rattling a whole lot of work and rolling it back at the end but that’s usually not that trivial to once you start having nested transactions and things. Often the only way to really test the thing is almost do a full database restore before every test and that's pretty scary stuff to do.
Bill Graziano: That really is, and if you're dealing with any kind of a decent sized data set it's also time prohibited too. Wish I had a silver bullet for that but. It's a struggle to wade through that.
Greg Low: I think database testing is; what's still one of the big challenges; is the how you can run a proc that might affect a whole lot of things but have the database be in a known state every time you want to test that.
Bill Graziano: You know what's interesting, I wonder if some of the snapshots of 2005 will let us do things like that.
Greg Low: I keep wondering about that; although probably the down side of that is the fact that it's a read only snapshot you know. In fact what I'm thinking is probably more likely to be useful things like Virtual PC where you can have an undo disc and we could fire up an environment which is, we've taken a snapshot at a particular point of time you could then run test sheets against it and then just simply undo everything you just did at the disc level.
Bill Graziano: That's an interesting approach.
Greg Low: It's one I’ve been meaning to spend a bit of time; it's one most speakers do now for presentations where we have a Virtual PC that the presentation’s done on. At the end of the presentation you don't commit anything you just undo everything you did at the presentation then it's ready to go again for the next one. I think the same sort of technology probably needs, something along those lines, needs to be used for database testing.
Bill Graziano: Do you ever feel like you've got more ideas than you've got time to work through them?
Greg Low: Oh yes.
Bill Graziano: I'll read something or hear something and think wow I’d like to think through that and learn more about that just don’t have enough time.
Greg Low: Actually, in terms of things coming up in the future now you're going to be speaking in Seattle I presume, so with the upcoming conference, and this is along the lines of things you wish developers knew or something?
Bill Graziano: Actually I'm gonna be a spotlight speaker at the some PASS conference and my presentation is what I wish developers knew about SQL server. And I did a variation of it at the last conference and this is now updated for 2005 material.
Greg Low: Could you share maybe two or three of the top things from that?
Bill Graziano: Sure. It's interesting because it's a little different than trying to be a really in depth, everything you want to know about transactions. I've really tried to focus more on here's the mistakes I see again and again and again and we've talked a lot about query plans and understanding those and that's probably the biggest things that I wish developers knew more about is understanding how simple changes to a query can really impact a query plan. A simple thing like ... function around a column then expecting it to use an index. It just won’t. Things like that. When I did the 2000 version, the presentation, I talked an awful lot about error... handling... in SQL server or lack of error handling. Then types of patterns that would work well in that, you know, happened to check every statement and you react to that. Those were probably two of the bigger areas of topic matter. How to handle errors gracefully, kind of transactions fit into that to how do you gracefully roll back a transaction when your store procedure may have started its own transaction, may have had a transaction pass to it from a parrot... store procedure or a client application. Things like that.
Greg Low: That's great. Well look I must admit I'm really hoping I can get to see that one. One of the challenges whenever you’re speaking at one of these conferences you know there's usually something else going on in another room you’d like to see that you don't get to see. In fact we've got an upcoming code camp at the moment and I'm sort of allocating an introductory track alongside the main track and I'm also trying to decide which things, if I'm getting one of the speakers to present something in the introductory track I’m trying to not be too painful with what they might want to watch in the main track themselves. That’s quite a challenge.
Bill Graziano: Well you know one of the things I'm doing this year for PASS is I'm the programme director and ... make as hard as possible to have people find slots that they don't like in any session we try to fill up any slot with great sessions.
Greg Low: That’s great, so I suppose, just getting towards time, I suppose the main other thing is where can we see you what's happening in your world, what's coming up? So Seattle's one, obviously that's in November.
Bill Graziano: Seattle is November. If you happen to be in Kansas, I'm speaking in Wichita on April 28th, I think, whatever that Friday is, I’m gonna be in Wichita. I'm actually hoping to go to a couple of minor league baseball games that are going on down there too. I’m a big baseball fan.
Greg Low: Excellent. I must talk to you further about that one day I’m strangely for an Australian it's actually a sport I've played since I was very young. I ended up also then doing a lot of coaching and in later years a lot of umpiring; so I've found that the umpiring was something that gave you a different perspective on dealing with people, shall we say.
Bill Graziano: I would agree. I umpired for a number of years, I certainly agree with that.
Greg Low: It was really enjoyable. I worked through different umpiring levels, I think the highest level things I ended up doing, and I did do some games when they had the Pan pacific games here and things like that, so the international comps and things like that so it was really interesting to do. The expectation level's pretty high though at that point.
Kansas City’s, I'm a Kansas City Royal's fan, and our best prospects is a young Aus kid by the name of Justin Hubert.
Greg Low: Well in fact the better known of the local guys I actually grew up, my coach was a guy named Tim Nielson actually and Tim used to call him big red. He had all his boys playing baseball and probably the best known was Dave Nielsen and Dave ended up playing for the Milwaukee for many years and then later off across in Japan. Just an amazing player and must admit I've ended up coaching his nephews many years back and also umpired games where he's been playing, and if you have him there as a catcher and you're umpiring it's just an amazing thing to watch. I find it quite interesting shall we say. But the speed of those games is really something. I find it quite exhilarating at the higher level games. I think the thing I love in the US ones the guys at the top level clearly understand they're part of a big show, I mean the fact they call it the show, but they certainly do seem to think that way as well. My favourite story I heard from one of the umpires, umpiring Candlestick park many, many years ago he was saying he had a situation where he had a guy slide into second one day and he'd called safe but he'd indicated out and he said that the guy was lying on the ground looking at him not knowing what to do and he leaned down and he said you know you're safe, I know you're safe, but there's 60,000 people out there who think you're out so see ya later. All they see’s the arm. Wonderful game, love the game, but glad to see you love it too.
Bill Graziano: Great. I did not expect to find an Australian baseball fan on this phone call.
Greg Low: There you go. That's good so any other speaking, so Kansas City you're saying you're speaking, there’s articles or writing or any of those sort of things on the go?
Bill Graziano: No, nothing else scheduled at this point. I know I've got a couple other webcasts but those are not scheduled yet.
Greg Low: Really encourage people to get up and have a look at those. On the webcast site there are so many webcasts posted up there, they're just an amazing high quality free resource that people can learn form. In fact, I don't know if you got to see that series of ten that Kym Trip posted up recently but just her rave reviews from people that watch those.
Bill Graziano: I have just begun to look at those.
Greg Low: There’s just a wealth of free information up there.
Bill Graziano: I have a lot of articles up. I try to get something out there every month or so. Been doing a lot of work for 2005 lately on CLRs and SMO articles. I try to understand that. And I know for speaking in Kansas City I usually speak in a local SQL server group three or four times a year so should be something coming up there soon.
Greg Low: Magic. Well, thank you so very much today Bill. That's been really entertaining to get to talk to you and we'll talk to you again soon.
Bill Graziano: Yeah, thanks for having me I'm looking forward to seeing you in Seattle.
Greg Low: Indeed, ta.
Phone: 1300 SQL SQL (1300 775 775) l International +61 1300 775 775 l Fax: +61 3 8676-4913
Copyright 2017 by SQL Down Under | Terms Of Use | Privacy Statement