RichText

In my last post I described how my new Apple MacBook arrived just before Christmas with a dead pixel in the screen. My replacement MacBook finally arrived last night, the screen is perfect and everything else seems to be fine with it too.

I’ve managed to get all my data/applications off the old one and onto the new one without much fuss. All I’ve got to do now is arrange for the defective one to be picked up by the courier.

Apple took their time with the replacement, but overall I’m pretty pleased with the way that this has been sorted out, considering some manufacturers would have just told me to live with the dead pixel.

My MacBook arrived last night amid much excitement, only for me to have my glee quashed by a ‘dead’ pixel on the screen.

I called apple customer support with trepidation, thinking that I would just have to send it back and wait for a new one to come. But I spoke to someone very understanding who has arranged for a replacement to be sent out to an address of my choice. The best bit is that I get to keep the original MacBook for upto 5 days after the replacement comes (so that I can transfer my data), after which time a courier will come and pick up the defective one from another location of my choice.

This all sounds great in theory, but I’ll reserve judgement until I’ve seen how smoothly it all goes – I’m not going to be in one place for very long over the Christmas period!

See this post for how it got resolved.

So I finally gave in and ordered an Apple MacBook…

I have been in the market for a highly-portable notebook for a while, and I figured by getting a new Intel-based MacBook I would get the best of both worlds by being able to run both OSX and Windows on the same computer using either Bootcamp or Parallels.

Also, they’re actually quite good value for a compact notebook of this spec. (I went for the 2.0GHz Core 2 Duo White MacBook with 1GB RAM, 1280×800 screen, DVD Super-drive).

I’ll blog about any interesting things I find out about it, once it gets delivered.

I was recently investigating disaster recovery techniques for Sql Server 2005, and for my needs Database Mirroring looked like a good candidate. (Note that Mirroring is only supported from Sql Server 2005 SP1).

Having looked into log-shipping and replication techniques in the past, this seemed like a good compromise between the two. The main down-point of Mirroring is that, like for log-shipping, the stand-by database must be kept offline. A big advantage that Mirroring has over replication is that changes to the structure of the Principal site are automatically applied to the Mirror.

Database mirroring in Sql Server 2005 lets you keep a “Mirror” of your live Sql Server database up to date in near real-time. In the event of your Main Site’s database becoming unavailable, the Mirror can then serve the database clients.

Database Mirroring can be run in various modes. These can include using a “Witness” server to watch proceedings to see if a fail-over is required. You can also choose whether you want to wait until transactions have been applied at both Principal and Mirror sites before committing (High Safety Mode), or whether you want transactions to be applied asynchronously at the Mirror site (High Performance Mode).

For my situation, I went with no Witness server and High Performance mode, as the Mirror database was going to be in a remote location, with a relatively slow network link.

There are various performance counters and statuses associated with Database Mirroing, and various ways of being notified if any of these indicate a problem. For example, you can set up an email or net-send notification to certain people if the oldest unsent transaction is older than a certain age, or if the connection between Principal and Mirror is broken.

After a bit of fiddling most things seemed to work for me in a pretty obvious manner. However, there were a few little hurdles I had to get over.

1. If both machines are on the same domain then the security configuration is quite simple as long as the Sql Server services run under the same domain user account. If the server instances run under different user accounts, user logins on the Principal instance must be manually created on the Mirror (and vice-versa if you want the Mirror and Principal to be able swap roles). The thing that caught me out was if the machine account is used rather than a domain account, it must be added as a user on the other server instance.

2. If both machines are not on the same domain, then you need to use certificates instead. This msdn page tells you how. I’m not sure if this is because of some time-zone issue as I’m in the UK, but if I didn’t specify a start date for my certificates then they didn’t seem to work until a couple of hours later!

SELECT * FROM DATABASE_MIRRORING_STATE_CHANGE

SELECT * FROM DATABASE_MIRRORING_STATE_CHANGE WHERE Database = 'MyDatabase'

As I said earlier, pretty much every thing else worked the way the documentation said it would.

This msdn page links to lots of useful articles. Happy Mirroring!

I recently changed my ADSL ISP from Bulldog (who, in my humble opinion, weren’t great and would only give me 2Mb/s) to IDNet.

I’ve only been using IDNet for a week or so, but they seem pretty good – I’m getting about 0.4Mb/s upload and 5Mb/s download speeds. Best of all however, is when I called for support out of working hours and left a message, they called me back within about 5 mins and were extremely helpful. Can’t beat that for customer service. :)

Sorry for the lack of useful posts recently – been very busy. Hopefully I might write something of interest soon!