RE: 8i-10g upgrade

  • From: "Michael Fontana" <mfontana@xxxxxxxxxxx>
  • To: <guillermo.bort@xxxxxxx>
  • Date: Mon, 1 Dec 2008 10:33:43 -0600 (CST)

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:


A)      Actively working the issue.

B)      Gaining the attention of SAP and Oracle support.

C)      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



From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Jared Still
Sent: Sunday, November 30, 2008 10:11 AM
To: guillermo.bort@xxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: 8i-10g upgrade


On Fri, Nov 28, 2008 at 5:19 AM, Bort, Guillermo <guillermo.bort@xxxxxxx>

    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.



Other related posts: