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
This commit is contained in:
2026-08-03 12:11:29 +03:00
parent 5f3a17c5c7
commit 48f15c1da1
6 changed files with 1473 additions and 2 deletions

View File

@@ -5,6 +5,16 @@ Actualizarea automata a aplicatiilor si a bazei ruleaza din jobul `CONTAFIN_ORAC
**UpdateScripts** (umple `UPD_DATABASE`) -> **UpdateDatabaseSqlPlus** (aplica scripturile pe scheme).
O etapa esuata le opreste pe toate urmatoarele.
## Scriptul de diagnostic
`COMUN\utile\diag_actualizare.ps1 -Alias <ALIAS_TNS>` ruleaza tot lantul de mai jos si scoate un
verdict (unde a ramas rularea, care e scriptul candidat, unde e eroarea). Strict read-only; `-Disc`
adauga verificarea spatiului pe discurile serverului (singura parte care scrie ceva — un `.ps1`
temporar in `DMPDIR`). Foloseste-l intai; sectiunile de mai jos explica ce citeste si de ce.
Cand cauza e spatiul (tablespace plin, audit/loguri Oracle care umplu discul), continua cu
`depanare-spatiu-oracle.md` si `COMUN\utile\diag_spatiu.ps1`.
## Unde te uiti, in ordine
| Ce | Unde |
@@ -52,6 +62,31 @@ Fisierul se poate citi si fara acces la desktopul serverului, prin `UTL_FILE` pe
`DMPDIR` (`fopen(...,'R',32767)` + `get_line` in bucla; tine ultimele N linii intr-un tablou —
partea utila e la sfarsit).
### Caz: nu orice esec de script e o problema de SQL (SIGMA, 03.08.2026)
`ff_2026_07_29_02_COMUN_TVA11.SQL` a picat pe `MARCU` cu `ORA-01653: unable to extend table
SYS.INFO ... in tablespace SYSTEM` (din `SYS.PINFO`/`SYS.AUTH_PACK`, recursiv). Tablespace-ul
`SYSTEM` era plin: autoextensibil, dar cu `maxbytes` atins la 600 MB, ~2 MB liberi. **Orice**
script ar fi picat identic — `AUTH_PACK` scrie in `SYS.INFO` la fiecare conectare. Cand eroarea nu
priveste obiectele scriptului, verifica intai spatiul.
Ce a contat, pentru data viitoare:
- **`maxbytes` mic nu e o limita XE.** Cele 11 GB ale XE sunt pe *date utilizator*; un plafon mic pe
`SYSTEM.DBF` e o setare de instalare. Se ridica din `contafin_oracle` (are `ALTER DATABASE`):
`alter database datafile '<cale>\SYSTEM.DBF' autoextend on next 50M maxsize 2000M;`
- **Spatiul pe discul serverului se verifica fara RDP**, cu `sys.ExecuteScriptOS` (vezi mai jos) —
`Get-WmiObject Win32_LogicalDisk -Filter "DriveType=3"`, iesire in `DMPDIR`, citita cu `UTL_FILE`.
Job asincron, dar raspunde in cateva secunde.
- **`SYS.INFO` e tabel ROA, nu obiect de dictionar** (log de login scris de `PINFO`, ~7 randuri per
conectare, +16-17k randuri/luna, nimic din baza nu-l citeste). Se poate goli, **dar numai ca
`SYSDBA`**: privilegiile `ANY` (`DROP ANY TABLE`, `DELETE ANY TABLE`) nu se aplica pe obiectele
din schema `SYS` cat timp `O7_DICTIONARY_ACCESSIBILITY=FALSE`, deci din `contafin_oracle` iese
`ORA-01031`.
- Restul lui `SYSTEM` era dictionar Oracle (`IDL_UB1$`, `SOURCE$`, `IDL_UB2$`, `ARGUMENT$` ~207 MB) —
de neatins fara export/import. `AUD$`/`FGA_LOG$` erau goale. Recyclebin-ul si bloat-ul de scheduler
stateau in `ROA`/`SYSAUX`, nu in `SYSTEM`.
## Descarcarea (UpdateApp)
Cu `server_info.POWERSHELLDOWNLOAD = '1'`, `PACK_UTILS.DownloadFileOS` scrie un `.ps1` cu `curl` in

View File

@@ -0,0 +1,55 @@
# Depanare spatiu Oracle la clienti
```powershell
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.