romfast/ROMFASTSQL
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
205 Commits 1 Branch 0 Tags
31c4065bd2ff13b45fbf72012c76da3eb11dc014
Commit Graph

6 Commits

Author SHA1 Message Date
Marius
3ba36b6119 fix(oracle): sys-grants.sql muta DMPDIR inapoi pe C:, iar 05 numara esecul drept succes 
Gasite la prima rulare reala a FAZA2 la VADECO. Toate trei importurile de firma
au picat, si scriptul a raportat "Successful: 3, Failed: 0".

1. sql/sys-grants.sql facea CREATE OR REPLACE DIRECTORY DMPDIR AS 'C:\DMPDIR'
   neconditionat. Ruleaza in pasul 04, deci DUPA importul contafin-ului din 03:
   importul acela reusea cu calea corecta, iar obiectul era mutat imediat dupa.
   Pe VADECO, unde procesul Oracle nu ajunge la nicio cale de pe C:, esecul a
   aparut abia in faza 2, ca ORA-39002 / ORA-39070 / ORA-29283 - ore mai tarziu
   si fara nicio legatura vizibila cu pasul care il provocase.

   E aceeasi clasa de defect ca cel reparat in ec66377 pentru pasul 02, dar
   ascuns intr-un fisier .sql, deci corectia de atunci l-a ratat. Acum calea
   existenta se pastreaza si se raporteaza, ca in grants-public.sql; se creeaza
   doar daca DMPDIR lipseste cu totul, caz in care se si avertizeaza ca pasul 01
   nu a rulat.

2. 05-import-companies.ps1 incrementa $successCount si pe ramura de cod de
   iesire nenul, iar numarul de obiecte de dupa import nu era verificat deloc.
   Rezultatul: trei scheme goale raportate ca importate cu succes, faza 2
   terminata "cu observatii", si defectul descoperit doar pentru ca schemele
   goale sar in ochi la verificare.

   Acum: 0 obiecte inseamna esec, oricare ar fi codul de iesire - un import care
   lasa schema goala nu e un succes. Codul 5 ramane acceptat (ORA-31684 pe user,
   ORA-39082 pe obiecte compilate, normale la ROA), orice alt cod nenul e esec.
   Sumarul si codul de iesire spun adevarul, deci FAZA2.cmd se opreste pe
   :esec_05 in loc sa continue peste un import inexistent.

3. 07-verify-installation.ps1 verifica acum ca baza chiar poate SCRIE in DMPDIR,
   printr-o runda UTL_FILE (deschide, scrie, sterge). Calea din dba_directories
   e doar un sir de caractere si nu spune nimic despre acces - exact motivul
   pentru care New-OracleDirectory primise deja acelasi tratament in ec66377.
   Verificarea asta ar fi prins defectul de mai sus inainte de faza 2.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
 2026-08-25 22:32:17 +03:00
Marius
a5ea8c7ffa fix(oracle): instanta citeste TNS_ADMIN-ul de masina, nu Oracle Home 
Continuarea corectiei 3 din ec66377. Aceea rezolva doar jumatatea vizibila a
problemei; jumatatea ascunsa ar fi lovit la primul reboot al serverului, dupa
plecarea de la client. Gasit la VADECO, verificat pe loc.

1. ORA-12514 la toti clientii, cu baza perfect sanatoasa.

   TNS_ADMIN de masina nu decide doar de unde se citeste sqlnet.ora: instanta
   rezolva de acolo si aliasurile din tnsnames.ora. La Oracle XE LOCAL_LISTENER
   e implicit aliasul LISTENER_XE, definit doar in tnsnames.ora din Oracle Home.
   Cand serviciul reporneste dupa ce ROAClient a pus TNS_ADMIN pe folderul
   instantclient-ului, aliasul nu se mai rezolva, instanta nu se mai
   inregistreaza la listener, si atunci: v$instance OPEN, v$pdbs READ WRITE,
   listener pornit pe 0.0.0.0:1521, lsnrctl arata doar CLRExtProc, si absolut
   orice client primeste ORA-12514.

   Capcana e de timp, nu de continut: o instanta pornita inainte ca TNS_ADMIN
   sa existe nu il vede, deci instalarea pare impecabila si cade la primul
   reboot. Reprodus la VADECO cu un simplu Restart-Service OracleServiceXE.

   Pasul 01 scrie acum si tnsnames.ora in TNS_ADMIN (aliasul ROA pentru
   ROAClient - sablonul livrat cu el arata spre HOST=SERVER_ROA, inexistent -
   plus LISTENER_XE pentru instanta) si, mai important, fixeaza LOCAL_LISTENER
   pe adresa literala. Doar asta din urma rezista si daca ROAClient se
   instaleaza dupa kit, sau daca folderul instantclient se muta.

