One of my biggest annoyances with SQL Server is how it stores dates and times in some of the MSDB tables. In this case, I’m looking at sysjobhistory. SQL Server stores these as integers. Worse yet, the date and time are in different columns. Crystal Reports has no idea that these are actually date and time values.   You get something that looks like this.

Screenshot: Date and Time in different columns

It’s hard to do calculations on this, let alone have it look presentable. To fix that problem, I give you the Crystal Reports formula from hell.

datetime(
tonumber(left(cstr({sysjobhistory.run_date},0,”"),4)),
tonumber(left(right(cstr({sysjobhistory.run_date},0,”"),4),2)),
tonumber(right(cstr({sysjobhistory.run_date},0,”"),2)),

IF len(cstr({sysjobhistory.run_time},0,”")) =6
THEN tonumber(left(cstr({sysjobhistory.run_time},0,”"),2))
ELSE IF len(cstr({sysjobhistory.run_time},0,”")) =5
THEN tonumber(left(cstr({sysjobhistory.run_time},0,”"),1))
ELSE 0,
IF (len (cstr({sysjobhistory.run_time}))) < 3 THEN 0 ELSE tonumber(left(right(cstr({sysjobhistory.run_time},0,”"),4),2)),

tonumber(right(cstr({sysjobhistory.run_time},0,”"),2))
)

Is it ugly? Yes.
Does it look hacked together? Yes.
Is it messy? Absolutely.
Is there a better way? Probably.
Does this work? Hell yeah!

So now we have something that looks much more presentable in a report.

Screenshot: After the formula

I like this much better. By putting the date and time into a formula that is in a datetime format, it allow us to do things like sort, group, and calculate.

To be honest, as great as this works, I want to find a better way, without all of those type conversions. If I find it, I’ll let you know.

For most of our key business applications, we have two sets of servers, a primary and secondary. The secondary servers are in a different data center. Fortunately, bandwidth isn’t a problem.

I need to keep my secondary servers current in case the primary data center becomes unavailable. This is the perfect place to implement log shipping or database mirroring. Unfortunately, we also use the secondary servers for testing. That means we do it the old fashioned way, backup the primary and restore to the secondary. I’m not saying it’s right, but it’s the environment I have.

I’m a complete nut for consistency. When I inherited this environment, we had network shares and copy scripts for database backups. No two applications did their backups the same way. One day, I ripped it apart and put it back together. Since all of my database servers use the same domain service account and that service account has administrative rights on all database servers, security isn’t a problem. It also means I can write to the administrative shares on other servers without the need to create shares or users.

First, I wrote a single script that gets used across every primary server. With a few parameter changes, my script works for every system. Basically, I build a list of databases and then back them up to the file system on the local file server. That’s the one that gets sent to long-term storage. Next, I write the backup file to the secondary server.

My script is on my site. I’m really proud of this and it has served us well. As you’ll see in the comments, this works well in our small environment with lots of small databases.  This won’t scale well after we double our current size.

Of course, I still back up my transaction logs. I would love to hear some feedback from other DBAs who can help me make this better.

My next step is to write a consistent recovery process.

In larger environments, monitoring software can do this for you. I bet this could be done in System Center Operations Manager. In the meantime, though, I’m doing this the old-fashioned way.

The MSDB database has a vault of information that I’m just starting to explore. I’m sure somebody else has figured this out somewhere else. I figured this one out on my own and thought it was worth sharing.

The sysjobhistory table shows the execution of all of your SQL Agent jobs, broken down by step. If the step_id is 0, that means it’s the job as a whole. I filter those out. By getting an average of the run_duration, we can see how long things usually take.

select job_id, step_id, avg(run_duration) average
into #recentaverages
from sysjobhistory
where run_date > @historydate
and step_id > 0
group by job_id, step_id
order by job_id, step_id

There is a @historydate variable that I use to hold a date of 30 days ago.

Screenshot: Job history average execution times

Next I took that temp table and joined it back to sysjobhistory, filtering out anything that runs in less than ten seconds. I also use @analysisdate for everything since yesterday.

select sjh.job_id, sjh.step_id, sjh.run_date, sjh.run_time, sjh.run_duration, ra.average
from sysjobhistory sjh
inner join #recentaverages ra
on sjh.job_id = ra.job_id
and sjh.step_id = ra.step_id
where run_date >= @analysisdate
and sjh.run_duration > ra.average
and sjh.run_duration > 10

Screenshot: Job executions running above average execution times

Already, I can see one job that has several executions that are running longer than usual. This appears to be a job that runs hourly and six runs in the past 24 hours ran longer than usual. This could be a problem and warrants investigation.

Finally, I join this data to be sysjobs and sysjobsteps to find out who the culprits are.

select sj.name, sjs.step_id, sjs.step_name, run_date, run_time, sjh.run_duration, ra.average
from sysjobhistory sjh
inner join #recentaverages ra
on sjh.job_id = ra.job_id
and sjh.step_id = ra.step_id
inner join sysjobsteps sjs
on sjh.job_id = sjs.job_id
and sjh.step_id = sjs.step_id
inner join sysjobs sj
on sj.job_id = sjs.job_id
where run_date >= @analysisdate
and sjh.run_duration > ra.average
and sjh.run_duration > 10
order by sj.name, sjs.step_id

Screenshot: Shows the job and step names for jobs that are taking longer than average

I now know my jobs and steps that may need to be investigated. Unfortunately, I had to block out some proprietary info, but you certainly get the idea of what’s going on here.

This could certainly be tweaked to look at the job as a whole instead of steps. Do that simply by looking only at step_id = 0 in the first query. Another option is to add a threshold that looks at anything like 10% above average.

Drop this into a SQL job that e-mails you when this script finds data, and you have a pretty powerful tool in your arsenal. You can find my entire script on my site. In the meantime, I have a longer-than-average running job to investigate.

I’ve read some of the following ideas about naming standards:

• Tables should be prefixed with tbl

• Views should be prefixed v_

• Stored procedures should be prefixed with usp_

• Objects should be all UPPERCASE

• Objects should be all lowercase

• Objects should use camelCase.

• Objects should use ProperCase.

• Tables should reference singular items (order vs orders)

There are a lot of different rules here, and to be honest, I think they’re all crap. What works in your environment probably won’t work in my environment. Rules for a new project may be different than rules for an existing project. Systems developed in-house will probably have different rules for off-the-shelf software that gets customized.

From my perspective, there are four things that actually matter with naming standards.

1. Choose a standard that works for your environment and stick with it. It needs to work in your environment, and everybody needs to use it. This includes developers, DBAs, report writers, and even managers. As a DBA, we have to enforce those standards. And if it means sending something back to a developer because the standard wasn’t followed, it may mean playing the bad guy. At the same time, we have to lead by example when we put objects in place ourselves.

2. Object names must make sense. I used to work for a guy who loved to call his temp tables names like #temp, #temp1, and #temp2. What the hell is in that table? If we had a naming standard to enforce, it would have been an awful lot easier to manage this situation. In my current environment, an off-the-shelf product has a table that stores customer orders. Naming this table something like CustomerOrders, customer_orders, or even OrdersCustomer would make perfect sense to me. I know by looking at the name that the table stores customer orders. However, this particular vendor decided that co would be a perfectly valid object name. Yes, the table name is co. It’s hard to yell at a developer you’ve never met.

3. SQL Server allows your object names to be upto 30 characters. Don’t be afraid to use them. I’ve already ranted about calling the customer orders table co. Other names that are too brief would be custord or custordr. I once had a developer tell me that he preferred to abbreviate object names because it was less work for him when writing code. It’s one of the few times I will advocate physical abuse of a developer. That’s just being lazy. Now that most editors have some form of code completion, I just don’t buy that.

4. Object Names should not use reserved words or variations of them. This should be a given. Not everyone gets it, though.

No two environments are the same. Use what works for you. When everybody follows the standard, the standard works for everybody.

Let me preface this discussion by reminding you that most of my experience as a DBA is in smaller environments. If you’re in a large enterprise, Access shouldn’t even be an option. Most of the DBA bloggers deal with terabytes of data and thousands of user connections. I’d never tolerate an Access database in those environments, either.

But lets say we have a small application for a workgroup that only has a few hundred megabytes of data with no more than a hundred users. Access can be entirely practical, provided one simple rule is followed–no local Access tables. When you pair Access as a front end with a SQL database backend, this can be an incredibly powerful combination.

In this combination, you can leverage the power of the SQL DBMS with the ease of use of an Access database. Better yet, this combination allows you to enforce security, constraints, and backups on the back end, where they should be. One of the biggest complaints about Access is that it’s security features don’t measure up to SQL Server. Instead, we can leverage the power of SQL Server’s security features.

Access backups are restricted to that one file that holds everything. SQL Server handles backups much better. The best part of this is that if the Access database gets corrupted, we can recover from ANY recent backup without data loss. As the DBA, I’m responsible for backing up the data, and nothing in this scenario changes that.

Don’t get me wrong. I rarely advocate the creation of an Access database. In fact, I’ll be the first one to point the user to Sharepoint for small applications. Still, Access should have a seat at some tables, even mine.