PASS SQLRally Dallas Pre-Con Previews

 
Want a sneak peek at what you’ll learn at SQLRally Dallas’s can’t-miss lineup of pre-conference seminars? Go inside the 7 in-depth, full-day training classes in this Q&A series with our presenters:

Don't miss out - see the full pre-con schedule and register now!
 

Storage for the DBA
By Denny Cherry

Q. If you could put up a billboard about your pre-con seminar, what would it say?
A.
Sick of fighting with your storage admin? Come learn all their secrets so you are ready for the next battle.

Q. What draws you most to the topic of storage?
A.
So many DBAs aren’t allowed to look at the storage, which is typically the biggest bottleneck on a production SQL Server. Having insight into the storage admin’s world is critical to getting and keeping everything running smoothly.

Q. Where does your workshop take attendees beyond what you might cover in a 60- or 75-minute session?
A.
The storage world is a massive environment of which only a very small portion can be covered in an hour. In the longer session, we can go a lot deeper. Sadly this would need to probably be a month-long class to dive as deep as most people really want it to go.

Q. What's the most surprising statement attendees might hear you say during the pre-con?
A.
There’s probably nothing groundbreaking that I say during the session that people wouldn’t have heard me say at dinner, or over drinks. It’s just a matter of getting all this information collected into a single location all at once that’ll be the most shocking. After all, this is a 7-hour session with no labs, little to no demos, just me talking… the entire time.

Q. If there was one practice you wish attendees would give up after attending your workshop, what would it be?
A.
By the time this daylong session is done, if anyone is not asking the storage admin questions about their configuration, I’d be pretty disappointed in them.

Q. What have you struggled most with in putting together this information on storage for the DBA?
A.
Just getting access to a lot of this information was pretty tough. Most storage people, vendors, etc. don’t want to give up the secrets of their systems and how things are set up and working. But they really need to in order to get the systems working as best as possible.

Q. If attendees could take back just one message to their teams about this topic, what do you want them to remember?
A.
That every storage config that they walk into should be different from the last one they looked at. Just because it was done one way at one company doesn’t mean that it should be done the same way at the next company. Every storage vendor does things differently; every server needs a different storage configuration. Using standard one-size-fits-all configs doesn’t work well, pretty much ever.
 

Leadership and Team Management Skills for the Database Professional
By Kevin Kline

Q. If you could put up a billboard about your pre-con seminar, what would it say?
A.
Learn to Lead, Inspire, and Motivate IT Professionals!

Q. What draws you most to the topic of IT leadership and team management?
A.
I have led many IT teams in the past, from small to large, and it wasn’t a seamless or smooth transition. The skills that make you successful as an IT technologist are a world apart from the skills that make you a good manager and leader. I wanted to synthesize and distill my years of experiences and training into a curriculum distinctly optimized for managers of IT people.

Q. Where does your workshop take attendees beyond what you might cover in a 60- or 75-minute session?
A.
My 60- to 75-minute session, Team Management Fundamentals, is literally a high-speed crash course designed to help you dodge the most egregious management mistakes and grasp the foundation-level concepts of leading a team effectively. The full-day workshop teaches many more foundational skills and delves deeper into the top five problem scenarios for new leaders. Incidentally, I’ve also developed a 3-day course.

Q. What's the most surprising statement attendees might hear you say during the pre-con?
A.
Many IT professionals will have an epiphany – “I don’t actually want to be a manager because I like being hands-on technical” – but you’ll never know unless you try it.

Q. If there was one practice you wish attendees would give up after attending your workshop, what would it be?
A.
Using email (and other technological forms of communication like IMs, Twitter, Skype, etc.) as the sole method for communication. Email is only one of many ways to communicate and can very frequently become unproductive or even counter-productive. I wish IT people would spend more time thinking about what information the person on the other side of the conversation needs to hear and then tailor their message accordingly.

Q. What has been the most difficult thing for you to get your mind around in this area?
A.
IT professionals expect to win influence and motivate their peers, bosses, and staff through the rationality of their arguments and the proof of their data. “Of course we should implement strategy XYZ, just look at what a difference it’ll make based on my reports!” But it was a big turning point for me when I realized that most people, especially those outside of IT, make decisions based mostly on factors besides rationality or logical decision making.

Q. If attendees could take back just one message to their teams about leadership and team management, what do you want them to remember?
A.
I would want attendees of my workshop to remember that as leaders and managers, we’re no longer measured by our success as individual contributors but instead are measured by the success of the entire team. As a manager, it’ll matter a lot less that you are exceptional and a lot more that you enable each member of your team to achieve their peak potential.


