fix(roa): aliasul TNS lipsea din Oracle Home, iar actualizarea esua tacut

Constatat la VADECO pe 2026-08-28: pe serverul acela actualizarea ROA nu
aplicase NICIODATA un script, desi jobul raporta succes de la instalare.

PACK_UPDATE nu aplica el scripturile - genereaza D:\DMPDIR\script_master.sql
si lanseaza un sqlplus EXTERN, apoi se termina. Deci UPDATEROA_ZILNIC
raporteaza starea lansarii, nu a actualizarii: SUCCEEDED in ~5 secunde chiar
si cand nu s-a aplicat nimic. Scriptul generat incepe cu
"CONNECT CONTAFIN_ORACLE/...@ROA" (aliasul vine din NOM_FIRME.NUME_SERVER)
si are WHENEVER SQLERROR EXIT, deci iese la prima linie daca aliasul nu se
rezolva.

Lantul cauzal: sqlplus-ul lansat de baza mosteneste mediul serviciului
Oracle. La o instalare noua instanta porneste INAINTE ca 01-setup-database
sa scrie TNS_ADMIN de masina, deci serviciul nu il are si cade pe
tnsnames.ora din Oracle Home. La 21c XE home-ul e read-only, deci fisierul
real e in product\21c\homes\OraDB21Home1\network\admin, iar acolo Oracle
genereaza doar XE, LISTENER_XE si ORACLR_CONNECTION_DATA - fara ROA.
Rezultat: ORA-12154, tacut. Perfid: tnsping ROA REUSESTE dintr-o sesiune
interactiva, pentru ca aceea are TNS_ADMIN.

Eroarea era mascata dublu - jobul zicea SUCCEEDED, iar emailul de raportare
nu pleaca oricum (ORA-29279, SMTP-ul romfast nu anunta AUTH).

01-setup-database.ps1 scrie acum aliasul si in tnsnames.ora al Oracle
Home-ului, cu acelasi IP din LAN. Blocul se IMBINA in fisierul existent:
XE, LISTENER_XE si ORACLR_CONNECTION_DATA raman neatinse, pentru ca de ele
depind extproc si inregistrarea instantei la listener. Cu backup si
idempotent - regexul consuma si comentariile lipite deasupra lui "ROA =",
altfel antetul se dubla la fiecare rulare (prins de test).

Testat unitar (fisier Oracle fara ROA, idempotenta peste 4 rulari, ROA
preexistent cu alt IP la mijloc, fisier inexistent, paranteze echilibrate,
fara BOM) si end-to-end pe o copie a fisierului real de pe serverul VADECO:
tnsping ROA OK, sqlplus CONTAFIN_ORACLE@ROA conectat in XEPDB1, zero ORA-,
XE si LISTENER_XE inca se rezolva.

docs/lectii-actualizare-roa-alias-tns.md are diagnosticul complet, inclusiv
cum verifici ca actualizarea chiar s-a aplicat: script_master.log si
SCHEMA.versiune, NU statusul jobului. Contine si capcana ca randurile din
SCHEMA.versiune vin cu dump-ul la import, deci o schema proaspat importata
pare la zi fara ca actualizarea sa fi rulat vreodata local.

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

CLAUDE.md

@@ -50,6 +50,7 @@ input/                      # Oracle DMP files for import
 - **Instalare/migrare Oracle — care director se folosește**: `proxmox/lxc108-oracle/docs/instalare-si-migrare-oracle.md`
 - **ROA Windows setup scripts (XE/SE 21c)**: `proxmox/lxc108-oracle/roa-windows-setup/README.md`
 - **Conectarea clienților vechi (Instant Client 10/11) la 21c — ORA-28040 / ORA-01017 / ORA-12514**: `docs/lectii-conectare-client-oracle.md`
+- **Actualizarea ROA eșuează tăcut fără aliasul TNS pe server (jobul zice SUCCEEDED, dar nu aplică nimic)**: `docs/lectii-actualizare-roa-alias-tns.md`
 - **Kit de instalare pentru client (DMP-uri șablon + scripturi, gata de dus la client)**: `proxmox/lxc108-oracle/scripts/build-client-kit.ps1`
 - **VM 302 test environment for ROA setup**: `proxmox/vm302-oracle-test/README.md`
 - **Diagnostic spațiu Oracle la clienți (job zilnic + emailuri)**: `docs/diagnostic-spatiu-clienti.md`