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
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>
