Capitolul 3

3.3. Instrumente utilizate pentru migrarea datelor

Migrarea datelor se poate face manual sau folosind anumite instrumente. Pornind de la baza de date sursă se exportă structura, obiectele şi datele acesteia în scripturi SQL. Acestea sunt apoi adaptate la sintaxa bazei de date destinaţie, pentru a putea fi rulate pe aceasta, proces care poate fi unul deosebit de anevoios. De aceea, se recomandă folosirea unui asistent de migrare, care să faciliteze acest proces. El trebuie să îndeplinească cât mai multe din următoarele cerinţe:

1. 
   Să ofere o soluţie cuprinzătoare şi integrată
   

Asistentul de migrare trebuie să asigure nu doar conversia datelor, ci întregii scheme a bazei de date şi algoritmului. Trebuie convertite şi datele de tip LOB (imagini, video), definiţiile de tabele incluzând şi tipurile de date, tipul NULL, valorile implicite şi comentariile, cheile primare, unice şi externe, viziunile, funcţiile/ procedurile/pachetele stocate. Dacă aceste facilităţi nu sunt oferite de baza de date, asistentul trebuie să poată oferi soluţii alternative (spre exemplu, conversia pachetelor în funcţii şi proceduri, dacă baza de date destinaţie nu are suport nativ pentru pachete). Pe lângă diferenţele de sintaxă, software-ul trebuie să rezolve problemele legate de cuvinte rezervate şi de conflicte de identificatori. Dacă se schimbă numele unei tabele sau unei coloane, modificarea trebuie reflectată automat în toate funcţiile sau tabelele care referă acea tabelă sau coloană. Software-ul de migrare trebuie să cunoască particularităţile fiecărei baze de date. Spre exemplu, MySQL impune definirea de indecşi pe coloanele care sunt folosite ca şi chei externe pentru alte tabele. Dacă aceste cerinţe nu sunt îndeplinite şi se convertesc doar datele, restul de obiecte trebuiesc convertite manual sau cu un alt asistent de migrare.

2. 
   Să ofere o soluţie flexibilă pentru definirea regulilor globale
   

Structura bazei de date nu trebuie modificată prea mult în timpul conversiei, deoarece ar trebui rescrise aplicaţiile, ceea ce ar face migrarea foarte scumpă. Există cazuri în care trebuie schimbatmodul implicit de conversie între două tipuri de date sau modul de redenumire a coloanelor/tabelelor/funcţiilor care în noua bază de date sunt nume rezervate. Implicit, aceste nume sunt puse între ghilimele sau apostroafe, dar pentru mulţi dezvoltatori acest lucru poate fi un inconvenient, deoarece vor trebui să fie folosite ghilimelele de fiecare dată când este referită tabela/coloana respectivă. Toate aceste reguli trebuie să poată fi definite global şi să fie aplicate pentru toate obiectele.

3. 
   Să faciliteze migrarea aplicaţiilor
   

După migrarea bazei de date, aplicaţiile sunt de obicei modificate, fără a afecta însă structura bazei de date. Aceste modificări vor conduce la schimbarea sintaxei comenzilor SQL în cazul în care acest lucru este impus de noul SGBD,dar şi rezolvarea de incompatibilităţi de interfaţă. Aplicaţiile scrise doar în SQL sunt în general uşor de migrat. E mai dificil în cazul unei aplicaţii scrise, spre exemplu în Visual C+, care apelează o bază de date Oracle printr-un ODBC. Sunt imposibil de migrat aplicaţiile scrise într-un mediu proprietar (spre exemplu Orace Developer Suite). Pentru ca acest lucru să se desfăşoare cât mai uşor asistentul, trebuie să raporteze modificările realizate în structura bazei de date în timpul conversiei cât şi posibilele incompatibilităţi de interfaţă între aplicaţii şi noua bază de date.

4. 
   Să ofere performanţe ridicate
   

Deoarece bazele de date stochează volume mari de date, migrarea trebuie să se realizeze în cel mai rapid mod posibil. Comenzile LOAD DATA INFILE din MySQL şi IMP din Oracle sunt de 20 de ori mai rapide decât importul folosind INSERT din SQL. Asistentul de migrare trebuie să folosească aceste facilităţi şi să recurgă la INSERT din SQL prin interfaţa ODBC doar dacă nu există altă alternativă mai rapidă. Este necesar însă şi exportul structurii tabelelor în scripturi SQL şi a datelor în formate ASCII (CSV, Tab Delimited, SQL Insert).

