ROMFASTSQL/proxmox/lxc108-oracle/docs/instalare-si-migrare-oracle.md

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/	instalare ROA completă pe Windows + Oracle 21c (XE sau SE)	activ, validat pe VM 302 (XE)
migration/	migrare Oracle 10g → 21c XE cu Oracle în Docker pe LXC 108	activ pentru infrastructura internă
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
09	09-copy-licenses.ps1	SYS.AUTH_SERII + SYS.AUTH_DETALII de pe serverul vechi, prin rețea sau din fișier (sql/export-licente.sql); recreează SEQ_AUTH_SERII peste MAX(ID_SERIE)+1
10	10-setup-roaupdate-iis.ps1	directoarele de modul D:\ROAUPDATE\<MODUL>, instalarea rolului IIS dacă lipsește, aplicația /roaupdate către D:\ROAUPDATE
11	11-setup-backup-export.ps1	D:\ROA\EXPORT_ORADMP cu backupora.exe, setari.ini (din șablon), schema.txt (din NOM_FIRME), DIRECTORY BACKUP_ORACLE, task zilnic Windows
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, licențe, oglinda de update + IIS, exportul zilnic
—	drop-contafin.ps1	DROP USER CONTAFIN_ORACLE CASCADE, doar pentru reimportul din faza 2
99	99-uninstall-roa.ps1	curățare completă, pentru re-testare

Cele trei fluxuri de rulare:

Fișier	Ordinea	Când
FAZA1.cmd	01 → 02 → 03 → 04 → 09 → 08 → 10 → 11 → 07	migrare, în timpul programului
FAZA2.cmd	[drop → 01 → 03 → 04] → 05 → 08 → 11 -SchemaOnly → 07	migrare, după program
INSTALEAZA.cmd	01 → 02 → 03 → 04 → 05 → 08 → 07	într-o singură rulare; fără 09/10/11

RunAll.cmd e varianta interactivă a lui INSTALEAZA.cmd. Run.cmd <script> rulează unul singur, rezolvând ExecutionPolicy.

De ce se poate împărți în două faze: pe CONTAFIN_ORACLE nu se lucrează activ, deci poate fi exportat de pe serverul vechi în timpul programului; doar schemele de firmă se schimbă sub picioare. Faza 2 reia obligatoriu pasul 08 pentru că SERVER_INFO e o tabelă în CONTAFIN_ORACLE: dump-ul clientului aduce cu el căile și parolele serverului vechi.

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: 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). Î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=:

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:

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.

---

6. Mediu de test

Validarea se face pe VM 302 (oracle-test-302, 10.0.20.130) — vezi ../../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
FAZA1.cmd / FAZA2.cmd	NETESTATE pe VM 302 — scrise, dar nerulate încă end-to-end
Pașii 09 / 10 / 11	NETESTAȚI — 11 are nevoie de backupora.exe, care încă nu e în kit

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. Pentru fluxul în două faze: 99-uninstall-roa.ps1 -Force → FAZA1.cmd → FAZA2.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:

  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.