Files
ROMFASTSQL/docs/handoff_vadeco-migrare.md
Marius e6d727bfab docs: handoff migrare VADECO - faza 1 terminata, ce ramane pentru faza 2
Starea instalarii pe serverul nou, ruta de transfer a DMP-urilor prin
DBMS_DATAPUMP + IIS (serverul vechi e 11.2.0.2 si nu are shell), capcana cu
discul C: inaccesibil procesului Oracle, si pasii ramasi: firmele, tnsnames.ora
al ROAClient si sqlnet.ora in TNS_ADMIN.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
2026-08-25 21:21:03 +03:00

197 lines
9.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Handoff — migrare VADECO pe server nou (Oracle 21c XE)
Stare la 2026-08-25, seara. Predare din cauza pragului de context.
Nimic nu e într-o stare periculoasă. Modificările de cod sunt **comise și pushuite**.
## Serverele
| | Vechi | Nou |
|---|---|---|
| Nume | `CONTAFIN` (workgroup VADECO) | `WIN-16COB435C1E` (nume default, neschimbat) |
| IP LAN | `192.168.101.110` | `192.168.101.111` |
| Acces | **fără SSH**; doar 1521 / 445 / 3389 / 80 (IIS 7.5) | SSH pe cheie prin Tailscale: `ssh Administrator@100.93.100.75` |
| OS | Windows Server 2008 R2 (dedus din IIS 7.5) | Windows Server 2019 Standard, 15.7 GB RAM, 4 vCPU |
| Oracle | XE **11.2.0.2.0**, service `XE`, AL32UTF8 | XE **21.3**, CDB `XE` + PDB **`XEPDB1`**, AL32UTF8 |
| Discuri | — | C: 74 GB liber, **D: 725 GB liber** |
Credențiale baza veche: `sys/romfastsoft`, `system/romfastsoft`,
`contafin_oracle/ROMFASTSOFT`. Baza nouă: `sys` și `system` = `romfastsoft`.
**Id client = 134** (citit din `SYS.AUTH_DETALII` de pe serverul vechi).
Firme în `NOM_FIRME` (toate cu parola `ROMFASTSOFT`): `DANUBE`, `DANUBE_20200914`,
`LACERTA`, `SPACE`. **`DANUBE_20200914` se exclude din migrare** — decizie Marius.
Deci pasul 05 și verificarea 07 vor raporta o firmă lipsă; e corect, nu e defect.
Volume: contafin 593 MB segmente (514 MB date reale), firmele migrate ~185 MB.
Total sub 12 GB, deci limita XE nu e o problemă.
## Ruta de transfer a DMP-urilor — de ce e neobișnuită
`expdp` **nu** se poate rula de pe serverul nou: client Data Pump 21c contra
server 11.2.0.2 nu e suportat. Iar pe serverul vechi nu avem shell, iar `C$` e
refuzat cu credențialele curente.
Soluția folosită, validată end-to-end cu un fișier de test înainte de a produce
sute de MB pe discul clientului:
1. `DBMS_DATAPUMP` rulat **în interiorul bazei vechi** prin `sqlplus` (fără
problema de versiune de client), scriind în directorul Oracle existent
`UPD_ROAUPDATE` = `D:\ROAUPDATE`;
2. fișierul descărcat de pe serverul nou prin IIS: `http://192.168.101.110/roaupdate/<nume>.zip`
(extensia `.zip` e obligatorie — IIS întoarce 404 pentru `.dmp`/`.explog`,
neavând tipul MIME);
3. verificare de integritate prin comparare de dimensiuni;
4. ștergere de pe serverul vechi cu `UTL_FILE.FREMOVE`.
Serverul vechi a rămas curat: fișierele de transfer ale contafin-ului au fost
șterse. **Dump-urile firmelor sunt încă acolo** — vezi „Ce a mai rămas".
## Ce e făcut
- **Commit `5a74699`** — kitul din sesiunea anterioară (FAZA1/FAZA2, scripturile
09/10/11, `drop-contafin`, `backupora.exe`, verificările din 07).
- **Commit `ec66377`** — corecțiile găsite chiar în această instalare, detaliate
în mesajul de commit. Pe scurt:
- calea DMP e acum parametrul `-DmpDir`, expus ca `/dmpdest:` în FAZA1/FAZA2 și
transmisă pașilor 01, 02, 03, 05, 06 (înainte era hardcodată în cinci locuri,
iar pasul 02 repoziționa tăcut `DIRECTORY DMPDIR` înapoi pe `C:\DMPDIR`);
- `New-OracleDirectory` testează acum cu `UTL_FILE` că baza chiar **poate scrie**
acolo, nu doar că șirul din `dba_directories` e cel așteptat;
- pasul 01 scrie `sqlnet.ora` **și** în `TNS_ADMIN` când acesta diferă;
- pasul 05 nu mai poate lega o schemă de DMP-ul altei firme.
- **Kitul e pe serverul nou** în `D:\ROA-SETUP\roa-windows-setup\`, cu scripturile
actualizate. `DMPDIR\` al kitului conține `contafin_oracle.dmp` (213 MB, exportat
azi de la client) și `FIRMANOUA.dmp` (23 MB, adus de pe LXC 108).
- **`D:\DMPDIR`** pregătit, cu ACL pentru `NT SERVICE\OracleServiceXE`, conține
ambele DMP-uri.
- **FAZA1 rulată** cu:
```
FAZA1.cmd 134 /dmpdest:D:\DMPDIR /vechi:192.168.101.110 /parolavechi:romfastsoft /serviciuvechi:XE
```
Pașii 1–7 trecuți: tablespace + profil + user, obiecte SYS, import contafin
(**366 obiecte**, cod 5 = normal), sinonime + granturi, licențe de pe serverul
vechi, `08-post-install-config` (Id 134, 54 directoare de modul, joburi create
**dezactivate**), IIS instalat și `/roaupdate` publicat, export zilnic configurat.
Verificarea finală: **366 obiecte, 0 invalide, 12107 sinonime publice**.
`FAZA1.cmd` a ieșit cu **codul 1** și mesajul „FAZA 1 TERMINATA, CU OBSERVATII".
Singura observație e `4 company schemas are missing` (`DANUBE`,
`DANUBE_20200914`, `LACERTA`, `SPACE`) — **normal pentru faza 1**, firmele vin
în faza 2. Nimic altceva nu a eșuat.
> De îmbunătățit în kit: la faza 1, codul de ieșire 1 pentru firme lipsă e
> nedistinsabil de un eșec real. Pasul 07 ar trebui să primească un mod
> „faza 1" în care firmele lipsă nu schimbă codul de ieșire.
- Curățat după diagnostic: obiectele `DIRECTORY` de test (`T_WINTEMP`, `T_CROOT`,
`T_DMPDIR2`, `TESTDIR_D`) șterse, `C:\DMPDIR2` și `D:\DMPDIR-TEST` șterse, ACE-ul
temporar de pe rădăcina `C:\` retras.
## Capcana cu discul C: — nu o mai investiga
Pe serverul ăsta procesul Oracle **nu ajunge la nicio cale de pe `C:`**: nici
`C:\DMPDIR`, nici `C:\DMPDIR2`, nici `C:\Windows\Temp` (scriibil de oricine), nici
`C:\` însuși. Toate dau `ORA-29283: invalid file operation ... [29434]`, la
`UTL_FILE` direct, nu doar prin Data Pump. `D:` funcționează cu exact același
grant de ACL.
Verificat și exclus: ACL pe folder (era corect), ACL/traversare pe rădăcina `C:`
(adăugat explicit, fără efect), `PATH_PREFIX` de PDB (inexistent), `PDB_LOCKDOWN`
(gol), contul serviciului (`NT SERVICE\OracleServiceXE`, confirmat ca proprietar al
`oracle.exe`). Cauza reală n-a fost găsită și **nu merită căutată**: `D:` e oricum
locul corect — acolo sunt Oracle Home, `D:\ROA`, `D:\ROAUPDATE` și 725 GB liberi.
## Ce a mai rămas de făcut
1. **FAZA1 e gata** — nu mai e nimic de reluat acolo. Logurile pe server:
`D:\ROA-SETUP\roa-windows-setup\logs\`.
2. **Adu dump-urile firmelor și rulează FAZA2.** Exporturile sunt **deja făcute**
pe serverul vechi, în `D:\ROAUPDATE\`, ca `danube.zip`, `lacerta.zip`,
`space.zip` (plus `.explog` fiecare). Toate trei au raportat
`STATUS=COMPLETED`. De pe serverul nou:
```powershell
$wc = New-Object System.Net.WebClient
foreach ($s in 'danube','lacerta','space') {
$wc.DownloadFile("http://192.168.101.110/roaupdate/$s.zip",
"D:\ROA-SETUP\roa-windows-setup\DMPDIR\$($s.ToUpper()).dmp")
}
```
Numele fișierului trebuie să fie **exact `<SCHEMA>.dmp`** — pasul 05 leagă
schema de DMP după nume.
Apoi:
```
FAZA2.cmd 134 /dmpdest:D:\DMPDIR
```
`/reimportcontafin` **nu** e necesar: contafin-ul a fost exportat azi și nu s-a
adăugat nicio firmă între timp.
3. **Șterge fișierele de transfer de pe serverul vechi** după descărcare — altfel
rămân ~185 MB în `D:\ROAUPDATE` la client:
```sql
-- sqlplus system/romfastsoft@//192.168.101.110:1521/XE
begin
for f in (select column_value nume from table(sys.odcivarchar2list(
'danube.zip','danube.explog','lacerta.zip','lacerta.explog',
'space.zip','space.explog'))) loop
begin utl_file.fremove('UPD_ROAUPDATE', f.nume); exception when others then null; end;
end loop;
end;
/
```
4. **`tnsnames.ora` al ROAClient e încă cel șablon** — `D:\ROA\instantclient_11_2_0_2\tnsnames.ora`
conține `HOST = SERVER_ROA` / `SID = ROA`, care nu există. Trebuie înlocuit cu:
```
ROA =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.101.111)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = XEPDB1))
)
```
IP-ul serverului, nu `localhost`, ca să meargă același fișier și pe stații.
**Fă backup înainte.** Nu am apucat să-l scriu — FAZA1 rula și n-am vrut să
umblu la configurația de rețea în timpul ei.
5. **Verifică `sqlnet.ora` în `TNS_ADMIN`.** `TNS_ADMIN` de mașină e
`d:\roa\instantclient_11_2_0_2` și **nu conținea niciun `sqlnet.ora`**. Pasul 01
din commit-ul `ec66377` îl scrie și acolo, dar **rularea de azi a folosit
versiunea veche a scriptului** pentru pasul 01 — deci pe server fișierul
probabil lipsește încă. Copiază-l manual din
`D:\app\Administrator\product\21c\homes\OraDB21Home1\network\admin\sqlnet.ora`,
altfel clienții vechi iau `ORA-28040`. Testul care contează:
```powershell
'exit' | Set-Content -Encoding ascii C:\Windows\Temp\e.sql
& 'D:\ROA\instantclient_11_2_0_2\sqlplus.exe' -S -L "system/romfastsoft@//192.168.101.111:1521/XEPDB1" '@C:\Windows\Temp\e.sql'
```
Ieșire goală = merge. La ultima încercare a dat `ORA-12514`, dar listenerul
tocmai era repornit de FAZA1 — de retestat.
6. **Joburile de update sunt create dezactivate.** Se activează manual când e cazul:
```sql
EXEC DBMS_SCHEDULER.ENABLE('CONTAFIN_ORACLE.UPDATEROA_ZILNIC');
EXEC DBMS_SCHEDULER.ENABLE('CONTAFIN_ORACLE.UPDATERTVAI_ZILNIC');
```
7. **Netestat încă:** pasul 11 (export zilnic cu `backupora.exe`). Marius a instalat
ROAClient în `D:\ROA`, deci runtime-ul VFP9 ar trebui să existe — asta rezolvă
incertitudinea din handoff-ul precedent. Rămâne de confirmat convenția
`backuppath` (`ExportPath` vs `C:\BACKUP_ORACLE`) și că `backupora.exe` acceptă
un service name EZConnect (`XEPDB1`), nu doar un SID.
## Ce e interzis
- Nu rula scripturile pe `10.0.20.121` (LXC 108) — e sursa șabloanelor, nu o țintă.
- Nu comite `config.ps1` și nici fișiere `.dmp`.
- Nu porni joburile de actualizare pe serverul nou cât timp utilizatorii lucrează
pe cel vechi.
- Nu reveni la `C:\DMPDIR` pe serverul ăsta.
## Legături
- Kit și flux complet: `proxmox/lxc108-oracle/roa-windows-setup/README.md`
- Handoff-ul precedent (starea kitului înainte de prima rulare reală):
`docs/handoff_instalare-doua-faze.md`
- Accesul prin Tailscale la clienți: `docs/acces-client-tailscale-ssh.md`