ROMFASTSQL/docs/diagnostic-ora-65114-spatiu.md

ORA-65114 la salvarea istoricului de coduri fiscale — diagnostic

Data: 02.08.2026 · Server: ROA_CENTRAL (10.0.20.121:1521) · Conexiune folosita: MARIUSM_AUTO

Eroarea

[Oracle][ODBC][Ora]ORA-65114: space usage in container is too high
ORA-06512: at "CONTAFIN_ORACLE.PACK_ISTORIC_CF", line 153
ORA-06512: at "MARIUSM_AUTO.PACK_PARTENERI", line 720

begin pack_parteneri.save_istoric_cod_fiscal(...); end;

OEXECUTOR.OEXECUTA
VERIFICAREANAF.SALVEAZAISTORICDINCURSOR
VERIFICAREANAF.VERIFICALISTACIF
FRM_VERIFICARE_PARTENERI.DO_VERIFICA

Nu e o eroare de cod. Codul VFP/PL-SQL e corect; INSERT-ul in CONTAFIN_ORACLE.ISTORIC_CODURI_FISCALE esueaza pentru ca baza nu mai are unde sa scrie. Verificarea a 1526 de CIF-uri a fost doar declansatorul (scrie ~1500 randuri deodata) — orice alt INSERT/UPDATE mai mare pica la fel acum.

Topologia serverului 10.0.20.121

Verificat prin sondare de servicii (conectare cu user inexistent: ORA-01017 = serviciul exista, ORA-12514 = nu exista):

Port	Serviciu	Ce e
1521	XE	CDB root
1521	ROA	PDB — con_id 4, aici ruleaza ROACONT
1521	ROA2	al doilea PDB (user MARIUSM_AUTO nu exista acolo)
1522	XEPDB1	instanta separata (DSN ROA_CENTRAL3)

Deci da: doua PDB-uri in acelasi CDB XE pe portul 1521, plus o a treia baza pe 1522. 10.0.20.122 (vechea intrare ROA_CENTRAL din tnsnames-ul clientului 11.2) nu mai raspunde.

Consecinta pentru plafon: MAX_PDB_STORAGE e per PDB (ridicarea lui pentru ROA nu atinge ROA2), dar limita XE de 12 GB date de utilizator e pe intreg CDB-ul, comuna celor doua PDB-uri. Cat consuma ROA2 nu se poate vedea din ROA — e nevoie de o conexiune SYSDBA in CDB$ROOT (vezi "Ce trebuie masurat" mai jos).

Cauza reala

Oracle 21c Express Edition (XE), container XE (CDB), PDB-ul ROA:

Marime	Valoare
MAX_PDB_STORAGE	5 GB (5368709120)
Total datafiles	5,29 GB
Total tempfiles	0,21 GB
Total ocupat	~5,5 GB → peste plafon

Tablespace-uri:

Tablespace	Alocat (MB)	Liber (MB)	Autoextend max
ROA	2848	1	32 GB (blocat de plafonul PDB)
SYSAUX	1590	0	32 GB
SYSTEM	490	28	32 GB
USERS	250	249	32 GB
UNDOTBS1	235	222	32 GB

Fisierele ar putea creste (autoextend pana la 32 GB), dar MAX_PDB_STORAGE = 5G opreste extinderea → ORA-65114.

Ce ocupa spatiul

In tablespace-ul ROA (unde scrie aplicatia)

Obiect	Tip	MB	Randuri	Observatie
SOFT.ERRORS	tabela	392	678.430	jurnalul de erori raportate de clienti (goMyXMLHTTP.postError)
CONTAFIN_ORACLE.UPD_DATABASE.SCRIPT_CONTENT	LOB	336	3.308	continutul scripturilor de update DB
MARIUSM_AUTO.IREG_PARTENERI + indecsi	tabela+idx	~580	1.546.290	registrul ANAF importat in schema de dezvoltare
MARIUSM_AUTO.XSERVER_LOG	tabela	152	1.752.814	log
CONTAFIN_ORACLE.RTVAI_FISIERE.ISTORIC	LOB	89	—
ACN.LOG_REDESCHID.OBSERVATII	LOB	72	—

