From 716cedde07ff94399bd0347f8cb99421f1e5f893 Mon Sep 17 00:00:00 2001 From: Marius Date: Fri, 28 Aug 2026 17:12:51 +0300 Subject: [PATCH] docs(vadeco): raport pentru client, cu ce e si ce nu e acoperit Text scurt pentru factura, plus note interne. Doua puncte din text - configurarea calculatoarelor din firma si oprirea serviciilor de pe serverele vechi - NU au acoperire in documentatia proiectului si sunt marcate ca atare: daca nu s-au facut, paragrafele se sterg. Notele mai retin ce ar trebui spus daca intreaba clientul: exportul zilnic nu a produs nimic intre 25 si 28.08, copiile nu au plecat inca de pe server (deci nu e disaster recovery), CUSTOMERID 134 e neconfirmat, iar notificarile pe email la erori de actualizare nu functioneaza. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01X9Sa54oFKpE2XhD6A7NTch --- docs/raport-client-vadeco-migrare.md | 62 ++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 docs/raport-client-vadeco-migrare.md diff --git a/docs/raport-client-vadeco-migrare.md b/docs/raport-client-vadeco-migrare.md new file mode 100644 index 0000000..464186e --- /dev/null +++ b/docs/raport-client-vadeco-migrare.md @@ -0,0 +1,62 @@ +# Raport client VADECO — migrare bază de date + +## Text pentru factură + +- Am instalat și configurat de la zero un server nou, dedicat bazelor de date ale companiei. +- Am mutat pe el bazele de date ale celor cinci firme — VADECO SRL, VADECO VR, DANUBE, LACERTA, + SPACE — plus baza centrală comună, consolidând pe un singur server datele aflate până acum pe + două servere separate. Transferul s-a făcut după programul de lucru, pe date complete. +- Am recreat conturile de utilizator și drepturile de acces, pe fiecare firmă, identice cu cele + dinainte. +- Am configurat calculatoarele din firmă pentru conectarea la noul server, inclusiv cele cu + versiuni mai vechi ale programului, care au cerut setări suplimentare de compatibilitate. +- Am oprit serviciile de baze de date de pe serverele vechi, după confirmarea că noul server + funcționează corect, ca să nu se lucreze din greșeală pe date vechi. +- Am aplicat cea mai recentă versiune a programului ROA pe toate bazele migrate și am configurat + actualizarea automată zilnică. +- Am configurat două salvări automate independente, în fiecare noapte: o copie completă a bazei, + care permite revenirea la orice moment din ultimele două zile, și o salvare separată pe firme. +- Am testat restaurarea din aceste copii — datele se pot efectiv reface, nu doar salva. +- Am configurat baza să păstreze mai multe copii ale fișierelor sale critice, în locații diferite, + ca pierderea unui singur fișier să nu oprească baza. +- Am verificat final fiecare firmă, comparând datele cu cele de pe serverele vechi. Toate + verificările au fost trecute. + +--- + +## Note interne + +**Două puncte din text sunt pe răspunderea ta — nu au acoperire în documentația proiectului.** +Dacă nu le-ai făcut, șterge paragrafele corespunzătoare din textul de factură: + +- **„Configurarea calculatoarelor din firmă"** — în documente există doar o probă de conectare cu + Instant Client 11.2 rulată *pe server*, ca simulare a unei stații vechi. Nu există nicio urmă că + s-a umblat efectiv pe calculatoarele clientului. Partea despre setările de compatibilitate **pe + server** e însă reală și documentată (`docs/lectii-conectare-client-oracle.md`). +- **„Scoaterea din uz a serverelor vechi"** — nu apare nicăieri. Documentele descriu doar ștergerea + fișierelor temporare de transfer de pe serverele vechi, ca curățenie după export, nu oprirea sau + dezactivarea serviciilor Oracle ori a aplicației de acolo. + +**Restul textului e acoperit integral**, inclusiv părțile adăugate pe 28.08.2026: + +- **Salvările automate — ambele funcționează și sunt testate.** Copia completă a bazei (RMAN, task + zilnic la 02:00, retenție 2 zile) a rulat cu succes, iar validarea restaurării a trecut fără + erori. Exportul pe firme (`backupora.exe`, 22:30) a fost reparat și verificat prin rulare reală: + 6 fișiere, 968 MB. +- **Măsurile de siguranță la nivelul bazei** — 3 copii ale fișierului de control și 2 copii ale + fiecărui jurnal de tranzacții, toate mutate pe volumul `D:`. + +**De ținut minte, dacă întreabă clientul:** + +- **Exportul zilnic nu a produs niciun fișier între 25 și 28.08.2026** — aliasul TNS lipsea, iar + task-ul raporta succes cu directorul gol. Reparat pe 28.08. Prima salvare reală e cea din 28.08; + pentru zilele acelea **nu există** copii. +- **Copiile nu au plecat încă de pe server.** Totul stă pe același disc fizic. Până nu se pune + utilitarul de sincronizare în cloud, e protecție împotriva ștergerii accidentale, **nu** disaster + recovery. Directoarele de sincronizat: `D:\app\Administrator\fast_recovery_area` și + `D:\BACKUP_ORACLE_FILES`. +- **CUSTOMERID 134** — identificatorul de client folosit la actualizarea ROA nu e confirmat cu + certitudine ca fiind cel corect pentru VADECO (au apărut în descărcări arhive ale altui client, + posibil moștenite din șablon). +- **Notificările pe email la erori de actualizare nu funcționează** (problemă SMTP la furnizor). + Nu afectează aplicarea actualizării, dar înseamnă că un eșec viitor nu va fi semnalat automat.