ROMFASTSQL/docs/diagnostic-spatiu-clienti.md

Diagnostic spatiu Oracle la clienti — unde sunt lucrurile si cum se citesc

Nota de referinta, ca sa nu se mai caute nimic de la zero. Sursa efectiva a scripturilor e repo-ul COMUN; aici stau doar pointerii + cum se citesc emailurile + cum se interpreteaza alertele.

1. Unde sunt scripturile (repo COMUN)

Remote	git@gitea.romfast.ro:romfast/comun.git
Clona locala	D:\roa\roagest\comun

Fisier	Ce e
docs\depanare-spatiu-oracle.md	documentul de baza — jobul, mecanismele reutilizabile, ce umple spatiul in ordinea frecventei, cazuri, capcane
docs\PACK_DIAG_SPATIU.pck	sursa de referinta a pachetului rulat in baza clientului
docs\email-thunderbird.md	cum se citesc mbox-urile Thunderbird
docs\depanare-pack-update.md	actualizarea blocata de spatiu (punctul de plecare cand PACK_UPDATE cade)
utile\diag_spatiu.ps1	diagnosticul manual, din afara: powershell -File COMUN\utile\diag_spatiu.ps1 -Alias <ALIAS_TNS> [-Disc] [-SysPassword <parola>] [-Top 30] — strict read-only in afara lui -Disc, curatarea e doar sugerata
utile\citeste_email.ps1	listare/citire mesaje din mbox

2. Jobul automat din baza clientului

DIAGSPATIU_ZILNIC — ruleaza zilnic la 06:00 la fiecare client, e echivalentul in baza al lui diag_spatiu.ps1.

• tabela de istoric DIAG_SPATIU_LOG (purjata la 90 zile), pachetul PACK_DIAG_SPATIU
• scripturi de livrare: co_2026_08_03_02 (tabela), co_2026_08_03_03 (pachet), co_2026_08_03_04 (jobul), sys_2026_08_03_05 (granturi directe — rolurile nu se aplica in pachete cu drepturi de definitor)
• corectii ulterioare: co_2026_08_06_01_DIAG_SPATIU_PACK (praguri + log complet in email), co_2026_08_06_08_DIAG_SPATIU_PACK + sys_2026_08_06_07_DIAG_SPATIU_GRANT3 (tabela/coloana de provenienta la top segmente)

Praguri (exact, din pachet)

tnPragTsMb = 2048 MB absolut, tnPragFraPct = 75 %, CT_PRAG_REL_PCT = 15 %.

Pentru fiecare tablespace se calculeaza cat mai poate creste:

poate_creste = liber_in_datafile + (maxbytes - alocat)

si se alerteaza cand poate_creste scade sub:

max <= 2048 MB  ->  15% din max                        (doar garda relativa)
max >  2048 MB  ->  GREATEST(2048 MB, 15% din max)

Pragul absolut se sare pe tablespace-urile cu maximul sub el (UNDO, SYSTEM mic) — altfel ar alerta zilnic prin definitie. Asta e fix-ul din co_2026_08_06_01; un client care alerteaza pe un tablespace cu max <= 2048 MB si mult spatiu liber nu are inca acest script aplicat.

Alte doua verificari cu prag: FRA (percent_space_used >= 75) si plafonul editiei XE (4/11/12 GB dupa versiune, numarand doar datele de utilizator — fara SYSTEM/SYSAUX/UNDO/TEMP; alerta sub GREATEST(2048 MB, 15% din plafon)).

Sectiunile informative (recyclebin, UNDO, TEMP, istoric statistici/scheduler, top segmente, audit SYS, disc) se scriu doar cand exista deja o alerta — dau context, nu alerteaza singure.

3. Emailurile

• destinatar: marius.mutu@romfast.ro
• expeditor: cate unul per client — roaupdate_acn@, roaupdate-sigma@, roaupdate-clever@, roaupdate-automotive@ … (roaupdate[-_]<client>@romfast.ro)
• subiect: Diagnostic spatiu Oracle <BAZA> <dd.mm.yyyy> <hh:mi> (<BAZA> = numele bazei: XE, ROA, XEPDB1 — nu numele clientului; clientul se ia din expeditor)
• corp: liniile de alerta, apoi (dupa co_2026_08_06_01) tot logul rularii cu ! pe randurile peste prag, plafonat la 30000 de caractere

Linia de tablespace se citeste asa:

