# 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.