Oracle Home naming convention

From: Patterson, Joel <>
Date: Mon, 26 Nov 2012 10:17:59 -0500
Message-ID: <>

Resent with new subject since the reply is really not TTS related.

Joel Patterson
Database Administrator
904 727-2546

-----Original Message-----

From: Patterson, Joel
Sent: Monday, November 26, 2012 10:17 AM To: ''; Subject: RE: Transportable Tablespaces and Deferred segment creation "bug"

Ahem :),
Speaking of oracle homes, I am still experimenting with naming conventions and the out-of-line patching. So looking for input.

I decided lately to spell out the oracle version, (and I had no reason for numbering dbhome_1, _2).

/orasoft/app/oracle/product/ /orasoft/app/oracle/product/ etc..

The original reason was to upgrade and patch databases one at a time, say to, and to One result is upgrading through a version, say to 112033 leaves an empty oracle homes like 10g, 112010, or 112030, which can be cleaned up, or left in place for later upgrading of other databases.

Now, if I get another PSU, I think I have to install the base 112030 in a new home say,, and apply the PSU 112035?

So the jury is still out on whether or not this is an optimal idea or not. Any comments from the list? Any other naming conventions that the listers like over others?

Joel Patterson
Database Administrator
904 727-2546
-----Original Message-----

From: [] On Behalf Of Norman Dunbar Sent: Monday, November 26, 2012 5:55 AM
Subject: Transportable Tablespaces and Deferred segment creation "bug"

Morning all,

Oracle versions are Enterprise and Standard on Linux x86-64. May affect others.

I'm fighting/discussing with Oracle Support at the moment on a potential bug in the use of Transportable Tablespaces exporting from an Enterprise Edition database and importing into a Standard Edition.

I need to do this because I (yes, me!) inadvertently assigned the wrong Oracle Home while creating a 6.5 Tb database and built it with Enterprise rather than Standard edition (it was a naming convention that is, ahem, useless, that caused this error).

Anyway, Enterprise comes with deferred_segment_creation defaulted to true, so creating tables and/or indexes doesn't create a segment until the first row is added to the table.

Standard Edition also comes with the default set to true, but Standard Edition ignores the parameter and all segments get allocated on initial creation of the table/index.

Doing a Transportable Tablespace export works fine, doing the import results in a number of IMP-00017 errors caused by ORA-01647 "Tablespace is read only, cannot allocate space in it" errors. It's not the most helpful error message in the world, all the tablespaces being imported are read only because they don't actually exists until the import if done - so I couldn't make them read write even if I wanted to!

All the tables throwing this error on the import are empty in the source (Enterprise) database and don't have a segment allocated for them in DBA_SEGMENTS due to the default setting.

I've written it up here if anyone suffers something similar.

There is nothing in Oracle's docs to say that this will happen, even the engineer on the call at MOS was unable to find any. I've requested that this be logged as a bug, but I don't hold out much hope!



Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767

-- Received on Mon Nov 26 2012 - 16:17:59 CET

Original text of this message