Cap.

2 7IMPORT
Acest capitol descrie cum sa folositi utilitarul Import, care citeste dintr-un fisier export intr-o baza de date Oracle. Import citeste numai fisiere export create de utilitarul Export. Pentru informatii despre cum sa exportati o baza de date vezi Cap. 1 Export. Pentru a incarca date din alte fisiere vezi SQL*Loader. Acest capitol abordeaza urmatoarele: Ce este utilitarul Import Moduri de import Folosirea importului Privilegii necesare pentru a folosi importul Importul in tabele existente Parametri import Folosirea Exportului si Importului la nivel tabela si partitie Exemple de sesiuni de import Folosirea metodei interactive Importul fisierelor de export incrementale, cumulative si complete Controlul creerii si intretinerii indecsilor Reducrerea fragmentarii bazei de date Mesaje de atentionare, de eroare si de finalizare Manipularea erorilor Consideratii in retea Importuri si instantanee (snapshots) Drop(uirea unui) tablespace Reorganizarea unui tablespace Consideratii asupra setului de caractere si a NLS-ului Consideratii asupra importului obiectelor bazei de date Folosirea unui fisier de export Oracle7 Folosirea fisierelor de export Oracle6 Folosirea fisierelor de export Oracle5

Nota: Daca folositi optiunea de replicare avansata, vedeti Oracle8 Replicare, Apendix

B - Migrare si compatibilitate. Daca folositi Trusted Oracle vezi documentatia despre Trusted Oracle despre cum puteti folosi utilitarul Import in acel mediu. CE ESTE UTILITARUL IMPORT? Conceptul de baza din spatele Import este foarte simplu. Import insereaza obiectele bazei de date extrase dintr-o baza Oracle prin utilitarul Export (si memorate intr-un fisier dump) intr-o alta baza de date Oracle. Fisierul export poate fi citit doar de Import. Vezi cap.1 Export pentru mai multe informatii despre utilitarul Export. Import citeste definitiile de obiecte si datele din tabele, pe care Export le-a extras dintro baza de date Oracle si le-a memorat intr-un fisier Export (dump) in format binar, localizat tipic pe disc sau banda. Aceste fisiere sunt de obicei copiate cu FTP sau transportate fizic (in cazul benzilor), intr-o locatie diferita, si folosite, cu utilitarul Import pentru a transfera date intre baze de date care sunt pe masini neconectate printr-o retea, sau ca parti din strategii de restaurare a datelor. Utilitarele Export si Import pot facilita anumite aspecte ale replicarii avansate Oracle, ca de ex. instantierea offline. Vezi Replicare Oracle8 pentru mai multe informatii. Retineti ca fisierul dump Export poate fi citit doar de utilitarul Import. Daca doriti sa incarcati date din formate ASCII, format fix sau delimitat vezi cap. 3-8 SQL*Loader. Figura 2-1 ilustreaza procesul importului dintr-un fisier de export.

OBIECTE TABEL: ORDINEA IMPORTULUI Obiectele tabel sunt importate pe masura ce sunt citite din fisierul de export. Fisierul export contine obiecte in urmatoarea ordine: 1. definitii de tabele 2. date din tabele 3. indecsi ai tabelelor 4. constrangeri de integritate, trigere si indecsi bitmap Prima data sunt create tabelele noi. Apoi sunt importate datele si sunt construiti indecsii. Apoi sunt importate trigerele, constrangerile de integritate sunt stabilite pe noile tabele si sut construiti indecsii bitmap. Aceasta secventa de lucru previne rejectarea datelor datorita ordinii in care acestea sunt importate. Aceasta secventa previne, de asemenea declansarea redundanta (a doua oara) a trigerelor pe aceleasi date (o data cand au fost initial inserate si a doua oara in timpul importului).

De ex. daca tabela EMP are o constrangere referentiala de integritate pe tabela DEPT si tabela EMP este importata prima, toate randurile EMP care fac referire la departamente care nu au fost inca importate in DEPT ar fi rejectate daca ar fi activate constrangerile. Totusi, atunci cand datele sunt importate in tabele existente, ordinea importului ar putea produce esecuri la verificarile de constrangeri de integritate. In situatia deja discutata, daca tabela EMP exista, si constrangerile referentiale de integritate sunt active, multe randuri ar putea fi eliminate. O situatie similara ar aparea atunci cand o constrangere referentiala de integritate pe o tabela s-ar autoreferi (la tabela in cauza). De exemplu, daca managerul lui SCOTT din tabela EMP este DRAKE, si randul lui DRAKE nu a fost deja incarcat, incarcarea randului lui SCOTT va esua, chiar daca ar fi valid la sfarsitul exportului (atunci ar fi inserat si randul lui DRAKE). Sugestie: Pentru ratiunile prezentate mai sus, este o buna idee sa dezactivati constrangerile referentiale de integritate atunci cand importati in tabele existente. Restabiliti constrangerile la terminarea importului. COMPATIBILITATE Import poate citi fisiere de export create de versiuni 5.1.22 si ulterioare MODURI DE IMPORT Utilitarul import asigura trei moduri de import. Obiectele importate depind de modul de import pe care l-ati ales, si de modul care a fost folosit de catre utilitarul export. Toti utilizatorii Tabela: Acest mod va permite sa importati tabele specificate in schema proprie, in loc sa importati toate tabelele. Un utilizator privilegiat poate numi tabelele prin specificarea (prin prefixare a) schemei care le contine. Implicit este sa se importe toate tabelele in schema utilizatorului care realizeaza importul. Utilizator: Acest mod va permite sa importati toate obiectele care apartin utilizatorului (tabele, date, granturi, indecsi). Un utilizator privilegiat importand in mod user poate importa toate obiectele in schemele unui set specificat de utilizatori. Full database: au doua alegeri pentru modul de import. Un utilizator cu rolul IMP_FULL_DATABASE (utilizator privilegiat) are trei alegeri

Numai utilizatorii cu rolul IMP_FULL_DATABASE pot importa in acest mod un fisier de export creat in modul export full database. Vezi Parametri de import pag. 2-12 pentru informatii asupra specificarii fiecarui mod. Un utilizator cu rolul IMP_FULL_DATABASE trebuie sa specifice una din aceste optiuni sau sa specifice un import incremental, altfel se genereaza un mesaj de eroare. Daca un utilizator fara rolul IMP_FULL_DATABASE esueaza sa specifice una din aceste optiuni, este efectuat un import la nivel user. Tabelul 1-1 la pag. 1-3 (Cap.1 Export) arata obiectele care sunt exportate si importate in fiecare mod. INTELEGEREA IMPORTULUI LA NIVEL TABELA SI PARTITIE Se pot importa tabele si partitii in urmatoarele moduri: Import la nivel tabela: Importa toate datele din tabelele specificate din fisierul de export Import la nivel partitie: Importa doar datele din partitiile specificate Trebuie setat parametrul IGNORE=Y atunci cand incarcati date in tabele existente. Vezi IGNORE pag 2-17 pentru informatii asupra parametrului IGNORE. IMPORT LA NIVEL TABELA Pentru fiecare tabela specificata, importul la nivel tabela importa toate randurile de date. La nivel tabela pot fi importate toate tabelele exportate prin orice mod de export (full, user sau tabela) utilizatorii pot importa tabele in intregul lor (partitionate sau nu) sau partitii dintr-un export la nivel tabela intr-o tabela tinta (partitionata sau nu) cu acelasi nume. Daca tabela nu exista, si daca tabela de export a fost partitionata, importul la nivel tabela creaza o tabela partitionata. Daca se reuseste crearea tabelei, importul la nivel tabela citeste toate datele din fisierul de export in tabela tinta. Dupa import tabela tinta contine definitiile de partitii ale tuturor partitiilor tabelei sursa din fisierul de export. Aceasta operatiune asigura mentinerea prin import a tuturor atributelor fizice si logice (inclusiv partitiile destinatie) ale partitiilor sursa. IMPORT LA NIVEL PARTITIE Se importa un set de partitii dintr-o tabela sursa intr-o tabela destinatie. Retineti urmatoarele puncte:

Intotdeauna

importul

memoreaza

randurile

in

concordanta

cu

schema

de

partitionare a tabelei destinatie. Importul la nivel partitie va permite sa incarcati selectiv date din partitia specificata dintr-un fisier de export. Importul la nivel partitie insereaza doar randurile de date din partitia sursa specificata. Daca tabela tinta este partajata, importul la nivel partitie rejecteaza toate randurile care sunt peste cea mai inalta partitie a tabelei tinta. Importul la nivel partitie poate fi specificat doar in mod tabela. Exportul si importul la nivel partitie asigura o modalitate de reunire a partitiilor in aceeasi tabela, chiar daca prin SQL nu se permite explicit reunirea (fuzionarea) partitiilor. Un DBA poate folosi importul la nivel partitie pentru a reuni partitia unei tabele in urmatoarea (cea mai inalta) partitie a aceluiasi sistem. Vezi Exemplul 2: Reunirea partitiilor unei tabele pag. 2-27 pentru un exemplu. Nivelul partitie al export si import nu asigura spargerea (impartirea) unei partitii. Pentru informatii despre spargerea unei partitii vezi Ghidul administratorului Oracle. Pentru informatii despre import vezi Folosirea nivelului tabela si partitie la la export si import pag 2-22. FOLOSIREA IMPOTULUI Aceasta sectiune descrie ce trebuie sa faceti inainte de a incepe un import si cum sa apelati utilitarul import. INAINTE DE A FOLOSI IMPORTUL Pentru a folosi importul trebuie rulat fie scriptul CATEXP.SQL fie CATALOG.SQL (care ruleaza CATEXP.SQL) dupa ce ati creat baza de date. Informatie suplimentara: Numele actual al scripturilor depinde de sistemul de operare. Numele lor si metoda de a fi rulate sunt descrise in documentatia Oracle specifica sistemului de operare. CATEXP.SQL sau CATALOG.SQL trebuie sa fie rulate doar o singura data pe o baza de date. Acestea realizeaza urmatoarele sarcini, pentru a pregati baza de date pentru import: asigneaza toate privilegiile necesare rolului IMP_FULL_DATABASE

asigneaza rolul IMP_FULL_DATABASE rolului DBA creaza vederile necesare dictionarului de date APELAREA IMPORTULUI

Importul se poate apela in trei moduri: Dati urmatoarea comanda: imp user/parola PARFILE=filename PARFILE este un fisier continand parametri de import pe care ii folositi de obicei. Daca folositi parametri diferiti pentru baze de date diferite puteti avea mai multe rfisiere de parametri. Aceasta este metoda recomandata. Vezi Fisierul de parametri pag. 2-8 pentru informatii despre cum sa folositi fisierul de parametri. Dati comanda: imp user/parola <parametri> unde inlocuiti <parametri> cu diferiti parametri pe care doriti sa-i folositi. Observati ca numarul de parametri nu poate depasi lungimea maxima a liniei de comanda pentru sistemul de operare. Dati comanda: imp user/parola pentru a incepe o sesiune interactiva, si a lasa utilitarul import sa ceara informatiile necesare. Observati ca metoda interactiva nu asigura suficienta functionalitate precum metoda pe baza de parametri. Ea exista din ratiuni de compatibilitate Obs: In mediu NT comanda este imp80 .... Se poate folosi o combinatie a primei si a celei de-a doua optiuni. Adica, puteti specifica parametri fie in fisierul de parametri, fie in linia de comanda. De fapt, se poate specifica acelasi parametru in ambele locuri. Pozitia parametrului PARFILE si alti parametri pe linia de comanda determina ce parametru suprascrie pe altul. De ex. sa presupunem ca fisierul de parametri params.dat contine parametrul INDEXES=Y si import este apelat cu urmatoarea linie de comanda: imp system/manager PARFILE=params.dat INDEXES=N In acest caz, pentru ca INDEXES=N apare dupa PARFILE=params.dat, INDEXES=N suprascrie valoarea parametrului INDEXES din fisierul de parametri. Se poate specifica numele de utilizator si parola in fisierul de parametri, dar totusi, din considerente de securitate, aceasta nu este recomandata. Daca omiteti numele de utilizator si parola, import le va cere.

Vezi Parametri import pag. 2-12 pentru o descriere a fiecarui parametru. APELAREA IMPORTULUI CA SYSDBA De obicei, nu ar trebui sa apelati importul ca SYSDBA. Totusi, daca folositi Tablespace Point-In-Time-Recovery (TSPITR) care va permite sa refaceti rapid una sau mai multe tablespace-uri, la un punct in timp diferit de al restului bazei de date, va trebui sa stiti cum sa o faceti. Atentie: Este recomandat sa cititi informatia despre TSPITR in Ghidul Oracle8 Backup si Recovery, POINT_IN_TIME_RECOVER pag. 2-19 si RECOVERY_TABLESPACES pag. 1-14, inainte de a continua cu aceasta sectiune. Pentru a apela Importul ca SYSDBA, folositi urmatoarea sintaxa: imp username/password AS SYSDBA sau, optional: imp username/passwordainstance AS SYSDBA Nota: Pentru ca sirul AS SYSDBA contine un blank, cele mai multe sisteme de operare necesita ca intregul sir username/password AS SYSDBA sa fie plasat intre ghilimele sau marcat ca literal, printr-o metoda oarecare. Observati ca anumite sisteme de operare necesita, de asemenea ca ghilimelele sa fie prefixate cu secvente escape. Vedeti documentatie specifica sistemului de operare pentru caracterele speciale si rezervate, pe sistemul de operare specific. Notati ca daca fie numele utilizatorului, fie parola sunt omise Import le va cere. Daca folositi importul in mod interactiv, nu veti fi intrebati pentru a specifica daca vreti sa va conectati ca SYSDBA sau ainstance impreuna cu numele utilizatorului. Obtinerea help-ului online Importul asigura help online. Introduceti imp help=y pe linia de comanda pentru a vedea ecranul de help, ca in ecranul de mai jos: > imp help=y Import: Release 8.0.4.0.0 - Product on Fri Nov 03 9:26:39 1997 (c) Copyright 1997 Oracle Corporation. All rights reserved. You can let Import prompt you for parameters by entering the IMP command followed by your username/pasword: Example: IMP SCOTT/TIGER

