But, it still works FINE…

A good many companies still have servers chugging along on SQL Server 2000 (or even, as some of us noted on Twitter, SQL Server 7.0 and 6.5) . If you’re one of those companies, and you’ve never had a problem with it, why should you upgrade?1, stability: It’s completely out of support. Microsoft won’t release any new patches, and won’t help you if (when) something blows up. New viruses or bugs out there can find and exploit your server.

2, applications: Vendors increasingly don’t release to or support software on SQL Server 2000. Your apps are out of support, too, and your monitoring and alerting options are increasingly limited.

3, maintainability: It’s getting harder and harder to find DBAs with SQL Server 2000 experience. Make no mistake, 2000 is an entirely different animal. When I work with it, I have to take the (billable) time to backward-port all of my day-to-day scripts – scripts that make heavy use of the system views and other improvements they’ve made in the eight years of post-SQL 2000 releases. You’re actually costing yourself quite a lot of money over time if you have contractors and consultants supporting your 2000 instances.

4, migration: It’s getting harder and harder to migrate from SQL 2000 to the newer versions. It’s already a two-step process, and you’re piling up the deprecated features. Eventually it’ll be so difficult, you may have to recreate your entire system and code a data port from the old system, just as if you were getting off of another RDBMS entirely.

These aren’t the only four reasons to upgrade from SQL Server 2000. We’ve barely mentioned the wild array of new features in each successive release. But think about it: you’re going to have to move your data into a robust, supported system eventually. Why wait until something goes really wrong?

Happy days,
Jen McCown
http://www.MidnightDBA.com/Jen

This is our brand-spanking-new session for the interviewERs…those who question, vet, and rant about it afterward. Check out all the details on the PASS Session Details page. And while you’re there, feel free to take a look around at the other community sessions.

So, to review:

• PASS Summit 2013 is in Charlotte, NC
• On October 15-18
• With pre-conference sessions October 14-15
• Discount (good ill June 30) is $800 off the final rate , and you can get another discount from your local PASS Chapter (see here).

There, I think we’ve covered it all.

Happy days,
Jen McCown
http://www.MidnightDBA.com/Jen

• 5/18/2013 – Atlanta - Scheduled to speak.
• 8/3/2013 – Baton Rouge - Submitted. Call for speakers closes 6/1/2013
• 8/17/2013 – NYC - Considering. Call for speakers closes 6/18/2013
• 8/24/2013 – OKC - Submitted. Call for speakers closes 6/21/2013
• 9/14/2013 – KSC - Submitted. Call for speakers closes 7/16/2013
• 9/28/2013 – Denver - Considering. Call for speakers closes 7/30/2013
• 10/15/2013 – PASS Summit – Submitted. Call for speakers closed.
• 12/7/2013 – D.C. - Considering. Call for speakers closes 10/8/2013

Let me know where you’re going to be! Maybe we’ll cross paths, shake hands, share info, sing a song…

Happy days,
Jen McCown
http://www.MidnightDBA.com/Jen

SELECT LEFT(physical_name, 1) as Drive,
SUM(size)*8/1024 as SizeMb
FROM sys.master_files
GROUP BY LEFT(physical_name, 1)
ORDER BY Drive;

And then I compare the numbers I got back against what Windows says. Hmm, odd. SQL says it’s using up 296,869 Mb (that’s ~289 Gb) of space on U:\, but when I go to Start > Computer it says it’s using up 390Gb of space on U:\.

Rogue files! Rogue files on my data drive! I now have to HUNT DOWN AND PUNISH those 101 Gb of files freeloading on my data drive. And oh, how they’ll pay….

First, Gather Data and Compare

Step 1: Get the physical_name of all files on that drive from sys.master_files. That’s easy: SELECT physical_name FROM sys.master_files WHERE physical_name like ‘U%’;

Step 2: Open powershell, navigat to U:\, and run get-childitem -name -recurse -filter *.*

Step 3: Compare the lists. You can, of course, import to SQL and compare that way, or just paste each list into Excel for a look-see.

