skills: 9 skill-uri de agent ROA (COMUN\skills) + legare si rutare
- leaga_skills.ps1: expune skill-urile in ~/.claude/skills prin symlink (citit si de Claude Code, si de opencode), fara copiere - rutare zona->skill in reguli_lucru pct. 7, README, AGENTS.md; skill-ul devine proprietarul procedurii, docurile raman referinta conditionata - rec_skills.md: decizia, inventarul si cum se adauga un skill nou
This commit is contained in:
92
skills/roa-oracle-diagnostic/SKILL.md
Normal file
92
skills/roa-oracle-diagnostic/SKILL.md
Normal file
@@ -0,0 +1,92 @@
|
||||
---
|
||||
name: roa-oracle-diagnostic
|
||||
description: Diagnostic read-only pentru doua incidente de productie la clientii ROA - actualizarea automata (PACK_UPDATE) care nu se termina si tablespace-ul/discul Oracle plin. Foloseste-l OBLIGATORIU cand utilizatorul spune "actualizarea nu se termina la clientul X", "a ramas blocat la pasul 3", "update-ul nu a mers azi", "verifica de ce n-a mers update-ul", "clientul are baza plina", "spatiu insuficient la client", "ORA-01653", "ORA-01654", "nu mai pot salva in baza", "tablespace plin" sau cere sa verifici de ce a esuat o actualizare. Ruleaza intai scriptul de diagnostic dedicat, citeste dovada exacta (starea rularii, scriptul candidat, consumatorul de spatiu, procentul tablespace-ului) si abia apoi da verdictul. Nu improviza interogari manuale, nu relansa update-ul si nu rula curatare pana nu stii pasul exact unde s-a oprit.
|
||||
---
|
||||
|
||||
# Diagnostic ROA: actualizare blocata si spatiu Oracle plin
|
||||
|
||||
Doua incidente, acelasi tipar: simptomul din aplicatie nu spune cauza. Fie actualizarea nu se
|
||||
termina (`stare=3` fara `dataora_end`, log mut), fie baza/discul e plin (`ORA-01653`/`ORA-01654`,
|
||||
blocaj brusc). Diagnostic STRICT read-only: se identifica pasul/consumatorul exact si se propune deblocarea.
|
||||
|
||||
## Cand se foloseste
|
||||
|
||||
- "actualizarea nu se termina la clientul X", "a ramas la pasul 3", "update-ul nu a mers azi";
|
||||
- "verifica de ce n-a mers actualizarea", "de ce nu s-a actualizat baza la client";
|
||||
- "clientul are baza plina", "spatiu insuficient", "ORA-01653", "ORA-01654", "ORA-00257";
|
||||
- orice cerere de a verifica o actualizare esuata sau un tablespace/disk plin la un client; nu
|
||||
improviza interogari si nu relansa update-ul inainte de verdictul scriptului.
|
||||
|
||||
## Pasi
|
||||
|
||||
Ambele: intai conexiunea (tunel SSH pe 1521 + alias TNS pe `127.0.0.1` in
|
||||
`D:\ROA\instantclient_19_18\tnsnames.ora`, user `contafin_oracle`), apoi scriptul dedicat.
|
||||
|
||||
A. Actualizarea nu se termina (job `UPDATEROA_ZILNIC` -> `PACK_UPDATE.UpdateROA`):
|
||||
1. Ruleaza `diag_actualizare.ps1 -Alias <ALIAS>` si citeste verdictul: pana unde a ajuns si unde e
|
||||
eroarea. Lantul e secvential, o etapa picata le opreste pe toate: UpdateApp -> UpdateScripts ->
|
||||
UpdateDatabaseSqlPlus.
|
||||
2. `UPD_ISTORIC`: `stare` (0=start, 1=aplicatii, 2=scripturi, 3=aplicare, 4=incheiat) si
|
||||
`dataora_end` gol = neincheiata; un sir oprit la aceeasi `stare` arata etapa vinovata.
|
||||
3. `UPD_LOG`: `dataora_start` = rularea, `secventa`+`dataora` = ordinea, `explicatie` (CLOB) =
|
||||
cauza reala. Se goleste la fiecare rulare - iei logul curent sau relansezi ca sa-l reproduce.
|
||||
4. Versiuni: `UPD_DATABASE.script_date` vs `<schema>.VERSIUNE.data_script`. La `stare=3` fara
|
||||
`dataora_end` cu `VERSIUNE` blocat, candidatul e primul script `UPD_DATABASE` neaplicat.
|
||||
5. `script_master.log` in `DMPDIR` (`C:\DMPDIR`) pe server = mesajul real al aplicarii. Eroarea
|
||||
de aici NU ajunge in `UPD_LOG`; se citeste si prin `UTL_FILE` fara RDP (util e la sfarsit).
|
||||
6. Descarcare: daca etapa 1 a picat, verifica intai folderul Oracle `UPD_<PROGRAM>` pe disc
|
||||
(`dbms_lob.fileexists(bfilename(...))`) si `all_directories like 'UPD%'`, nu reteaua.
|
||||
7. `GetStare` refuza o rulare noua cat timp precedenta e neincheiata si n-a trecut o ora.
|
||||
Deblocarea e doar sugestie - nu o executa fara acordul explicit.
|
||||
|
||||
B. Spatiu Oracle plin:
|
||||
1. Ruleaza `diag_spatiu.ps1 -Alias <ALIAS> -Disc` (cu `-Disc` doar pe servere Windows) si citeste
|
||||
verdictul plus topul segmentelor.
|
||||
2. Tablespace + datafile: ce e plin, `maxbytes` vs `bytes`, cat mai poate creste. Un `maxbytes`
|
||||
sub XE 11/12 GB nu e limita XE - e plafon pus la instalare.
|
||||
3. Top consumatori: tablespace cu `maxbytes` atins, `SYSAUX` (SQL Tuning Sets/AWR/audit), fisiere
|
||||
`.aud` din `adump` (NU se vad din SQL, doar cu `-Disc`), alert log/trace/ADR, FRA plina cu
|
||||
`ARCHIVELOG` (`ORA-00257`/`ORA-19809`), recyclebin/UNDO/TEMP, logurile aplicatiei care cresc.
|
||||
4. Daca eroarea de actualizare nu priveste obiectele atinse de script, suspecteaza intai spatiul
|
||||
(ex. `ORA-01653 table SYS.INFO in tablespace SYSTEM`, ridicata din `SYS.PINFO`).
|
||||
|
||||
Cand A si B se intersecteaza, verdictul leaga scriptul candidat de tablespace-ul plin.
|
||||
|
||||
## Capcane
|
||||
|
||||
- `UPD_LOG` se goleste la fiecare rulare - nu ai istoric; altfel relansezi orbeste.
|
||||
- Eroarea din `additional_info`-ul jobului e de obicei falsa: `EmailLog` ridica `ORA-20000` (SMTP
|
||||
picat) si mascheaza eroarea originala. Cauza adevarata e in `UPD_LOG`.
|
||||
- UpdateApp abandoneaza TOT la primul program nedescarcat (`CT_INSUCCES`): un fisier indisponibil
|
||||
blocheaza la infinit, tacut (`Fisierul NU s-a salvat pe disc.`). Verifica folderul, nu reteaua.
|
||||
- Ordinea de citit cand actualizarea e muta: `UPD_ISTORIC` -> `UPD_LOG` -> `script_master.log`;
|
||||
daca sari direct la logul de SQL, nu stii pe ce schema si pe ce rulare te uiti.
|
||||
- Erorile de script fac `UPD_LOG` curat (`WHENEVER SQLERROR EXIT ... ROLLBACK`); semnul e
|
||||
`stare=3` fara `dataora_end` + `VERSIUNE` blocat. Mesajul real e doar in `script_master.log`.
|
||||
- `adrci purge` si `alter database datafile ... autoextend` sunt DOAR sugestii afisate; nu le rula
|
||||
automat si niciodata fara acordul explicit al utilizatorului.
|
||||
- La clienti Oracle 10g lipsesc coloane din `dba_scheduler_*` - foloseste `dba_scheduler_job_run_details`.
|
||||
- `-Disc` scrie un `.ps1` temporar in `DMPDIR`; pe Linux expira dupa 60s cu mesaj.
|
||||
|
||||
## Criterii de acceptare si dovada
|
||||
|
||||
Fara dovezile de mai jos nu exista verdict; diagnosticul NU se raporteaza ca terminat.
|
||||
|
||||
1. Verdictul scriptului e citat. Ramura A: `stare` + `dataora_end` din `UPD_ISTORIC` si linia
|
||||
exacta din `UPD_LOG`/`script_master.log`. Ramura B: procentul tablespace-ului vinovat + `maxbytes`.
|
||||
2. Scriptul candidat e numit exact (primul din `UPD_DATABASE` de dupa ultima versiune), nu
|
||||
"undeva in etapa 3".
|
||||
3. Dovada e legata de obiectele reale: daca mesajul Oracle nu priveste ce atinge scriptul, s-a
|
||||
dovedit spatiul (procent + plafon), nu scriptul.
|
||||
4. Deblocarea propusa e scrisa ca sugestie cu comanda exacta, neexecutata.
|
||||
|
||||
## Scripturi
|
||||
|
||||
- `D:\ROA\ROAFACTURARE\COMUN\utile\diag_actualizare.ps1`
|
||||
`powershell -File D:\ROA\ROAFACTURARE\COMUN\utile\diag_actualizare.ps1 -Alias <ALIAS> [-DoarLog] [-Disc]`
|
||||
- `D:\ROA\ROAFACTURARE\COMUN\utile\diag_spatiu.ps1`
|
||||
`powershell -File D:\ROA\ROAFACTURARE\COMUN\utile\diag_spatiu.ps1 -Alias <ALIAS> [-Disc] [-SysPassword <parola>] [-Top 30]`
|
||||
|
||||
## Referinta (doar la nevoie)
|
||||
|
||||
- Doar daca ramura A (actualizare) sau ramura B (spatiu) cere detalii, citeste `COMUN\docs\depanare-pack-update.md` si `COMUN\docs\depanare-spatiu-oracle.md`.
|
||||
Reference in New Issue
Block a user