ROMFASTSQL/docs/raport-client-vadeco-migrare.md

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.