Sure enough, there were about 100Gb of duplicate data files – MDFs, NDFs, and LDFs, if you can believe it! – on that server that hadn’t been touched in years. Time for vengance…

Delete Files, if you Dare

There are a number of ways we could go about removing these files, of course. In my case, it so happens that all my current, supposed-to-be-there files have recent modification dates, and everything else is pre-2012. That makes it very easy!

Let’s start with a test script, that will just list the things we want to delete:

get-childitem “U:\SQL03\” | where {$_.lastwritetime -lt (get-date).adddays(-365) } |% {write-output $_.fullname}

Explanation:

• get-childitem “U:\SQL03\” |    Get all objects in the specified directory, and pipe them to the next operation.
• where {$_.lastwritetime -lt (get-date).adddays(-365) } |  Test each item’s “last write time” date against today -365 days; if they’re earlier than that date, pipe them to the next operation.
• % {write-output $_.fullname}   Take each item and output its name.

Awesome. All we have to do to change this into a dangerous, file-destroying script*is to replace write-output with remove-item.

Wait, I could use this to routinely clean up old backups too, right?

Funny you should ask! Yes.

Let’s say you want to delete backup files in a dedicated folder that are older than N days, and repeat regularly. Just take this and schedule it in a SQL Agent job! (You might want to change the -365 to -30, or whatever your given retention period is, in days.)

Yeah, but my SQL backups go to a UNC share

Except that your backups aren’t on a local drive; they’re on a UNC share, and you’re getting a weird error. No problemo!

Your new, file-destroying script* that will indeed delete all files older than 30 days now looks like this:

cd “\\Server01\SQLShare”; get-childitem “\\Server01\SQLShare \SQL03\FULL” | where {$_.lastwritetime -lt (get-date).adddays(-30) } |% {remove-item $_.fullname}

Let’s make this slightly safer, and only delete the *.bak files older than 30 days:

cd “\\Server01\SQLShare”; get-childitem “\\Server01\SQLShare \SQL03\FULL” -filter *.bak | where {$_.lastwritetime -lt (get-date).adddays(-30) } |% {remove-item $_.fullname}

 There we go, wielding Powershell like Foe-hammer in a goblin cave**. Feels good, don’t it?

Happy days,
Jen McCown
http://www.MidnightDBA.com/Jen

*Note that the sys.master_files “size” column isn’t in Mb, but in pages.  To translate pages to Mb, SELECT name, (size*8)/1024 as SizeInMb from sys.master_files.
*Which you will test thorougly before you use in a production environment, So Help You Codd.
** Too nerdy?

Inspirational code source: Powershell delete files in subfolder older than 30 days with out deleting subfolders

The error information returned by PowerShell is: ‘Cannot find path ‘\\backup\SQL’ because it does not exist.

The script I have runs fine manually in Powershell, but not in SQLPS. The job itself runs under the SQL Agent service account, which is an AD account, which has full permissions to the share. That should really cover all the bases, shouldn’t it?

As it turns out, no. A web search turned up this exact issue in Microsoft Connect. At least the workaround is simple! You have to get out of the SQL Server “context” in SQLPS before you try to hit a UNC path. So I just added this to the start of my script:

cd c:\;

Making the full script like this:

cd c:\; cd \\backup\SQL; dir *.bak

And that’s it! I do love a simple solution…

Happy days,
Jen McCown
http://www.MidnightDBA.com/Jen

Hm. Well, let’s take a quick look at the sysjobhistory table:

SELECT * FROM msdb..sysjobhistory;

Huh…that returned over 990 rows! So SOME jobs are showing history. But my Full backup ran successfully last weekend, and the record’s not in here!

The answer is simple, if a tiny bit obscured: Your job history log is set to only store a certain amount of information – in this particular case, 1,000 rows. And we’re running a LOT of jobs frequently, every day. That pushes out the old information.

Just resize your job history log (right click SQL Agent, Properties, History) to keep the amount of history you want.

Happy days,
Jen McCown
http://www.MidnightDBA.com/Jen