5. 
   Să ofere posibilităţi de personalizare
   

Se doreşte ca migrarea să fie automatizată în procent de 100%, dar asistenţii de migrare existenţi pot oferi o automatizare de până la 95%. Dar, chiar şi numai 5% de obiecte care nu au fost migrate automat pot genera mari probleme. De aceea, este foarte important ca producătorul asistentului să ofere servicii de personalizare pentru fiecare proiect în parte, pentru a micşora la minim conversia manuală.

6. 
   Să ofere posibilităţi de migrare între cât mai multe sisteme de baze de date, inclusiv pentru bazele de date distribuite.
   

Fiecare producător de SGBD pune la dispoziţie un asistent pentru preluarea de date din alte baze de date. Există însă şi asistenţi mai generali, care suportă mai multe baze de date ca sursă şi ca destinaţie.

3.3.1. Oracle Migration Workbench

Acest utilitar asigură migrarea datelor şi procedurilor stocate în Oracle din alte baze de date. Cea mai recentă versiune apărută este 10.1.0.4.

Obiectul MS SQL Server & Sybase MS Access Informix MySQL DB2/400 DB2/UDB Tabele D D D D D D Viziuni D D (Interogari) D I D N Indexes D D D D D D Groupuri/Roluri D I D I N D Utilizatori D N D D D D Restrictii D D (Reguli) D D D D Drepturi D N D D D D Tipuri de date definite de utilizator D I N/A D D D Proceduri stocate D I D I N N Declanşatori D I D I N N Embedded SQL I I ESQL/C Pro*C I N I Alte opţiuni N/A Relaţii, tabele de legătură, reutilizarea codului aplicaţiei. Tipuri de date colecţie, secvenţe. Support ENUM N/A Obiectele schemei migrate în obiecte utilizator

Tabel 3.2 Migrare folosind Oracle WorkBench (D=DA, N=NU, I=INDISPONIBIL)

3.3.2. Utilitarele SQL*Loader şi Import/Export

Oracle Database Server are trei utilitare încărcarea şi descărcarea datelor dintr-o bază de date: Export, Import şi SQL*Loader. Utilitarele Import şi Export lucrează împreună: Export trimite definiţiile bazei de date şi datele efective unui fişier de export şi Import poate citi fişierul pentru a efectua diferite activităţi. Se poate utiliza Import şi Export pentru diverse activităţi importante ale bazei de date: restaurarea unei tabele, generarea de comenzi script CREATE, copierea datelor între baze de date Oracle, migrarea între versiuni Oracle, mutarea tabelelor dintr-o schemă în alta.

SQL*Loader este asemănător cu Import în modul în care încarcă datele, diferenţa principală este aceea că utilitarul Import poate citi numai fişiere de export Oracle, iar SQL*Loader poate citi şi fişiere text generate de baze de date non-Oracle. SQL*Loader utilizează un fişier de control pentru a comunica utilitarului cum să încarce datele.

Utilitarele Import şi Export pot efectua următoarele operaţii:

1. 
   Arhivarea şi recuperarea datelor. Probabil cea mai folosită caracteristică a acestor utilitare este capacitatea de a servi ca o soluţie de arhivare. Majoritatea soluţiilor Oracle utilizează arhivări on-line sau hot pentru a arhiva întreaga bază de date, în eventualitatea unui defect hardware sau software. Acestea funcţionează bine, deoarece toate datele pot fi restaurate la o miime de secundă faţă de momentul prăbuşirii bazei de date. Dacă o singură tabelă din întreaga bază de date are nevoie de recuperare în timpul unei arhivări complete, întreaga bază de date va trebui recuperată pe un alt calculator, iar tabela respectivă să fie copiată la loc. Export permite ca dintr-un fişier ce conţine întreaga bază de date, să poată fi extrase un utilizator, o tabelă sau orice alt obiect.
   
