scripturi de diagnostic baza de date + script de livrare

- diag_actualizare.ps1: de ce s-a oprit actualizarea (UPD_ISTORIC, UPD_LOG,
  script_master.log prin UTL_FILE, versiuni per schema, spatiu tablespace, verdict)
- diag_spatiu.ps1: spatiu Oracle la clienti (tablespace, audit, ADR, FRA, disc server)
- livrare.ps1: git_sync + curatenie + verificari + commit/push
- curatenie.ps1: sterge si docs\propuneri_*.md
- docs: depanare-spatiu-oracle.md nou, depanare-pack-update.md completat cu cazul SIGMA

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

docs/depanare-pack-update.md

@@ -5,6 +5,16 @@ Actualizarea automata a aplicatiilor si a bazei ruleaza din jobul `CONTAFIN_ORAC
 **UpdateScripts** (umple `UPD_DATABASE`) -> **UpdateDatabaseSqlPlus** (aplica scripturile pe scheme).
 O etapa esuata le opreste pe toate urmatoarele.
 
+## Scriptul de diagnostic
+
+`COMUN\utile\diag_actualizare.ps1 -Alias <ALIAS_TNS>` ruleaza tot lantul de mai jos si scoate un
+verdict (unde a ramas rularea, care e scriptul candidat, unde e eroarea). Strict read-only; `-Disc`
+adauga verificarea spatiului pe discurile serverului (singura parte care scrie ceva — un `.ps1`
+temporar in `DMPDIR`). Foloseste-l intai; sectiunile de mai jos explica ce citeste si de ce.
+
+Cand cauza e spatiul (tablespace plin, audit/loguri Oracle care umplu discul), continua cu
+`depanare-spatiu-oracle.md` si `COMUN\utile\diag_spatiu.ps1`.
+
 ## Unde te uiti, in ordine
 
 | Ce | Unde |
@@ -52,6 +62,31 @@ Fisierul se poate citi si fara acces la desktopul serverului, prin `UTL_FILE` pe
 `DMPDIR` (`fopen(...,'R',32767)` + `get_line` in bucla; tine ultimele N linii intr-un tablou —
 partea utila e la sfarsit).
 
+### Caz: nu orice esec de script e o problema de SQL (SIGMA, 03.08.2026)
+
+`ff_2026_07_29_02_COMUN_TVA11.SQL` a picat pe `MARCU` cu `ORA-01653: unable to extend table
+SYS.INFO ... in tablespace SYSTEM` (din `SYS.PINFO`/`SYS.AUTH_PACK`, recursiv). Tablespace-ul
+`SYSTEM` era plin: autoextensibil, dar cu `maxbytes` atins la 600 MB, ~2 MB liberi. **Orice**
+script ar fi picat identic — `AUTH_PACK` scrie in `SYS.INFO` la fiecare conectare. Cand eroarea nu
+priveste obiectele scriptului, verifica intai spatiul.
+
+Ce a contat, pentru data viitoare:
+
+- **`maxbytes` mic nu e o limita XE.** Cele 11 GB ale XE sunt pe *date utilizator*; un plafon mic pe
+  `SYSTEM.DBF` e o setare de instalare. Se ridica din `contafin_oracle` (are `ALTER DATABASE`):
+  `alter database datafile '<cale>\SYSTEM.DBF' autoextend on next 50M maxsize 2000M;`
+- **Spatiul pe discul serverului se verifica fara RDP**, cu `sys.ExecuteScriptOS` (vezi mai jos) —
+  `Get-WmiObject Win32_LogicalDisk -Filter "DriveType=3"`, iesire in `DMPDIR`, citita cu `UTL_FILE`.
+  Job asincron, dar raspunde in cateva secunde.
+- **`SYS.INFO` e tabel ROA, nu obiect de dictionar** (log de login scris de `PINFO`, ~7 randuri per
+  conectare, +16-17k randuri/luna, nimic din baza nu-l citeste). Se poate goli, **dar numai ca
+  `SYSDBA`**: privilegiile `ANY` (`DROP ANY TABLE`, `DELETE ANY TABLE`) nu se aplica pe obiectele
+  din schema `SYS` cat timp `O7_DICTIONARY_ACCESSIBILITY=FALSE`, deci din `contafin_oracle` iese
+  `ORA-01031`.
+- Restul lui `SYSTEM` era dictionar Oracle (`IDL_UB1$`, `SOURCE$`, `IDL_UB2$`, `ARGUMENT$` ~207 MB) —
+  de neatins fara export/import. `AUD$`/`FGA_LOG$` erau goale. Recyclebin-ul si bloat-ul de scheduler
+  stateau in `ROA`/`SYSAUX`, nu in `SYSTEM`.
+
 ## Descarcarea (UpdateApp)
 
 Cu `server_info.POWERSHELLDOWNLOAD = '1'`, `PACK_UTILS.DownloadFileOS` scrie un `.ps1` cu `curl` in