romfast/ROMFASTSQL
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(oracle): kit de instalare la client + corectarea lipsurilor din instalare

Browse Source 
Blocul de instalare/migrare Oracle 21c XE, terminat si validat pe VM 302.

Kit de instalare (nou)

  scripts/build-client-kit.ps1 exporta CONTAFIN_ORACLE si FIRMANOUA de pe
  LXC 108 (PDB ROA2, nu ROA - ROA e productia ROA_CENTRAL), le aduce local
  prin cele trei hopuri container -> LXC -> host -> statie, le redenumeste la
  numele pe care le asteapta scripturile si le impacheteaza cu o copie a
  directorului roa-windows-setup. Citeste logul expdp si raporteaza cate
  firme are NOM_FIRME, ca sa nu plece din greseala datele unui client.

  roa-windows-setup/INSTALEAZA.cmd ruleaza pasii 01..08 fara "set /p", deci
  merge si prin SSH - RunAll.cmd nu poate fi rulat neinteractiv. Trateaza
  corect codul 5 de la pasul 03 si se opreste la prima eroare reala.

Corectii

  01-setup-database.ps1 nu mai scrie SQLNET.RECV_TIMEOUT / SEND_TIMEOUT in
  sqlnet.ora. Le hardcoda la 30 s, iar fisierul e citit si de impdp: in timpul
  unui import serverul poate lucra minute fara sa trimita un pachet, clientul
  murea cu ORA-12609 iar scriptul raporta esec pentru un import care se
  terminase cu bine pe server. Reprodus si reparat pe VM 302.

  01-setup-database.ps1: Step 4c optional (-ResetSystemPassword) care curata
  EXPIRED(GRACE) pe SYSTEM in CDB root; ALTER PROFILE opreste expirarile
  viitoare dar nu reseteaza un cont deja intrat in gratie.

  uninstall-roa.sql: retry la DROP USER dupa KILL SESSION, plus un bloc final
  de verdict care numara ce a ramas si iese cu ORA-20900 daca baza nu e
  curata. Pana acum toate sectiunile prindeau exceptiile in WHEN OTHERS si
  scriptul tiparea "UNINSTALL COMPLETE" chiar si cand un user supravietuise,
  iar instalarea urmatoare dadea ORA-31684 in lant. 99-uninstall-roa.ps1
  propaga codul de iesire.

  08-post-install-config.ps1: Step 7b seteaza SMTP_OUT_SERVER si ACL-ul de
  retea pentru CONTAFIN_ORACLE. UTL_MAIL se instala si primea EXECUTE, adica
  destul cat sa compileze, dar nu si cat sa trimita. Privilegiul resolve nu
  accepta interval de porturi (ORA-24244), deci se acorda separat de connect.

  07-verify-installation.ps1: sectiune noua care verifica prezenta lui
  FIRMANOUA.dmp in DMPDIR si o raporteaza ca eroare daca lipseste. Fara el,
  adaugarea unei firme noi pica in DBMS_DATAPUMP.ADD_FILE peste luni de la
  instalare, cand nimeni nu mai leaga eroarea de instalare.

  configure-profile.sql: antetul spune ca e unealta de remediere manuala, nu
  parte din flux; pas nou la final pentru CDB root.

Documentatie

  README-ul roa-windows-setup descrie acum explicit cele doua scenarii -
  instalare pe curat si migrare - de unde se iau DMP-urile sablon, si capcana
  ORA-12609. Handoff-urile de sesiune au fost sterse; ce era durabil in ele a
  intrat in README-uri si in docs/diagnostic-spatiu-clienti.md.

Validare pe VM 302: ciclu complet din kit, instalare pe curat, verificarea
finala "[OK] All checks passed!".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
This commit is contained in:
Marius
2026-08-25 18:05:56 +03:00
parent 3a7e751fc1
commit 7fce925349
17 changed files with 3329 additions and 1753 deletions
Download Patch File Download Diff File Expand all files Collapse all files

199
docs/acces-client-tailscale-ssh.md Normal file
View File