Relational Database Design Workshop
By Louis Davidson

Q. If you could put up a billboard about your pre-con seminar, what would it say?
A.
Sick of struggling with terrible databases? Learn to design your own databases the right way!

Q. What draws you most to the topic of database design?
A.
A number of years ago, I had a side job designing a database for a small company. I was clueless about what I was doing, and I did a terrible job. I had recently taken a college class in Relational Databases, and it was pretty much useless from a practical point of view. Ironically, it was my worst performance in all of my computer science classes. My next job, I left database work and started as a LAN administrator and worked on the Help desk.

At a conference I attended, SQL Server was just starting to come into life, and a coworker and I suggested we try to replace a super expensive mainframe with a single PC (with 16MB of RAM!). And we did. The lead programmer understood database design really well, and after another person left the company, I was approached (due to my previous database "experience") to take over the data programming while he did the UI. I was hooked in a minute, and under the tutelage of the lead programmer, we implemented this database system and saved our company a six-figure amount each year.
 
From then on, my goal was to get better at database design, but there was little information available that made sense to me. So I started writing, teaching, and helping others learn about database design. What I found was that the problems I encountered back in my first database implementation were often the same that others were struggling with. And as a bonus, as I spend more time teaching (particularly the past 2 years with SQLSaturdays becoming so plentiful), I am learning from attendees as well and continuing to improve my skills.

Q. Where does your workshop take attendees beyond what you might cover in a 60- or 75-minute session?
A.
The problem with teaching a 75-minute class in database design is that we can barely cover the beginning (and essential) material in that time period. Worse yet, when the 75 minutes is over, the attendees will have just heard about design, not actually seen much design nor participated in a design session (and one void of office politics!). So over the 7 hours of presentation time in my pre-con, we will cover the basic theory that governs why our databases need to be designed a given way, talk about the lifecycle involved, and actually do the process a few times. Obviously it will be very small designs, but we do just have 7 hours – and I have never designed a production database in 7 hours of meetings, much less design time. :)

I also expect that some of the people who attend the workshop will not be currently active designing databases. One of the major tasks of a database programmer/report writer is to "read" a database – determining what the design tells you without even a line of documentation.

Finally, I offer attendees a chance to do "homework" after the pre-con and have me "grade" it for them to help them see what they did right (and perhaps wrong). I do this interactively, like a client would, asking questions and leading them to a working design. I’ll be interested to see how many people take me up on the offer, but it is there if they are interested.

Q. What's the most surprising statement attendees might hear you say during your pre-con?
A.
Probably that "the fourth and fifth normal forms are actually important in every design." If there is a preconceived notion that is the most prevalent in relational databases, it is that anything beyond third normal form is harmful to your performance. Ironically, the reason why third normal form is the most important is that violations of fourth and fifth normal form are semi-rare. So while most designers who take the time to consider third normal form end up getting it right without realizing it, sometimes issues are missed that don't show up until you are writing a complex query and subtle errors start occurring in results.

Q. If there was one practice you wish attendees would give up after attending your workshop, what would it be?
A.
Rushing to a solution. I will be honest, I do it myself over and over, letting myself be pushed into turning over a design faster than I am ready to – and it never pays off in faster release times. The beauty of the design process is that change is almost free when you haven't written code yet. When I have the time to work through requirements, design the database, and work with developers to get the processes and data usage down pat, we save more time at the end of the project than we ever have by getting started coding quickly.

Thinking back to the previous question, the second most surprising statement I tend to make is that "the best software testing is done before code is written." Working through scenarios of how the system will work and what data is needed in the scenarios can be a lot of work, but change is easy when there are no existing dependencies, like code that has taken hundreds of hours to write that turns out to be completely incorrect but unchangeable due to a deadline that forces you to stick with code that is actually wrong.

Q. What have you struggled most with in the world of database design?
A.
Theory (and why it is actually important to grasp "why" good databases look a certain way). I mentioned that I had recently had a college class on database design when I got my first job designing a database. I had barely grasped the theory enough to pass the class, but it all seemed like the ideas of people who didn't like to get things done. Yet the more I designed and the more I coded, the more I realized that I was missing something. It was just really hard to do the kinds of things my users wanted.

So I worked hard to understand the basics of theory, and finally realized why it was so important to design in this way, which from the outside looks like more work and certainly ended up often taking an order of magnitude more tables to represent the same concepts than I originally had built without consideration of how the engine worked, or why.

