7fce925349
Blocul de instalare/migrare Oracle 21c XE, terminat si validat pe VM 302. Kit de instalare (nou) scripts/build-client-kit.ps1 exporta CONTAFIN_ORACLE si FIRMANOUA de pe LXC 108 (PDB ROA2, nu ROA - ROA e productia ROA_CENTRAL), le aduce local prin cele trei hopuri container -> LXC -> host -> statie, le redenumeste la numele pe care le asteapta scripturile si le impacheteaza cu o copie a directorului roa-windows-setup. Citeste logul expdp si raporteaza cate firme are NOM_FIRME, ca sa nu plece din greseala datele unui client. roa-windows-setup/INSTALEAZA.cmd ruleaza pasii 01..08 fara "set /p", deci merge si prin SSH - RunAll.cmd nu poate fi rulat neinteractiv. Trateaza corect codul 5 de la pasul 03 si se opreste la prima eroare reala. Corectii 01-setup-database.ps1 nu mai scrie SQLNET.RECV_TIMEOUT / SEND_TIMEOUT in sqlnet.ora. Le hardcoda la 30 s, iar fisierul e citit si de impdp: in timpul unui import serverul poate lucra minute fara sa trimita un pachet, clientul murea cu ORA-12609 iar scriptul raporta esec pentru un import care se terminase cu bine pe server. Reprodus si reparat pe VM 302. 01-setup-database.ps1: Step 4c optional (-ResetSystemPassword) care curata EXPIRED(GRACE) pe SYSTEM in CDB root; ALTER PROFILE opreste expirarile viitoare dar nu reseteaza un cont deja intrat in gratie. uninstall-roa.sql: retry la DROP USER dupa KILL SESSION, plus un bloc final de verdict care numara ce a ramas si iese cu ORA-20900 daca baza nu e curata. Pana acum toate sectiunile prindeau exceptiile in WHEN OTHERS si scriptul tiparea "UNINSTALL COMPLETE" chiar si cand un user supravietuise, iar instalarea urmatoare dadea ORA-31684 in lant. 99-uninstall-roa.ps1 propaga codul de iesire. 08-post-install-config.ps1: Step 7b seteaza SMTP_OUT_SERVER si ACL-ul de retea pentru CONTAFIN_ORACLE. UTL_MAIL se instala si primea EXECUTE, adica destul cat sa compileze, dar nu si cat sa trimita. Privilegiul resolve nu accepta interval de porturi (ORA-24244), deci se acorda separat de connect. 07-verify-installation.ps1: sectiune noua care verifica prezenta lui FIRMANOUA.dmp in DMPDIR si o raporteaza ca eroare daca lipseste. Fara el, adaugarea unei firme noi pica in DBMS_DATAPUMP.ADD_FILE peste luni de la instalare, cand nimeni nu mai leaga eroarea de instalare. configure-profile.sql: antetul spune ca e unealta de remediere manuala, nu parte din flux; pas nou la final pentru CDB root. Documentatie README-ul roa-windows-setup descrie acum explicit cele doua scenarii - instalare pe curat si migrare - de unde se iau DMP-urile sablon, si capcana ORA-12609. Handoff-urile de sesiune au fost sterse; ce era durabil in ele a intrat in README-uri si in docs/diagnostic-spatiu-clienti.md. Validare pe VM 302: ciclu complet din kit, instalare pe curat, verificarea finala "[OK] All checks passed!". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
358 lines
19 KiB
Markdown
358 lines
19 KiB
Markdown
# 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
|
||
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):
|
||
|
||
```powershell
|
||
$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).
|
||
|
||
```powershell
|
||
# 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):
|
||
|
||
```sql
|
||
-- 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`
|
||
|
||
```sql
|
||
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 |
|
||
|
||
```sql
|
||
-- 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`
|
||
(SVN r18010) face acelasi lucru pe bazele deja instalate, in doi pasi: **recrearea** tabelei in
|
||
tablespace-ul `ROA` (`drop table sys.info purge` + `create ... tablespace ROA lob (info) store as
|
||
(tablespace ROA)`) → crearea jobului.
|
||
|
||
**Se recreeaza, nu se muta**: continutul e log fara valoare, iar `DROP`+`CREATE` nu cere spatiu
|
||
liber cat segmentul si nu tine tabela blocata cat ar dura copierea. `DROP` e cu `PURGE`, altfel
|
||
segmentul ramane in recyclebin si spatiul nu se elibereaza. Daca `CREATE`-ul in `ROA` esueaza,
|
||
tabela se recreeaza in `SYSTEM`, ca sa existe intotdeauna; `SYS.pINFO` ramane `INVALID` dupa `drop`,
|
||
deci se recompileaza explicit (s-ar recompila si singura la primul apel).
|
||
|
||
Pasul 1 are `EXCEPTION WHEN OTHERS THEN NULL` **intentionat**: o eroare acolo 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 catre clienti** — publicarea se face cu `COMUN\utile\publicare_scripturi.ps1` si scrie
|
||
in `Y:\ROAUPDATE\_UPDATE\`, care e live pentru toti.
|
||
|
||
Pointeri incrucisati: [`00-INSTALL-ORACLE-XE.md`](../proxmox/lxc108-oracle/roa-windows-setup/docs/00-INSTALL-ORACLE-XE.md)
|
||
si [`00-INSTALL-ORACLE-SE.md`](../proxmox/lxc108-oracle/roa-windows-setup/docs/00-INSTALL-ORACLE-SE.md).
|
||
|
||
## 8b. Ramase de verificat (din blocul 08.08.2026)
|
||
|
||
- **`SYSTEM` verificat doar la `sigma` si `automotive`.** Ceilalti clienti nu au fost atinsi;
|
||
expeditorii cunoscuti sunt `roaupdate_acn@`, `roaupdate-clever@` (lista completa in sectiunea 3).
|
||
- **`ACN` — tacere de pe 06.08** dupa curatenie. Neconfirmat ca jobul mai ruleaza. Se verifica cu:
|
||
```sql
|
||
SELECT MAX(dataora) FROM contafin_oracle.diag_spatiu_log;
|
||
```
|
||
- **`UPDATEROA_ZILNIC.failure_count`** = 233 la AUTOMOTIVE, 47 la SIGMA, desi toate rularile din
|
||
ultimele 7 zile sunt `SUCCEEDED`. Pare contor istoric — neinvestigat, de urmarit, nu de reparat.
|
||
- **`SYS.AUTH_DETALII` si `SYS.AUTH_SERII` raman in `SYSTEM`** (`sys-objects.sql`, pasii `[1/11]`
|
||
si `[2/11]`). Nu cresc, nu s-au atins.
|
||
|
||
## 9. Legaturi in acest repo
|
||
|
||
| Document | Ce e |
|
||
|---|---|
|
||
| [`diagnostic-ora-65114-spatiu.md`](diagnostic-ora-65114-spatiu.md) | `ROA_CENTRAL`, 02.08.2026 — `ORA-65114`, topologia 10.0.20.121, ce trebuie masurat |
|
||
| [`curatenie-spatiu-oracle.sql`](curatenie-spatiu-oracle.sql) | SQL-uri gata scrise de curatenie tintita |
|
||
| [`../proxmox/lxc108-oracle/clienti/oracle-xe-21c/`](../proxmox/lxc108-oracle/clienti/oracle-xe-21c/) | ROMPETROL ENERGY — `ORA-12954`, recreare PDB (13.5 GB → 3 GB) |
|
||
| [`../proxmox/lxc108-oracle/clienti/README.md`](../proxmox/lxc108-oracle/clienti/README.md) | indexul cazurilor de client |
|
||
|
||
---
|
||
|
||
**Ultima actualizare:** 08.08.2026
|