TABLESPACE SYSTEM: 65 - alocat=540MB max=600MB liber=5MB
                   ^^                                ^^^
                   |                                 liber in datafile-ul deja alocat
                   cat mai poate creste = 5 + (600-540) = 65 MB

Emailul vine doar la prag depasit. Tacere = totul in regula — dar tacerea inseamna si "jobul nu a rulat", deci la un client care alerta si s-a oprit brusc se confirma cu ultima dataora din DIAG_SPATIU_LOG, nu se presupune ca s-a rezolvat.

4. Cum se citesc emailurile (Thunderbird Portable, local)

Conectorul Gmail din Claude vede doar mmarius28@gmail.com. Conturile de lucru se citesc din mbox-urile Thunderbird Portable:

D:\UTIL\portable\PortableApps\ThunderbirdPortable\Data\profile\ImapMail\mail.romfast.ro\INBOX

• mail.romfast.ro = marius.mutu@romfast.ro (server3 in prefs.js) — contul cautat
• mail.romfast-1.ro = office@romfast.ro (server8)
• restul conturilor sunt vechi de ani
• profilul din %APPDATA%\Thunderbird\Profiles e gol si induce in eroare — instalarea folosita e cea portabila de pe D:; se confirma cu Get-Process thunderbird | Select Path

Varianta cu scriptul din COMUN:

powershell -File D:\roa\roagest\comun\utile\citeste_email.ps1 -Cauta 'Diagnostic spatiu' -Ultimele 10
powershell -File D:\roa\roagest\comun\utile\citeste_email.ps1 -Nr <linie> [-Linii 200]

Varianta fara script, care extrage direct toate diagnosticele (expeditor + subiect + alerte):

$f='D:\UTIL\portable\PortableApps\ThunderbirdPortable\Data\profile\ImapMail\mail.romfast.ro\INBOX'
$from=''
Get-Content $f -ReadCount 0 | ForEach-Object { $_ } | ForEach-Object {
  if     ($_ -like 'From: *')                    { $from = $_.Substring(6) }
  elseif ($_ -like 'Subject: Diagnostic spatiu*') { "`n### $($_.Substring(9))   [$from]" }
  elseif ($_ -like 'TABLESPACE *')                { "    $_" }
}

Capcane la citire:

• nu da Grep/ripgrep pe folderul de mail — INBOX.sbd\Sent are ~2.5 GB si cautarea expira; tinteste fisierul INBOX direct
• numerotarea liniilor difera intre unelte (mbox-ul are linii cu \r singur) — pentru -Nr foloseste numarul dat de citeste_email.ps1
• Thunderbird tine fisierul deschis → citire doar cu FileShare::ReadWrite
• mesajele sunt in ordine cronologica, cel mai nou la sfarsitul fisierului, separator From - <data>

5. Triaj: ce fac cand vine o alerta

1. Verifica intai daca alerta e reala. max <= 2048 MB + poate_creste peste 15% din max = fals pozitiv din pragul absolut → clientul n-are co_2026_08_06_01. Se stinge singura la urmatoarea actualizare, nu se atinge baza.
2. Alerta reala pe SYSTEM/SYSAUX plafonat mic — tiparul SIGMA: blocheaza PACK_UPDATE. Continua cu COMUN\docs\depanare-pack-update.md.
3. Alerta reala pe tablespace-ul de date — cere contextul (top segmente cu DetaliuSegment, disc) din email sau din DIAG_SPATIU_LOG, apoi:
   • segmente TEMPORARY orfane intr-un tablespace permanent → v$sort_usage gol? curatare fortata ca SYS (vezi capcanele din depanare-spatiu-oracle.md)
   • LOB umflat → alter table t move lob (col) store as (...), nu shrink space pe MSSM (ORA-10635)
   • tabele de log ale aplicatiei crescute nelimitat
4. Nu se vede din SQL (fisiere .aud, alert log, trace): diag_spatiu.ps1 -Disc, doar pe servere Windows.
5. Intai ridici plafonul, apoi cureti — curatenia insasi poate esua din lipsa de spatiu.

6. Tunel SSH catre serverul unui client

Regula din COMUN\docs\local\oracle.md: tunelul spre productie se foloseste doar cand acel server e chiar subiectul investigatiei, si atunci strict read-only. Testele se fac pe ROA_CENTRAL, nu prin tunel.