Or, you can control how Import runs by entering the IMP command followed by various arguments. To specify parameters, you use keywords: Format: IMP KEYWORD=value or KEYWORD=(value1,value2,...,valueN) Example: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) FULL=N or TABLES=(T1:P1,T1:P2), if T1 is partitioned table USERID must be first parameter on the command line. (USERID trebuie sa fie primul parametru in linia de comanda) Keyword Description (default) Keyword Description (default) USERID username/password FULL export entire file (N) BUFFER size of data buffer FROMUSER list of owner username FILE input file (EXPDAT.DMP) TOUSER list of usernames SHOW list file contents (N) TABLES list of table names IGNORE ignore create errors (N) RECORDLENGTH length of IO record GRANTS import grants (Y) INCTYPE incremental import (Y) INDEXES import indexes (Y) COMMIT commit array insert(N) ROWS import data rows (Y) PARFILE parameter filename LOG log file of screen output DESTROY overwrite tablespace data file (N) INDEXFILE write table/index info to specified file CHARSET character set of export file (NLS_LANG) POINT_IN_TIME_RECOVER Tablespace Point-in-time Recovery (N) SKIP_UNUSABLE_INDEXES skip maintenance of unusable indexes (N) ANALYZE execute ANALYZE statements in dump file (Y) FEEDBACK display progress every x rows (0) VOLSIZE number of bytes in file on each volume of a file on tape Import terminated succesfully without warnings. FISIERUL DE PARAMETRI Fisierul de parametri va permite sa specificati parametri de Import intr-un fisier unde pot fi usor modificati sau reutilizati. Creati fisierul de parametri folosind orice editor de text (Notepad, Edit). Optiunea linie de comanda PARFILE=filename spune lui Import sa citeasca parametri din fisierul specificat, in loc sa-i citeasca din linia de comanda. De ex: imp PARFILE=filename sau imp username/password PARFILE=filename Sintaxa pentru specificatia fisierului de parametri este una din urmatoarele: KEYWORD=value KEYWORD=(value) KEYWORD=(value1, value2, ....) Se pot adauga comentarii intr-un fisier de parametri prin precedarea parametrului cu semnul pound (A). Toate caracterele la dreapta semnului pound (A) sunt ignorate. Urmatorul exemplu arata o portiune din fisierul de parametri:

FULL=Y FILE=DBA.DMP GRANTS=Y INDEXES=Y A import all indexes CONSISTENT=Y Vezi Parametri Import pag. 2-12 pentru descrierea fiecarui parametru. PRIVILEGII NECESARE PENTRU A FOLOSI IMPORTUL Aceasta sectiune descrie privilegiile de care aveti nevoie pentru a folosi utilitarul Import si pentru a importa obiecte in schema proprie sau in schema altor utilizatori. PRIVILEGII DE ACCES Pentru a folosi importul, aveti nevoie de privilegiul CREATE SESSION pentru a va loga la un server Oracle8. Acest privilegiu apartine rolului CONNECT, stabilit la crearea bazei de date. Puteti efectua un import chiar daca nu dvs. ati creat fisierul de export. Totusi, daca fisierul de export a fost creat de cineva cu rolul EXP_FULL_DATABASE, nu puteti importa acel fisier decat daca aveti rolul IMP_FULL_DATABASE. IMPORTUL OBIECTELOR IN SCHEMA PROPRIE Tabelul 2-1 afiseaza privilegiile necesare pentru a importa obiecte in propria schema. Initial, toate aceste privilegii apartin rolului RESOURCE. Tabelul 2-1: Privilegii necesare pentru a importa obiecte in propria schema: Obiect clustere database link Privilegiu CREATE CLUSTER si tablespace quota, sau UNLIMITED TABLESPACE CREATE DATABASE LINK CREATE SESSION pe baza la distanta CREATE TRIGGER CREATE INDEX tablespace quota, sau UNLIMITED TABLESPACE ALTER TABLE CREATE ANY LIBRARY CREATE PROCEDURE CREATE SYNONYM Tip privilegiu sistem sistem sistem sistem sistem sistem sistem obiect sistem sistem sistem

trigere indexes si: constrangeri integritate librarii package-uri sinonime private de

secvente instantanee (snapshots) functii memorate proceduri memorate date in tabele definitii de tabele (inclusiv comentarii si optiuni de auditare) vederi obiecte tipuri librarii de externe

CREATE SEQUENCE CREATE SNAPSHOT CREATE PROCEDURE CREATE PROCEDURE INSERT TABLE CREATE TABLE tablespace quota, sau UNLIMITED TABLESPACE CREATE VIEW SELECT pe tabela de baza, sau SELECT ANY TABLE CREATE TYPE CREATE LIBRARY

sistem sistem sistem sistem obiect sistem sistem sistem obiect sistem sistem sistem

si si

functii

IMPORTUL GRANTURILOR Pentru a importa privilegii pe care un user le-a acordat altor useri, userul care initiaza importul trebuie, fie sa detina obiectele, sau sa aiba privilegii obiect cu WITH GRANT OPTION. Tabela 2-2 arata conditiile necesare pentru ca autorizarile (stabilirea granturilor) sa fie valide pe sistemul tinta. Tabela 2-2 Privilegii necesare importului granturilor Grantul privilegii obiect Conditia Obiectul trebuie sa existe in schema utilizatorului, sau utilizatorul trebuie sa aiba privilegiul obiect cu WITH GRANT privilegii sistem OPTION. Utilizatorul trebuie sa aiba privilegiul sistem impreuna cu WITH ADMIN OPTION. IMPORTUL OBIECTELOR IN SCHEMA ALTOR UTILIZATORI Pentru a importa obiecte in schema altor utilizatori trebuie sa aveti activat rolul IMP_FULL_DATABASE. IMPORTUL OBIECTELOR SISTEM Pentru a importa obiecte dintr-un fisier export full database, trebuie sa aveti activat rolul IMP_FULL_DATABASE. Parametrul FULL arata ca aceste obiecte sistem sunt incluse in import atunci cand un fisier export este un full export. profile legaturi publice intre baze de date

10

sinonime publice roluri definitii de segmente rollback optiuni audit la nivel sistem privilegii sistem definitii de tablespace-uri definitii de utilizatori aliasuri pe directoare PRIVILEGII UTILIZATOR

Atunci cand definitiile de utilizatori sunt importate intr-o baza de date Oracle, utilizatorii sunt creati cu comanda CREATE USER. Astfel, la importul din fisiere export create de versiuni precedente ale Export, utilizatorilor nu li se acorda automat privilegiul CREATE SESSION. IMPORTUL IN TABELE EXISTENTE Aceasta sectiune descrie factorii de care trebuie tinut cont atunci cand importati date in tabele existente. CREAREA MANUALA A TABELELOR INAINTE DE IMPORTUL DATELOR Atunci cand alegeti sa creati manual tabele inainte de a importa date in ele dintr-un fisier de export, ar trebui fie sa folositi exact aceeasi definitie a tabelei, fie sa folositi un format compatibil. De ex., in timp ce mariti o coloana si concomitent le schimbati ordinea, nu puteti face urmatoarele: sa adaugati coloane NOT NULL sa schimbati tipul de date al unei coloane la un tip incompatibil (LONG la NUMERIC, de exemplu) sa schimbati definitiile tipurilor de obiecte folosite in tabela DEZACTIVAREA CONSTRANGERILOR REFERENTIALE In ordinea normala de import, constrangerile referentiale sunt importate doar dupa ce toate tabelele sunt importate. Aceasta ordine previne erorile care ar putea apare daca ar exista o constrangere referentiala de integritate pentru date care nu ar fi fost inca

11

importate. Totusi, aceste erori pot sa apara atunci cand importati date in tabele existente. De ex. daca tabela EMP are o constrangere referentiala de integritate pe coloana MGR, care verifica daca exista marca managerului in tabela EMP, un rand de angajat, perfect valabil ar putea esua la verificarea constrangerii daca randul managerului sau nu ar fi deja importat. Atunci cand apare o astfel de eroare, Import genereaza un mesaj de eroare, elimina randul necorespunzator, si continua importul celorlalte randuri in tabela. Pentru a evita o astfel de situatie puteti dezactiva manual constrangerile. Constrangerile referentiale intre tabele pot de asemenea sa cauzeze probleme. De ex., daca tabela AEMP apare inainte de tabela BDEPT in fisierul de export, dar exista o constrangere de integritate din tabela AEMP in tabela BDEPT, anumite randuri din tabela AEMP ar putea sa nu fie importate datorita violarii constrangerii referentiale. Pentru a preveni astfel de erori, ar trebui sa dezactivati constrangerile referentiale de integritate atunci cand importati date in tabele existente. CONDUCEREA MANUALA A IMPORTULUI Atunci cand reactivati constrangerile dupa import, intreaga tabela este verificata, ceea ce poate lua mult timp pentru o tabela mare. Daca timpul necesar pentru aceste verificari este prea mare, ar putea fi benefic sa conduceti manual importul. Pentru a realiza aceasta, faceti mai multe importuri dintr-un fisier de export, in loc de a face doar un singur import. Prima data importati tabelele care sunt tinta a constrangerilor referentiale, inainte de a importa tabelele care le refera. Aceasta optiune functioneaza atunci cand tabelele nu se refera unele pe altele intr-o maniera circulara, si daca tabela nu se refera la ea insasi. PARAMETRI IMPORT Urmatoarea diagrama arata sintaxa pentru parametri care pot fi specificati in fisierul de parametri sau pe linia de comanda. Continuarea acestei sectiuni descrie fiecare parametru

12

ANALYZE Implicit: Y Specifica daca utilitarul Import sa executre sau nu comanda SQL ANALYZE, gasita in fisierul de export BUFFER Implicit: dependent de sistemul de operare Marimea buferului este marimea, in octeti, a bufferului prin care sunt transferate randurile. Parmetrul BUFFER (marimea bufferului) determina numarul de randuri in tabela inserata de import. Urmatoarea formula da o aproximare a marimii bufferului care insereaza o anumita tabela (de randuri): buffer_size = rows_in_array * maximum_row_size Pentru tabelele continand coloane de tipul LONG, LOB, BFILE, REF, ROWID, randurile sunt introduse individual. Marimea bufferului trebuie sa fie suficienta pentru a contine intregul rand, cu exceptia coloanelor LOB. Daca bufferul nu poate pastra cel mai mare rand dintr-o tabela, import incearca sa aloce un buffer mai mare. Informatie suplimentara: Vezi documentatia Oracle specifica sistemului de operare pentru a determina valoarea implicita a acestui parametru. CHARSET Implicit: none (nici unul)

13

Nota: Acest parametru se aplica doar fisierelor export Oracle versiunea 5 si 6. Fisierele de export Oracle versiunea 5 si 6 nu contin identificatorul setului de caractere NLS. Totusi, versiunile 5 si 6 indica daca setul de caractere al sesiunii utilizator a fost ASCII sau EBCDIC. Folositi acest parametru pentru a indica setul actual de caractere folosit la momentul exportului.. Utilitarul Import va verifica atunci cand setul de caractere al sesiunii utilizator (import) este ASCII, daca fisierul de export este in ASCII, si similar pentru EBCDIC. Folosirea acestui parametru nu este recomandata. Este asigurat doar pentru motive de compatibilitate cu versiunile precedente. Posibil ca in versiunile ulterioare sa nu mai fie admis. Daca folositi un fisier export Oracle7 sau Oracle8, setul de caractere este specificat in interiorul fisierului de export, si se realizeaza conversia automata la setul de caractere al bazei de date. Specificarea acestui parametru serveste doar ca verificare pentru a fi siguri ca setul de caractere al exportului se potriveste valorii asteptate. Daca nu se potriveste, se genereaza un mesaj de eroare. COMMIT Implicit: N Specifica daca Import sa execute commit dupa insertul fiecarui bloc. Implicit, Import face commit dupa incarcarea fiecarei tabele, si importul efectueaza un rollback daca apare o eroare, inainte de a continua cu urmatorul obiect. Daca o tabela are coloane tabele imbricate sau atribute, continutul tabelelor imbricate este importat ca tabele separate. De aceea, continutul tabelelor imbricate este intotdeauna commit-at intr-o tranzactie distincta de tranzactia folosita pentru a face commit pe tabela externa. Daca avem COMMIT=N si tabela este partitionata, fiecare partitie din fisierul de export este importata intr-o tranzactie separata. Specificand COMMIT=Y se previne ca segmentele de rollback sa creasca necontrolat, si imbunatateste performantele importurilor mari. Specificarea COMMIT=Y este recomandata pentru tabele care au constrangere de unicitate. Daca importul este

reluat, orice rand care deja a fost importat este rejectat, cu o eroare nefatala. Observati ca, daca tabela nu are o constrangere de unicitate, si specificati COMMIT=Y, Import ar putea conduce la duplicari de randuri atunci cand ati relua importul datelor. Pentru tabele continand coloane LONG, LOB, BFILE, REF, ROWID, nu sunt realizate

14