The funny thing is, once you get the concepts of relational databases straight, it becomes very difficult to do things incorrectly. Even coming up with examples of bad design (without plagiarizing your coworkers or clients) becomes almost impossible.

Q. If attendees could take back just one message to their teams about this topic, what do you want them to remember?
A.
Requirements are the most important part of design, and design is the most important part of coding. I don't know how many times I see it, but the phases of projects that directly produce software are the least important parts of a software project. Sure, they are the most fun, and they are definitely a lot easier to quantify. But unless you know what you need to code (requirements) and how you are going to implement those requirements (design), the code you write could be completely useless. A George Harrison song lyric is so fitting here: "If you don't know where you're going, any road will take you there."


How to Be a DBA - A Utility Belt of Tools
By Tjay Belt & Chris Shaw

Q. If you could put up a billboard about your pre-con seminar, what would it say?
Tjay:
We were thinking more along the lines of a TV ad – “ Hello, Database Professionals, look at your database, now back to me, now back at your database, now back to me. Sadly, your database isn’t my database. But if you started using the tools in our tool belt, your database could smell like mine…”
Chris: “Look down, back up, where are you? You’re in a data center troubleshooting the database your database could smell like. What’s in your hand? Look back at me. I have it. It’s the tools from our tool belt that your database will love. Look again, the tools are now diamonds. You are now the hero. Anything is possible when your database smells like our database. I’m on a horse.”

Q. What draws you most to this topic?
Tjay:
We have performed these same database tasks ourselves, painfully sometimes.
Chris: Absolutely. We have learned many things we wish we would have known in the beginning of our careers. Our desire is to share these things with others.

Q. Where does your workshop take attendees beyond what you might cover in a 60- or 75-minute session?
Tjay:
Our pre-con will delve into six distinct topics. We take the approach of showing you how to apply these topics. You will not just learn how to perform the task – we’ll answer the When and the Why.
Chris: And we are heavy on real-life examples, so you can see everything in practice.

Q. What's the most surprising statement attendees might hear you say during the pre-con?
Chris:
Backups are not the most important thing to your database – there is a more important ability, and if you don’t have it, that is a sure-fire way to start working on your resume-building skills.

Q. If there was one practice you wish attendees would give up after attending your workshop, what would it be?
Tjay:
Doing things the way you’ve always done it without asking yourself “Why do I do this? What is its purpose? Can I do this better? Is there a better way?”

Q. What have you struggled most with in the area of putting together your own SQL Server toolbox and knowing when to use which tool?
TJay:
The most difficult struggle was the realization that this is our job. It’s our job to architect solutions, produce streamlined processes, and revamp how things are done. We need to ensure that our data is loved, protected, and properly accessible.
Chris: It's difficult to not force a solution where it doesn’t belong. One task can be completed so many ways, and there are so many right answers. That is why you so often hear "It depends.” Every situation is different, and one solution is not the correct way for everyone.

Q. If attendees could take back just one message to their teams about this topic, what do you want them to remember?
TJay:
I learned things from these two guys that do the same job as me, and I can apply them today to make my life easier.
Chris: Wow, there are so many things we can do to work smarter.


99 Tips for Tuning and Enhancing Analysis Services
By Greg Galloway

Q. If you could put up a billboard about your pre-con seminar, what would it say?
A.
I enjoy the advertising genius behind the billboards advertising air conditioning that say, “Your wife is hot!” While my wife is hot, I can't see how that relates to Analysis Services. Maybe my billboard would say, “Your cube is cold!”

Q. What draws you most to Analysis Services tuning?
A.
I've been brought in to fix the performance and the user experience of countless cubes, so I have seen firsthand the common mistakes Analysis Services developers can make. In several cases, I was fixing cubes I myself built, and I wish my future self could lecture my past self. I hope that other people can learn from my mistakes.

Q. Where does your workshop take attendees beyond what you might cover in a 60- or 75-minute session?
A.
To quote Spinal Tap’s Nigel Tufnel, “You see, most blokes will be playing at ten. You're on ten on your guitar. Where can you go from there? Where? Eleven. Exactly. One louder. These go to eleven.”

Q. What's the most surprising statement attendees might hear you say during the pre-con?
A.
This is probably more ironic than surprising, but I strongly believe that the developer who named the Analysis Services “Query Log” should be tarred and feathered since it does not actually log queries.

Q. What have you struggled most with in the area of Analysis Services performance and tuning?
A.
Kerberos is a beast, and I gladly pawn the task of setting up Kerberos onto sharp co-workers. Thankfully, I’m going to avoid Kerberos during this pre-con session except to show a trick that avoids the need for Kerberos altogether.

