feat(oracle): granturi dictionar PACK_DIAG_SPATIU + sys-grants.sql legat in flux

Trei probleme gasite pregatind migrarea unui client de pe Oracle XE 11 pe XE 21c.

1. sys-grants.sql nu era rulat de niciun script PowerShell. Era referit doar din
   run-all-sys.sql, care se lanseaza manual. Pe orice instalare facuta cu
   RunAll.cmd lipseau sinonimele SYS (SYN_NEWSCHEMA, SYN_NEWSCHEMAJOB,
   EXECUTESCRIPTOS, SYN_PINFO), DMPDIR si granturile pe DBMS_SCHEDULER / UTL_* /
   DBMS_CRYPTO catre CONTAFIN_ORACLE. Legat ca STEP 3 in 04-create-synonyms-grants,
   dupa import - unde propriul header al fisierului spune ca trebuie rulat.

2. Granturile de dictionar cerute de PACK_DIAG_SPATIU lipseau complet. Consolidez
   sys_2026_08_03_05, sys_2026_08_03_07 si sys_2026_08_06_07 in sectiunea [5/5]
   din sys-grants.sql: SELECT direct pe 18 vederi dba_*/v$*, idempotent, cu
   ORA-00942 tratat pentru vederile absente pe alte editii/versiuni. Grantul prin
   rolul DBA nu ajunge - rolurile nu se aplica in pachetele cu drepturi de
   definitor, iar PACK_DIAG_SPATIU e exact asa; fara ele ramane INVALID si
   DIAGSPATIU_ZILNIC nu ruleaza.

3. Capcana la migrari: tabela de versiuni a lui PACK_MIGRARE traieste in
   CONTAFIN_ORACLE si vine cu DMP-ul, deci baza noua raporteaza scripturile sys_*
   drept aplicate si ROAACTUALIZARI le sare, desi in SYS nu exista nimic. De aceea
   obiectele si granturile SYS se pun la instalare, nu prin actualizator.
   Documentat in sys-updates/README.md si in ghidul nou.

07-verify-installation raporteaza nominal care dintre cele 18 granturi lipsesc.

Documentatie: docs/instalare-si-migrare-oracle.md - arbore de decizie intre
roa-windows-setup/ (client pe Windows), migration/ (Oracle in Docker pe LXC 108) si
new-roa-oracle-server/ (arhiva). Include de ce migration/ nu se foloseste la un
client Windows: creeaza PDB ROA cu OraclePass123, sinonime minimale, fara
SERVER_INFO / ROAUPDATE / ACL / sqlnet.ora, iar sys_objects.sql de acolo creeaza
INFO in SYSTEM - cauza cunoscuta a ORA-01653 la actualizare. Plus comenzile de
export din XE 11 / 10g si plafonul XE de 12 GB.

Corectat pe drum: dual-edition-test-plan si issues-se-prod indicau clonarea
VM 302 -> 303 pentru testul SE, dar 303 e ocupat de Win11-Adina. Mutat pe 304.

NETESTAT pe baza reala - VM 302 e oprit. Scripturile trec doar parse-check
PowerShell.

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

proxmox/lxc108-oracle/docs/instalare-si-migrare-oracle.md