inserturi pe blocuri. Daca specificati COMMIT=Y, Importul realizeaza commit pentru aceste tabele dupa fiecare rand. DESTROY Implicit: N Specifica daca fisierele existente din aranjamentul bazei de date sa fie reutilizate sau nu. Adica, parametrul DESTROY specifica daca importul va folosi optiunea reuse din clauza comenzii CREATE TABLESPACE. Fisierul de export contine numele fisierelor de date folosite in fiecare tablespace. Daca incercati sa creati o a doua baza de date pe aceeasi masina (pentru testari sau alte scopuri), utilitarul import va suprascrie fisierele de date ale bazei de date originale, atunci cand va crea tablespace-urile. Acest lucru nu este de dorit!. Cu acest parametru setat pe N (valoarea implicita), se genereaza o eroare daca fisierele de date deja exista atunci cand se creaza tablespace-ul. Pentru a elimina aceasta eroare atunci cand importati intr-o baza de date auxiliara, creati anterior tablespace-ul si specificati fisierele lui de date. (Specificand IGNORE=Y eliminati eroarea de creere a tablespace-ului care deja exista - l-ati creat anterior). Pentru a elimina eroarea atunci cand importati in baza de date originala, specificati IGNORE=Y pentru a adauga la fisierele de date existente, fara a le inlocui. Pentru a refolosi fisierele originale ale bazei de date dupa eliminarea continutului lor, specificati DESTROY=Y. Nota: Daca ati creat anterior tablespace-urile necesare, trebuie sa specificati DESTROY=N altfel tablespace-urile anterior create vor fi pierdute. Atentionare: Daca fisierele de date sunt memorate in raw device-uri, DESTROY=N nu impiedica suprascrierea fisierelor de date!!!! FEEDBACK Implicit: 0 (zero) Specifica daca importul va afisa un indicator de progres sub forma unui punct pentru n randuri importate De ex., daca specificati FEEDBACK=10, import va afisa un punct de fiecare data cand sunt importate 10 randuri. Valoarea FEEDBACK se aplica tuturor tabelelor importate; nu poate fi setat la nivel de tabela importata, ci la nivel de sesiune de import. FILE Implicit: expdat.dmp

15

Numele fisierului de export care urmeaza sa fie importat. Nu este necesar sa fiti utilizatorul Oracle care a exportat fisierul. Totusi, e necesar sa aveti acces curent pe fisier. Extensia implicita este .dmp dar se poate specifica orice extensie. FROMUSER Implicit: none (nici unul) O lista a schemelor continand obiectele de importat. Implicit, pentru utilizatorii fara rolul IMP_FULL_DATABASE este importul in mod user. Adica, sunt importate obiectele pentru utilizatorul curent. (Daca parametrul TABLES este de asemenea specificat, este executat un import la nivel tabela). Atunci cand se importa in mod user, toate celelalte obiecte din fisierul de export sunt ignorate. Efectul este acelasi ca in cazul in care fisierul de export ar fi creat in mod user (sau mod tabela). Vezi tabela 1-1 pag 1-3 pentru lista obiectelor care sunt importate in mod user si mod tabela. De ex. urmatoarea comanda trateaza fisierul de export ca si cum ar fi un simplu export in mod user al obiectelor lui SCOTT: imp system/manager FROMUSER=scott Daca utilizatorul SCOTT nu exista in baza de date curenta, obiectele lui vor fi importate in schema importatorului - in acest caz, schema lui system. Altfel (SCOTT exista), obiectele sunt importate in schema lui SCOTT. Daca este indicata o lista de scheme, fiecare schema poate fi specificata doar o data. Urmatorul exemplu arata un import din doua scheme: imp system/manager FROMUSER=scott, blake Nota: Specificand FROMUSER=SYSTEM nu importa obiectele sistem. Aceasta

specificatie importa doar acele obiecte care apartin utilizatorului SYSTEM. Atunci cand FROMUSER este specificat si TOUSER lipseste, obiectele lui FROMUSER sunt importate inapoi lui FROMUSER. Totusi, daca schema specificata in FROMUSER nu exista in baza de date curenta, obiectele sunt importate in schema importatorului. Pentru a importa obiectele system (de ex. definitii de utilizatori si tablespace-uri), trebuie sa importati dintr-un fisier de full export, specificand FULL=Y. FULL Implicit: N Specifica daca sa se importe intregul fisier de export. GRANTS Implicit: Y

16

Specifica daca sa se importe granturile pe obiecte. Implicit, utilitarul Import importa toate granturile pe obiecte care au fost exportate. Daca exportul a fost un export in mod user, fisierul de export contine numai primul nivel de granturi-obiect (cele asigurate de proprietar). Daca exportul a fost in mod fulldatabase, fisierul de export contine toate granturile-obiect, inclusiv granturile low-level (cele asigurate de utilizatori care au privilegiul WITH GRANT OPTION). Daca specificati GRANTS=N, utilitarul Import nu importa granturile pe obiecte. (Retineti ca granturile system sunt importate char daca GRANTS=N). Nota: Exportul nu exporta granturile pe dictionarul de views-uri, pentru ratiuni de securitate, care ar afecta Importul. Daca aceste granturi ar fi exportate, privilegiile de acces ar fi schimbate, si utilizatorul nu ar fi atentionat despre aceasta. Altfel, nefortand granturile la import permite utilizatorului mai multa flexibilitate pentru a fixa granturile potrivite la import. HELP Implicit: N Afiseaza o descriere a parametrilor de import. IGNORE Implicit: N Specifica cum trebuie tratate erorile de creere ale obiectelor. Daca specificati IGNORE=Y (Obs: Y apare in documentatie, dar cred ca trebuie sa fie N!), Import va afisa erorile de creere atunci cand incearca sa creeze obiecte ale bazei de date. Daca specificati IGNORE=Y, Import continua fara a raporta vreo eroare (de creere a obiectelor). Daca acceptati valoarea implicita IGNORE=N, Import scrie in log si/sau afiseaza eraorea de creere a obiectelor inainte de a continua. Pentru tabele, IGNORE=Y cauzeaza ca randurile sa fie importate in tabele existente. Nu va fi dat nici un mesaj. IGNORE=N cauzeaza o raportare a erorii, si tabela este sarita, daca ea exista deja. Observati ca sunt ignorate doar erorile de creere ale obiectelor, alte erori, ex. ale sistemului de operare, ale bazei de date, erori SQL nu sunt ignorate si pot cauza oprirea procesului de import. In situatii unde sunt efectuate mai multe importuri dintr-un singur fisier de export, cu IGNORE=Y, anumite obiecte ar putea fi create de mai multe ori (cu toate ca ele vor avea nume unice). Se poate preveni aceasta, pentru anumite obiecte (de ex.

17

constrangeri)

prin

efectuarea

unui

export

in

mod

tabela

cu

parametrul

CONSTRAINTS=N. Observati ca, daca faceti un export complet cu parametrul CONSTRAINTS setat pe N, nu va fi exportata nici o constrangere pentru nici o tabela. Daca vreti sa importati date intr-o tabela care deja exista - posibil pentru ca vreti sa folositi noi parametrii de memorare (storage parameters), sau pentru ca ati creat tabela intr-un cluster, specificati IGNORE=Y. Utilitarul Import va importa randurile de date in tabele existente. Atentionare: Atunci cand importati in tabele existente, daca nici o coloana din tabela nu este indexata unic, randurile ar putea fi dublate, daca deja sut prezente in tabela. (Aceasta atentionare se aplica doar importurilor ne-incrementale. Importurile incrementale inlocuiesc tabela de la ultimul export complet si apoi o reconstruiesc pana la ultima stare salvata, dintr-o serie de exporturi cumulative si incrementale). INCTYPE Implicit: nedefinit Specifica tipul exportului incremental. Optiunile sunt: SYSTEM Importa cea mai recenta versiune a obiectelor sistem. Trebuie sa fisier de export incremental atunci cand folositi importa librariile de functii externe si utilizatorului sau obiecte. specificati cel mai recent aceasta optiune. Un import SYSTEM RESTORE

definitiile de tipuri de obiecte, dar nu importa datele continute in fisierul de export.

Importa toate obiectele bazei de date aferente utilizatorului si datele

Vezi Importul incremental, cumulativ si complet al fisierelor de export pag. 2-43 pentru mai multe informatii despre parametrul INCTYPE. INDEXES Implicit: Y Specifica daca indecsii vor fi importati sau nu. Indecsii generati de sistem, ca indecsii LOB, OID, sau indecsii pentru constrangeri de unicitate sunt re-creati de import functie de setarea acestui parametru. Daca indecsii pentru tabela tinta exista deja, Import asigura intretinerea (actualizarea) lor atunci cand sunt inserate datele in tabele. Se poate amana crearea tuturor indecsilor generati de utilizator pana la terminarea importului prin specificarea INDEXES=N. INDEXFILE

18

Implicit: nici unul Specifica un fisier pentru primirea comenzilor de creere a indecsilor. Atunci cand acest parametru este specificat, comenzile de creere a indecsilor pentru modul cerut sunt extrase si scrise in fisierul specificat, in locul celor folosite pentru a crea indecsii in baza de date. Tabelele si alte obiecte ale bazei de date nu sunt importate. Fisierul poate fi apoi editat (de ex. pentru a modifica parametrii de memorare) si folosit ca un script SQL pentru a crea indecsii. Pentru a face mai usor de identificat indecsii definiti in fisier, comenzile CREATE TABLE si CREATE CLUSTER sunt incluse ca si comentarii. Parcurgeti urmatorii pasi pentru a folosi aceasta facilitate: 1. Importati folosind parametrul INDEXFILE pentru a crea un fisier cu comenzile de creere a indecsilor 2. Editati fisierul, adaugand o parola valida la stringul de conectare. 3. Rulati din nou importul, specificand INDEXES=N. (Acest pas importa obiectele bazei de date in timp ce importul este impiedicat sa foloseasca definitiile de indecsi memorate in fisierul de export) 4. Executati fisierul cu comenzile de creere a indecsilor ca un script SQL, pentru a crea indecsii. Parametrul INDEXFILE poate fi folosit numai impreuna cu parametrul FULL=Y, FROMUSER, TOUSER, sau TABLES. LOG Implicit: nici unul Specifica un fisier care inregistreaza mesajele de informare si eroare. Daca specificati un fisier de log, utilitarul import scrie toate informatiile in fisierul de log, si pe ecran. PARFILE Implicit: nedefinit Specifica un fisier care contine o lista cu parametrii de import. Pentru mai multe informatii asupra folosirii unui fisier de parametri vezi Fisierul de parametri pag. 2-8. POINT_IN_TIME_RECOVER Implicit: N Indica daca import sa refaca una sau mai multe tablespace-uri la un punct in timp precedent, fara sa afecteze restul bazei de date. Pentru mai multe informatii vezi Oracle8 Ghidul Backup si Recovery

19

RECORDLENGHT Implicit: dependent de sistemul de operare Specifica lungimea, in octeti, a inregistrarii in fisier. Parametrul RECORDLENGHT este necesar atunci cand trebuie sa transferati fisierul de export pe un alt sistem de operare care foloseste o alta valoare implicita. Daca nu definiti acest parametru, el trece la valoarea implicita platformei pentru BUFSIZ. Pentru mai multe informatii despre valoarea implicita a lui BUFSIZ, vezi documentatia specifica sistemului de operare. Se poate seta valoarea lui RECORDLENGHT la orice valoare egala sau mai mare celei a lui BUFSIZ (specifica sistemului de operare). Cea mai mare valoare este 64k. Schimbarea parametrului RECORDLENGHT afecteaza numai marimea datelor care se acumuleaza inaintea scrierii pe disc. Nu afecteaza marimea file block size, a sistemului de operare. Nota: puteti folosi acest parametru pentru a specifica marimea bufferului I/O de export. Informatie suplimentara: Vezi documentatia Oracle specifica sistemului de operare pentru a determina valoarea potrivita sau pentru a crea un fisier cu o marime diferita a inregistrarii. ROWS Implicit: Y Specifica daca sa importati sau nu randurile de date. SHOW Implicit: N Atunci cand specificati SHOW, continutul fisierului de export este afisat la consola, si nu este importat. Declaratiile SQL continute in fisierul de export sunt afisate in ordinea in care import le va executa. Parametrul SHOW poate fi folosit doar impreuna cu parametri FULL=Y, FROMUSER, TOUSER, sau TABLES SKIP_UNUSABLE_INDEXES Implicit: N Specifica daca Import sa treaca peste constructia indecsilor care au fost trecuti in starea Index neUtilizabil (IU), fie de catre sistem, fie de catre utilizator. Vezi ALTER SESSION SET SKIP_UNUSABLE_INDEXES=TRUE in Manualul Oracle8 SQL. Alti indecsi (netrecuti anterior ca Index neUtilizabil), vor fi actualizati in continuare, pe masura ce se adauga randuri.

20

Acest parametru va permite sa amanati actualizarea indecsilor selectati pana dupa inserarea randurilor de date. Apoi aveti responsabilitatea sa refaceti indecsii afectati. Puteti folosi parametrul INDEXFILE impreuna cu INDEXES=N pentru a obtine scripturi SQL pentru recreerea indecsilor. Fara acest parametru ar esua inserarea randurilor care ar determina actualizarea indecsilor neutilizabili. TABLES Implicit: nici una Specifica o lista de nume de tabele pentru a fi importate. Folositi un asterisc (*) pentru a indica toate tabelele. Cand este folosit, acest parametru initiaza un import mod tabela, care restrictioneaza importul la tabele si obiectele lor asociate, precum e listat in tabelul 1-1 la pag. 1-3. Numarul tabelelor care pot fi specificate depinde de limitarile marimii liniei de comanda. Orice import la nivel de tabela sau la nivel de partitie incearca sa creeze o tabela partitionata cu aceleasi nume de partitii ca tabela exportata, inclusiv numele formurilor SYS_Pnnn. Daca exista o tabela cu acelasi nume, procesarea este dependenta de setarea parametrului IGNORE. Daca nu aveti setat SKIP_UNUSABLE_INDEXES=Y, inserarea randurilor exportate in tabela tinta esueaza daca Import nu poate actualiza un index nepartitionat sau un index partitionat, care este marcat ca Index neUtilizabil. Cu toate ca la export se poate numi tabela prin prefixul schemei (ca in SCOTT.EMP), nu puteti face asa atunci cand importati. In exemplul urmator, parametrul TABLES este specificat incorect: imp system/manager TABLES=(jones.accts, scott.emp, scott.dept) Specificatiile valide pentru a importa aceste tabele sunt: imp system/manager FROMUSER=jones TABLES=(accts) imp system/manager FROMUSER=scott TABLES=(emp, dept) Daca este specificat TOUSER, obiectele lui SCOTT sunt memorate in schema specificata prin TOUSER. Daca utilizatoruul SCOTT nu exista in baza de date curenta, tabelele lui sunt importate in schema importatorului, system, in exemplul precedent. Informatie suplimentara: Anumite sisteme de operare, ca de ex. UNIX necesita folosirea caracterelor escape inaintea caracterelor speciale, ca de ex paranteze, astfel incat caracterul sa nu fie tratat ca un caracter special. Pe UNIX folositi un backslash (i) pe post de caracter escape, cum se arata in exemplul urmator: TABLES=i(EMP, DEPTi) RESTRICTII ASUPRA NUMELUI TABELELOR

