sync SVN r18017/r18018: diagnoza spatiu - autoextend si prag disc

Continut adus prin svn update din alta copie de lucru, identic cu 04a7d05 de
pe origin/main. Doua gauri prin care o baza blocata putea sa nu alerteze:
tablespace fara autoextend (maxbytes = 0 il scotea din verificare, acum
plafonul e GREATEST(maxbytes, bytes)) si disc plin sub datafile
autoextensibil (sectiunea DISC are prag propriu si ruleaza mereu, prima).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013gYCNE26G1G7UoGu2ju7aS

docs/depanare-spatiu-oracle.md

@@ -20,7 +20,19 @@ cu `diag_spatiu.ps1`; **email doar la prag depasit**, tacere completa altfel. Su
 `COMUN\docs\PACK_DIAG_SPATIU.pck`.
 
 Sectiunile informative (recyclebin, UNDO, TEMP, istoric statistici/scheduler, top segmente, audit
-SYS, disc) se scriu doar cand exista deja o alerta — dau context, nu alerteaza singure.
+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`,
@@ -87,6 +99,15 @@ Emailurile ajung pe `marius.mutu@romfast.ro`, cate un expeditor per client
 - **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