Wednesday, August 31, 2011

Swapping the white shirt for a towel ?

For almost three years I have been a consultant. Dark suit, white shirt, tie. The official uniform of the 'You can trust us' brigade. [Aside, I was reading Superfreakonomics recently and learned that ties are often germ ridden so the soon we all stop wearing them, the better!]

Next week I start a new job. Back to contract work, with a role doing Application Express development. Yeah ! I do like Apex. I'd previously remarked about the feeling of accomplishment I get when building code. It is nice to see something you've built being used.

I'm contracting through an agency (BSIPeople) who supplied me with a snazzy Sports Bag on sign up. The bag contained the ubiquitous pen, a hat, a drink bottle and a towel. My wife's reaction to the towel was an immediate reference to the Hitchhikers Guide to the Galaxy.

"any man who can hitch the length and breadth of the galaxy, rough it, slum it, struggle against terrible odds, win through, and still knows where his towel is, is clearly a man to be reckoned with"

There's something appropriate about going back to contracting armed with a towel. I'm looking forward to it.

Sunday, August 28, 2011

Canadian dogs on drugs

This is what happens when you get your data model wrong.

I subscribe to RISKS digests, and the latest issue has an interesting post on a poor Canadian bloke who got confused with his dog.

The dog was on some prescription medicine. Dogs can't go into the local pharmacy and buy this stuff themselves, so the owner performed this duty. The drug purchase/pickup got entered into the nationwide recording system against the purchaser's name.

The problem comes when this guy goes into hospital and that purchase shows up on his records. There's no indication that the drugs are actually intended for a different recipient (Cooper the dog) so the doctors didn't know this. Fortunately the owner was conscious and lucid and able to tell the doctor that he wasn't on those drugs and the mixup got sorted.

It is perfectly reasonable to have a pharmacy record that doctors in hospitals can easily refer to so that they can find out what medications a patient is on. My dad takes various pills for things, and i'd be pretty sure he won't remember the individual names. Plus they deal with accidents and cases where the patient may be unconscious or unable to talk.

I suspect they've also started to use the same pharmacy records to pick up people who buy too much of particular drugs. Here in Oz they've gone as far as to stop selling various cold remedies whose ingredients were used in making illegal drugs. So drug purchases for pets get thrown into the same bit bucket.

The problem is that corruption of the data model, of the meaning of the data, has impacted the primary purpose of the system. Keep your data clean folks

Sunday, August 21, 2011

Redo log buffer or redo log file ?

There's a very interesting post on Jonathan Lewis' blog under the unassuming title of REDO.

Oracle treats a transaction as committed when the change and the commit has been written to the redo log BUFFER and doesn't require it to be written to the redo log FILE.

