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
This commit is contained in:
Marius
2026-08-28 17:12:41 +03:00
parent 5f770c0b60
commit 91e822eb53
5 changed files with 295 additions and 152 deletions

View File

@@ -150,6 +150,80 @@ select count(*) from CONTAFIN_ORACLE.UPD_ISTORIC where stare = 2; -- trebuie 0
- Un `stare=2` rămas deschis blochează rularea următoare — de aceea `IncheiereActualizare` e primul
pas după orice eșec.
## A doua victimă a aceleiași cauze: exportul zilnic `backupora.exe`
**Constatat tot la VADECO, 2026-08-28**, la câteva ore după cazul de mai sus. Aceeași cauză —
un alias TNS care nu se rezolvă — dar alt consumator, alt simptom și, din nou, **eșec complet tăcut**.
### Simptomul
Task-ul `ROA Export Oracle` rulează, se termină cu **cod 0**, își creează directorul zilei
(`D:\BACKUP_ORACLE_FILES\AAAALLZZ\`) și scrie în log câte un **`DONE`** pentru fiecare schemă.
Directorul rămâne **gol**. Singura urmă e o linie discretă între `RUN` și `DONE`:
```
RUN d:\...\bin\expdp.exe CONTAFIN_ORACLE/******@XEPDB1 directory=dmpdir dumpfile=CONTAFIN_ORACLE_54325.dmp
Copiere DATAPUMPFILE d:\dmpdir\CONTAFIN_ORACLE_54325.dmp in d:\backup_oracle_files\20260828\...
Eroare la copiere DATAPUMPFILE: File 'd:\dmpdir\contafin_oracle_54325.dmp' does not exist.
DONE d:\backup_oracle_files\20260828\CONTAFIN_ORACLE_54325.dmp
```
`backupora.exe` **nu verifică codul de ieșire al lui `expdp`** și scrie `DONE` chiar și după ce
eroarea de copiere a fost logată. Deci exportul „reușește" în fiecare zi, la ora lui, fără să
producă nimic.
### Cauza
`schema.txt` conține linii `SCHEMA;PAROLA@XEPDB1`. Aliasul **`XEPDB1` nu exista** în `tnsnames.ora`:
`01-setup-database.ps1` scria doar aliasul `ROA` (plus `LISTENER_XE`), iar
`11-setup-backup-export.ps1` are `-ServiceName` implicit **`XEPDB1`**. Cele două scripturi din
același kit nu erau de acord asupra numelui.
Rulat manual, `expdp` spune limpede ce nu merge:
```
UDE-12154: operation generated ORACLE error 12154
ORA-12154: TNS:could not resolve the connect identifier specified
```
**Indiciul din log care trădează cazul:** fiecare schemă durează **exact același timp**, ~16 secunde,
indiferent de mărime. O bază de 775 MB și una de 45 MB nu se exportă în același timp. Timp uniform
= `expdp` nu exportă, ci moare la conectare.
### Reparația
Aliasul cu numele serviciului trebuie să existe, pe lângă `ROA`, în **ambele** `tnsnames.ora`
(cel din `TNS_ADMIN` și cel din Oracle Home — vezi mai sus de ce contează amândouă). În kit:
- `01-setup-database.ps1` scrie acum **două** aliasuri: `ROA` și unul numit ca `$ServiceName`,
ambele către același `SERVICE_NAME`. Nu atinge aliasurile generate de Oracle
(`XE`, `LISTENER_XE`, `ORACLR_CONNECTION_DATA`).
- `11-setup-backup-export.ps1` face `tnsping $ServiceName` **înainte** de a scrie `schema.txt` și
**oprește instalarea** dacă aliasul nu se rezolvă. Mai bine o instalare care se plânge decât un
backup care nu există.
### Verificarea, la orice client
Nu te uita la codul de ieșire al task-ului și nici la `DONE` din log. Uită-te la **fișiere**:
```powershell
# Directorul zilei trebuie sa contina cate un .dmp de dimensiune plauzibila
Get-ChildItem "D:\BACKUP_ORACLE_FILES\$(Get-Date -Format 'yyyyMMdd')" |
Select-Object Name, @{n='MB';e={[math]::Round($_.Length/1MB,1)}}
# Si logul zilei sa nu contina esecuri de copiere
Select-String -Path "D:\ROA\EXPORT_ORADMP\LOG\$(Get-Date -Format 'yyyyMMdd').log" -Pattern 'Eroare'
```
Un `.dmp` de 0 octeți sau lipsa lui înseamnă export inexistent, oricât de verde ar fi task-ul.
### Lecția generală
De două ori în aceeași zi, pe același server, aceeași formă: **un alias TNS lipsă nu dă eroare
vizibilă, pentru că procesul care cade e lansat de altcineva, iar cel care raportează nu-i verifică
rezultatul.** Peste tot unde un script lansează un proces extern Oracle, verifică **efectul**
(fișier scris, rând apărut), nu **raportul** procesului care l-a lansat.
## Legături
- Lecții de conectare a clienților vechi (`ORA-28040` / `ORA-01017` / `ORA-12514`):