21

Numele tabelelor specificate pe linia de comanda sau in fisierul de parametri nu pot contine semnul pound (A), doar daca numele tabelei este inclus intre ghilimele. De ex., daca fisierul de parametri contine urmatoarea linie, import interpreteaza tot ce urmeaza pe linie dupa EMPA ca un comentariu. Ca rezultat, DEPT si MYDATA nu vor fi importate. TABLES=(EMPA, DEPT, MYDATA) Totusi, daca fisierul de parametri contine urmatoarea linie, utilitarul Import va importa toate cele trei tabele: TABLES=(EMPA, DEPT, MYDATA) Atentie: atunci cand specificati numele tabelei intre ghilimele, acesta este case sensitive. Numele tabelei trebuie sa se potriveasca exact cu numele memorat in baza de date. Implicit, numele din baza de date sunt memorate cu litere mari. Informatie suplimentara: Anumite sisteme de operare necesita ghilimele simple in locul ghilimelelor duble. Vezi documentatia Oracle, specifica sistemului de operare al dvs. TOUSER Implicit: nici unul Specifica o lista a utilizatorilor a caror schema va fi importata. E necesar rolul IMP_FULL_DATABASE pentru a folosi acest parametru. Pentru a importa intr-o schema diferita de cea in care era continut obiectul exportat specificati TOUSER. De ex.: imp system/manager FROMUSER=scott TOUSER=joe TABLES=emp Daca sunt specificate scheme multiple, numele de scheme trebuie sa fie perechi. Urmatorul exemplu importa obiectele lui SCOTT in schema lui JOE, si obiectele lui FRED in schema lui TED: imp system/manager FROMUSER=scott,fred TOUSER=joe,ted Nota: Daca lista FROMUSER este mai lunga decat lista TOUSER, se poate folosi urmatoarea sintaxa pentru a ne asigura ca orice obiect suplimentar merge in schema lui TOUSER: imp system/manager FROMUSER=scott,fred TOUSER=ted,ted Observati ca userul Ted este listat de doua ori. USERID Implicit: nedefinit Specifica userul/parola (si optional stringul de conectare) al utilizatorului care realizeaza importul. Atunci cand folositi refacerea tablespace-ului la un moment de timp, USERID poate fi:

22

username/password AS SYSDBA sau username/passwordainstance AS SYSDBA Vezi Apelarea importului ca SYSDBA pag. 2-6 pentru mai multe informatii. Observati ca, sistemul dvs. de operare ar putea cere sa tratati AS SYSDBA ca un sir special, cerand sa includeti intregul sir intre ghilimele, cum e specificat la pag. 2-7. Optional puteti specifica clauza astring_de_conectare pentru NET8. Vezi ghidul utilizatorului pentru protocolul NET8. Vezi de asemenea Sisteme distribuite de baze de date Oracle. FOLOSIREA EXPORTULUI SI IMPORTULUI LA NIVEL TABELA SI NIVEL PARTITIE Atat Exportul la nivel tabela cat si la nivel partitie pot migra datele prin tabele si partitii. GHID PENTRU FOLOSIREA IMPORTULUI LA NIVEL PARTITIE Aceasta sectiune asigura informatii detaliate despre Importul la nivel partitie. Pentru informatii generale vezi Intelegerea importului la nivel tabela si la nivel partitie pag. 2-4. Importurile la nivel partitie nu pot importa o tabela nepartitionata. Totusi, o tabela partitionata poate fi importata dintr-o tabela exportata ca tabela nepartitionata folosind importul la nivel tabela. Importul la nivel partitie este legal numai daca tabela sursa a fost partitionata si exista in fisierul de export. daca numele partitiei nu este o partitie valida in fisierul de export, Import genereaza o atentionare. Numele partitiei din clauza se refera doar la partitia din fisierul exportat, care poate sa nu contina toate datele din intreaga tabela exportata. Daca ROWS=Y (implicit), si tabela nu exista pe sistemul tinta unde se face importul, toate randurile partitiei specificate din tabela vor fi inserate in aceeasi partitie din tabela pe tabela tinta. Daca ROWS=Y (implicit), dar tabela deja exista inainte de import, toate randurile pentru partitia specificata in tabela vor fi inserate in tabela tinta. Daca tabela tinta este partitionata, Import va raporta fiecare rand care va fi rejectat pentru ca esueaza la testul de cea mai inalta partitie a tabelei tinta.

23

MIGRAREA DATELOR PRIN PARTITII SI TABELE Prezenta unui nume_tabela:nume_partitie impreuna cu parametrul TABLES conduce la citirea din fisierul de export doar a datelor din partitia sursa specificata. Daca nu specificati numele partitiei intreaga tabela este folosita ca sursa. Importul emite o atentionare daca partitia specificata nu este in lista partitiilor din tabela exportata. Datele exportate din una sau mai multe partitii pot fi importate in una sau mai multe partitii. Importul insereaza randuri in partitii pe baza criteriului de partitionare din baza de date de import. In exemplul urmator, utilitarul import importa randuri de date din partitia sursa py a tabelei scott.b in partitia py a tabelei tinta scott.b, dupa ce tabela si partitiile ei sunt create: imp system/manager FILE=export.dmp FROMUSER=scott TABLES=b:py Urmatorul exemplu face importul randurilor de date a partitiilor qc si qd a tabelei scott.e in tabela scott.e imp scott/tiger FILE=export.dmp TABLES=(e:qc, e:qd) IGNORE=y Daca tabela e nu exista pe sistemul tinta de import, ea este creata si datele sunt inserate in aceleasi partitii. Daca tabela e exista pe sistemul tinta inainte de import, randurile de date sunt inserate in partitiile al caror rang permite inserarea. Randurile de date pot ajunge in nume de partitii diferite de qc si qd. Nota: Prin importul la nivel partitie, intr-o tabela existenta, trebuie sa aranjati corespunzator partitiile tinta si sa folositi parametrul IGNORE=Y. COMBINAREA MAI MULTOR PARTITII INTR-O SINGURA PARTITIE Unirea partitiilor permite ca datele din mai multe partitii sa fie unite intr-o singura partitie pe sistemul tinta. Pentru ca partitiile sunt recreate identic cu cele din tabela exportata atunci cand IGNORE=N, unirea partitiilor reuseste doar atunci cand IGNORE=Y si tabela partitionata exista pe sistemul tinta. Urmatorul exemplu presupune prezenta fisierului de export (exp.dmp) continand o tabela partitionata c care are partitiile qa, qb si qc. Anterior importului, tabela tinta c este creata cu partitii, inclusiv partitia qc. Partitia qd este creata cu un rang al partitiei care poate primi date din partitiile qa si qb a tabelei sursa c. imp mary/lamb FILE=exp.dmp TABLES=(c:qa, c:qb) IGNORE=Y Aceasta comanda in mod linie cauzeaza Importul partitiilor qa si qb a tabelei mary.c in partitia qd a tabelei mary.c de pe sistemul tinta. Vezi Exemplul 2: unirea partitiilor unei tabele pag. 2-27 pentru un exemplu

24

suplimentar despre unirea partitiilor. RECONFIGURAREA PARTITIILOR Se poate folosi exportul si importul la nivel partitii pentru a reconfigura partitii. Se parcurg urmatorii pasi: 1. Exportul tabelei pentru a salva datele 2. Alterarea tabelei cu noua schema de partitionare 3. Importul datelor De exemplu, un utilizator poate muta date care au fost anterior memorate in partitia P1 si P2 din tabela T in partitii de rang diferit a tabeli T pe acelasi sistem. Sa presupunem ca tabela sursa T are alte partitii in afara de P1 si P2. Sa presupunem ca partitiile tinta sunt numite P1, P2, P3, si P4. Urmatorii pasi pot fi utilizati: 1. Exportul datelor din partitiile P1, P2 a tabelei T (sau exportul tabelei T) 2. Alterati tabela prin realizarea urmatoarelor: Comanda SQL: ALTER TABLE T DROP PARTITION pentru P1 si P2 Comanda SQL: ALTER TABLE T ADD PARTITION pentru P1, P2, P3, si P4 Importati datele din partitiile exportate P1 si P2 (sau importati tabela T) cu IGNORE=Y. Daca tabela tinta este partitionata, Import va rejecta toate randurile care sunt sub cea mai inalta partitie a tabelei tinta. EXEMPLE DE SESIUNI DE IMPORT Aceasta sectiune da cateva exemple de sesiuni de import care va arata cum sa folositi fisierul de parametri si metoda liniei de comanda. Exemplele ilustreaza patru scenarii: tabele importate de un administrator in aceeasi schema din care ele au fost exportate. tabele importate de un user din schema altuia in schema proprie a utilizatorului. tabele importate de catre un administrator intr-o schema diferita. tabele importate folosind importul la nivel partitie EXEMPLU SPECIFICAT In acest exemplu, folosind un export full database, un administrator importa tabelele DEPT si EMP in schema lui SCOTT. Daca schema lui SCOTT nu exista, tabelele sunt importate in schema lui SYSTEM DE IMPORT AL TABELELOR PENTRU UN UTILIZATOR

25

Metoda fisierului de parametri imp system/manager parfile=params.dat Fisierul params.dat contine urmatoarele informatii: FILE=dba.dmp SHOW=n IGNORE=n GRANTS=Y FROMUSER=scott TABLES=(dept,emp) Metoda liniei de comanda imp system/manager file=dba.dmp fromuser=scott tables=(dept,emp) Mesaje ale importului Import: Release 8.0.4.0.0 - Production on Mon Nov 7 10:22:12 1997 (c) Copyright 1997 Oracle Corporation. All rights reserved. Connected to: Oracle8 Server Release 8.0.4.0.0 - Production PL/SQL Release 8.0.4.0.0 - Production Export file created by EXPOTT:V08.00.03 via conventional path . importing SCOTTs objects into SCOTT .. importing table DEPT 4 rows imported .. importing tabel EMP 14 rows imported Import terminated succesfully without warnings. EXEMPLU DE IMPORT AL TABELELOR EXPORTATE DE UN ALT UTILIZATOR Acest exemplu ilustreaza importul tabeleor UNIT si MANAGER dintr-un fisier exportat de BLAKE in schema lui SCOTT. Metoda fisierului de parametri imp scott/tiger parfile=params.dat Fisierul params.dat contine urmatoarele informatii: FILE=blake.dmp SHOW=n IGNORE=n GRANTS=Y ROWS=y FROMUSER=blake TOUSER=scott TABLES=(unit, manager) Metoda liniei de comanda imp scott/tiger fromuser=blake tables=(unit,manager) Mesaje ale importului touser=scott file=blake.dmp

Import: Release 8.0.4.0.0 - Production on Mon Nov 7 10:22:12 1997 (c) Copyright 1997 Oracle Corporation. All rights reserved.

26

Connected to: Oracle8 Server Release 8.0.4.0.0 - Production PL/SQL Release 8.0.4.0.0 - Production Export file created by EXPOTT:V08.00.04 via conventional path Warning: the objects were exported by BLAKE, not by you . importing BLAKEs objects into SCOTT .. importing table UNIT 4 rows imported .. importing tabel MANAGER 4 rows imported Import terminated succesfully without warnings. EXEMPLU DE IMPORT AL TABELELOR UNUI UTILIZATOR IN SCHEMA ALTUIA In acest exemplu, un DBA importa toate tabelele apartinand lui SCOTT in schema lui BLAKE. Metoda fisierului de parametri imp system/manager parfile=params.dat Fisierul params.dat contine urmatoarele informatii: FILE=scott.dmp FROMUSER=scott TOUSER=blake TABLES=(*) Metoda liniei de comanda imp system/manager file=scott.dmp fromuser=scott touser=blake tables=(*) Mesaje ale importului Import: Release 8.0.4.0.0 - Production on Mon Nov 7 10:22:12 1997 (c) Copyright 1997 Oracle Corporation. All rights reserved. Connected to: Oracle8 Server Release 8.0.4.0.0 - Production PL/SQL Release 8.0.4.0.0 - Production Export file created by EXPOTT:V08.00.04 via conventional path Warning: the objects were exported by SCOTT, not by you . importing BLAKEs objects into SCOTT .. importing table BONUS 0 rows imported .. importing tabel DEPT 4 rows imported .. importing table EMP 14 rows imported .. importing tabel SALGRADE 5 rows imported Import terminated succesfully without warnings. EXEMPLU DE SESIUNE DE IMPORT FOLOSIND IMPORTUL LA NIVEL PARTITIE Aceasta sectiune descrie cum sa folositi Importul la nivel partitie pentru a partitiona o tabela nepartitionata, cum sa uniti partitiile unei tabele, si sa repartitionati o tabela dupa o coloana diferita. Exemplele din aceasta sectiune presupun ca exista urmatoarele tablespace-uri:

27

tbs_e1, tbs_e2, tbs_e3 tbs_d1, rbs_d2, tbs_d3 Exemplul 1: Partitionatea unei tabele nepartitionate

Efectuati urmatorii pasi pentru a partitiona o tabela nepartitionata: 1. Exportati tabela, pentru a salva datele. 2. Dati drop pe tabela. 3. Creati tabela, dar cu partitii 4. Importati datele din tabela. Urmatorul exemplu va arata cum sa partitionati o tabela nepartitionata: exp scott/tiger tables=emp file=empexp.dmp . . . About to export specified table via Conventional Path ... .. exporting table EMP 14 rows exported Export terminated succesfully without warnings. . . . SQL> drop table emp cascade constraints; Table dropped. SQL> create table emp 2 ( 3 empno number(4) not null, 4 ename varchar2(10), 5 job varchar2(9) 6 mgr number(4), 7 hiredate date, 8 sal number(7,2), 9 comm number(7,2), 10 deptno number(2) 11 ) 12 partition by range (empno) 13 ( 14 partition emp_low values less than (7600) 15 tablespace tbs_e1, 16 partition emp_mid values less than (7900) 17 tablespace tbs_e2, 18 partition emp_high values less than (8100) 19 tablespace tbs_e3 20 ); Table created SQL> exit Imp scott/tiger tables=emp file=empexp.dmp ignore=Y . .. Export file created by EXPORT:V08.00.03 via conventional path . importing SCOTTs objects into SCOTT

