Hectic few days nearly over. Some of our clients have the busiest period of the year right now. That means extra time spent making sure everything is hunky dory.

The usual: keep an eye on weird take-offs in CPU usage, watch disk space, particularly those pesky temp tablespaces that suddenly take off in disk usage when someone fires off the "mother of all queries for the year". That sort of thing.

While sparsely allocated temporary files in temp tablespaces look nice on paper, it's a RPITA when a large demand is made on temp disk space and someone forgot such free space really needed to be there in the first place: it shouldn't have been used for other crap...
Hey: it happens in the best families! :-)

But it's one of the reasons I don't like this kind of brainless "automation": it creates more problems than it solves!


Finally got all my Xmas shopping sorted out. Kids have got the toys they wanted and we could afford, wife has got the thingamabobs that wifes seem to need at this time of the year. I got my scanner last month and a few of the books I wanted to get: there is going to be a lot of reading going on in the next few days! The usual charities have also been catered for. And we're as usual pennyless and eagerly awaiting the next pay cycle...

Ah well: all in the Xmas spirit, I reckon! One good thing: Isabel is doing the Portuguese pumpkin fritters - filhózes, or as they say in Dad's village: belhózes - and a few of the other season specials! There is some turkey, the Portuguese salted cod fish - bacalhau - and a stack of other nice things to eat. In a few hours, it'll be time to start relaxing and enjoy some of the truly great flavours in life.

And as usual, it's pelting down in Sydney. We needed the rain but did it really have to come in during the Xmas break?...

Here is hoping this finds you folks in the same spirit. And if not, then at least with enough spirits to let you truly enjoy the next few days!

Dudettes, dudes: all the best season greetings and may you enjoy a peaceful break.

Catchyalata, folks.



Howard Rogers blogged recently about a simple feature that would greatly simplify his Oracle dba tasks. In his case if roles worked properly in Oracle and/or user authentication methods were not linked to the user name itself, life would have been a lot easier.

Yes, there are heaps of these small enhancements that were requested from Oracle over the years. Very few made it to the latest versions of Oracle. If ever. It's a pity, really.

Historically, Oracle has always relied more on new features than actually making life easy for their current users/administrators. I could go on with a long list of requested enhancements that was never acted upon.

But quite frankly: I stopped bothering a long while ago! More or less when they decided that the solution to a skills shortage was to eliminate the skill. The problem of course is they tried to eliminate the skill of using a brain...

While I'm in rant mode, I might as well mention the fixation that some folks have with automating Oracle startups and shutdowns with those of the operating system itself.

Folks, the VERY LAST thing you want done to a database service - and I don't care if this is SQL Server, db2 or Oracle - is to have it start up automatically with the OS. It's a sure fire recipe for a potentially terminally corrupt database: all you need is for the last shutdown to have been caused by a hardware crash involving the right kind of loss of disk. And no, RAC/SAN/Clustering won't help you here!

In the particular case of Oracle, you now will have ALL your multiplexed controlfile copies pointing to a failed, attempted recovery: the very last place you want to be at!

Of course: had Oracle paid attention to the many requests for enhancements, there were a few asking for controlfile mux copies to be offlined/onlined dynamically. That way folks could always turn off one of the muxed copies at system startup by default, then add it later manually if the db started up fine. But then again: why listen to folks who have been suffering - sorry: using - their product for decades? All "old Cobol dinosaurs", are they?...


Been busy last week with some minor personal and friend's problems: an old friend of mine lost his Mum to a combination of old age and cancer. That really touched me as I'm due for the same at some early future stage. I spent some time comforting him and thinking about the whole episode. Things appear to be better now so hopefully I'll have free time to continue my hobbies.

The next two weeks I'm on early-start shifts: that means I'll be at work at sparrow-fart and back home at around 4pm. I like that. Means around 4 hours of daylight in Sumer to catch up with all the little jobs that need doing and still have time to do some photos. Or go out for a quick 9-hole golf sortie. Or whatever. A much better way of running one's day. Wish I could make it permanent. But the other folks I share the work shifts with think the same way. (sniff...)

A word to the folks from the UK who might read this:
sorry about the Ashes.

But they were due back. There, I said it! (flak jacket on)

Catchyalata, folks.



not sure anyone should be laughing, but:

(if you're using Firefox, click on image to see the detail)

what sort of mindset prompts anyone to plonk a witch's hat like this in the main entrance to their business address?

I suppose it's the same mindset of the support person who gets a call from a client complaining that something is running slow or using up too much CPU, then proceeds to do a few screen grabs with "sar" or similar and finally replies that "something is wrong with your application, the server is running fine".

how about a look into V$SESSION_LONGOPS for starters? if all was going well, odds on that the problem will be a "CBO senior moment" and there will be some FTS going on. if that's indeed the case, how about fishing the actual SQL causing the problem using the SQL_ADDRESS column in that view and V$SQL. and if a view is involved, how about fishing its text from DBA_VIEWS and attaching that to the - now quite extensive - reply to the client?

at the end of it all, the second reply will say - essentially - the same as the first one. but it'll have that little bit of value-add that separates the professional's attitude.

and who knows, the client may suddenly "click" onto something else as a result of this extra information and actually be able to fix a few problems rather than just one?

or is it the mindset of the sales attendant at the local mall who doesn't even bother to understand what the customer wants and proceeds to try and sell something else equally useless? who knows there might actually be an opportunity there to sell not only the correct item AND some additional useless, expensive crap - as a result of a now happy punter?

it's all about attitude, isn't it?

on the photo front: I'm starting to get the hang of the new scanner. finally had some serious play time with it and the results are indeed superb. I've been wasting my time trying to get quality results from a flatbed: should have invested in a proper film scanner ages ago! then again: had I done so, maybe I wouldn't have trained my eye and mind to find and track scanning problems?

still not perfect, but the results are starting to please me a lot.

the film that David Littleboy sent me from Japan turned out to be a stunning experience: it's by far the best colour negative film I've ever seen, bar none.

sure, some of the Kodak UC100 is precious.

but this stuff - Fujicolor 160NC Pro - is absolutely one or two ranks above anything else I've seen. not only does it produce amazingly smooth color gradation and saturation but it also doesn't block out and scans really well without any of the grain "clumping" I see with some other emulsions.

truly outstanding and highly recommended for anyone still into film.
it's also called Fujicolor 160S Pro in other markets.

anyways, time to go back to my Oblivion game for another hour or so of healthy escapism before I call it a night.

catchyalata, folks



this showed up in one of our 10gr2 alert logs:

Tue Dec 5 10:00:58 2006
Thread 1 advanced to log sequence 1411
Current log# 5 seq# 1411 mem# 0: /u209/oradata/ZOT/ZOT_redo05.log
Tue Dec 5 10:21:56 2006
Some indexes or index [sub]partitions of table SYS.WRH$_SEG_STAT have been marked unusable
Tue Dec 5 10:30:37 2006
Thread 1 advanced to log sequence 1412
Current log# 1 seq# 1412 mem# 0: /u209/oradata/ZOT/ZOT_redo01.log

how about an error code, mr Oracle? perhaps we should read the alert log in its entirety now? instead of "grepping", like everyone has done for longer than I can remember?

of course, a little bit of investigation showed this:

select * from dba_part_indexes
2 where table_name = 'WRH$_SEG_STAT';
Press return to continue...

------------------------------ ------------------------------
------------------------------ ------- ------- ---------------
(etcetc, snipped for brevity)
0 2 0 LOCAL
1 row selected.


ZOT->select index_name,partition_name,high_value,status,tablespace_name
2 from dba_ind_partitions
3 where index_name = 'WRH$_SEG_STAT_PK';
Press return to continue...

------------------------------ ------------------------------
-------- ------------------------------

WRH$_SEG_STAT_PK WRH$_SEG_ST_3930333368_0
3930333368, MAXVALUE

2 rows selected.

so: which one exactly was marked as "unusable"?

beats me. ain't AWR peachy? I like this kind of automation, though. yes, it simply prunes partitions older than a week and this message is part of that process.

makes sense: anything to reduce my workload is welcome. just wish someone at Oracle had the vision to write messages in the alert log that can be "grepped" for...

while I'm here and following on from my very rude interjection - my apologies - after Joel's reply, I must mention these:

bugs 3406157, 5237272, 5458753

I won't mention what they are, it'd be breaking our support agreement with Oracle. anyone with proper and authorized Metalick access can check what this is about.

scary eh? I've seen this happen in in Linux. could never pinpoint it to any known bug. by luck I stumbled upon this and from there I got the bugs above.

that is a violation of the most basic rules of safety in any database!

unbreakable, mr Oracle? Why bother? it's BROKEN already!

quite frankly: although this is supposedly fixed in, it's just completely unacceptable that it isn't in ALL PRIOR VERSIONS all the way down to 9ir1!

perhaps it's time for mr Oracle to stop pandering to the "technology de jour" and other moronic flights of fancy and concentrate their R&D on fixing bugs in what is after all their flagship product?

if I have to pay a premium price for this sort of crap, then I simply won't.
or should we start learning Postgres?


more scripting fun

it's been a week of exercising my old shell scripting skills, this one...

well, picture this:

. someone installs a new test instance called "zot10".
. prior to this, there was a "zot" test instance there.
. a week later cron fires off the cold backup of "zot" .
. cold backup fails, complaining that there was a left-over process after shutdown still connected to the "zot10" instance!


this is the command line that checks for "left-over" processes after shutdown:

ps -ef|grep "ora_pmon_$ORACLE_SID"|grep -v "grep"

followed by some suitable return code testing.

nothing wrong with it. on face value...

but the devil is always in the details: in HP boxes, the output of "ps" ends on the comand line string, with EOL after it.

but that is NOT what the above grep search string looked for. it looked for "ora_pmon_zot", period. *anywhere* in the output of ps.

you guessed it: "ora_pmon_zot" and "ora_pmon_zot10" all look the same to such a match string!

there was always a "left-over" process for "zot" for as long as there was a "zot10" instance running!

the fix was to make grep look for the CORRECT match string:

grep "ora_pmon_${ORACLE_SID}\$"

something else I always do: use the "{}" around variable names in shell scripting. I know: it's not needed in 99.9% of the cases.

it's the remaining 0.1% though that makes you leave bed at 3am to fix silly problems. I'm a strong believer in avoiding ALL possibility of problems, not just 99.9%. As such I use the "{}" around variable names ALL the time. Period.

'nyways: 'nuff shop-talk

not much done in the photo front: been very busy with parties, setting up the Xmas decos inside the house, etc. got three rolls to take to the lab this week, will scan them later. and I've got to start on my older underwater slides at some stage!

it's been pelting down for the whole weekend. to the point where our planned fishing trip had to be canceled!