fix(oracle): sys-grants.sql muta DMPDIR inapoi pe C:, iar 05 numara esecul drept succes
Gasite la prima rulare reala a FAZA2 la VADECO. Toate trei importurile de firma au picat, si scriptul a raportat "Successful: 3, Failed: 0". 1. sql/sys-grants.sql facea CREATE OR REPLACE DIRECTORY DMPDIR AS 'C:\DMPDIR' neconditionat. Ruleaza in pasul 04, deci DUPA importul contafin-ului din 03: importul acela reusea cu calea corecta, iar obiectul era mutat imediat dupa. Pe VADECO, unde procesul Oracle nu ajunge la nicio cale de pe C:, esecul a aparut abia in faza 2, ca ORA-39002 / ORA-39070 / ORA-29283 - ore mai tarziu si fara nicio legatura vizibila cu pasul care il provocase. E aceeasi clasa de defect ca cel reparat inec66377pentru pasul 02, dar ascuns intr-un fisier .sql, deci corectia de atunci l-a ratat. Acum calea existenta se pastreaza si se raporteaza, ca in grants-public.sql; se creeaza doar daca DMPDIR lipseste cu totul, caz in care se si avertizeaza ca pasul 01 nu a rulat. 2. 05-import-companies.ps1 incrementa $successCount si pe ramura de cod de iesire nenul, iar numarul de obiecte de dupa import nu era verificat deloc. Rezultatul: trei scheme goale raportate ca importate cu succes, faza 2 terminata "cu observatii", si defectul descoperit doar pentru ca schemele goale sar in ochi la verificare. Acum: 0 obiecte inseamna esec, oricare ar fi codul de iesire - un import care lasa schema goala nu e un succes. Codul 5 ramane acceptat (ORA-31684 pe user, ORA-39082 pe obiecte compilate, normale la ROA), orice alt cod nenul e esec. Sumarul si codul de iesire spun adevarul, deci FAZA2.cmd se opreste pe :esec_05 in loc sa continue peste un import inexistent. 3. 07-verify-installation.ps1 verifica acum ca baza chiar poate SCRIE in DMPDIR, printr-o runda UTL_FILE (deschide, scrie, sterge). Calea din dba_directories e doar un sir de caractere si nu spune nimic despre acces - exact motivul pentru care New-OracleDirectory primise deja acelasi tratament inec66377. Verificarea asta ar fi prins defectul de mai sus inainte de faza 2. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
This commit is contained in:
@@ -580,6 +580,32 @@ ALTER SYSTEM REGISTER;
|
||||
| `ORA-00959: tablespace 'USERS' does not exist` (PDB nou) | `impdp … REMAP_TABLESPACE=USERS:ROA` |
|
||||
| `ORA-39405: … TSTZ version newer` | folosește DMP-uri exportate din Oracle 18c (TSTZ 31), nu 21c (TSTZ 35) |
|
||||
| `ORA-39002` / eroare la deschiderea fișierului | serviciul Oracle nu are drepturi pe `C:\DMPDIR` — `icacls C:\DMPDIR /grant "NT SERVICE\OracleServiceXE:(OI)(CI)F" /T` |
|
||||
| `ORA-39002` + `ORA-39070: Unable to open the log file` + `ORA-29283` | `DIRECTORY DMPDIR` nu arată unde crezi — vezi mai jos |
|
||||
|
||||
### `DIRECTORY DMPDIR` s-a mutat singur
|
||||
|
||||
**Simptom:** importul contafin-ului (pasul 03) reușește, dar importul firmelor
|
||||
(pasul 05, de obicei în altă zi) pică pe toate schemele cu
|
||||
`ORA-39070 / ORA-29283`, iar schemele rămân goale.
|
||||
|
||||
**Cauză, până pe 2026-08-25:** `sql/sys-grants.sql`, rulat de pasul **04**, făcea
|
||||
`CREATE OR REPLACE DIRECTORY DMPDIR AS 'C:\DMPDIR'` necondiționat. Pasul 04
|
||||
rulează *după* 03, deci importul contafin-ului apuca să reușească, iar obiectul
|
||||
era mutat imediat după. Pe mașinile unde `C:` nu e accesibil procesului Oracle,
|
||||
eșecul apărea abia ore mai târziu, fără nicio legătură vizibilă cu pasul care îl
|
||||
provocase. Corectat: calea existentă se păstrează.
|
||||
|
||||
**Verificare** — calea din dicționar nu e o dovadă, contează dacă baza chiar
|
||||
poate scrie acolo. `07-verify-installation.ps1` face acum o rundă `UTL_FILE`.
|
||||
Manual:
|
||||
|
||||
```sql
|
||||
SELECT directory_path FROM dba_directories WHERE directory_name = 'DMPDIR';
|
||||
```
|
||||
|
||||
```powershell
|
||||
Run.cmd 01-setup-database.ps1 -DmpDir D:\DMPDIR # repune calea si o verifica
|
||||
```
|
||||
|
||||
### ORA-12954: baza depășește 12 GB (doar XE)
|
||||
|
||||
|
||||
@@ -392,13 +392,29 @@ EXIT;
|
||||
-Username "SYSTEM" -Password $SystemPassword -SqlCommand $recompileSql -Silent
|
||||
}
|
||||
|
||||
if ($process.ExitCode -eq 0) {
|
||||
Write-LogSuccess "$($item.Schema) imported successfully ($afterTotal objects)"
|
||||
# Codul 5 inseamna "terminat cu avertismente" (ORA-31684 pe user, ORA-39082
|
||||
# pe obiecte compilate) si e normal la ROA. Orice alt cod nenul e esec.
|
||||
# Iar numarul de obiecte e criteriul care nu poate fi pacalit: un import
|
||||
# care lasa schema goala nu e un succes, oricare ar fi codul de iesire.
|
||||
#
|
||||
# Pana pe 2026-08-25, ramura "else" de aici incrementa tot $successCount.
|
||||
# La VADECO, cele trei importuri au picat cu ORA-39070/ORA-29283 (DMPDIR
|
||||
# mutat de sys-grants.sql), au raportat "Objects after import: 0" - si
|
||||
# scriptul a anuntat "Successful: 3, Failed: 0".
|
||||
if ($afterTotal -eq 0) {
|
||||
Write-LogError "$($item.Schema): importul a lasat schema GOALA (0 obiecte, cod impdp $($process.ExitCode))."
|
||||
Write-LogError " Verifica logul Data Pump din DIRECTORY DMPDIR si calea acestuia:"
|
||||
Write-LogError " SELECT directory_path FROM dba_directories WHERE directory_name = 'DMPDIR';"
|
||||
$failCount++
|
||||
}
|
||||
elseif ($process.ExitCode -eq 0 -or $process.ExitCode -eq 5) {
|
||||
$sufix = if ($process.ExitCode -eq 5) { ", cu avertismente" } else { "" }
|
||||
Write-LogSuccess "$($item.Schema) imported successfully ($afterTotal objects$sufix)"
|
||||
$successCount++
|
||||
}
|
||||
else {
|
||||
Write-LogWarning "$($item.Schema) import completed with warnings"
|
||||
$successCount++
|
||||
Write-LogError "$($item.Schema): impdp a iesit cu codul $($process.ExitCode) ($afterTotal obiecte in schema)."
|
||||
$failCount++
|
||||
}
|
||||
|
||||
# Clean up copied dump file
|
||||
@@ -417,7 +433,12 @@ EXIT;
|
||||
# Summary
|
||||
Write-LogSection "Import Complete"
|
||||
|
||||
Write-LogSuccess "Company import batch completed!"
|
||||
if ($failCount -eq 0) {
|
||||
Write-LogSuccess "Company import batch completed!"
|
||||
}
|
||||
else {
|
||||
Write-LogError "Import batch terminat CU ESECURI - $failCount din $($importList.Count) scheme."
|
||||
}
|
||||
Write-Log ""
|
||||
Write-Log "Summary:"
|
||||
Write-Log " Total companies: $($importList.Count)"
|
||||
|
||||
@@ -509,6 +509,47 @@ EXIT;
|
||||
}
|
||||
else {
|
||||
Add-ReportLine "DMPDIR: $dmpDirPath"
|
||||
|
||||
# Calea din dba_directories e doar un sir de caractere: nu spune nimic
|
||||
# despre faptul ca procesul Oracle chiar poate scrie acolo. Pe VADECO,
|
||||
# DMPDIR arata spre C:\DMPDIR, unde procesul Oracle nu ajunge deloc, iar
|
||||
# importurile din faza 2 au picat toate cu ORA-39070 / ORA-29283.
|
||||
# O runda UTL_FILE spune adevarul in doua secunde.
|
||||
$probaSql = @"
|
||||
SET SERVEROUTPUT ON SIZE 32000
|
||||
SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF LINESIZE 300
|
||||
DECLARE
|
||||
f UTL_FILE.FILE_TYPE;
|
||||
n VARCHAR2(64) := 'roa_verif_dmpdir.tmp';
|
||||
BEGIN
|
||||
f := UTL_FILE.FOPEN('DMPDIR', n, 'W');
|
||||
UTL_FILE.PUT_LINE(f, 'proba');
|
||||
UTL_FILE.FCLOSE(f);
|
||||
UTL_FILE.FREMOVE('DMPDIR', n);
|
||||
DBMS_OUTPUT.PUT_LINE('DMPDIR_WRITE:OK');
|
||||
EXCEPTION
|
||||
WHEN OTHERS THEN
|
||||
BEGIN IF UTL_FILE.IS_OPEN(f) THEN UTL_FILE.FCLOSE(f); END IF; EXCEPTION WHEN OTHERS THEN NULL; END;
|
||||
DBMS_OUTPUT.PUT_LINE('DMPDIR_WRITE:ESEC ' || SQLERRM);
|
||||
END;
|
||||
/
|
||||
EXIT;
|
||||
"@
|
||||
$probaOut = Invoke-SqlPlus -OracleHome $oraHome -ServiceName $ServiceName `
|
||||
-Username "SYS" -Password $SystemPassword -SqlCommand $probaSql -AsSysdba -Silent
|
||||
|
||||
if ($probaOut -match 'DMPDIR_WRITE:OK') {
|
||||
Add-ReportLine " baza poate scrie acolo: OK"
|
||||
}
|
||||
else {
|
||||
$motiv = if ($probaOut -match 'DMPDIR_WRITE:ESEC (.+)') { $Matches[1].Trim() } else { 'motiv necunoscut' }
|
||||
Add-ReportLine " baza poate scrie acolo: NU - $motiv"
|
||||
Add-ReportLine "[WARNING] Orice import sau export Data Pump prin DMPDIR va esua."
|
||||
Add-ReportLine " Repune calea corecta si verific-o:"
|
||||
Add-ReportLine " Run.cmd 01-setup-database.ps1 -DmpDir D:\DMPDIR"
|
||||
$extraIssues += "DMPDIR ($dmpDirPath) is not writable by the database: $motiv"
|
||||
}
|
||||
|
||||
$tmplPath = Join-Path $dmpDirPath "FIRMANOUA.dmp"
|
||||
if (Test-Path $tmplPath) {
|
||||
$sizeMb = [math]::Round((Get-Item $tmplPath).Length / 1MB, 1)
|
||||
|
||||
@@ -100,9 +100,28 @@ PROMPT SYS public synonyms complete.
|
||||
PROMPT
|
||||
PROMPT [4/6] Creating DMPDIR directory...
|
||||
|
||||
-- DMPDIR e creat de 01-setup-database.ps1, pe calea data cu -DmpDir. Aici doar
|
||||
-- se acorda drepturile; calea NU se atinge.
|
||||
--
|
||||
-- Pana pe 2026-08-25 aici era un CREATE OR REPLACE DIRECTORY ... 'C:\DMPDIR'
|
||||
-- neconditionat. Pasul 04 ruleaza dupa 03, deci importul contafin-ului reusea
|
||||
-- (DMPDIR era inca unde il pusese 01), iar apoi 04 muta tacut obiectul inapoi pe
|
||||
-- C:\DMPDIR. Esecul aparea abia in faza 2, la importul firmelor, ca
|
||||
-- ORA-39070 / ORA-29283 - ore mai tarziu si fara nicio legatura vizibila cu
|
||||
-- pasul care il provocase. Vezi docs/lectii-conectare-client-oracle.md.
|
||||
DECLARE
|
||||
v_count NUMBER;
|
||||
v_path VARCHAR2(4000);
|
||||
BEGIN
|
||||
EXECUTE IMMEDIATE 'CREATE OR REPLACE DIRECTORY DMPDIR AS ''C:\DMPDIR''';
|
||||
DBMS_OUTPUT.PUT_LINE(' Directory DMPDIR created.');
|
||||
SELECT COUNT(*) INTO v_count FROM dba_directories WHERE directory_name = 'DMPDIR';
|
||||
IF v_count = 0 THEN
|
||||
EXECUTE IMMEDIATE 'CREATE DIRECTORY DMPDIR AS ''C:\DMPDIR''';
|
||||
DBMS_OUTPUT.PUT_LINE(' Directory DMPDIR created (C:\DMPDIR).');
|
||||
DBMS_OUTPUT.PUT_LINE(' ATENTIE: 01-setup-database.ps1 nu a rulat sau a esuat.');
|
||||
ELSE
|
||||
SELECT directory_path INTO v_path FROM dba_directories WHERE directory_name = 'DMPDIR';
|
||||
DBMS_OUTPUT.PUT_LINE(' Directory DMPDIR exista deja (' || v_path || ') - calea se pastreaza.');
|
||||
END IF;
|
||||
EXCEPTION
|
||||
WHEN OTHERS THEN
|
||||
DBMS_OUTPUT.PUT_LINE(' Directory DMPDIR: ' || SQLERRM);
|
||||
|
||||
Reference in New Issue
Block a user