Monthly Archives: June 2014

Computer Hardware

Supermicro X9SRW-F CPU Temperature Issues

Leave a comment

So I was not having a good time with this supermicro box – it’s a 2U with 8 SATA drives (3T each), areca raid controller, 4 core intel, 8gb ram. Not much. It ran wonderfully as a FreeNAS/NAS4Free box for the last 36 months and was just no being repurposed as an Oracle Playground (ie development/POC).

Installed CentOS 6.4 on it and gave it to the developer. Full building power outage later and it wasn’t booting backup. Turns out that my 8 drive RAID10 had some issues; 1 of the drives in a mirror died (click of death) and the other drive had corrupt data blocks. Awesome. Finding some working drives later, I rebuilt it again.

Now it was Fan full throttle, fan not full throttle, random fan issues. The logs stated something like CPU Temperature assertion, CPU Temperature desertion. Overheating? The room temperature is a balmy 72F. So I put the fans on Heavy I/O fan mode. This seemed to work for a few hours but then we were back to throttle up/down again.

I upgraded the IPMI firmware from 1.2.x to 3.0.x. I rebooted the machine. I even cold booted. I then updated the BIOS (download from supermicro, use Rufus to create a new bootable USB device, copy files, run ami.bat BIOSNAME.FILE). Still no dice.

Then I read what user “SpeedKills” posted on a forum board; simply RESET the IPMI to factory defaults.

Did that and no more fan issues.

Microsoft

Clear MSSQL Log Files

2 Comments

So first of all I’m not a SQL expert. Secondly I don’t recommend performing this on a production system. Third, this actually won’t happen on a production system as long as you’re performing backups – and your backup solution supports MSSQL – and I hope if it *is* a production system that you are actually backing it up.

Open the SQL Management Studio
Connect using the windows authentication piece, OR your SA password

Run the following in the query window
DBCC sqlperf(logspace)

This will show you the name of the database and associated size of log files.

Assuming that the INSERTNAMEHERE database is the one eating through the space
USE INSERTNAMEHERE;
GO
ALTER DATABASE INSERTNAMEHERE
SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (INSERTNAMEHERE, 1);
GO
ALTER DATABASE INSERTNAMEHERE
SET RECOVERY FULL;
GO

You can then run the logspace again and verify
DBCC sqlperf(logspace)

This all worked nicely on my development system that doesn’t require/have backups in place.