Permalink | Leave a comment  »

A quick iPhone 4.1 HDR shot of the field just behind our house in the morning sunshine.

Permalink | Leave a comment  »

So far, other people have commented:

• "it'll just randomly drop sometimes, really odd."
• "I need to restart the hub every day, sometimes 3 or 4 times"
• "Wifi goes from working fine one minute to not existing the next; usually as you're in the middle of something"
• "My HH2 has always done this since it arrived 8 months ago"
• "I don't use HH2's WiFi any more - can't rely on it staying up without frequent reboots"
• "We had these problems with a BT HH2 until we replaced it with a Belkin router"

Add yours below!

Permalink | Leave a comment  »

I installed the final GM seed of iPhone iOS 4.1 on my iPhone 4 this morning, and on the way home from the office thought I'd quickly try out the newly announced HDR camera mode.

Presently surprised with the first couple of attempts:

Compared to a non HDR version with blown highlights in the sky.

Had another go, this time focusing on the darker foreground to see if it made any difference... 

Non HDR:

So far so good - need to find more examples and try again, but I'm quite pleased with the results.
No additional effort needed to shoot in HDR mode either; just select "HDR" and fire away!

Nice to see that the Photos app has also been updated to recognise an HDR photo, displaying an appropriate badge when viewing photos now.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Since introducing Oracle to our live environment to support a major system, we’ve been seeing a variety of problems – resolution for which can only really be described as a black art.  Why does Oracle make life so difficult for those new to the platform to find out what it’s actually doing?

We’re currently running a 2-node Oracle 11g RAC cluster on 64-bit Windows 2003 server; which seems to be the first hurdle that has to be climbed…  Although Oracle are quick to state that Oracle-on-Windows (OoW )is a first class platform, and on the whole one that seems to perform just fine, something that’s become more apparent as time has gone on is that finding other people who have investigated & resolved performance issues with OoW is somewhat of an upward struggle. This extends into patching for example.

We recently identified a problem in the RAC clusterware that has been patched for all other platforms, but for some reason wasn’t ported to OoW. This came to light during an amusing conversation with Oracle’s support team who were avidly advising us to apply this patch, but were unable to provide us with a direct link to the patch to download. Only after getting them to go check the available downloads on Metalink did they realise that the particular patch wasn’t available for 11.0.x on Windows! Linux, *nix or Solaris – no problem…

Patching aside, we’ve recently been struggling with a major performance problem on our database which periodically resulted on both RAC servers essentially locking up at 100% CPU load across all cores, with the applications grinding to a standstill thanks to endless amounts of escalating locks within the database.

After what felt like many fruitless days of battling with this issue alongside working with the software vendor to determine whether the application issues we were seeing were a cause or effect of the problem, we started examining exactly what Oracle was doing at the point of an issue occurring. Eventually, with the aid of Oracle’s support team to analyse many Gb’s of traces captured with the system struggling, we were able to determine that the database was having great difficulty caching & reusing execution plans – and once identified, altered a system parameter to force Oracle to reuse execution plans. Problem seemingly solved!

Presenting symptoms:

• High CPU usage across both cluster nodes
• Unstable RAC environment with frequent node crashes, possibly due to excessively high CPU loads, forcing us to run on 1 RAC node.
• Rapid lock-state escalation resulting in all sessions being blocked & application crashes
• High % of lock wait states
• High % “Library Cache Latch” wait states
• High IO wait states
• Retention of 10’s of 1000’s of versions of query execution plans

Our first attempt at diagnosing this focused largely on the IO side of things, as storage for Oracle was not originally dedicated to Oracle but was located on a shared SAN diskgroup with some other applications. This was causing a variety of IO problems within the database as performance of the DB’s LUNs would fluctuate depending on other activities on the SAN. We decided to rule this out completely, so decided to provision a new set of SAN enclosures & disks dedicated to providing Oracle with sufficient storage, over dedicated spindles, arranged into RAID 10 for best performance. Oracle’s ASM proved its worth when the new disk became available, allowing us to keep the database fully available for users during migration of around 2.5Tb to new disks. Although the new storage helped dramatically by reducing IO contention & related wait states, it left us with the lock & Library Cache Latch wait states which between them still were able to bring the system to its knees.

To cut a long story short, it seems that the query code emitted from our applications was not lending itself to efficient re-use within Oracle as it doesn’t currently utilise bind variables, so at the peak of our problems we could query V$sqlarea and see 1000’s of versions of our top 10 queries being retained – despite them being identical bar substitution of a few parameters.

The key symptoms in all of this were actually the high % of “Library Cache Latch” wait states and the high number of execution plan versions being retained in the DB’s shared memory pool.

Inspecting v$sqlarea revealed that Oracle was not able to reuse execution plans as we were seeing retention of 1000’s of versions of plans for specific queries, along with high numbers of open & loaded versions of those plans indicating that nearly every query was being individually parsed to determine how best to execute it.

