docs(clienti): index ROMPETROL ENERGY ORA-12954 PDB recreation case

Add a top-level case index at lxc108-oracle/clienti/README.md and a
narrative README inside oracle-xe-21c/ that names ROMPETROL ENERGY
explicitly, describes symptom -> diagnostic -> what failed -> what
worked, and lists each numbered SQL with its role in the import phases.

Wire the case into discoverable entry points:
- proxmox/lxc108-oracle/README.md: new "clienti/" subsection
- proxmox/README.md: tree + nav links
- /workspace/romfastsql/CLAUDE.md: entry points

Future "Rompetrol Energy" / "ORA-12954" / "recreare PDB" searches now hit
the docs from the master indices instead of via grep on schema name.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Agent
2026-04-25 19:48:18 +00:00
parent e852df1a59
commit 2ee51c7318
5 changed files with 203 additions and 0 deletions

View File

@@ -841,6 +841,17 @@ SQL> SELECT username FROM dba_users; -- arată userii din ROA
## 📂 Subdirectoare
### clienti/
Cazuri concrete de depanare / migrare bază de date la clienți, cu scripturi
reutilizabile generate din fiecare incident.
| Caz | Director | Scop |
|-----|----------|------|
| **ROMPETROL ENERGY** (schemă `ROMPETROLE`) | `clienti/oracle-xe-21c/` | Recreare PDB Oracle XE 21c după ORA-12954 (12 GB depășiți) — diagnostic SYSAUX, drop+recreate PDB din `PDB$SEED`, reimport scheme |
**Documentație:** [`clienti/README.md`](clienti/README.md) (index general)
și [`clienti/oracle-xe-21c/README.md`](clienti/oracle-xe-21c/README.md) (cazul ROMPETROL).
### migration/
Scripturi pentru migrarea Oracle 10g → 21c XE:
- `00-MASTER-MIGRATION.sh` - Script master orchestrare migrare

View File

@@ -0,0 +1,27 @@
# Cazuri clienți — istoric depanare Oracle
Index al cazurilor concrete de depanare / migrare / recreare bază de date
întâlnite în producție la clienți. Conține diagnosticul, soluția aplicată și
scripturile reutilizabile generate din fiecare caz.
## Cazuri documentate
| Client | Schemă | Problemă | Soluție | Director |
|--------|--------|----------|---------|----------|
| **ROMPETROL ENERGY** | `ROMPETROLE` | Oracle XE 21c CDB plin (ORA-12954, limita 12 GB) — SYSAUX umflat de SQL Tuning Sets, AWR, audit policies. Cleanup parțial nu a recuperat spațiul (datafile-uri nu s-au putut shrink-ui). | Recreare PDB `XEPDB1` din `PDB$SEED` + reimport scheme cu `remap_tablespace=USERS:ROA`. Total alocat: 13.5 GB → ~3 GB. | [`oracle-xe-21c/`](oracle-xe-21c/) |
## Convenție
Fiecare caz are propriul director cu:
- `README.md` — narațiune (simptom → diagnostic → ce s-a încercat → ce a mers → rezultat)
- documente de referință tehnică (`depanare-*.md`)
- scripturi/SQL-uri reutilizabile
Materialul e **generic-izat** (numele schemei rămâne, dar parolele, datele clientului
sunt înlocuite cu placeholdere). Scripturile pot fi rulate la următorul client cu
aceeași problemă, doar înlocuind valori în config.
---
**Last Updated:** 2026-04-25

View File