2. 
   Copierea obiectelor între scheme (utilizatori). Utilitarele pot fi utilizate pentru a copia de la o schemă la alta toate tipurile de obiecte: tabele, indecşi, drepturi, proceduri, viziuni. Se pot specifica obiectele care se doresc mutate, specificând schemele sursă şi destinaţie prin (utilizatorii) prin FROM şi TO. Pentru a copia tabele între utilizatori, acestea trebuie să aibă permisiunile corecte. CREATE ANY TABLE este necesar pentru a crea tabele în contul destinaţie. În plus, oricare din permisiunile SELECT sau EXP_ANY_TABLE trebuie acordate utilizatorului care efectuează exportul. Spaţiile de tabele trebuie să fie suficient de mari pentru ca tabelele să poată fi create.
   

Exemplu:

Pentru a exporta datele din tabelele departamente şi angajaţi din utilizatorul datef, se poate utiliza următoarea comandă:

Exp userid=system/manager@oracle9i tables=datef.departamente, datef.angajaţi

La importarea datelor, poate apărea una din următoarele situaţii:

• 
  Dacă tabelele departamente şi angajaţi nu există în utilizatorul test, se poate folosi următoarea sintaxă:
  

imp userid=system/manager@oracle9i from user=datef to user=test tables=departamente, angajaţi

• 
  Dacă tabele există deja în userul test, dar nu conţin date se poate utiliza parametrul IGNORE=Y:
  

imp userid=system/manager@oracle9i from user=datef touser=test tables=departamente, angajaţi IGNORE=Y

• 
  Dacă există în utilizatorul test una din tabelele departamente sau angajaţi, acestea trebuie trunchiate înainte de import pentru a evita să existe date duplicate sau respinse (din cauza cheilor primare sau unice).
  

3. 
   Copierea obiectelor între baze de date Oracle. O tabelă se poate exporta dintr-o bază de date şi să fie importată în alta (chiar şi de altă versiune). Sunt situaţii în care sunt exportate tabele cheie (sau cele ce se modifică) şi sunt trimise către o locaţie îndepărtată unde se poate utiliza Import pentru a încărca datele în baza de date locală. Aceasta este o formă de replicare a datelor la distanţă cu o singură direcţie.
   
4. 
   Generarea comenzilor script de tip CREATE. Export şi Import conţin opţiuni puternice ce permit generarea de comenzi script pentru crearea de tabele, viziuni, indecşi, proceduri/funcţii/pachete stocate sau orice alt obiect, spaţii de tabele, segmente rollback, acordare de drepturi, etc. Acestea sunt folositoare pentru refacerea structurii bazei de date. Generarea de fişiere script se face folosind opţiunile SHOW şi LOG pentru a salva comenzile SQL într-un fişier script, listat în ordinea corectă a dependenţelor (adică o tabelă este creată înaintea unui index, cheile primare înaintea cheilor externe, şamd). Formatarea rezultatului nu este corectă din punct de vedere sintactic, apărând ghilimele aşezate necorespunzător, sau cuvinte despărţite pe două linii, rezultate care necesită modificare manuală.
   
5. 
   Migrarea bazei de date de la o versiune Oracle la alta. Se poate efectua upgrade, iar uneori downgrade folosind Import şi Export. De exemplu, se poate exporta o bază de date Oracle8i, copia fişierul pe un calculator având Oracle9i şi importa fişierul. Se recomandă ca importul şi exportul să se facă cu utilitarele versiunii de bază de date destinaţie.
   
6. 
   Defragmentarea unui spaţiu de tabelă. Fragmentarea se produce atunci când tabelele şi indecşii sunt creaţi, şterşi, măriţi şi reduşi de mai multe ori într-o perioadă de timp. Acest fapt determină ca spaţiul liber să fie despărţit în mai multe bucăţi. Dacă sunt mai multe blocuri mici de spaţiu liber în loc de câteva spaţii mari, s-ar putea ca anumite obiecte să nu poată fi create sau anumite tabele să nu poată fii populate. Defragmentând tabelele de spaţiu, datele sunt reorganizate, astfel încât tot spaţiul liber este aşezat într-o singură zonă, iar spaţiile obiectelor sunt grupate alăturat. Utilitarele Import şi Export pot rezolva fragmentarea în două feluri: fie procesează o tabelă cu spaţii multiple pentru a o redimensiona într-o tabelă cu un singur spaţiu mai mare care va avea dimensiunea totală a spaţiilor anterioare, fie alipeşte obiectele din spaţiile de tabele, în timp ce transformă spaţiile libere într-un spaţiu liber mai mare. Metoda cea mai uşoară de rezolvare a problemei este următoarea: Se exportă baza de date, specificând FULL=Y şi COMPRESS=Y. FULL=Y exportă întreaga bază de date, iar COMPRESS=Y indică compresarea spaţiilor. După aceea se şterge şi se recreează întreaga bază de date, iar importul se face cu parametrul FULL=Y.
   