2. ORA-01017 desi parola e corecta.

   Cu SQLNET.ALLOWED_LOGON_VERSION_SERVER=8 serverul autentifica orice client
   pre-12c pe baza verificatorului 10G. Un cont fara 10G in PASSWORD_VERSIONS
   nu se mai poate conecta din Instant Client 10/11, si eroarea nu e ORA-28040,
   ci ORA-01017 - fix cea care trimite pe pista parolei. Dupa o instalare 21c,
   SYSTEM are doar 11G 12C; CONTAFIN_ORACLE scapa doar pentru ca pasul 01 ii
   rescrie parola dupa ce a scris sqlnet.ora. Pasul 01 rescrie acum si parola
   lui SYSTEM, din CDB$ROOT, cu aceeasi valoare.

   Subtilitate: interogat din PDB, PASSWORD_VERSIONS al unui utilizator comun
   ramane cel vechi si dupa reparatie, desi autentificarea foloseste definitia
   din root si functioneaza. Coloana nu e o dovada pentru SYSTEM; conectarea e.

3. Pasul 07 verifica acum ce nu se vede pe hartie.

   Toate cele trei erori trec de verificarile de pana acum: fisierul exista,
   parametrul e setat, contul e OPEN, obiectele sunt valide. Sectiunea noua
   "Conectivitate client vechi (Instant Client)" verifica unde se citeste
   efectiv sqlnet.ora, daca tnsnames.ora din TNS_ADMIN mai e sablonul, daca
   LOCAL_LISTENER e alias sau adresa, ce verificatoare de parola au conturile,
   si - singurul lucru care le prinde pe toate - face o conectare adevarata cu
   Instant Client-ul gasit pe masina. La esec, raportul spune si unde sa te
   uiti. Parametri noi: -ContafinPassword, -InstantClientDir.

4. Get-ServerLanIPv4, in biblioteca.

   Pe serverele la care intram prin Tailscale, un tnsnames.ora cu 100.x nu duce
   nicaieri de pe o statie. Functia alege IP-ul din LAN sarind peste Tailscale
   (100.64.0.0/10) si APIPA, dupa ruta implicita cand sunt mai multe placi.
   Get-ListenerHost o foloseste si el la fallback-ul pe 0.0.0.0, unde inainte
   lua prima adresa nefiltrata.

La VADECO a mai fost nevoie de o corectie manuala, in afara kitului: listener.ora
avea HOST = <nume>.ts.net, deci pornirea listenerului depindea de Tailscale.
Regula generala e in documentatie.

Detaliile, cu dovezi si comenzi de diagnostic: docs/lectii-conectare-client-oracle.md

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
 2026-08-25 22:14:45 +03:00
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
Marius
7fce925349 feat(oracle): kit de instalare la client + corectarea lipsurilor din instalare 
Blocul de instalare/migrare Oracle 21c XE, terminat si validat pe VM 302.

Kit de instalare (nou)

  scripts/build-client-kit.ps1 exporta CONTAFIN_ORACLE si FIRMANOUA de pe
  LXC 108 (PDB ROA2, nu ROA - ROA e productia ROA_CENTRAL), le aduce local
  prin cele trei hopuri container -> LXC -> host -> statie, le redenumeste la
  numele pe care le asteapta scripturile si le impacheteaza cu o copie a
  directorului roa-windows-setup. Citeste logul expdp si raporteaza cate
  firme are NOM_FIRME, ca sa nu plece din greseala datele unui client.

  roa-windows-setup/INSTALEAZA.cmd ruleaza pasii 01..08 fara "set /p", deci
  merge si prin SSH - RunAll.cmd nu poate fi rulat neinteractiv. Trateaza
  corect codul 5 de la pasul 03 si se opreste la prima eroare reala.

Corectii

  01-setup-database.ps1 nu mai scrie SQLNET.RECV_TIMEOUT / SEND_TIMEOUT in
  sqlnet.ora. Le hardcoda la 30 s, iar fisierul e citit si de impdp: in timpul
  unui import serverul poate lucra minute fara sa trimita un pachet, clientul
  murea cu ORA-12609 iar scriptul raporta esec pentru un import care se
  terminase cu bine pe server. Reprodus si reparat pe VM 302.

  01-setup-database.ps1: Step 4c optional (-ResetSystemPassword) care curata
  EXPIRED(GRACE) pe SYSTEM in CDB root; ALTER PROFILE opreste expirarile
  viitoare dar nu reseteaza un cont deja intrat in gratie.

  uninstall-roa.sql: retry la DROP USER dupa KILL SESSION, plus un bloc final
  de verdict care numara ce a ramas si iese cu ORA-20900 daca baza nu e
  curata. Pana acum toate sectiunile prindeau exceptiile in WHEN OTHERS si
  scriptul tiparea "UNINSTALL COMPLETE" chiar si cand un user supravietuise,
  iar instalarea urmatoare dadea ORA-31684 in lant. 99-uninstall-roa.ps1
  propaga codul de iesire.

  08-post-install-config.ps1: Step 7b seteaza SMTP_OUT_SERVER si ACL-ul de
  retea pentru CONTAFIN_ORACLE. UTL_MAIL se instala si primea EXECUTE, adica
  destul cat sa compileze, dar nu si cat sa trimita. Privilegiul resolve nu
  accepta interval de porturi (ORA-24244), deci se acorda separat de connect.

  07-verify-installation.ps1: sectiune noua care verifica prezenta lui
  FIRMANOUA.dmp in DMPDIR si o raporteaza ca eroare daca lipseste. Fara el,
  adaugarea unei firme noi pica in DBMS_DATAPUMP.ADD_FILE peste luni de la
  instalare, cand nimeni nu mai leaga eroarea de instalare.

  configure-profile.sql: antetul spune ca e unealta de remediere manuala, nu
  parte din flux; pas nou la final pentru CDB root.

