Niall's Oracle Pages

Developers may just have noticed that the JDeveloper IDE is now free of charge (support costs mind you). Anyway when I was playing around I noticed that os authentication does not work in the 10.1.0.3 developer preview - I assume it doesn't in any of the production versions either.

It turns out that this is a bug in the oci jdbc driver shipped with the base install of Oracle 10g database (and presumably other 10g branded products). This is fixed in 10.1.0.3 and above.

My solution therefore. Backup the jdev jdbc/lib directory and then replace the contents with the contents of jdbc/lib from a 10.1.0.3 or 10.1.0.4 Oracle Database Oracle_Home. You'll still need to use the oci8 driver of course.

from unattributable comments from todays UKOUG Oracle on Windows special event - more later - it would appear that 10gR2 will be available for download from June 30th. Don't expect windows then just the likely platforms *cough* linux *cough*.

There's an interesting discussion over on Tom Kyte's blog about the software development process. It drew the following comment which I thought worth looking at a little more.

RAD and iterative development methods have pretty much killed design skills as far as I can see. Not that there is anything wrong with these as concepts. As always the problem is their implementation. A large number of development projects take the view that iterative development means you don't have to think at all, just start. I hear quotes like, "We'll refactor that later!", all the time. The problem is that later never comes.

I repeatedly think back to my early days in IT working on real-time control systems with Oracle as a back end. We created requirement specs, functional specs and module specs, all of which were signed off by the customer. We then designed our DB to support the requirements. We wrote pseudocode, had it reviewed, then turned it into real code (PL/SQL and Pro*C). More often than not it worked first time due to the details and care taken along the way. when it was over the customers liked what they were given because they were involved in the whole process.

Fast forward a few years and what do we have, a spec in a single email that the customer hasn't approved, but, "It's OK! We can change it later. It's iterative development!"


Now that's a cariacature, but I'm rather afraid not actually that far from the truth.

RAD and iterative development methods have pretty much killed design skills as far as I can see. Not that there is anything wrong with these as concepts. As always the problem is their implementation. A large number of development projects take the view that iterative development means you don't have to think at all, just start. I hear quotes like, "We'll refactor that later!", all the time. The problem is that later never comes.

Consider also the Agile Manifesto
Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan



This is another formulation of the same idea, that good software is developed not by careful design, appropriate modelling of the business problem you are trying to solve or the task you are trying to automate, but by putting it together as you go. If it doesn't work then undo it and try again, or more probably throw in a case specific fudge. There is something wrong with this as a concept, as well as practical implications, but it is the idea that RAD to some extent, but iterative development in particular is OK as a concept that I wish to remark upon.