28

.. importing table EMP 14 rows imported Import terminated succesfully without warnings Urmatoarele declaratii SELECT va arata ca datele sunt partitionate dupa coloana empno SQL> select empno from EMPNO ----7369 7499 7521 7566 4 rows selected. SQL> select empno from EMPNO -----7654 7698 7782 7788 7839 7844 7876 7 rows selected SQL> select empno from EMPNO ----7900 7902 7934 3 rows selected Exemplul 2: Unirea aratat in exemplul 1. Efectuati urmatorii pasi pentru a uni partitiile unei tabele: 1. Exportati partitiile pe care vreti sa le uniti. Aceasta va salva datele. 2. Alterati tabela prin stergerea partitiilor pe care vreti sa le uniti. 3. Importati partitiile pe care vreti sa le uniti. Urmatorul exemplu va arata cum sa uniti partitiile unei tabele: exp scott/tiger tables=emp:emp_mid file=empprt.dmp . .. About to export specified tables via Conventional Path ... .. exporting table EMP .. exporting partition Emp_MID 7 rows exported Export terminated succesfully without warnings. . . emp partition (emp_low);

emp partition (emp_mid);

emp partition (emp_high);

partitiilor unei tabele

Acest exemplu presupune ca tabela EMP are trei partitii, dupa coloana EMPNO, cum s-a

29

. SQL> alter table emp drop partition emp_mid; Table altered. . . . imp scott/tiger fromuser=scott tables=emp:emp_mid file empprt.dmp ignore=y . . . Export created by EXPORT:V08.00.04 via conventional path . importing SCOTTs objects into SCOTT .. importing partiton EMP:EMP_MID 7 rows imported Import terminated succesfully without warnings. Urmatoarele declaratii SQL arata datele din partitia stearsa EMP_MID acum unite in partitia EMP_HIGH: SQL> select empno from emp partition (emp_low); EMPNO ----7369 7499 7521 7566 4 rows selected. SQL> select empno from emp partition (emp_high); EMPNO ----7654 7698 7782 7788 7839 7844 7876 7900 7902 7934 10 rows selected Exemplul 3: Repartitionarea unei tabele dupa o coloana diferita Acest exemplu presupune ca tabela EMP are doua partitii, dupa coloana EMPNO, dupa cum a rezultat din exemplul 2. Acest exemplu repartitioneaza tabela EMP dupa coloana DEPTNO. Efectuati urmatorii pasi pentru a repartitiona o tabela dupa o coloana diferita: 1. Exportati tabela pentru a salva datele. 2. Stergeti tabela din baza de date. 3. Creati tabela cu noile partitii.

30

4. Importati datele din tabela originala. Urmatorul exemplu va arata cum sa repartitionati o tabela dupa o coloana diferita: exp scott/tiger tables=emp file=empexp.dat . . . About to export specified tables via Conventional Path ... . exporting table EMP .. exporting partition EMP_LOW 4 rows exported .. exporting partition EMP_HIGH 10 rows exported Export terminated successfully without warnings. . . . SQL> drop table emp cascade constraints; Table dropped. SQL> create table emp 2 ( 3 empno number(4) not null, 4 ename varchar2(10), 5 job varchar2(9) 6 mgr number(4), 7 hiredate date, 8 sal number(7,2), 9 comm number(7,2), 10 deptno number(2) 11 ) 12 partition by range (deptno) 13 ( 14 partition dept_low values less than (15) 15 tablespace tbs_d1, 16 partition dept_mid values less than (25) 17 tablespace tbs_d2, 18 partition dept_high values less than (35) 19 tablespace tbs_d3 20 ); Table created SQL> exit Imp scott/tiger tables=emp file=empexp.dmp ignore=Y . .. Export file created by EXPORT:V08.00.04 via conventional path . importing SCOTTs objects into SCOTT .. importing partition EMP:EMP_LOW 4 rows imported .. importing partition EMP:EMP_HIGH 10 rows imported Import terminated succesfully without warnings Urmatoarele declaratii SELECT va arata ca datele sunt partitionate dupa coloana DEPTNO: SQL> select empno, deptno from emp partition (dept_low); EMPNO DEPTNO ----------

31

7934 10 7782 10 7839 10 3 rows selected. SQL> select empno, deptno from emp partition (dept_mid); EMPNO DEPTNO -----------7369 20 7566 20 7902 20 7788 20 7876 20 5 rows selected. SQL> select empno, deptno from emp partition (dept_high); EMPNO DEPTNO ---------7499 30 7521 30 7900 30 7654 30 7698 30 7844 30 6 rows selected. FOLOSIREA METODEI INTERACTIVE Apelarea importului din linia de comanda fara nici un parametru initiaza metoda interactiva. Aceasta metoda nu asigura intrebari (prompturi) pentru toate functionalitatile Import. Metoda interactiva este asigurata din ratiuni de compatibilitate cu versiunile precedente. Daca nu specificati un user/parola pe linia de comanda, utilitarul Import cere aceste informatii. Urmatorul exemplu ilustreaza metoda interactiva: imp system/manager Import: Release 8.0.4.0.0 - Production on Fri Nov 7 10:11:37 1997 (c) Copyright 1997 Oracle Corporation. All rights reserved. Connected to: Oracle8 Server Release 8.0.4.0.0 - Production PL/SQL Release 8.0.4.0.0 - Production Import file: expdat.dmp > Enter insert buffer size (minimum is 4096) 30720 > Export file created by EXPORT:V08.00.04 via conventional path Warning: the objects were exported by BLAKE, not by you List contents of import file only (yes/no): no > Ignore create error due to object existence (yes/no): no > Import grants (yes/no): yes > Import table data (yes/no): yes > Import entire export file (yes/no): no > y . importing BLAKEs objects into SYSTEM .. importing table DEPT 4 rows imported .. importing table MANAGER 3 rows imported

32

Import terminated succesfully without warnings. S-ar putea sa nu puteti vedea toate intrebarile (prompturile) intr-o anumita sesiune Import, pentru ca anumite intrebari depind de raspunsurile dvs. la alte intrebari. Anumite intrebari afiseaza un raspuns implicit; daca acesta este acceptabil, apasati sENTERt Nota: Daca specificati N la intrebarea urmatoare, Import intreaba pentru un nume de schema si numele tabelelor pe care vreti sa le importati pentru acea schema: Enter table (T) or partition (T:P) names. Null list means all tables for user Introducerea unei liste nule de tabele determina importul tuturor tabelelor. Se poate specifica doar o schema la un moment dat, atunci cand folositi metoda interactiva. APELAREA INTERACTIVA A IMPORTULUI CA SYSDBA In mod normal nu ar trebui sa aveti nevoie sa apelati interactiv Importul ca SYSDBA. Totusi, daca folositi Refacerea Tablespace-urilor la momente de timp (TSPITR), care va permite sa refaceti rapid una sau mai multe tablespace-uri la momente de timp diferite de restul bazei de date, trebuie sa stiti cum sa realizati aceasta. Atentie: Este recomandabil sa cititi informatiile despre TSPITR in ghidul Oracle8 Backup si Recovery, POINT_IN_TIME_RECOVER pag. 2-19, si RECOVERY_TABLESPACES pag 1-14. IMPORTUL EXPORTURILOR INCREMENTALE, CUMULATIVE SI COMPLETE Pentru ca un export incremental extrage doar tabelele care au fost modificate de la ultimul export complet, cumulativ sau incremental, un import dintr-un fisier de export incremental importa definitiile de tabele si toate datele nu doar randurile schimbate. Pentru ca importul dintr-un export incremental este dependent de metoda folosita la exportul datelor, trebuie sa recititi Exporturi incrementale, cumulative si complete pag 1-27. Este important sa observati ca, din cauza ca importul unui fisier de export incremental importa noua versiune a obiectelor existente, obiectele existente sunt sterse (drop) inainte ca cele noi sa fie importate. Aceasta comportare difera de cea de la importul normal. In timpul unui import normal, obiectele nu sunt sterse si se genereaza, in mod normal o eroare daca obiectele deja exista. RESTAURAREA UNUI SET DE OBIECTE

33

Este foarte importanta ordinea in care sunt facute exporturile incrementale, cumulative si complete. Un set de obiecte nu poate fi restaurat pana cand nu s-a rulat un export complet asupra bazei de date. Dupa ce s-a realizat aceasta, procesul restaurarii obiectelor urmeaza pasii descrisi mai jos: Nota: Pentru a restaura un set de obiecte, trebuie sa importati mai intai cel mai recent export incremental, pentru a importa obiectele sistem (prin specificarea INCTYPE=SYSTEM). Apoi trebuie sa importati fisierele export in ordine cronologica (adica sa specificati INCTYPE=RESTORE). 1. Importati cel mai recent export incremental (specificati INCTYPE=SYSTEM pentru import) sau cumulativ, daca ultimul export nu a fost incremental. 2. Importati cel mai recent fisier de export complet. 3. Importati, in ordine, toate exporturile cumulative efectuate dupa ultimul export complet. 4. Importati, in ordine, toate exporturile incrementale efectuate dupa ultimul export cumulativ. De ex., daca aveti urmatoarele: un export complet numit X1 doua exporturi cumulative, numite C1 si C2 trei exporturi incrementale numite I1, I2 si I3 INCTYPE=SYSTEM FULL=Y FILE=I3 INCTYPE=RESTORE FULL=Y FILE=X1 INCTYPE=RESTORE FULL=Y FILE=C1 INCTYPE=RESTORE FULL=Y FILE=C2 INCTYPE=RESTORE FULL=Y FILE=I1 INCTYPE=RESTORE FULL=Y FILE=I2 INCTYPE=RESTORE FULL=Y FILE=I3

atunci trebuie sa importati in urmatoarea ordine: imp system/manager imp system/manager imp system/manager imp system/manager imp system/manager imp system/manager imp system/manager Note:

Observati ca importati ultimul export incremental dse doua ori; o data la inceput pentru a importa cea mai recenta versiune a obiectelor sistem, si o data la sfarsit, pentru a aplica cele mai recente modificari asupra datelor utilizatorilor si obiectelor.

Atunci cand restaurati tabele cu aceasta metoda, ar trebui ca intotdeauna sa incepeti cu o baza de date curata (adica fara tabele utilizator) inainte de a incepe secventa de import. IMPORTUL OBIECTELOR TIP SI A LIBRARIILOR DE FUNCTII STRAINE DINTR-UN FISIER DE EXPORT INCREMENTAL

34

Doar pentru importurile incrementale obiectele tip si librariile de functii straine sunt tratate ca obiecte sistem. Adica, sunt importate doar definitiile lor, impreuna cu celelalte obiecte sistem, atunci cand INCTYPE=SYSTEM. Aceasta importa cea mai recenta definitie a obiectelor tip (inclusiv identificatorul obiectului) si cea mai recenta definitie a specificatiei librariei. Apoi, pe masura ce tabelele sunt importate din exporturi incrementale mai vechi, folosind INCTYPE=RESTORE, Importul verifica daca exista fiecare tip de obiect necesar tabelei si are acelasi identificator de obiect. Daca obiectul nu exista, sau daca exista, dar identificatorul sau de obiect nu se potriveste, tabela nu este importata. Aceasta arata ca tipul de obiect a fost sters (drop) sau inlocuit dupa ultimul export incremental, necesitand ca toate tabelele care depind de acel obiect sa fie sterse (drop). Daca un user are drept de executie la un tip de obiect si creaza o tabela continand date de acel tip, dar privilegiul execute a fost revocat ulterior, importul acelei tabele va esua. Utilizatorul trebuie sa aiba drept de executie pentru a importa cu succes o tabela care contine date de acest tip. CONTROLUL CREERII SI ACTUALIZARII INDECSILOR Aceasta sectiune descrie comportarea utilitarului Import asupra creerii si intretinerii indecsilor. CREAREA INDECSILOR SI CONTROALE ASUPRA INTRETINERII LOR Daca SKIP_UNUSABLE_INDEXES=Y, utilitarul Import amana actualizarea tuturor indecsilor care au fost setati pe starea Index neUtilizabil inainte de Import. Alti indecsi (nesetati inainte pe Index neUtilizabil) vor fi in continuare actualizati pe masura ce se adauga randuri. Aceasta comportare permite actualizarea indecsilor in timpul Importului si presupune ca utilizatorul poate da comanda potrivita ALTER INDEX pentru alti indecsi neacoperiti de lista de Export, inainte de a face importul. Intarzierea actualizarii indecsilor poate cauza violarea unei constrangeri de unicitate asigurata de index. Existenta unei constrangeri de unicitate pe o tabela nu previne existenta cheilor duplicate intr-o tabela care a fost importata cu INDEXES=N. Indexul care asigura aceasta va fi in starea neUtilizabil pana cand dublurile vor fi eliminate si

35

indexul este reconstruit. Tabela 2-3 este un sumar al rezultatului combinarilor parametrilor IGNORE si INDEXES la importul la nivel partitie. Import INDEXES=Y Creaz Amana a indecsilor INDEXES=N actualiz. Creaza Amana pentru index Nu indecsilor actualiz. pentru

index Indecsii neUtilizabili IGNORE=Y Existenti Nu Nu index inainte de import Inexiste Da N/A

Indecsii neUtilizabili Da

Nu Nu

N/A Da

nti IGNORE=N Existenti Eroar Eroare index inainte de import Inexiste Da nti AMANAREA CREERII INDECSILOR N/A e

Nu