Documentatie

  README-ul roa-windows-setup descrie acum explicit cele doua scenarii -
  instalare pe curat si migrare - de unde se iau DMP-urile sablon, si capcana
  ORA-12609. Handoff-urile de sesiune au fost sterse; ce era durabil in ele a
  intrat in README-uri si in docs/diagnostic-spatiu-clienti.md.

Validare pe VM 302: ciclu complet din kit, instalare pe curat, verificarea
finala "[OK] All checks passed!".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
 2026-08-25 18:05:56 +03:00
Marius
afb8266407 feat(oracle): granturi dictionar PACK_DIAG_SPATIU + sys-grants.sql legat in flux 
Trei probleme gasite pregatind migrarea unui client de pe Oracle XE 11 pe XE 21c.

1. sys-grants.sql nu era rulat de niciun script PowerShell. Era referit doar din
   run-all-sys.sql, care se lanseaza manual. Pe orice instalare facuta cu
   RunAll.cmd lipseau sinonimele SYS (SYN_NEWSCHEMA, SYN_NEWSCHEMAJOB,
   EXECUTESCRIPTOS, SYN_PINFO), DMPDIR si granturile pe DBMS_SCHEDULER / UTL_* /
   DBMS_CRYPTO catre CONTAFIN_ORACLE. Legat ca STEP 3 in 04-create-synonyms-grants,
   dupa import - unde propriul header al fisierului spune ca trebuie rulat.

2. Granturile de dictionar cerute de PACK_DIAG_SPATIU lipseau complet. Consolidez
   sys_2026_08_03_05, sys_2026_08_03_07 si sys_2026_08_06_07 in sectiunea [5/5]
   din sys-grants.sql: SELECT direct pe 18 vederi dba_*/v$*, idempotent, cu
   ORA-00942 tratat pentru vederile absente pe alte editii/versiuni. Grantul prin
   rolul DBA nu ajunge - rolurile nu se aplica in pachetele cu drepturi de
   definitor, iar PACK_DIAG_SPATIU e exact asa; fara ele ramane INVALID si
   DIAGSPATIU_ZILNIC nu ruleaza.

3. Capcana la migrari: tabela de versiuni a lui PACK_MIGRARE traieste in
   CONTAFIN_ORACLE si vine cu DMP-ul, deci baza noua raporteaza scripturile sys_*
   drept aplicate si ROAACTUALIZARI le sare, desi in SYS nu exista nimic. De aceea
   obiectele si granturile SYS se pun la instalare, nu prin actualizator.
   Documentat in sys-updates/README.md si in ghidul nou.

07-verify-installation raporteaza nominal care dintre cele 18 granturi lipsesc.

Documentatie: docs/instalare-si-migrare-oracle.md - arbore de decizie intre
roa-windows-setup/ (client pe Windows), migration/ (Oracle in Docker pe LXC 108) si
new-roa-oracle-server/ (arhiva). Include de ce migration/ nu se foloseste la un
client Windows: creeaza PDB ROA cu OraclePass123, sinonime minimale, fara
SERVER_INFO / ROAUPDATE / ACL / sqlnet.ora, iar sys_objects.sql de acolo creeaza
INFO in SYSTEM - cauza cunoscuta a ORA-01653 la actualizare. Plus comenzile de
export din XE 11 / 10g si plafonul XE de 12 GB.

Corectat pe drum: dual-edition-test-plan si issues-se-prod indicau clonarea
VM 302 -> 303 pentru testul SE, dar 303 e ocupat de Win11-Adina. Mutat pe 304.

NETESTAT pe baza reala - VM 302 e oprit. Scripturile trec doar parse-check
PowerShell.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
 2026-08-25 15:46:28 +03:00
Marius
989477f7a4 Add ROA Oracle Database Windows setup scripts with old client support 
PowerShell scripts for setting up Oracle 21c/XE with ROA application:
- Automated tablespace, user creation and imports
- sqlnet.ora config for Instant Client 11g/ODBC compatibility
- Oracle 21c read-only Home path handling (homes/OraDB21Home1)
- Listener restart + 10G password verifier for legacy auth
- Tested on VM 302 with CONTAFIN_ORACLE schema import

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2026-01-28 17:08:02 +02:00