romfast/ROMFASTSQL
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
31c4065bd2ff13b45fbf72012c76da3eb11dc014
ROMFASTSQL/proxmox/lxc108-oracle/docs/instalare-si-migrare-oracle.md
Marius 5a746990ce feat(oracle): instalare ROA in doua faze, licente, IIS si export zilnic 
Adauga FAZA1.cmd/FAZA2.cmd, care despart migrarea in partea care se poate
face in timpul programului (contafin, obiecte SYS, sinonime, licente, IIS)
si partea de seara (schemele de firma). Scripturi noi: 09 pentru licentele
din SYS.AUTH_SERII/AUTH_DETALII, 10 pentru publicarea D:\ROAUPDATE in IIS,
11 pentru exportul zilnic cu backupora.exe, drop-contafin pentru reimport.

backupora.exe si sabloanele sale intra in repo ca sa fie kitul autonom.
Pasul 07 primeste verificarile corespunzatoare pentru licente, IIS si task.

Nerulat inca pe o baza reala - vezi docs/handoff_instalare-doua-faze.md.

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

240 lines
13 KiB
Markdown
Raw Blame History

# 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` |
| 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`](../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) |
| `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:
```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.
Reference in New Issue View Git Blame Copy Permalink