Voice of the DBA

Author: way0utwest

  • The T-SQL Tuesday #027 Roundup

    UPDATE: I found a few more posts, and have added them to the round up. Trackbacks didn’t work for some reason.

    I didn’t have quite the level of participation for T-SQL Tuesday #027 that I would have liked. I understand it was a holiday, and many people might have been otherwise occupied (a good thing), and there’s less work for my round up (a good thing), but less information out there (a bad thing). Perhaps it wasn’t a great topic, but in any case, here’s the roundup.

    In the early hours of the day, Rob Farley in Australia gave is a short preview of Big Data coming in 24 hours of PASS.

    Right behind Rob, Pinal Dave in India gave a simple explanation of Big Data that I thought made it easy to understand some of the concepts behind how Big Data and SQL Server fit together.

    Sebastian Meine wrote an interesting piece on purging data, and how large data manipulation operations can benefit from indexing.

    The SQL Philosopher talks about some of the challenges of rapidly growing data in his environment.

    Vinod Kumar has a nice summary of what the challenges of Big Data in general can be.

    Bob Pusateri has a post on why he loves Big Data. I agree with him that Big Data gives the DBA a chance to shine, but also a chance for lots of headaches. You have to decide how you feel about that.

    Mike Walsh has a post on what he’s doing with Big Data, and Hadoop, with a client of his. An interesting read on the application of large data sets.

  • Programmers v Salespeople

    Are sales more important than development?

    Last year my wife moved from a sales engineering position to a sales rep job with her company. It has been a bit of a challenge, but she’s enjoyed it, and it’s been good for the family. On top of a small raise, she has a large potential upside to her income as a sales representative. I’m amazed how much money some of the people in her company make from selling software and services, and I sometimes wonder how it works out.

    Recently I sent her this link about salespeople and commissions. It talks about the problems with commissions and the potential misunderstandings of what commissions actually do for our company. I know that some companies think paying salespeople flat rates and no commission is heresy. I know others that have transitioned to flat rates, including many retail companies, and they have continued to achieve high sales.

    As we debated the benefits of paying commissions,  we argued a bit about the relative value of the positions. She asked me if everyone received a salary, who shoudl be paid more. I said that I thought it was easy to replace salespeople in a company, so developers. My wife countered with “it’s easy to replace programmers.” So for a Friday poll, I thought I’d ask the tech people out there.

    Should salespeople make more than programmers?

    You can assume a commission structure, or salaries for everyone, but when you look at the value each brings to a company, and the ways in which they can help grow business, which is more valuable? Which is easier to replace? Replacing a top performer in either place is probably hard, but what’s your opinion?

    I still stand by the idea that it’s easier to replace salespeople. While I think selling is a skill, I think it’s one more easily learned by a wider variety of the population. I think programming has a fundamental mindset that is hard to teach.

    Or maybe it’s a larger number of people would be more willing to spend their days trying to sell something than sitting in a cubicle writing code.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Creating Your Own Certificates

    Did you know that you don’t need to go to Digicert or Thawte, or any other company to get a certificate to use in SQL Server? You can create your own certificate.

    Why you would want to do this is a longer discussion, but suffice it to say that if your environment allows for self-signed certificates, you have a couple options for creating these in SQL Server and Windows. I’ll show you how easy this can be using these two methods:

    • makecert
    • CREATE CERTIFICATE

    Please be careful if you plan on creating your own certificates. The value of a certificate and asymmetric keys comes in the hierarchy of trust for these certificates and if you do not have a strong hierarchy, you could potentially be making your security worse, rather than better.

    Makecert

    The Windows Software Development Kit (SDK) contains a number of utiltiies, one of which is makecert. It’s a command line tool that creates certificates for you, and It’s easy to use.

    I downloaded the SDK, extracted it, and then fired up a command prompt, running this: 

    makecert -sv "c:\EncryptionPrimer\MyHRCert.pvk" -pe -a sha1 -b "01/01/2012" -e "12/31/2012" -len 2048 -r -n CN="HR Protection Certificate" c:\EncryptionPrimer\MyHRCert.cer

    This code creates a private key file (MyHRCert.pvk) and a public key certificate (MyHRCert.cer)

    You can click the link and read the parameters, but it’s really that simple. When you create this certificate, you can use the FROM FILE options for CREATE CERTIFICATE to load this certificate into your SQL Server.

    CREATE CERTIFICATE

    I guess technically you are using the CREATE CERTIFICATE in either case here, but this section looks at the actual creation of the certificate by SQL Server.

    CREATE CERTIFICATE is standard DDL, like so many other commands in SQL Server. The parameters are similar to those for makecert. Here’s a statement that matches up with the one above.

    create certificate MySalaryCert
   ENCRYPTION BY PASSWORD = N'R3allyToughP@ssword4You'
   WITH SUBJECT = 'HR Protection Certificate',        
   START_DATE = '20120101',
   EXPIRY_DATE = '20121231';

    Note that you don’t need to specify the algorithm or other parameters. SQL Server handles that for your. You also don’t need to specify the two files here. The database engine stores these keys inside the database. You should make a backup of them, and you can use the BACKUP CERTIFICATE command to do this.

  • Use Your Tools

    I used this tool for the first time and found it very handy.

    Someone asked me recently if I’ve ever exported a table using SQL Packager, a tool from my employer, Red Gate Software. I hadn’t, and in fact, hadn’t ever even opened the tool. So I started it up and exported a table. I was surprised how easy it was, and I wrote up a short blog on it.

    That reminded me of a common issue that many of us have: we get into a rut. It’s easy to stick to doing things the “old way” we’ve learned, and not updating our skills to take advantage of newer features.  It’s also easy to get used to going through a process one way and never trying, or experimenting with different techniques or applications of the tools.

    I have been guilty of this, and am trying to rectify it, working with new features, and trying out new SQL Server 2008 R2 or SQL Server 2012 T-SQL changes where I can. I noticed Grant Fritchey recently talking about Extended Events and the advantages of using them with deadlocks, and also using them for performance tuning. Learning Extended Events is an area I need to spend some time with in the future, and I’d recommend most other SQL Server professionals do the same.

    However it’s not just the changes in SQL Server. There are changes in tools from vendors that can help us do our jobs better, or even tools we don’t know we have. I have spoken with lots of Red Gate customers that weren’t even aware of the capabilities of the tools on their machines. In some cases they weren’t even aware they had the tools because they were purchased in a bundle. Not every tool is useful, and not always appropriate, but it’s worth a little time investment to learn how to use the tools and gain some awareness of their capabilities.

    We publish some information on the Red Gate tools at SQLServerCentral, and I constantly find great blogs written by people that actually use the tools in their daily work. I suspect that’s the case for other tools as well. Take some time and read about the tools you own, and even the ones you don’t. You might find one that will actually save you time, make your job easier, and provide a nice ROI for your company.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.