Author: way0utwest

  • SQL Saturday #28 – Slides and Impressions

    I’m late, I suck, but here’s some things I started in Baton Rouge and am just now getting out.

     

    First, I’ll add my slides to the SQL Saturday site soon. I did two presentations and the keynote, which I posted yesterday. However I know a few people want to see them, so I’ve added them up on SQL Saturday to a static page I built.

     

     

    Impressions of SQL Saturday #28

    I have to say that Patrick LeBlanc’s enthusiasm is infectious. There is a whole team of people in the local area that I was thrilled to see again and impressed with the level of effort they put into making the event run smoothly. They’re always happy, very welcoming with Southern hospitality, and they make the event a lot of fun for everyone involved, especially those of us that come from out of town.

     

    I grabbed a little video and some images, adding in a little narration. Nothing special, but some memories for me:

     

     

    This was an impressive lineup of speakers. Not to take away from the local speakers, who did a great job, but I believe Patrick had 14 MVPs, many from out of town like me, that came to the event. The speaker’s dinner was great, with about 50 people there, which is huge. Many I’ve attended had about 12 people. Patrick even personalized shirts for us. I don’t wear many of my SQL Saturday shirts, but I’ll wear this one.

     

    The event ran very smoothly. The group gets the use of a building a LSU, which is a beautiful place. They had two hallways, with food and sponsors in between them. As much as many people don’t want to see vendors, those people and their money is the reason the event runs. Remember that the next time you don’t want to hear about a product or pass a table.

     

    I had one of four early morning sessions that gave people something to do if they arrive early, and helps beginners get some basic knowledge. I’d like to see this at more events. Then I gave the keynote, which can be a challenge at many places. About 250-300 people were there, I hurried a bit, but I think it went well.

     

    Then it was a full day, 8 or 9 tracks, of sessions. There was even a great .NET track run by a guy basically giving a full day of .NET basics to people. I loved that!

     

    Lunch went smooth, with some optional vendor presentations (see three paras above), but they were sparsely attended. Lots of people sitting around instead, which is fine. I think lunch is a good decompression time.

     

    After lunch, more sessions, and I walked between a few, trying to get some clips of different people, checking out some speakers that I, surprisingly, hadn’t seen before. I popped in to watch Sean McCown, Tim Costello, Denny Cherry, Wes Brown, and a few more. I made it a point to watch a few people talk.

     

    The hallways were mostly dead during sessions, a nice sign. People were coming for training. I shook a lot of hands, and had a lot of 3 minute conversations with students that attended various colleges, even some out of state. They were looking for some basic training. I met local people coming to get some knowledge that the boss wouldn’t pay for, and even a guy that had driven 3 hours from M-eye-ess-ess-eye-ess-ess-eye-pee-pee-eye for training since his employer didn’t pay for much. I queried everyone if they thought it was worth it, and got all positive responses.

     

    A long day, especially for me since I started at 6:30 and left around 5:15. I went for a run on lovely University Lake before going to the after party (after showering). It was mostly for volunteers and speakers, but I had fun chatting with people until around 10 when I left to get dinner.

     

    All the SQL Saturdays are good events. I haven’t seen a bad one, and they have tended to run fairly smoothly. The only things I noticed here were a lack of water (we ran out in the afternoon, but had lots of Orange soda) and the raffle at the end was hard to hear Patrick. For the latter, I told him they should be up on the stairs, not at the bottom. For the water, I know there’s a lot in the air, but more would be nice, especially since I try to promote being healthy. Patrick had fun as there were tweets asking us to drink Orange Soda and then he raffled off a case at the end.

     

    The enthusiasm and fun that that the volunteers have, the jokes they make, and even the tweets coming out make this the most fun of all the events I’ve been to.

    A few other links:

  • The DBA Financial Analyst

    The DBA job is somewhat nebulous, with a variety of skills being needed, and the mix of those skills varying from company to company. As companies look to save money, and look to perhaps go with cloud computing or other types of hosted environments, are DBAs going to need to also perform financial calculations?

    I was reading a post on SQL Azure recently that talked about the cost of indexes. Not performance, or space, but actual real dollars and cents cost since indexes take up space and you are charged by the space you use. Adding extra indexes, or adding columns to indexes, or adding covering columns, can cost you real money if you have any large scale of resources.

    So does that mean that in addition to trying to determine what changes you can make to code to improve performance, or what new features might make sense to your applications, you need to also run some financial ROI calculation on the choices? Maybe PowerPivot was released just in time for all those virtual systems that might charge by the byte or cycle.

    As a DBA, I’ve had to budget, and try to determine  how to spend funds for hardware, balancing out choices for RAM v disk v CPU, and even comparing secondary servers for read-only scale out against a larger single server. However I typically don’t have to compare the cost of features in my analysis.

    I’ve sometimes wished I could pay for just one feature, and it’s starting to look like that might be something that could happen in the cloud. While the possibility if mix and match features intrigues me, the extra work to add cost to my calculations along with performance makes me think the cloud might be more trouble than it’s worth.

    Steve Jones

  • You Don’t Need Log Backups

    You don’t need log backups. You don’t. They aren’t required for SQL Server to function.

    The place when you don’t need log backups is when you have a database operating in the Simple recovery model. In this model, your transaction log will clear out on a regular basis, every few minutes, and the space will be reused.

    I saw a post recently where someone said they had a database that only changed once a day. Data was loaded once a day and otherwise the database was read only. In that case, you:

    • Need log backups if you are in Full or Bulk-Logged recovery models
    • Do not need log backups if you are in simple mode.

    It doesn’t matter how many changes you have, if you don’t have log backups in full recovery, you’ll eventually have an out of control log growth situation.

  • When To Touch

    It seems that every product that has an underlying database has documentation that says not to modify the schema?  Do you always pay attention to that warning? The PSS blog at Microsoft says that for Reporting Services you ought to definitely keep your hands off, and gives some good reasons why you should.

    However what about those other products? Dynamics, SAP, JD Edwards, and other common types of software that many companies use. Can you modify them at all? Perhaps.

    We hear about the build vs. buy debate in software, but there’s also the modify vs. workaround argument. I was reminded of that from the PSS blog. There are times that you might be tempted to change things in a database built a software company, or add objects to that database. In many cases this can be seen as action that voids any support contract with the vendor, and more often than not they won’t want to give permission to make changes.

    I can understand that, as it can substantially increase the support costs for a software company. However I also think that a blanket policy prohibiting changes is a bad idea.

    I think there are plenty of things that you can do, especially with the latest versions of SQL Server, that could be useful “touches” that improve the use of a database. Adding indexes judiciously to improve performance of some queries is one very light touch that can add tremendous benefits. Adding reporting objects in another schema could help you extend functionality to get more value from the software.

    Touching a database that you didn’t build should be done carefully, lightly, and with a lot of testing, and it can be something that creates a much more valuable system.

    Steve Jones