ROMFASTSQL/docs/handoff_vadeco-migrare.md

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:

   $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:

   -- 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ă:

   '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:

   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