ROMFASTSQL/proxmox/lxc108-oracle/clienti/oracle-xe-21c/README.md

ROMPETROL ENERGY — Recreare PDB Oracle XE 21c după ORA-12954

Client: ROMPETROL ENERGY Schemă aplicație: ROMPETROLE (parolă inițială: ROMFASTSOFT) Bază de date: Oracle XE 21c (CDB XE + PDB XEPDB1) pe Windows Stadiu: rezolvat — PDB recreat, total alocat redus de la 13.5 GB la ~3 GB

Simptom

Aplicația nu mai putea scrie în baza de date. La operații de DML / cleanup:

ORA-12954: The request exceeds the maximum allowed database size of 12 GB.

Inclusiv DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL eșua cu același cod, deci nici curățarea audit trail-ului nu mai era posibilă în-place.

Diagnostic

Limita 12 GB a Oracle XE se aplică pe suma dba_data_files (spațiu alocat), nu pe dba_segments (spațiu efectiv folosit). Datafile-urile pot fi 90% goale și tot să atingă limita.

Distribuție găsită la diagnostic:

Componentă	Alocat
SYSAUX	7.8 GB (segmente reale: 7.5 GB)
UNDOTBS1	2.1 GB
SYSTEM + alte	rest
Total	~13.5 GB (peste limită)

Cauze SYSAUX umflat (în ordinea impactului):

1. SQL Tuning Sets (wri$_sqlset_*) — ~5 GB acumulat
2. AWR snapshots — retention default + moving window baseline 8 zile
3. Audit policies active (ORA_SECURECONFIG, ORA_LOGON_FAILURES) → AUDSYS umflat în PDB nou creat din PDB$SEED
4. Auto tasks (sql tuning advisor, auto space advisor) regenerează constant date

Vezi depanare-ora-12954-spatiu.md pentru queries-le de diagnostic.

Ce s-a încercat (parțial)

1. DROP pe SQL Tuning Sets via DBMS_SQLTUNE.DROP_SQLSET — nu a eliberat spațiul LOB-ului. TRUNCATE direct pe wri$_sqlset_* a funcționat.
2. DBMS_ADVISOR.DELETE_EXPIRED_TASKS, MODIFY_SNAPSHOT_SETTINGS, PURGE_STATS, PURGE DBA_RECYCLEBIN — au eliberat segmentele.
3. ALTER DATABASE DATAFILE ... RESIZE pe SYSAUX — eșec ORA-03297 (used data beyond resize value). Pe XE 21c nu există ALTER TABLESPACE ... SHRINK (apare doar din 23ai). Segmentele SYSAUX erau la high water mark și nu puteau fi compactate.
4. UNDOTBS1 — soluționat prin recreare (drop tablespace + recreate cu datafile mic). Funcționează pentru UNDO, NU și pentru SYSAUX.

Concluzie: SYSAUX nu se poate shrink-ui pe XE 21c → singura soluție definitivă = recrearea PDB-ului.

Soluție: recreare PDB + reimport

Pași (orchestrator: import/recreare_pdb.sql):

1. Export din PDB-ul vechi (înainte de orice DROP):
   • expdp Data Pump pentru schemele aplicației: CONTAFIN_ORACLE, ROMPETROLE
   • expdp separat pentru tabele SYS custom (SYS.AUTH_SERII, SYS.AUTH_DETALII, SYS.INFO)
   • export_pdb_complet.sql din SQLPlus pentru obiectele de cod SYS (packages, views, triggers, context) care nu se pot exporta cu Data Pump
2. DROP PLUGGABLE DATABASE XEPDB1 INCLUDING DATAFILES din CDB$ROOT
3. CREATE PLUGGABLE DATABASE XEPDB1 din PDB$SEED cu admin user nou
4. Faza 1 import (import/11_import_master.sql) — infrastructură care trebuie să existe înainte de Data Pump: tablespaces (01) → useri (02) → directories (03) → tabele SYS (04) → context (08)
5. Data Pump impdp scheme aplicație cu remap_tablespace=USERS:ROA (PDB-ul nou din seed nu are tablespace USERS)
6. Data Pump impdp tabele SYS custom cu table_exists_action=APPEND
7. Faza 2 import (import/11_import_master_faza2.sql) — obiecte dependente de date: cod SYS (05) → views (06) → triggers (07) → granturi (09) → sinonime publice (10)
8. Recompilare — DBMS_UTILITY.COMPILE_SCHEMA pentru CONTAFIN_ORACLE, ROMPETROLE, SYS
9. Prevenție — dezactivare auto tasks, retention AWR la min 8 zile, NOAUDIT POLICY pe ORA_SECURECONFIG și ORA_LOGON_FAILURES

