cancel
Showing results for 
Search instead for 
Did you mean: 

SHDDBCLONE/DBCLONE max # extents (505) reached in log segment........ FPLAYOUTT ....Error copying table data

Former Member
0 Kudos
I'm in the process of an EHP6 upgrade and am experiencing the following error:
CLONING ERRORS and RETURN CODE in DBCLONE08.QAS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 ETGCLN DELETE FROM DDSTORAGE WHERE DBSYSABBR = 'ORA' AND TABNAME = 'FPLAYOUTT~' AND INDEXNAME = ' '
3 ETGCLN CREATE UNIQUE INDEX "FPLAYOUTT^0" ON "FPLAYOUTT~" ("NAME", "STATE", "LANGUAGE", "ID") PCTFREE 10    INITRANS 002 TABLESPACE PSAPPOOLI NOCOMPRESS STORAGE (INITIAL 0000000088 K NEXT 0000000080 K MINEXTENTS 0000000001 MAXEXTENTS UNLIMITED PCTINCREASE 0000 FREELISTS 001)
3 ETGCLN DELETE FROM DDSTORAGE WHERE DBSYSABBR = 'ORA' AND TABNAME = 'FPLAYOUTT~' AND INDEXNAME = '0'
3 ETGCLN ALTER TABLE "FPLAYOUTT~" MODIFY LOB ("LAYOUT") (CACHE)
3 ETGCLN insert /*+ APPEND */ into "FPLAYOUTT~" (  "NAME", "STATE", "LANGUAGE", "ID", "LAYOUT" ) select  "NAME", "STATE", "LANGUAGE", "ID", "LAYOUT" from "FPLAYOUTT"
1EETGCLN ORA-01693: max # extents (505) reached in lob segment SAPR3.SYS_LOB0000458190C00005$$
1EETGCLN FPLAYOUTT
1EETGCLN Error copying table data
We have set the table FPLAYOUTT to unlimited. Following the solution in SAP Note 533455 - Terminations due to higher number of extents. We have brought down and restarted (in an act of desperation) the system to no avail. Even after the max extenst are set to unlimited, we still get the "max # extents (505) reached". This is a mystery and is holding up our upgrade.
Any help is certainly appreciated.
Thanks in advance,
Kyle

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Turns out that this is a known issue in Oracle where eventhough the table and LOB are set to unlimited, it doesn't recognize that. It has something to do with having upgraded Oracle. There was (and forgive me as I don't know exactly what our DBA did here) a fix available from Oracle to resolve this. It was set in a previous version and couldn't be changed in the current version. Basically Oracle's resolution was to trick the system into thinking it was the older version to make the change. This is how it was explained to me.

Answers (2)

Answers (2)

Former Member
0 Kudos

We have set the table FPLAYOUTT to unlimited.

But the error occured on FPLAYOUTT~ which is the shadow table of the original object.

If you are unlucky, SUM will drop and recreate the table again with the wrong values. If that is the case you can try to catch the right moment, as soon as the object is created and the loading starts, try to either set max extents to unlimited, or increase the next extent.

Another solution could be to create a dedicated locally managed tablespace and move the table there and then retry.

A third possibility is to try to change the properties in SE11 -> storage parameters -> for new creation.

As Stefan said you should get rid of dictionary managed tablespaces as quick as possible.

Cheers Michael

stefan_koehler
Active Contributor
0 Kudos

Hi Kyle,

> We have set the table FPLAYOUTT to unlimited

Did you just set the table to max extent unlimited or the corresponding LOB segment as well? Your issue is caused by the LOB segment (SYS_LOB0000458190C00005$$) and not the "base table".

SQL> select OWNER, EXTENTS, MAX_EXTENTS from DBA_SEGMENTS where SEGMENT_NAME = 'SYS_LOB0000458190C00005$$';

SQL> alter table SAPR3."FPLAYOUTT" modify lob ("LAYOUT") (STORAGE (MAXEXTENTS UNLIMITED));

SQL> select OWNER, EXTENTS, MAX_EXTENTS from DBA_SEGMENTS where SEGMENT_NAME = 'SYS_LOB0000458190C00005$$';

By the way is there a valid reason why you still use dictionary managed tablespaces? We have passed the Oracle 8i times a looooong time ago

Regards

Stefan