Ray Lane at HP
Leo Apotheker is taking over as CEO of HP, and Ray Lane as chairman. I don’t know Leo, but I did talk a lot with Ray when he was at Oracle in the 1990s. Quick observations include: Read more
| Categories: HP and Neoview, Oracle, Vertica Systems | 9 Comments |
Evidently IBM bought Cast Iron Systems for $190 million
Sequoia told TechCrunch that Cast Iron Systems was acquired for $190 million. That’s a much more successful exit than I thought.
| Categories: Cast Iron Systems, Data integration and middleware, EAI, EII, ETL, ELT, ETLT, IBM and DB2 | 2 Comments |
A rant about medical records
It is very difficult to convey utterly tedious frustration without — well, without thoroughly boring one’s audience. And hence I will not try to explain the full awfulness of modern medical records and information compartmentalization. But I was personally present 5 times in one recent week while Linda gave detailed information about her contact information, medical history, etc. — and all 5 times it was to the same hospital.
In our case, that just costs time. But the information flow in my father’s case upsets me more. Read more
| Categories: Health care, Surveillance and privacy | 2 Comments |
Further thoughts on previous posts
One thing I love about DBMS 2 is the really smart comments a number of readers — that would be you guys — make. However, not all the smart comments are made in the first 5 minutes a post is up, so some readers (unless you circle back) might miss great points other readers make. Well, here are some pointers to some of what you might have missed, along with other follow-up comments to old posts while I’m at it. Read more
| Categories: About this blog, Calpont, IBM and DB2, Netezza, Oracle, SAS Institute | Leave a Comment |
A little more on the JPMorgan Chase Oracle outage
Jaikumar Vijayan of Computerworld did a story based on my reporting on the JP Morgan Chase Oracle outage. He did a good job, getting me to simplify some of what I said before. 🙂 He also added a quote from Chase to the effect:
the “long recovery process” was caused by a corruption of systems data that disabled the bank’s “ability to process customer log-ins to chase.com”
While that’s true, and indeed is the reason I first referred to this as an “authentication” problem, I believe it to be incomplete. For example, the $132 million in missed ACH payments weren’t directly driven by log-ins; they were to be done on schedule, perhaps based on previous log-ins. Or as Jai and I put it in the guts of his story: Read more
| Categories: JPMorgan Chase, Oracle | 6 Comments |
Where I’m at
It would be an exaggeration to say that my family health issues are “under control.” My father still isn’t fully alert. He also has tubes surgically implanted in his throat and belly, and will not be able to speak during a months-long rehab. (He will HATE that; he’s the kind of guy who always charms or at least entertains his caretakers.) In one of my better pieces of writing, I explained all that in a long note to my partly-senile mother, who seems to be handling it; but of course she remains a concern. Linda’s leg is still broken.
One moral in all this is that it is a VERY good idea for the elderly to live in the same metropolitan area as their children. When I’m with my father, I can rein in his overconfidence about muddling through episodes of weakness. When I’m not, bad things happen.
Still, things are moving forward. A long, slow rehab will be very unpleasant for my parents, but at least there’s good hope we won’t have too many more near-term urgent crises. Communication and coordination among my parents’ support structure is better, even in the case of Friendship Village. And Linda seems sufficiently able to fend for herself that I’ll keep my plans to go to the SF Bay area the week of October 4, albeit being very careful to stock the house with food beforehand.
I’ve kept up client service through all this, cutting relatively few corners, and that won’t change. Read more
| Categories: About this blog | 12 Comments |
How to tell whether you need ACID-compliant transaction integrity
In a post about the recent JPMorgan Chase database outage, I suggested that JPMorgan Chase’s user profile database was over-engineered, in that various web surfing data was stored in a fully ACID-compliant manner when it didn’t really need to be. I’ve since gotten private communication expressing vehement agreement, and telling of the opposite choice being major in other major web-facing transactional systems.
What’s going on is this:
- ACID-compliant transaction integrity commonly costs more in terms of DBMS licenses and many other components of TCO (Total Cost of Ownership) than less rigorous approaches.
- Worse, it can actually hurt application uptime, by forcing your system to pull in its horns and stop functioning in the face of failures that a non-transactional system might smoothly work around.
- Other flavors of “complexity can be a bad thing” apply as well.
Thus, transaction integrity can be more trouble than it’s worth.
In essence, of course, that’s half of the classic NoSQL claim, where the other half of the claim is to assert that the same may be said of joins.
So when should you go for ACID-compliant transaction integrity, and when shouldn’t you bother? Every situation is different, but here’s a set of considerations to start you off. Read more
| Categories: NoSQL, Web analytics | 12 Comments |
Some thoughts on the announcement that IBM is buying Netezza
As you’ve probably read, IBM and Netezza announced a deal today for IBM to buy Netezza. I didn’t sit in on the conference call, but I’ve seen the reporting. Naturally, I have some quick thoughts, which I’ve broken up into several sections below:
- Clearing some underbrush.
- Speculation about what IBM/Netezza will do.
- Speculation about alternative acquirers for Netezza.
- Speculation about what IBM/Netezza competitors will do.
Details of the JPMorgan Chase Oracle database outage
After posting my speculation about the JPMorgan Chase database outage, I was contacted by – well, by somebody who wants to be referred to as “a credible source close to the situation.” We chatted for a long time; I think it is very likely that this person is indeed what s/he claims to be; and I am honoring his/her requests to obfuscate many identifying details. However, I need a shorter phrase than “a credible source close to the situation,” so I’ll refer to him/her as “Deep Packet.”
According to Deep Packet,
- The JPMorgan Chase database outage was caused by corruption in an Oracle database.
- This Oracle database stored user profiles, which are more than just authentication data.
- Applications that went down include but may not be limited to:
- The main JPMorgan Chase portal.
- JPMorgan Chase’s ability to use the ACH (Automated Clearing House).
- Loan applications.
- Private client trading portfolio access.
- The Oracle database was back up by 1:12 Wednesday morning. But on Wednesday a second problem occurred, namely an overwhelming number of web requests. This turned out to be a cascade of retries in the face of – and of course exacerbating – poor response time. While there was no direct connection to the database outage, Deep Packet is sympathetic to my suggestions that:
- Network/app server traffic was bound to be particularly high as people tried to get caught up after the Tuesday outage, or just see what was going on in their accounts.
- Given that Deep Packet said there was a definite operator-error contributing cause, perhaps the error would not have happened if people weren’t so exhausted from dealing with the database outage.
Deep Packet stressed the opinion that the Oracle outage was not the fault of JPMorgan Chase (the Wednesday slowdown is a different matter), and rather can be blamed on an Oracle bug. Read more
| Categories: JPMorgan Chase, OLTP, Oracle | 45 Comments |
Speculation about the JPMorgan Chase authentication database outage
Edit: Subsequent to making this post, I obtained more detail about the JPMorgan Chase database outage.
I was just contacted for comment about the Chase database outage, about which they’ve released remarkably little information (they’ve even apologized for their terseness). About all Chase has said is:
A third-party database company’s software caused a corruption of systems information, disabling our ability to process customer log-ins to chase.com. This resulted in a long recovery process,
and even that quote is a bit hard to find. From other reporting, we know that ATM machines, bank branches, and the call centers continued to work, but various web and mobile access applications were disabled.
Of course, that quote is pretty ambiguous. My thoughts on it include: Read more
| Categories: Data types, JPMorgan Chase | 11 Comments |