Andmete migratsioon uuele platvormile üleminekul. Suurprojektide andmete migratsiooni tehnoloogia. Plussid, miinused, järeldused


kuidas rakendada tasuta tarkvara

Vaba tarkvarale üleminek on nagu uuemale operatsioonisüsteemile üleminek. Näitena võib tuua esimese välimuse Windowsi valikud meie riigis. Sama markantne näide on üleminek Windows NT-le, mille töö ideoloogia erines järsult Windows 9x-st. Võib tuua veel ühe näite - iga uus MS Office'i paketi versioon erineb eelmisest mitte ainult liidese erinevuste, vaid ka failivormingute poolest. Seega on migratsiooni ülesanne asjakohane ka juhul, kui kasutatakse ühe tootja tarkvara.

See artikkel pakub migratsioonimetoodika üldist kirjeldust koos oluliste punktidega. Üldine põhimõte ränne on protsessi läbimõeldud ja hoolikas rakendamine järkjärguliste muutuste kaudu. Migratsioon koosneb mitmest loogiliselt lahutamatust osast, etapist.

looming töögrupp(kes teeb)

Rände rakendamisel on vaja ette näha nii tehnilist kui ka mittetehnilist laadi küsimuste lahendamine.

Oluline on kaaluda juriidilisi küsimusi, mis viimastel aegadel on mõne SRÜ riigi, eriti Ukraina jaoks äärmiselt olulised. Mõnel juhul on mõttekas arutada läbi tööandja-kasutaja-halduri suhte haldusülesanded. Ajalooliselt ei ole neid suhteid ettevõttesiseste reeglite ja juhistega piisavalt reguleeritud.

Materjali koostamise käigus viidi läbi intervjuud turvavaldkonna, arvutiõiguse ja süsteemiadministraatoritega. Valdav enamus väljendas vajadust dokumentatsioon reeglid kasutajatele organisatsiooni infosüsteemiga töötamiseks.

Õige planeerimise juurde kuulub ka rahaasjadega tegelemine. Vajalik on hinnata olemasoleva legaliseerimise kulusid infosüsteem, uue kasutuselevõtu maksumus, prognoosige omamiskulusid lähitulevikus.

Iga projekti, sealhulgas migratsiooniprojekti, võib alahinnata inimfaktor. Loomulikult on vajalik personalijuhtimise meetodite rakendamine. Enamik autorile teadaolevaid süsteemiadministraatoreid ja IT-juhte ei ole personalijuhtimise ega finantsvaldkonna spetsialistid. Nii keerulist ülesannet ei suuda lahendada üks IT-osakond.

Esimene ülesanne uuele sihtsüsteemile üleminekul on migratsiooni planeerimise töörühma loomine. See rühm vastutab rände läbiviimise eest ja seetõttu peaks tal olema üsna laialdased volitused.

Projekti eesmärk on ehitada välja majanduslikult tasuv IT-taristu. Hea kandidaat töörühma juhi kohale oleks ettevõtte või organisatsiooni tippjuht, näiteks finantsdirektor. Loomulikult kuulub sellesse gruppi IT osakonna juhataja, kellele kuulub visioon kogu IT infrastruktuurist as Sel hetkel, kui ka tulevikus. Grupi koosseisus on vajalik kogemustega süsteemiadministraator, soovitavalt vaba tarkvara kasutamise kogemusega. Grupi suurust ei saa hinnata – mõnel juhul kaasatakse vajadusel ka teisi ettevõtte töötajaid. Võimalik on kaasata kogemustega kolmas konsultant või sellistele lahendustele spetsialiseerunud ettevõte. Selle rühma töö tulemuseks on üksikasjalik migratsiooniplaan koos migratsiooni maksumuse hinnanguga. Või - ​​selgitusi organisatsioonile tasuta lahendustele ülemineku ebaefektiivsusest.

uurimine (mis on)

Esimese sammuna tuleks läbi viia audit – olemasoleva (pärandi)süsteemi kirjeldus.

Pole saladus, et aastatepikkuse rakendatud "hädaolukorra" informatiseerimisega, võtmata arvesse tarkvarale kulutatud raha tagasimaksmist, ei olnud tulemus reeglina mitte ainult majanduslikult, vaid ka tehnoloogiliselt tasakaalustamata süsteemid. Ettevõtte tarkvara audit on läbivaatamine installitud programmid, millega määratakse kindlaks vastavus nende ärinõuetele.

Auditiprotsessi väljund on:

Kirjeldus spetsifikatsioonid installitud tarkvara;

Litsentseerimata tarkvara kasutamisega seotud tuvastatud riskide loetelu;

Installitud tarkvara litsentside hankimise maksumuse arvutamine;

Litsentsimata tarkvara eemaldamise ja litsentsitud tarkvara installimise kulude arvutamine;

Tarkvara edasise kasutamise otstarbekuse määramine;

Tarkvara kasutamisega seotud tuvastatud riskide loetelu;

tarkvara inventar

Mõned uuringud näitavad, et enamik organisatsioonide juhte pöörab rohkem tähelepanu kasutatava tarkvara funktsionaalsusele ja palju vähem kasutatavate toodete õiguste austamisele.

Kahjuks puudub enamikul organisatsioonidel IT-kultuur. Mõnikord ei tea isegi IT-teenuse esindajad tegelikult, mis ja kuhu on töötajate arvutitesse installitud ning tavalised töötajad otsustavad ja installivad iseseisvalt. tarkvaratooted saadud kahtlastest allikatest.

Tarkvaravaru aitab tuvastada organisatsioonis litsentsimata tarkvara. Tuleb rõhutada, et see üritus on alati kasumlik. Inventuuri tulemusest saab hinnata tarkvara legaliseerimise kulusid nii vaba kui ka mittevaba tarkvara abil.

Organisatsioonide juhid on sageli huvitatud tarkvara kasutamise ja arendamise kulude selgest finantsplaneerimisest. Tippjuhtide huvi sellise detaili vastu on igati arusaadav - ettevõtete tippjuhtkond on huvitatud tarkvara muutmisest ettevõtete varaks, mille üle peetakse arvestust, kontrollitakse ja arendatakse sarnaselt muude varaliikidega.

Tarkvaraaudit on reeglina palju aega nõudev protseduur, mis nõuab infoanalüüsi etapis kõrgelt kvalifitseeritud personali ja mitmesuguse spetsiifilise informatsiooni tundmist. Soovitatav on võtta ühendust nendele teenustele spetsialiseerunud ettevõttega. IT-osakonna auditi läbiviimine on aga täiesti võimalik.