Profilele Bitvise SSH Client stau in D:\GoogleDrive\<client>.tlp (ex. sigma.tlp → romfast@82.137.26.46:22122). Profilul are parola si cheia gazdei salvate si primeste regulile de forwarding de la server (ROA Oracle = 127.0.0.1:1521, ROA Update = 127.0.0.1:80 — a doua esueaza cu Windows error 10013, e normal si nu incurca).

# 0. verifica intai ca nu e deja un tunel deschis spre ALT client
Get-NetTCPConnection -State Listen -LocalPort 1521

# 1. deschide tunelul (fara -c2s: regulile vin de la server; `--%` opreste parsarea PowerShell)
& 'C:\Program Files (x86)\Bitvise SSH Client\stnlc.exe' --% -profile=d:\GoogleDrive\sigma.tlp -noRegistry=y

# 2. conecteaza-te (alias TNS pe 127.0.0.1, SQL-ul dintr-un fisier, nu prin pipe)
& 'D:\ROA\instantclient_19_18\sqlplus.exe' -L -S 'contafin_oracle/ROMFASTSOFT@ROA_SIGMA' '@diag.sql'

# 3. INCHIDE tunelul cand ai terminat
Get-Process stnlc | Stop-Process -Force

Capcane:

• -profile= si un host pozitional nu merg impreuna (ERROR: The host and -profile parameters cannot be used together) — daca dai si -c2s=, scrie regulile cu virgula, nu cu doua puncte.
• aliasurile de client din D:\ROA\instantclient_19_18\tnsnames.ora tintesc toate 127.0.0.1:1521 (ROA_SIGMA → SID=XE), deci un tunel gresit te duce tacut la alt client — de aici verificarea de la pasul 0 si select instance_name, host_name from v$instance ca prima interogare.
• serverele de client pot fi Oracle 11.2 XE (SIGMA e 11.2.0.2 pe DESKTOP-ETLNAPG) — plafonul editiei e 11 GB, iar unele coloane din dba_scheduler_* lipsesc.

7. Situatia la 08.08.2026 (din INBOX)

Primele diagnostice in INBOX sunt din 05.08.2026 (jobul a fost livrat pe 03.08).

Data	Client (expeditor)	Baza	Alerta	Verdict
05–08.08	automotive	XE	SYSTEM: 65 - alocat=540MB max=600MB liber=5MB	reala, cronica, neschimbata 4 zile
05–06.08	automotive	XE	UNDOTBS1: ~487 / max 500MB	fals pozitiv; dispare din 07.08 = pack nou aplicat
05.08	acn	ROA	ROA: 2141.81 / max 32767.98MB (6.5%)	reala
06.08	acn	ROA	ROA: 1716.81 / max 32767.98MB (5.2%)	reala, −425 MB/zi; rulare manuala repetata la 10:48
07–08.08	acn	—	tacere	probabil curatenia din 06.08 (segmente TEMPORARY orfane + move lob) — de confirmat
06–07.08	sigma	XE	SYSTEM: ~1481 / max 2000MB (74% liber), UNDOTBS1: ~480 / max 500MB	fals pozitiv; verificat prin tunel — nimic de facut (vezi mai jos)
05–06.08	clever	XEPDB1	UNDOTBS2: ~2013 / max 2048MB (98% liber)	fals pozitiv; dispare din 07.08

Singura problema reala ramasa: automotive, SYSTEM plafonat la 600 MB. Nu se misca de 4 zile, deci nimeni n-a intervenit; e exact tiparul care blocheaza actualizarea.

AUTOMOTIVE — verificat prin tunel, 08.08.2026 (read-only)

xe 11.2.0.2 pe host SERVER (78.96.115.213, profil automotive.tlp). Alerta e reala si cauza e identificata — acelasi tipar ca la SIGMA pe 03.08:

Datafile	E:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBF
Dimensiune / plafon	540 MB / 600 MB, autoextend YES next 10M
Liber in datafile	5 MB, o singura extenta (+60 MB pana la plafon)
Cel mai mare segment din SYSTEM	SYS.INFO = 80 MB, peste IDL_UB1$ (62) si SOURCE$ (56)
SYS.INFO	552.576 randuri din 18.03.2023, ~13.578 randuri/luna (~2 MB/luna)
AUD$ / FGA_LOG$ / recyclebin	goale (.06 MB / .06 MB / 0)

