romfast/comun
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
edbcfcd63f6893880a16ba3d61b4c4d9571cc807
comun/docs/depanare-pack-update.md
Marius Mutu edbcfcd63f sync SVN r18140
2026-09-16 14:33:43 +03:00

9.3 KiB
Raw Blame History

Depanare actualizare ROA (CONTAFIN_ORACLE.PACK_UPDATE)

Actualizarea automata a aplicatiilor si a bazei ruleaza din jobul CONTAFIN_ORACLE.UPDATEROA_ZILNIC -> PACK_UPDATE.UpdateROA, in 3 etape secventiale: UpdateApp (descarca arhivele programelor) -> UpdateScripts (umple UPD_DATABASE) -> UpdateDatabaseSqlPlus (aplica scripturile pe scheme). O etapa esuata le opreste pe toate urmatoarele.

Scriptul de diagnostic

COMUN\utile\diag_actualizare.ps1 -Alias <ALIAS_TNS> ruleaza tot lantul de mai jos si scoate un verdict (unde a ramas rularea, care e scriptul candidat, unde e eroarea). Strict read-only; -Disc adauga verificarea spatiului pe discurile serverului (singura parte care scrie ceva — un .ps1 temporar in DMPDIR). Foloseste-l intai; sectiunile de mai jos explica ce citeste si de ce.

Cand cauza e spatiul (tablespace plin, audit/loguri Oracle care umplu discul), continua cu depanare-spatiu-oracle.md si COMUN\utile\diag_spatiu.ps1.

Cand eroarea e de retea/HTTP (ORA-29273 / ORA-29024 / descarcare esuata), cauza e aproape sigur pe serverul de actualizari, nu pe client: continua cu depanare-server-update-roa.md.

Unde te uiti, in ordine

Ce Unde
pana unde a ajuns fiecare rulare UPD_ISTORIC (stare: 0=start, 1=aplicatii, 2=scripturi, 3=aplicare, 4=incheiat; dataora_end gol = neincheiata)
cauza reala a esecului UPD_LOG (dataora_start = rularea, secventa+dataora = ordinea; explicatie e CLOB)
ce a raportat jobul dba_scheduler_job_run_details (log_date, status, additional_info)
ce versiuni s-au descarcat UPD_PROGRAME
scripturi disponibile / aplicate UPD_DATABASE.script_date vs <schema>.VERSIUNE.data_script
erorile din aplicarea scripturilor C:\DMPDIR\script_master.log pe serverul de baze de date

Un sir de rulari oprite la aceeasi stare da direct etapa vinovata, iar prima zi din sir da data de la care s-a schimbat ceva.

Capcane

  • UPD_LOG se goleste la fiecare rulare. Nu ai istoric: iei log-ul rularii curente, altfel relansezi ca sa-l reproduci.
  • Eroarea din additional_info a jobului e de obicei falsa. Pe orice esec se apeleaza EmailLog, iar daca SMTP-ul e picat ridica ORA-20000 care inlocuieste eroarea originala. Cauza adevarata e in UPD_LOG.
  • UpdateApp abandoneaza tot la primul program nedescarcat (exit din bucla, CT_INSUCCES) — deci si programele de dupa el in lista, si ambele etape de baza de date. Un singur fisier indisponibil blocheaza actualizarile la infinit, tacut.
  • GetStare refuza o rulare noua cat timp precedenta e neincheiata si nu a trecut o ora. Se deblocheaza cu exec contafin_oracle.pack_update.IncheiereActualizare.
  • Programele %USERREPORTS% merg toate in directorul UPD_USERREPORTS, nu in UPD_<nume_program>.

Aplicarea scripturilor (script_master.log)

Etapa 3 nu ruleaza scripturile din PL/SQL, ci genereaza in DMPDIR (C:\DMPDIR) cate un script_<SCHEMA>.sql plus script_master.sql, pe care le da unui SQL*Plus extern, cu iesirea in C:\DMPDIR\script_master.log (script_master2.log = pasii de la final).

Erorile de aici NU ajung in UPD_LOG. O rulare care esueaza la un script arata perfect curata in baza: UPD_LOG fara nicio eroare, doar UpdateSchemaSQLPLUS ... / UpdateDatabaseSQLPLUS END. Semnele indirecte sunt ca rularea ramane la stare = 3 fara dataora_end, iar <schema>.VERSIUNE nu mai avanseaza. Scriptul vinovat e primul din UPD_DATABASE de dupa ultima versiune inregistrata acolo, iar mesajul real e doar in script_master.log.

Scripturile au WHENEVER SQLERROR EXIT SQL.SQLCODE ROLLBACK, deci primul esec opreste tot lantul si se repeta identic la fiecare rulare pana e reparat.

Fisierul se poate citi si fara acces la desktopul serverului, prin UTL_FILE pe directorul DMPDIR (fopen(...,'R',32767) + get_line in bucla; tine ultimele N linii intr-un tablou — partea utila e la sfarsit).

Un esec de script raportat nu inseamna neaparat o problema de SQL in script

Eroarea Oracle poate veni din obiecte cu totul straine de ce modifica scriptul (ex. ORA-01653: unable to extend table SYS.INFO ... in tablespace SYSTEM, ridicata din SYS.PINFO/AUTH_PACK la conectare, nu din scriptul insusi) - orice script ar fi picat identic. Cand mesajul de eroare nu priveste obiectele pe care scriptul chiar le atinge, verifica intai spatiul (maxbytes pe tablespace-ul din mesaj nu e o limita XE - cele 11 GB XE sunt pe date utilizator, plafonul mic e o setare de instalare, se ridica din contafin_oracle cu alter database datafile '<cale>\<TS>.DBF' autoextend on next 50M maxsize 2000M;). Spatiul pe discul serverului se verifica fara RDP cu sys.ExecuteScriptOS (vezi mai jos, sectiunea "Comenzi OS pe serverul de baze de date").