Mõnes organisatsioonis on suuremahulist tarkvarainventuuri korraga läbiviimine ebamugav (sageli võimatu). Põhjused võivad olla organisatsiooni suuruses või turvapoliitikas. Vaja on leida kompromiss inventuuri efektiivsuse ja sellist protsessi raskendavate tegurite vahel.

Auditi tegemiseks on kaks võimalust. Esimene võimalus on täielik audit, mis uurib kõiki arvutusseadmeid, kohalik võrk ja äärealadel. Väärikust seda meetodit- suur täpsus, puudus - kõrge hind, pikk aeg ja ebamugavus kasutajatele. Selle meetodi täiendav eelis on tuvastamisvõime kasutajate poolt installitud tarkvara ja uurida kasutajate nõudeid tarkvarale nende töökohtadel kasutades selleks spetsiaalselt koostatud küsimustikke. Teine võimalus on mõne tüüpilise arvutusseadmete, kohaliku võrgu ja välisseadmete audit. Sel juhul dikteerivad auditiobjektide valiku reeglina kasutajate funktsionaalsed kohustused. See ligikaudne meetod vähendab oluliselt varude maksumust, kuid sellel on suur viga.

Väiksemad organisatsioonid saavad käsitsi auditeerida ja sisestada teavet arvutite ja serverite ning nendesse installitud tarkvara kohta lihtsasse arvutustabelisse. Sel juhul peaksite iga leitud tarkvaratoote kohta märkima vajalike litsentside, autentsussertifikaatide ja autoriõiguslepingute olemasolu või puudumise.

Keskmiste ja suurte jaoks võite soovitada spetsiaalse tarkvara kasutamist või kutsuda sellistele teenustele spetsialiseerunud kolmanda osapoole organisatsiooni. Dokumendi koostamise käigus tehti tööd tarkvara automaatse inventuuri tööriistade ülevaatamiseks ja riistvara(teada on programmid GASP, PC inventar, MSIA). eXponenti toodetud eXponent Navigator (http://www.e-x.ru/pages/expnav.html) võib olla soovituslik.

Eksponentnavigaator

Toode on mõeldud riist- ja tarkvara ülevaatamiseks võrgu kaudu. Teave arvutite kohta sisaldab teavet komponentide (protsessor, emaplaat, kõvakettad, mälumoodulid, videokaart, võrgukaardid, printer ja muud seadmed), operatsioonisüsteem, draiverid ja tarkvara.

Programmi loojate sõnul on pärast arvutite kohta info automaatse kogumise korraldamist võimalik seda infot vaadata ja korrastada, koostada trükitud aruandeid ja veebiväljaandeid, laadida andmeid üles Microsoft Excel, XML ja muud vormingud. Võimalused:

Arvutikonfiguratsiooni automaatne diagnostika;

Arvutite kohta teabe automaatne kogumine võrgu kaudu;

Paigaldatud seadmete määratlus;

Installitud programmide tuvastamine;

Faili omaduste määratlemine;

Täiustatud andmete sortimine, otsimine ja valimine;

Trükitud aruannete koostamine;

Andmete eksport MS Excelisse;

Veebiväljaannete automaatne genereerimine.

Programmi tasuta versioonil on piirang - kuni 25 arvutit; Litsentsi hind on 1 dollar 1 arvuti kohta.

me kujundame (mida me tahame)

Töödeldud olemasoleva süsteemi uuringu tulemused on aluseks uue, sihtsüsteemi modelleerimisel. See küsimus on äärmiselt oluline ja keeruline. Selle probleemi käsitlemist raskendab see, et enamik IT-juhte ja süsteemiadministraatoreid ei tunne ajalooliselt vaba tarkvara, eriti Linuxit.

Linuxi kohta on palju kirjandust, sealhulgas venekeelset, mis kirjeldab selle platvormi eeliseid tehnoloogilisest aspektist. Kuid kõik need eelised on olulised, koos põhiprobleemiga - laia valiku rakendustarkvara olemasolu erinevates suundades. Müüt, et Linuxi platvormi all on piiratud kogus ettevõtetes kasutamiseks mõeldud rakendustarkvara, sealhulgas kontoriautomaatika, on levinud juba pikka aega ja on laialt levinud. Enamiku neist müütidest on loonud ja toidavad varalise tarkvara loojad ja müüjad ning neil on tegelikkusega vähe pistmist. Selle müüdi ümberlükkamine ei ole selle raamatu peamine eesmärk. Sellegipoolest väärib märkimist, et näiteks rakendustarkvara laius on ajalooliselt väljakujunenud dokumentide vahetamise standardeid arvestades absoluutne fantoom. Näiteks kontoritoimetaja tegelik standard on Microsofti kontor, toimetaja rastergraafika- Adobe Photoshop ja nagu vektorgraafika Corel Draw on väga levinud.

Teine probleem on sageli patenteeritud toodete liigne funktsionaalsus, mida ei dikteeri mitte turu vajadused, vaid turundajate arvamus. Ja selle üleliigse funktsionaalsuse eest maksab kasutaja üsna palju raha: programmide kasutusõiguse litsentsi maksumus, töö keerukuse suurenemine ja suurenenud nõuded riistvarale.

Viimasel ajal on olukord muutunud - Linuxi rakenduse kohta on palju teavet. ilmselt, parim materjal tuleb see dokument :-), milles on kavas käsitleda palju administratiivseid ja tehnilisi küsimusi.

