jinnantonnixx

Quick update, currently building my HP Micrososerver by installing the 'live' spin of XBMC Downloads | XBMC I've used the supplied 250GB disk for /boot, /, and swap partitions. The firmware mirroring facility is 'fake raid' and needs OS drivers so I gave up on that idea. I'm building a software-mirrored LVM volume from the Ubuntu installer (the XBMC live distro is based on Ubuntu 10.04) using two 2GB disks I managed to get for 'only' twice the retail price after the floods. I was going to get a bluetooth keyboard but I found this: Official XBMC Remote for Android | XBMC So now I can control the XBMC server with my phone! Works like a charm from the live boot, so that's cool. The LVM build is taking forever, but it sounds like it's busy.... Looking forward to getting it up and running.

Hi Vik - guru? (blush), no I don't think so. The log file is always used by SQL server, no matter what database model you use. It's nothing to do with SIMS or any other app, it's the way the SQL server operates. Any change made by SIMS, for instance, is first written to the log file by the server. This is so that in the event of the cleaner pulling the socket out of the wall, when the SQL server starts up it will be able to check for uncommitted transaction stored in the log file. It scans through these and commits any un-committed logs into the database.) So, no matter what model of database you use, the log file is an integral part of the database system. There's some confusion over how the log file is 'used'. It's always used by SQL server, it needs it to maintain a consistent state. But in the case of backups, not so. In the case of a 'full' backup model, you can restore the database to a point in time by restoring the database then restoring all or some of the transactions in the log file, to any point in time. This is the most flexible system, but requires planning. In the case of the 'simple' database model, the log file is not (and cannot) to used as part of the restore - it is only used by the SQL server to maintain consistency and to recover its state in the event of a crash or power failure. The simple model only permits you restore a whole backup, any changes made after the last backup will be lost. Next, why does the log file get bigger? When the SQL server 'knows' that the database has been backed up, it can be sure that the items in the log file before that backup are not needed. After all, we have a backup of that database at that point. The log file is truncated, which means that the portion of disk previously used by the old transaction items can be re-used. A bit like a tape-loop. All being well, and backups running regularly, the log file doesn't grow; it is reused. If backups go wrong, the SQL server is unable to truncate the log file is it cannot guarantee that the data can be recovered - we haven't backed up the database, so it must keep the logs in case we need to commit the logs into a restored database to bring it up to date. Of course, the 'tape loop' concept fails as we run out of space, so it must extend the physical size of the file, hence the increase in log size. Be aware that truncating the log is not the same as shrinking the log. Truncating the log makes virtual markers in the log indicating that sections of the log file can be re-used. This doesn't resize the file. Shrinking the file actually reduces the physical space the file takes up by re-organising the log file and throwing away unused space. Unless something crazy has happened (as in @SHimmer45 's case) there's no need to bother shrinking the log file.

The solution is beautifully simple: One person cuts the pizza/cake in 'half', the other person chooses which 'half' they want. Works every time.

Fractions drive me nuts. When Dad's involved with any DIY, it's 7"3/8 - 2"3/4. Sends my head spinning. O.T., do you know the perfect way to divide a pizza (or cake for that matter) between two people?

Avoid using auto-growth as a management tool. Always size the databases correctly, an auto-grow will halt the database engine while the server extends the files. Switch on auto-grow by all means, but set it so that the increment is a large size (rather than a percentage). This means that if the server ever needs it (for whatever reason), it will extend the files by a large, defined increment, rather than nudging the file size every so often. Forget auto-shrink, do this manually if you must. Here's why. http://blogs.msdn.com/b/sqlserverstorageengine/archive/2007/03/28/turn-auto-shrink-off.aspx

Are Finnish schools the best in the world? - Schools - Education - The Independent

Good job you spotted the problem.

Before attempting to shrink the file (in itself it's not going to cause too much of a problem, apart from being very big) it's best to try and find out why it's been growing, or we'll end up with the same problem again. We need to know the database model (simple/full) and the backup mechanism used.

It's quite likely that your backups are not truncating the log file. What's your backup mechanism?

We were looking at these cabinets, but I found them after the installation contracts were drawn up. Might be worth a look. If I remember correctly, you can hire them rather than buy them outright. Server Cabinets - Virtually silent, Sound Proofed Server Cabinet Rack Solution

If it's of any use, I got into a hell of a mess with Squid one time and the machine was inside-out. Using dpkg --remove --force-remove-reinstreq got me out of this mess; I found it here: apt-get how to fix very broken packages | Shadows of epiphany

You win. At snap.

Is it just me, or has the government played a blinding 'divide and rule' stroke? All the proles are squabbling amongst themselves and the pressure's off the government. Public sector vs private sector. Even Clarkson's put his big foot in it. I've said it before, but the MPs in the government work in the public sector.

I'll see your Han Solo in Carbonite, and raise you one Han Solo in Bourbonite.

Oh it just gets better. I'm watching the goalposts race away into the distance....

[Reworded post] Politicians themselves work for the public sector. This seems to have been missed by a lot of people. Let's take a look at their pensions while we're at it. After all, they are public sector employees.

Nice. I think I'll order one tomorrow.

You're quite right, I did miss the requirement for incremental copies. As you suggest, the /M option will work, copying files that changed since your last copy. /M :: copy only files with the Archive attribute and reset Also, the /MAXAGE option in Robocopy is a more absolute way of doing this. /MAXAGE:n : MAXimum file AGE - exclude files older than n days/date. /MINAGE:n : MINimum file AGE - exclude files newer than n days/date. (If n < 1900 then n = no of days, else n = YYYYMMDD date). Note the option which allows the use of YYYYMMDD. We've already calculated this in our script, so we can use this option quite easily.

I third you.

As @dhicks syggested, roll your own is a good idea, or was a good idea before the ridiculous disk price hike. I bought a HP Microserver (from serversplus) and just heard that my £100 cashback cheque is on its way to me. Nett outlay = £100, and that includes a 250GB disk for the OS. If you want to go free, you could do worse than Ubuntu server + Samba or FreeNAS.

This should get you there. You can remove the echos and comments if you like; they're for testing so you can see how it works. :: script to robocopy files to a folder named after the current date :: set the time & date into a variable for /f "tokens=1,2" %%a in ('time/t') do set time=%%a for /f "tokens=1,2" %%a in ('date/t') do set date=%%a :: date has '/' characters which we can't use in a file or folder :: use the 'set' command to substitute the / to a - set date=%date:/=-% :: time has ':' characters which we can't use in a file or folder :: change to a '.' set time=%time::=.% echo Time=%time% echo Date=%date% :: you can use the date as is, or we can split it up into YYYYMMDD :: to make file sorting more logical for /f "tokens=1,2,3 delims=-" %%a in ('echo %date%') do ( set dd=%%a set mm=%%b set yyyy=%%c ) echo DD=%dd% echo MM=%mm% echo YY=%yyyy% :: set the destination folder :: if you don't care about file sorting set destfolder=X:\BACKUPS\%date%\FULL or whatever :: if you want full sorting on YYYYMMDD set destfolder=X:\BACKUPS\%yyyy%%mm%%dd%\FULL or whatever :: if you want full sorting + time set destfolder=X:\BACKUPS\%yyyy%%mm%%dd%\%time%\FULL or whatever :: call robocopy robocopy %destfolder% /E It assumes you're using the European date model (DD/MM/YYYY) not the crazy American date.

Pretty straightforward. If no-one posts a solution in the meantime, I'll post a sample script tomorrow.

Hand on heart, I have been trapped in a clothes horse. What's more, I was entrapped not alone, but with a friend from next door. In the same clothes horse. At the same time. It was about 1977, however, and we were both young and foolish. As I recall (and memory is hazy) we couldn't get out without the assistance of a third party. My mum rescued us. I still remember the noise of the clothes horse as it snared its prey, it was a creaky old wooden one.

.... because everyone loves things that go 'bang'. There. That's why.

You could wire up two or three for added 'effect'.