MARIUSM_AUTO.ISTORIC_CF_BKP_20260731 (552 randuri) e neglijabil — nu el e problema.

In SYSAUX (nu e "date de utilizator", dar intra in plafonul PDB)

Obiect	MB	Observatie
SYS.WRI$_SQLSET_PLAN_LINES.OTHER_XML (LOB)	432	SQL Tuning Sets ramase
AUDSYS.AUD$UNIFIED (+ LOB)	338	unified audit trail

Masuratoare din CDB$ROOT (sysdba, 02.08.2026)

con_id	PDB	Total (GB)	MAX_PDB_STORAGE	Stare
2	PDB$SEED	0,73	—	read only
4	ROA	5,49	5 GB	peste plafon
5	ROA2	3,67	5 GB	are ~1,3 GB marja

Tablespace-uri per PDB (MB):

	ROA	SYSAUX	SYSTEM	USERS	UNDOTBS1
con 4 (ROA)	2848	1590	490	250	235
con 5 (ROA2)	2048	700	410	250	135

Date de utilizator pe tot CDB-ul: 5401 MB. Limita XE 21c e 12 GB → mai sunt ~6,6 GB disponibili. Deci plafonul de 5 GB al lui ROA poate fi ridicat.

Alte constatari relevante:

• Baza e in NOARCHIVELOG → nu exista recuperare punctuala; ce se sterge e pierdut.
• UNDOTBS1 = 235 MB, din care 222 liberi, si nu se poate extinde cat timp PDB-ul e peste plafon → orice DELETE mare trebuie facut in loturi cu commit.

Optiuni de rezolvare

A. Ridicarea plafonului PDB (instant, fara pierdere de date)

-- ca SYSDBA, in CDB$ROOT:
alter pluggable database ROA storage (maxsize 7G);

7 G pentru ROA + 5 G pentru ROA2 = exact limita XE de 12 GB. Efect imediat: fisierul roa01.dbf poate creste din nou. E si conditia ca pasii de curatenie sa poata rula (altfel nici UNDO nu se poate extinde).

B. Curatenie — script gata de rulat: docs\curatenie-spatiu-oracle.sql

Ce contine, in ordinea din script (verificat fiecare candidat inainte):

Pas	Obiect	Ce se sterge	Castig
2	MARIUSM_AUTO.XSERVER_LOG	truncate — 1.752.814 randuri, toate din 2009–2011	~152 MB in ts. ROA
3	SOFT.ERRORS	randurile < 01.01.2020 — 665.781 din 678.430; raman 12.649 (2020–2023). Tabela nu mai e alimentata din 2023	~385 MB in ts. ROA
4	AUDSYS.AUD$UNIFIED	audit mai vechi de 90 zile (64.351 randuri, 09.2025–07.2026)	~340 MB in SYSAUX
5	SYS_AUTO_STS	SQL Tuning Set automat, 23.228 instructiuni; XE nu are Tuning Pack	~430 MB in SYSAUX

Total estimat: ~1,3 GB, din care ~537 MB direct in tablespace-ul ROA (acolo unde esueaza INSERT-ul).

Precautii incluse in script:

• SOFT.ERRORS se sterge in loturi de 50.000 cu commit — un DELETE monolitic ar cere ~450 MB undo, iar UNDOTBS1 are 222 MB liberi si nu se poate extinde.
• Dupa stergere: enable row movement + shrink space cascade. Fara asta, blocurile golite raman in segmentul SOFT.ERRORS (high water mark) si nu pot fi folosite de ISTORIC_CODURI_FISCALE.
• truncate ... drop storage la pasul 2 nu genereaza undo si returneaza extenturile imediat.

Nu se atinge (deliberat)

• CONTAFIN_ORACLE.UPD_DATABASE (LOB 336 MB) — contine scripturile de update DB folosite de PACK_UPDATE.
• MARIUSM_AUTO.IREG_PARTENERI (1.546.290 randuri, ~580 MB cu indecsi) — registrul ANAF importat; ar fi cel mai mare castig, dar e decizie de-a ta daca mai e necesar.
• MARIUSM_AUTO.ISTORIC_CF_BKP_20260731 (552 randuri) — neglijabil ca marime.

