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
This commit is contained in:
Marius
196
docs/handoff_vadeco-migrare.md
Normal file
196
docs/handoff_vadeco-migrare.md
Normal file
@@ -0,0 +1,196 @@
|
||||
# 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`
|
||||
Reference in New Issue
Block a user