# Depanare spatiu Oracle la clienti

```powershell
powershell -File COMUN\utile\diag_spatiu.ps1 -Alias <ALIAS_TNS> [-Disc] [-SysPassword <parola>] [-Top 30]
```

Strict read-only in afara lui `-Disc` (singura parte care scrie: un `.ps1` temporar in `DMPDIR`,
lansat cu `sys.ExecuteScriptOS` si sters la final). Actiunile de curatare sunt doar **sugerate**,
niciodata executate. 8 sectiuni: conexiune/versiune (CDB-PDB), tablespace + top segmente, audit,
alert log/trace/ADR, archivelog/FRA, disc server, alti mancatori de spatiu, verdict.

Pentru actualizarea blocata de spatiu, punctul de plecare e `depanare-pack-update.md`.

## Jobul automat `DIAGSPATIU_ZILNIC` (SVN r17969)

Echivalentul in baza al scriptului de mai sus, rulat zilnic la 06:00 de la fiecare client:
`co_2026_08_03_02` (tabela `DIAG_SPATIU_LOG`, istoric purjat la 90 zile), `co_2026_08_03_03`
(`PACK_DIAG_SPATIU`), `co_2026_08_03_04` (jobul), `sys_2026_08_03_05` (granturi). Praguri identice
cu `diag_spatiu.ps1`; **email doar la prag depasit**, tacere completa altfel. Sursa de referinta:
`COMUN\docs\PACK_DIAG_SPATIU.pck`.

Sectiunile informative (recyclebin, UNDO, TEMP, istoric statistici/scheduler, top segmente, audit
SYS) se scriu doar cand exista deja o alerta — dau context, nu alerteaza singure.

`co_2026_08_20_01_DIAG_SPATIU_PACK` (20.08.2026) inchide doua gauri prin care o baza blocata putea
sa nu alerteze niciodata:

- **tablespace fara autoextend**: `dba_data_files.maxbytes` e 0, iar conditia `max_bytes > 0` il
  scotea complet din verificare, oricat de plin ar fi fost. Acum plafonul e
  `GREATEST(maxbytes, bytes)`, deci pentru un datafile fix maximul e chiar spatiul alocat. In log,
  maximul 0 se scrie `fara autoextend`, nu `0MB`.
- **disc plin sub datafile autoextensibil**: tablespace-ul arata zeci de GB "poate creste", dar
  autoextend-ul pica. Sectiunea `DISC` are prag propriu (`tnPragDiscMb`, implicit 2048 MB liberi) si
  ruleaza mereu, prima; alerta ei deschide si sectiunile informative (`Verifica` o primeste prin
  `tnAlerteInitiale`). Inainte rula doar daca exista deja o alerta, deci nu putea declansa una.

`co_2026_08_06_08_DIAG_SPATIU_PACK` + `sys_2026_08_06_07_DIAG_SPATIU_GRANT3` (06.08.2026) scriu la
top segmente si **tabela/coloana din care provine segmentul** (`DetaliuSegment`: `DBA_LOBS`,
`DBA_LOB_PARTITIONS`, `DBA_INDEXES`; segmentele temporare se marcheaza ca atare) — fara asta un
`SYS_LOB0000630560C00017$$` de 4 GB in email nu spune nimic, iar serverul clientului nu e accesibil
direct. Atentie: pentru `LOB PARTITION`, `dba_segments.segment_name` e `lob_name`, nu
`lob_partition_name`.

Emailurile ajung pe `marius.mutu@romfast.ro`, cate un expeditor per client
(`roaupdate_<client>@romfast.ro`); citirea lor: `email-thunderbird.md`.

`co_2026_08_06_01_DIAG_SPATIU_PACK` (06.08.2026) corecteaza doua lucruri vazute pe primele rulari:

- **pragul absolut (2048 MB) nu se mai aplica tablespace-urilor al caror maxim e sub el** — orice
  `UNDOTBS`/`SYSTEM` plafonat la 500–2048 MB alerta zilnic, prin definitie; acolo ramane doar garda
  relativa de 15%.
- **emailul contine tot logul rularii** (alertele intai, apoi toate randurile din `DIAG_SPATIU_LOG`,
  cu `!` pe cele peste prag, sortate pe sectiune si valoare descrescator), nu doar un pointer catre
  tabela. Corpul e plafonat la 30000 de caractere (`EmailDiagSpatiu` lucreaza pe `VARCHAR2(32000)`),
  cu marcaj `... restul in DIAG_SPATIU_LOG` la depasire.

