Serverul 10.0.20.36 a parut blocat 20 de minute (12:02-12:22). Nu a fost
blocaj, crash sau oprire: a intrat in standby S3 in urma unei actiuni de
power de la consola. BootId neschimbat, oracle.exe si tnslsnr.exe neintrerupte
din 15 iulie, zero erori in System/Application.
Dovada decisiva e listener.log: clienti serviti normal pana la 12:01:26, apoi
gaura totala pana la 12:22:03 - singura discontinuitate din toata ziua.
Remediere aplicata si verificata:
- somnul eliminat complet (powercfg /a nu mai listeaza nicio stare)
- butoane power si meniu Start -> Shut down; buton sleep -> Do nothing
- Sleep after era 600 s pe profilul DC, adica serverul ar fi adormit la 10 min
dupa o pana de curent; acum 0
- Critical battery action era Hibernate, imposibil dupa dezactivarea hibernarii;
corectat pe Shut down, praguri urcate 5%->20% / 7%->25% / 10%->40%
- ViewPower oprit si dezactivat: comunicatia cu UPS-ul era moarta (QPI NAK), iar
Windows gestioneaza UPS-ul nativ prin HID UPS Battery
- sonda roa2web care lovea listenerul la 30 s: oprita. Verifica portul 1521, adica
listenerul de productie, nu tunelul vending - raporta fals "sanatos". Tunelul e
dezactivat, era oricum cazut de la boot-ul din 15 iulie
Ramane, doar daca se repune vending in functiune: autorizarea cheii pe
79.119.86.134 (plink e respins de server dupa banner-ul de versiune).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RoM99w9qRELJefaWrtPRHo
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
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
