My problem with it is that it’s dumb to have them, and they cause problems like this:

http://blogs.oracle.com/theshortenspot/2009/03/change_to_hidden_oracle_parame.html

The major issue here is that by having these hidden parameters, you effectively have turned every instance to a beta version, and worse, you reward the risk taker DBA by allowing them to do things that they really shouldn’t be doing. It’s just an unneeded hassle that has very little benefit in my mind.

All of which makes me wonder about the piss poor Eclipse support from Oracle. I was only able to find this on the Oracle site. Now, OEP is nice and all, but there is sooo much more that could be, and should be, done with Eclipse and Oracle, especially compared to where IBM is in this same space.

One of the things I’ve been thinking about recently is load testing. It seems like the great white whale of Oracle testing, to validate the effects of load on a running system. I think the reason it proves elusive is:

1) It seems so easy. C’mon. You think, there has to be an easy way of doing this…
2) Simple hardware changes between systems make big differences. Getting a ‘perf’ installation to look JUST like production is expense and difficult to justify. No one cares about performance until it sucks.
3) Just what data am I load testing? Things like Swingbench aren’t very specific about what data they are using. And the devil is in the details here – if you aren’t testing transaction for transaction, like for like, you’re screwed.
4) Pseudo testing. ‘We don’t need to do real testing or transactional replay – we can simulate the load. We won’t be pushing transactions through the system.’ Doesn’t work, no matter who says it.

In the 9i days, I was a huge fan of using logminer to get the transactions then replaying it on a sister system. It gave completely accurate results – but it was still costly in terms of time and resources (human and otherwise).

In 11g, Database Replay (discussed here) does the job nicely. I still worry that this kind of functionality strains the redo management a little too much, warping the internals a bit. But, in testing, it tends to get within 5% of the actual results, which is impressive.

Its a slick tool, that may be the final word in load testing an Oracle database.

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1011065100346196442

I really could argue this for days, but lets take a couple of points here:

1) File systems are written in a FUNDAMENTALLY different way then a relational database (WinFS as an example of a filesystem that could NOT mimic a database)

2) If you put a word doc into an Oracle database, you BREAK one of Tom’s cardinal rules: type the column correct for the data.

3) This quote is ridiculous: “if you store them in the database, they are not files anymore – they are data.” No Tom, they are files – the storage DOES NOT MATTER – only the application use does. If the application is built to look at files, you’ve just abstracted its unit of work in a really dumb way.

4) Suggesting that XML DB is the right way to do this is just silly – So, I’m going to take documents that may or may not support the tenents of XML, then put it in XML DB to make is searchable? You’re abstracting the actual format of the doc twice.

That’s just the start of my objections. This is a dumb architectural choice, and while I respect Tom alot, this is just dumb, and cuts to the core of a stupid philosophy about Oracle – that it can do everything.

Tom you’re better than this. Don’t recommend insufficient design just cause its Oracle.