Restul e sanatos: ROA 5440/32768 MB, SYSAUX 940/32768, UNDOTBS1 380/500, USERS 100/11264. DIAGSPATIU_ZILNIC a rulat azi 06:00 cu o singura alerta (chiar SYSTEM), lantul de actualizare e sanatos (UPD_ISTORIC stare = 4 zilnic), iar scripturile CO_2026_08_06_01/08 + SYS_2026_08_06_07 sunt deja in UPD_DATABASE.

Deci nu e fals pozitiv si nu se rezolva de la sine: SYS.INFO creste ~2 MB/luna intr-un tablespace cu 5 MB liberi. Primul script care cere o extenta noua pica cu ORA-01653, exact ca ff_2026_07_29_02_COMUN_TVA11.SQL pe MARCU la SIGMA — AUTH_PACK scrie in SYS.INFO la fiecare conectare.

Reparatie aplicata 08.08.2026, in ordine (intai plafonul, apoi curatenia — curatenia poate esua din lipsa de spatiu):

-- 1. ca contafin_oracle (are ALTER DATABASE, verificat in session_privs - nu cere SYSDBA)
alter database datafile 'E:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBF'
  autoextend on next 50M maxsize 2000M;

-- 2. ca SYSDBA (sys/romfastsoft@ROA_AUTOMOTIVE as sysdba) - privilegiile ANY nu se aplica pe
--    schema SYS cat timp O7_DICTIONARY_ACCESSIBILITY=FALSE
truncate table sys.info;   -- 552.581 randuri, 80 MB -> 0.06 MB

Rezultat: SYSTEM 540 MB alocati / 2000 MB plafon, 84.94 MB liberi in datafile, 1544.94 MB de crestere (77.2%) — mult peste pragul de alerta (15% din 2000 = 300 MB), deci jobul tace de maine. In SYSTEM au ramas doar segmente de dictionar (IDL_UB1$ 62 MB, SOURCE$ 56 MB, IDL_UB2$ 25 MB), de neatins fara export/import si fara crestere semnificativa.

Plafonul de 11 GB al lui XE 11g e pe date utilizator — SYSTEM nu intra la socoteala, deci ridicarea la 2000 MB nu apropie baza de limita editiei.

SIGMA — verificat prin tunel, 08.08.2026 (read-only)

xe 11.2.0.2 pe DESKTOP-ETLNAPG. Nu e nimic de reparat, alarma s-a stins singura:

• toate tablespace-urile sanatoase: SYSTEM 650/2000 MB (1481 MB de crestere, 74%), ROA 2048/32768, SYSAUX 840/32768, UNDOTBS1 430/500, USERS 100/11264; plafonul XE 11 GB e folosit doar 2.1 GB
• DIAGSPATIU_ZILNIC a rulat azi 06:00 SUCCEEDED, 169 randuri in DIAG_SPATIU_LOG, toate cu prag_depasit = 0 → de aceea n-a venit email azi
• PACK_DIAG_SPATIU recompilat de lantul de actualizare (UPD_ISTORIC are stare = 4 in fiecare zi); CO_2026_08_06_01, CO_2026_08_06_08 si SYS_2026_08_06_07 sunt in UPD_DATABASE si aplicate — corectia de praguri a ajuns intre rularea din 07.08 si cea din 08.08
• cauza incidentului din 03.08 e curatata: SYS.INFO are acum 0.44 MB. SYSTEM e ocupat de dictionar real (IDL_UB1$ 79 MB, SOURCE$ 72 MB, IDL_UB2$ 30 MB …), de neatins fara export/import — dar nici nu deranjeaza la plafonul de 2000 MB
• de urmarit, nu de reparat: DBA_SCHEDULER_JOBS.FAILURE_COUNT = 47 pe UPDATEROA_ZILNIC, desi toate rularile din ultimele 7 zile sunt SUCCEEDED si UPD_ISTORIC ajunge la stare = 4 — pare contor istoric, dinainte de 01.08

8. Plafoane si limitari de pus la instalare (ca sa nu se repete)

Ambele incidente reale de pana acum (SIGMA 03.08, AUTOMOTIVE 08.08) au aceeasi cauza structurala, si e una pe care o produce chiar instalarea noastra: SYS.INFO — logul de login al ROA — se creeaza in tablespace-ul SYSTEM si nu se purja niciodata, intr-un SYSTEM plafonat mic la instalarea Oracle.

proxmox/lxc108-oracle/roa-windows-setup/sql/sys-objects.sql:93