Hetkel on aga dokument alles loomisel ja infot leiab erinevatest allikatest. On võimatu mööda minna Valeri V. Kachurovi, Nesov Artemi materjalidest "Windowsi programmide analoogid Linuxis - vastavustabel". (http://linuxshop.ru/linuxbegin/win-lin-soft/). See ressurss sisaldab palju väärtuslikku teavet. Kahjuks tundub, et autorid on sellest tööst loobunud. See saidi jaotis pole regulaarselt saadaval, kuid arvutustabeli koopia leiate aadressilt http://www.blif.net/modules.php?name=LinWin. Saate nõustada Open Source Applications Foundationi ressursse
(http://www.osafoundation.org/), eriti http://www.osafoundation.org/desktop-linux-overview.pdf.

Tulemuseks on:

Tööjaamade prototüübi loomine;

Kavandatava tarkvara litsentside maksumuse arvutamine;

Kasutajakoolitus;

Ligikaudse teostusgraafiku koostamine;

Riskide loetelu vaba tarkvara juurutamisel;

Tasuta lahenduste tugi;

Uue süsteemi majandusliku efektiivsuse arvestus kuni viieks aastaks.

pilootprojekt (võitluskatse)

Kuna pärandsüsteemis on palju tegureid ja migratsioon võib potentsiaalselt mõjutada suurt hulka kasutajaid, on soovitatav migratsiooni katsetada väikeses mahus. See etapp on vajalik migratsiooniplaanide ja uue süsteemi prototüübi testimiseks ja kohandamiseks. Just pilootprojekt on aluseks uue avatud lähtekoodiga tarkvaral põhineva infosüsteemi kasutuselevõtu otsuse tegemisel. Pilootprojekti teiseks väärtuseks on võimalus teavitada kasutajaid uuest süsteemist, saada kasutajatelt tagasisidet. Kolmas argument pilootprojekti kasuks on võimalus projekti maksumust katseliselt täpsemalt määrata.

Katseobjekti valikul on vaja leida kuldne kesktee. Esiteks peab valitud objekt andma hindamiseks usaldusväärseid andmeid. Teiseks ei tohiks pilootprojekti läbiviimine äritegevusele kriitilist mõju avaldada.

Selles etapis koolitatakse ka süsteemiadministraatoreid ja lõppkasutajaid: antakse prototüüp õppematerjalid, dokumentatsioon, ressursid Internetis. Pilootprojektis osalevatel kasutajatel on soovitav „ära laadida“ ja anda võimalus kasutada osa ajast uue süsteemi valdamiseks.

Eksperimentaalne etapp on eriti nõutud:

Kui kasutajate üleviimise võimalus pärandsüsteemist uude süsteemi ei ole tõestatud;

Kui kasutaja on skeptiline, võib see migratsiooniprotsessi aeglustada;

Organisatsioonil puudub korporatiivne kultuur (mis on kahjuks SRÜ-s tavaline);

Kui laiaulatuslikuks rändeks on piiratud ressursid;

Organisatsioon on suur ja pilootprojektiga ei kaasata palju kasutajaid;

Kui pärandvarasüsteemid on kiiresti arenenud nii tehnilises mõttes kui ka kulude vähendamise osas;

Rände majanduslik mõju pole täielikult välja selgitatud.

Edu saavutamiseks peab pilootprojekt:

Ei tohiks viidata ettevõtte kriitilisele valdkonnale;

Peaks olema ettevõtte jaoks piisavalt oluline;

Ei tohiks nõuda liigset ressurssi inimestelt, kes on niigi ajaliselt piiratud;

Peab olema oluline tugirühm;

Tuleb pakkuda Tagasiside kasutajatega (Help Desk süsteemid);

Teiste sfääris ei tohiks olla piiratud perioodi (näiteks äritegevuse jaoks oluline periood).

Olenevalt organisatsiooni suurusest on vabale ülemineku stringide ja kulude täpsemaks määramiseks võimalik üks või mitu katseetappi. Oluline on hinnata selle tulemusi ja teha kindlaks, kas visioon ja eesmärgid on praktilised või tuleks neid muuta või ehk isegi loobuda. Nende pilootprojektide andmeid tuleks kasutada plaanide kohandamiseks ja lõplike kulude arvutamiseks. Katse käigus on vaja selgitada küsimusi:

Prototüüptööjaamade kirjeldus;

Kasutajapõhiste sätete kirjeldus:

Jaamatüüpide kasutuselevõtu keskmised kulud;

Andmete ülekandmine päritud süsteemist uude;

Kasutajakoolitus;

Tarkvara juurutamise maksumuse arvutamine;

Tasuta lahenduste tugi.

planeerimine (mida ja kuidas)

1. Koostage migratsiooniplaan. Rändeplaan peaks vastama küsimustele:

Süsteemi ehitamise etappide kirjeldus;

Toetusvajaduste väljaselgitamine;

Migratsiooni lõpuleviimise kirjeldus.

Tegelikult tehakse lõplik valik, kuidas ränne toimub. Migratsiooni hinnanguline maksumus on heaks kiidetud.

2. Süsteemi ülesehitamise etappide kirjeldus. Tuleks hinnata süsteemi loomise etappe, mis toetavad kõige paremini kasutaja vajaduste prioriteete.

Plaan peaks vastama järgmistele küsimustele:

Mil määral ja millistes etappides tuleks süsteem installida ja kasutusele võtta, et see vastaks kõige paremini kasutajate vajadustele?

Mida on vaja migratsiooni igas etapis uus süsteem organisatsiooni klientidelt ja süsteemikasutajatelt?

Milline on süsteemi kasutamise mõju ja risk igal juurdekasvu etapil?

Süsteemi juurutamise etapid tuleks migratsiooniplaanis selgelt määratleda; kliente, arendajaid ja kasutajaid tuleb sellest teavitada. Riskianalüüsid tuleb lõpule viia enne süsteemi ehitusplaani valmimist. Tuleb tagada, et planeerimisprognoosid oleksid mõistlikud, lähenemisviis oleks hästi läbimõeldud vastavalt organisatsiooni prioriteetidele ning potentsiaalne mõju klientidele ja kasutajatele vastuvõetav.

3. Toetusvajaduse väljaselgitamine. Tuleks pakkuda optimaalset tuge, et aidata kasutajatel uut süsteemi kasutada. Lisaks vajavad kasutajad sageli kasutajatoet, mis aitaks neil mõista sihtsüsteemi üldisi võimalusi.

Probleemid, mida tuleb lahendada, hõlmavad järgmist:

Millist koolitust ja tegevusabi kasutajad vajavad?

Milline on migratsioonitoe üldine tase, mida kasutajad eduka migratsiooni tagamiseks vajavad?

Kuidas saavutada kasutaja poolt sihtsüsteemi heakskiit ja vältida kasutajate vastuseisu uue süsteemi rakendamisele?

Kuidas teavitatakse kliente ja kasutajaid peatsetest muudatustest süsteemi funktsioonides ja teenustes?

Kas on võimalik tasuta lahendust toetada organisatsiooni IT-osakond või parim variant kas see ostetakse sisse?

Migratsiooniplaan peaks keskenduma nende probleemide lahendamisele, kavandades kasutajatuge järgmistes valdkondades:

Vigadest teatamise süsteem;

Uute süsteemide tehnilise abi teenused;

Tehniline abi kasutajatele, kes migreeruvad uutele süsteemidele;

Kasutusjuhendid üleminekuks ja pärast seda;

Kasutajate koolitus uue süsteemi õppimiseks ja sellega kohanemiseks, sama tüüpi ülesannete täitmiseks;

Võimalus testida uute süsteemide kasutamist;

Uute süsteemide kasutamise demonstratsioonid, et näidata olemasolevatele pärandsüsteemide kasutajatele, kuidas uus süsteem töötab ja kuidas nad saavad võrreldavaid ülesandeid täita;

Praeguste tööprobleemide ületamine.

Kasutajate koolitusfaasis pöörake erilist tähelepanu järgijatele vana süsteem ja/või uute süsteemide vastane.

4. Migratsiooni lõpuleviimise kirjeldus. Pärast iga uue juurutamise ja koolituse etapi lõppu peavad arendajad ja juurutajad tagama, et kasutajad migreeruksid uuele sihtsüsteemile võimalikult mugavalt. Rändekava peaks nägema ette migratsiooni kiirendamise ja pärandsüsteemi võimalikult kiire eemaldamise.

"Viimaste kasutajate" ja teiste kasutajate jaoks, kellel on ettenägematuid probleeme, on vaja teha täiendavaid jõupingutusi. Selle tegevuse teine ​​aspekt on aja ja kulude hindamine, mis kulub kõigi kasutajate uuele süsteemile ülemineku lõpuleviimiseks ja vanade, litsentseerimata varalisele tarkvarale ehitatud süsteemide eemaldamiseks.

Organisatsiooni juhid, arendajad ja juurutajad peaksid kaaluma mitme lähenemisviisi kaasamist, et aidata pärandsüsteemide kasutajaid migreerida.

Teatage igale kasutajarühmale, kuidas ja millal nad peaksid oma ülesandeid uutesse süsteemidesse migreerima, kuidas töökoormus muutub pärandsüsteemidest migratsiooni perioodil;

Määrake tegevuseks stiimulid, lülituge täielikult uuele tasuta süsteem ja kõrvaldada sõltuvused pärandsüsteemidest;

Pakkuda abi (tarkvara ja lisapersonal) pärandandmete teisendamiseks uude süsteemi; – vanade süsteemide dekomisjoneerimise kord;

Pärandsüsteemide andmete arhiveerimine ja nende säilitamine.

migratsioon (teha)

Viimasesse etappi jääb üle vaid plaani järgi töötada.

Hallake ja kontrollige aktiivselt migratsiooniprotsesse:

Määrake mõõtmiskriteeriumid ja jälgige migratsiooni etappe ja ressursikulusid;

Teha perioodilisi olukorra ülevaatusi ja tutvuda nendega vastavalt mandaadile ja organisatsioonipoliitikale asjaosalistega (juhtkond, projektijuhid ja sponsor);

Luua jälgimissüsteem protsesside edenemise (edenemise), probleemide, lahenduste ja muude rände planeerimise ja rakendusplaanidega seotud äriprobleemide haldamiseks.

Vadim Mashkov, UA-FOSS [e-postiga kaitstud]

  • migreerida olemasolevad ressursidomeenid uute domeenide organisatsiooniüksustesse, mis lihtsustab võrguressursside haldamist;
  • "imiteerima" migratsiooni kulgu, samal ajal kui tegelikku andmeedastust ei toimu;
  • tühistada migratsiooniga seotud toimingud;
  • liigutada Kontod teenused;
  • taaskehtestada usalduslik suhe lähte- ja sihtdomeeni vahel;
  • teisendada palju domeene üheks või mitmeks suureks domeeniks juba loodud Active Directory keskkonnas;
  • restruktureerida olemasolevaid rühmi või liita mitu rühma üheks sihtdomeenis;
  • analüüsida andmete migratsiooni protsessi migratsioonisündmuste logimise abil.

Kasutajate ja tööjaamade migreerimine ühtsesse Active Directory struktuuri teostatakse olemasolevate juurdepääsuõiguste säilitamisega.

Uuendusvalikud

Domeeni infrastruktuuri uuendamiseks on kaks peamist võimalust [4]:

  • Domeeni värskendus. See meetod on domeenide migreerimisel kõige levinum ja lihtsamini rakendatav. See meetod võimaldab salvestada praeguse domeenistruktuuri, süsteemiseaded, kasutaja- ja rühmastruktuuri. Domeeni värskendus (kohapealne värskendus) hõlmab kontrollerite ülekandmist olemasolev domeen loodud domeenile.
  • Domeeni ümberstruktureerimine. See meetod võimaldab teil muuta olemasolevat domeenistruktuuri, ühendada domeene või teisendada domeene organisatsiooniüksusteks.

Lisaks ülaltoodud võimalustele on ka nendel põhinev segavariant - domeenide uuendamine koos nende hilisema ümberstruktureerimisega [13].

Neid valikuid nimetatakse migratsiooniteed Active Directory juurutamisel. Nende hulgast valitud üleminekutee saab olema domeeni infrastruktuuri uuendamise üldise strateegia peamiseks lüliks. See strateegia sisaldab kirjeldust, milliseid kataloogiteenuse objekte ja millises järjekorras teisaldada. Parim viis Iga rakenduste migreerimine Active Directory juurutamisel seisneb iga detaili dokumenteerimises töödokumendis, mida nimetatakse migratsiooniplaaniks.

Üleminekutee valiku kriteeriumid

Migratsioonitee valikul eeldatakse, et see otsus puudutab ainult ühte domeeni, st igati õiglane on ühe organisatsiooni piires erinevate domeenide jaoks kasutada erinevaid migratsiooniteid.

Võtke arvesse peamisi kriteeriume, mida kasutatakse kõige sobivama üleminekutee valimisel [13], mis on toodud tabelites 12.1, 12.2, 12.3, 12.4, 12.5, 12.6.

  • Kriteerium 1. Rahulolu olemasoleva domeeni olemasoleva mudeliga. Tabel 12.1. Üleminekutee valik 1. kriteeriumi järgi
    Üleminekutee Kriteeriumide sobitamine
    Domeeni värskendus Kui domeenimudelis olulisi muudatusi teha ei ole, on domeeni värskendamine kõige lihtsam tee. Domeeninimi jääb samaks, nagu ka kõigi kasutaja- ja grupikontode olemasolu
    Domeeni ümberstruktureerimine Kui olemasolev domeenimudel ei rahulda enam organisatsiooni vajadusi või ei sobi enam organisatsiooniüksuste jaoks kõige paremini, siis parim valik toimub domeeni ümberstruktureerimine
  • Kriteerium 2. Riskiaste üleminekul uuele domeenimudelile. Tabel 12.2. Üleminekutee valik 2. kriteeriumi järgi
    Üleminekutee Kriteeriumide sobitamine
    Domeeni värskendus Domeeni uuendamine on madala riskiga meetod. Domeenikontrolleri uuendamise protsess on automaatne, nii et ilma kasutaja sekkumiseta on vigadeks vähe ruumi. Ebaõnnestunud domeeniuuendusest taastumise metoodika on samuti suhteliselt lihtne: kui uuendamine ebaõnnestub, tuleb esmane domeenikontroller (PDC) välja lülitada, määrata PDC rollile mis tahes varudomeenikontroller (BDC), millel on värskeid andmeid ja alustage protseduuri uuesti.
    Domeeni ümberstruktureerimine Domeeni ümberstruktureerimine on suurema riskiga tee kui domeeni uuendamine. Täitmata on rohkem ülesandeid ja seetõttu võivad paljud protsessid valesti minna. Selle tulemusena kasvab rahulolematus nende kasutajate seas, kes ei saa sisse logida, ei pääse ligi vajalikele ressurssidele ega pääse ligi oma postkasti.
  • Kriteerium 3. Üleminekuaeg 1 Ülemineku ajastus ei ole üleminekutee valimisel kriitilise tähtsusega tegur, kuid see võib olla kriitiline piiratud ressurssidega väiksemate organisatsioonide jaoks. .Tabel 12.3. Üleminekutee valik 3. kriteeriumi järgi
    Üleminekutee Kriteeriumide sobitamine
    Domeeni värskendus Domeeni uuendamine on lineaarne protsess: kui see on alanud, tuleb see lõpule viia. See nõuab vähem samme kui ümberkorraldamine ja seetõttu kulub kogu ülemineku lõpuleviimiseks vähem aega
    Domeeni ümberstruktureerimine Domeeni ümberstruktureerimine võtab alati kauem aega. Näiteks kulub ümberkorraldamisel palju aega sihtdomeeni infrastruktuuri ehitamisele ja valideerimisele, teisaldades kõik kontod lähtedomeenist sihtdomeeni. Suured organisatsioonid ei pruugi kõiki objekte korraga teisaldada, seetõttu tehakse domeenide ümberstruktureerimine sageli mitmes etapis
  • 4. kriteerium: kataloogiteenuse aeg, mis kulub üleminekuprotsessile. Tabel 12.4. Üleminekutee valik 4. kriteeriumi järgi
    Üleminekutee Kriteeriumide sobitamine
    Domeeni värskendus Kontoobjektid pole ülemineku ajal saadaval, kuna need lähevad domeeni täiendamisel ise üle
    Domeeni ümberstruktureerimine Hea valik organisatsioonidele, kus süsteemi tööaeg on kriitiline. Kuna see hõlmab tühja, "puhta" metsa loomist ja algse keskkonna sisuliselt muutmata jätmist, säilitatakse kataloogiteenuse töövõime, kuna kasutajad jätkavad olemasolevas keskkonnas töötamist. Saate migreerida suuri või väikeseid kasutajate partiisid väljaspool tipptundi ja jätta need uued kontod seisma, kuni olete valmis vanast süsteemist lahkuma
  • Kriteerium 5. Ressursside olemasolu ülemineku lõpuleviimiseks. Tabel 12.5. Üleminekutee valik 5. kriteeriumi järgi
    Üleminekutee Kriteeriumide sobitamine
    Domeeni värskendus Kuna domeeni uuendamine on automatiseeritud toiming, nõuab see migratsioonitee juurutamiseks vähem inimressursse.
    Domeeni ümberstruktureerimine Domeeni ümberkorraldamine hõlmab rohkem ülesandeid kui domeeni uuendamine ja nõuab seetõttu rohkem ressursse, mis tähendab, et töötajad peavad olema piisavalt varustatud, et tulla toime domeeni ümberkorraldamisega kaasneva täiendava töökoormusega. Teise võimalusena saate osa või kogu projekti väljast tellida: sellistele projektidele on spetsialiseerunud palju nõuanderühmi, mis säästab teie aega ja raha, mida on vaja sisemiste töötajate koolitamiseks.
  • Kriteerium 6. Üleminekuprojekti eelarve. Tabel 12.6. Üleminekutee valik 5. kriteeriumi järgi
    Üleminekutee Kriteeriumide sobitamine
    Domeeni värskendus Vajalike eelarvevahendite vähendamist soodustavad tegurid:
    • olemasoleva serveri riistvara kasutamise oskus;
    • madalamad personalikulud;
    • väiksemad testimiskulud, kuna testida tuleb vähem uuendustoiminguid
    Domeeni ümberstruktureerimine Paljudel põhjustel nõuab domeeni ümberstruktureerimine suuremat eelarvet kui domeeni uuendamine. Riistvaranõudeid, mis on vajalikud töötlemata metsakeskkonna ehitamiseks, kuhu soovite kataloogiteenuse objekte migreerida, tuleks arvestada eelarvekuludega

Kui ettevõte ei vasta päris täpselt tingimustele, mis lubavad enesekindlalt valida uuendamisteeks domeeni uuendamise või ümberkorraldamise või kui selleks sobivad mõlemad teed, siis saab valida kolmanda tee - domeeni uuendamine, millele järgneb ümberstruktureerimine.

See üleminekutee Active Directorysse toob koheseid eeliseid (halduse delegeerimine, rühmapoliitika, rakenduste avaldamine ja palju muud), samuti domeenide ümberkorraldamise pikaajalisi eeliseid (vähem domeene suurendatud domeeni suurusega, domeeni kujundus kooskõlas ettevõtte äriliste ja organisatsiooniliste eesmärkidega).

PLM-i tööstus on arenenud juba üle kümne aasta ning kätte on jõudnud aeg, mil ettevõtted, olles algselt valitud lahendusi testinud, otsustavad täiesti mõistlikult oma olemasoleva PLM-i mõne teise vastu vahetada või oluliselt muuta praeguse konfiguratsiooni. Ja siin tuleb küsimus PLM-i andmete migreerimisest vanast süsteemist uude. Nagu me teame, on isegi geomeetriliste andmete tõlkimine iseenesest keeruline ja mitmetähenduslik ülesanne, PLM-i andmete migreerimine on veelgi keerulisem ja seni vähetuntud protsess.

Kuidas see juhtub
Uue PLM-süsteemi valik on tehtud ja juhtkond tähistab kergendusega selle valiku raskete pingutuste tulemust. Tegelikult alles nüüd algab tegelik töö, mille käigus planeeritakse ja viiakse ellu andmete migratsioon olemasolevad süsteemid uude siht-PLM-platvormi. Ettevõtte olemasolevad andmed sisaldavad märkimisväärsel hulgal intellektuaalomandit (IP) ja sellest tulenevalt ka ettevõtte konkurentsieelist ja kapitali. Uue süsteemi juurutamise edukus sõltub suurel määral olemasolevate andmete tõhusast, intelligentsest, kvaliteetsest ja õigeaegsest migratsioonist.

Seda stsenaariumi korratakse regulaarselt ühel või teisel kujul kogu maailmas ja igas tööstusharus. Tehnoloogia arenemise kiire tempoga suureneb konkurentsisurve, mille tulemusena hindavad paljud ettevõtted pidevalt oma PLM-lahendusi ja teevad parandusi. Otsuse võib ajendada tõdemus, et praegune otsus või sagedamini selle Hooldus, või mitme süsteemi kasutamine, ettevõtte juhtkonnale ei sobi. Lisaks on veel üks ühine motiiv - ettevõtte omandamiste tagajärjed ja arusaam, et nende erinevate PLM-lahenduste konsolideerimine on õigustatud. Teine stsenaarium on vajadus praeguse platvormi ulatusliku ümberkonfigureerimise järele. Olenemata muudatuse põhjustest sõltub muudatuse tõhus rakendamine olemasolevate andmete edukast migratsioonist uus platvorm.

Andmemigratsiooni probleemid
Andmete migratsioon tõstab esile mitmeid probleeme. Näiteks võib selguda, et see on paljude aastate esimene redaktsioon selle kohta, kuidas ettevõte valis tooteandmete haldustööriistu. Praeguse andmemudeli ilmselgete puuduste ületamiseks, mis on aja jooksul arenenud, võib ettevõttel olla vaja mudeli osi muuta või seda laiendada. Igal juhul avaldavad need muudatused täiendavat survet vanalt uude ülemineku protsessile, lihtne andmete ülekandmine ei pruugi olla võimalik. Üks migratsiooni kõige olulisemaid aspekte on see, et kõigepealt peate kindlaks määrama kõik andmed, mida tuleb arvesse võtta. Paljud arvavad, et tegemist on ainult digitaalsete andmete edastamisega, kuid kogenud spetsialistid mõistavad kindlasti, et mõni osa ettevõtte kriitilisest IP-st võib siiski olla trükitud kujul või üldiselt on selle kandjateks võtmetöötajate juhid.

Kui migreeritavad andmed on tuvastatud, on vaja valideerimisprotsessid välja töötada ja rakendada. Sageli võivad andmed olla vananenud, kuna viimased muudatused rohkemate hulka pole lisatud varased versioonid andmeid. Lisaks kasutatakse sageli dubleerivaid andmeid (või neid säilitatakse mitmes süsteemis), mis nõuab pidevat või perioodilist järjepidevuse kontrolli ja andmete puhastamist. Migreeritavate andmete koguhulga kindlaksmääramine eeldab ettevõtte kõige kogenumate inimeste teadmiste kasutamist.

Võib-olla on üks suurimaid andmete migratsiooni väljakutseid migratsiooni ajastus. Vanu andmeid uuendatakse ja muudetakse pidevalt, kuna ettevõte ei saa oma tööd peatada ja oodata uue PLM-i juurutamise valmimist. Lisaks on tegelikult migratsioonimeeskonnal reaalseks üleminekuks väga piiratud tehniline ajaraam, tavaliselt nädalavahetused või pühad. Olemasoleva kalendriaja täitmise vajadus nõuab spetsiaalsete tööriistade abil migratsioonialgoritmide rakendamist, kuna andmed võivad hõlpsasti sisaldada sadu tuhandeid (või isegi miljoneid) kirjeid.

Lahenduse näide
Pöördugem nende kogemuste poole, kes on PLM-i andmete migratsiooni regulaarselt läbi viinud ja teostanud. Üks tunnustatud eksperte PLM-i andmete migratsiooni vallas on Saksa ettevõte PRION Group, millel on üheteistkümneaastane kogemus selliste teenuste pakkumisel ja tõhusad tööriistad nende rakendamiseks. Kuna PRION-i portfell sisaldab liideseid levinumate PDM-ide ja pärandsüsteemidega, kust andmeid migreeritakse, ei ole ettevõttel vaja migratsioonitarkvara iga juhtumi puhul eraldi ümber kujundada. See võimaldab teil kiiresti välja töötada ettevõttepõhise migratsiooniplaani ja migratsiooni kiiresti lõpule viia, et minimeerida selle mõju tootearendusele ja tootmisele. Alloleval joonisel on kujutatud tüüpilise PRION-metoodikat kasutava andmete migratsiooniprotsessi diagramm.

Kõige olulisem on see, et see skeem on korduvalt tõestanud, et see töötab paljude PRION-i klientidega PLM-i andmete migratsiooniprojektides. Veelgi enam, korduvad katsed edastada andmeid otse ühest PLM-süsteemist teise on osutunud sellise primitiivse lähenemisviisi 100% töövõimetuks. Seda olukorda määravate tegurite hulgas on andmete kogumine mitmest allikast, vajadus andmeid teisendada ja puhastada, kinnitada ja üles laadida uude süsteemi(desse), mida saab ka füüsiliselt levitada. Seega on uuele PLM-platvormile üleminekul täiesti vastuvõetamatud.

Nende riskide maandamiseks on PRION välja töötanud migratsioonitööriistad, mis kasutavad vahepealset andmebaasi. Andmed eksporditakse etappide andmebaasi ja teisendatakse selles andmebaasis, enne kui need laaditakse uuele PLM-i sihtplatvormile. Selline lähenemine ei too kaasa operatiivandmetes viivitamatut muutust ja äri võib jätkata tavapäraselt, kuni andmete migratsiooniprotsessi reeglid ja üksikasjad välja töötatakse. Migratsiooni õnnestumise kriitiliseks teguriks on muudatuste haldussüsteemi loomine, mis võimaldab mitte ainult jälgida andmete enda migratsiooni käigus tehtud muudatusi, vaid ka andmetes tehtud muudatusi pärast nende uuele PLM-platvormile üleslaadimist. . See muudatuste haldussüsteem peab toetama kliendi spetsiifilisi nõudeid alates migratsiooniprotsessist endast kuni uue süsteemi reaalsetes tingimustes tootmises käivitamiseni.

Asjaolu, et PRION saab kasutada paljusid migratsiooniskripte oma ulatuslikust teegist, mille jaoks on välja töötatud endised kliendid vähendab migratsiooniriske ja vähendab oluliselt tulevaste klientide kulusid. See lähenemine aitab paljude raskete migratsioonistsenaariumide korral, eriti kui sihtsüsteem on hajutatud lahendus.

Lisateabe saamiseks detailne info PRIONi tööriistade ja teenuste kohta soovitan veebisaiti külastada

Kaasaegsed ettevõtted seisavad sageli silmitsi vajadusega oma infosüsteeme migreerida. Kuid selle protseduuri rakendamisele peaks eelnema hoolikas ettevalmistus, kuna sellel teel on palju takistusi.

Uuele infosüsteemile (IS) ülemineku alustamisel võib olla väga palju põhjuseid, sealhulgas vananenud platvormide toimimisega kaasnevate riskide vähendamine, infosüsteemide viimine rahvusvahelistele standarditele ning äriprotsesside efektiivsuse tõstmine. Kuid olenemata sellest, milline ülesanne on ettevõtte ees, tuleb ühelt IS-lt teisele üleminek hoolikalt planeerida ja ette valmistada.

Rändeprobleemid

Mis puudutab tehingusüsteemide, nagu ERP, arveldamine, töötlemine või ABS, migratsiooni, on uuele süsteemile üleminek väga problemaatiline. Asi on selles, et IT-spetsialistid peavad tagama suurte andmemahtude täpse migratsiooni, säilitades vana ja uue süsteemi paralleelse töö tulemuste ühildamiseks ja analüüsimiseks.

Näiteks oli mul projektikogemus ühes suuremas pangas, kus toimus tehingusüsteemi üleminek enam mittetoetatud Informixi platvormilt Oracle platvormile. Samas oli vaja läbi viia põhjalik äriprotsesside analüüs, korduvalt andmeid vanast süsteemist uude üle kanda ning kontrollida uute ja vanade süsteemide töötulemuste vastavust, võttes arvesse protsessi regulatsioonide kestus. Seetõttu oli rändeperiood 14 kuud. Mõnikord võib kahe süsteemi paralleelne töötamine kesta kauemgi, kuid ka siis, kui see piirdub mitme kuuga, on uue IS-i töö tagamiseks vaja eraldada ettevõtte töötajatele täiendavat arvutusvõimsust ja märkimisväärset aega. ülesannete üheaegseks täitmiseks kahes süsteemis.

Osakondade süsteemist ettevõtte tasemele

Sageli uuendatakse IP-d globaliseerumise ja tsentraliseerimise osana. See võimaldab oluliselt vähendada tarkvarasüsteemide hooldamise ja uuendamise kulusid. Tõepoolest, kõiki töötajaid teenindava ühtse platvormi säilitamine on palju lihtsam kui iga osakonna jaoks eraldi tööriistade haldamine. Näiteks laoseisu kontrollisüsteemi edukas migreerimine võimaldab teil üle viia mitu tuhat suure organisatsiooni osakonda ühtne platvorm ja saavutada IT-kulude märkimisväärne vähenemine. Siiski tuleb meeles pidada, et suurem osa ettevalmistusest langeb sel juhul andmete koordineerimisele erinevates vormingutes ja esitusviisides, uute regulatsioonide väljatöötamisel ja uute töötajate suhtlusmudelite loomisel.

Teine oluline aspekt on integreerimisliidesed teiste ettevõtte IS-idega, eriti ise kirjutatud ja spetsiifilistega. Nendega seotud probleemid ei pruugi esimesel etapil olla nii märgatavad, kuid need tuvastatakse erinevate osakondade koostoime loomisel kogu süsteemiga. Ja kui vana süsteemi jaoks on sellised liidesed juba programmiliselt või organisatsiooniliselt juurutatud, siis uue süsteemi jaoks tuleb need võib-olla uuesti välja töötada.

Tuleb meeles pidada, et mõtted süsteemi funktsionaalsuse laiendamisest võivad tulla juba projekti elluviimisel, nii nagu isu tuleb söömisega. Ja see tähendab, et peate terve rida lisatööd.

Tegevuskava

Süsteemi migratsiooniprojekti tegevuste kogemus näitab, et iga selline projekt nõuab hoolikat ettevalmistust ja sellega peab kaasnema individuaalne plaan. Kuid olenemata migreeritavate süsteemide tüübist, tarkvarast, andmebaasi mahtudest jne. üldine skeem näeb välja peaaegu identne.

Esimeses etapis on vaja läbi viia üksikasjalik audit, selgitades välja kõik nõuded uue süsteemi töörežiimile, küsitledes kõiki võtmekasutajad. Oluline on aru saada, kui palju andmeid, milline koormus kõnealune, alles siis saavad eksperdid pakkuda õiget rändestrateegiat.

Protseduurid ise peaksid samuti olema hoolikalt läbi mõeldud ja sisaldama selliseid olulisi elemente nagu kasutajate juurdepääsu reguleerimine süsteemidele migratsiooni ajal, tagasipööramise protseduurid. eelmine olek rikete korral ja nende protsessidega seotud erinevate spetsialistide suhtlemise järjekord.

Pärast kliendiga kokkuleppimist koostatakse tavaliselt detailplaneering, mis hõlmab mitut etappi, nimelt: andmete kopeerimine, nende kontrollimine, kahe süsteemi paralleelne töö ja täielik üleminek uuele platvormile. Professionaalselt organiseeritud süsteemimigratsiooni juures on minu arvates peamine sujuvus seda protsessi kasutajatele, kes saavad järk-järgult, ilma stressita asuda tööle uues automatiseeritud süsteemis.

Kuid isegi põhjalik ettevalmistus ei päästa teid alati tööjõukulude alahindamisest kasutajate „uutele rööbastele“ üleviimisel. See protsess hõlmab nii ettevõtte töötajate koolitamist kui ka nende toetamist uue süsteemiga kohanemise perioodil.

Sergei Berdachuk, 1,0 2006.12.01

Tundub, et juba olemasoleva infosüsteemi (IS) olemasolu peaks lihtsustama ja kiirendama uue, vanal põhineva infosüsteemi väljatöötamist, kuid praktikas juhtub enamasti täpselt vastupidi. Esiteks, kuna tekkis vajadus luua uus IS, tähendab see enamasti seda, et varem loodud IS loodi oluliste vigadega ja on täis erinevaid vigu.

Tavaliselt IP-st, mis on aastate jooksul erinevate arendajate poolt kirjutatud. Samal ajal on projekti dokumentatsioon enamasti viletsas seisus ja mõnikord puudub see täielikult. "Päris" programmeerijad ei kirjuta dokumentatsiooni, veel vähem dokumendikoode. Miks, sest kõik on lihtne ja läbipaistev. Sellest hoolimata on poole aasta pärast enda koodi vaadates üsna raske aru saada, mis seal tehti. Eriti kui selle aja jooksul on tehtud mitu muud projekti.

Pealegi iga uus arendaja tavaliselt ei viitsita hoolikalt uurida ei koodi ega süsteemi arhitektuuri. Kuna tähtajad on alati “põlevad”, kirjutatakse “vidinad” lihtsalt ajutiseks lahenduseks pakiline probleem. Tulemuseks on "puder", mis koosneb paljudest erinevatest moodulitest ja kuidagi imekombel dokitud tehnoloogiatest, mis mõnikord omavahel ei ühildu. Olukorda halvendab pärandandmebaasihaldussüsteemide (DBMS) kasutamine andmete salvestamiseks, nagu dbase-III, FoxPro või Clipper. Tehingu kontseptsiooni puudumine ning ebaõige kujundus ja referentsiaalne terviklikkus põhjustab arvukalt andmete terviklikkuse rikkumisi. Õnnelikuks võib pidada seda, kui vana süsteem kasutas DBMS-i, vahel on loomingut, mis kasutavad andmete salvestamiseks tekstifaile (ühe sellise süsteemi migreerimisel pidi autor sellisesse andmebaasi pääsemiseks kirjutama spetsiaalse draiveri).

Ainus positiivne punkt on võib-olla kogunenud kogemus äsja arendatud IS-i nõuete kujundamisel. Teisest küljest võib vana süsteemiga suhtlemise kogemus saada oluliseks piduriks uue toote kasutuselevõtul. Enamasti juhtub see visuaalse liidese ülesehituse ja teatud toimingute tegemiseks kasutatavate funktsiooniklahvide erinevuste tõttu. Jah, osa funktsiooniklahvid operatsioonisüsteem võib teatud toimingute jaoks reserveerida. Tüüpiline näide on klahvi "Enter" kasutamine, et liikuda muudetava vormi järgmise elemendi juurde vanemates DOS-i IC-des. Graafilistes liidestes kasutatakse selleks tavaliselt klahvi "Tab". Selle tulemusena saame juurutamisel kasutajatelt tugeva vastuseisu uus versioon toode. Muidugi on võimalik emuleerida vana süsteemi UI (User Interface) liidese käitumist, kuid kõige parem on seda teha valikuliselt. Need. tutvustada süsteemi käitumise konfigureerimise võimalust IS-i konfiguratsioonimoodulis ja vaikimisi kasutada praegusele operatsioonisüsteemile vastavaid sätteid. Vastasel juhul on äsja arendatud toodet raske õppida uutel kasutajatel, kes eeldavad, et programm käitub vastavalt kehtivatele standarditele.

Mis puutub töösse vana süsteemi salvestatud andmetega, siis on olukord veelgi hullem. Kõige rängemad tagajärjed on juhtkonna otsusel kasutada osa vana süsteemi moodulitest. Näiteks kui meie ees seisab laoarvestuse uue versiooni väljatöötamine ja muude ülesannete (raamatupidamine jms) lahendamisega tegeleb esialgu IS vana versioon. Selles töörežiimis tekib "reaalajas" andmete migratsiooni probleem. Kõikide moodulite kui terviku töö ülalpidamise üldkulud võivad ületada kõigi moodulite uue versiooni väljatöötamise kulud. Pealegi võivad kulud erineda suurusjärkude kaupa, võttes arvesse võimalikke kahjusid vana süsteemi puudustest ning vigadest andmete vahetamisel ja teisendamisel. Seega tuleks hoolikalt hinnata vana ISi seisukorda ja selle teostatavust. Ja mis kõige huvitavam, praktikas seda probleemi tavaliselt ei mõjutata enne, kui see tekib: "Teeme uue süsteemi ja siis tegeleme dokkimisega teisega. tarkvara ja andmeid migreerida.

Kuid siis saabub hetk, mil probleem on küps, uus süsteem on kirjutatud ja on aeg andmed teisendada ja uude süsteemi üle kanda. Analüüsides paljude erinevate infosüsteemide andmemigratsiooni kogemust, võib välja tuua tüüpilise andmete migratsiooni protseduuri, mis hõlmab:

  • Vana ja uue andmebaasi struktuuri andmevormingute analüüs, migratsiooni ja andmete ümberkujundamise plaani koostamine;
  • Tabelite vaheliste seoste määratlemine (objektide hierarhiad);
  • Andmete allalaadimise järjestuse määramine vastavalt sõltuvuste hierarhiale. Mõnikord, kuid mitte alati (näiteks kui andmebaasi uus versioon on juba tootmises), võite seoseid ignoreerida ja lihtsalt kõik välja lülitada. võõrvõtmed enne migreerimist ja loo need uuesti pärast kõigi andmetega manipuleerimist;
  • Objektide muutmise skripti täitmine andmebaasi uues versioonis;
  • Andmete otseedastus koos vajalike teisendustega "lennult";
  • Skripti käivitamine keelatud indeksite, täiendavate teisenduste jms taastamiseks. pärast andmete migratsiooniprotseduuri lõpetamist.

kõige poolt lihtne variant tavaliselt on vaheprogrammi loomine. See peab suhtlema lähte- ja sihtandmebaasidega ning tegema vajalikud teisendused.

Riis. 1. Vahevara võimalus andmete migreerimiseks


Märkimisväärne puudus see otsus võib andmeedastuse ajal muutuda võrgukoormuseks. Kui andmemaht on märkimisväärne, võib võrgusuhtlus jõudlust oluliselt mõjutada.

Parem lahendus võib olla vanade andmete eellaadimine uue DBMS-i ajutistesse tabelitesse. Kaasaegsed DBMS-id (nagu Oracle) sisaldavad tavaliselt spetsiaalsed kommunaalteenused, mis võimaldavad väga kiiresti alla laadida erinevates vormingutes väliseid andmeid. Migratsioonimoodul ise on kirjutatud DBMS-i sisseehitatud protseduurilistes keeltes (näiteks PL/SQL või java). Migreerimisprotseduuri kiirust saate märkimisväärselt suurendada tänu sellele, et sisseehitatud programmeerimiskeeled töötavad "natiivses" keskkonnas, on optimeeritud siht-DBMS-i jaoks ja võrgu kaudu andmevahetusel pole üldkulusid. .

Riis. 2. Andmete migratsiooni võimalus DBMS-i abil


Alates praktiline kogemus Selliste programmide kirjutamisel tahaksin pöörata tähelepanu pakett-SQL-meetodite kasutamisele, mida toetab enamik DBMS-i ja programmeerimiskeeli (näiteks java meetodid addBatch() ja executeBatch()). 100–200 kirjest koosneva andmemassiivi jaoks ühe INSERT- või UPDATE-lause täitmine suurendab oluliselt jõudlust võrreldes käivitamisega. antud operaator omakorda silmuses iga kirje jaoks.