C. Ce NU rezolva

Modificari in codul VFP sau in PACK_ISTORIC_CF / PACK_PARTENERI. Un commit mai des sau loturi mai mici doar amana eroarea.

Ce s-a executat efectiv (01–02.08.2026)

Toti pasii au fost rulati cu sys ... as sysdba pe ROA_CENTRAL. Fisa de interventie (cu corectiile aparute la rulare): docs\curatenie-spatiu-oracle.sql.

Pas	Actiune	Rezultat
1	alter pluggable database ROA storage (maxsize 7G)	plafon 5 G → 7 G; PDB-ul poate extinde din nou
2	truncate MARIUSM_AUTO.XSERVER_LOG	1.752.814 → 0 randuri; segment 152 MB → 0,3 MB
3	truncate SOFT.ERRORS (decizie: golire completa)	678.430 → 0 randuri; segment 392 MB → 0,1 MB, index 12 MB → 0,1 MB
4	purjare unified audit > 90 zile	64.351 → 4.105 randuri; AUDSYS 409 MB → 46 MB
5	golire SYS_AUTO_STS	23.263 → 0 instructiuni
6	MARIUSM_AUTO.IREG_PARTENERI, pastrare an >= 2025	1.546.290 → 8.166 randuri; tabela 232 → 64 MB, cei 10 indecsi 441 → 128 MB

Pasul 6 nu s-a facut cu DELETE (ar fi insemnat ~1,54 milioane randuri de undo, adica exact ce umflase deja UNDOTBS1), ci: create table ireg_part_keep as select * ... where an >= 2025 → truncate table ireg_parteneri drop storage → insert /*+ append */ inapoi → deallocate unused pe tabela si pe fiecare index → drop table ireg_part_keep purge. Asa structura, cei 10 indecsi (inclusiv cel functional IDX_IREG_PART_010) si toate constrangerile raman neatinse, iar undo-ul generat e neglijabil.

Stare finala

Tablespace	Alocat (MB)	Liber (MB)	Era liber
ROA	2848	1036	1
SYSAUX	1740	447	0
UNDOTBS1	785	0	222
SYSTEM	490	28	28
USERS	250	249	249

PDB ROA: 6,18 GB din plafonul de 7 GB. Eroarea ORA-65114 nu mai poate aparea — INSERT-urile in ISTORIC_CODURI_FISCALE au peste 1 GB liber in propriul tablespace.

Ce a ramas nerezolvat

1. UNDOTBS1 umflat la 785 MB (de la 235). Cauza: stergerea in loturi din SOFT.ERRORS, pornita inainte de decizia de truncate. Toate extenturile sunt UNEXPIRED, deci resize da ORA-03297. Se reia pasul 6 din script dupa ce trece UNDO_RETENTION — recupereaza ~500 MB.
2. SYS.WRI$_SQLSET_PLAN_LINES + LOB-ul lui (592 MB in SYSAUX) raman alocate desi sunt goale: shrink nu e permis dintr-un PDB (ORA-65040), iar LOB-ul are coloane lungi (ORA-10662). Spatiul e reutilizabil de acele segmente, deci nu deranjeaza.
3. IDX_IREG_PART_00005 si tabela IREG_PARTENERI au ramas la 64 MB fiecare dupa deallocate unused (nu au coborat la extentul initial). Nu deranjeaza; daca e nevoie, alter index ... rebuild le aduce la cativa MB.

Capcane intalnite (de retinut)

• O linie prompt --- text --- in sqlplus: -- porneste un comentariu care inghite instructiunea de pe randul urmator. Un truncate nu s-a executat, desi iesirea parea normala. Foloseste prompt >> text.
• truncate ... drop storage nu a dezalocat extenturile; segmentul a ramas 152 MB cu tabela goala. A fost nevoie de alter table ... deallocate unused keep 0.
• dbms_audit_mgmt.init_cleanup / is_cleanup_initialized cu AUDIT_TRAIL_UNIFIED dau ORA-46250 intr-un PDB; set_last_archive_timestamp + clean_audit_trail merg direct.