Actually you don't need to copy the datafiles a read-only tablespace can be shared between instances quite happily - all you have to do is export the metadata from one instance and import it into the other using the same file locations. I use this technique to enable a 3rd party application that maintains its own session metadata to access the data in a physical standby that has been opened read-only - The external application has its own writable instance but the read only tablespaces from the physical have been transported in without changing their file locations. This works on a non-ASM filesystem but as long as your ASM diskgroup is visible to both instances I see no reason why it shouldn't work. Cheers, Ian ________________________________ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Dennis Williams Sent: 15 March 2007 23:55 To: sosoracle@xxxxxxxxx Cc: oracle-l Subject: Re: shared tablespace Cindy, If the historical data doesn't change, you might look into a read-only transportable tablespace. Each database would still have to have a copy, so you wouldn't be saving space, but this feature may figure into your solution. If the suggestions so far don't suit your problem, perhaps you can describe more about what your goals are. Dennis Williams . This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person. Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice. Thank you for your cooperation. Ordnance Survey Romsey Road Southampton SO16 4GU Tel: 08456 050505 http://www.ordnancesurvey.co.uk