To determine this, try running something like the query below to retrieve your version counts from v$sqlarea:

select version_count, loaded_versions, open_versions, executions, sql_text 
from v$sqlarea order by version_count desc 

In our case we could see 6000 or so versions of one query, with 4-5000 loaded versions, 1-2000 open versions etc. These numbers were somewhat higher than expected… should ideally have a handful of versions, <10 loaded / open versions etc.

Every one of those execution plan versions gets checked when Oracle is presented with a new query to see if they can be reused, so given that every query was being parsed… all those plan versions were being checked for virtually every transaction the DB was processing. This is what seems to have produced 100% CPU load & the “Library Cache Latch” waits, and as a result the corresponding high numbers of Lock waits.

To test our theory we tried flushing the shared memory pool during one period when the system was experiencing locking issues:

ALTER SYSTEM FLUSH SHARED_POOL;

And were able to see an instant reduction in both CPU load, retained plan versions & lock waits.

To prevent this from happening and to get Oracle to re-use queries whenever possible, Oracle Support advised us to set the CURSOR_SHARING system parameter to “FORCE”, which under certain circumstances can improve re-use of execution plans.

ALTER SYSTEM SET cursor_sharing='FORCE' SCOPE=BOTH;

After altering the setting & flushing the shared pool, we saw an immediate reduction in CPU load along with an instant reduction in the numbers of queries being cached & a corresponding drop in contention / wait states due to all the various types of lock state.  Since introducing the setting we’re now seeing a maximum of 5-10 open versions of our most frequently hit queries despite some of them having been executed 4-500,000 times. We’ve also been able to resume operations with both cluster nodes online as neither node is now running at much more than 30-40% CPU.

This chart shows the difference in wait states within the database from before & after the CURSOR_SHARING configuration was adjusted...  

Just goes to show that Oracle performance issues can be dependent on anything and sometimes wait states from something seemingly unconnected to the issues you’re seeing can actually be directly symptomatic of the underlying issue plaguing your database!

Permalink | Leave a comment  »

Still, at least I'd finished the car :)

Permalink | Leave a comment  »

After a tedious couple of weeks, the transformation of our old kitchen into a dining room is nearly complete.

Aside from needing to hang a couple of doors, all that's really left to do is sealing & painting the walls & ceiling.

That's tomorrows job, followed by the skirting & anything else wooden that needs a coat of paint..

The end is (finally) in sight!

Permalink | Leave a comment  »

Here we are, nearing the end of August, and in South Norfolk at any rate we're currently getting what can only be described as torrential rain.

Download now or watch on posterous

IMG_0474.MOV (25325 KB)

It's an excuse to break out the iPhone 4 video camera however; and once again, this comes with a reminder that I need to think about getting an iPhone suitable mini tripod / Gorillapod or something similar before shooting video for anything too serious. 

Either that, or I haven't quite worked out how you're supposed to be able to hold an iPhone steady enough to shoot HD footage..?

iMovie for iPhone still amazes me though - in that it lets you edit, trim, join, title, set to music & export HD video; on your phone!!

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Although it's a Land rover there's no need for it to look quite like this...

Time to do something about it!!

Permalink | Leave a comment  »

Download now or watch on posterous

file.qt (10292 KB)

Permalink | Leave a comment  »

Progress is happening - sloooowwwwlllly...

Framing for the boiler box-work is complete and a door's been hung.

The flooring, skirting & architrave are all complete, and we're now waiting for the plasterer to arrive next week to cover up the boiler :)

Next stops, more door hanging; reskimming over a couple of holes in the ceiling; lots of clearing up & lots of painting!

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

The new dining room is really taking shape now, and it's finally beginning to look like a completed room rather than a building site.

As the floor nears completion however we realised that we needed to get some door bars to join the flooring under hall door, across the threshhold into the lounge and where it's going to meet some vinyl flooring in the downstairs loo and understairs utility room.

Off I went to B&Q (really need to think about buying shares in this place) and began a fruitless hunt for something that would match the laminate.

You really wouldn't think it would be that hard to find some "door bars" that would match the floor - it's Floormaster ToughLoc laminate which is one of the main lines sold by B&Q, and it's still very much a current product as we only recently bought it from them & they still have mountains of it to sell.

However.... No exact matches could be found whatsoever, so after a quick whip around a couple of other places selling laminate we ended up settling for something that will hopefully not look too out of place as a temporary fix with a view to replacing them with a more exact match as and when we find one.Although it's described as "Oak effect" it's not too bad a match with the floor though there is unfortunately a distinct difference between them.

