[The following is a guest blog post courtesy of Peter Robson, prompted by this event that we both attended. Peter's a good friend, I love his writing style and he's expressed similar opinions in the past to me, so I asked if he would write them down for a wider audience. See what you think. Thanks, Peter.]
Recently I attended an Oracle User Group meeting on server technology. The speakers were excellent, the topics highly relevant to a contemporary interest in server technology, and the audience receptive and appreciative. But there was something wrong – each speaker was showing the audience how to address the failings or weaknesses of the Oracle database system. Given the very high initial purchase price of the product, and the equally daunting annual maintenance costs, this seemed something of an unsatisfactory juxtaposition.
There are three topics I want to address, tuning, upgrades and security.
On tuning. Attendees at this meeting were presented with a veritable avalanche of slides, showing graphs, both 2D and 3D, tables, even 4-dimensional matrices, all illustrating just how many variables can be measured and adjusted in Oracle. Specialists have carried out much serious work and research in this area. Customers in particular get enormous benefit from taking the advice of these highly skilled specialists. Indeed, the proliferation of technical gurus skilled in many of the arcane characteristics of Oracle is a further indirect endorsement of the product itself.
There are winners and losers here. Oracle wins – they need to spend less time on perfecting their product. The consultants win; because of the position Oracle adopts, they are guaranteed a job for as long as Oracle pursues this strategy. The cost of both the product (which one might perhaps begin to suggest is unfinished) and the cost of the down-stream consultancy advice is all born by the customer. In fact, it’s not just the price of purchase, but ongoing maintenance that irks many users. At something like 15 to 20% of the purchase price every year, the customer must pay this price to ensure they receive corrections (euphemistically entitled patches), as well as retain the right to receive the next major release. These privileges are generally described as ‘support’. One might just begin to wonder which party is actually being supported in this situation. It’s a beautiful catch-22 revenue stream, and once again the loser pays all.
Oracle provide some tools (AWR) to assist with tuning the database – but as an extra cost option. They tend to be inserted during the main installation, even if they are not explicitly licensed. It is quite easy to accidentally access one of these components (perhaps by looking at a dictionary view), resulting in the internal logging which Oracle have installed on the customer system recording the event. This will prompt an additional cost being charged to the customer..
But is it acceptable that a vendor should install a product on one’s own hardware, which generates logs using disk space and cpu resources, which the owner of those resources are not permitted to access without paying extra?
One used to have to use a PL/SQL package licensed as part of the Diagnostics pack in order to disable the Diagnostics pack, to ensure that accidental access to one of the monitoring dictionary views was prevented. Only after uproar in the user community was this anomaly resolved. This was a bizarre revenue stream – a costed item to make sure one does not use a cost item. In any event, one has to ask why should one have to pay extra to monitor and adjust the product already paid for? It’s tantamount to buying a car, and being told the dashboard instruments are extra. Worse than that, in fact – it’s like paying extra for the on-board computer that monitors and controls the engine management system.
A talk on upgrades described many of the difficulties in moving from one version to another, including most astonishingly the total corruption of data during its migration from one version of Oracle. The only way to avoid this situation is, apparently, a) don’t upgrade, or b) test, test and test again before going live with a new version. But why should the customer have to test a product so exhaustively for which they pay so much? Does the manufacturer have a lack of confidence in the suitability of a new release? One could be forgiven for believing that Oracle is in fact using the customer base as a means of final testing of new versions. It must explain why many customers are reluctant to buy into the first version of a new release. Of course many installations will upgrade without any problems, but the very fact that problems have to be anticipated is unacceptable given the investment involved in this product.
But the whole issue begs the question of why upgrades appear so thick and fast. I would suggest that this happens for two reasons – income stream, and the drive to develop technology for its own sake. Note the vested interest in the guru community of seeing their clients upgrade. Note also the way in which the underlying architecture of the database seems to change subtly with each new release, requiring a new edition to the guru handbook ‘How to Tune Oracle Version xx’. I do not believe that this is an environment in which the end user is best served. Unless there are particularly strong business reasons to do so, no organisation should ever upgrade just for the sake of it. In fact, I would say that the constant tinkering of the kernel by Oracle with each new release, probably by different, even competing coders within Oracle Corp, militates against the basic stability of the product. If so much testing is required following each new version, then too much must have been changed. Why?
Finally, the issue of security was the subject of another interesting presentation. It recently emerged into the public domain (following the MacKinnon hacking trial and other sources) that there are copies of Oracle embedded in the most secure sites in the US military and security sectors which still have not properly implemented password security. Anyone with a modicum of knowledge of Oracle default passwords can walk right in to many of these databases. As many competent hackers have done from all round the world (and countries from the Far East are notable here). One has to ask what sort of company is it that even allows a foolish customer to install their database product without FORCING them to impose the most fundamental of security constraints – primary password access. This rather worrying gap in basic security has to pose the question of how fit for purpose the Oracle dbms is for installation into a secure environment run by not quite competent users. Downstream security may indeed be excellent, but if the front door is left wide open, that downstream security is somewhat compromised.
So, great product, but it could be so much greater if more effort were directed to improvements truly for the benefit of customers, and not simply to maintain an income stream based on a technological merry-go-round.
Peter Robson