Marius Mutu
be37c2c99c
Niciun ';' la capat de linie intr-un comentariu '--' din interiorul unei instructiuni
(SQL*Plus termina instructiunea acolo, chiar daca ';'-ul e in comentariu). Fiecare
script se incheie cu exec pack_migrare.UpdateVersiune('<nume_script>'); urmat de
commit; (UpdateVersiune e DML, fara commit explicit VERSIUNE minte despre ce s-a aplicat).
132 lines
7.9 KiB
Markdown
132 lines
7.9 KiB
Markdown
# Scripturi migrare baza de date Oracle
|
|
|
|
Scripturile de migrare a schemei (si modelele pentru scripturi noi) sunt in
|
|
`DATABASE\SCRIPTURI_CLAR` de sub radacina suitei ROA (`gcDirMare`/`dirgen` — ex.
|
|
`D:\ROA\DATABASE\SCRIPTURI_CLAR`). Sursa SVN: `http://svnroa:3001/svn/ROA/DATABASE/Branches/RB-1.00`.
|
|
Pentru un script nou, urmeaza formatul/conventiile celor recente de acolo. Publicarea catre clienti
|
|
(import in `UPD_DATABASE` + arhiva lunara): `publicare-scripturi-db.md`.
|
|
|
|
Reguli confirmate de Marius (24.07.2026):
|
|
|
|
- **Line-endings CRLF obligatoriu** in scripturile `.sql` — tool-urile agentului scriu implicit
|
|
LF; dupa orice scriere, verifica si converteste byte-safe LF -> CRLF (fara decodare/reincodare).
|
|
Parsarea pe fluxul ROA (ex. `ALINES` pe `CHR(13)+CHR(10)`) esueaza silentios pe LF: tot fisierul
|
|
devine un singur rand.
|
|
- `versiune_db.txt` (marker-ul `YYYY_MM_DD_NN` din radacina aplicatiei) se scrie fara newline la
|
|
final (conventia existenta).
|
|
- Aplicarea prin ODBC/`goExecutor`: sintaxa SQL*Plus `exec pachet.procedura(...)` nu functioneaza
|
|
— foloseste `begin pachet.procedura(...); end;`.
|
|
- **Niciun `;` la capat de linie intr-un comentariu `--` din interiorul unei instructiuni.** SQL*Plus
|
|
termina instructiunea acolo, chiar daca `;`-ul e in comentariu: restul `CREATE VIEW`-ului ajunge sa
|
|
fie interpretat linie cu linie ca si comenzi, cu zeci de `SP2-0734` si un `ORA-00936` derutant care
|
|
arata spre comentariu. Pus la sfarsit de fraza, `.` in loc de `;`. Comentariile de **dinaintea**
|
|
instructiunii nu sunt afectate.
|
|
- **Fiecare script se incheie cu `exec pack_migrare.UpdateVersiune('<nume_script>');` urmat de
|
|
`commit;`.** DDL-ul comite implicit, dar `UpdateVersiune` e DML: fara `commit` explicit, un script
|
|
se poate aplica fara ca versiunea sa se inregistreze, iar `VERSIUNE` ajunge sa minta despre ce s-a
|
|
aplicat.
|
|
- **Rularea manuala se face conectat pe schema tinta** (`CONTAFIN_ORACLE` pentru `co_`, schema firmei
|
|
pentru `ff_`), niciodata cu un user de lucru. DDL-ul neprefixat (`create or replace package ...`)
|
|
merge pe schema conexiunii: pe alt user iese `PLS-00304` si ramane un obiect orfan, iar pachetul
|
|
tinta ramane neschimbat. In acelasi script, DML-ul pe tabele cu sinonim public nimereste tabela
|
|
reala si pare ca totul a mers — verifica intotdeauna iesirea sqlplus si `all_objects`.
|
|
`PACK_UPDATE` face `CONNECT <schema>/<parola>@ROA` real per schema (`UpdateSchemaSQLPLUS`, parola
|
|
din `SERVER_INFO`), deci scriptul neprefixat e corect pentru livrare.
|
|
|
|
## Sursa de referinta pentru DDL: MARIUSM_AUTO, nu productia
|
|
|
|
Regula lui Marius (06.08.2026): **orice modificare de tabela, view, procedura, functie sau pachet se
|
|
scrie plecand de la sursa din schema de dezvoltare `MARIUSM_AUTO` (`ROA_CENTRAL`), niciodata de la
|
|
sursa citita dintr-o schema de client** (`VENDING`, `ACN`, ...). Schemele de client raman in urma:
|
|
pot avea scripturi neaplicate sau variante livrate separat (ex. pachetele `_10G_ROMCONSTRUCT`), iar o
|
|
modificare scrisa peste o sursa veche sterge corectii deja livrate.
|
|
|
|
Schemele de client raman utile doar pentru **masuratori pe date reale**, in citire.
|
|
|
|
### Verifica intai ca MARIUSM_AUTO e la zi
|
|
|
|
"Ultima versiune din dev" e ultima versiune doar daca toate scripturile din `SCRIPTURI_CLAR` chiar au
|
|
fost aplicate acolo. `pack_migrare.UpdateVersiune` inregistreaza fiecare script aplicat in tabela
|
|
`VERSIUNE` (`script_final` = numele fisierului, cu tot cu `.sql`), deci diferenta se vede direct:
|
|
|
|
```sql
|
|
select script_final, data_final from versiune order by data_script desc, seq_script desc;
|
|
```
|
|
|
|
```powershell
|
|
Get-ChildItem D:\ROA\DATABASE\SCRIPTURI_CLAR -Recurse -Filter *.sql |
|
|
Select-Object -ExpandProperty Name | Sort-Object
|
|
```
|
|
|
|
Daca lipsesc scripturi din `VERSIUNE`, **nu porni modificarea** pe sursa de acolo — semnaleaza-i lui
|
|
Marius ce nu e aplicat. Exportul sursei de referinta: `oracle_export.md`.
|
|
|
|
## Continutul unui script
|
|
|
|
- **Minimul necesar si intotdeauna SCOPED**: `update`/`insert` doar pe randurile cazului tratat
|
|
(setul, codul, firma anume), niciodata pe toate randurile care "seamana" cu el.
|
|
- **Fara `select` de raportare in script** — nu-l citeste nimeni la aplicare si poate da eroare.
|
|
Verificarile se fac inainte, separat, pe schema de lucru.
|
|
- **Idempotent**: rulat de doua ori nu mai schimba nimic (`merge`, `where <coloana> is null`).
|
|
- **Un pachet sta singur in scriptul lui**, fara alt DDL sau DML alaturi: modificarile de tabele si
|
|
curateniile de date merg in scripturi separate, cu numar propriu.
|
|
|
|
## Compatibilitate cu serverele clientilor
|
|
|
|
Serverul de dezvoltare e mai nou decat serverele clientilor, deci un script care trece local poate
|
|
pica la client si opri actualizarea.
|
|
|
|
Parcul de servere (03.08.2026): **un client pe Oracle 10.2** (ROMCONSTRUCT), cativa pe **XE 11 si
|
|
11g** standard, restul pe **XE 18/19/21 si 18/21**.
|
|
|
|
**Regula: orice script care ajunge in comune se scrie la nivelul Oracle 10.2 si trebuie sa ruleze pe
|
|
10.2 si pe 11.x.** Numitorul comun e 10.2 — nu se folosesc facilitati 11g si cu atat mai putin 12c+,
|
|
oricat de comod ar fi pe dev. Proba inainte de publicare se face pe serverul cel mai vechi
|
|
(ROMCONSTRUCT), nu pe dev.
|
|
|
|
Constructii care merg pe dev si pica mai jos:
|
|
|
|
| Constructie | Disponibila de la | Ce iese sub ea |
|
|
|---|---|---|
|
|
| identificator peste 30 de caractere (tabela, index, constrangere, coloana) | 12.2 | `ORA-00972` |
|
|
| `REGEXP_COUNT` | 11.1 | `ORA-00904` in SQL / `PLS-00201` in PL/SQL |
|
|
| `CONTINUE` (instructiune PL/SQL) | 11.1 | `PLS-00201: identificatorul 'CONTINUE' trebuie declarat` |
|
|
| `LISTAGG` | 11.2 | `ORA-00904` |
|
|
| `PIVOT` / `UNPIVOT` | 11.1 | eroare de sintaxa |
|
|
| trigger compus (`COMPOUND TRIGGER`) | 11.1 | eroare de compilare |
|
|
| `secventa.NEXTVAL` direct intr-o atribuire PL/SQL | 11.1 | `PLS-00357` (pe 10g: `select ... into` din `dual`) |
|
|
| `FETCH FIRST n ROWS`, `CROSS APPLY`, `LATERAL` | 12.1 | eroare de sintaxa (pe 10g/11g: `rownum`) |
|
|
| `IDENTITY`, `DEFAULT ON NULL`, coloane invizibile | 12.1 | eroare de sintaxa |
|
|
| `VALIDATE_CONVERSION`, `CAST ... DEFAULT ON CONVERSION ERROR` | 12.2 | `ORA-00904` |
|
|
| `FORALL` cu campuri de record din colectie (`S(i).camp`) | 11.1 | `PLS-00436` / `PLS-00382` |
|
|
|
|
Editiile **XE** adauga limite proprii, independent de sintaxa: XE 11.2 nu are partitionare, executie
|
|
paralela si nici masina virtuala Java in baza; XE 18/19/21 au setul de facilitati al editiei mari,
|
|
dar plafonate pe resurse (12 GB de date, 2 GB RAM, 2 fire de executie). Deci nimic care sa depinda de
|
|
partitionare sau de Java in baza, si nicio operatie care sa presupuna spatiu/memorie de server mare.
|
|
|
|
Plus, independent de versiune: **un obiect nu se poate referi la ceva creat de un script ulterior.**
|
|
Pe dev obiectul exista deja, deci pachetul compileaza; la client scriptele se aplica in ordine si
|
|
iese `ORA-00942` / corp invalid. Cand un script creeaza o tabela si altul un pachet care o foloseste,
|
|
tabela trebuie sa fie prima in ordinea `YYYY_MM_DD_NN`.
|
|
|
|
Un pachet care nu are echivalent 10g se livreaza ca varianta separata pentru serverul acela
|
|
(ex. `ff_..._PACK_CONTAFIN_10G_ROMCONSTRUCT.pck`). La aplicarea manuala a unei astfel de variante se
|
|
compileaza **doar PACKAGE BODY-ul**: recrearea specificatiei invalideaza dependentele si da
|
|
`ORA-04068` utilizatorilor conectati. Inainte, verifica ca specificatia din fisier e identica cu cea
|
|
de pe server.
|
|
|
|
Verificarea erorii se face in `C:\DMPDIR\script_master.log` de pe serverul clientului
|
|
(`depanare-pack-update.md`) — nu apare in `UPD_LOG`.
|
|
|
|
## Numerotare si versiune_db.txt
|
|
|
|
Numele scriptului: `<prefix>_YYYY_MM_DD_NN_<subiect>.sql`. Prefixe in uz: `ff` (schema fiecarei
|
|
firme), `co` (`CONTAFIN_ORACLE`), `sys`, `ris`, `rf`.
|
|
|
|
- **`NN` e o secventa unica pe zi, comuna tuturor prefixelor** — un numar consumat de un `co_`
|
|
nu se reia intr-un `ff_` din aceeasi zi si invers.
|
|
- In `versiune_db.txt` (radacina aplicatiei) se trece **doar versiunea ultimului script `ff_`**:
|
|
programele se conecteaza pe schema firmei, nu pe `CONTAFIN_ORACLE`, deci markerul urmareste
|
|
numai migrarile aplicate acolo.
|