## Mecanisme reutilizabile (din investigatia pentru job)

- **`CONTAFIN_ORACLE.SERVER_INFO`** tine parolele `PASSWORD_SYS`/`PASSWORD_CONTAFIN_ORACLE`
  (zip+base64, nu criptare), caile `SQLPLUSPATH`/`POWERSHELLPATH`/`DMPDIR`, cheile `EMAIL_*` si
  cache-ul `VERSIUNE_<SCHEMA>`. Parola se citeste cu `PACK_UPDATE.GetSchemaParola('<SCHEMA>')`
  (decodeaza doar pentru `SYS` si `CONTAFIN_ORACLE`; pentru schemele de firma intoarce
  `'ROMFASTSOFT'` hardcodat).
- **Rulare ca `SYS` din PL/SQL**: scrii un `.sql` in `DMPDIR` cu `connect sys/<parola>@ROA as
  sysdba` + `spool`, il lansezi cu `sys.UpdateSQLPLUS` si astepti fisierul de iesire; pentru OS,
  `sys.ExecuteScriptOS` (PowerShell). Ambele sunt asincrone (job `dbms_scheduler` de tip
  `executable`, auto-drop) — mecanismul folosit si de `PACK_UPDATE.UpdateDatabaseSqlPlus`. Fisierele
  temporare au nume proprii, ca sa nu se bata cu `script_master.sql` al actualizarii.
- **`PACK_UPDATE.EmailLog` nu e reutilizabila** pentru alt continut: subiectul e hardcodat
  ("Actualizare ROA ...") si corpul vine din `UPD_LOG`. Pentru alte alerte, bloc `UTL_SMTP` propriu
  care citeste aceleasi chei `EMAIL_*`.
- **Scripturile `sys_*`** se aplica automat, ca orice `co_`/`ff_`: prefixul e recunoscut in
  `PACK_UPDATE.UpdateSchema*`, schema `SYS` se actualizeaza **prima**, iar `UpdateVersiune` isi
  scrie randul in `CONTAFIN_ORACLE.versiune` (schema `SYS` n-are tabela proprie). Deci un `sys_`
  livrat in aceeasi zi ruleaza inaintea scripturilor `co_` care depind de el.

## Ce umple spatiul, in ordinea frecventei

- **Tablespace cu `maxbytes` atins** — nu "disc plin", ci un plafon pus la instalare. Pe XE limita
  de 11/12 GB e pe *date utilizator*, nu pe `SYSTEM`.
- **`SYSAUX`** — SQL Tuning Sets (`wri$_sqlset_*`), AWR, audit policies active pe un PDB nou.
- **Fisierele `.aud`** din `audit_file_dest` (`adump`) — zeci de mii, niciodata curatate; **nu se vad
  din SQL**, doar cu `-Disc`.
- **Alert log / trace / incident** (`diagnostic_dest`) — se purja cu `adrci purge`.
- **FRA plina cu `log_mode=ARCHIVELOG`** → `ORA-00257`/`ORA-19809`; baza se blocheaza brusc, fara
  eroare vizibila in aplicatie.
- Recyclebin, `UNDO` umflat, istoric statistici/scheduler, `TEMP`.
- **Tabele de log ale aplicatiei** care cresc nelimitat (tiparul `SYS.INFO` de pe SIGMA) — apar in
  raportul de top segmente, numele difera per client.

## Cazuri