@@ -0,0 +1,199 @@
# Acces administrativ la un server de client prin Tailscale + SSH
De ce: pentru instalări/migrări Oracle la client avem nevoie de **shell text** pe serverul lui.
RustDesk nu ajută — e sesiune grafică, nu se poate automatiza. Iar la mulți clienți **nu se pot
face forward-uri de porturi pe router**. Tailscale rezolvă exact asta: nodul face doar conexiuni
de ieșire (UDP 41641 pentru NAT traversal, cu cădere pe releu DERP peste 443), deci merge și în
spatele CGNAT, fără nicio regulă pe router.
RustDesk rămâne util pentru **bootstrap-ul de o singură dată** — pașii de mai jos se execută
manual, o dată, prin el.
Primul caz aplicat: **VADECO** — `vadeco-server`, Windows Server 2019 Standard, Tailscale
`100.93.100.75` (2026-08-25).
Context conex: `acces-ssh-chei-angajati.md` (Bitvise pe chei, capcana LSA protection).
---
## 1. Tailscale pe serverul clientului
1. Instalezi Tailscale, te loghezi cu contul ROMFAST.
2. **Run unattended** — din tray → Preferences, sau `tailscale up --unattended`. Fără el,
tailscaled pornește abia după ce cineva face login în Windows; pe un server la care nu se
loghează nimeni, accesul e mort după fiecare reboot.
3. Cere acordul clientului înainte — e VPN pe serverul lui.
## 2. Izolarea nodului: tag + ACL
Fără asta, serverul clientului intră în tailnet ca device obișnuit și **vede toată
infrastructura ROMFAST**. Dacă e vreodată compromis, atacatorul sare mai departe.
Modelul Tailscale, pe scurt:
- ACL-ul e **default-deny**: ce nu e permis explicit, e blocat. Nu scrii interdicții.
- Regulile au **direcție**: `src` = cine deschide conexiunea, `dst` = cine o primește.
- Fiecare device are o **identitate**: fie contul care l-a logat (*user-owned*), fie **tag-ul**.
Aplicarea unui tag **înlocuiește** proprietatea contului, nu se adaugă la ea.
- `autogroup:member` = conturile umane din tailnet. Un device tagged **nu** e member.
### Politica
Admin console → Access controls. UI-ul nou are editor vizual (Definitions / Grants); fișierul
HuJSON brut e la `https://login.tailscale.com/admin/acls/file`.
```hujson
{
"tagOwners": {
"tag:client": ["autogroup:admin"],
},
"acls": [
// device-urile noastre (ne-tagged) ajung oriunde
{ "action": "accept", "src": ["autogroup:member"], "dst": ["*:*"] },
// NU exista nicio regula cu "src": ["tag:client"]
// => serverul clientului nu poate initia nimic in tailnet
],
}
```
> **Obligatoriu:** șterge regula implicită `src: ["*"]` → `dst: ["*:*"]`. Cât timp există,
> `*` include și `tag:client` și toată izolarea e degeaba.
> **Înainte de a șterge**, verifică în Machines că niciun nod ROMFAST nu e deja tagged — ar
> rămâne fără acces.
### Aplicarea tag-ului
Machines → nodul → `...` → **Edit ACL tags** → `tag:client`.
Efecte: proprietatea trece la tag (dispare din „owned by you" — normal), iar **expirarea cheii
se dezactivează automat** la device-urile tagged, deci nu mai trebuie dezactivată manual.
Verificare rapidă în `tailscale status` — nodul apare cu owner `tagged-devices`:
```
100.93.100.75 vadeco-server tagged-devices windows -
```
### Testul de izolare
Rulează **aceeași** comandă înainte și după aplicarea tag-ului, de pe serverul clientului:
```powershell
Test-NetConnection 100.95.55.51 -Port 22 # 100.95.55.51 = LXC 171, are sshd pornit
```
- înainte de tag: `TcpTestSucceeded : True` (nodul e încă member) — confirmă că testul e valid
- după tag: `TcpTestSucceeded : False` (~20s până expiră) — confirmă izolarea
> **Nu folosi `tailscale ping` ca test de ACL.** Lucrează sub filtrul de pachete și poate
> reuși chiar când ACL-ul blochează traficul real. Doar un test TCP pe un port concret spune
> adevărul.
Sensul invers (noi → client) se testează la punctul 4, cu serverul SSH pornit.
> „Dacă nodul nu poate ajunge la noi, cum îmi răspunde SSH-ul?" — ACL-ul reglementează **cine
> deschide** o conexiune, nu direcția octeților. Sesiunea deschisă dinspre noi funcționează
> normal în ambele sensuri; clientul doar nu poate iniția el ceva spre tailnet.
## 3. Serverul SSH pe mașina clientului
Două variante; ambele merg, alege după context.
### Bitvise SSH Server (consecvent cu restul clienților)
Control Panel → **Easy settings**:
- **Windows accounts** → `Administrator` (sau alt cont din grupul Administrators) →
**Public keys** → Import cheia publică. Shell access: terminal + exec.
- Conturile **virtuale** rămân pentru tuneluri (la VADECO: `romfast`, `vadeco`, s2c pe 1521/80).
> **Capcana conturilor virtuale:** implicit sunt mapate pe contul Windows `bvssh_virtualusers`,
> cu privilegii minime. Prin ele obții shell, dar `Get-Service`, `Get-CimInstance` și
> `Get-PSDrive` întorc **gol** — nu erori, ci nimic — și nu se poate instala Oracle. Simptom:
> `whoami` întoarce `<host>\bvssh_virtualusers` și verificarea de admin dă `False`.
>
> Fie folosești un cont Windows real (mai simplu), fie mapezi contul virtual pe un cont admin
> din Advanced settings → Access control → grup → **Windows account** + parolă, plus setarea
> **Elevation** (fără ea, token filtrat de UAC și instalarea Oracle pică pe permisiuni obscure).
> Dezavantaj: parola de admin ajunge stocată în configul Bitvise.
> **Capcana LSA protection:** pe Windows recent (~2025+) cu Bitvise < 9.51, autentificarea cu
> cheie pe **conturi Windows** eșuează (parola merge, cheia nu) — vezi
> `acces-ssh-chei-angajati.md`. Pe Server 2019 nu se aplică. Conturile virtuale nu sunt afectate
> niciodată.
### OpenSSH nativ Windows (alternativă, fără licențiere)
```powershell
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Set-Service -Name sshd -StartupType Automatic
Start-Service sshd
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell `
-Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" `
-PropertyType String -Force
$f = "$env:ProgramData\ssh\administrators_authorized_keys"
Set-Content -Path $f -Encoding ascii -Value 'ssh-ed25519 AAAA... comentariu'
icacls $f /inheritance:r /grant "*S-1-5-32-544:F" /grant "*S-1-5-18:F"
Restart-Service sshd
```
- `administrators_authorized_keys` e fișierul corect pentru conturi **admin** (nu `~/.ssh`).
- ACL-ul de la `icacls` e obligatoriu: cu moștenire de permisiuni, sshd ignoră fișierul **în
tăcere** și vezi doar „Permission denied". SID-urile evită problema pe Windows localizat.
- `-Encoding ascii` intenționat — `utf8` în PowerShell 5.1 scrie BOM, iar sshd nu digeră cheia.
### Firewall
```powershell
Set-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -RemoteAddress 100.64.0.0/10
# Bitvise:
Get-NetFirewallRule -DisplayName '*Bitvise*' | Set-NetFirewallRule -RemoteAddress 100.64.0.0/10
```
Restricția se face **pe firewall**, nu prin bind pe adresa 100.x în configul serverului SSH: la
boot, interfața Tailscale urcă adesea *după* serviciu, bind-ul eșuează și serverul rămâne mort.
## 4. Testul de acceptanță
De pe orice device ROMFAST din tailnet:
```bash
ssh Administrator@100.93.100.75 "powershell -c (Get-Item 'C:\').FullName"
```
Pentru comenzi mai complexe, ghilimelele se pierd prin lanțul ssh → Bitvise → PowerShell.
Folosește `-EncodedCommand`:
```bash
ENC=$(iconv -f UTF-8 -t UTF-16LE script.ps1 | base64 -w0)
ssh Administrator@100.93.100.75 "powershell -NoProfile -EncodedCommand $ENC"
```
Output-ul PowerShell prin exec vine cu antet `#< CLIXML` și un bloc `<Objs Version=...>` —
se filtrează cu `grep -v`.
## 5. Verificare de mediu înainte de instalarea Oracle
```powershell
"ADMIN = $(([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))"
"OS = $((Get-CimInstance Win32_OperatingSystem).Caption)"
"RAM_GB = $([math]::Round((Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory/1GB,1))"
Get-Service | Where-Object {$_.Name -like 'Oracle*'} | Select-Object Name,Status,StartType
Get-PSDrive -PSProvider FileSystem | Select-Object Name,@{n='FreeGB';e={[math]::Round($_.Free/1GB,1)}}
```
`ADMIN = True` e condiția minimă — dacă e `False`, restul câmpurilor vin goale din lipsă de
drepturi, nu pentru că lipsesc, și orice concluzie despre mașină e falsă.
## Revocarea accesului
1. Machines → nodul → **Remove** (îl scoate din tailnet complet); și/sau
2. ștergerea cheii publice din contul de pe serverul SSH.
Pasul 1 e suficient și instantaneu — fără el, ștergerea cheii lasă nodul în rețea.

13
docs/diagnostic-spatiu-clienti.md
View File

@@ -330,6 +330,19 @@ in `Y:\ROAUPDATE\_UPDATE\`, care e live pentru toti.
Pointeri incrucisati: [`00-INSTALL-ORACLE-XE.md`](../proxmox/lxc108-oracle/roa-windows-setup/docs/00-INSTALL-ORACLE-XE.md)
si [`00-INSTALL-ORACLE-SE.md`](../proxmox/lxc108-oracle/roa-windows-setup/docs/00-INSTALL-ORACLE-SE.md).
## 8b. Ramase de verificat (din blocul 08.08.2026)
- **`SYSTEM` verificat doar la `sigma` si `automotive`.** Ceilalti clienti nu au fost atinsi;
expeditorii cunoscuti sunt `roaupdate_acn@`, `roaupdate-clever@` (lista completa in sectiunea 3).
- **`ACN` — tacere de pe 06.08** dupa curatenie. Neconfirmat ca jobul mai ruleaza. Se verifica cu:
```sql
SELECT MAX(dataora) FROM contafin_oracle.diag_spatiu_log;
```
- **`UPDATEROA_ZILNIC.failure_count`** = 233 la AUTOMOTIVE, 47 la SIGMA, desi toate rularile din
ultimele 7 zile sunt `SUCCEEDED`. Pare contor istoric — neinvestigat, de urmarit, nu de reparat.
- **`SYS.AUTH_DETALII` si `SYS.AUTH_SERII` raman in `SYSTEM`** (`sys-objects.sql`, pasii `[1/11]`
si `[2/11]`). Nu cresc, nu s-au atins.
## 9. Legaturi in acest repo
| Document | Ce e |

117
docs/handoff_diagnostic-spatiu-oracle.md
View File

@@ -1,117 +0,0 @@
# Handoff — diagnostic spatiu Oracle la clienti (08.08.2026)
Stare la predare. **Fara analize noi** — doar ce s-a facut, ce nu, si capcanele platite.
## 1. Livrabile
### Comise si impinse — `015cd79` pe `master` (ROMFASTSQL)
| Fisier | Ce contine |
|---|---|
| `docs/diagnostic-spatiu-clienti.md` | **documentul principal** (nou, 9 sectiuni): pointeri COMUN, praguri, emailuri, tunel SSH, triaj, starea per client, plafoane la instalare, ce s-a schimbat in installer |
| `CLAUDE.md:51` | linie de index catre documentul de mai sus |
| `proxmox/lxc108-oracle/clienti/README.md` | idem, in tabelul „Proceduri generale" |
| `.../roa-windows-setup/sql/sys-objects.sql` (sectiunea `[3/11]`) | `SYS.INFO` se creeaza in tablespace `ROA` (tabela + LOB), fallback pe `SYSTEM` cu avertisment |
| `.../roa-windows-setup/sql/scheduler-jobs.sql` (SECTION 4, prompturi renumerotate `/5`) | job `SYS.SYSINFO_PURJARE_ZILNIC`, 03:30, retentie 90 zile, transe de 10.000 randuri, **ENABLED** |
| `.../roa-windows-setup/sql/uninstall-roa.sql` | dezinstalarea sterge si jobul |
| `.../roa-windows-setup/docs/00-INSTALL-ORACLE-XE.md` si `-SE.md` | pas post-instalare: plafon `SYSTEM` 2000M + mutarea `SYS.INFO` la instalari vechi |
### In SVN (r18010), **NEPUBLICAT catre clienti** — in afara acestui repo
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\sys_2026_08_08_02_SYS_INFO_TABLESPACE_PURJARE.sql`
Doi pasi: **recrearea** tabelei in `ROA` (`drop table sys.info purge` + `create ... tablespace ROA
lob (info) store as (tablespace ROA)` + `alter procedure sys.pinfo compile`) → creare job.
Nivel Oracle 10.2, idempotent, CRLF verificat (103 linii, 0 LF singure, 0 octeti non-ASCII).
**r18009 muta tabela** (`alter table ... move`); **r18010 o recreeaza** — decizia lui Marius:
continutul e log fara valoare, iar `DROP`+`CREATE` nu cere spatiu liber cat segmentul si nu tine
tabela blocata. `PURGE` e obligatoriu (altfel segmentul ramane in recyclebin). Fallback pe `SYSTEM`
daca `CREATE`-ul in `ROA` esueaza, ca tabela sa existe intotdeauna.
Pasul 1 are `EXCEPTION WHEN OTHERS THEN NULL` **intentionat** (o eroare acolo nu are voie sa
opreasca lantul de actualizare; ce n-a mers apare a doua zi in alerta `DIAGSPATIU_ZILNIC`).
**Publicarea catre clienti NU s-a facut si e decizia lui Marius** —
`COMUN\utile\publicare_scripturi.ps1` scrie in `Y:\ROAUPDATE\_UPDATE\`, care e live pentru toti.
## 2. Modificari aplicate in productie
**AUTOMOTIVE (`78.96.115.213`, xe 11.2.0.2 pe host `SERVER`), 08.08.2026 — write-back facut, verificat:**
```sql
alter database datafile 'E:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBF'
autoextend on next 50M maxsize 2000M; -- ca contafin_oracle
truncate table sys.info; -- ca SYSDBA
```
Rezultat verificat: `SYSTEM` 540 MB alocati / 2000 plafon, 84.94 MB liberi, **1544.94 MB de crestere
(77.2%)** vs prag 300 MB. `SYS.INFO` 552.581 randuri / 80 MB → 0 randuri / 0.06 MB.
**Nicio alta baza de client nu a fost modificata.** SIGMA a fost doar citita.
## 3. Ce NU s-a facut
- scriptul de livrare e in SVN (r18009) dar **nu e publicat catre clienti**;
- **nu s-a verificat `SYSTEM` la ceilalti clienti** — umblat doar la `sigma` si `automotive`;
ceilalti expeditori cunoscuti: `roaupdate-clever@`, `roaupdate_acn@`;
- `ACN` — tacere din 06.08 dupa curatenie; **neconfirmat** ca jobul chiar mai ruleaza (se verifica
cu `max(dataora)` din `contafin_oracle.diag_spatiu_log`);
- `UPDATEROA_ZILNIC.failure_count` = 233 la AUTOMOTIVE, 47 la SIGMA, desi toate rularile din
ultimele 7 zile sunt `SUCCEEDED` si `UPD_ISTORIC` ajunge la `stare = 4` — neinvestigat, pare
contor istoric;
- `SYS.AUTH_DETALII` si `SYS.AUTH_SERII` raman in `SYSTEM` (`sys-objects.sql` `[1/11]`, `[2/11]`) —
nu cresc, nu s-au atins.
## 4. Stare periculoasa la predare
**Niciuna.** Toate tunelurile sunt inchise (`Get-Process stnlc` gol, portul 1521 liber), nu exista
tranzactii deschise, nu exista fisiere editate fara write-back, nimic necomis din ce am atins.
Fisierele `.sh` care apar modificate in `git status` (`migration/*.sh`, `lxc171-claude-agent/*.sh`,
`clone-vm300.sh`, `export-roa2.sh`, `fix-sqlnet.sh`) si `bash.exe.stackdump` **nu sunt ale acestei
sesiuni** — le-a lasat sesiunea paralela. Nu le atinge fara sa intrebi.
## 5. Capcane de mediu platite
- **Alta sesiune lucreaza in acelasi repo.** In timpul lucrului a comis `9475842` si a curatat
working tree-ul, **stergand toate modificarile mele in fisiere urmarite de git**. Au supravietuit
doar fisierul nou (netracked) si scriptul de pe `D:`. A trebuit refacut totul. **Comite des.**
- **Thunderbird**: profilul din `%APPDATA%\Thunderbird\Profiles` e gol si induce in eroare —
instalarea reala e portabila, `D:\UTIL\portable\PortableApps\ThunderbirdPortable`. Contul
`marius.mutu@romfast.ro` = `ImapMail\mail.romfast.ro\INBOX`. Nu da ripgrep pe folder
(`INBOX.sbd\Sent` are 2.5 GB).
- **Bitvise `stnlc`**: `-profile=` nu merge cu host pozitional; **nu da `-c2s`**, regulile de
forwarding vin de la server. Sintaxa care merge:
`& 'C:\Program Files (x86)\Bitvise SSH Client\stnlc.exe' --% -profile=d:\GoogleDrive\<client>.tlp -noRegistry=y`
Profilele: `D:\GoogleDrive\*.tlp` (`sigma`, `automotive`, `clever-motors`, `rompetrole`, …).
- **Toate aliasurile TNS de client tintesc `127.0.0.1:1521`** — un tunel gresit te duce tacut la alt
client. Verifica portul liber inainte (`Get-NetTCPConnection -State Listen -LocalPort 1521`) si
pune `select instance_name, host_name from v$instance` ca prima interogare.
- **Inchide tunelul** cand termini: `Get-Process stnlc | Stop-Process -Force`.
- Regula din `COMUN\docs\local\oracle.md`: tunelul spre productie doar cand acel server e chiar
subiectul investigatiei, si atunci **strict read-only** (exceptia de azi a fost ceruta explicit).
- SQL-ul se da lui `sqlplus` **dintr-un fisier**, nu prin pipe.
## 6. Comenzi
```powershell
# emailurile de diagnostic (expeditor + subiect + alerte)
powershell -File D:\roa\roagest\comun\utile\citeste_email.ps1 -Cauta 'Diagnostic spatiu' -Ultimele 10
# diagnostic manual pe un client, read-only
powershell -File D:\roa\roagest\comun\utile\diag_spatiu.ps1 -Alias ROA_SIGMA [-Disc]
# conectare prin tunel
& 'D:\ROA\instantclient_19_18\sqlplus.exe' -L -S 'contafin_oracle/ROMFASTSOFT@ROA_SIGMA' '@diag.sql'
```
Fara loguri de rulare — verificarile s-au facut interactiv, iesirea e in conversatie.
## 7. De unde se reia
1. publicarea lui `sys_2026_08_08_02_...` catre clienti (decizie Marius; e deja in SVN la r18009);
2. verificarea preventiva a lui `SYSTEM` la `clever` si `acn`;
3. confirmarea ca `DIAGSPATIU_ZILNIC` mai ruleaza la `acn`.
Contextul complet: [`diagnostic-spatiu-clienti.md`](diagnostic-spatiu-clienti.md).

159
docs/handoff_oracle-instalare-migrare-sys-grants.md
View File

@@ -1,159 +0,0 @@
# Handoff — granturi dicționar PACK_DIAG_SPATIU + `sys-grants.sql` legat în flux
**Data:** 2026-08-25
**Branch:** `feat/oracle-instalare-migrare-sys-grants`
**Commit:** `afb8266`
**Bloc următor:** testare pe VM 302 (oprit acum, trebuie pornit)
---
## 1. De unde a pornit
Client vechi cu **Oracle XE 11 pe Windows**; se instalează Oracle 21c XE pe un server nou și se
mută `CONTAFIN_ORACLE` + schemele de firme. Întrebarea inițială: care dintre directoarele de
migrare se folosește.
**Răspuns stabilit (nu se mai re-analizează):** `proxmox/lxc108-oracle/roa-windows-setup/`.
Motivele complete sunt în `proxmox/lxc108-oracle/docs/instalare-si-migrare-oracle.md`.
`migration/` țintește Oracle în Docker pe LXC 108; `new-roa-oracle-server/` e arhivă istorică.
---
## 2. Livrabile — inventar
### Cod
| Fișier:linie | Ce s-a schimbat |
|---|---|
| `proxmox/lxc108-oracle/roa-windows-setup/sql/sys-grants.sql:107-172` | secțiune nouă `[5/5]` — `GRANT SELECT` direct pe 18 vederi `dba_*`/`v$*` către `CONTAFIN_ORACLE`; bloc PL/SQL idempotent, `ORA-00942` tratat; secțiunile 1-4 renumerotate `[n/4]` → `[n/5]` |
| `proxmox/lxc108-oracle/roa-windows-setup/scripts/04-create-synonyms-grants.ps1:147-166` | STEP 3 nou — execută `sys-grants.sql` ca SYS/SYSDBA, după import |
| `…/04-create-synonyms-grants.ps1:225-258` | verificare `DICT_GRANTS` (avertizează sub 15 din 18) |
| `…/04-create-synonyms-grants.ps1` (header, validare căi, summary) | `$sysGrantsScript`, `Test-Path`, linii de summary |
| `proxmox/lxc108-oracle/roa-windows-setup/scripts/07-verify-installation.ps1:255-305` | secțiune de raport „Dictionary Grants (PACK_DIAG_SPATIU)" — listează nominal care lipsesc |
Ambele `.ps1` trec `[Parser]::ParseFile` fără erori. **Atât s-a verificat.**
### Documentație
- **nou:** `proxmox/lxc108-oracle/docs/instalare-si-migrare-oracle.md`
- actualizate: `roa-windows-setup/README.md`, `migration/README.md`,
`lxc108-oracle/README.md`, `proxmox/README.md`, `CLAUDE.md`,
`roa-windows-setup/sql/sys-updates/README.md`, `vm302-oracle-test/README.md`,
`vm302-oracle-test/docs/dual-edition-test-plan.md`,
`vm302-oracle-test/docs/issues-se-prod.md`
---
## 3. Ce e terminat și ce nu
**Terminat:** editările pe disc, commit făcut, working tree curat.
**NU e terminat: nimic nu a fost rulat pe o bază Oracle reală.** VM 302 era oprit
(`qm list` → `302 oracle-test-302 stopped`) și nu l-am pornit. Nicio afirmație despre
comportamentul la rulare nu e verificată.
---
## 4. Blocul următor — testare pe VM 302
```bash
ssh root@10.0.20.201 "qm start 302" # ~2-3 min boot
ssh root@10.0.20.201 "qm status 302"
```
VM 302: `oracle-test-302`, **10.0.20.130**, hostname `ROACENTRAL`, Windows 11, Oracle 21c XE
(CDB/PDB, service `XEPDB1`), user `romfast`. RDP: `mstsc /v:10.0.20.130`.
Scripturile pe VM stau în `C:\roa-setup\` — **sunt o copie**, nu un clone al repo-ului.
**Primul pas: sincronizează `C:\roa-setup\` cu branch-ul `feat/oracle-instalare-migrare-sys-grants`**,
altfel testezi versiunea veche. Minimum de copiat:
`sql\sys-grants.sql`, `scripts\04-create-synonyms-grants.ps1`, `scripts\07-verify-installation.ps1`.
DMP-uri deja prezente pe VM în `C:\DMPDIR\`: `contafin_oracle_72001.dmp` (276 MB),
`capidavatour_72001.dmp` (76 MB).
Ciclul de test:
```powershell
cd C:\roa-setup
.\scripts\99-uninstall-roa.ps1 -SystemPassword "romfastsoft" -Force
.\RunAll.cmd # ~8 min
.\Run.cmd 07-verify-installation.ps1
```
Logurile scriu în `C:\roa-setup\logs\<script>_<yyyyMMdd_HHmmss>.log`.
### Ce trebuie să arate testul
1. `04-create-synonyms-grants.ps1` — STEP 3 rulează `sys-grants.sql`; în log:
`Dictionary grants for PACK_DIAG_SPATIU: 18 / 18`.
2. `07-verify-installation.ps1` — secțiunea „Dictionary Grants (PACK_DIAG_SPATIU)" cu
`Status: OK`.
3. Verificare independentă, direct în bază:
```sql
SELECT COUNT(*) FROM dba_tab_privs
WHERE grantee = 'CONTAFIN_ORACLE' AND grantor = 'SYS' AND privilege = 'SELECT';
```
4. Sinonimele SYS care înainte **nu se creau** (regresia găsită la punctul 1 din commit):
```sql
SELECT synonym_name FROM dba_synonyms
WHERE owner = 'PUBLIC' AND table_owner = 'SYS'
AND synonym_name IN ('SYN_NEWSCHEMA','SYN_NEWSCHEMAJOB','EXECUTESCRIPTOS','SYN_PINFO');
```
Trebuie 4 rânduri. Dacă apar 4, e confirmarea că STEP 3 chiar rulează.
**Notă:** DMP-ul de test `contafin_oracle_72001.dmp` s-ar putea să nu conțină
`PACK_DIAG_SPATIU` (pachetul e livrat prin `co_2026_08_*` din repo-ul COMUN). Testul verifică
**granturile**, nu compilarea pachetului. Dacă vrei și compilarea, pachetul trebuie adus separat
din `D:\roa\roagest\comun\docs\PACK_DIAG_SPATIU.pck`.
---
## 5. Stare periculoasă / atenționări
- **Nimic în stare inconsistentă.** Fără tranzacții deschise, fără procese rămase vii, fără
fișiere editate fără write-back.
- **VM 302 rămâne oprit** — dacă îl pornești, oprește-l la final:
`ssh root@10.0.20.201 "qm shutdown 302"`.
- **`99-uninstall-roa.ps1 -Force` e distructiv** — șterge `CONTAFIN_ORACLE`, `CAPIDAVATOUR`,
tablespace-ul `ROA`, sinonimele publice și obiectele SYS. Corect pe VM 302 (e mediu de test).
**Niciodată la client.**
- **Branch, nu master.** Merge-ul nu e făcut:
```bash
git checkout master && git merge feat/oracle-instalare-migrare-sys-grants
```
Nu e împins nicăieri.
- **Diff-ul `.ps1` pare rescriere totală.** Cauză preexistentă: blob-urile din HEAD sunt cu
CRLF, iar `.gitattributes` cere `*.ps1 text eol=crlf`, deci orice atingere declanșează
renormalizarea. Modificarea reală: 66 și 51 de linii. Se vede cu `git diff --ignore-cr-at-eol`.
---
## 6. Ce s-a stabilit deja (nu se reia)
- **Directorul corect e `roa-windows-setup/`.** Analiza comparativă e în
`docs/instalare-si-migrare-oracle.md`; nu se re-face.
- **`sys_2026_01_14_01_AUTH_PACK` e deja acoperit** de `sql/sys-objects.sql` — specificația
pachetului e identică, iar lista de programe din repo e un superset (are în plus
`GENERARESCRIPT.EXE`, `ROAACTUALIZARI.EXE`, `EXP.EXE`, `IMP.EXE`).
- **`sys_2026_08_08_02_SYS_INFO_TABLESPACE_PURJARE` e deja acoperit** de
`sys-objects.sql:94-109` (INFO în tablespace `ROA`) + `scheduler-jobs.sql:176`
(`SYS.SYSINFO_PURJARE_ZILNIC`). A intrat prin commit-ul `015cd79`.
- **Singurele `sys_*` care lipseau** erau cele trei `DIAG_SPATIU_GRANT*` — acum consolidate.
- Sursa scripturilor `sys_*`: `D:\roa\database\SCRIPTURI_CLAR\<an>\<lună>\`. Cel mai recent
la data handoff-ului: `sys_2026_08_08_02`.
---
## 7. De verificat înainte de migrarea reală la client
- **Plafonul XE.** 21c XE: 12 GB date de utilizator, 2 GB RAM, 2 thread-uri. Sursa (11.2 XE)
avea plafon 11 GB, deci teoretic intră, dar cu marjă mică. Se măsoară pe sursă:
```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 → Standard Edition, care e **netestată** (`vm302-oracle-test/docs/issues-se-prod.md`).
- **Conectarea la `XEPDB1`**, niciodată la `XE` (CDB root).
- **`sqlnet.ora` + resetarea parolelor**, altfel Instant Client 10/11 al clientului nu se conectează.
- **`expdp` vs `exp`** — formate incompatibile; `exp` se importă doar cu `imp`.