-
Multumesc Mugur.
Vreau sa mai aduc unele precizari, pentru ca ieri, din criza de timp nu am apucat.
De fapt sunt doua teme:
– Am introdus o protectie suplimentara la utilizarea neautorizata a updater-ului de catre oricine, prin solicitarea unei parole la rularea sa. Parola curenta este salvata in directorul de download in fisierul parola.txt si se va schimba cu fiecare nou release pentru a asigura utilizarea in principal de catre personalul autorizat a updater-ului.
– Legat de actualizarea bazei de date:
Aceasta se compune din urmatoarele etape elementare:
– ShutDownDatabase = deconectarea tuturor clientilor curent cuplati si permisiunea de conectare numai pt. sysdba. Cum insa in 99.99% din implementari userul de SmartCash este SYSDBA, aceasta nu inseamna ca un “iute de click”, nu se poate reconecta imediat dupa ce a fost deconectat !! Atentie. Oricum deconectarea este fortata si va genera exceptii la nivelul aplicatiilor conectate. Nu sunt insa posibile pierderi de date in afara celor continute in ferestrele de input curent deschise…lucru care nu este foarte dramatic. Oricum, este bina sa le explicati la efectuarea actualizarii, ca intai trebuie sa se opreasca statiile/programele conectate de la baza de date.
– Backup baza de date intr-un fisier in aceeasi locatie cu baza vvv_AAALLZZ.gbk. Daca nu se finalizeaza back-up-ul cu succes, nu se trece mai departe. Efectuarea unui back-up dupa shutdown database, este cea mai sigura metoda ca in back-up au fost incluse complet toate tranzactiile comise.
– Dupa finalizarea back-up-ului se redeschide baza si mai apoi se da din nou ShutDown Database. Motivul: Scoaterea celor “iuti de click” de la conexiunea cu baza de dat chiar inaintea aplicarii scripturilor DDL/SQL de update. Este esential accesul unic in acest moment deoarece unele actualizari de indecsi sau foreign_keys se pot face numai in acest regim, in caz contrar fiind ridicata o exceptie de catre serverul SQL. Deoarece back-up-ul poate dura destul de mult, in functie de dimensiunea bazei de date, este posibil ca in acest interval, vreun user sa se reconecteze la baza de date asa incat, pentru siguranta se redeconecteaza toti potentialii utilizatori chiar inainte de actualizarea propriu-zisa.
– Se aplica succesiv scripturile de actualizare… de obicei dureaza doar cateva secunde, asa incat reconectarea in acest interval de timp nu este posibila in 90% din situatii.
– Se redeschide baza pentru useri si se iese in aplicatia principala pentru actualizarea finala a fisierelor locale de pe PC-ul respectiv.
Cam asta ar fi un ciclu normal de upgrade baza cu noul updater.
In plus, in cazul in care cel putin unul din pasii scriptului de actualizare a bazei a esuat, procesul se intrerupe si se efectueaza automat restaurarea bazei de date din copia originala intr-o baza de date noua cu aceeasi denumire ca fisierul de backup. Motivul este acela de a pastra ambele baze de date cea veche si cea noua (inconsistenta in acest moment), urmand ca inlocuirea ei sa fie facuta de catre un operator manual.