Author: way0utwest

I actually got back from camping Sat night, but since I wasn’t scheduled to come back until Sun afternoon, I avoided the computer. I let both the desktop and laptop remain at idle, not even checking personal email until Sun night.

When I checked Sun night, I saw a newsletter scheduled, and thought I was in good shape for today. I didn’t look closely enough, as I woke up to an email asking why Database Weekly was still sending and why the SSC newsletter hadn’t gone out.

Doh!

That was the DBW one scheduled. I checked my browsers and sure enough I had the SSC one up there, just not saved 😦

Our system is a little weird in that when we create the DBW newsletter, it is created for Monday. We then test it and once it’s OK, we leave it alone except that we change the schedule date back to Sat or Sun and save it. I forgot to do that.

And when I glanced at it last night, I then didn’t realize that I was looking at Database Weekly ready to go out and not SQLServerCentral.

So much for that goal. That’s 2 this year 😦

It seems that often I see posts that say “I’m out of space on my drive, what do I do?” The answer, as with most anything in SQL Server is, it depends.

Backups

The most common issue I see for running out of space is the lack of deleting database backup files. The maintenance plan wizard instructs you to perform backups, and defaults to making a separate file for each backup, but it doesn’t necessarily clue in the “Accidental DBA” to remove old backups.

You need a maintenance cleanup task here and set it to remove old backups, but be sure that you have a new, good backup first. In other words, the maintenance cleanup comes after the full backup, and then only when that task completes with success.

You can delete old backup files manually, but think about how many you need to keep. Most people probably can get by with 1 or 2.

IIS Log Files

I know lots of people that have IIS on the same box with SQL Server for small to medium web sites. Unfortunately IIS doesn’t have a maintenance cleanup task. It creates new log files on a daily or weekly basis, and those will fill up your disk when you are least expecting it.

These are in the LogFiles folder under System32 on your system drive. Set a reminder in Outlook to trim these down occasionally.

Transaction Log

Another very common issue is that transaction log growing to fill all disk space. This happens because so many new DBAs assume that a full backup also includes a log backup. It doesn’t, for multiple reasons, and it doesn’t matter if it should or no; it doesn’t.

What you need to do here is first make sure you have time, and then clear the log. That’s a log backup with truncate in versions 2000 and prior. It’s setting to Simple mode in 2005 and above and then . Be sure you set the mode back to Full.

Once you have space back, I’d recommend you take a full backup. You can get by with a diff, or maybe wait until your next scheduled one,but I’m conservative. I’d recommend a full backup right then. Once that’s done, you need to get a good size for the transaction log. Unfortunately that requires some trial and error.

The size of your log file depends on the load your database experiences in terms of changes, but also on your log backup schedule. A log backup allows the space in the log to be resused. If you produce 10MB of changes an hour, and back up once an hour, you need a log file that’s 10MB. Actually you’d want it larger to account for a larger load some hours, but you get the idea. If you backup the log once a day, you’d need a 240MB log ( plus pad).

So, what I’d recommend is that you schedule hourly log backups. See how large the backup files are and then size your log file appropriately. As far as the initial size, you can run a DBCC SHRINKFILE to make your log file smaller. I’d lower it to 1GB to start with. That’s just a guess, and you might want to set it to 10% of your data files, but disk space cheap, and 1GB will accommodate lots of databases.

Summary

There are other reasons, like your data file growing, but I’m not trying to cover every situation. If you’re new to SQL Server, and you have a full disk, check these items first. If none of these help you, post a note in our forums and someone will answer.

This is a great write-up that shows what is important in a phone. It’s how you interact with it, not the features, not the specs, it’s how you use it.

I tend to agree with that. With both the G1 and the iPhone, the interaction with the device for the most part, has not been on the phone. It’s been twitter, web, reading, music, and the smoothness of those two devices is unbeatable.

I hope that more phone manufacturers realize this and they start to build up their networks of apps. The app store with Apple, and integration with a PC to allow me to manage things either on the PC or the phone, it’s unbeatable. If I could have read books from Barnes and Noble or Amazon on my G1, I might not have moved to an iPhone, but I couldn’t and that mattered.

I’m not sure how big a deal it is for everyone else, but I see more and more people doing things on their phones that aren’t involving making calls.

People building SQL Server apps, especially BI apps ought to consider these markets and look to build small applications that ensure a smooth interaction with customers. As much as I like browser apps onthe desktop, they don’t work on a cell phone, even one with as large a screen as the iPhone of G1.