SQL*Loader poate efectua următoarele operaţii:

1. 
   Încărcarea datelor într-o bază de date Oracle dintr-o bază de date non-Oracle. Utilitarul SQL*Loader este folosit pentru analizarea şi încărcarea fişierelor text în tabele Oracle. Multe produse non-Oracle – cum ar fi Microsoft Excel, Acces, SQL Server, Lotus 1-2-3, SyBase, Informix pot salva date într-un fişier cu lungime fixă, variabilă sau într-un fişier delimitat. Un fişier cu lungime fixă are un număr de caractere specificat pentru fiecare coloană în tabel. De exemplu, dacă specificarea este de 50 de bytes si există doar 20 de bytes în coloana înregistrări, vor fi adăugate 20 de spaţii libere. În acest fel Oracle ştie unde să caute fiecare coloană. Într-un fişier delimitat existănun caracter special (de obicei, un tab sau o virgulă) care separă fiecare coloană pentru fiecare înregistrare. În general, datele de tip şir de caractere sunt puse între ghilimele, iar dacă delimitatorul se regăseşte între acestea el este ignorat.
   
2. 
   Înlocuirea datelor existente cu date noi. SQL*Loader poate să înlocuiască înregistrările existente într-o tabelă cu înregistrările care sunt încărcate. Acesta metodă este cunoscută sub denumirea de REPLACE. O metodă asemănătoare este TRUNCATE, mai rapidă decât REPLACE, în care toate înregistrările sunt îndepărtate din tabel înainte ca noile date să fie introduse.
   
3. 
   Obţinerea unui set cu datele invalide. SQL*Loader poate crea fişiere ce listează toate înregistrările care nu îndeplinesc condiţiile specificate, sau datele formatate în mod incorect. Aceste fişiere pot fi analizate după încărcare, şi, dacă se doreşte acest lucru, datele pot fi şterse şi reîncărcate.
   
4. 
   Lucrul la nivel logic cu datele în timpul încărcării. Se pot specifica condiţii WHEN astfel încât numai anumite tipuri de înregistrări să fie încărcate.
   
5. 
   Încarcarea datelor din surse multiple în mod simultan. Înregistrările fizice multiple se pot combina într-o singură înregistrare a bazei de date, utilizând clauza CONTINUE IF...THIS în fişierul de control din SQL*Loader. Pentru ca acesta să funcţioneze, fişierul text trebuie setat într-un mod special. Altă metodă este încărcarea surselor multiple în tabele temporare în baza de date şi apoi unirea acestora folosind SQL.
   
6. 
   Încarcarea datelor în tabele multiple. Această opţiune din SQL*Loader permite specificarea coloanelor care merg într-o tabelă şi coloanelor care merg în alta. Se pot chiar repeta coloanele de încărcare în mai multe tabele ale bazei de date. Un avantaj este faptul ca setul de tabele al bazei de date să fie normalizat, fiecare tabelă cu o cheie primară folosită pentru joncţiune, caz în care SQL*Loader poate încărca coloanele adecvate în fiecare tabelă în timp ce copiază cheia primară în fiecare tabelă pentru fiecare înregistrare din fişierul text.
   

Figura 3.2. SQL* Loader

SQL Loader este invocat folosind comanda sqlldr, eventual cu parametrii pentru a stabili caracteristicile sesiunii. În situaţia în care parametrii se modifică rar, este mai eficient a se specifica parametrii, grupându-i într-un fişier de parametrii specificat mai apoi în linia de comandă folosind parametrul PARFILE. Anumiţi parametrii pot fi incluşi în fişierul de control al SQL*Loader-ului folosind clauza OPTIONS. Totuşi valorile parametrilor specificate în linia de comandă suprascriu valorile din fişierele din parametri sau cei din clauza OPTIONS.

Fişierul de control este un fişier text scris după o structură pe care SQL*Loader-ul o înţelege. Acest fişier îi spune unde se găsesc datele, cum să le citească şi cum să le interpreteze, unde să le insereze şi încă câteva alte lucruri. Se poate spune că fişierul de control are trei secţiuni, deşi acestea nu sunt definite prea precis:

• 
  Prima secţiune conţine informaţii generale despre sesiune, printre acestea: opţiuni globale, cum ar fi numărul de rânduri, numărul de rânduri peste care să sară, clauza INFILE (care specifică unde sunt localizate datele).
  
• 
  A doua secţiune este alcătuită din unul sau mai multe blocuri INTO TABLE. Fiecare dintre aceste blocuri conţine informaţii despre tabele în care se încarcă datele, cum ar fi numele acesteia şi coloanele care o alcătuiesc.
  
• 
  A treia secţiune este opţională şi poate conţine datele efectiv de încărcat. Sintaxa fişierului de control este liberă, comenzile putându-se extinde pe mai multe linii şi nu se face diferenţa între literele mari şi cele mici (case insensitive), cu excepţia şirurilor de caractere aflate între ghilimele, care sunt luate ca atare. Cuvintele CONSTANT şi ZONE au o semnificaţie aparte pentru SQL*Loader şi de aceea nu se recomandă folosirea acestor denumiri pentru tabele sau coloane.
  

Fişierele de date de intrare. SQL*Loader citeşte datele din unul sau mai multe fişiere specificate în fişierul de control. Din punctul lui de vedere, datele din fişierele de intrare sunt organizate în înregistrări. O înregistrare poate fi în format fix, variabil sau stream. Formatul înregistrărilor este specificat în fişierul de control, mai exact prin parametrul INFILE. Dacă nu este specificat nici un format, implicit se foloseşte tipul delimitat (stream).

1. 
   Un fişier este în format fix când toate înregistrările au aceeaşi lungime. Deşi acest format este cel mai puţin flexibil, este în schimb cel mai performant. Se specifică faptul că fişierul de date este în format fix astfel: INFILE 'nume_fişier_date ' "fix n", unde “n” este lungimea în octeţi a fiecărei înregistrări.
   

Fişierul de date din următorul exemplu conţine cinci înregistrări, prima înregistrare [001, cd,] având 11 octeţi considerându-se că fiecare caracter ocupă un octet, iar delimitatorul de rând încă un octet.

Ldr.sql

load data

infile 'example.dat' "fix 11"

into table example

fields terminated by ',' optionally enclosed by '"'

(col1, col2)
example.dat:

001, cd, 0002,fghi,

00003,lmn,

1, "pqrs",

0005,uvwx,
Importul se lansează astfel:

sqlldr userid=user/parola@bazadate control=ldr.sql log=log.txt

2. 
   Un fişier este în format variabil când lungimea fiecărei înregistrări, în cazul unui câmp de tip caracter, se află la începutul fiecărei înregistrări din fişierul de date. Formatul acesta este mai flexibil decât cel anterior şi aduce un spor de performanţă faţă de cel de tip stream. Spre exemplu, se poate specifica ca un fişier de date să fie interpretat în format variabil astfel: INFILE 'nume_fişier_date' "var n", unde „n” reprezintă numărul de octeţi ai fiecărui câmp de specificare a lungimii înregistrării. Dacă „n” nu este specificat, i se atribuie valoarea implicită 5, iar dacă îi este atribuită o valoare mai mare de 40 va rezulta o eroare.
   

În exemplul următor, fişierul de control spune SQL*Loader-ului să caute datele în fişierul example.dat şi se aşteaptă un format variabil, în care câmpurile au maxim 3 octeţi. Fişierul de date example.dat conţine trei înregistrări. Prima înregistrare este de 009 octeţi, a doua este de 010 octeţi (include şi caracterul de rând nou), iar a treia de 012 octeţi (de asemenea, e inclus caracterul de rând nou).

load data

infile 'example.dat' "var 3"

into table example

fields terminated by ',' optionally enclosed by '"'

(col1 char(5),

col2 char(7))
example.dat:

009salut,cd,010carte,im,

012my,name is,

3. 
   Un fişier este în format delimitat (stream), când nu se specifică lungimea înregistrărilor. SQL*Loader formează înregistrări, căutând terminatorul de înregistrare. Acest format este cel mai flexibil, dar şi cel mai puţin performant. Pentru ca un fişier de date să fie prelucrat ca fiind în format delimitat se specifică: INFILE nume_fisier_date ["str terminator_sir"]. Terminatorul poate fi specificat în format caracter, între ghilimele (de exemplu ",") sau ca un octet în baza 16. Când un terminator conţine un caracter special, neimprimabil, el trebuie specificat în format hexa. Totuşi există anumite caractere neimprimabile care pot fi specificate în format caracter astfel:
   