The reason I object so heavily to this is partly the last observation from the original comment, later never comes, but mostly because I think this betrays that we as a profession have lost sight of the disciplines of engineering. Consider almost any other engineering discipline that you care to imagine, ship building, tool manufacture, car design, house or office building, computer hardware design even. Can they be characterised by the sort of approaches outlined above, iterative rethinks of core parts of the product (I know lets make the captain's quarters out of marble, marble is very fashionable these days)?

It is unfashionable amongst the /. crowd for example to point out as Fabian Pascal does so effectively that the RDBMS is a (flawed implementation of) a mathematically sound model and that if you wish to effectively use the relational approach you have to understand the model and do the ground work of application of relational design to your specific situation. It seems that it is also becoming fashionable to try and avoid any modelling of what you are trying to achieve at all. Hidden in both the comment and the practical application of the agile manifesto is the fact that the software developer, and probably the client as well, doesn't actually know or understand the problem they are trying to solve or the business process they are trying to automate. Now repeatedly trying something until you find something that works is certainly one approach - it reminds me of my toddler trying all the holes in his posting toy until he finds the hole that the shape goes through - but its surely not as good as knowing what you are trying to build before you start out.

Techies hate marketeers.

It's one of those timeless truths, like your project will be at least one of

• Late


• Overbudget


• Below expectations

Only today has rather brought back to me that it needn't be like this. First I was rather nice about Oracle Corporation marketing in a discussion about RAC on large numbers of nodes over at Oracle-L.

Then, whilst I'm waiting for data to come back off tape I came across a post on marketing's marketing problems over at Seth Godin's blog. Now I don't agree with all on that blog by any means, but the standout argument for me in the excellent article was this.

Marketing is not about trickery or even insincerity. It's about spreading ideas that you believe in, sharing ideas you're passionate about... and doing it with authenticity. Marketing is about treating prospects and customers with respect, and realizing that it's easier to grow the amount of business you do with happy people than it is to find new strangers to accost.

As it happens the Oracle world has some great, and some not so great, exponents of the art of marketing - as defined above. The above is a pretty good description of what Tom Kyte does for Oracle, for example. Its possible, but I'm not convinced, that the 'Grid Message' currently coming out of Redwood Shores is also a sincere spreading of ideas that Oracle is passionate about as well, but it feels more like aligning messages with market trends. That of course is advertising which is a whole different thing.

It was pointed out to me that I, and Mark Bobak, are referred to here as noted Oracle Internals Experts, now whilst it is almost always nice to be called an expert, in this case the attribution of such a term to me is clearly misplaced. If you follow the original article you'll find that it was Mark who offered the nearest thing to Internals information - actually a clarification of terms, My contribution amounted to a suggestion that if desired to allocate more memory to Oracle 10g then raising SGA_TARGET and SGA_MAX_SIZE would be a good first step, and an observation that in low memory situations Oracle seems to make sure the shared pool is a decent size, even at the expense of the buffer cache. I can't really see that either of these are especially expert, or indeed internals.

I know, I know. I said little to no advocacy on these pages. This is a rule with very few exceptions. I am about to make 2. The second of these is Oracle related, but I'll be contacting a few folk at Oracle Corp first to make sure that I express myself fairly.

The second is UK related, and thanks to Shrek for bringing the site to my attention. if, like me you regard the National ID Card proposals as a gross invasion of privacy, asking for trouble (your database has no data quality errors right?), and a huge waste of time, effort and resources. (2000 house moves per day on latest figures all of which need to be accurately captured, entered and verified) then pay a visit to the no2id site (yes its in txt msg spk, you can't have everything) and sign the petition.

If you think that technology will solve security issues, then look at just a couple of precedents.

ID cards - available in both major targets of al-qaeda (NYC and Madrid)
CCTV - that's why city centres are safer than ten years ago.

Technological progress is a good thing, blind faith and abandoning it to governments and vested interests (who is bidding for the contract, it won't be a UK company there isn't one that can supply the technology) isn't.

You restart the database server. The disks are no longer visible to the OS. Of such is deep joy made.

A great line which I entirely agree with from Jeff Hunter's Top 11 Backup and Recovery list. Jeff is absolutely right, because (as Tom says in the comments) you just cannot be allowed to get recovery wrong, the amount you have to think when performing the recovery should be effectively zero. Got to do PITR because you accidentally dropped the wrong table or an end user deleted the wrong account. Follow the steps that you already wrote down and tested.

Where your thinking should not be limited is in diagnosing the fault and examining your options. On at least two occasions we have had classic recovery scenarios - on neither occasion did we actually do recovery, there were other ways to get the data back.

And to make it maybe a Top 12. Before you do a recovery - backup your disaster (preferably with a cold backup if you can). This means if you do make the number one error and get the recovery wrong you at least get another shot at it.

Yesterday was a good day up at the Scottish OUG in Edinburgh. Thanks to a little encouragement from Anjo Kolk we saw Mogens Norgaard in a kilt, not perhaps the best thing in the world to be greeted with at 9am. Doug Burns presented on Parallel Execution, you can read his paper here and if like me you have never really investigated parallel operations, (not really feasible with single-user scripts on a single-cpu machine) it is an excellent discussion of the topic.

Over in the applications/business stream Mark Rittman presented on Business Intelligence in 10g (direct download link), the attendees were almost evenly split between technical guys and business/application oriented delegates which is unusual for this sort of event. It made me think a lot about how little many DBAs (including myself) really know about what is going on the Application Server world.

Thanks to Garry Derrick and Thomas Presslie of the Scottish OUG for inviting me and for the splendid hospitality, and to Lavinia Burns of UKOUG for organising an excellent day.