romfast/comun
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
comun/docs/depanare-spatiu-oracle.md

8.1 KiB
Raw Permalink Blame History

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_08_DIAG_SPATIU_PACK + sys_2026_08_06_07_DIAG_SPATIU_GRANT3 (06.08.2026) scriu la top segmente si tabela/coloana din care provine segmentul (DetaliuSegment: DBA_LOBS, DBA_LOB_PARTITIONS, DBA_INDEXES; segmentele temporare se marcheaza ca atare) — fara asta un SYS_LOB0000630560C00017$$ de 4 GB in email nu spune nimic, iar serverul clientului nu e accesibil direct. Atentie: pentru LOB PARTITION, dba_segments.segment_name e lob_name, nu lob_partition_name.

Emailurile ajung pe marius.mutu@romfast.ro, cate un expeditor per client (roaupdate_<client>@romfast.ro); citirea lor: email-thunderbird.md.

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

  • Segmentele TEMPORARY dintr-un tablespace permanent nu dispar intotdeauna la restart (ACN, 06.08.2026: 1.3 GB ramasi si dupa repornirea serviciului). Daca v$sort_usage e gol, sunt orfane si se curata fortat, ca SYS: alter session set events 'immediate trace name DROP_SEGMENTS level <ts#+1>' (ts# din v$tablespace) — la ACN au disparut instantaneu, cu tot spatiul recuperat. Daca nici asa nu pleaca, apartin unui DDL neterminat — cauta SYS_JOURNAL% (index online) sau obiecte INVALID/UNUSABLE in schema respectiva.
  • shrink space pe un LOB cere ASSM; pe un tablespace MSSM da ORA-10635 (cazul ROA la ACN). Echivalentul care merge: alter table t move lob (col) store as (tablespace <ts>) — reconstruieste segmentul, tine tabela blocata cat dureaza si cere spatiu liber cat segmentul mutat.
  • 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.