MOVE

 

Your ELOPR execution itself is clean, but I would not start ELO_LN_DS_META_DATA_01 from the alone yet. There are two different things in your results that need to be separated.

The completed ELOPR run is excellent:

• Scheduler ACPT_ASV_PR_EXECUTE_JOB = SUCCEEDED

• FAILURE_COUNT = 0

• Duration ≈ 8h 22m

• Manifest = 260,731 SUCCESS / 83.47 GB

• No PENDING, RUNNING, or FAILED manifest rows

However, your third is important. The query intended to show remaining source segments appears to return:

INDEX                 1
INDEX PARTITION  155321    ~9.754 GB
TABLE                22
TABLE PARTITION  105387   ~113.759 GB

If that grid really belongs to:

WHERE tablespace_name = 'ELO_PR_STG_DATA_01'

then the source is not empty, despite the manifest saying SUCCESS. We must resolve that contradiction before progressing. If Grid 3 is instead the target ELO_PR_STG_DATA_01_N, then it is expected.

Also, the invalid views in FN2GR2DS1_05_DBO should be compared with the PRE baseline. A tablespace move should not normally invalidate ordinary views merely because segments moved. Do not mass-compile them until you establish whether they were already invalid before the migration.

Run this one transition gate

This is deliberately small. It simultaneously tells us source versus target placement, manifest state, job result, and invalid-object summary.

SET SERVEROUTPUT ON SIZE UNLIMITED
SET LINESIZE 220
SET PAGESIZE 200
SET TIMING ON

PROMPT ================================================================
PROMPT ELOPR CLOSEOUT / LN_METADATA GO-NO-GO
PROMPT ================================================================

PROMPT === 1. SOURCE VS TARGET PHYSICAL SEGMENTS ===

SELECT tablespace_name,
       segment_type,
       COUNT(*) AS segment_count,
       ROUND(SUM(bytes)/1024/1024/1024,3) AS gb
FROM dba_segments
WHERE tablespace_name IN
      ('ELO_PR_STG_DATA_01',
       'ELO_PR_STG_DATA_01_N')
GROUP BY tablespace_name, segment_type
ORDER BY tablespace_name, segment_type;


PROMPT === 2. ELOPR MANIFEST FINAL STATE ===

SELECT status,
       COUNT(*) AS operations,
       ROUND(SUM(NVL(size_mb,0))/1024,2) AS manifest_gb
FROM rdsadm.ts_move_log
WHERE run_id = 'ACPT_ASV_PR_STAGING_20260922'
  AND phase_no > 0
GROUP BY status
ORDER BY status;


PROMPT === 3. ELOPR JOB FINAL RESULT ===

SELECT job_name,
       state,
       enabled,
       failure_count,
       last_start_date,
       last_run_duration
FROM dba_scheduler_jobs
WHERE owner = 'RDSADM'
  AND job_name = 'ACPT_ASV_PR_EXECUTE_JOB';


PROMPT === 4. INVALID OBJECT SUMMARY -- COMPARE WITH PRE BASELINE ===

SELECT object_type,
       COUNT(*) AS invalid_count
FROM dba_objects
WHERE owner = 'FN2GR2DS1_05_DBO'
  AND status = 'INVALID'
GROUP BY object_type
ORDER BY object_type;


PROMPT === 5. LN_METADATA MANIFEST READINESS ===

SELECT run_id,
       status,
       COUNT(*) AS operations,
       ROUND(SUM(NVL(size_mb,0))/1024,2) AS gb
FROM rdsadm.ts_move_log
WHERE run_id = 'ACPT_ASV_LN_METADATA_20260922'
GROUP BY run_id, status
ORDER BY status;

The decision is simple

If output #1 shows:

ELO_PR_STG_DATA_01_N    TABLE...
ELO_PR_STG_DATA_01_N    TABLE PARTITION...
ELO_PR_STG_DATA_01_N    INDEX...
ELO_PR_STG_DATA_01_N    INDEX PARTITION...

and no rows at all for ELO_PR_STG_DATA_01, then physical ELOPR relocation is confirmed.

If those 105387 / 155321 segments are actually under ELO_PR_STG_DATA_01, stop there. Don't start LN_METADATA. We need to determine why the manifest says SUCCESS while the source still contains physical segments.

About the INVALID views

Don't do this yet:

EXEC UTL_RECOMP.RECOMP_SERIAL(...);

and don't blindly compile the whole schema.

First compare against the PRE-migration invalid-object baseline. If the same views were invalid before ELOPR, they're unrelated baseline conditions. If they became invalid only after this migration, that's a post-migration discrepancy that should be understood before application release.

That does not automatically mean the data movement failed.