@@ -0,0 +1,218 @@
+# Instalare și migrare Oracle pentru ROA — care director, pentru ce
+
+În `proxmox/lxc108-oracle/` există **trei** directoare cu scripturi de instalare/migrare, iar
+numele lor nu spun de la sine care se potrivește. Nota asta e ghidul de rutare: ce livrează
+fiecare, ce **nu** livrează și cum se aleg între ele.
+
+| Director | Ce e | Stare |
+|---|---|---|
+| [`roa-windows-setup/`](../roa-windows-setup/README.md) | instalare ROA completă pe **Windows** + Oracle 21c (XE sau SE) | activ, validat pe VM 302 (XE) |
+| [`migration/`](../migration/README.md) | migrare Oracle 10g → 21c XE cu Oracle **în Docker pe LXC 108** | activ pentru infrastructura internă |
+| [`new-roa-oracle-server/`](../new-roa-oracle-server/) | arhiva istorică din era Oracle 10g | **doar referință**, nu se rulează |
+
+---
+
+## 1. Arbore de decizie
+
+```
+Baza Oracle ajunge pe un server Windows la client?
+├── DA  → roa-windows-setup/          (PowerShell nativ, fără WSL)
+└── NU  → baza ajunge în Docker pe LXC 108 / alt Linux?
+          ├── DA  → migration/         (bash, orchestrat de 00-MASTER-MIGRATION.sh)
+          └── NU  → niciunul; descrie scenariul înainte de a improviza
+```
+
+**Cazul tipic la client** — server vechi cu Oracle XE 11 (sau 10g), se mută
+`CONTAFIN_ORACLE` + schemele de firme pe un server nou cu Oracle 21c XE, tot Windows:
+→ **`roa-windows-setup/`**, plus pasul de export descris la §4.
+
+---
+
+## 2. Ce livrează fiecare
+
+### `roa-windows-setup/` — instalare ROA, nu doar bază de date
+
+Diferența esențială: `migration/` îți lasă o bază cu schemele înăuntru;
+`roa-windows-setup/` îți lasă o **instalare ROA funcțională**.
+
+| # | Script | Ce face |
+|---|---|---|
+| 01 | `01-setup-database.ps1` | tablespace `ROA`, profil, user `CONTAFIN_ORACLE`, `sqlnet.ora` cu `ALLOWED_LOGON_VERSION=8` |
+| 02 | `02-create-sys-objects.ps1` | obiectele SYS din `sql/sys-objects.sql` (AUTH_PACK, AUTH_DETALII, AUTH_SERII, VAUTH_SERII, INFO, pINFO, SEQ_AUTH_SERII, EXECUTESCRIPTOS, NEWSCHEMA, NEWSCHEMAJOB, UPDATESQLPLUS) |
+| 03 | `03-import-contafin.ps1` | import `CONTAFIN_ORACLE` (parfile: `par/import-contafin.par`) |
+| 04 | `04-create-synonyms-grants.ps1` | `synonyms-public.sql` + `grants-public.sql` + **`sys-grants.sql`** (granturi SYS, sinonime SYS, DMPDIR, granturi de dicționar pentru `PACK_DIAG_SPATIU`), context `SESIUNE`, ACL de rețea |
+| 05 | `05-import-companies.ps1` | import în lot al schemelor de firme (parfile: `par/import-company.par`) |
+| 06 | `06-add-company.ps1` | adaugă o firmă nouă pe un server deja instalat (opțional) |
+| 08 | `08-post-install-config.ps1` | 54 directoare `ROAUPDATE` (fizice + obiecte `DIRECTORY`), `SERVER_INFO`, `AUTH_DETALII` (Customer ID), joburile `UPDATEROA_ZILNIC` / `UPDATERTVAI_ZILNIC` / `SYSINFO_PURJARE_ZILNIC` |
+| 07 | `07-verify-installation.ps1` | raport de verificare: versiune/ediție, tablespace, obiecte, obiecte invalide, sinonime, **granturi de dicționar**, firme din `NOM_FIRME` vs. scheme reale, ACL |
+| 99 | `99-uninstall-roa.ps1` | curățare completă, pentru re-testare |
+
+`RunAll.cmd` le rulează în ordinea `01 → 02 → 03 → 04 → 05 → 08 → 07`.
+`Run.cmd <script>` rulează unul singur, rezolvând `ExecutionPolicy`.
+
+Compatibilitate cu clienți vechi: `01-setup-database.ps1` scrie
+`SQLNET.ALLOWED_LOGON_VERSION_SERVER/CLIENT=8` (implicitul în 21c este 12 și **refuză**
+Instant Client 10/11). Detalii și capcanele — în
+[`config/sqlnet.ora`](../roa-windows-setup/config/sqlnet.ora): fișierul merge în *Oracle Base
+Home*, nu în `ORACLE_HOME`; listener-ul se **oprește și pornește** (nu doar `reload`); parolele
+trebuie resetate ca să se regenereze verificatorul 10G.
+
+### `migration/` — Oracle în Docker pe LXC 108
+
+| Script | Ce face |
+|---|---|
+| `00-MASTER-MIGRATION.sh` | orchestratorul; moduri de export AUTO (SSH) / MANUAL / LOCAL / IN-PLACE |
+| `00-MASTER-MIGRATION.bat` | varianta Windows; pentru scenariile 1-3 deleagă la `wsl bash -c ./00-MASTER-MIGRATION.sh`, iar pe ramura nativă își **generează la runtime** `setup-windows.sql`, `synonyms-windows.sql`, `finalize-windows.sql` |
+| `00-install-oracle21c-xe.sh` | instalează Oracle 21c XE **în Docker** |
+| `01-setup-oracle21c.sh` … `06-finalize-migration.sh` | tablespace + useri, export, transfer DMP, import, sinonime/granturi, recompilare |
+| `sys_objects.sql` | obiectele SYS, **versiunea pre-consolidare** |
+
+De ce nu se folosește la un client Windows, deși are și un `.bat`:
+
+- ramura nativă creează un **PDB numit `ROA`** în CDB-ul XE, cu parola `OraclePass123` — altă
+  convenție decât `XEPDB1` / `romfastsoft` din `roa-windows-setup`;
+- generează un set minimal de sinonime, nu cele 81 publice și nici cele 54 de `DIRECTORY`;
+- nu configurează `SERVER_INFO`, `AUTH_DETALII`, joburile de actualizare, ACL-ul de rețea;
+- nu scrie `sqlnet.ora` de compatibilitate — aplicațiile vechi ale clientului nu se vor conecta;
+- `sys_objects.sql` de acolo creează `AUTH_DETALII`, `AUTH_SERII` **și `INFO` în `SYSTEM`** —
+  exact cauza umplerii tablespace-ului dicționarului și a erorilor `ORA-01653` la actualizare
+  (vezi [`docs/diagnostic-spatiu-clienti.md`](../../../docs/diagnostic-spatiu-clienti.md)). În
+  `roa-windows-setup/sql/sys-objects.sql` asta e deja corectat: `INFO` se creează în
+  tablespace-ul `ROA`.
+
+### `new-roa-oracle-server/` — arhivă
+
+Conține `createdb.sql`, `createco.sql`, `createfn.sql`, `roa.bat`, `roa_firma.bat` și seria
+istorică `sys_2007_*` … `sys_2026_01_*`. E **sursa din care a fost consolidat**
+`roa-windows-setup/sql/sys-objects.sql`, nu un runbook. Nu se rulează pe un server nou.
+
+---
+
+## 3. Ce **nu** e acoperit de scripturi
+
+Exportul de pe serverul sursă nu e automatizat în `roa-windows-setup/`. Fișierele DMP se
+așteaptă deja în `C:\DMPDIR\` pe serverul nou.
+
+---
+
+## 4. Export de pe un server client existent (XE 11 / 10g)
+
+**Oracle XE 11.2 → 21c.** `impdp` din 21c acceptă direct seturile Data Pump produse de 11.2,
+deci nu e nevoie de `VERSION=`:
+
+```bat
+REM pe serverul sursa, ca SYSTEM
+sqlplus system/parola@XE
+  CREATE OR REPLACE DIRECTORY DMPDIR AS 'C:\DMPDIR';
+  GRANT READ, WRITE ON DIRECTORY DMPDIR TO SYSTEM;
+
+expdp system/parola@XE SCHEMAS=CONTAFIN_ORACLE DIRECTORY=DMPDIR ^
+      DUMPFILE=contafin_oracle.dmp LOGFILE=export_contafin.log
+
+expdp system/parola@XE SCHEMAS=FIRMA1,FIRMA2 DIRECTORY=DMPDIR ^
+      DUMPFILE=firme_%U.dmp LOGFILE=export_firme.log PARALLEL=2
+REM  ^ %U e substituția Data Pump; din interiorul unui fișier .bat se scrie %%U
+```
+
+Lista schemelor de exportat se ia din `CONTAFIN_ORACLE.NOM_FIRME` (`WHERE sters = 0`) — e
+aceeași listă pe care `07-verify-installation.ps1` o compară apoi cu schemele existente pe
+serverul nou.
+
+**Oracle 10g ca sursă.** `expdp` există de la 10.1, dar dacă exportul a fost făcut cu `exp`
+clasic, importul se face cu `imp`, nu cu `impdp` — cele două formate nu sunt interschimbabile.
+
+**Export din LXC 108 (mediul intern), pentru clienți care cer compatibilitate 11g:**
+
+```bash
+docker exec oracle18-xe expdp system/romfastsoft@localhost:1521/XEPDB1 \
+  SCHEMAS=CONTAFIN_ORACLE DIRECTORY=DMPDIR DUMPFILE=contafin_oracle.dmp \
+  LOGFILE=export_contafin.log VERSION=11.2
+```
+
+Containerul 18c (port 1522) există tocmai pentru asta — 21c nu poate produce dump-uri cu
+`VERSION=11.2` din cauza tipurilor TSTZ versiunea 31.
+
+---
+
+## 5. Scripturile `sys_*` — proveniență și sincronizare
+
+Scripturile `sys_*` produc obiecte **deținute de SYS**, deci **nu călătoresc în DMP-ul de
+schemă**. Pe un server nou trebuie aplicate explicit, prin `02-create-sys-objects.ps1` și
+`04-create-synonyms-grants.ps1`.
+
+### Capcana tabelei de versiuni
+
+Tabela de versiuni a lui `PACK_MIGRARE` trăiește în **`CONTAFIN_ORACLE`** — acolo își
+înregistrează și scripturile `sys_*` aplicarea (`pack_migrare.UpdateVersiune(..., 'SYS')`).
+Tabela vine cu DMP-ul.
+
+Consecința, la migrarea unui client existent: baza nouă raportează scripturile `sys_*` drept
+**deja aplicate**, `ROAACTUALIZARI` le sare, dar în `SYS` nu există nimic. De aceea obiectele
+și granturile SYS se pun la instalare, din scripturile de setup — nu se așteaptă de la
+actualizator.
+
+### Stare curentă a sincronizării
+
+Sursa scripturilor `sys_*` e `D:\roa\database\SCRIPTURI_CLAR\<an>\<luna>\`.
+
+| Script sursă | Unde e în `roa-windows-setup/` |
+|---|---|
+| `sys_2026_01_14_01_AUTH_PACK` | `sql/sys-objects.sql` — specificația e identică, iar lista de programe din repo e un superset (`GENERARESCRIPT.EXE`, `ROAACTUALIZARI.EXE`, `EXP.EXE`, `IMP.EXE` în plus) |
+| `sys_2026_08_08_02_SYS_INFO_TABLESPACE_PURJARE` | `sql/sys-objects.sql` (INFO creată în tablespace-ul `ROA`) + `sql/scheduler-jobs.sql` (`SYS.SYSINFO_PURJARE_ZILNIC`) |
+| `sys_2026_08_03_05_DIAG_SPATIU_GRANT` | `sql/sys-grants.sql`, secțiunea `[5/5]` |
+| `sys_2026_08_03_07_DIAG_SPATIU_GRANT2` | `sql/sys-grants.sql`, secțiunea `[5/5]` |
+| `sys_2026_08_06_07_DIAG_SPATIU_GRANT3` | `sql/sys-grants.sql`, secțiunea `[5/5]` |
+
+Cele trei scripturi `DIAG_SPATIU_GRANT*` acordă `SELECT` direct pe 18 vederi de dicționar:
+`DBA_DATA_FILES`, `DBA_FREE_SPACE`, `DBA_TEMP_FILES`, `DBA_SEGMENTS`, `DBA_TAB_STATS_HISTORY`,
+`DBA_SCHEDULER_JOB_RUN_DETAILS`, `DBA_RECYCLEBIN`, `DBA_TABLESPACES`, `DBA_LOBS`,
+`DBA_LOB_PARTITIONS`, `DBA_INDEXES`, `V_$INSTANCE`, `V_$DATABASE`, `V_$PARAMETER`,
+`V_$TRANSACTION`, `V_$TEMP_SPACE_HEADER`, `V_$FLASH_RECOVERY_AREA_USAGE`, `V_$VERSION`.
+
+Grantul trebuie să fie **direct**, nu prin rolul `DBA`: rolurile nu se aplică în pachetele cu
+drepturi de definitor, iar `CONTAFIN_ORACLE.PACK_DIAG_SPATIU` este exact așa. Fără ele
+pachetul rămâne `INVALID` și jobul `DIAGSPATIU_ZILNIC` nu rulează. Vederile absente pe o
+ediție/versiune dată sunt sărite (`ORA-00942`), deci scriptul e sigur și pe baze mai vechi.
+
+`07-verify-installation.ps1` are o secțiune dedicată care listează care dintre cele 18 lipsesc.
+
+### Când apar scripturi `sys_*` noi
+
+Un `sys_*` nou fie se **consolidează** în `sys-objects.sql` / `sys-grants.sql` /
+`scheduler-jobs.sql` (dacă e parte din instalarea de bază), fie se pune în `sql/sys-updates/`
+ca patch post-instalare. Vezi
+[`sql/sys-updates/README.md`](../roa-windows-setup/sql/sys-updates/README.md).
+
+---
+
+## 6. Mediu de test
+
+Validarea se face pe **VM 302 (`oracle-test-302`, 10.0.20.130)** — vezi
+[`../../vm302-oracle-test/README.md`](../../vm302-oracle-test/README.md).
+
+| Ediție | Stare |
+|---|---|
+| 21c XE (CDB/PDB) | OK — `RunAll.cmd` rulează complet |
+| 21c SE (non-CDB) | **NETESTAT** — în producție au apărut erori, vezi [`issues-se-prod.md`](../../vm302-oracle-test/docs/issues-se-prod.md) |
+
+VM 302 stă oprit; se pornește cu `ssh root@10.0.20.201 "qm start 302"`.
+Ciclul de re-testare: `99-uninstall-roa.ps1 -Force` → `RunAll.cmd` → `07-verify-installation.ps1`.
+
+Scripturile din `migration/` **nu** au un mediu de test dedicat — se validează direct pe
+LXC 108.
+
+---
+
+## 7. De verificat înainte de a porni o migrare la client
+
+- **Plafonul XE.** 21c XE limitează datele de utilizator la **12 GB** (11.2 XE avea 11 GB),
+  RAM la 2 GB și 2 thread-uri CPU. Se măsoară pe sursă înainte:
+  ```sql
+  SELECT ROUND(SUM(bytes)/1024/1024/1024, 2) AS gb
+    FROM dba_segments
+   WHERE owner NOT IN ('SYS','SYSTEM','OUTLN','DBSNMP','XDB','APEX_040000');
+  ```
+  Peste plafon, singura opțiune e Standard Edition — care e **netestată** (vezi §6).
+- **CDB/PDB.** Pe XE 21c aplicațiile se conectează la **`XEPDB1`**, niciodată la `XE` (CDB root).
+- **Clienți vechi.** `sqlnet.ora` + resetarea parolelor, altfel Instant Client 10/11 nu se conectează.
+- **Versiunea sursei.** `expdp` (Data Pump) și `exp` (clasic) produc formate incompatibile.