Dėl vis didėjančio duomenų kiekio ir augančio poreikio juos saugoti, sisteminti ir analizuoti, tampa svarbu turėti efektyviai veikiančią duomenų saugojimo ir apdorojimo platformą. „Microsoft SQL Server“ yra plačiai paplitusi duomenų bazių valdymo sistema, daugybės organizacijų naudojama transakcijų tvarkymui, monitoringui ir verslo aplinkos analitikai.

Kada svarbu atsinaujinti?

Vienu iš daugelio argumentų, ar reikia svarstyti apie „SQL Server” versijos, kurią naudojate savo organizacijos IT infrastruktūroje, atnaujinimą, gali būti „SQL Server” versijos gamintojo pagrindinio ir išplėstinio palaikymo laikotarpio pabaiga. Pasibaigus produkto palaikymo laikotarpiui, jokiu būdu staiga nestoja veikti jau turimos sistemos. Tačiau svarbu atkreipti dėmesį, kad sistema daugiau nebegaus gamintojo reguliarių atnaujinimų, susijusių su paslaugos paketais (angl. Service Packs) arba atnaujinimo paketų rinkiniais (angl. Cumulative Updates).

Taip pat, gali iškilti nesklandumų, kai organizacijoje naudojamos „SQL Server” versijos, naujos aplikacijos ar sistemos nebepalaiko. Pasitaiko ir atvirkštinių atvejų, kai naudojamos aplikacijos ar sistemos organizacijoje nebepalaiko naujesnių „SQL Server” versijų.

Dažniausiai pasitaikantys faktoriai, kuriuos svarbu apsvarstyti

Ne visi „SQL Server” duomenų bazių atnaujinimai reikalauja tokio pat kruopštaus planavimo ir pastangų, kaip ir didieji sudėtingiausi projektai. Išskiriama keletas faktorių, kurie padės nustatyti laiko ir išteklių sąnaudas, kurių pareikalaus atnaujinimo procesas. Žemiau pateikti dažniausiai pasitaikantys faktoriai:

• Kritinės aplikacijos. Šios aplikacijos reikalauja detalesnio „SQL Server” atnaujinimo plano ir daugiau testavimo. Naujuose „SQL Server” leidimuose yra funkcijų, komandų, sintaksių, kurios yra pažymėtos kaip neveikiančios ir gali būti pašalintos būsimose „SQL Server” versijose. Programuotojams visada yra sunku sekti visus pokyčius naujoje „SQL Server” versijoje, norint įsitikinti, ar jų aplikacija veiks su naujausia „SQL Server” versija. Jeigu kritinės aplikacijos naudoja aukšto patikimumo ir atstatymo komponentus, tai reikalauja papildomų IT infrastruktūros kompetencijų, pailgina atnaujinimo plano parengimo laiką ir testavimo terminus.
• Aplikacijos. Daugelyje organizacijų naudojamos aplikacijos, kurios buvo įsigytos per nepriklausomus programinės įrangos tiekėjus ir naudoja „SQL Server” duomenų bazes kaip pagrindą duomenų talpinimui. Jeigu „SQL Server” duomenų bazė buvo įdiegta nepriklausomo tiekėjo, geriausias ir greičiausias atnaujinimo kelias yra atlikti atnaujinimą vadovaujantis tiekėjo pateiktu išsamiu atnaujinimo planu. Tai padės iš anksto nustatyti kokios papildomos investicijos ir ištekliai bus reikalingi.
• Duomenų bazių dydžiai. Sparčiai besivystant technologijoms, duomenų bazes apibūdinti kaip „dideles“ tampa nebeadekvatu, tad apibrėžimas „didelė duomenų bazė“ yra subjektyvus ir besikeičiantis. Pavyzdžiui, prieš 10 metų 1 TB duomenų bazė buvo laikoma didelė, tačiau šiandien toks dydis yra visiškai įprastas. Duomenų bazės dydis ir objektų, esančių duomenų bazėje, skaičius gali turėti įtakos atnaujinimo procesui, projekto trukmei ir sėkmingo grįžimo (angl. Rollback) plano įgyvendinimui.
• Duomenų replikacija. Šis faktorius svarbus organizacijoms, kurios naudoja duomenų replikavimo technologiją. Jeigu yra naudojama „SQL Server” duomenų bazių ir jos aplinkos replikacija, svarbu nustatyti replikuojamų komponentų atnaujinimo seką. Nesilaikant nustatytos sekos, kurią rekomenduoja gamintojas, galima prarasti duomenis. Neatmetami ir „SQL Server” infrastruktūros griūties atvejai.
• Greitaveikos analizė (angl. Performance baseline) prieš ir po. Šis žingsnis dažniausiai pamirštamas arba praleidžiamas „SQL Server” migracijos ar atnaujinimo metu. Greitaveikos ir veikimo pablogėjimas tampa dažna problema perkėlus sistemas į naują aplinką. Dėl šios priežasties prieš pradedant atnaujinimą svarbu atlikti greitaveikos matavimus esamoje „SQL Server” sistemoje. Atliekant greitaveikos duomenų palyginimą, problemos nustatymas gali būti daug lengvesnis ir greitesnis.

