Archive for the ‘erp’ tag
Backward Compatability
Backward Compatability is a very big technological driver. Especially for software companies like Oracle that have customers with a large installed base of users who rely on expensive functionality that they have purchased. When companies invest in software it is usually for very good business reasons and they expect that software to carry on doing at least what it did in the previous version as time progresses.
In 2006 I argued (www.niall.litchfield.dial.pipex.com/ManageabilityManifesto.pdf) that Oracle Corp had removed some existing functionality from Standard Edition users of the database product by making certain features that had previously been available in a management pack for SE users (and the base product for that matter). I started a petition (that had very little effect, the relevant product manager said they preferred to hear direct from customers – presumably in sales meetings – and not from users and advocates of the product ) and generally made a bit of a fuss.
Four years later and the same team have committed a similar error again. If you visit http://www.oracle.com/oms/enterprisemanager11g/webcast-067871.html you can hear Charles Phillips and others talking about Oracle Enterprise Manager 11g. What’s frustrating for me is that some of what is described (for example the management packs for Oracle E-Business Suite described in BreakOut Session 1 @8:33 , but especially 10:14-12:44) exists in the 10g product, but will not install on and is not certified for 11g. I can’t speak to whether an upgraded installation will work correctly, but I’m not encouraged. It turns out that this subject was covered on Stephen Chan’s excellent blog at http://blogs.oracle.com/stevenChan/2010/06/oem_11g_amp_acmp_plans.html. It rather looks as if to get features that were working in 10g Enterprise Manager, you’ll have to wait for a future release of the management pack – and moreover that possibly this project has only just started.
Possibly Related Posts:
New Features, New Defaults, New Side-Effects
Starting with 11.2 which is now available for all the major platforms the behaviour of the CREATE TABLE statement has changed. Specifically, as introduced here, when creating a conventional table in a database created with the default options then the initial segment is not created until the first row is inserted into the table.
The good part of this is well described in the link above, specifically
The advantages of this space allocation method are the following:
•A significant amount of disk space can be saved for applications that create hundreds or thousands of tables upon installation, many of which might never be populated.
•Application installation time is reduced
In other words this is a very nice enhancement for applications like, for example, the Oracle E-Business Suite which typically take multiple hours to install and install a large number of objects that will never be used by any given customer.
I am however already aware of 2 potential downsides to this. The first downside will also apply to exactly the ERP type of application that the designers apparently had in mind for this feature. This is well described in Metalink Note 1050193.1 as follows:
The sequences created as default ( start with 1 increment by 1) are not staring with ’1′ when used in insert query script, Instead they are starting with 2 or 4.
This behaviour of sequences is seen in version Oracle11gR2, not seen in earlier versions
In other words if you specify a sequence and a start with value to generate a range of IDs to be used to create a primary key, the sequence will effectively not start with the “START WITH” value. This is likely a minor inconvenience but one to be aware of if you subscribe to the artificial key design paradigm.
The second is described in this forum thread and is a result of the new default behaviour only applying to the Enterprise Edition of Oracle. Should you create an 11.2 database using the default options and later wish to export the data and import into a standard edition database (We have a number of clients for whom this is not a hypothetical case, they’ve done exactly this in the past) then there isn’t currently a satisfactory method to do this for schemas of any size. The issue is compounded currently by the fact that the Enterprise only status of this feature is not correctly documented.
All in all I think I’d rather that the default value for the initialisation parameter DEFERRED_SEGMENT_CREATION was set to false with the option for people who regularly create schemas with large numbers of never to be used tables and for whom application software installation time is a significant concern to set it to TRUE. It just seems like one of those cases where adopting a new option as a default in the very first release in which it is available is a less than optimal idea.