Rezultat

Componentă	Înainte	După recreare PDB
SYSAUX	7.8 GB	390 MB
SYSTEM	—	370 MB
ROA	—	2 GB
UNDOTBS1	2.1 GB	165 MB
Total alocat	13.5 GB	~3 GB

Marjă recâștigată față de limita 12 GB: ~9 GB.

Scripturi în acest director

Fișier	Scop
depanare-ora-12954-spatiu.md	Ghid complet ORA-12954: diagnostic, cleanup, resize, gotcha-uri Oracle XE 21c
import/recreare_pdb.sql	Orchestrator (drop PDB → recreate → faze import)
import/export_pdb_complet.sql	Export obiecte SYS care nu merg via Data Pump
import/01_tablespaces.sql	Faza 1.1: ROA tablespace
import/02_useri.sql	Faza 1.2: CONTAFIN_ORACLE, ROMPETROLE
import/03_directories.sql	Faza 1.3: DIRECTORY objects
import/04_sys_tables.sql	Faza 1.4: tabele SYS custom
import/05_sys_code_objects.sql	Faza 2.1: packages SYS
import/06_sys_views.sql	Faza 2.2: views SYS
import/07_sys_triggers.sql	Faza 2.3: triggere SYS
import/08_context.sql	Faza 1.5: application context
import/09_granturi.sql	Faza 2.4: granturi
import/10_sinonime_publice.sql	Faza 2.5: sinonime publice
import/11_import_master.sql	Faza 1 master (rulează 01 → 04, 08)
import/11_import_master_faza2.sql	Faza 2 master (rulează 05 → 07, 09 → 10) + verificare
import/cleanup_audit.sql	Curățare audit trail (rulează doar dacă DB-ul nu e plin)

Reutilizare la alți clienți

Scripturile sunt parametrizate la nivel de schemă aplicație. Pentru un client nou cu aceeași problemă (Oracle XE 21c plin):

1. Adaptează 02_useri.sql cu noua schemă (înlocuiește ROMPETROLE)
2. Adaptează 04_sys_tables.sql și 09_granturi.sql la nevoie
3. Rulează exportul, apoi recreare_pdb.sql pas cu pas
4. La pasul de prevenție, rulează imediat NOAUDIT POLICY și DBMS_AUTO_TASK_ADMIN.DISABLE — dacă lași PDB-ul nou în default, problema reapare în câteva luni

Lecții învățate

1. TRUNCATE > DROP pe SQL Tuning Sets — DROP nu eliberează LOB-ul.
2. Limita 12 GB = dba_data_files — segmentele pot fi mici, contează spațiul alocat.
3. SYSAUX nu se poate shrink pe XE 21c (fără 23ai). Singura ieșire = recreare PDB.
4. AWR retention >= 8 zile — moving window baseline default e 8 zile, nu poți seta sub fără să modifici baseline-ul (care nu există ca procedură pe XE 21c).
5. PDB nou din PDB$SEED are audit policies active — ORA_SECURECONFIG și ORA_LOGON_FAILURES umflă AUDSYS rapid. Dezactivare imediat după CREATE.
6. DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL eșuează când DB-ul e plin — chiar și în restricted mode. Prevenția > intervenția.
7. PDB nou nu are tablespace USERS — toate impdp-urile cu obiecte pe USERS necesită remap_tablespace=USERS:ROA.
8. Pe Windows, AS SYSDBA în impdp/expdp trebuie inclus în ghilimelele conexiunii: expdp "sys/...@XEPDB1 AS SYSDBA" ...

---

Last Updated: 2026-04-25 Autor depanare: Marius Mutu