Kaip nustatyti atnaujinimo projekto sudėtingumo lygį?

Apsvarstę įvairius faktorius ir rizikas, galime nustatyti „SQL Server” atnaujinimo projekto tipą.  Žemiau pateikiame keletą projekto tipų pagal jų sudėtingumą. Šių projekto tipų tarpusavio santykis ir eiga matomi 2 pav.

• Sudėtingas atnaujinimo projektas. Šis projekto tipas reikalauja daugiausia investicijų, resursų ir išteklių. Prieš pradedant tokio tipo atnaujinimo projektus svarbu įsitikinti, kad pasiruošimo metu buvo patvirtintas detalus atnaujinimo planas, įvertintos rizikos, atlikti reikiami testai, pasirūpinta reikiamų technologijų kompetencija, resursais ir ištekliais. Užtikrinus šiuos veiksmus sumažinama duomenų bazių ir aplikacijų prastovų ar neveikimo rizika. Šie projektai linkę būti „stresiniais“ organizacijai ir sistemų naudotojams, todėl turi būti dedamos papildomos pastangos siekiant užtikrinti projekto sėkmę.
• Nesudėtingas atnaujinimo projektas. Šio projekto apimtyje rekomenduojama atlikti bazinius testus. Tokio tipo projektai nereikalauja didelių darbuotojų komandų užduotims atlikti. Visgi, būtina imtis prevencinių priemonių (pvz., rezervinių kopijų atlikimas ir patikrinimas, Rollback plano sudarymas), kad būtų sumažintos rizikos.
• Atnaujinimo projektas su Rollback planu. Šio tipo projektai vykdomi toms duomenų bazėms, kurios nėra kritinės ir neturi specialių reikalavimų jų priežiūrai. Nepasiteisinus atnaujinimo procesui arba klaidų atveju vykdomas Rollback planas.
• Tiekėjo paruoštas atnaujinimo planas. Tokius projekto tipus renkasi organizacijos, kurios neturi pakankamai resursų ar kompetencijos atlikti atnaujinimo veiksmus. Taip pat, pasirinkus tokio projekto tipą, rizikos valdymas perduodamas kompetentingam tiekėjui.

Rekomenduojama naudoti arba naujausią „SQL Server” versiją (dėl naujų produkto funkcijų ir galimybių), arba vienu lygio žemesnę versiją. Planuojant atnaujinimą, svarbu atkreipti dėmesį į tokius veiksnius, kaip atnaujinimui paskirtas biudžetas, (ar padengiami naujos įrangos kaštai?), testavimą, licencijavimą, aplikacijų palaikymą bei aplikacijų programinio kodo keitimą atsiradus nesuderinamumui su naujausią „SQL Server” versiją.

---

AUTORIUS

Edgar Viršilo – „Blue Bridge“ vyresnysis sistemų inžinierius-konsultantas, turintis daugiau nei 10 metų patirtį informacinių sistemų projektavimo, infrastruktūros sprendimų diegimo, migravimo, modernizavimo bei sistemų priežiūros ir administravimo srityse. „Microsoft“ sertifikuotas dėstytojas, galintis vesti tiek „Microsoft“ oficialiai siūlomus, tiek „Blue Bridge“ papildomai sukurtus mokymus. Turi „Microsoft P-Seller” (Data platform) išskirtinę kompetenciją „Microsoft“ duomenų bazių sprendimų srityje.

Domina „Microsoft SQL Server“ sprendimas, turimo sprendimo versijos atnaujinimas arba mokymai?

Susisiekime: Algirdas.Lunys@www.bluebridge.lt, +370 676 25066

Algirdas Lunys – „Blue Bridge“ infrastruktūros sprendimų vadovas, sertifikuotas „Microsoft“ programinės įrangos įsigijimo, valdymo, optimizavimo bei licencijavimo smulkioms, vidutinėms ir didelėms organizacijoms specialistas. Turi daugiau nei 8 metų patirtį informacinių technologijų srityje.