This can cause issues if the instance fails before that log data is flushed to the the file. If the disk write fails BECAUSE the instance fails, it is very unlikely that anything would have had a chance to look at the data in that tiny gap (but even rare risks WILL happen somewhere, sometime). If the disk write fails but the instance continues for a time (which is simulated in Jonathan's post) then the risk gets higher.

I think RAC throws a few more variables in there. Conceivably, a transaction in one instance may have committed data (not written to redo log file) shunted to another instance where it can be amended again and written to that instance's redo log file. If that first instance fails without a persistent copy of that initial transaction, then it can never be re-applied in its entirety.

But then I'm a developer and maybe I'm missing something in the the way instance recoveries are managed in RAC.

So is Oracle 'broken' ?

One problem is the notion of 'durability' is vague. A committed action should last beyond 'system failure', but in a 'cheap' system the CPU and disks can be in the same rack (or the same server) and a failure, such as a fire, could destroy both. Does that mean a transaction shouldn't be viewed as 'committed' until the log file is archived and shipped elsewhere ? Conversely, an expensive 'Data Guard' architecture with a maximum protection mode/level might not be impacted by the failure of a redo log write on a single node.

I suspect this one will run on for a while, and it is worth keeping an eye on Jonathan's post as the experts weigh in.

Friday, August 19, 2011

The casino approach to security

We can learn a lot from casinos. At least that's one view on application security. The rules have changed from being a case of what is allowed versus what isn't allowed, to something a bit fuzzier.

As an example, on my way to the Sydney Oracle Meetup 'Expert' event I had a phone call from my bank. Apparently my credit card had just been rejected in a Australia Post office as a suspect transaction. Since I'd been on the train it wasn't me. The card was in my wallet too, so it hadn't been nicked. The card had been skimmed somewhere.

The suspect transaction wasn't above my credit limit. It's not like I've never used it in an Australia Post either (though never for the amount involved). It may have been an odd location, but I hadn't had any rejections on a recent holiday. In short, it probably wasn't any single factor that tripped the security wire, rather a whole set of criteria that marked it as suspect. Okay, maybe it came down to a suspicious employee of Australia Post, but this is a database blog not an episode of Law and Order.

There's a careful balancing act the bank has to perform (and it did it very well in this case). It has to, in the words of the article, "let the people play". It can't stop every credit card transaction, but has to look for rogue behavior. Its not something I've directly worked in, but I've done fuzzy algorithms for data matching. You add some points for one fact, a few more for another and at the end you get a resulting numeric value for 'how likely'.

That requires lots of logging of activity, and there's an increasing requirement to analyse these logs, sometimes in real time (or near real time) for those behavioral factors. Hadoop seems to get some mentions for this form of analysis, though I'm sure there are other solutions in the NoSQL world. I'm sure VoltDB would offer themselves up here too. My gut feel for this style of application would be some form of distributed data store.

There are rumors of an Oracle Hadoop Appliance which may or not be confirmed in a few weeks at OOW. That said, there have long been rumors of an Oracle Games Console, and I'm thinking of applying for a trademark for ExaPhone before Larry gets in there. Oracle do have a pedigree of dealing with vast amounts of data (anyone mention CERN ?) so it will be interesting to see how they play out in this area.

An evening with some Oracle Experts

This week has been InSync11 week in Sydney. Actually it was Tuesday and Wednesday (though Tom Kyte stuck around afterwards for a 'Day of Real World Performance'). The bad news is that my dollars didn't stretch to any of those events.

The good news is that it did stretch to the (free) Sydney Oracle Meetup event mentioned by a couple of our guest experts, Richard Foote and Tim Hall. We were able to tempt the experts away to a local RSL club with the promise of alcohol and Oracle users.

Each of the experts got to pick a question to answer from a carefully selected list.

Tim picked out one on the worth of certifications. He's got lots and doesn't think a lot of them. Or rather, as a debate with Marcelle drew out, believes they are limited in the practical benefit of them in the workplace. They do work in exposing areas of new functionality, so that you can think about them. Marcelle is of the opinion that learning to deal with users, developers and managers is more important than learning syntax.

Richard waxed forth on the importance of knowing about indexes. Apparently he doesn't actually spend his working days poring over block dumps and counting blevels. He actually does a lot of normal DBA work and became synonymous with indexes when his Rebuilding the Truth paper went viral, plus a bet about how long he could blog about indexes (and David Bowie).

Marcelle chose the question about dealing with people rejecting an expert's advice. Some of this was drawn from the debate over her paper on Foreign Keys. Given the rise of the NoSQL / distributed database concepts, and the 'eventual consistency' model, the paper raised some valid points. Equally the advice is irrelevant to many people who are not faced with those problems.

Tom talked about the fear of presenting. Apparently this is best resolved by doing it lots. [Tony Jambu won the autographed copy of Tom's book. It is impressive when you have an Oracle ACE in the audience.]

Chris Muir talked about his crush on Lucas Jellema when answering about his favorite expert. Apparently he is very enthusiastic and it can be contagious. [He didn't actually say "crush", but I find it fun to use since Kellyn talked of her DBA Crushes.]

Connor talked about user groups and how it is fun to be around people who think this database stuff is fun. He also complemented us on the turnout (around 60 - our biggest event so far). Not sure who got the autographed copy of his book (or rather the one he did a chapter for) but I'm envious.

Craig picked up a question on social media. The upshot seemed to be that having a social media presence doesn't make you an expert, but it can help your expertise get noticed. A lot of our 'experts' didn't feel quite comfortable under that label. They pointed out that there are a lot of 'quiet experts' out there with excellent experience and knowledge. They just happen to go around talking about it.

This also came across in Guy's response to how long it takes to become an expert. It isn't really about time. If you do something a lot, you will become good at it, but it reaches a point where it doesn't add any more. Furthermore, with the pace of change in IT, after a couple of years it actually becomes less relevant as it is out-dated.

There was also some final discussion on balancing Oracle with a 'non-oracle' life , such as family. Apparently it helps if you don't watch Masterchef. It doesn't look easy when lots of travel is required though.