comun/docs/depanare-spatiu-oracle.md

Depanare spatiu Oracle la clienti

powershell -File COMUN\utile\diag_spatiu.ps1 -Alias <ALIAS_TNS> [-Disc] [-SysPassword <parola>] [-Top 30]

Strict read-only in afara lui -Disc (singura parte care scrie: un .ps1 temporar in DMPDIR, lansat cu sys.ExecuteScriptOS si sters la final). Actiunile de curatare sunt doar sugerate, niciodata executate. 8 sectiuni: conexiune/versiune (CDB-PDB), tablespace + top segmente, audit, alert log/trace/ADR, archivelog/FRA, disc server, alti mancatori de spatiu, verdict.

Pentru actualizarea blocata de spatiu, punctul de plecare e depanare-pack-update.md.

Jobul automat DIAGSPATIU_ZILNIC (SVN r17969)

Echivalentul in baza al scriptului de mai sus, rulat zilnic la 06:00 de la fiecare client: co_2026_08_03_02 (tabela DIAG_SPATIU_LOG, istoric purjat la 90 zile), co_2026_08_03_03 (PACK_DIAG_SPATIU), co_2026_08_03_04 (jobul), sys_2026_08_03_05 (granturi). Praguri identice cu diag_spatiu.ps1; email doar la prag depasit, tacere completa altfel. Sursa de referinta: COMUN\docs\PACK_DIAG_SPATIU.pck.

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.

co_2026_08_06_01_DIAG_SPATIU_PACK (06.08.2026) corecteaza doua lucruri vazute pe primele rulari:

• pragul absolut (2048 MB) nu se mai aplica tablespace-urilor al caror maxim e sub el — orice UNDOTBS/SYSTEM plafonat la 500–2048 MB alerta zilnic, prin definitie; acolo ramane doar garda relativa de 15%.
• emailul contine tot logul rularii (alertele intai, apoi toate randurile din DIAG_SPATIU_LOG, cu ! pe cele peste prag, sortate pe sectiune si valoare descrescator), nu doar un pointer catre tabela. Corpul e plafonat la 30000 de caractere (EmailDiagSpatiu lucreaza pe VARCHAR2(32000)), cu marcaj ... restul in DIAG_SPATIU_LOG la depasire.

Mecanisme reutilizabile (din investigatia pentru job)

• CONTAFIN_ORACLE.SERVER_INFO tine parolele PASSWORD_SYS/PASSWORD_CONTAFIN_ORACLE (zip+base64, nu criptare), caile SQLPLUSPATH/POWERSHELLPATH/DMPDIR, cheile EMAIL_* si cache-ul VERSIUNE_<SCHEMA>. Parola se citeste cu PACK_UPDATE.GetSchemaParola('<SCHEMA>') (decodeaza doar pentru SYS si CONTAFIN_ORACLE; pentru schemele de firma intoarce 'ROMFASTSOFT' hardcodat).
• Rulare ca SYS din PL/SQL: scrii un .sql in DMPDIR cu connect sys/<parola>@ROA as sysdba + spool, il lansezi cu sys.UpdateSQLPLUS si astepti fisierul de iesire; pentru OS, sys.ExecuteScriptOS (PowerShell). Ambele sunt asincrone (job dbms_scheduler de tip executable, auto-drop) — mecanismul folosit si de PACK_UPDATE.UpdateDatabaseSqlPlus. Fisierele temporare au nume proprii, ca sa nu se bata cu script_master.sql al actualizarii.
• PACK_UPDATE.EmailLog nu e reutilizabila pentru alt continut: subiectul e hardcodat ("Actualizare ROA ...") si corpul vine din UPD_LOG. Pentru alte alerte, bloc UTL_SMTP propriu care citeste aceleasi chei EMAIL_*.
• Scripturile sys_* se aplica automat, ca orice co_/ff_: prefixul e recunoscut in PACK_UPDATE.UpdateSchema*, schema SYS se actualizeaza prima, iar UpdateVersiune isi scrie randul in CONTAFIN_ORACLE.versiune (schema SYS n-are tabela proprie). Deci un sys_ livrat in aceeasi zi ruleaza inaintea scripturilor co_ care depind de el.

