RE: 8i-10g upgrade

As both a political move and on the off-chance that there actually is a solution out there, I would bring this to the attention of SAP support.  

It might not hurt to document your issue with Oracle as well. This will provide documentation to the customer that you are:  

1. Actively working the issue.
2. Gaining the attention of SAP and Oracle support.
3. Looking for consensus on a solution.

I would suspect you're on the right track. Assuming Oracle and SAP agree, this would go a long way towards getting whatever resources you need to test and implement, including downtime.

It would also backup the fact that if you do nothing, you might eventually have to suffer debilitating performance issues and perhaps an extended unplanned outage. There is a physical limit to how many extents can be tracked on a dictionary managed tablespace. I would look into this as well.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Jared Still
Sent: Sunday, November 30, 2008 10:11 AM To: guillermo.bort_at_eds.com
Cc: oracle-l_at_freelists.org
Subject: Re: 8i-10g upgrade  

On Fri, Nov 28, 2008 at 5:19 AM, Bort, Guillermo <guillermo.bort_at_eds.com> wrote:

    We thought about DBMS_REDEFINITION (or the legacy alter table move), however that would imply creating new tablespaces, and since the rdbms server a SAP aplication, creating new tablespaces is a bit of a headache, and moving objects arround is even worse. So basically we need to have the same structure on another server, move the tbs to locally and still have the db synchronized.

DBMS_REDEF requires converting all LONGS to LOBS, which DBMS_REDEF will do, but
that may not be what you want to do. There are some SAP notes on this.

ALTER TABLE MOVE will not work with LONG/LONG RAW columns, and as you are a aware, there
are a few in SAP systems.

Jared  

--
http://www.freelists.org/webpage/oracle-l