romfast/comun
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
48f15c1da1a1f8b87ee4d90fcbeda83a018eac87
comun/docs/depanare-spatiu-oracle.md
Marius Mutu 48f15c1da1 scripturi de diagnostic baza de date + script de livrare 
- diag_actualizare.ps1: de ce s-a oprit actualizarea (UPD_ISTORIC, UPD_LOG,
  script_master.log prin UTL_FILE, versiuni per schema, spatiu tablespace, verdict)
- diag_spatiu.ps1: spatiu Oracle la clienti (tablespace, audit, ADR, FRA, disc server)
- livrare.ps1: git_sync + curatenie + verificari + commit/push
- curatenie.ps1: sterge si docs\propuneri_*.md
- docs: depanare-spatiu-oracle.md nou, depanare-pack-update.md completat cu cazul SIGMA

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014sNn6dmAimtyXkDU4frJrh
2026-08-03 12:11:42 +03:00

3.3 KiB
Raw 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.

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 difera de la server la server. -SysPassword e optional; diagnosticul de baza merge complet fara el, doar sectiunile SYSDBA se sar.
  • 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.