\n indică linia nouă;

\t indică tabul orizontal;

\f indică form feed;

\v indică tab vertical;

\r indică carriage return.

Dacă setul de caractere nu este specificat prin parametrul NLS_LANG, iar setul de caractere a sesiunii curente este diferit faţă de cel din fişierul de date, caracterele sunt convertite în setul de caractere a acestuia. Această conversie se realizează înainte de căutarea terminatorului de înregistrare. Pe platformele Unix, dacă nu este specificat nici un terminator, cel implicit este '\n'. Pe o platformă Windows, dacă nu este specificat terminatorul, SQL*Loader foloseşte \n sau \r\n, mai exact pe care îl găseşte primul. Dacă terminatorul dorit este \r\n şi \n se află mai înainte, trebuie specificat explicit terminatorul. În exemplul următor este specificat terminatorul '|\n'.

load data

infile 'example.dat' "str '|\n'"

into table example

fields terminated by ',' optionally enclosed by '"'

(col1 char(5),

col2 char(7))

example.dat:

hello,world,|

ileana,alina,|
SQL*Loader organizează datele de intrare în înregistrări fizice, în funcţie de formatul specificat. Implicit, o înregistrare fizică este echivalentă cu una logică, dar SQL*Loader-ul poate combina mai multe înregistrări fizice într-una logică. El poate combina un număr fix de înregistrări fizice pentru a forma fiecare înregistrare logică sau poate combina înregistrările fizice în cele logice, atât timp cât o anumită condiţie este adevărată. Începând cu Oracle9i, sunt suportate înregistrări mai mari decât 64KB. Acest lucru reduce nevoia de a se despărţi înregistrările logice în mai multe înregistrări fizice. Pentru asamblarea la loc a înregistrărilor fizice în înregistrări logice se pot folosi CONCATENATE sau CONTINUEIF. Se va folosi CONCATENATE când se doreşte ca SQL*Loader să combine mereu acelaşi număr de înregistrări fizice pentru a forma o înregistrare logică. În exemplul următor, integer specifică numărul de înregistrări fizice de combinat: CONCATENATE integer. Valoarea integer specificată determină numărul de structuri de înregistrări fizice pe care SQL*Loader le alocă pentru fiecare rând din vectorul coloanelor. Deoarece valoarea implicită pentru COLUMNARRAYROWS este mare, dacă se va specifica o valoare mare şi pentru CONCATENATE este posibil să apară erori din cauza memoriei insuficiente. Performanţa se poate îmbunătăţi prin reducerea valorii parametrului COLUMNARRAYROWS (reducând numărul de rânduri într-un vector de coloane).