N/A

Importul va asigura capacitatea intarzierii creerii indecsilor si a actualizarii pana dupa terminarea importului si inserarea randurilor de date. Realizarea (re)creerii sau actualizarii indecsilor dupa terminarea imporului este in general mai rapida decat actualizarea indecsilor dupa introducerea fiecarui rand de date. Crearea indexului poate fi o operatiune consumatoare de timp, si de aceea poate fi mai eficient sa fie facuta dupa terminarea importului tuturor obiectelor. Se poate amana crearea indecsilor globali si locali dupa terminarea importului prin specificarea INDEXES=N (INDEXES=Y este implicita) si INDEXFILE=nume_fisier. Comenzile de creere a indecsilor, care ar fi generate de import vor fi memorate in fisierul specificat. Dupa terminarea importului, trebuie sa creati indecsii, de obicei prin folosirea continutului fisierului (specificat prin INDEXFILE), ca un script SQL. Daca volumul total al actualizarii indecsilor este mai mic in timpul inserarii de date decat cel necesar refacerii indecsilor dupa import, utilizatorul poate alege sa actualizeze acesti indecsi in momentul introducerii datelor in tabele, prin setarea parametrului INDEXES=Y.

36

EXEMPLE DE AMANARE A ACTUALIZARII INDECSILOR De ex. sa presupunem ca tabela partitionata t cu partitiile p1 si p2 exista pe sistemul tinta de import. Presupunem ca indecsii locali p1_ind pe partitia p1 si p2_ind pe partitia p2 exista de asemenea. Presupunem ca partitia p1 contine un volum mult mai mare de date in tabela t, in comparatie cu volumul de date care va fi inserat din fisierul de Export (expdat.dmp). Presupunem ca pentru p2 este valabila situatia inversa (volum mic de date in tabela comparativ cu datele de inserat). Utilizatorul poate amana actualizarea indexului local pentru p2_ind in timpul importului prin folosirea urmatoorilor pasi: 1. dati urmatoarea comanda SQL inainte de import ALTER TABLE t MODIFY PARTITION p2 UNUSABLE LOCAL INDEXES; 2. dati urmatoarea comanda pentru Import: imp scott/tiger FILE=export.dmp TABLES = (t:p1, t:p2) IGNORE=Y SKIP_UNUSABLE_INDEXES=Y Acest exemplu executa o comanda ALTER SESSION SET SKIP_UNUSABLE_INDEXES=Y inainte de inceperea importului. 3. dati urmatoarea comanda SQL dupa Import: ALTER TABLE t MODIFY PARTITION p2 REBUILD UNUSABLE LOCAL INDEXES; In acest exemplu, indexul local p1_ind va fi actualizat pe masura incarcarii datelor in partitia p1 in timpul Importului. Indexul local p2_ind va fi actualizat la momentul refacerii indexului, dupa Import. REDUCEREA FRAGMENTARII BAZEI DE DATE O baza de date cu multe blocuri mici de spatii libere, blocuri necontigue este o baza fragmentata. O baza de date fragmentata ar trebui sa fie reorganizata pentru a face spatiu disponibil in blocuri mari, contigue. Se poate reduce fragmentarea prin realizarea unui export full-database, apoi import, precum urmeaza: 1. Faceti un export total (FULL=Y) pentru a salva intreaga baza de date. 2. Opriti serverul Oracle dupa ce au iesit toti utilizatorii din sesiune. Folositi comanda MONITOR in SQL*DBA sau Server Manager pentru a urmari activitatea utilizatorilor. 3. Stergeti baza de date. Vedeti documentatia specifica sistemului de operare pentru informatii asupra stergerii bazei de date. 4. Re-creati baza de date folosind comanda CREATE DATABASE. 5. Efectuati un import complet al bazei de date (FULL=Y) pentru a reface intreaga

37

baza de date. Vezi Ghidul administratorului Oracle8 pentru mai multe informatii asupra creerii bazei de date. MESAJE DE AVERTIZARE, EROARE SI TERMINARE Implicit Import afiseaza toate mesajele de eroare. Daca specificati un fisier log prin folosirea parametrului LOG, Import scrie mesajele de eroare si in fisierul de log pe masura ce le afiseaza pe ecran. Ar trebui ca intotdeauna cand realizati un import sa folositi un fisier de log. (Se poate redirecta iesirea lui Import intr-un fisier, pentru SO care permit redirectarea) Informatie suplimentara: Pentru informatii asupra parametrului LOG vezi LOG la pag. 2-19. Vezi, de asemenea documentatia specifica sistemului de operare pentru informatii asupra redirectarii iesirii. Atunci cand un import se termina fara erori, se emite mesajul Import terminated successfully without warnings. Daca apar una sau mai multe erori ne-fatale si Import a fost capabil sa continue apare mesajul Import terminated succesfully with warnings. Daca apare o eroare fatala Importul se termina imediat cu mesajul: Import terminated unsuccessfully. Informatie suplimentara: Mesajele sunt documentate in Mesajele Oracle8 si in documentatia specifica sistemului de operare. TRATAREA ERORILOR Aceasta sectiune descrie erorile care apar la importul obiectelor bazei de date. ERORI ASUPRA RANDURILOR Daca un rand este eliminat datorita violarii unei constrangeri de integritate sau unor date invalide, Import afiseaza un mesaj de avertizare dar continua prelucrarea restului tabelei. Anumite erori, ca de exemplu tablespace plin (tablespace full), se aplica tuturor randurilor urmatoare din tabela. Aceste erori determina importul sa opreasca prelucrarea tabelei curente si sa treaca la tabela urmatoare. ESUAREA LA CONSTRANGERI DE INTEGRITATE O eroare este generata daca un rand violeaza o constrangere de integritate activa pe sistemul dvs, incluzand

38

constrangeri not null constrangeri de unicitate constrangeri primary key (not nul si unique) constrangeri referentiale de integritate constrangeri de verificare (check constraints)

Vezi Ghidul dezvoltatorului de aplicatii Oracle8 si Concepte Oracle8 pentru mai multe informatii asupra constrangerilor de integritate. DATE INVALIDE Erori pot apare atunci cand definitia unei coloane din tabela bazei de date este diferita de definitia coloanei din fisierul de export. Eroarea este determinata de date care sunt prea lungi pentru a se potrivi in noua coloana din tabela, de tipuri de date invalide, sau de alte erori INSERT. ERORI LA IMPORTUL OBIECTELOR BAZEI DE DATE Erori pot sa apara din multe motive atunci cand importati obiecte ale bazei de date, dupa cum este descris in aceasta sectiune. Atunci cand astfel de erori apar, importul obiectului curent este intrerupt. Importul incearca sa continue cu urmatorul obiect al bazei de date, din fisierul de export. OBIECTUL EXISTA DEJA Daca obiectul de importat exista deja in baza de date, se genereaza o eroare de creere obiect. Ce urmeaza in continuare depinde de setarea parametrului IGNORE. Daca IGNORE=N (implicit), eroarea este raportata, si Import continua cu urmatorul obiect al bazei de date. Obiectul curent nu este inlocuit. Pentru tabele, aceasta comportare inseamna ca randurile continute in fisierul de export nu sunt importate. Daca IGNORE=Y, erorile de creere ale obiectelor nu sunt raportate. Cu toate ca obiectul bazei de date nu este inlocuit, daca obiectul este o tabela, randurile sunt importate in el. Observati ca numai erorile de creere obiecte sunt ignorate, toate celelalte erori, (ca de ex. ale sistemului de operare, ale bazei de date sau SQL) sunt raportate si prelucrarea se poate opri. Atentie: Specificarea IGNORE=N poate cauza duplicarea randurilor care se vor importa, daca una sau mai multe coloane ale tabelei nu sunt specificate cu constrangeri de unicitate. Aceasta ar putea apare, de exemplu, daca importul ar

39

fi rulat de doua ori. SECVENTE Daca numerele de secventa trebuie sa fie resetate la valoarea din fisierul de export, trebuie sa stergeti (drop) secventa. O secventa care nu este stearsa inainte de import nu este setata la valoarea capturata in fisierul de export, pentru ca importul nu sterge si recreaza o secventa care deja exista. Daca secventa exista, declaratia CREATE SEQUENCE din fisierul de export esueaza si secventa nu este importata. ERORI ALE RESURSELOR Limitele resurselor pot cauza sarirea obiectelor. Atunci cand importati tabele, de exemplu, erori ale resurselor pot sa apara ca rezultat al problemelor interne, sau la epuizarea unei resurse, ca de exemplu, memorie. Daca apare o eroare de resurse in timp ce se importa un rand, importul opreste prelucrarea tabelei curente si trece la tabela urmatoare. Daca ati specificat COMMIT=Y, importul scrie importul partial in tabela curenta. Daca nu, are loc un rollback a tabelei curente, inainte ca importul sa continue. (Vezi descrierea lui COMMIT pag. 2-14 pentru informatii asupra parametrului COMMIT). ERORI FATALE Atunci cand apare o eroare fatala Importul se termina. De exemplu, daca introduceti o combinatie user/parola incorecta, sau daca incercati sa rulati exportul sau importul fara sa fi rulat inainte CATEXP.SQL sau CATALOG.SQL, apare o eroare fatala si importul se termina. CONSIDERATII IN RETEA Aceasta sectiune descrie factorii de care trebuie sa tineti cont atunci cand folositi Exportul si Importul intr-o retea. TRANSPORTUL FISIERELOR DE EXPORT PRIN RETEA. Atunci cand transferati un fisier de export prin retea urmariti sa il transmiteti folosind un protocol care asigura integritatea fisierului. De exemplu, daca folositi un protocol FTP sau altul similar, transmiteti fisierul in mod binar. Transmiterea fisierului in mod caracter (ASCII) determina aparitia erorilor la importul fisierului. EXPORT SI IMPORT SUB NET8

40

Prin eliminarea granitelor dintre sisteme de operare si masini diferite, Net8 asigura un mediu de procesare distribuita pentru Oracle8. Net8 va permite sa exportati si importati intr-o retea. De ex. ruland local utilitarul Export, puteti scrie date dintr-o baza de date Oracle la distanta, intr-un fisier local de export. Ruland local Import puteti scrie date intr-o baza Oracle la distanta. Pentru a folosi Export sau Import cu Net8, trebuie sa includeti referinta spre baza de date (sirul de conectare) aconnect_string dupa user/parola, in comanda exp sau imp. Pentru sintaxa corecta a acestei comenzi vezi ghidul utilizatorului pentru protocolul Net8. Pentru mai multe informatii despre Net8 vezi Ghidul administratorului Net8 Vezi, de asemenea Sisteme de baze de date Oracle8 distribuite. IMPORT SI INSTANTANEE Cele trei obiecte in relatie intr-un sistem bazat pe instantanee sunt: tabela master, fisierul optional de log, si instantaneul propriu-zis. Tabelele (tabela master, tabela definitiilor logului (pt. instantaneu), si tabelele instantaneu) pot fi exportate independent unele de altele. Logul de instantaneu poate fi exportat doar daca exportati si tabela master asociata. Se pot exporta instantanee folosind exportul fulldatabase sau in mod user; nu puteti folosi exportul mod tabela pentru a exporta instantanee. Aceasta sectiune prezinta cum sunt afectate refreshurile rapide (instantaneele) atunci cand aceste obiecte sunt importate. Replicarea Oracle8 va ofera mai multe informatii despre instantanee si loguri de instantanee. TABELA MASTER Datele importate sunt inregistrate in logul de instantaneu daca tabela master exista pentru baza de date in care importati si ea are un log de instantaneu. LOGUL DE INSTANTANEU Atunci cand exportati un log de instantaneu, ROWID-urile memorate in logul de instantaneu nu mai au nici o semnificatie dupa import. Ca rezultat, fiecare prima incercare de reimprospatare rapida a ROWID de instantaneu esueaza, generand o eroare care va indica necesitatea unui refresh complet. Pentru a elimina eroarea de refresh, faceti un refresh complet dupa importul unui fisier

41

de log ROWID instantaneu. Dupa un refresh complet, urmatoarele refresh-uri rapide vor functiona corespunzator. In contrast, atunci cand un log de instantaneu este exportat, valorile primary key isi mentin semnificatia dupa import. Din acest motiv, instantaneele pe baza primary key pot efectua un refresh rapid dupa import. Vezi Replicare Oracle8 pentru informatii despre instantanee primary key. INSTANTANEE Un instantaneu care a fost refacut dintr-un fisier de export a mers inapoi in timp (has gone back in time) la o stare precedenta. La import, timpul ultimului refresh este importat, ca parte componenta a tabelei de definitie instantanee. Functia care calculeaza urmatorul moment de refresh este de asemenea importata. Fiecare refresh lasa o semnatura. Un refresh rapid, foloseste intrarile din log din momentul de timp al acelei semnaturi pentru a actualiza instantaneul. Atunci cand se termina fast refresh-ul, semnatura este stearsa si este creata o noua semnatura. Orice intrare in log care nu este necesara pentru a reimprospata alte instantanee este, de asemenea, stearsa. IMPORTUL UNUI INSTANTANEU Atunci cand refaceti un instantaneu dintr-un fisier de export, ati putea avea o problema, in anumite circumstante. Sa presupunem ca un instantaneu este reimprospatat la timpul A, exportat la timpul B, si reinprospatat din nou la momentul C. Atunci, datorita coruperii sau altor probleme, instantaneul trebuie refacut, prin stergerea lui si importare din fisierul de export. Cea mai noua versiune importata are inregistrat timpul improspatarii ca fiind momentul A. Totusi, intrari in log necesare unui refresh rapid ar putea sa nu mai existe. Daca ele exista (din cauza ca sunt necesare pentru alte instantanee care urmeaza sa fie reimprospatate), ele sunt utilizate, si refreshul rapid se incheie cu succes. In alte conditii, refreshul rapid esueaza, generand o eroare care avertizeaza ca este necesar un refresh complet. IMPORTUL UNUI INSTANTANEU INTR-O SCHEMA DIFERITA Instantaneele, logurile de instantaneu, si obiectele in relatie sunt exportate cu numele schemei dat explicit in comenzile DDL, din aceasta cauza, instantaneele si obiectele in relatie nu pot fi importate intr-o alta schema. Daca incercati sa utilizati FROMUSER/TOUSER pentru a importa un instantaneu , va fi generata o eroare, scrisa in fisierul de log si instantaneul nu va fi importat.

