Thanks for explaining it. Luckily, it was just a test in UAT before moving to the 1tb production table. And thanks for giving guidance on when partitioning does and doesn't make sense.

Please see the MOS Note:
Initial Extent Size of a Partition Changed to 8MB from 64KB After Upgrade to 11.2.0.2 or Later (Doc ID 1295484.1)
Where it explains why this happens and gives you a workaround to fallback to pre-11g behavior:
alter session set "_partition_large_extents" = false;
or
alter system set "_partition_large_extents" = false;

We have a situation where partitioning a 156G, ~750M row table with CLOBs ends up growing by at least 10% when redefined into yearly partitions. The CLOBs are securefile, and we are getting the most out of our Advanced compression license in both the original and new table. This is a staging database run, before we run it in production - there isn't much recent data here. The database is near latest 19c on Oracle Cloud.

Both

Year   Approximate Size
P2016  10G -- includes more years from earlier
P2017  1.6G
P2018  18G
P2019  50G
P2020  51G
P2021  38G
P2022  16M
P2023  16M
P2024  16M

I thought maybe the difference might be made up in a smaller lob segment due to some difference while using the STORAGE IN ROW clause, but that's grown too, from ~6,504G to ~6,536G. The database was also 11.2.0.4 before 2018. The table has always been INSERT/SELECT only with very rare exceptions. Anyway, here's the essence of the original table definition:

CREATE TABLE OUR_BIG_DATA
(
  THE_ID    NUMBER                      NOT NULL,
...
  THE_CLOB_FIELD           CLOB                        NOT NULL,
...
  CREATION_DATE     DATE                        NOT NULL,
...
)
LOB (THE_CLOB_FIELD) STORE AS SECUREFILE (
  TABLESPACE  ORIGINAL_TS -- smallfile
  ENABLE      STORAGE IN ROW
  CHUNK       8192
  RETENTION
  COMPRESS HIGH
  NOCACHE
  LOGGING
  STORAGE    (
              INITIAL          2M
              NEXT             2M
              MINEXTENTS       1
              MAXEXTENTS       UNLIMITED
              PCTINCREASE      0
              BUFFER_POOL      DEFAULT
             ))
TABLESPACE ORIGINAL_TS
PCTFREE    10
INITRANS   25
MAXTRANS   255
STORAGE    (
            INITIAL          2M
            NEXT             2M
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
           )
LOGGING 
COMPRESS FOR OLTP
NOCACHE;

The new table has the same definition apart from the partitioning/tablespaces:

CREATE TABLE OUR_BIG_DATA
(
  THE_ID    NUMBER                      NOT NULL,
...
  THE_CLOB_FIELD           CLOB                        NOT NULL,
...
  CREATION_DATE     DATE                        NOT NULL,
...
)
LOB (THE_CLOB_FIELD) STORE AS SECUREFILE (
  TABLESPACE  NEW_TBSP_MAX -- bigfile
  ENABLE      STORAGE IN ROW
  CHUNK       8192
  RETENTION
  COMPRESS HIGH
  NOCACHE
  NOLOGGING)
COMPRESS FOR OLTP
TABLESPACE NEW_TBSP_MAX -- bigfile
PCTFREE    10
INITRANS   1
MAXTRANS   255
STORAGE    (
            BUFFER_POOL      DEFAULT
           )
PARTITION BY RANGE (CREATION_DATE)
(  
  PARTITION P2016 VALUES LESS THAN (TO_DATE(' 2017-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    COMPRESS FOR OLTP
    TABLESPACE NEW_TBSP_2016
    LOB (THE_CLOB_FIELD) STORE AS SECUREFILE (
      TABLESPACE  NEW_TBSP_2016
      ENABLE      STORAGE IN ROW
      CHUNK       8192
      RETENTION
      COMPRESS HIGH
      NOCACHE
      LOGGING
      STORAGE    (
                  INITIAL          16M
                  NEXT             16M
                  MINEXTENTS       1
                  MAXEXTENTS       UNLIMITED
                  PCTINCREASE      0
                  BUFFER_POOL      DEFAULT
                 ))
    PCTFREE    10
    INITRANS   1
    MAXTRANS   255
    STORAGE    (
                INITIAL          16M
                NEXT             16M
                MINEXTENTS       1
                MAXEXTENTS       UNLIMITED
                PCTINCREASE      0
                BUFFER_POOL      DEFAULT
               ),  
...

and the other 8 partitions are similar in tablespaces all created from the same script.

No problem "wasting" up to 16M per year but I cannot explain how this gets to 15G. This has been highlighted as we're running a space saving exercise with intent to prune off old partitions in nonproduction environments after cloning from production, and there are many clones.

There may be some parallel threads involved in the dbms_redefinition execution, but AFAIK it's not very high - the session either had force parallel dml/ddl 8 or 16. Can anyone explain this? It takes a while to change something and rerun, and my brain hurts.