218 lines
9.7 KiB
Markdown
218 lines
9.7 KiB
Markdown
# 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)
|
||
|
||
```sql
|
||
-- 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.
|