Ce umple spatiul, in ordinea frecventei

• Tablespace cu maxbytes atins — nu "disc plin", ci un plafon pus la instalare. Pe XE limita de 11/12 GB e pe date utilizator, nu pe SYSTEM.
• SYSAUX — SQL Tuning Sets (wri$_sqlset_*), AWR, audit policies active pe un PDB nou.
• Fisierele .aud din audit_file_dest (adump) — zeci de mii, niciodata curatate; nu se vad din SQL, doar cu -Disc.
• Alert log / trace / incident (diagnostic_dest) — se purja cu adrci purge.
• FRA plina cu log_mode=ARCHIVELOG → ORA-00257/ORA-19809; baza se blocheaza brusc, fara eroare vizibila in aplicatie.
• Recyclebin, UNDO umflat, istoric statistici/scheduler, TEMP.
• Tabele de log ale aplicatiei care cresc nelimitat (tiparul SYS.INFO de pe SIGMA) — apar in raportul de top segmente, numele difera per client.

Cazuri

• Rompetrol Energy (XE 21c): ORA-12954, limita de 12 GB pe dba_data_files atinsa. SYSAUX umflat la 7.8 GB din SQL Tuning Sets (~5 GB) + AWR + audit policies. TRUNCATE wri$_sqlset_* a eliberat segmentele, dar RESIZE a picat cu ORA-03297 (SYSAUX nu se shrink pe XE 21c) → singura solutie a fost recrearea PDB-ului, 13.5 GB → 3 GB. Detalii: E:\proiecte\ROMFASTSQL\proxmox\lxc108-oracle\clienti\oracle-xe-21c\ (README.md, depanare-ora-12954-spatiu.md).
• ROA_CENTRAL (ORA-65114, 02.08.2026): acelasi tipar, rezolvat prin curatenie tintita in loc de recreare PDB; SQL-uri gata scrise in acelasi repo (docs/curatenie-spatiu-oracle.sql).
• SIGMA (03.08.2026): SYSTEM plafonat la 600 MB — vezi depanare-pack-update.md.

Capcane

• Privilegiile ANY nu se aplica pe obiectele din schema SYS cat timp O7_DICTIONARY_ACCESSIBILITY=FALSE — orice curatare acolo cere SYSDBA.
• Parola SYS e de obicei cea generica (vezi COMUN\docs\local\oracle.md), dar nu la toti clientii (ex. ROMCONSTRUCT) — cand nu merge, se ia cu PACK_UPDATE.GetSchemaParola('SYS'). -SysPassword ramane optional: diagnosticul de baza merge complet fara el, doar sectiunile SYSDBA se sar.
• Rolurile nu se aplica in pachete cu drepturi de definitor: un pachet care refera static dba_*/v$* iese INVALID la clientul care are accesul doar prin rolul DBA, chiar daca aceleasi interogari merg din SQL*Plus. De aceea granturile directe din sys_2026_08_03_05. Lantul de actualizare nu se opreste in acest caz: sqlplus iese cu cod 0 la eroare de compilare, deci se vede doar ca pachet invalid + job cazut.
• Curatenia poate esua din lipsa de spatiu (DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL a picat asa la Rompetrol): intai ridici plafonul, apoi cureti.
• RESIZE pe datafile da ORA-03297 daca extentele folosite nu sunt la coada fisierului — un DELETE fara MOVE/SHRINK nu recupereaza MB.
• Dimensiunile reale ale fisierelor de pe disc nu se vad din SQL — -Disc, prin ExecuteScriptOS.
• -Disc merge doar pe servere Windows (ExecuteScriptOS lanseaza PowerShell). Pe Linux expira curat dupa 60s, cu mesaj.
• MAX_PDB_STORAGE se citeste doar de pe un alias care tinteste radacina CDB. De pe un serviciu de PDB (cazul obisnuit al aliasurilor din tnsnames.ora), alter session set container=CDB$ROOT da ORA-01031 — e nevoie de un alias separat spre radacina.