Se poate folosi şi CONTINUEIF, dacă numărul de înregistrări fizice ce trebuie combinate variază. Clauza CONTINUEIF este urmată de o condiţie, care va fi evaluată pentru fiecare înregistrare fizică, în timp ce este citită. Spre exemplu, două înregistrări pot fi combinate dacă semnul diez (#) se află pe poziţia 80 a primei înregistrări. Dacă la această poziţie se află orice alt caracter, a doua înregistrare nu este concatenată cu prima. Poziţiile specificate în clauză se referă la poziţia din fiecare înregistrare fizică, aceasta fiind singura situaţie în care sunt referite poziţii din înregistrările fizice. Orice alte referinţe au în vedere înregistrările logice. Pentru CONTINUEIF THIS şi CONTINUEIF LAST, dacă parametrul PRESERVE nu este specificat, câmpul de continuare este şters din toate rândurile fizice unde înregistrarea logică este asamblată. Spre exemplu, dacă se specifică CONTINUEIF THIS(3:5)='***' este specificat, atunci poziţiile de la 3 la 5 sunt şterse din toate înregistrările, chiar dacă pe aceste poziţii se află caracterele de continuare (***). În cazul CONTINUEIF THIS şi CONTINUEIF LAST, dacă este specificat parametrul PRESERVE, câmpul de continuare este menţinut.

Exemplu (CONTINUEIF THIS fără parametrul PRESERVE)

Se presupune cazul unor înregistrări fizice de 14 octeţi, în care punctul reprezintă un spaţiu:

%%aaaaaaaa....

%%bbbbbbbb....

..cccccccc....

%%dddddddddd..

%%eeeeeeeeee..

..ffffffffff..

Dacă clauza CONTINUEIF THIS nu conţine parametrul PRESERVE:

CONTINUEIF THIS (1:2) = '%%'
În acest caz dacă, '%%' se află pe primele două poziţii ale unei înregistrări fizice (rând), următoarea înregistrare este concatenată după aceasta, nemenţinându-se caracterele de continuare:

aaaaaaaa....bbbbbbbb....cccccccc....

dddddddddd..eeeeeeeeee..ffffffffff..
Dacă clauza CONTINUEIF THIS foloseşte parametrului PRESERVE, caracterele de continuare '%%' sunt menţinute şi după concatenare:

CONTINUEIF THIS PRESERVE (1:2) = '%%'

În acest caz, înregistrările logice sunt asamblate astfel:

%%aaaaaaaa....%%bbbbbbbb......cccccccc....

%%dddddddddd..%%eeeeeeeeee....ffffffffff..

După formarea înregistrărilor logice, sunt setate câmpurile de date din cadrul acestora. Setarea câmpurilor este un proces în care SQL*Loader foloseşte specificaţiile din fişierul de control pentru a determina care parte a înregistrărilor logice corespunde fiecărui câmp din fişierul de control. Este posibil ca pentru două sau multe specificaţii, să se refere la aceleaşi date. De asemenea, este posibil ca o înregistrare logică să conţină date care nu sunt referite de nici o specificaţie a fişierului de control. De cele mai multe ori, specificaţiile câmpurilor din fişierul de control se referă la o parte din înregistrările logice.

Fişierele de tip LOB şi cele secundare. Fişierele de tip LOB sunt suficient de mari pentru a fi încărcate din fişiere speciale: LOBFILE. În aceste fişiere datele, câmpurile nu sunt organizate în înregistrări şi de aceea lucrul destul de anevoios cu acestea este evitat. Spre exemplu se pot folosi fişiere LOBFILE pentru a încărca mărcile, numele şi CV-urile angajaţilor. În acest caz marca şi numele pot fi citite din fişierul normal de date, iar CV-urile, care sunt mai voluminoase, din fişierele LOBFILE. Aceste fişiere pot fi folosite şi pentru o încărcare mai facilă a datelor de tip XML.

Fişierele secundare de date (SDF) sunt similare celor principale: o colecţie de înregistrări, fiecare înregistrare fiind alcătuită din câmpuri. Acestea trebuie specificate în fişierul de control (folosind parametrul SDF) şi sunt folosite în special pentru a încărca tabele imbricate.

LOAD DATA

INFILE 'sample.dat'

INTO TABLE person_table

FIELDS TERMINATED BY ','

(name CHAR(20),

"RESUME" LOBFILE(CONSTANT 'jqresume') VARCHARC(4,2000))

Datafile (sample.dat)

Johny Quest,

Speed Racer,

Secondary Datafile (jqresume.txt)

0501Johny Quest

500 Oracle Parkway

...

0000
VARCHARC(4,2000) arată că primii patru octeţi (caractere) trebuie să fie interpretaţi ca lungimea fişierului (spre exemplu, 0501 arată ca fişierul LOB conţine 501 de caractere, iar 0000 arată că fişierul LOB nu conţine date) şi că dimensiunea maximă a câmpului este de 2000 de caractere.

Conversia datelor. În timpul unei încărcări obişnuite, câmpurile din fişiere sunt copiate şi convertite în coloanele din baza de date. Conversia se face în doi paşi:

SQL*Loader foloseşte specificaţiile câmpurilor din fişierul de control pentru a interpreta formatul fişierului de date, pentru a analiza fişierele de intrare şi pentru a popula vectorii ce corespund unei comenzi INSERT.

Baza de date acceptă datele şi execută comenzile INSERT.

Baza de date foloseşte tipul de dată a coloanei pentru a converti datele în formatul în care vor fi stocate. Trebuie ţinut cont de faptul că există o diferenţă între tipurile de date ale câmpurilor definite în fişierul de control al SQL*Loader-ului şi cele ale coloanelor din baza de date.

Înregistrările cu erori. Înregistrările citite din fişierele de date pot să nu fie inserate în baza de date, ele regăsindu-se într-un fişier cu înregistrări eronate (bad file) sau într-un fişier cu înregistrări ignorate (rejected file). Fişierul cu înregistrări eronate conţine înregistrările care au fost respinse fie de Loader, fie de baza de date. Fişierele de date sunt respinse de SQL*Loader când formatul de intrare este eronat. Spre exemplu, dacă nu există un caracter delimitator, sau dacă un câmp este mai mare decât dimensiunea maximă. Un fişier de date procesat de SQL*Loader este trimis bazei de date pentru a fi inserat într-o tabelă ca o înregistrare. Dacă baza de date determină că înregistrarea este validă, ea este introdusă în tabelă, iar dacă nu, ea este respinsă şi SQL*Loader-ul o introduce în fişierul cu date eronate. O înregistrare poate fi invalidă deoarece: o cheie nu este unică, un câmp obligatoriu este NULL sau nu este îndeplinită altă condiţie de integritate, datele sunt invalide pentru tipul de dată al coloanei din baza de date, etc. SQL*Loader poate crea, la cerere, un fişier cu datele ignorate. Aceste date sunt cele care nu au trecut de filtrare pentru că nu au corespuns nici unui criteriu de selecţie specificat în fişierul de control. Se poate specifica numărul maxim de înregistrări care să fie inserate în acest fişier.

Fişierul de log. Când SQL*Loader începe execuţia, el creează un fişier de log care va conţine detalii despre încărcarea datelor şi despre erorile apărute. Dacă acest fişier nu poate fi creat, execuţia nu se mai desfăşoară. Acest fişier este creat implicit în acelaşi director cu fişierul de control.

3.3.3. Ispirer SQLWays

Este un asistent de migrare foarte bun pentru importul datelor în MySQL, el suportând numeroase baze de date, atât ca sursă (DB2, Oracle, SQL Server, SyBase, SAP, Access, Lotus Notes, Foxpro, Dbase), cât şi ca destinaţie (DB2, SqlServer, Oracle, SyBase, Pervasive SQL). Cea mai recentă versiune apărută este 3.9 şi suportă ca sursă şi destinaţie cele mai recente versiuni ale SGBD-urilor (DB/2 8.2, Oracle 10g, MySql 5.x, MS SQL Server 2005, ş.a.). Acest utilitar dă posibilitatea administratorului de bază de date să intervină în convertirea implicită a tipurilor de date prin definire unor reguli globale.

SQLWays rezolvă situaţiile apărute datorită conflictelor de identificatori sau datorită unei denumiri de obiect din baza de date sursă care este cuvânt rezervat în baza de date destinaţie. Când se redenumeşte un astfel de obiect, asistentul realizează modificările necesare în toate obiectele care îl refereau. SQLWays poate exporta baza de date sursă în script SQL, ceea facilitează folosirea altor utilitare sau limbaje de script (Perl spre exemplu). SQLWays realizează rapoarte despre modificările suferite în timpul conversiei şi facilitează conversia aplicaţiilor. Ca şi utilitarele pentru migrare oferite de Oracle sau IBM pentru propriile lor baze de date, SQLWays realizează exportul şi importul în modul cel mai rapid disponibil.

3.3.4. Embarcadero DT/Studio

Este optimizat pentru folosirea în cazul depozitelor de date şi este orientat mai ales pe transferul şi transformarea de date. Suportă, de asemenea, modelarea datelor şi ingineria inversă (pentru a converti şi schema bazei de date) poate converti şi schema bazei de date. DT/Studio este recomandat în cazul când este necesară o reproiectare importantă a bazei de date, deoarece pune la dispoziţie numeroase funcţii şi facilităţi de transformare. DT/Studio nu suportă conversia funcţiilor/procedurilor/pachetelor stocate în baza de date.

3.3.5. Microsoft DTS

Şi acest utilitar se concentrează pe transferul de date şi pune la dispoziţie scripturi, Visual Basic pentru transformări de date. Se pot redefini tipurile de date pentru fiecare tabelă şi se pot schimba denumirile de tabele sau de coloane, dar este necesară o intervenţie importantă din partea utilizatorului pentru ca migrarea să se facă complet. DTS oferă facilităţi limitate de conversie a schemei bazei de date, nesuportând chei primare, unice sau externe, valori implicite sau comentarii.