Descarcarea (UpdateApp)

Cu server_info.POWERSHELLDOWNLOAD = '1', PACK_UTILS.DownloadFileOS scrie un .ps1 cu curl in DMPDIR, il lanseaza cu sys.ExecuteScriptOS si asteapta aparitia fisierului in directorul Oracle UPD_<PROGRAM>. Daca folderul de pe disc lipseste, curl esueaza mut si in log apare doar Fisierul NU s-a salvat pe disc. — verifica intai directorul, nu reteaua.

Verificari rapide (read-only, din contafin_oracle):

-- calea configurata
select directory_name, directory_path from all_directories where directory_name like 'UPD%';
-- fisierul chiar exista pe disc?
select dbms_lob.fileexists(bfilename('UPD_ROACONT','ROACONT-2.11.70.zip')) from dual;

-- directorul exista si e scriibil? ORA-29283 = cale OS inexistenta sau fara drept de scriere
declare f utl_file.file_type; begin
  f := utl_file.fopen('UPD_USERREPORTS','__probe.txt','W'); utl_file.fclose(f);
  utl_file.fremove('UPD_USERREPORTS','__probe.txt');
end;
/

URL-ul se testeaza direct cu curl de pe orice masina (optiuni.UPD_URL_APP, cu |CUSTOMERID| inlocuit din sys.auth_detalii.detalii); daca da 200, problema e local pe server.

Comenzi OS pe serverul de baze de date

sys.ExecuteScriptOS(<powershell>, <cale .ps1>) creeaza un job scheduler executable — asincron, deci rezultatul se verifica prin polling, nu imediat. Scriptul se scrie cu pack_utils_file.clob2fileX(<clob>, 'DMPDIR', '<nume>.ps1'). Utila cand ai doar acces Oracle (ex. tunel SSH), fara RDP:

declare lcPS server_info.value%type; begin
  select value into lcPS from server_info where upper(name)='POWERSHELLPATH';
  pack_utils_file.filedelete('DMPDIR','x.ps1');
  pack_utils_file.clob2fileX('New-Item -ItemType Directory -Force -Path ''D:\...'' | Out-Null',
                             'DMPDIR','x.ps1');
  sys.ExecuteScriptOS(lcPS, 'C:\DMPDIR\x.ps1');
end;
/

Emailuri: log de actualizare vs buletin informativ

Sunt doua emailuri diferite, trimise de doua masini diferite — se confunda usor.

Log de actualizare Buletin informativ
Cine trimite baza de date, PACK_UPDATE.EmailLog (UTL_SMTP direct catre EMAIL_SMTP:EMAIL_PORT, AUTH LOGIN) serverul de update (ASP.NET); baza doar face un GET pe optiuni.UPD_URL_BULETININF (cu `
Destinatari server_info.EMAIL_TO + EMAIL_CC configurati pe serverul de update, nu in server_info (ex. office@romfast.ro)
Subiect / continut Actualizare ROA dd.mm.yyyy hh24:mi:ss; liniile din UPD_LOG, text simplu separat cu TAB compus de serverul de update
In UPD_LOG erorile SMTP: EROARE: utl_smpt ERROR CODE ... raspunsul HTTP, verbatim (ex. ERR-1-BULETIN INFORMATIV NU S-A TRIMIS. MOTIVUL: Error: 1429)

Detalii care conteaza la depanare:

  • EMAIL_CC nu produce un antet Cc:. Codul il concateneaza cu virgula la EMAIL_TO si trimite RCPT TO pentru toti; antetul e un singur To: <toti>. Deci un email primit in Cc nu vine de la EmailLog.
  • EMAIL_FROM e per server de client (roaupdate-<client>@romfast.ro) si difera de contul autentificat, care e acelasi peste tot (EMAIL_USERNAME = roaupdate@romfast.ro). Expeditorul e singurul indiciu din email despre serverul care l-a trimis. Daca EMAIL_FROM lipseste, se compune din UTL_INADDR.get_host_name.
  • Un buletin esuat nu opreste nimic: raspunsul ERR-1-... e text normal, se scrie in UPD_LOG si actualizarea merge mai departe. Doar exceptiile HTTP ajung ca ERR: <url> ....
  • Un SMTP picat, in schimb, opreste tot — EmailLog ridica ORA-20000 care mascheaza eroarea reala (vezi „Capcane" mai sus). E singurul loc din lantul de email care are voie sa arunce.

Configurare (CONTAFIN_ORACLE)

  • server_info: POWERSHELLDOWNLOAD, POWERSHELLPATH, POWERSHELLTIMEOUT, CURLPATH, SQLPLUSPATH, EMAIL_METHOD/EMAIL_SMTP/EMAIL_PORT/EMAIL_USERNAME/EMAIL_PASSWORD/ EMAIL_FROM/EMAIL_TO.
  • optiuni: UPD_URL_APP, UPD_URL_DATABASE, UPD_URL_BULETININF (daca lipsesc, pachetul foloseste URL-uri implicite din cod).

Conectare la serverul unui client

Tunel SSH pe 1521 + alias TNS pe 127.0.0.1 in D:\ROA\instantclient_19_18\tnsnames.ora (ex. ROA_ROMCONSTRUCT), utilizator contafin_oracle. Vezi oracle_export.md pentru client si capcana de encoding; parolele stau in COMUN\docs\local\oracle.md (neversionat in git).

Serverele de client pot fi Oracle 10g: unele coloane din dba_scheduler_* lipsesc (dba_scheduler_running_jobs.last_start_date) — foloseste dba_scheduler_job_run_details.