# 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.