I’m embarrassed to see how long I’ve been neglecting this blog.
Today was the closing of Oracle Openworld 2013. I’ve just returned to my hotel from the It’s a Wrap party and a quick dinner. I’ll be spending the weekend in the San Francisco area, back home on Sunday, and back to work on Monday.
I’ve got some blogging ideas, starting with some work I’ve been doing w/ OpenLDAP, so, that’s probably where I’ll start. I should have part one of that series up by next weekend.
Until then, I wish safe travels to my friends returning home from OOW.
I try to be active on the OTN Forums, particularly the Database – General forum. Very often, I’ll see people asking about Oracle internals and X$ tables and where they can learn more. The answer is generally, that you can’t. It’s not possible to read up on stuff that’s largely undocumented. Further, you shouldn’t really care that much. While internals can be interesting, they rarely add a great deal of real, practical value.
My apologies for my extended absence. Well, I ran into something interesting today, and, I thought it would be appropriate for a blog post, and apparently, I got inspired. No startling revelation here, this is just a bit of a cautionary tale about the unintended consequences of using a new feature. A quick search of the Oracle Documentation confirms that the
skip locked directive of the
select for update statement was introduced in Oracle 11g, version 11.1. But, before we dive into that, let’s review the functionality of
select for update through versions of Oracle preceding 11g.
Or should I say ‘Brum’?
Well, I’ve just been notified that one of my abstract submissions, “Introduction to Locks and Enqueues”, has been accepted by the UKOUG for the 2008 Annual Conference, coming up in December. I’m really looking forward to it. This will be my 4th year attending. It’s also the first year the conference will be expanded to a full 5-day week. There’s bound to be a ton of great material. I have to say, even for someone coming from overseas, this conference is well worth your time and money.
See you in Birmingham, er, Brum!
As the subject says, there’s my first two real posts, so, I guess I’m blogging. I won’t guarantee how active I’ll be here, or how much of what I write will be Oracle, as opposed to other stuff, but, for what it’s worth, here I am.
I ran into a situation over the weekend, where an application and schema, which were stable under 10.2.0.3, started hitting ORA-00060 deadlocks in 22.214.171.124, in spite of the fact that no application code changes had occurred. It seems that 11g was more sensitive to deadlocks in this situation than 10gR2 was.
Well, I finally decided I have something noteworthy to blog about. This was a bit of a stumper, that we ran into the other day….I did finally get to the bottom of it, and I thought it worth a mention, here.
We have a three node RAC running 10.2.0.3 on DL-585s.
This is a reasonably busy system, but, these boxes have lots of horsepower, so, no serious I/O or CPU bottlenecks are observed. We seem to be humming along when we hit ORA-257 (archiver error, connect internal only until freed). I think “Ok, the archivelog backup process is failing to run, and the archivelog area is full”. But, I find that the 100GB archivelog area is nearly empty. And we’re still stuck on ORA-257. What the ….? Some weird 10.2.0.3 bug, perhaps? We notice that bouncing the stuck instance frees up the problem…..very strange indeed.
To make a long story short, we opened an SR, uploaded lots and lots of logs, and discovered…..when this server was set up, processes was set to 500, which is too small. The process table filled up, and at archive time, apparently the archiver spawns a process to talk to ASM (archivelog area is under ASM), and since the process table was full, it couldn’t do that, so it reports the (misleading) ORA-257 error. We bumped processes to 1000 for all three nodes, and Voila! Problem solved.
So, anyhow, just thought I’d mention that scenario. If you hit ORA-257 and your ASM managed archivelog area is not full, think PROCESSES parameter…