From f5dbb4cc2d89444bbee0b8ae07a16eeccc017ee3 Mon Sep 17 00:00:00 2001 From: Marius Date: Sat, 8 Aug 2026 16:25:30 +0300 Subject: [PATCH] curatenie spatiu --- docs/curatenie-spatiu-oracle.sql | 134 +++++++++++++++++ docs/diagnostic-ora-65114-spatiu.md | 217 ++++++++++++++++++++++++++++ 2 files changed, 351 insertions(+) create mode 100644 docs/curatenie-spatiu-oracle.sql create mode 100644 docs/diagnostic-ora-65114-spatiu.md diff --git a/docs/curatenie-spatiu-oracle.sql b/docs/curatenie-spatiu-oracle.sql new file mode 100644 index 0000000..4ad6810 --- /dev/null +++ b/docs/curatenie-spatiu-oracle.sql @@ -0,0 +1,134 @@ +-- ===================================================================== +-- Curatenie spatiu Oracle -- server 10.0.20.121:1521, PDB ROA +-- Motiv: ORA-65114 la INSERT in CONTAFIN_ORACLE.ISTORIC_CODURI_FISCALE +-- Diagnostic: docs\diagnostic-ora-65114-spatiu.md +-- +-- EXECUTAT pe 01-02.08.2026. Scriptul e pastrat ca fisa de interventie +-- si ca sablon pentru urmatoarea curatenie. Contine corectiile aflate +-- la rulare (vezi notele "ATENTIE"). +-- +-- Rulare: +-- D:\ROA\instantclient_19_18\sqlplus.exe -L "sys/@ROA_CENTRAL as sysdba" @curatenie-spatiu-oracle.sql +-- +-- ATENTIE GENERALA: liniile "prompt" NU trebuie sa se termine cu "---"; +-- sqlplus interpreteaza "--" ca inceput de comentariu si inghite +-- instructiunea urmatoare (s-a intamplat: un truncate nu s-a executat, +-- desi iesirea parea normala). Foloseste "prompt >> text". +-- ===================================================================== + +set lines 220 pages 500 feedback on timing on serveroutput on + + +prompt >> STARE INITIALA +alter session set container=CDB$ROOT; +select con_id, name, open_mode, round(total_size/1024/1024/1024,2) gb_total from v$pdbs order by 1; +select con_id, property_value max_pdb_storage from cdb_properties where property_name='MAX_PDB_STORAGE' order by 1; + + +prompt >> PAS 1: ridicare plafon PDB ROA 5G -> 7G +-- XE 21c permite 12 GB date de utilizator pe intreg CDB-ul; erau 5401 MB +-- (ROA 3098 + ROA2 2298 + root 5). Plafoanele devin 7+5 = 12 G. +-- Fara acest pas PDB-ul nu poate extinde NICI un fisier, nici UNDO, +-- deci pasii urmatori ar putea esua. +alter pluggable database ROA storage (maxsize 7G); + + +alter session set container=ROA; +prompt >> liber in tablespace ROA inainte (MB) +select nvl(round(sum(bytes)/1024/1024,1),0) mb_liber from dba_free_space where tablespace_name='ROA'; + + +prompt >> PAS 2: MARIUSM_AUTO.XSERVER_LOG +-- 1.752.814 randuri, toate din 2009-2011 (DATA_INCEPUT). Log mort, 152 MB. +truncate table mariusm_auto.xserver_log drop storage; +-- ATENTIE: "drop storage" NU a dezalocat extenturile (segmentul a ramas +-- 152 MB / 5 extenturi cu tabela goala). Pasul care elibereaza efectiv: +alter table mariusm_auto.xserver_log deallocate unused keep 0; + + +prompt >> PAS 3: SOFT.ERRORS +-- 678.430 randuri, 392 MB, nimic mai nou de 2023 (tabela nu mai e alimentata). +-- Decizie Marius: golire completa. +truncate table soft.errors drop storage; +alter table soft.errors deallocate unused keep 0; +-- +-- Varianta cu pastrare partiala (daca la o rulare viitoare tabela e activa): +-- stergerea trebuie facuta IN LOTURI cu commit -- un DELETE monolitic pe +-- ~665.000 randuri cere ~450 MB undo, iar UNDOTBS1 avea 222 MB liberi. +-- declare +-- n_lot pls_integer; n_total pls_integer := 0; +-- begin +-- loop +-- delete from soft.errors where created_at < date '2020-01-01' and rownum <= 50000; +-- n_lot := sql%rowcount; commit; n_total := n_total + n_lot; +-- exit when n_lot = 0; +-- end loop; +-- dbms_output.put_line('sterse: ' || n_total); +-- end; +-- / +-- alter table soft.errors enable row movement; +-- alter table soft.errors shrink space cascade; +-- alter table soft.errors disable row movement; + + +prompt >> PAS 4: unified audit trail (SYSAUX) +-- 64.351 inregistrari, 09.2025-07.2026, 409 MB. Se pastreaza ultimele 90 zile. +-- ATENTIE: dbms_audit_mgmt.init_cleanup / is_cleanup_initialized dau +-- ORA-46250 pentru AUDIT_TRAIL_UNIFIED intr-un PDB. Nu sunt necesare: +-- set_last_archive_timestamp + clean_audit_trail functioneaza direct. +begin + dbms_audit_mgmt.set_last_archive_timestamp( + audit_trail_type => dbms_audit_mgmt.audit_trail_unified, + last_archive_time => systimestamp - 90); + dbms_audit_mgmt.clean_audit_trail( + audit_trail_type => dbms_audit_mgmt.audit_trail_unified, + use_last_arch_timestamp => true); +end; +/ + + +prompt >> PAS 5: SQL Tuning Set automat SYS_AUTO_STS (SYSAUX) +-- 23.263 instructiuni capturate automat. Artefact de diagnostic; XE nu are +-- licenta Tuning Pack. Se goleste continutul, setul ramane. +begin + dbms_sqltune.delete_sqlset(sqlset_name => 'SYS_AUTO_STS', sqlset_owner => 'SYS'); +end; +/ +-- ATENTIE: segmentele SYS.WRI$_SQLSET_* NU pot fi micsorate dintr-un PDB +-- alter table sys.wri$_sqlset_plan_lines shrink space -> ORA-65040 +-- alter table ... modify lob (other_xml) (shrink space) -> ORA-10662 +-- Spatiul ramane alocat segmentului (reutilizabil de el), ~590 MB in SYSAUX. + + +prompt >> PAS 6 (de rulat la >30 min dupa stergerile mari): micsorare UNDO +-- Stergerile in loturi au umflat UNDOTBS1 de la 235 la 785 MB. Extenturile +-- devin EXPIRED abia dupa expirarea UNDO_RETENTION; pana atunci resize da +-- ORA-03297. Se reia periodic pana trece. +declare + v_file varchar2(400); +begin + select file_name into v_file from dba_data_files where tablespace_name='UNDOTBS1' and rownum=1; + for m in 1..8 loop + declare + v_mb number := 800 - m*70; + begin + execute immediate 'alter database datafile ''' || v_file || ''' resize ' || v_mb || 'M'; + dbms_output.put_line('UNDO redimensionat la ' || v_mb || ' MB'); + exit; + exception when others then + dbms_output.put_line(v_mb || ' MB -> ' || substr(sqlerrm,1,60)); + end; + end loop; +end; +/ + + +prompt >> STARE FINALA +select d.tablespace_name, round(sum(d.bytes)/1024/1024,0) mb_alocat, + nvl((select round(sum(f.bytes)/1024/1024,0) from dba_free_space f + where f.tablespace_name=d.tablespace_name),0) mb_liber + from dba_data_files d group by d.tablespace_name order by 2 desc; + +alter session set container=CDB$ROOT; +select con_id, name, round(total_size/1024/1024/1024,2) gb_total from v$pdbs order by 1; +exit diff --git a/docs/diagnostic-ora-65114-spatiu.md b/docs/diagnostic-ora-65114-spatiu.md new file mode 100644 index 0000000..ed105bc --- /dev/null +++ b/docs/diagnostic-ora-65114-spatiu.md @@ -0,0 +1,217 @@ +# 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.