- **Rompetrol Energy** (XE 21c): `ORA-12954`, limita de 12 GB pe `dba_data_files` atinsa. `SYSAUX`
  umflat la 7.8 GB din SQL Tuning Sets (~5 GB) + AWR + audit policies. `TRUNCATE wri$_sqlset_*` a
  eliberat segmentele, dar `RESIZE` a picat cu `ORA-03297` (`SYSAUX` nu se shrink pe XE 21c) →
  singura solutie a fost **recrearea PDB-ului**, 13.5 GB → 3 GB. Detalii:
  `E:\proiecte\ROMFASTSQL\proxmox\lxc108-oracle\clienti\oracle-xe-21c\` (`README.md`,
  `depanare-ora-12954-spatiu.md`).
- **ROA_CENTRAL** (`ORA-65114`, 02.08.2026): acelasi tipar, rezolvat prin curatenie tintita in loc
  de recreare PDB; SQL-uri gata scrise in acelasi repo (`docs/curatenie-spatiu-oracle.sql`).
- **SIGMA** (03.08.2026): `SYSTEM` plafonat la 600 MB — vezi `depanare-pack-update.md`.
- **VADECO** (XE 11.2, 20.08.2026): actualizarea a picat cu `ORA-00604` + `ORA-01654: unable to
  extend index SYS.I_IDL_CHAR1 in tablespace SYSTEM` la un `create package body` — eroarea n-are
  legatura cu scriptul: `IDL_CHAR$` e locul unde Oracle scrie codul PL/SQL. `SYSTEM` era 600 MB
  alocat cu `maxsize` tot 600 MB (autoextend pornit, dar la plafon), din care ~207 MB doar
  `SOURCE$`/`IDL_*` si 41 MB `SYS.INFO`. Deblocare: `alter database datafile '...\SYSTEM.DBF'
  autoextend on next 50m maxsize 2048m` (pe XE plafonul de 11 GB e pe date utilizator, nu pe
  `SYSTEM`), apoi reluarea actualizarii si `sys_2026_08_08_02` pentru `SYS.INFO`. Jobul de
  diagnostic n-ar fi ajutat: batch-ul murise inainte de `co_2026_08_03_02/03/04`, deci nu era
  instalat.

## Capcane

- **Segmentele `TEMPORARY` dintr-un tablespace permanent nu dispar intotdeauna la restart** (ACN,
  06.08.2026: 1.3 GB ramasi si dupa repornirea serviciului). Daca `v$sort_usage` e gol, sunt orfane
  si se curata fortat, ca `SYS`: `alter session set events 'immediate trace name DROP_SEGMENTS level
  <ts#+1>'` (`ts#` din `v$tablespace`) — la ACN au disparut instantaneu, cu tot spatiul recuperat.
  Daca nici asa nu pleaca, apartin unui DDL neterminat — cauta `SYS_JOURNAL%` (index online) sau
  obiecte `INVALID/UNUSABLE` in schema respectiva.
- **`shrink space` pe un LOB cere ASSM**; pe un tablespace MSSM da `ORA-10635` (cazul `ROA` la ACN).
  Echivalentul care merge: `alter table t move lob (col) store as (tablespace <ts>)` — reconstruieste
  segmentul, tine tabela blocata cat dureaza si cere spatiu liber cat segmentul mutat.
- **Privilegiile `ANY` nu se aplica pe obiectele din schema `SYS`** cat timp
  `O7_DICTIONARY_ACCESSIBILITY=FALSE` — orice curatare acolo cere `SYSDBA`.
- Parola `SYS` e de obicei cea generica (vezi `COMUN\docs\local\oracle.md`), dar **nu la toti
  clientii** (ex. ROMCONSTRUCT) — cand nu merge, se ia cu `PACK_UPDATE.GetSchemaParola('SYS')`.
  `-SysPassword` ramane optional: diagnosticul de baza merge complet fara el, doar sectiunile
  SYSDBA se sar.
- **Rolurile nu se aplica in pachete cu drepturi de definitor**: un pachet care refera static
  `dba_*`/`v$*` iese `INVALID` la clientul care are accesul doar prin rolul `DBA`, chiar daca
  aceleasi interogari merg din SQL*Plus. De aceea granturile directe din `sys_2026_08_03_05`.
  Lantul de actualizare **nu** se opreste in acest caz: `sqlplus` iese cu cod 0 la eroare de
  compilare, deci se vede doar ca pachet invalid + job cazut.
- **Curatenia poate esua din lipsa de spatiu** (`DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL` a picat asa la
  Rompetrol): intai ridici plafonul, apoi cureti.
- `RESIZE` pe datafile da `ORA-03297` daca extentele folosite nu sunt la coada fisierului — un
  `DELETE` fara `MOVE`/`SHRINK` nu recupereaza MB.
- Dimensiunile reale ale fisierelor de pe disc nu se vad din SQL — `-Disc`, prin `ExecuteScriptOS`.
- **`-Disc` merge doar pe servere Windows** (`ExecuteScriptOS` lanseaza PowerShell). Pe Linux
  expira curat dupa 60s, cu mesaj.
- **`MAX_PDB_STORAGE` se citeste doar de pe un alias care tinteste radacina CDB.** De pe un
  serviciu de PDB (cazul obisnuit al aliasurilor din `tnsnames.ora`), `alter session set
  container=CDB$ROOT` da `ORA-01031` — e nevoie de un alias separat spre radacina.