CREATE TABLE SYS.INFO (
    INFO CLOB, DATAORA TIMESTAMP(6) DEFAULT SYSTIMESTAMP, LOCATIA VARCHAR2(200) NULL
) TABLESPACE SYSTEM     -- <-- aici

SYS.pINFO (sys-objects.sql:131) scrie in ea la fiecare conectare, din AUTH_PACK — ~7 randuri per login, ~13.500 randuri/luna ≈ 2 MB/luna (masurat la AUTOMOTIVE: 552.581 randuri / 80 MB acumulate din 18.03.2023). Nimic din baza nu o citeste si nimic nu o goleste.

Valori de referinta

Ce	Valoare	De ce
SYSTEM.DBF maxsize	2000M, autoextend on next 50M	600 MB (implicit la unele instalari) se umple in ~2 ani doar din SYS.INFO; dictionarul singur ocupa ~200 MB
SYS.INFO	purjare periodica, sau creata in ROA	fara asta, orice plafon se atinge in cele din urma
Tablespace ROA	SIZE 1000M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED (sql/create-tablespace.sql:59)	deja bine — dar pe XE limita editiei taie oricum la 11/12 GB
SYSAUX, audit, AWR	vezi „Preventie ORA-12954" din docs/00-INSTALL-ORACLE-XE.md	auto tasks + audit policies + AWR umflu SYSAUX pana la limita

-- de rulat ca SYSDBA la instalare, dupa crearea bazei
alter database datafile '<ORADATA>\SYSTEM.DBF' autoextend on next 50M maxsize 2000M;

Ce s-a schimbat in installer (08.08.2026)

Fisier	Modificare
sql/sys-objects.sql	SYS.INFO se creeaza in tablespace-ul ROA (tabela si segmentul LOB), nu in SYSTEM; daca ROA inca nu exista, cade inapoi pe SYSTEM cu avertisment si comanda de mutare
sql/scheduler-jobs.sql	job nou SYS.SYSINFO_PURJARE_ZILNIC — zilnic la 03:30, retentie 90 zile, stergere in transe de 10.000 de randuri ca sa nu umfle UNDO. Creat ENABLED (spre deosebire de jobul de actualizare): nu are nimic de configurat, iar uitat dezactivat reproduce exact problema pe care o rezolva
sql/uninstall-roa.sql	dezinstalarea sterge si jobul
docs/00-INSTALL-ORACLE-XE.md, docs/00-INSTALL-ORACLE-SE.md	pas post-instalare pentru plafonul SYSTEM + mutarea SYS.INFO la instalarile vechi

Jobul e in schema SYS pentru ca privilegiile ANY nu se aplica pe obiectele SYS cat timp O7_DICTIONARY_ACCESSIBILITY = FALSE — din CONTAFIN_ORACLE ar iesi ORA-01031.

Livrarea catre clientii existenti

D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\sys_2026_08_08_02_SYS_INFO_TABLESPACE_PURJARE.sql (repo COMUN / SVN) face acelasi lucru pe bazele deja instalate, in trei pasi: purjare la 90 de zile → alter table sys.info move tablespace ROA lob (info) store as (tablespace ROA) → crearea jobului.

Pasii 1 si 2 au EXCEPTION WHEN OTHERS THEN NULL intentionat: o eroare acolo (lipsa de spatiu in ROA, tabela blocata) nu are voie sa opreasca lantul de actualizare al clientului, iar ce nu s-a facut se vede a doua zi in alerta DIAGSPATIU_ZILNIC. Scris la nivel Oracle 10.2, idempotent, CRLF.

Nepublicat inca — publicarea se face cu COMUN\utile\publicare_scripturi.ps1 si e o actiune catre toti clientii.

Pointeri incrucisati: 00-INSTALL-ORACLE-XE.md si 00-INSTALL-ORACLE-SE.md.

9. Legaturi in acest repo

Document	Ce e
diagnostic-ora-65114-spatiu.md	ROA_CENTRAL, 02.08.2026 — ORA-65114, topologia 10.0.20.121, ce trebuie masurat
curatenie-spatiu-oracle.sql	SQL-uri gata scrise de curatenie tintita
../proxmox/lxc108-oracle/clienti/oracle-xe-21c/	ROMPETROL ENERGY — ORA-12954, recreare PDB (13.5 GB → 3 GB)
../proxmox/lxc108-oracle/clienti/README.md	indexul cazurilor de client

---

Ultima actualizare: 08.08.2026