fix(export): aliasul TNS lipsa facea exportul zilnic sa esueze tacut

La VADECO, backupora.exe rula in fiecare noapte, se termina cu cod 0 si scria
"DONE" pentru fiecare schema - dar directorul zilei ramanea gol. Intre 25 si
28.08.2026 nu a existat niciun export.

Cauza: schema.txt cere "@XEPDB1", iar 01-setup-database.ps1 scria in tnsnames.ora
doar aliasul ROA. expdp cadea instant cu ORA-12154, iar backupora.exe nu-i
verifica codul de iesire. Doua scripturi din acelasi kit nu erau de acord asupra
numelui bazei, si nimic nu tipa.

Indiciul din log, daca reapare: fiecare schema dura exact 16 secunde, indiferent
de marime. Timp uniform = expdp moare la conectare, nu exporta.

Reparatii, ca sa nu se repete la alt client:

- 01-setup-database.ps1 scrie acum doua aliasuri, ROA si numele serviciului,
  in ambele tnsnames.ora. Curatarea dinaintea rescrierii parcurge fiecare alias
  gestionat de noi, altfel al doilea s-ar dubla la fiecare rulare. Aliasurile
  generate de Oracle (XE, LISTENER_XE, ORACLR_CONNECTION_DATA) raman neatinse.

- 11-setup-backup-export.ps1 face tnsping inainte de a scrie schema.txt si
  opreste instalarea daca aliasul nu se rezolva. Mai bine o instalare care se
  plange decat un backup care nu exista.

- lectii-actualizare-roa-alias-tns.md capata sectiunea despre a doua victima a
  aceleiasi cauze. Lectia generala: unde un script lanseaza un proces extern
  Oracle, verifica efectul, nu raportul procesului care l-a lansat.

Include si blocul NTS din config/sqlnet.ora, ramas necomis: autentificarea OS
cere si apartenenta la ORA_OraDB21Home1_DBA, si setarea din sqlnet.ora.

Nota: CLAUDE.md apare ca modificat integral - blob-ul din git avea CRLF, iar
core.autocrlf=true il normalizeaza la LF. Modificarea reala e o singura linie.

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

proxmox/lxc108-oracle/roa-windows-setup/scripts/11-setup-backup-export.ps1

@@ -197,6 +197,31 @@ function New-SchemaFile {
 
     Write-LogSection "schema.txt"
 
+    # Verificarea care lipsea si care a costat, la VADECO, patru zile de export
+    # gol (28.08.2026): sirul de conectare scris in schema.txt trebuie sa se
+    # REZOLVE. Daca aliasul nu exista in tnsnames.ora, expdp cade instant cu
+    # ORA-12154, nu scrie niciun DMP - dar backupora.exe logheaza TOTUSI "DONE"
+    # pentru fiecare schema si creeaza directorul zilei, gol. Esecul e complet
+    # tacut: nicio alarma, doar backup-uri care nu exista.
+    # De aceea aici oprim zgomotos, inainte ca fisierul sa apuce sa fie folosit.
+    $tnsping = Join-Path $OraHome "bin\tnsping.exe"
+    if (Test-Path $tnsping) {
+        $iesireTns = & $tnsping $Service 2>&1 | Out-String
+        if ($LASTEXITCODE -ne 0 -or $iesireTns -match 'TNS-\d') {
+            Write-LogError "Aliasul TNS '$Service' NU se rezolva."
+            Write-LogError "schema.txt cere '@$Service', deci expdp ar cadea cu ORA-12154 la fiecare"
+            Write-LogError "rulare, iar backupora.exe ar raporta oricum 'DONE'. Exportul zilnic ar fi gol."
+            Write-LogError "Repara: ruleaza 01-setup-database.ps1 (scrie aliasul in tnsnames.ora)"
+            Write-LogError "sau da un -ServiceName care se rezolva."
+            throw "Aliasul TNS '$Service' nu se rezolva - schema.txt ar produce un export gol."
+        }
+        Write-LogSuccess "Aliasul TNS '$Service' se rezolva - expdp se va putea conecta."
+    }
+    else {
+        Write-LogWarning "Nu gasesc tnsping.exe in $OraHome\bin; sar peste verificarea aliasului '$Service'."
+        Write-LogWarning "Verifica manual ca '@$Service' se rezolva, altfel exportul zilnic va fi gol."
+    }
+
     if ($SourcePath) {
         if (Test-Path $SourcePath) {
             Copy-Item -Path $SourcePath -Destination $SchemaFile -Force