Rummage through this blog

Monday, 28 September 2009

Adobe Updater

Adobe updater can be really annoying - it will try to update your machine persistently. Clearly if you have legitimate software this is not a problem, or is it?

Yes it is, if you are sitting behind a web proxy which you do not control it might be difficult to configure adobe updates to work correctly.

So the trick is to force adobe to think that it isn't due for another update by editting the gile AdobeUpdaterPrefs.dat in (on Windows XP, it will be in the equivalent on Vista which you can google) c:\Documents and Settings\YourUserName\Local Settings\Application Data\Adobe\Updater5

Just change the date between the LastDateCheck tags to be a date wildly in the future and job done, or is it?

Yes, I am writing this because I have just been updated to Adobe Reader 9 and my previous fix has just failed (it fails in that I get logged out of the network about every minute when Adobe Updater is failing so is just a little frustrating) - the AdobeUpdaterPrefs.dat files now sits in the Updater6 folder.

For those people au fait with a registry editor (eg regedit) remember to delete the adobe speed launcher thing from the run settings unless you use acrobat very frequently. The run settings are under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, if you care about performance you will already be actively managing the contents of both.

Friday, 18 September 2009

Bald sunflower

A few days on and Alex has brushed all of the coloured heads off of the now hardened seeds on his fallen sunflower so time for another picture

Tuesday, 15 September 2009

Grand Tour

Well, mum & dad are off to Australia for 6 months now, crikey they'd not even left the country before phoning! It is the grand tour, Hong Kong, Australia, New Zealand & Thailand.

Alex is hugely impressed with the enormous Australia map they have given us - he has not quite got the hang of the idea of the scale difference between that one and the little world map he has so he won't have it that Australia is both that big blob on one sheet and that little blob on the other but he will get the hang of it once we start sticking things onto it to show progress.

Even better - they have left and the fridge is actually empty and perishables are gone and inspite of the horrid rain all day Tuesday even had time to clean the pond pump! Now I've redirected the flow back into the middle of the pond even the fish are happy. Boy, we now have 6 jars of mustard (open) and a lifetime supply of marmite to deal with. Such is life.

Friday, 11 September 2009

Moving tempdb

I'm doing it again, moving the SQL Server tempdb. For some reason people setup tempdb in places which just makes no sense whatsoever - like in the same location as other files. It's well documented that tempdb should be on its own drives as its performance is critical to that of the system as a whole.

What type of drive is arguable, generally I've used raid 10 although raid 1 is viable too.  There are arguments for raid 0 out there for the performance benefit, the downside is that if you lose 1 drive then your whole instance is in trouble so not really worth the risk.

You should have 1 tempdb file for each core (I've seen a suggestion of up to 8 files, after which .5 files per core applies but I've no evidence at that scale) and every file must be exactly the same size so the server can create 1 thread per file and use proportional fill.

Microsoft's own advice (this is from Microsoft staff presenting but doesn't make it into written documentation) is to fill the tempdb drive to 90% and have your tempdb at a fixed size ie figure out the max tempdb size you'll ever need, add a bit just in case & create your disk partition so that the size of the tempdb you calculated is 90% of the partition size then create the tempdb files to go in there. I would put a caveat on that, auto-grow is stupid - why would anyone with a live database want auto-grow to come along and trash their database performance while doing its thing & fragmenting your hard disk - plan properly! That said, I like the idea of planning in advance for file sizes but as long as disk space exists auto-grow I leave auto-grow turned on because it is better to take that performance hit rather than your database stop because it has no space. Naturally, you will be reporting regularly on database space used and free disk space to avoid issues won't you? While on "auto" things, there's no point in having auto create stats on and auto-shrink / auto-close are not appropriate for tempdb.

Big note, from SQL Server 2005, each time the instance restarts the tempdb is copied from MODEL so inherits some config options (eg ALLOW_SNAPSHOT_ISOLATION).

It is worth talking a little about the tempdb log file - yes it has one and is used. However, SQL Server 2005 has been optimised so that instead of the usual before & after log, some after logs are not saved so reducing the traffic and file size.

No real advice exists about the placement of the tempdb log file, I would say that if you are forced to keep your tempdb on the same drive as your data then at least place the log file with your other log files, otherwise the norm appears to be to keep the log file next to the tempdb datafiles.

Here is the Microsoft summary which is unfortunately woolly on some details (eg what type of drive to use) but specific on others

If you just want to move your tempdb, that's easy, just run the following query to identify what you already have in the way of tempdb files :
USE tempdb


EXEC sp_helpfile

and then run the following to move your files replacing tempname with the name of the file & c:\tempdb.mdf with your new path, similarly change the templog alter command. You will need to use the alter command for each file that you are moving

USE master


ALTER DATABASE tempdb MODIFY FILE (NAME = tempname, FILENAME = 'c:\tempdb.mdf')

ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'C:\templog.ldf')


Having done that you will need to restart the database and once successfully started and you have confirmed the changes are in place remember to delete the old tempdb files.

Saturday, 5 September 2009

Alex's sunflower

Alex has a sunflower, well had a sunflower, it was growing nicely with plenty of stakes to stop in blowing over, however, there is a limit and that limit was reached & it blew over and snapped at the base.

The seeds are not ripe but the insects seem to like it and it was an opportunity for some close-ups & grandma has a much talled sunflower that is still intact.

Friday, 4 September 2009

Shoreham Airshow

From 2009 Shoreham on Sea Air Show
Once again Shoreham Airshow was a great success with the thundering Typhoon and the world's only flying Vulcan bomber (a friend in Crawley remarked on how noisy it is) and a general all round spectacle for the family

Typically, Alex & his cousin Ewan probably had more fun on the bouncy slide and the diggers than they did watching the aeroplanes. That said Alex is still talking about the "ladies who walk on the planes" aka wingwalkers.