So this last weekend was the 13th SoCal Code Camp (the 6th at this location). I presented three different sessions at this code camp. My slide decks can be downloaded below.
If you attended the sessions please rate my presentations on SpeakerRate.com/mrdenny.
OK, everyone it’s time to come out west. There are two SQL Saturday’s scheduled for April 9th, 2011 here on the west coast. Personally I’d love to see you all show up at our SQL Saturday event down here in Huntington Beach (Orange County, CA). The weather will be beautiful (OK so I can’t guarantee it, but there’s like a 95% chance of great weather in April in Orange County).
The SQL Saturday is just a few minute drive from the beach, if you want to bring your families and they like the beach. If the beach isn’t their thing Disneyland is only a 30 minute drive away (the multi-day tickets are a MUCH better deal than paying for single day tickets, Costco usually has a pretty good deal on tickets as well) and what family doesn’t like going to Disneyland while mom or dad is at SQL Saturday. There’s plenty of great shopping in the area at South Coast Plaza (just 5-10 minutes down the freeway) as well as The Spectrum (about 20 minutes down the freeway. We’ve got a great after party in the planning, that some of the local MVPs are putting together.
Hopefully you can make it out here for the SQL Saturday. We had about 150 people last year (with 6 weeks notice) and this time we are hoping for 250. If you can make it down, we’d love to have you and you’ll probably get a pretty good turn out.
If you’ll be flying in Orange County (SNA) airport is the closest, Long Beach (LGB) is the next closest, Los Angeles (LAX) is the next (but this airport is huge and is a pain to fly through). Your next best choice is Ontario (ONT) but is about an hour from the SQL Saturday site. Andrew and his team have gotten a great hotel setup for us at the Huntington Beach Marriott. If you are going to stay at a different hotel, check with Andrew or me first as some of the hotels in the area really suck. I used to work down the street from the college where SQL Saturday will be held, so I know where the decent hotels are.
See you in April.
In case you missed me when I was in Tampa last week at the awesome SQL Saturday 62 event, all is not lost. I’ll be back at the Dev Connections March 27th-30th, 2011.
I’ve got three sessions scheduled for this event.
- Exploring the DAC and Everyone’s Favorite Feature, the DACPAC
- SQL Server Clustering 101
- Getting SQL Service Broker Up and Running
Hopefully I’ll see you at the event while I try and rip a few attendees away from Paul and Kimberly’s sessions.
So a couple of nights ago Paul Randal (Blog | Twitter), Wendy Pastrick (Blog | Twitter), Jonathan Kehayias (Blog | Twitter) and I were talking about how some of our demo’s have completely and totally failed, often in front of a live audience. As we all were chatting about our various demo’s crapping out we came to the realization (ok, we had all already come to this realization separately) that when your demo fails, how you handle it is how you prove that you are a truly good speaker.
Speaking by it self isn’t all that easy for a lot of people (oddly not me, but I’m kind of an attention whore) but when that demo blows up, and it will at some point, how you handle that is where you really show that you know the product. Since it is a little hard to tell a good story in 140 characters, I decided that a blog post would be a good way to give my story.
Windows just won’t cluster
So my first mega fail was actually not in front of a live audience (unless you count the recording engineer). The first time I did a recording for the SSWUG conference (I think it was the first, I’m going to record by third or fourth set of sessions soon) one of the sessions that I did was on SQL Clustering. During the session I walked through the Windows 2008 clustering process and got the SQL Installation started. I would jump back to it through out the session so the demo was throughout the session because sitting there watching the wizard running which I do nothing isn’t very exciting.
So I tested everything before I left home and everything was working perfectly. I decided to test everything from the hotel the night before (I always fly in the night before when I do the recordings) and when I ran through the clustering validation wizard it took 3 or 4 times for me to get a successful validation. At this point it was late, so I called it a night. When we did the recording the next day, wouldn’t you know it the damn validation wizard just wouldn’t work. Which means that SQL Server wouldn’t install on the cluster as SQL won’t install on a cluster that hasn’t passed validation. So I just had to wing it, and explain that this is what you should be seeing on this screen, etc.
Needless to say the session went great, and was a pretty good length (I think I went really close to the one hour limit on it) and the reviews were great. I even got some positive reviews for leaving in the problem demo and not refilming it to make it look correct.
OK, who’s set off the fire alarm?
My second story is more recent, and was in person. At the 2010 SQL PASS Summit I was doing a quick 45 minute storage session during Buck Woody’s post-con on Sharepoint. During my talk the fire alarm for the building started going off. It wasn’t so loud that you couldn’t here me, but it was a bit annoying to listen to (I suppose that is the point). Someone come in to tell us that we didn’t need to leave, which was good since I was still talking, with occasional pauses to yell at the building, but we worked right through it.
What’s happened to you when you present?
So what sort of fun would this telling of the nightmares be if I didn’t open it up for you to tell us about what sort of problems you’ve had with your demo’s or sessions (hopefully Buck Woody (Blog | Twitter) will post something, he’s got some great stories). If you aren’t syndicated on SQLServerPedia.com or SSC please link back to me, so I can compile a master list later.
So it is time for another vote for the second category that I have a SQL Rally session submitted for. This time the vote is for the “Enterprise Database Administration & Deployment” track. I’ve got a session up titled “Using SQL Server Denali’s Always On” again in the Summit Spotlight section.
The abstract for my session is:
In this session we will look at the features which are provided with Microsoft SQL Server “Denali” as part of the “Always On” features including site to site configurations to allow of a large scale high availability solution without the need for any high end SAN storage solution. Additionally we will be looking at the ability to have redundant servers which can be used for reporting or for taking your backups reducing the load from the production database.
So, I’m guessing that my first solo book must be getting close to shipping. You can now flip through the first 11 pages of “Securing SQL Server” (preview page) on Amazon’s website. Now the images in the online preview are in color, but the book won’t be (or so I was told) so they must have used my original images to put together what Amazon is showing.
This is what I’m guessing is one of the last steps before the book is actually shipped.
Now for those of you that are going to wait for the Kindle edition, you’ve got a little longer to wait. While it is available to view on Amazon, you can’t purchase it yet. I’ve been told by the publisher that it’ll be about 3 months behind the print version.
So I got an email from someone (and yes he told me that I can publish this post about it) because he was having an argument with his storage / systems team about LUN config for the SQL Servers. He wanted smaller LUNs so that they could be more easily moved around if performance problems showed up on the array. His storage / system folks big argument against this was that it was complex to setup, so they didn’t want to do it. When I got to this “argument” I knew that this blog post was coming.
As IT professionals our job is to design and build systems which meet the performance requirements of the applications which will sit upon them. And to keep those systems running for as long as the business determines that those systems are useful to making the company money. We as professionals (those that know me can stop snickering when I call myself a professional) shouldn’t be designing systems a specific way just because it is easier to do so. If that way doesn’t support the needs of the application then it is the wrong way.
In the case of storage, there are lots of systems out there that needs lots of LUNs for one reason or another (usually to spread the load out). After carving up the LUNs and presenting them to the SQL Server, you mount them as mount points and setup the dependencies in the cluster admin tool (this server is clustered I’m told) and you are done. There’s not much do “manage” from the disk level at this point on a day to day basis. If everything is sized correctly then the LUNs won’t need to be grown for quite some time and everything can just be left as is.
In short, quit being so lazy when designing systems. Don’t take the easy way out just because you can. Design the system correctly so that you don’t have to redesign it later. I can’t tell you the number of months that I’ve spent redesigning systems because they weren’t done correctly the first time. If you need help designing a system ask someone, there are lots of people who will be happy to help. But don’t make poor planning decisions just because you don’t want to do a little bit of extra work.
The SQL PASS organization has taken a different approach to session selection for the SQL Rally than they normally do for the annual summit. Instead of a full program committee which selects sessions then announces them, they are leaving the session selection up to the community via a vote. This weeks voting is for the Database/Application Developer track. Within that track sessions are broken down into 11 categories. As a former SQL PASS summit speaker my session does into the Summit Spotlight track, which is probably the toughest track to be in as everyone else in the Summit Spotlight track is also a former summit speaker.
The session which I’ve submitted as a Database/Application Developer session is called “Where should I be encrypting my data?”. In this session we’ll be looking at all the various places within the application stack that data can be encrypted. This includes the application layer, the database layer, encrypting over the wire, transparent data encryption, encrypting using your MPIO driver and offloading encryption to your HBAs. We will look at why and how you encrypt data at all of these levels, and learn when to use each one. As data encryption is a must for any business doing business in the United States, this session is a must for any database or application developer.
Voting for this round of the SQL PASS sessions is being done the week of January 17th-23rd, 2011 only, so you’ll need to vote soon for your vote to count. If you would like to be emailed when the next rounds of voting happen, you can register for that as well.
The way the session selection will work (as I under stand it) is that the number of sessions have already been selected. The top sessions from each group will be given spots at the SQL Rally event, so getting the word out is very important. As is the fact that people need to be sure to vote for sessions that they want to see.
I gave two talks at the recent SQL Saturday 62 in Tampa, FL and I had a blast doing it. As promised I’ve posted them on Monday (it is still Monday my time, so that counts right)?
Thanks everyone for coming to my session. Hopefully I’ll see you at the Tampa SQL Saturday next year.
The short answer is as much as possible.
The more exact answer is you typically can’t allocate cache to a specific LUN. You can usually carve up the total amount of cache into read and write cache. You want as much write cache as possible so that the database writes directly to the disk as little as possible.
There is no number that I can give saying that you need X amount of write cache for a 500 Gig database, because it doesn’t depend on the database size. It depends on the amount of data change per minute, how fast the data can be destaged from the write cache to the disks, and how much load is being placed on the disk for reading data.