42

PARAMETRI DE MEMORARE Implicit, o tabela este importata in tablespace-ul original. Daca tablespace-ul nu mai exista, sau daca utilizatorul nu are o cota suficienta in tablespace, sistemul foloseste tablespace-ul implicit pentru acel utilizator, cata vreme tabela nu: este partitionata este o tabela tip contine coloane LOB

Daca utilizatorul nu are cota suficienta in tablespace-ul implicit, tabelele userului nu vor fi importate. (vezi Reorganizarea tablespace-urilor pag. 2-41 pt. a vedea cum puteti folosi aceasta in avantajul dvs). PARAMETRUL OPTIMAL Parametrul OPTIMAL de memorare pentru segmentele de rollback nu este pastrat in timpul exportului si importului. PARAMETRI DE MEMORARE PENTRU INDECSI OID SI COLOANE LOB Tabelele sunt exportate cu parametri lor curenti de memorare. Pentru tabele obiect, OIDINDEX este creat cu parametri curenti de memorare, si cu nume, daca este furnizat. Pentru tabelele care contin coloane LOB, datele LOB si indecsii LOB sunt creati cu parametri lor curenti de memorare. Daca utilizatorul modifica parametri de memorare ai tabelelor existente inainte de a fi exportate, tabelele sunt exportate folosind acei parametri modificati de memorare. Parametri de memorare pentru date LOB si indecsi LOB nu pot fi modificati. Observati ca datele si indecsi LOB ar putea sa nu se afle in acelasi tablespace cu tabelul care le contine. Tablespace-ul pentru aceste date trebuie sa fie /citit/scris la momentul importului, daca nu, tabela nu va fi importata. Daca datele LOB sau indecsii LOB se afla intr-un tablespace care nu ami exista la momentul importului sau utilizatorul nu are suficienta cota (quota) in tablespace, acea tabela nu va fi importata. Pentru ca pot fi mai multe clauze asupra tablespace-urilor, inclusiv una pentru tabela, Import nu poate determina din cauza carui tablespace nu a putut importa tabela. SUPRASCRIEREA PARAMETRILOR DE MEMORARE Fisierul de export include parametri de memorare ai tabelei, asa ca poate vreti sa pre-

43

creati tabele mari cu parametri de memorare diferiti, inainte de a importa datele. Daca da, trebuie sa specificati urmatoarea in linia de comanda, sau in fisierul de parametri: IGNORE=Y PARAMETRUL DE EXPORT COMPRESS Implicit, la momentul exportului parametri de memorare pentru tabele mari sunt ajustati pentru a consolida toate datele tabelei in extentul initial. Pentru a pastra marimea originala a extentului initial, trebuie sa specificati la momentul exportului ca extenturile nu vor fi consolidate (prin setarea COMPRESS=N). Vezi COMPRESS pag. 19 pentru o descriere a parametrului COMPRESS. TABLESPACE-URI READ-ONLY Tablespace-urile read-only pot fi exportate. La Import, daca tablespace-ul nu exista deja in baza de date tinta, el este creat ca un tablespace citire/scriere. Daca doriti functionalitate doar read-only, trebuie sa faceti manual, dupa import, tablespace-ul read-only. Daca tablespace-ul exista, si este deja read-only, trebuie sa-l faceti scriere/citire inainte de import. SEGMENTE ROLLBACK Atunci cand initializati (creati) o baza de date Oracle creaza un singur segment de rollback (numit SYSTEM). Oracle utilizeaza acest segment de rollback doar pentru tranzactii care manipuleaza obiecte din tablespace-ul SYSTEM. Totusi, daca vreti sa importati intr-un tablespace diferit, trebuie sa creati un nou segment de rollback. Aceasta restrictie nu se aplica daca doriti sa importati doar in tablespace-ul SYSTEM. Pentru detalii asupra creerii segmentelor de rollback vezi Ghidul administratorului Oracle8. STERGEREA UNUI TABLESPACE Se poate sterge un tablespace prin redefinirea obiectelor sa foloseasca un tablespace diferit inainte de import. Se poate da apoi comanda de import si sa specificati IGNORE=Y. In multe cazuri, se poate sterge un tablespace prin efectuarea unui export fulldatabase, apoi prin creerea unui tablespace cu zero-blocuri, cu acelasi nume (inainte de a face log off), ca tablespace-ul pe care doriti sa-l stergeti. In timpul importului, cu IGNORE=Y, comanda relevanta CREATE TABLESPACE va esua si prin asta se previne

44

createa tablespace-ului nedorit. Toate obiectele din acel tablespace vor fi importate in tablespace-urile implicite ale proprietarilor obiectelor, cu exceptia tabelelor partitionate, tabelelor tip si tabelelor care contin coloane LOB. Import nu poate determina care tablespace a cauzat eroarea. Pentru a preveni aceasta, utilizatorul trebuie sa creeze tabela si s-o importe din nou, specificand IGNORE=Y. Obiectele nu sunt importate in tablespace-ul implicit daca tablespace-ul nu exista sau daca utilizatorul nu are cota necesara pentru tablespace-ul implicit. REORGANIZAREA TABLESPACE-URILOR Daca prin cota se permite, tabelele utilizatorului sunt importate in acelasi tablespace ca cel din care au fost exportate. Totusi, daca tablespace-ul nu mai exista sau daca utilizatorul nu are cota suficienta, sistemul va folosi tablespace-ul implicit pentru acel utilizator, cata vreme tabelele nu sunt partitionate, nu contin coloane LOB si tabela nu este o tabela tip. Daca utilizatorul nu poate accesa tablespace-ul implicit, tabelele nu pot fi importate. Acest scenariu poate fi folosit pentru a muta un utilizator dintr-un tablespace in altul. De ex. doriti sa mutati tabelele lui JOE din tablespace-ul A in tablespace-ul B, dupa un export full-database. Urmati pasii de mai jos: 1. Daca JOE are privilegiul UNLIMITED TABLESPACE, revocati-l. Setati cota lui JOE pe tablespace-ul A la zero. De asemenea revocati toate rolurile care ar putea avea asemenea privilegii sau cote. Nota: Revocarea rolurilor nu cascadeaza. De aceea, utilizatorilor carora JOE le-a asignat alte roluri nu vor fi afectati. 2. Exportati tabelele lui JOE. 3. Stergeti tabelele lui JOE din tablespace-ul A. 4. Dati lui JOE cota pe tablespace-ul B si faceti-l tablespace-ul implicit. 5. Creati tabelele lui JOE in tablespace-ul B. 6. Importati tabelele lui JOE. (Implicit Import va pune tabelele lui JOE in tablespace-ul B) Nota: Un index pe o tabela este creat in acelasi tablespace cu tabela insasi, cata vreme nu exista deja. CONSIDERATII ASUPRA SETULUI DE CARACTERE SI NLS

45

Aceasta sectiune descrie comportarea lui Export si Import vizavi de setul de caractere si suportul pentru limba nationala (NLS). CONVERSIA SETULUI DE CARACTERE Utilitarul Export scrie fisierul de export folosind setul de caractere specificat pentru sesiunea utilizatorului, de ex. ASCII pe 7 biti, sau IBM Code Page 500 (EBCDIC). Sesiunea de import si setul de caractere al bazei de date tinta pot diferi de setul de caractere al bazei de date sursa. Aceasta necesita una sau mai multe operatii de conversie de seturi de caractere. Fisierul de export identifica schema de codare a caracterelor folosita. Daca este necesar, utilitarul Import va translata automat datele la setul de caractere a sistemului gazda. Import converteste datele la setul de caractere al sesiunii daca acesta este diferit de setul de caractere al exportului. Vezi Conversia setului de caractere pag 1-25 si 1-34 pentru o descriere asupra modului in care Export trateaza seturile de caractere. Import poate converti datele la setul de caractere al sesiunii utilizator numai daca raportul dintre lungimea celui mai extins / celui mai restrans caracter este 1. IMPORTUL SI SETURI DE CARACTERE PE UN OCTET Daca setul de caractere al fisierului de export este unul pe un octet, si daca setul de caractere pe baza de date tinta este de asemenea pe un octet, datele vor fi convertite automat la import, la schema de codare a sesiunii utilizator, specificata prin parametrul NLS_LANG. Dupa ce datele sunt convertite la setul de caractere al sesiunii, acestea vor fi convertite la setul de caractere al bazei de date. Anumite caractere pe 8 biti pot fi pierdute (adica vor fi convertite la echivalente pe 7 biti), atunci cand importati un fisier de export pe set de caractere pe 8 biti. Aceasta se intampla daca masina pe care are loc importul are un set nativ de caractere pe 7 biti, sau daca variabila de mediu NLS_LANG este setata la un set de caractere pe 7 biti. Mai des, aceasta se observa atunci cand caracterele cu accent pierd semnul accent. Pentru a preveni aceasta conversie nedorita, se poate seta variabila de mediu NLS_LANG la cea a setului de caractere de la export. Vedeti sectiunile Conversia setului de caractere pag. 1-34 si Seturi de caractere pe un octet la export si import pag. 1-35 pentru mai multe informatii. IMPORTUL SI SETURI DE CARACTERE MULTI-OCTET

46

Pentru seturi de caractere multi-octet, Importul poate converti datele la setul de caractere al sesiunii utilizator doar daca raportul dintre lungimea celui mai extins caracter / cel mai restrans caracter este 1. Daca acest raport nu este 1, setul de caractere al sesiunii utilizator trebuie sa se potriveasca cu setul de caractere al sesiunii de export, in asa fel incat import sa nu faca conversie. In timpul conversiei, orice caractere din fisierul de export care nu au corespondent in setul de caractere tinta vor fi inlocuite cu un caracter implicit. (Caracterul implicit este cel definit de setul de caractere tinta). Pentru a garanta o conversie 100%, setul de caractere tinta trebuie sa fie un supraset (sau echivalent) al setului de caractere sursa. Pentru mai multe informatii vezi sectiunea NLS - Suport de limba nationala in Referintele Oracle8. Pentru ca conversiile de seturi de caractere sunt mari consumatoare de timp de procesare, limitati aceste conversii la strictul necesar. Daca setul de caractere al sesiunii de import si al bazei de date tinta sunt aceleasi, dar difera de setul de caractere al bazei de date sursa, este necesara o conversie de set de caractere. Oracle8 poate exporta si importa tipuri de date NCHAR. Importul nu translateaza datele NCHAR, dar daca este necesar OCI va converti automat datele la setul national de caractere al serverului de import. CONSIDERATII ASUPRA IMPORTULUI OBIECTELOR BAZEI DE DATE Aceasta sectiune descrie comportarea unor obiecte ale bazei de date in timpul importului IMPORTUL IDENTIFICATORILOR OBIECTELOR Serverul Oracle8 asigneaza identificatori de obiecte pentru a identifica unic obiectele tip, obiectele tabele si randuri in obiectele tabele. Acesti identificatori de obiecte sunt pastrati prin import. Pentru obiectele tip, daca IGNORE=Y si obiectul tip deja exista si identificatorul de obiect se potriveste, nu este raportata nici o eroare. Daca identificatorul de obiect nu se potriveste, este raportata o eroare si nu este importata nici o tabela care foloseste obiecte de acel tip. Pentru obiectele tip, daca IGNORE=N si obiectele tip exista deja, este raportata o

47

eroare. Daca identificatorul de obiect nu se portiveste, toate tabelele folosind acele tipuri de obiecte nu vor fi importate. Pentru obiecte tabele, daca IGNORE=Y si tabela exista deja si daca identificatorul de obiect se potriveste, nu este raportata nici o eroare. Randurile sunt importate in tabela. Daca identificatorul de obiect nu se potriveste, este raportata o eroare si tabela nu este importata. Pentru obiecte tabele daca IGNORE=N si tabela exista deja, este raportata o eroare si tabela nu este importata. Pentru obiecte tabele, daca IGNORE=Y si daca tabela exista deja, si daca identificatorul obiectului tabela se portiveste, importul randurilor ar putea esua daca randuri cu acelasi identificator de obiect exista deja in tabela obiect. Pentru ca importul pastreaza identificatorii obiectelor pentru obiectele tip si obiectele tabela retineti urmatoarele considerente cand importati obiecte din schema unui utilizator in schema altui utilizator, folosind parametri FROMUSER si TOUSER: Daca obiectele tip si obiectele tabel ale lui FROMUSER exista pe sistemul tinta, apar erori pentru ca identificatorul obiectelor tip si obiectelor tabel ale lui TOUSER sunt deja in use. Obiectele tip si obiectele tabela ale lui FROMUSER trebuie sa fie sterse din sistem inainte de inceperea importului. Daca a fost creat un obiect tabela folosind optiunea OID AS pentru a asigna acelasi identificator de obiect ca al unei alte tabele, ambele tabele nu pot fi importate. Una poate fi importata, dar a doua primeste o eroare pentru ca identificatorul de obiect este deja folosit. IMPORTUL OBIECTELOR TABEL EXISTENTE SI A TABELELOR CARE CONTIN OBIECTE TIP Utilizatorii creaza frecvent tabele inainte de import pentru a reorganiza folosirea tablespace-urilor sau pentru a schimba parametrii de memorare. Tabela trebuie sa fie creata cu aceleasi definitii ca cea precedent folosita sau intr-un format compatibil (exceptie pentru parametrii de memorare). Pentru obiectele tabele si tabelele care contin coloane de obiecte tip, compatibilitatile de format sunt mai restrictive. Pentru obiectele tabel, acelasi tip de obiect trebuie sa fie specificat, si acel obiect trebuie sa aiba acelasi identificator de obiect ca originalul. Pentru tabele continand coloane de obiecte tip, trebuie sa fie specificat acelasi tip de obiect si acel tip trebuie sa aiba acelasi identificator de obiect ca si originalul. Export scrie informatiile despre tipurile obiect folosite de o tabela in fisierul de export,