Impressed I am not :(

Oh well...

Still, the rest of the floor should be down by afternoon and skirting's in the process of being replaced as needed - all good!

Permalink | Leave a comment  »

Feels like progress.. Got home to find that we'd gone from grey vinyl tiles to a nearly finished new floor in the space of a day!

The cat's a little unsure about the changes at the moment though....

Much more to do yet however. The rest of the floor needs to be fitted by the front door, and there's architrave to trim along with skirting that needs to be removed and refitted to accomodate floor's change in height.

Once the flooring's finished, next stop is building a stud wall around the boiler & lots of door hanging.... oh, and sealing & painting all the new plaster :(

Permalink | Leave a comment  »

After a couple of days of plastering, we finally have what looks like a room taking shape.

Waiting for new plaster to dry always seems to be such a tedious & lengthy process. In the mean time, those lovely louvered & glass panelled doors just had to go... Along with the rather tired flooring in the hall to make way for the new laminate flooring to match the lounge.

Lovely 1970's grey tiles... Fortunately they won't be on show for long :)

After another 12 hours - the plaster is finally nearly dry... Or dry enough at any rate to refit electrical sockets etc.

Next stop - laying the floor & boxing in the boiler.

Permalink | Leave a comment  »

And so it begins. The plasterer's been busy today, cleaning everything up to the point of being able to start plastering, and then cracking on with "first fix". Lots of big holes in the walls where pipes & cables previously resided have all been filled & smoothed, and the ceiling's had its first coat as a base for the top coat. So far so good & he will hopefully be back tomorrow to crack on with the rest :)

From this....

To this... Lots of fresh plaster which'll hopefully dry overnight.

Ceiling

Box work redone...!

Permalink | Leave a comment  »

Why is it that computer equipment, and especially any form of computer equipment that stores data, always only ever fails at an inopportune moment?

Laptops for work never break the day before you go off on holiday leaving plenty of time for them to be fixed while you don’t need them; digital cameras never fail once you’ve finished using them to take pictures of something important; and harddisks never, ever fail when they’re sat on a shelf or desk, blank, without anything important on them.

We were unfortunate enough to have a laptop harddisk fail which, just as it was needed and while it contained a substantial amount of documents, PDFs, InDesign files and stock photos that for some currently unknown reason were not being properly backed up to another device.

The disk started to make lots of nasty sounding noises – metallic clicking, rasping and grinding sounds… none of which you really want to ever hear emanating from the direction of a hard disk – so after a quick check of the obvious, we determined it had a bit of a problem and removed it from the host computer.

The next stop saw us embarking on what’s turned out to be an unexpectedly difficult challenge of finding someone who’s able to take a look at the failed disk, fix whatever’s failed, and hopefully recover the data.

We started looking around for a data recovery company using the same method as I’d expect most people would… Google.

Searches for “hard disk data recovery” and “laptop data recovery” etc all returned 10000’s of hits, most of which seemed to be links to a variety of small outfits who seemed to collectively promise to fix any form of fault known to man but yet didn’t actually seem to either be properly established companies & typically lacked any form of actual clean-room facility. Not really the sort of outfit you’d want to entrust anything to – yet alone a disk containing loads of stuff that we wouldn’t mind seeing again. How on earth are you supposed to be able to determine who you can and can’t trust to recover your data!?

In the end we bombarded most of the top 4 vendors found in our search with a number of questions to see whether they were able to help and ended up selecting one of them based largely on their quick & precise responses and a reasonable cost… along with a no-win-no-fee type guarantee around diagnostic costs so that if they were unable to recover the data all we’d end up paying was the cost of return shipping to get the disk back.

A quick phone call later and a courier collection was booked for the following day.

We duly packaged the disk up as instructed and sent it on its way… hoping to hear something positive within 24 hours or so.

24 hours passed… and the silence was deafening.

Another 24 hours passed without word from the company, so I called them for an update to be told something along the lines of “yup, we’ve had a look… it looks like it’s suffered a mechanical failure with failed read/write heads, and we need to source parts to repair”. Fair enough I suppose, so we sat back to wait a little longer.

A week after we’d dispatched the drive and after a few more phone calls similar to the above, it was starting to become fairly evident that the company we’d selected were struggling with this disk, a thought that was confirmed when they called to say that despite replacing the read/write heads they’d deemed the device to have a corrupted “service area” and as such was beyond their ability to recover.

Back to the drawing board…

More Googling quickly revealed that there’s a fairly short list of companies who have the ability to recover from Hitachi disks with corrupted service areas so we called what appeared to be the top two companies offering this capability and quickly picked what looked like the front runner in terms of capability.

Our original vendor was happy to send the drive directly onto the new company so this was arranged and the disk dispatched.

Within 12 hours of its arrival, the second company had inspected it and interestingly diagnosed it as having failed read/write heads – suggesting perhaps that either the first vendor’s claims of repairing the disk either weren’t strictly correct, or they’ve swapped the replaced heads out for the original failed ones.

We’re now back in the waiting game….

Permalink | Leave a comment  »