Q. If there was one thing you wish attendees would implement after attending your workshop, what would it be?
A.
I wish people would take an hour to set up logging of Perfmon counters and trace information so you can see how performance is trending over time. I’ll do my best to convince attendees how useful this information can be and show what I personally choose to log.


How to Perform a SQL Server Health Check
By Brad McGehee

Q. If you could put up a billboard about your SQLRally pre-conference seminar, what would it say?
A.
There is a SQL Server health pandemic. Most organizations don’t realize how sick most of their SQL Server instances really are.

Q. What draws you most to the topic of SQL Server health?
A.
I have been writing about SQL Server health since 2000. That was the year I started as a SQL Server DBA at a new company, and every instance they had was new to me. My first job was to learn about each one, determine their health, and decide on how to fix them. At that time, I started creating a list of things to check, and that list now has over 500 items on it. Creating my checklist, and creating best practices around them, has become a big project for me. In fact, I am in the process of writing a new book that covers this same topic.

Q. Where does your workshop take attendees beyond what you might cover in a 60- or 75-minute session?
A.
I actually tried to teach this daylong seminar in a 75-minute session. But after trying it twice, I gave up – there was no way to do the topic justice in such a short amount of time. A full day allows me not only to cover more topics (not the full 500, but a lot :) but also to cover them in-depth. I will be picking what I think are the key health-check items, as there is not enough time to cover them all.

Q. What's the most surprising statement attendees might hear you say during the pre-con?
A.
Performing a health check on a SQL Server instance is very similar to getting an annual physical with a physician. The difference is that the DBA is the doctor and SQL Server is the patient.

Q. If there was one practice you wish attendees would give up after attending your workshop, what would it be?
A.
Not taking the time to document each of your SQL Server instances. One of the key components of performing a SQL Server health check is documenting what you have and comparing it against both baselines and best practices.

Q. What have you struggled most with in doing SQL Server health checks?
A.
SQL Server is an overwhelmingly large product, and because of this, there is no way to be able to check everything you would like to check. You have to focus on the key areas, which I will emphasize in my session.

Q. If attendees could take back just one message to their teams about this topic, what do you want them to remember?
A.
As much as practical, try to configure each of your SQL Server instances as identically as possible. It will make your life as a DBA much easier. Of course there are exceptions, but the more consistent you are in configuring your SQL Server instances, the better.
 

Demystifying Database Administration Best Practices
By Argenis Fernandez & Robert Davis

Q. If you could put up a billboard about your SQLRally pre-conference seminar, what would it say?
Robert:
No one has ever gotten fired for following my advice.
Argenis: Pay attention to our pre-con, implement the best practices, sleep better at night. Foolproof plan!

Q. What draws you most to the topic of database administration best practices?
Robert:
A majority of problems DBAs contend with could be prevented by following best practices.
Argenis: Best practices are all about being proactive, about doing things right. Who wouldn't want to talk about doing things the right way?

Q. Where does your workshop take attendees beyond what you might cover in a 60- or 75-minute session?
Robert:
How to distinguish myth from fact and logically investigate recommendations before implementing them.
Argenis: We bring a lot of practical, hands-on experience to this pre-con. Rob and I have been DBAs for a very long time, so we feel it's time to share our knowledge with the community.

Q. What's the most surprising statement attendees might hear you say during the pre-con?
Robert:
Do NOT follow Microsoft's published best practice for this.
Argenis: The fastest query is the one you do not issue (that is, caching on web/application servers).

Q. If there was one practice you wish attendees would give up after attending your workshop, what would it be?
Robert:
Giving people access to SQL Server without asking why.
Argenis: STOP SHRINKING YOUR DATABASES!

Q. What have you struggled most with in the area of admin best practices?
Robert:
Figuring out how to prove that commonly accepted best practices are wrong.
Argenis: That there is no single place that has all of these best practices put together clearly for everyone to understand. We hope to change that with this pre-con.

Q. If attendees could take back just one message to their teams about this topic, what do you want them to remember?
Robert:
Don't automatically assume any advice is correct. Trust, but verify.
Argenis: I have to agree 100% with Robert's answer on this. Don't go and blindly implement something that somebody told you on the MSDN forums. Think before you click!

Join us on Twitter

sqlpass (PASS) - Last chance on 14 June to save EURO 200 early-bird-discount on PASS SQLRally Nordic. http://t.co/8TdeIg5qpz #sqlserver #sqlpass #sqlrally
6/3/2013 4:16:14 PM