Pe VADECO (instalat 25.08.2026) salvarea in istoric coduri fiscale pica cu
PLS-00905: VADECO.PACK_PARTENERI invalid. Cauza: pachetul isi declara parametrii
ca ISTORIC_CODURI_FISCALE.<col>%TYPE, nume necalificat, iar sinonimul public
lipsea. Serverul avea 81 de sinonime publice catre CONTAFIN_ORACLE, productia
10.0.20.36 are 100 -- lipseau exact 20.
Gaura apare pentru ca sinonimele publice nu fac parte dintr-un export
schema-mode (impdp nu le aduce), singurul loc care le creeaza este o lista
enumerata manual, iar CONTAFIN_ORACLE.VERSIUNE vine cu DMP-ul si marcheaza
scripturile co_*/sys_* drept aplicate, deci nici ROAACTUALIZARI nu le mai
ruleaza. Din acelasi motiv lipsea si SYS.NEWSCHEMAPROGRESS, o functie din 2014.
- synonyms-public.sql: cele 20 de sinonime (81 -> 101 CREATE)
- sys-objects.sql: pas [9b/10], SYS.NEWSCHEMAPROGRESS (sys_2014_11_06_01_FIRMA)
- sys-grants.sql: SYN_NEWSCHEMAPROGRESS in [3/6]; granturi directe SELECT pe
SYS.DBA_DATAPUMP_JOBS si SYS.AUTH_SERII in [1/6] (sys_2013_01_23_02)
- docs/refresh-scripturi-dupa-instalare.md: de ce completarea listelor e paliativ
si ce ar trebui sa faca un pas de refresh rulat dupa instalare, nu la instalare
- sys-updates/README.md, CLAUDE.md: trimiteri catre documentul nou
Aplicat pe VADECO: PACK_PARTENERI si PACK_IMPORT_COMENZI sunt VALID pe VADECO,
DANUBE, LACERTA si SPACE. Obiectele ramase invalide sunt cele preexistente,
invalide si pe 10.0.20.36.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J7vUBDUY5hvLwRZ45Uqzcf
La VADECO, backupora.exe rula in fiecare noapte, se termina cu cod 0 si scria
"DONE" pentru fiecare schema - dar directorul zilei ramanea gol. Intre 25 si
28.08.2026 nu a existat niciun export.
Cauza: schema.txt cere "@XEPDB1", iar 01-setup-database.ps1 scria in tnsnames.ora
doar aliasul ROA. expdp cadea instant cu ORA-12154, iar backupora.exe nu-i
verifica codul de iesire. Doua scripturi din acelasi kit nu erau de acord asupra
numelui bazei, si nimic nu tipa.
Indiciul din log, daca reapare: fiecare schema dura exact 16 secunde, indiferent
de marime. Timp uniform = expdp moare la conectare, nu exporta.
Reparatii, ca sa nu se repete la alt client:
- 01-setup-database.ps1 scrie acum doua aliasuri, ROA si numele serviciului,
in ambele tnsnames.ora. Curatarea dinaintea rescrierii parcurge fiecare alias
gestionat de noi, altfel al doilea s-ar dubla la fiecare rulare. Aliasurile
generate de Oracle (XE, LISTENER_XE, ORACLR_CONNECTION_DATA) raman neatinse.
- 11-setup-backup-export.ps1 face tnsping inainte de a scrie schema.txt si
opreste instalarea daca aliasul nu se rezolva. Mai bine o instalare care se
plange decat un backup care nu exista.
- lectii-actualizare-roa-alias-tns.md capata sectiunea despre a doua victima a
aceleiasi cauze. Lectia generala: unde un script lanseaza un proces extern
Oracle, verifica efectul, nu raportul procesului care l-a lansat.
Include si blocul NTS din config/sqlnet.ora, ramas necomis: autentificarea OS
cere si apartenenta la ORA_OraDB21Home1_DBA, si setarea din sqlnet.ora.
Nota: CLAUDE.md apare ca modificat integral - blob-ul din git avea CRLF, iar
core.autocrlf=true il normalizeaza la LF. Modificarea reala e o singura linie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X9Sa54oFKpE2XhD6A7NTch
Constatat la VADECO pe 2026-08-28: pe serverul acela actualizarea ROA nu
aplicase NICIODATA un script, desi jobul raporta succes de la instalare.
PACK_UPDATE nu aplica el scripturile - genereaza D:\DMPDIR\script_master.sql
si lanseaza un sqlplus EXTERN, apoi se termina. Deci UPDATEROA_ZILNIC
raporteaza starea lansarii, nu a actualizarii: SUCCEEDED in ~5 secunde chiar
si cand nu s-a aplicat nimic. Scriptul generat incepe cu
"CONNECT CONTAFIN_ORACLE/...@ROA" (aliasul vine din NOM_FIRME.NUME_SERVER)
si are WHENEVER SQLERROR EXIT, deci iese la prima linie daca aliasul nu se
rezolva.
Lantul cauzal: sqlplus-ul lansat de baza mosteneste mediul serviciului
Oracle. La o instalare noua instanta porneste INAINTE ca 01-setup-database
sa scrie TNS_ADMIN de masina, deci serviciul nu il are si cade pe
tnsnames.ora din Oracle Home. La 21c XE home-ul e read-only, deci fisierul
real e in product\21c\homes\OraDB21Home1\network\admin, iar acolo Oracle
genereaza doar XE, LISTENER_XE si ORACLR_CONNECTION_DATA - fara ROA.
Rezultat: ORA-12154, tacut. Perfid: tnsping ROA REUSESTE dintr-o sesiune
interactiva, pentru ca aceea are TNS_ADMIN.
Eroarea era mascata dublu - jobul zicea SUCCEEDED, iar emailul de raportare
nu pleaca oricum (ORA-29279, SMTP-ul romfast nu anunta AUTH).
01-setup-database.ps1 scrie acum aliasul si in tnsnames.ora al Oracle
Home-ului, cu acelasi IP din LAN. Blocul se IMBINA in fisierul existent:
XE, LISTENER_XE si ORACLR_CONNECTION_DATA raman neatinse, pentru ca de ele
depind extproc si inregistrarea instantei la listener. Cu backup si
idempotent - regexul consuma si comentariile lipite deasupra lui "ROA =",
altfel antetul se dubla la fiecare rulare (prins de test).
Testat unitar (fisier Oracle fara ROA, idempotenta peste 4 rulari, ROA
preexistent cu alt IP la mijloc, fisier inexistent, paranteze echilibrate,
fara BOM) si end-to-end pe o copie a fisierului real de pe serverul VADECO:
tnsping ROA OK, sqlplus CONTAFIN_ORACLE@ROA conectat in XEPDB1, zero ORA-,
XE si LISTENER_XE inca se rezolva.
docs/lectii-actualizare-roa-alias-tns.md are diagnosticul complet, inclusiv
cum verifici ca actualizarea chiar s-a aplicat: script_master.log si
SCHEMA.versiune, NU statusul jobului. Contine si capcana ca randurile din
SCHEMA.versiune vin cu dump-ul la import, deci o schema proaspat importata
pare la zi fara ca actualizarea sa fi rulat vreodata local.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X9Sa54oFKpE2XhD6A7NTch
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
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
Gasite la instalarea de productie VADECO (Oracle 21c XE, Windows Server 2019).
1. Pe serverul VADECO procesul Oracle nu poate atinge nicio cale de pe C:,
nici macar C:\Windows\Temp, desi ACL-urile sunt corecte si serviciul ruleaza
ca NT SERVICE\OracleServiceXE. D: merge cu exact acelasi grant. Calea DMP
era insa hardcodata "C:\DMPDIR" in 01, 02, 05, 06 si in biblioteca, deci
instalarea nu se putea muta. Acum e parametrul -DmpDir, expus ca /dmpdest:
in FAZA1.cmd si FAZA2.cmd si transmis tuturor pasilor.
Cel mai perfid era pasul 02: recrea DIRECTORY DMPDIR pe 'C:\DMPDIR' peste
valoarea pusa de 01. Chiar cu restul instalarii mutata, SYS.NEWSCHEMA ar fi
cautat FIRMANOUA.dmp in alta parte, iar adaugarea unei firme noi ar fi picat
peste luni, fara legatura vizibila cu instalarea.
2. New-OracleDirectory compara doar siruri de caractere: verifica ce scrie in
dba_directories, nu daca baza chiar poate scrie acolo. Acum face un
UTL_FILE round-trip si esueaza pe loc, cu explicatia cauzei. Inainte,
directorul inutilizabil trecea drept bun si importul cadea abia in impdp cu
ORA-29283, la zeci de linii distanta. Valoarea de retur nici nu era
verificata in 01/03/06 - de aici si "True" ratacit in log.
3. Instalarea ROAClient seteaza TNS_ADMIN de masina spre instantclient-ul ei.
Serviciul Oracle mosteneste variabilele de masina, deci citea sqlnet.ora de
acolo - unde nu exista niciunul - si nu din Oracle Home, unde il scria pasul
01. Compatibilitatea pentru clienti vechi nu se aplica, iar statiile ar fi
primit ORA-28040 cu fisierul scris corect, in locul gresit. Pasul 01 scrie
acum sqlnet.ora si in TNS_ADMIN cand difera.
4. Pasul 05 lega schemele de DMP-uri cu "^$schema[_\.]", deci schema DANUBE
putea primi DANUBE_20200914.dmp - datele altei firme, fara avertisment.
Numele exact are acum intaietate, prefixul se accepta doar daca e unic, iar
ambiguitatea se raporteaza.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
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
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
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
VM 303 rula ca linked clone din VM 300, deci template-ul contaminat nu putea
fi sters. Transformat in full clone si VM 300 eliminat din infrastructura.
Metoda: zfs send/recv local + swap de volid in config. `qm move-disk` nu era
o optiune — PVE respinge mutarea pe acelasi storage, iar pentru zvol-uri
conditia din Qemu.pm:4688 e mereu adevarata (numele n-are sufix de format).
- inventarele nu mai listeaza VM 300; VM 310 ramane singurul template
- clone-vm300.sh: comentariul spune de ce sursa e 310 (numele e istoric)
- handoff-ul sters la cererea utilizatorului; faptele care mai conteaza sunt
mutate inline in README-uri, ca sa nu ramana referinte moarte
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
VM 300 `Win11-Template` nu a fost sysprep-uit: poarta numele ROACENTRAL si
SID-ul de masina al VM 201 (S-1-5-21-1850128657-3079265004-705332634).
Clonele lui mostenesc acea identitate, iar NTLM intre doua masini cu acelasi
SID de masina esueaza — de aici imposibilitatea accesarii share-urilor SMB
intre VM 303 si VM 201, in ambele sensuri.
VM 300 nu poate fi reparat in loc: e template read-only, iar VM 303 e linked
clone din el. Solutia: clona completa 300 -> 310, sysprep acolo, conversie in
template. Verificat pe o clona de proba: nume si SID noi la fiecare pornire.
- clone-vm300.sh: SOURCE_VMID 300 -> 310
- README-uri: VM 310 marcat ca template de clonare, VM 300 ca "nu clona"
- vm302-oracle-test: corectat exemplul care clona in VM 303 (deja ocupat)
- docs/handoff-smb-vm303-roacentral.md: probele, capcanele de sysprep, stare
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
DROP+CREATE in loc de ALTER TABLE MOVE: continutul e log fara valoare, iar
recrearea nu cere spatiu liber cat segmentul si nu tine tabela blocata cat ar
dura copierea. DROP e cu PURGE, altfel segmentul ramane in recyclebin si spatiul
nu se elibereaza. SYS.pINFO ramane INVALID dupa DROP, deci se recompileaza.
Scriptul de livrare: SVN r18010.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rft5ofNa4Ux5VEh4YnhJRC
Doar line endings, zero modificari de continut (verificat cu
git diff --ignore-cr-at-eol: fara diferente ramase pe aceste fisiere).
Fisierele aveau CRLF comis efectiv in repo, nu doar in working tree.
Sunt scripturi care ruleaza pe Linux (migrarea Oracle, LXC 171 claude-agent),
iar deployate direct din working tree bash le refuza cu
"$'\r': command not found" - exact capcana pe care .gitattributes (comis in
9475842) o previne de acum inainte pentru fisierele noi.
Nu sunt incluse fisierele .md/.sql din roa-windows-setup: acelea au
modificari reale de continut, in curs, si apartin altui commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
SYS.INFO e log de aplicatie (SYS.pINFO din AUTH_PACK scrie ~7 randuri la fiecare
conectare, ~13.500 randuri / ~2 MB pe luna) si nimic din baza nu-l citeste. Creat
de installer in tablespace-ul SYSTEM si nepurjat niciodata, a umplut SYSTEM la doi
clienti si a oprit actualizarea cu ORA-01653 - eroarea apare pe orice script,
pentru ca AUTH_PACK scrie acolo la conectare.
SIGMA 03.08.2026 - ff_2026_07_29_02_COMUN_TVA11 picat pe MARCU
AUTOMOTIVE 08.08.2026 - 552.581 randuri / 80 MB, SYSTEM cu 5 MB liberi
Installer:
- sys-objects.sql: SYS.INFO (tabela + segment LOB) se creeaza in tablespace-ul
ROA, cu fallback pe SYSTEM daca ROA inca nu exista
- scheduler-jobs.sql: job nou SYS.SYSINFO_PURJARE_ZILNIC, zilnic 03:30, retentie
90 zile, stergere in transe de 10.000 randuri; creat ENABLED, pentru ca nu are
nimic de configurat iar uitat dezactivat reproduce chiar problema pe care o
rezolva. In schema SYS: privilegiile ANY nu se aplica pe obiectele SYS cat timp
O7_DICTIONARY_ACCESSIBILITY=FALSE
- uninstall-roa.sql: dezinstalarea sterge si jobul
- 00-INSTALL-ORACLE-XE.md / -SE.md: pas post-instalare pentru plafonul SYSTEM
(maxsize 2000M) si mutarea SYS.INFO la instalarile vechi
Documentatie noua (docs/diagnostic-spatiu-clienti.md): jobul DIAGSPATIU_ZILNIC si
pragurile lui, formatul emailurilor de alerta si cum se citesc din mbox-urile
Thunderbird, procedura de tunel SSH catre serverul unui client, triajul alertelor
si starea la 08.08.2026 pe fiecare client.
Reparatia la AUTOMOTIVE e deja aplicata in productie (plafon 600 -> 2000 MB,
truncate SYS.INFO): SYSTEM a trecut de la 65 MB la 1545 MB de crestere posibila.
Scriptul de livrare pentru ceilalti clienti e scris, dar nepublicat:
COMUN sys_2026_08_08_02_SYS_INFO_TABLESPACE_PURJARE.sql
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rft5ofNa4Ux5VEh4YnhJRC
clienti/ contained Oracle XE 21c troubleshooting and PDB recreation
scripts. Moving it under proxmox/lxc108-oracle/ keeps Oracle migration
material colocated with the Oracle host docs. Update the two relative
links in roa-windows-setup that pointed to the old location.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Move VM302-TESTING.md from lxc108-oracle/roa-windows-setup/test/ into a
new proxmox/vm302-oracle-test/ directory (sibling of vm109/vm201) so the
test environment is documented separately from the setup scripts. Add a
dual-edition test plan (XE validated / SE TODO) and a stub for capturing
the production SE errors next time they reproduce.
Cross-link from roa-windows-setup/README.md, proxmox/README.md master
index and CLAUDE.md entry points. Setup scripts stay in lxc108-oracle —
they are not VM-specific.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- ExecuteScriptOS.prc: runs PowerShell scripts via DBMS_SCHEDULER
- UpdateSQLPLUS.prc: runs SQL*Plus scripts via DBMS_SCHEDULER
- find_oracle_locations.sql: comprehensive script to discover all Oracle DB paths for backup/migration
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- New-OracleDirectory: Improved verification with direct SQL check, preserves
existing DMPDIR path instead of blindly recreating
- Get-DatafilePath: Better fallback logic using ORACLE_HOME to derive path,
no longer hardcodes C:\app\oracle
- grants-public.sql: Fixed DMPDIR creation - now preserves existing path
instead of overriding with wrong D:\Oracle\admin\ORCL\dpdump
- config.example.ps1: Added DATAFILE_DIR parameter with documentation
These fixes ensure scripts work without manual intervention on fresh Oracle XE
installations where default DMPDIR points to non-existent paths.
Tested on VM 302 - full installation (01-08) now completes successfully.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- New-OracleDirectory now checks if DMPDIR exists with wrong path
- If path differs from target, drops and recreates the directory
- Fixes Oracle XE issue where DMPDIR defaults to D:\Oracle\admin\ORCL\dpdump
- Added VM302-TESTING.md with complete testing workflow documentation
- Includes Proxmox VM management commands, troubleshooting, and deployment steps
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The script had inline SQL that was missing 20 synonyms compared to
synonyms-public.sql, causing PACK_DEF and other packages to fail with
missing synonym errors (SYN_VNOM_UM_ISO, SYN_ATAS_*, SYN_SAL_*, etc.).
Changes:
- Remove all inline SQL (~350 lines)
- Now runs synonyms-public.sql (81 synonyms vs 61 before)
- Now runs grants-public.sql for all grants and ACL
- Add verification of SESIUNE context
This ensures the script stays in sync with the SQL files and
prevents future desync issues.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Key fixes:
- Add Run.cmd/RunAll.cmd wrappers with ExecutionPolicy Bypass
- Add Get-ListenerHost() to auto-detect listener IP address
- Fix impdp connection using EZConnect format (host:port/service)
- Add parallel=1 for Oracle XE compatibility
- Fix Write-Log to accept empty strings with [AllowEmptyString()]
- Fix Get-SchemaObjectCount regex for Windows line endings (\r\n)
- Fix path comparison for DMP file copy operation
- Add GRANT EXECUTE ON SYS.AUTH_PACK TO PUBLIC for PACK_DREPTURI
- Fix VAUTH_SERII view to use SYN_NOM_PROGRAME (has DENUMIRE column)
- Add sections 10-11 to grants-public.sql for SYS object grants
Tested on VM 302 (10.0.20.130) with Oracle XE 21c.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Increase wait time from 10s to max 60s after listener restart
- Add active polling every 5s to check if service is registered
- Log progress while waiting for service registration
- Fixes race condition where script proceeds before service is ready
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- run-all-sys.sql: Master script that executes sys-objects.sql,
sys-grants.sql, and any scripts in sys-updates/ folder in order
- sys-grants.sql: Grants EXECUTE on AUTH_PACK, DBMS_SCHEDULER,
DBMS_LOCK, UTL_* packages to CONTAFIN_ORACLE; creates public
synonyms for SYS procedures; creates DMPDIR directory
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Rename $Host parameter to $DbHost in oracle-functions.ps1 (Invoke-SqlPlus,
Test-OracleConnection, Get-OracleVersion, Test-PDB, Get-ServiceName)
- Update all function calls in 01-setup-database.ps1 to use -DbHost instead of -Host
- Fix ${Host} -> ${DbHost} in log message (line 147)
- Fix Write-Log "" -> Write-Host "" to avoid empty string parameter error
- Add DbHost/Port parameters and config.ps1 support to setup script
- Update sys-updates/README.md to clarify folder is for future patches only
Tested successfully on ROACENTRAL (10.0.20.130) with Oracle XE 21c.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Added roa_kill_user_sessions helper procedure
- Kill all active sessions BEFORE attempting DROP USER
- Improved company user detection (also checks for synonyms to CONTAFIN_ORACLE)
- Added more Oracle 21c internal users to exclusion list
- Better error handling and output messages
- Helper procedure auto-cleanup at end
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
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>