@@ -0,0 +1,157 @@
# ROMPETROL ENERGY — Recreare PDB Oracle XE 21c după ORA-12954
**Client:** ROMPETROL ENERGY
**Schemă aplicație:** `ROMPETROLE` (parolă inițială: `ROMFASTSOFT`)
**Bază de date:** Oracle XE 21c (CDB `XE` + PDB `XEPDB1`) pe Windows
**Stadiu:** rezolvat — PDB recreat, total alocat redus de la 13.5 GB la ~3 GB
## Simptom
Aplicația nu mai putea scrie în baza de date. La operații de DML / cleanup:
```
ORA-12954: The request exceeds the maximum allowed database size of 12 GB.
```
Inclusiv `DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL` eșua cu același cod, deci
nici curățarea audit trail-ului nu mai era posibilă în-place.
## Diagnostic
Limita 12 GB a Oracle XE se aplică pe **suma `dba_data_files`** (spațiu alocat),
nu pe `dba_segments` (spațiu efectiv folosit). Datafile-urile pot fi 90% goale
și tot să atingă limita.
Distribuție găsită la diagnostic:
| Componentă | Alocat |
|------------|--------|
| SYSAUX | 7.8 GB (segmente reale: 7.5 GB) |
| UNDOTBS1 | 2.1 GB |
| SYSTEM + alte | rest |
| **Total** | **~13.5 GB** (peste limită) |
Cauze SYSAUX umflat (în ordinea impactului):
1. **SQL Tuning Sets** (`wri$_sqlset_*`) — ~5 GB acumulat
2. **AWR snapshots** — retention default + moving window baseline 8 zile
3. **Audit policies** active (`ORA_SECURECONFIG`, `ORA_LOGON_FAILURES`) →
AUDSYS umflat în PDB nou creat din `PDB$SEED`
4. **Auto tasks** (`sql tuning advisor`, `auto space advisor`) regenerează
constant date
Vezi [`depanare-ora-12954-spatiu.md`](depanare-ora-12954-spatiu.md) pentru
queries-le de diagnostic.
## Ce s-a încercat (parțial)
1. `DROP` pe SQL Tuning Sets via `DBMS_SQLTUNE.DROP_SQLSET` — nu a eliberat
spațiul LOB-ului. **`TRUNCATE` direct pe `wri$_sqlset_*`** a funcționat.
2. `DBMS_ADVISOR.DELETE_EXPIRED_TASKS`, `MODIFY_SNAPSHOT_SETTINGS`,
`PURGE_STATS`, `PURGE DBA_RECYCLEBIN` — au eliberat segmentele.
3. `ALTER DATABASE DATAFILE ... RESIZE` pe SYSAUX — **eșec ORA-03297** (used
data beyond resize value). Pe XE 21c nu există `ALTER TABLESPACE ... SHRINK`
(apare doar din 23ai). Segmentele SYSAUX erau la high water mark și nu
puteau fi compactate.
4. `UNDOTBS1` — soluționat prin recreare (drop tablespace + recreate cu
datafile mic). Funcționează pentru UNDO, NU și pentru SYSAUX.
**Concluzie:** SYSAUX nu se poate shrink-ui pe XE 21c → singura soluție
definitivă = **recrearea PDB-ului**.
## Soluție: recreare PDB + reimport
Pași (orchestrator: [`import/recreare_pdb.sql`](import/recreare_pdb.sql)):
1. **Export** din PDB-ul vechi (înainte de orice DROP):
- `expdp` Data Pump pentru schemele aplicației: `CONTAFIN_ORACLE`,
`ROMPETROLE`
- `expdp` separat pentru tabele SYS custom (`SYS.AUTH_SERII`,
`SYS.AUTH_DETALII`, `SYS.INFO`)
- `export_pdb_complet.sql` din SQLPlus pentru obiectele de cod SYS
(packages, views, triggers, context) care nu se pot exporta cu Data Pump
2. **DROP PLUGGABLE DATABASE** `XEPDB1 INCLUDING DATAFILES` din `CDB$ROOT`
3. **CREATE PLUGGABLE DATABASE** `XEPDB1` din `PDB$SEED` cu admin user nou
4. **Faza 1 import** ([`import/11_import_master.sql`](import/11_import_master.sql)) —
infrastructură care trebuie să existe înainte de Data Pump:
tablespaces (01) → useri (02) → directories (03) → tabele SYS (04) →
context (08)
5. **Data Pump impdp** scheme aplicație cu
`remap_tablespace=USERS:ROA` (PDB-ul nou din seed nu are tablespace USERS)
6. **Data Pump impdp** tabele SYS custom cu `table_exists_action=APPEND`
7. **Faza 2 import** ([`import/11_import_master_faza2.sql`](import/11_import_master_faza2.sql)) —
obiecte dependente de date: cod SYS (05) → views (06) → triggers (07) →
granturi (09) → sinonime publice (10)
8. **Recompilare**`DBMS_UTILITY.COMPILE_SCHEMA` pentru `CONTAFIN_ORACLE`,
`ROMPETROLE`, `SYS`
9. **Prevenție** — dezactivare auto tasks, retention AWR la min 8 zile,
`NOAUDIT POLICY` pe `ORA_SECURECONFIG` și `ORA_LOGON_FAILURES`
## Rezultat
| Componentă | Înainte | După recreare PDB |
|-----------|---------|-------------------|
| SYSAUX | 7.8 GB | 390 MB |
| SYSTEM | — | 370 MB |
| ROA | — | 2 GB |
| UNDOTBS1 | 2.1 GB | 165 MB |
| **Total alocat** | **13.5 GB** | **~3 GB** |
Marjă recâștigată față de limita 12 GB: ~9 GB.
## Scripturi în acest director
| Fișier | Scop |
|--------|------|
| [`depanare-ora-12954-spatiu.md`](depanare-ora-12954-spatiu.md) | Ghid complet ORA-12954: diagnostic, cleanup, resize, gotcha-uri Oracle XE 21c |
| [`import/recreare_pdb.sql`](import/recreare_pdb.sql) | Orchestrator (drop PDB → recreate → faze import) |
| [`import/export_pdb_complet.sql`](import/export_pdb_complet.sql) | Export obiecte SYS care nu merg via Data Pump |
| [`import/01_tablespaces.sql`](import/01_tablespaces.sql) | Faza 1.1: ROA tablespace |
| [`import/02_useri.sql`](import/02_useri.sql) | Faza 1.2: `CONTAFIN_ORACLE`, `ROMPETROLE` |
| [`import/03_directories.sql`](import/03_directories.sql) | Faza 1.3: DIRECTORY objects |
| [`import/04_sys_tables.sql`](import/04_sys_tables.sql) | Faza 1.4: tabele SYS custom |
| [`import/05_sys_code_objects.sql`](import/05_sys_code_objects.sql) | Faza 2.1: packages SYS |
| [`import/06_sys_views.sql`](import/06_sys_views.sql) | Faza 2.2: views SYS |
| [`import/07_sys_triggers.sql`](import/07_sys_triggers.sql) | Faza 2.3: triggere SYS |
| [`import/08_context.sql`](import/08_context.sql) | Faza 1.5: application context |
| [`import/09_granturi.sql`](import/09_granturi.sql) | Faza 2.4: granturi |
| [`import/10_sinonime_publice.sql`](import/10_sinonime_publice.sql) | Faza 2.5: sinonime publice |
| [`import/11_import_master.sql`](import/11_import_master.sql) | Faza 1 master (rulează 01 → 04, 08) |
| [`import/11_import_master_faza2.sql`](import/11_import_master_faza2.sql) | Faza 2 master (rulează 05 → 07, 09 → 10) + verificare |
| [`import/cleanup_audit.sql`](import/cleanup_audit.sql) | Curățare audit trail (rulează doar dacă DB-ul nu e plin) |
## Reutilizare la alți clienți
Scripturile sunt parametrizate la nivel de schemă aplicație. Pentru un client
nou cu aceeași problemă (Oracle XE 21c plin):
1. Adaptează `02_useri.sql` cu noua schemă (înlocuiește `ROMPETROLE`)
2. Adaptează `04_sys_tables.sql` și `09_granturi.sql` la nevoie
3. Rulează exportul, apoi `recreare_pdb.sql` pas cu pas
4. La pasul de prevenție, **rulează imediat** `NOAUDIT POLICY` și
`DBMS_AUTO_TASK_ADMIN.DISABLE` — dacă lași PDB-ul nou în default, problema
reapare în câteva luni
## Lecții învățate
1. **TRUNCATE > DROP pe SQL Tuning Sets** — DROP nu eliberează LOB-ul.
2. **Limita 12 GB = `dba_data_files`** — segmentele pot fi mici, contează
spațiul alocat.
3. **SYSAUX nu se poate shrink** pe XE 21c (fără 23ai). Singura ieșire =
recreare PDB.
4. **AWR retention >= 8 zile** — moving window baseline default e 8 zile,
nu poți seta sub fără să modifici baseline-ul (care nu există ca procedură
pe XE 21c).
5. **PDB nou din `PDB$SEED` are audit policies active**`ORA_SECURECONFIG`
și `ORA_LOGON_FAILURES` umflă AUDSYS rapid. Dezactivare imediat după CREATE.
6. **`DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL` eșuează când DB-ul e plin** — chiar
și în restricted mode. Prevenția > intervenția.
7. **PDB nou nu are tablespace `USERS`** — toate impdp-urile cu obiecte pe
USERS necesită `remap_tablespace=USERS:ROA`.
8. **Pe Windows, `AS SYSDBA` în impdp/expdp** trebuie inclus în ghilimelele
conexiunii: `expdp "sys/...@XEPDB1 AS SYSDBA" ...`
---
**Last Updated:** 2026-04-25
**Autor depanare:** Marius Mutu