48

inclusiv obiectele tip din scheme diferite. Obiectele tip din scheme diferite folosite drept coloane de nivel cel mai inalt sunt verificate la potrivirea numelui si a identificatorului de obiect la momentul importului. Obiectele tip din scheme diferite care sunt imbricate in interiorul altor obiecte tip nu sunt verificate. Daca obiectul tip deja exista, identificatorul sau de obiect este verificat. Importul retine informatia despre ce obiecte tip a creat, astfel incat daca un obiect tip este folosit de mai multe tabele, el este creat doar o data. In toate cazurile obiectul tip trebuie sa fie compatibil in termenii formatului intern folosit pentru memorare. Importul nu verifica daca formatul intern al unui tip este compatibil. Daca datele exportate nu sunt compatibile, rezultatele sunt imprevizibile. IMPORTUL TABELELOR IMBRICATE Pentru tabelele imbricate, informatia de memorare pentru tabela interioara este exportata cu o declaratie DDL separata, din creerea tabelei exterioare. Importul trateaza declaratiile multiple ca o singura operatiune indivizibila. Daca esueaza creerea tabelei exterioare, nu mai este executata nici informatia despre memorare a tabeli interioare. Daca creerea tabelei exterioare reuseste, dar crerea oricarei tabele interne esueaza, intreaga tabela este stearsa si datele nu sunt importate. Daca tabela exterioara exista si IGNORE=Y, tabela de memorare interna nu este creata. Pentru ca tabelele interioare imbricate sunt importate separat de tabela externa, incercarea de a accesa date din ele pe perioada importului poate produce rezultate neasteptate. De ex. daca un rand exterior este accesat inainte ca randurile sale interioare sa fie importate, importul intoarce un rand incomplet utilizatorului. Tabelele imbricate interioare sunt exportate separat de tabela exterioara. De aceea pot aparea diverse situatii cand datele din tabela imbricata interioara ar putea sa nu fie corespunzator importate. Sa presupunem ca o tabela cu o tabela interioara imbricata este exportata si apoi importata fara sa se stearga tabela sau sa se elimine randuri din tabela. Daca este folosit parametrul IGNORE=Y, va apare o violare de constrangere atunci cand se insereaza fiecare rand din tabela exterioara. Totusi, datele din tabela interioara ar putea fi importate cu succes, rezultand duplicarea randurilor in tabela interioara. Daca apar erori fatale la inserarea datelor in tabela exterioara, restul datelor din tabela exterioara este sarit, dar randurile corespunzand tabelelor interioare nu vor fi sarite. Aceasta poate duce ca randuri din tabela interioara sa nu fie referite de nici un rand din tabela exterioara.

49

Daca un insert intr-o tabela interioara esueaza dupa o eroare nefatala, randurile tabelei exterioare vor fi deja inserate in tabela exterioara si datele vor continua sa fie inserate in ea si orice tabela interioara ei. Aceasta determina un rand logic partial.

Daca apare o eroare fatala la inserarea datelor intr-o tabela interioara importul sare restul acelei tabele interioare dar nu sare tabela exterioara sau alta tabela imbricata.

Trebuie sa examinati intotdeanuna cu atentie fisierul de log pentru a analiza erorile in tabele exterioare si interioare. Pentru a deveni consistente tabelele imbricate poate ca trebuie modificate sau sterse. IMPORTUL DATELOR REF

Coloanele si atributele REF pot contine un ROWID ascuns care indica pre o referinta tip. Importul nu recalculeaza in mod automat aceste ROWID-uri pentru baza de date tinta. Trebuie sa executati urmatoarea comanda pentru a reseta ROWID la valorile corespunzatoare: ANALYZE TABLE sschema.ttable VALIDATE REF UPDATE Vezi manualul Referinte SQL Oracle8 pentru mai multe informatii despre comanda ANALYZE TABLE. IMPORTUL DATELOR ARRAY Atunci cand importul prelucreaza coloane sau atribute array, el aloca buffere pentru a cuprinde un masiv folosind cele mai mari dimensiuni care ar putea fi asteptate pentru coloana sau atribut. Daca dimensiunile maxime ale masivului depasesc cu mult memoria folosita, importul ar putea esua datorita epuizarii memoriei. IMPORTUL COLOANELOR BFILE SI A ALIASULUI DE DIRECTOARE Exportul si importul nu copiaza datele referite de coloanele BFILE si atributele din baza de date sursa in baza de date tinta. Exportul si importul doar propaga numele fisierelor si a aliasurilor de directoare referite de coloanele BFILE. Este responsabilitatea lui DBA sau a utilizatorului de a muta fisierele actuale referite prin coloanele si atributele BFILE. Atunci cand importati tabele care contin coloane BFILE, locatorul BFILE este importat impreuna cu aliasul de director si numele de fisier care a fost prezent la momentul exportului. Importul nu verifica daca aliasul de director sau fisierul exista. Daca aliasul de director sau fisierul nu exista, apare o eroare atunci cand utilizatorul acceseaza datele BFILE. Daca sintaxa folosita in fisierul de export pentru aliasul de directoare la nivelul sistemului de operare nu este valida pe sistemul de import, nu este raportata nici o

50

eroare la momentul importului. Urmatoarele accesari ale datelor vor genera erori. Este responsabilitatea lui DBA sau a utilizatorului sa se asigure ca aliasul de directoare este valid pe sistemul de import. IMPORTUL LIBRARIILOR DE FUNCTII STRAINE Importul nu verifica daca locatiile referite de libraria de functii straine este corecta. Daca formatul pentru numele de directoare si fisiere folosite in specificatiile librariei la export sunt invalide pe sistemul de import, nu este raportata nici o reoare la momentul importului. Urmatoarele apeluri ale functiilor vor genera erori. Este responsabilitatea lui DBA sau a utilizatorului sa mute manual librariile si sa se asigure ca specificatia de librarie este valida pe sistemul de import. IMPORTUL PROCEDURILOR MEMORATE, A FUNCTIILOR SI A PACKAGEURILOR Atunci cand este importata o procedura memorata, o functie sau un package, ea retine stampila originala de timp. Procedura, functia sau package-ul este recompilat dupa import. Daca rezultatul compilarii este succes, poate fi apelat de proceduri la distanta fara erori. Procedurile sunt exportate dupa tabele, vederi si sinonime, de aceea compilarea lor are in general succes, cata vreme toate dependintele lor vor exista deja. Totusi, procedurile, functiile si package-urile nu sunt exportate intr-o ordine a dependentelor. Daca o procedura, functie sau package depinde de o procedura, functie sau package care este memorata ulterior in fisierul de export, aceasta nu va fi compilata cu succes. Utilizarile ulterioare vor cauza o recompilare automata, si daca aceasta reuseste, va schimba stampila de timp. Aceasta ar putea cauza erori in procedurile la distanta care le apeleaza. IMPORTUL TABELELOR COZI AVANSATE (AQ) Importul unei cozi importa de asemenea orice tabela coada de legatura si tabelele dictionar aferente. O coada poate fi importata numai la nivelul de granularitate al tabelei coada. Atunci cand o tabela coada este importata procedura de export pretabela si post-tabela mentine dictionarul cozii. IMPORTUL COLOANELOR LONG Coloanele LONG pot avea lungime de pana la 2 Gigaocteti. La import si export coloanele LONG trebuie sa se potriveasca in memorie cu restul fiecarui rand de date. Totusi, memoria folosita pentru coloanele LONG nu este necesar sa fie contigua, pentru ca datele sunt incarcate in sectiuni.

51

IMPORTUL VEDERILOR Vederile sunt exportate in ordinea dependentei. In anumite cazuri, Exportul trebuie sa determine ordonarea, in loc sa obtina aceasta ordine de la serverul bazei de date. Pentru aceasta, Export nu poate fi totdeauna capabil sa refaca ordinea corecta, aparand erori de compilare atunci cand o vedere este importata. In particular, daca VIEWA foloseste procedura stocata PROCB si PROCB foloseste vederea VIEWC, Export nu poate determina ordinea corecta a lui VIEWA si VIEWC. Daca VIEWA este exportata inainte de VIEWC si PROCB deja exista pe sistemul de import, VIEWA receptioneaza erori de compilare (de avertizare) la momentul importului. Granturile pe vederi sunt importate chiar daca apar erori de compilare. O vedere poate avea erori de compilare daca un obiect de care depinde, ca de ex. o tabela, procedura sau alta vedere, nu exista atunci cand vederea este creata. Daca o tabela de baza nu exista, serverul nu poate valida ca grantorul are privilegiile necesaare pe tabela de baza cu GRANT OPTION. Din aceasta cauza pot apare violari de acces atunci cand vederea este folosita, daca grantorul nu are privilegiile potrivite dupa ce tabela care lipsea este creata. GENERAREA STATISTICILOR PE DATELE IMPORTATE Parametrul de export STATISTICS controleaza generarea statisticilor in timpul importului. Atunci cand specificati fie optiunea COMPUTE fie ESTIMATE al parametrului STATISTICS, toti indecsii, tabelele si clusterele care au aplicat ANALYZE sunt exportate impreuna cu comenzile necesare pentru a genera statisticile potrivite (estimate sau calculate) la import. Se poate seta parametrul de import ANALYZE la N pentru a preveni importul de a genera statistici. Nota: Generarea statisticilor este limitata la acele obiecte care le-au avut inainte de export. Acestea nu sunt generate automat pentru fiecare pentru fiecare index, tabela si cluster din baza de date ca rezultat al acestei optiuni. Daca de obicei folositi statistici, fie estimate fie calculate, este o idee buna sa folositi parametrul STATISTICS de fiecare data cand folositi exportul. Costurile (ca timp si spatiu) la export sunt neglijabile - statisticile nu sunt inregistrate in fisierul de export, doar comanda pentru a le genera. Implicit este STATISTICS=ESTIMATE. Vezi Concepte Oracle8 pentru mai multe informatii asupra optimizatorului. Prin folosirea parametrului STATISTICS in timpul exportului, va asigurati ca statisticile

52

corespunzatoare sunt generate atunic cand datele sunt importate. Daca fisierul de export a fost creat fara acest parametru, sau daca ati schimbat metoda de colectare a statisticilor folositi parametrul import INDEXFILE pentru a genera o lista a obiectelor importate. Apoi, editati aceasta lista pentru a produce o seri de comenzi ANALYZE asupra lor si executati scriptul SQL rezultat. (pentru mai multe informatii vezi INDEXFILE pag 2-18). FOLOSIREA FISIERELOR DE EXPORT ORACLE7 Aceasta sectiune da indicatii si prezinta restrictiile care se aplica atunci cand importati date dintr-o baza de date Oracle7 pe un server Oracle8. Informatii suplimentare pot fi gasite in Migrare Oracle8. CONSTRANGERI CHECK PE COLOANE TIP DATA In Oracle8 constrangerile check pe coloane tip data trebuie sa foloseasca functia TO_DATE pentru a specifica formatul datei. Pentru ca aceasta functie nu a fost prezenta in versiunile precedente, datele importate dintr-o astfel de versiune ar putea sa nu aiba functia TO_DATE. In aceste cazuri, constrangerile sunt importate in baza de date Oracle8, dar ele sunt marcate in dictionar ca invalide. Vederile catalog DBA_CONSTRAINTS, USER_CONSTRAINTS si ALL_CONSTRAINTS pot fi folosite pentru a identifica astfel de constrangeri. Importul emite mesaje de avertizare daca apar constrangeri invalide in baza de date. FOLOSIREA FISIERELOR DE EXPORT ORACLE6 Aceasta sectiune prezinta indicatii si restrictii care se aplica atunci cand importati date dintr-o baza de date Oracle6 pe un server Oracle8. COLOANE CHAR Coloanele CHAR din Oracle6 sunt convertite automat la tipul Oracle8 VARCHAR2. SINTAXA CONSTRANGERILOR DE INTEGRITATE Cu toate ca sintaxa constrangerilor de integritate in Oracle6 este diferita de cea din Oracle7 si Oracle8, constrangerile de integritate sunt importate corect in Oracle8. STAREA CONSTRANGERILOR DE INTEGRITATE Constrangerile NOT NULL sunt importate ca ENABLED. Toate celelalte constrangeri sunt importate ca DISABLED. LUNGIMEA VALORILOR COLOANELOR IMPLICITE O tabela cu o valoare implicita pe o coloana mai mare decat marimea maxima a acelei

53

coloane genereaza urmatoarea eroare la importul in Oracle8: ORA-1401: inserted value too large for column Oracle6 nu verifica coloanele din declaratia CREATE TABLE pentru a fi suficient de mari pentru a memora valorile implicite ale lor, astfel ca aceste tabele pot fi importate in Oracle6. Serverul Oracle8 asigura aceste verificari. Ca rezultat, tabela care poate fi importata in Oracle6 ar putea sa nu fie importata in Oracle8. Daca valoarea implicita este returnata de o functie, acea coloana trebuie sa fie suficient de mare pentru a retine cea mai mare valoare pe care o poate returna acea functie. Altfel, declaratia CREATE TABLE inregistrata in fisierul de export produce o eroare la import. Nota: Valoarea maxima a functiei USER a crescut la Oracle7, astfel coloane cu valori implicite date de functia USER ar putea sa nu fie suficient de mari. Pentru a determina marimea maxima a valorilor returnate de functia USER executati urmatoarea comanda SQL: DESCRIBE user_sys_privs Lungimea aratata pentru coloana USERNAME este lungimea maxima returnata de functia USER. FOLOSIREA FISIERELOR DE EXPORT ORACLE5 Importul lui Oracle8 poate citi fisiere de export create de versiunile 5.1.22 si urmatoarele. Retineti: Coloanele CHAR sunt convertite automat la VARCHAR2 Constrangerile NOT NULL sunt importate ca ENABLED Importul creaza automat un index asupra fiecarul cluster care trebuie importat.

54