UF 2.

INSTALLACI I AJUSTAMENT DE SGBD CORPORATIU

1. Tipus dEmmagatzematge de la Informaci. SGBD Corporatius. Installaci

Fitxers Operacions Bsiques amb Fitxers 1. Recuperaci de registres per clau de cerca independentment de lorganitzaci interna del fitxer i del mtode daccs, consisteix en dos passos: a) localitzar la posici del registre. b) Realitzar la lectura del registre. 2. Obtenci del registre segent es tracta dobtenir el registre segent dacord amb algun criteri, que no necessriament ser el de la proximitat fsica sin lordre lgic segons algun camp. Per tant, pot no servir dajuda haver llegit immediatament el registre predecessor per accelerar la localitzaci. 3. Inserci de registres pot tractar-se duna ampliaci del fitxer (inserci al final) que resulta una operaci poc costosa, o una inserci en una posici intermdia, que pot significar una reubicaci dalguns registres. 4. Actualitzaci de registres quan les dades estiguin emmagatzemades de forma redundant s necessari realitzar mltiples escriptures i lectures. A ms a ms si en actualitzar el registre aquest augmenta de mida, pot ser impossible utilitzar la posici antiga, per la qual cosa shaur dinvalidar el registre i inserir-ne un de nou. 5. Lectura de tot el fitxer algunes aplicacions utilitzen una lectura exhaustiva del fitxer. 6. Reorganitzaci del fitxer es tracta de treure els registres esborrats lgicament o invalidats per alguna operaci, i aix recuperar espai. Ser una operaci especialment important si shan realitzat moltes insercions i esborrats que admeten registres de longitud variable amb nous camps. Quan esborrem un registre, es fa de forma lgica, s a dir, el registre es marca com a esborrat. Relaci entre Camps, Registres, Blocs i Fitxers Fonamentalment, podem dir que conjunts de camps relacionats sagrupen en registres; conjunts de registres relacionats sagrupen en blocs (o pgines) i conjunts de blocs constitueixen un fitxer. De totes aquestes unitats, les niques que tenen una mida fixa son els blocs, tamb anomenats pgines, definits en el sistema com un mltiple de la mida del bloc del sistema operatiu. Considerarem que pot haver registres de longitud fixa i registres de longitud variable. Mtodes Bsic de Bloqueig Estudiarem de quines formes els registres poden ubicar-se dintre dels blocs.

El bloc s la unitat dinformaci transferida entre els dispositius demmagatzematge i en rea de treball de la memria principal (buffer). Els blocs son duna mida fixa i ha de dimensionar-se com a un mltiple dels blocs fsics del sistema operatiu. Per tenir accs a un registre ha de transferir-se a travs de blocs de S.O. primer i de BD desprs a memria. Anomenem Factor de Bloqueig al nombre de registres lgics que caben en un bloc. Dintre dun bloc hi ha un espai dedicat a marques, descripci del contingut, referncies, data de lltima actualitzaci, etc. Considerem dos mtodes de bloqueig: 1. Bloqueig Fix o Enter els registres subiquen dintre dun bloc i, eventualment, es desaprofita al final un espai ms petit que lespai ocupat per un registre. R1 R2 R3 Espai desaprofitat

bloc 2. Bloqueig Partit o Encadenat els registres sescriuen en blocs consecutius de memria podent quedar una part dun registre en el bloc segent. A continuaci sindica amb un apuntador al bloc segent. Resulta costs realitzar una cerca de registres partits i els fitxers resultants son difcils dactualitzar. Com a contrapartida, no es desaprofita prcticament espai. R1 R2 R3
RA1

Apuntador al segent bloc

RA2

Organitzaci de Fitxers i Mtodes dAccs

Considerem 4 organitzacions bsiques de fitxers en les quals es poden sustentar els diferents mtodes daccs. Fitxer Seqencial Fsic En aquest model les dades subiquen en ordre darribada, sense tenir en compte el significat del seu contingut. Recuperaci dun registre per recuperar un registre pel valor duna clau de cerca hem de recrrer el fitxer fins trobar-lo. En el pitjor dels casos haurem de recrrer tot el fitxer.. Obtenir el registre segent el registre segent pot estar en qualsevol posici, per tant, equival a la recuperaci de qualsevol registre. Inserci dun registre simplement sinsereix al final. 2

Actualitzaci dun registre primer hem de localitzar-lo i, en el pitjor dels casos (augment de mida) hem de marcar-lo com a esborrat i inserir-lo al final. Lectura exhaustiva del fitxer pot resultar molt costosa si hem de seguir un cert ordre (en aquest cas val la pena ordenar-lo prviament). Reorganitzaci del fitxer es copia el fitxer en un altre per ometent els registres marcats. Fitxer Seqencial Lgic Els registres sordenen segons una seqncia especfica que ve determinada pel contingut dun camp que denominarem clau fsica (que pot estar formada per ms dun atribut) i que identifica el registre. Quan el fitxer t una mida considerable, s molt costs obrir un forat per un registre nou, aix, per mantenir lordre per la clau fsica se sol disposar duna estructura addicional que es diu fitxer de desbordament o doverflow i que no est ordenat i que es gestiona com un fitxer seqencial fsic. Recuperaci dun registre Si latribut de cerca no coincideix amb la clau fsica, sha de recrrer el fitxer des del principi i si ha hagut insercions i shan ubicat en el fitxer de desbordament, tamb poden tenir que mirar en aquest fitxer. Si la clau de cerca coincideix amb la clau fsica, podrem realitzar una cerca binria. Tamb podrem haver de mirar en lrea de desbordament. Obtenci del registre segent El registre segent, si busquem per la clau fsica ser immediatament accessible, sin ser com recuperar qualsevol registre. Inserci dun nou registre sha de conservar la seqncia segons la clau fsica. Podrien haver de moure els registres una posici per tal dobrir un forat pel nou registre. 1. Localitzar la posici a inserir 2. llegir i escriure els registres posteriors 3. escriure el registre nou Actualitzaci dun registre si lactualitzaci no canvia la clau fsica no hi ha problema. En cas contrari lhem dinserir en la nova posici segons la clau fsica. Lectura exhaustiva del fitxer si sutilitza fitxer de desbordament, shaur dordenar primer. Reorganitzaci del fitxer noms t sentit quan hi ha un fitxer de desbordament o quan sha produt un elevat nombre doperacions desborrat. En el primer cas es far la barreja del fitxer amb el de desbordament. Fitxer Seqencial Indexat Ls dun o ms ndex servir per accelerar la cerca a les dades per una clau de cerca. Lndex t algun valor de dada rellevant junt amb una adrea o apuntador sobre la localitzaci del valor en el fitxer. En funci de si lapuntador de lndex indica una adrea de registre o de bloc, els ndex es classifiquen en densos i no densos, respectivament. Lestructura dun fitxer seqencial indexat consisteix en: 1. Un fitxer de dades que s un fitxer seqencial lgic, amb una possible rea de desbordament. 2. Un fitxer ndex, que tamb ser un fitxer seqencial lgic. Els seus registres consten tots dun camp clau pel qual es mantenen ordenats i un camp apuntador,

que cont ladrea per recuperar un registre en el fitxer mestre (el fitxer de dades). FSI Dens En aquest cas el nombre de registres de lndex coincideix amb el nombre de regisres del fitxer de dades. Recuperaci dun registre consisteix en dos passos: 1. Consulta de lndex on busquem la clau per obtenir lapuntador. 2. Recuperar el registre. Obtenci del registre segent obtenim la segent posici de lndex. Inserci dun registre Suposa, per una banda, les mateixes operacions dinserci en un fitxer seqencial lgic i per altra banda, s necessari actualitzar lndex. Actualitzaci dun registre Si lactualitzaci noms implica camps diferents als utilitzats com a clau de cerca a lndex, loperaci s idntica a la descrita en un fitxer seqencial lgic. En cas que afecti a la clau de cerca, shaur dactualitzar tamb lndex. Lectura exhaustiva del fitxer si la lectura es fa respecte a la clau indexada, hem de recrrer lndex. Si la lectura es fa respecte a una clau no indexada, shaur de recrrer tot el fitxer de dades (coincideix amb la lectura exhaustiva dels fitxers seqencials lgics). Reorganitzaci del fitxer aquesta operaci es planteja quan ha hagut un nombre elevat desborrats. Implica la reorganitzaci de tots dos fitxers (de dades i ndex). FSI no dens Els ndex no densos van aparixer per tal de reduir la mida del fitxer ndex. Un ndex no dens est composat per dos camps: la clau de cerca (que ha de coincidir amb la clau fsica) i ladrea de comenament del bloc on es troben els registres, la clau dels quals es troba en el rang indicat. El nombre de registres dun ndex no dens es redueix al nombre de blocs de dades del fitxer principal. Per tant, per crear i mantenir aquesta estructura s necessari anar agrupant els registres del fitxer de dades en blocs digual mida, de manera que lndex ara ens indica el bloc en el qual possiblement es trobi un determinat registre, per no es pot garantir la seva existncia. Laccs seqencial a lndex ser molt rpid. Per buscar en un ndex no dens: 1. Una vegada trobat el bloc on pot estar el registre buscat (seleccionem a lndex lentrada immediatament inferior al valor de la clau de cerca) es carrega en memria el bloc corresponent i es fa una cerca seqencial fins trobar el registre buscat. 2. En realitzar la cerca a lndex no tenim garantia de trobar el registre fins desprs de consultar el bloc corresponent. A diferncia dels ndex densos, els no densos noms es poden definir sobre la clau fsica (noms en pot haver un). s freqent deixar algun espai lliure al final de cada bloc per les insercions. Tamb es pot tenir un fitxer de desbordament. ndex Multinivell

Els ndex son efectiu quan el fitxer s gran i els registres tamb ho son, daquesta manera lndex ocupar poc espai en proporci. Si un ndex s molt gran, tamb podem indexar-lo, denominant-se aix ndex multinivell (podem tenir n nivells). Recuperaci dun registre en un FSI multinivell El procs consistir en una lectura per cada nivell i una lectura del fitxer de dades. Si ha hagut insercions, el registre buscat podria estar en lrea de desbordament. Obtenci del registre segent en un FSI multinivell llegim des de lltim registre llegit i ignorem lndex. Inserci dun registre en un FSI multinivell la inserci pot implicar diverses operacions, depenent de les consideracions que es facin: - El registre sinsereix en un bloc del fitxer de dades. - El registre sinsereix en el fitxer de desbordament. Actualitzaci dun registre en un FSI multinivell si el camp clau no es modifica, por ubicar-se en la posici que ocupa la versi anterior del registre. Si es tracta dun esborrat marquem el registre. Si modifica el camp clau, hem de canviar la ubicaci del registre amb la qual cosa, el que farem ser esborrar el registre i afegir-lo de nou. Lectura exhaustiva del fitxer en un FSI multinivell recorrem el fitxer de dades ignorant lndex. Reorganitzaci del fitxer en un FSI multinivell es pot fer quan lrea de desbordament
tingui una mida excessiva. Llegim el fitxer seqencialment i el tornem a escriure obviant els registres marcats com a esborrats. Tamb es refar lndex. Fitxers dAccs Directe Aquests fitxers permeten laccs a qualsevol posici directament. Sutilitza el valor de la clau per determinar la posici de cada registre. Existeixen diversos mtodes per convertir la clau en una adrea dintre del fitxer (directament o aplicant-hi una operaci). En el cas que apliquem una operaci per determinar ladrea on ha danar el registre apareixen dos problemes: - Collisions dos valors diferents de clau obtenen una mateixa posici. - Forats no hi ha cap valor de clau per una posici donada. Mecanismes per solucionar les collisions Existeixen dos formes de tractar les collisions: Direccionament Tancat lespai dadreces calculades pertany a un nic fitxer. Podem establir dues maneres: Cerca Lineal quan hi ha una collisi el registre semmagatzema en la primera posici lliure dintre del mateix bloc. Realeatoritzaci el registre a inserir sallotja en una posici aleatria que es calcula mitjanant un nou mtode de transformaci dintre del fitxer. No garanteix que sarribi fcilment a un forat. Direccionament Obert lespai dadreces calculades pertany a ms dun fitxer (fitxer de desbordament). Podem fer-ho de dues formes: Llistes enllaades consisteix en posar tots els registres collisionats al fitxer de desbordament utilitzant un encadenament similar al dels fitxers seqencials lgics. El fitxer de desbordament creix segons les necessitats despai. Blocs de desbordament sadjudiquen blocs de desbordament comuns a un interval de claus, de forma que si la posici que correspon a un

determinat registre ja est ocupada, el registre collisionat subica en el primer forat lliure del bloc de desbordament que li correspon segons la seva clau. Recuperaci dun registre en un fitxer daccs directe hem de calcular ladrea corresponent a la clau i si hi ha collisi tornar a buscar. Inserci dun registre en un fitxer daccs directe sha de localitzar la posici que li correspon segons la clau. Si la posici est ocupada shaur de tractar la collisi. Actualitzaci dun registre en un fitxer daccs directe si no es canvia la clau consisteix en trobar-lo i tornar a escriurel en el mateix lloc. Si es canvia la clau sha deliminar i tornar a inserir. Lectura exhaustiva del fitxer en un fitxer daccs directe en general, no se sol fer doncs, la posici fsica del registre no guarda relaci amb els registres vens. Reorganitzaci del fitxer en un fitxer daccs directe es realitzar si ha augmentat molt el nombre de registres i no va haver previsi per a la seva ampliaci. Tamb es far si ha hagut moltes eliminacions, amb la qual cosa, les rutes de cerca resulten llargues i enrevessades.

Sistemes dEmmagatzematge RAIDS L'acrnim RAID (de l'angls Redundant Array of Independent Disks, conjunt redundant de discos independents, anteriorment conegut com Redundant Array of Inexpensive Disks, conjunt redundant de discos barats) fa referncia a un sistema d'emmagatzematge que usa mltiples discos durs o SSD entre els quals es distribuxen o repliquen les dades. Depenent de la seva configuraci (a la qual sol cridar-se nivell), els beneficis d'un RAID respecte a un nic disc son: major integritat, major tolerncia a fallades, major rendiment i major capacitat. En les seves implementacions originals, el seu avantatge clau era l'habilitat de combinar diversos dispositius de baix cost i tecnologia ms antiga en un conjunt que oferia major capacitat, fiabilitat, velocitat o una combinaci d'aquestes que un sol dispositiu d'ltima generaci i cost ms alt. En el nivell ms simple, un RAID combina diversos discos durs en una sola unitat lgica. Aix, en lloc de veure diversos discos durs diferents, el sistema operatiu veu un sol. Els RAID solen usar-se en servidors i normalment (encara que no s necessari) s'implementen amb unitats de disc de la mateixa capacitat. A causa del decrement en el preu dels discos durs i la major disponibilitat de les opcions RAID incloses en els chipsets de les plaques base, els RAID es troben tamb com opci en les computadores personals ms avanades. Aix s especialment freqent en les computadores dedicades a tasques intensives i que requereixi assegurar la integritat de les dades en cas de fallada del sistema. Aquesta caracterstica no est bviament disponible en els sistemes RAID per programari, que solen presentar per tant el problema de reconstruir el conjunt de discos quan el sistema s reiniciat desprs d'una fallada per a assegurar la integritat de les dades. Per contra, els sistemes basats en programari sn molt ms flexibles (permetent, per exemple, construir RAID de particions en lloc de discos complets i agrupar en un mateix RAID discos connectats en diverses controladores) i els basats en maquinari afegeixen un punt de fallada ms al sistema (la controladora RAID). Totes les implementacions poden suportar l's d'un o ms discos de reserva (hot spare), unitats preinstallades que poden usar-se immediatament (i gaireb sempre automticament) desprs de la fallada d'un disc del RAID. Aix redueix el temps del perode de reparaci en escurar el temps de reconstrucci del RAID. Funcionament Les dades es desglossen en fragments que s'escriuen en diverses unitats simultniament. D'aquesta manera la informaci es reparteix en diferents discs utilitzant tcniques de detecci d'error com l'entrellaat de blocs o duplicaci. D'aquesta manera es permet proporcionar redundncia, reduir el temps d'accs i/o obtenir major taxa de bits per llegir/escriure, aix com la possibilitat de recuperar el sistema desprs de l'avaria d'un dels discs. Tanmateix, tots els sistemes RAID suposen una prdua de part de la capacitat d'emmagatzematge dels discs per tal d'aconseguir la redundncia o emmagatzemar les dades de paritat. A ms, els sistemes RAID professionals cal que incloguin per duplicat els elements crtics: fonts d'alimentaci, ventiladors redundants. Objectius Augmentar la integritat de les dades en els discs incorporant tcniques com la redundncia de dades i la informaci de paritat per tal d'augmentar-ne la fiabilitat.

Proporcionar alta disponibilitat i funcionament ininterromput millorant la tolerncia a fallades i errors. RAID ofereix reparaci dinmica de sectors (Hot Swap) que repara sobre la marxa els sectors defectuosos causats per errors de programari. Millorar el rendiment i la productivitat: RAID permet a diferents unitats treballar en parallel aconseguint rendiments superiors a un sol disc dur o a un grup de discs durs independents

Tipus Basada en programari: apropiada quan el factor de decisi s el cost inicial per s una soluci ms cara a mig termini. T l'inconvenient que ralentitza el rendiment del sistema. Basada en maquinari: 1. Basada en host Utilitza controladors RAID que es connecten a una ranura PCI del host. Ofereix avantatges importants en relaci a RAID basada en programari. 2. RAID extern solucions independents del sistema operatiu que s'executen en el servidor. Permeten major flexibilitat i permeten crear sistemes d'emmagatzematge de gran capacitat per servidors de gamma alta. Implementaci Hi ha 7 configuracions o nivells de RAID i, fins i tot, combinacions d'elles que permeten diferents equilibris entre tolerncia a fallades, rendiment i cost. L'elecci de la configuraci dependr en cada cas dels requeriments de seguretat, velocitat, capacitat i cost necessaris. Cada nivell de RAID ofereix una combinaci especfica de tolerncia a fallades, rendiment i cost. La majoria de nivells RAID poden satisfer de manera efectiva sols un o dos d'aquests requeriments. RAID0- segmentaci sense tolerncia a fallades: segmenta la informaci d'entrada repartint-la en diferents discs sense introduir-ne redundncia. Millora el rendiment per no ofereix tolerncia a fallades. Si un disc falla, tota la informaci que emmagatzemava es perd. Aconsellable en aplicacions que requereixin emmagatzematge a alta velocitat sense tolerncia a fallades (tractament d'imatges, vdeo i udio). RAID1- Redundncia: proporciona el doble de velocitat de transacci en lectura que els discs simples i la mateixa en escriptura. Molt utilitzada.

RAID 0+1 / 10: combinaci dels dos anteriors que proporciona velocitat i tolerncia a fallades alhora. Molt utilitzats.

RAID2- Accs parallel amb discs especialitzats. Redundncia a travs del codi Hamming: implementaci poc utilitzada. Aquest nivell divideix la informaci a nivell de bit. RAID3- Accs sncron amb disc dedicat a paritat: proporciona segmentaci a nivell de byte amb un disc dedicat exclusivament a informaci de paritat. Poc utilitzat. RAID4- Accs independent amb disc dedicat a paritat: segmentaci a nivell de bloc amb disc de paritat. Si un disc falla, el disc de paritat s utilitzat per crear un disc de reemplaament. Un inconvenient s que el disc de paritat pot crear colls d'ampolla durant l'escriptura. RAID5- Accs independent amb paritat distribuda: proporciona segmentaci a nivell de byte i tamb segmentaci en la informaci de correcci d'errors solucionant el problema de coll d'ampolla del RAID4. En resulta un excellent rendiment i bona tolerncia a fallades. s una de les configuracions ms utilitzades. RAID6- Accs independent amb doble paritat: proporciona segmentaci de bloc amb informaci de paritat al llarg de tots els discs.

Xarxes dEmmagatzematge Veurem quines solucions demmagatzematge hi ha al mercat. Actualment quan una empresa vol dur a terme un projecte demmagatzematge ha descollir quin, de tots els existents en el mercat, s el que ms sadequa a la seva infrastructura. Actualment hi ha tres maneres de solucionar lemmagatzematge: Via DAS (Direct Attached Storage) Via NAS (Network Attached Storage) o LAN (Local Area Network) Via SAN (Storage Area Network) Soluci DAS Una soluci DAS es basa en una arquitectura en la que el dispositiu demmagatzematge es connecta directament al sistema principal. Lemmagatzematge pot ser intern, com els discs durs interns dun ordinador, o extern. Aquesta soluci s la ms bsica per realitzar lemmagatzematge que, sense adonar-nos, sempre utilitzem (per exemple, quan connectem una memria flash o un pendrive a lordinador mitjanant el USB).

Hem de tenir en compte que el factor limitant daquesta soluci s el servidor o PC al que volem augmentar el disc. Si tenim en compte que un servidor de gamma mitja pot portar, ms o menys, un mxim de 4 discos, significa que tenim un mxim despai demmagatzematge. Depenent del dispositiu que hem de connectar al servidor necessitarem ms o menys softwares que installar. Si el que volem s llegir o gravar un CD aquesta soluci no necessita cap software addicional. Si volem connectar un sistema demmagatzematge de cintes per poder efectuar el Backup del servidor, necessitarem softwares addicionals que en permetin efectuar lacci. El principal avantatge daquesta soluci s que s realment senzilla dimplementar i implica molt poc cost inicial. Soluci NAS o LAN Una soluci NAS o LAN s el segent nivell en lemmagatzematge. Aquesta soluci es basa en connectar la unitat demmagatzematge a una xarxa LAN a la que tamb es connecten tots els servidors o PCs:

10

La soluci s una tecnologia demmagatzematge dedicada a la interconnexi directa dels dispositius demmagatzematge a la xarxa LAN. Mitjanant connexions Ethernet estndard, determinant la gesti del mateix utilitzant un sistema operatiu que dna accs mitjanant els protocols de xarxa (NFS i CIFS entre altres). Un NAS proporciona funcionalitats dels sistemes darxius als sistemes demmagatzematge, sent lobjectiu lliurar als servidors ASP de la gesti de les dades recollocant aquestes i separant-les de les aplicacions en els dispositius demmagatzematge, podent ser accedides des de tots els clients heterogenis que conformen la plataforma de servidors. Alguns beneficis daquesta configuraci, si excloem el tenir un emmagatzematge com igual que en una SAN, sn un menor cost i la utilitzaci de la mateixa infrastructura per les comunicacions i la gesti dels equips. Pel contrari, ls compartit de les comunicacions ens fa tenir menor rendiment i fiabilitat. Per tant, aquesta s una bona soluci quan es requereix compartir informaci i els nivells de fiabilitat no son crtics. Els protocols de comunicacions NAS estan basats en fitxers. Per aquesta ra el client sollicita el fitxer complet al servidor i treballa localment. s per aquest motiu que un NAS esta pensat per clients amb la informaci emmagatzemada en fitxers petits i en gran quantitat. La gesti duna soluci NAS s ms complexa que la dun DAS. Com hem comentat, un DAS no necessita cap software addicional per implementar la soluci. Els elements dun NAS, normalment, tenen el seu propi sistema operatiu i es configura i gestiona utilitzant utilitats del software que corren sobre qualsevol navegador web estndard. Una gesti mitjanant un navegador web permet a ladministrador del sistema comprovar lestat del sistema NAS i fer els canvis necessaris a la configuraci des de qualsevol servidor de la xarxa. Soluci SAN Una xarxa SAN s una xarxa demmagatzematge dedicada dalta velocitat, basada en el protocol Fibre Channel, que permet la connectivitat directa entre la plataforma de servidors i els dispositius demmagatzematge. Els elements que interconnecten els dispositius sn els elements propis duna xarxa local, normalment seran switchs, adaptats i caracteritzats per utilitzar la tecnologia Fibre Channel. Existeixen diverses topologies de xarxa que permeten implementar lestndard Fibre Channel: punt a punt, bucle arbitrat, bucle commutat... encara que la topologia ms utilitzada s la segent:

11

Els elements que formen una SAN es poden dividir en tres grans blocs: Servidors del sistema: dins duna xarxa demmagatzematge podem trobar servidors de tot tipus de sistemes i plataformes. Les aplicacions de dits servidors executaran de manera transparent laccs a lemmagatzematge de la xarxa i als dispositius fsics. La connexi del servidor de xarxa necessitar dadaptadors de bus especfics Fibre Channel denominats HBAs (Host Bus Adapter). El software demmagatzematge allotjat en els servidors ser objecte duna especial atenci per les noves caracterstiques de larquitectura implementada: disaster recovery, gesti de cintes, virtualitzaci, snapshoot, mirroring, etc. Emmagatzematge: dins dels dispositius destacarem llibreries de cintes magntiques, dispositius ptics, arrays de discs que es connecten directament a la SAN lliurant a la xarxa de la carrega demmagatzematge. La gesti i organitzaci dels arrays de discs es deuen realitzar atenent al grau dimportncia de les dades all emmagatzemades, introduint en funci de la poltica demmagatzematge: redundncia de components, tecnologia RAID, snapshoot, velocitat de transferncia i capacitat dels discs, etc.

12

Interconnexi Fibre Channel: com elements essencials es troben els commutadors o switchs permetent la interconnexi total dampli numero delements en la xarxa en funci del numero de ports, definint-se un conjunt dells o Switch Fabric. Aquesta s una soluci que ens aporta un mxim rendiment de les nostres mquines arribant en els elements dinterconnexi a unes tasses de 4GBps en els switchs i de 2GBps en les targetes. Si en un NAS veiem que el coll dampolla de la soluci esta en lample de banda de la xarxa LAN, en una SAN el coll dampolla no estan en la xarxa sin en la velocitat a la que poden transferir els servidors de la configuraci. El principal avantatge de la soluci s que el compartiment demmagatzematge. Aquest compartiment aporta a la flexibilitat a la xarxa simplificant la seva administraci.

13

Suports de Cpies de Seguretat Una de les qestions a les que totes les empreses s'enfronten en un moment o altre s la de crear una cpia de seguretat. Igual que hi ha gran varietat en el tipus d'empreses, hi ha una gran varietat de formats de cpia de seguretat, i no em refereixo a un format lgic, sin ms aviat ja a un format fsic en el de copiar la informaci. Els criteris a tenir en compte per triar entre un format o un altre sn diversos. Cost mitj per unitat d'informaci gravada, temps per gravar aquesta informaci, vida mitjana del suport, sn algunes de les qestions que hem de plantejar a l'hora de veure quin suport de cpia de seguretat adoptem en la nostra empresa. Els suports ms habituals en l'empresa sn els segents: Cinta magntica: s un clssic a causa fonamentalment del baix cost per unitat d'informaci gravada i que gaireb tots els servidors i programes de cpies de seguretat incorporen suport per a unitats de cintes. Ara per ara podem dir que segueix sent l'estndard. Els inconvenients els t en el temps d'execuci de la cpia, i la fiabilitat del suport en cinta magntica, que s mpliament superat per altres formats. CD / DVD / Blue-ray: cada dia s ms utilitzat en empreses, ja sigui en format normal o regravable. Els formats regravables poden ser una opci molt interessant ja que permeten reutilitzar els discos tot i que un nombre ms limitat de vegades que les cintes. Si els comparem amb les cintes tenen com a inconvenient un cost una mica ms car, i la seva capacitat limitada, encara que cada dia va a ms. Els seus avantatges estan la rapidesa de la cpia i la fiabilitat del suport ms gran que el de les cintes magntiques Sistemes RDX: En aparena s similar a una antiga cinta de vdeo, sobretot pel que fa a les dimensions, per es tracta d'una tecnologia que utilitza com a suport de la cpia de seguretat un disc dur amb una carcassa similar que el protegeix. Es poden integrar en la majoria dels servidors i sn admesos per la gran majoria dels programes de cpies de seguretat. Potser sn els suports que ms agraden respecte a la capacitat d'emmagatzematge, fiabilitat, rapidesa en la cpia i recuperaci de desastres. s clar que el cost a curt termini s el ms alt que de totes les opcions, per si considerem la durada dels suports les distncies no sn tan grans. Potser estan destinades a les empreses amb majors pressupostos i que requereixin una major seguretat en les cpies. Sistemes de disc dur ja sigui aquest en suport de disc dur extern, memria flash, etc. L'avantatge sol estar en el suport, la possibilitat de traslladar-lo, etc. i la part ms negativa s que ens confiem massa en aquests suports. En cas de triar discs durs el recomanable s buscar xifrat a nivell de maquinari perqu una prdua o sostracci no suposi que totes les dades de l'empresa quedin exposats. Sn sistemes molt utilitzats en petites empreses per el principal escull s l'escalabilitat. Cpia en el nvol, s l'opci que ltimament est guanyant quota de mercat amb l'abaratiment del preu de l'emmagatzematge en lnia. El principal problema que t est en les velocitats de pujada, que depenent del que ocupi la nostra cpia pot fer d'aquest aspecte una cosa molt tedis. Tamb tenim les nostres dades en un provedor extern, cosa que no acaba de convncer a totes les empreses. Finalment, un dels aspecte que totes les empreses han de tenir en compte s la velocitat de restauraci de la cpia. La majoria de les vegades no tenim en compte que la cpia de seguretat es realitza per utilitzar davant de qualsevol problema i trigar un mat o una

14

hora a restaurar dades i tornar a ser operatius s una cosa que hem de tenir en compte a l'hora de triar un format o un altre. Arribats a aquest punt, triar entre un format o un altre ser arribar a un comproms entre els aspectes a tenir en compte. s una qesti que no podem deixar a l'atzar i planificar de forma adequada, tant en la seva execuci com en el seu emmagatzematge o restauraci.

15

Altres Tipus dEmmagatzematge Bases de Dades en XML XML s el futur de ladministraci de dades ja que, aquest llenguatge ha prems trencar barreres i crear una altra manera estndard de processar la informaci. Doncs b, XML est provocant laparici de noves tecnologies, entre elles, una nova generaci de bases de dades, que si b es troben en fase dinvestigaci i desenvolupament, en un futur poden ser una alternativa a las BD relacionals. Aquest tipus de BD son completament diferents a les relacionals, les quals en lactualitat tenen suport per XML, per encara segueixen emmagatzemant tota la informaci en forma tabular o en tot cas, emmagatzemen tot el document en format Binary Large Object (BLOB), per la principal caracterstiques que ofereixen aquestes BD s la capacitat dobtenir els resultats de les consultes en format XML. Les bases de dades natives defineixen un model lgic per al document XML i ams, emmagatzema i recupera documents de la mateixa manera que els dXML. Aquest model ha dincloure, almenys, atributs com PCDATA i document en ordre. Totes les bases de dades relacions estan centrades en les dades, doncs els que emmagatzemen en els seus camps son dades atmiques. Una base de dades nativa en XML no posseeix camps, ni emmagatzema dades atmiques, sin documents XML, per tant, a aquest tipus de bases de dades se les denomina BD centrades en documents. XML es pot veure com a un estndard per lintercanvi de dades entre aplicacions en Internet independent del format demmagatzematge dels mateixos. Moltes aplicacions requereixen lemmagatzematge de dades XML. Existeixen diferents alternatives.

Les BD relacionals es basen en les taules bidimensionals com a nic medi per representar les dades. Tenen com a llenguatge estndard lSQL. Shan creat complexes teories i patrons per tal dencaixar objectes o estructures jerarquitzades en BD relacionals. Existeixen molts middlewares encarregats de la transferncia dinformaci entre estructures XML i BD relacionals. 16

17

Transformaci a XML

Llibres Isbn Ttol Autors Editorial Preu Any revisios

Nom

Cognom

email

nom oficina homepage

Nom

resultat

comentari

18

Regles de Transformaci Regla 1 Per a cada taula en lesquema de la BD sha de crear un element amb el mateix nom de la taula i la cardinalitat apropiada. <!DOCTYPE llibres [ <!ELEMENT llibres (llibre)*> ]> Regla 2 Les columnes de la taula sinclouen en un altre element (sub-element de lelement creat en la regla anterior), QUE REPRESENTA UN REGISTRE DE TAULA. <!ELEMENT llibre (isbn, titol, autors, editorial, preu, any, revisors)> Regla 3 Per a cada columna en la taula, el tipus de dades de la qual s simple (char, integer, etc.), crear un element, sub-element de lelement creat en el pas anterior, de tipus #PCDATA, amb el mateix nom de la columna. <!ELEMENT isbn (#PCDATA)> <!ELEMENT titol (#PCDATA)> Regla 4 Per a cada columna en la taula, el tipus de dades de la qual s complex (tipus objecte), crear un element complex, sub-element de lelement creat en el pas 2, amb el mateix nom de la columna. Per a cada propietat del tipus objecte crear un element amb el mateix nom de la propietat. <!ELEMENT autors (autor)+> <!ELEMENT autor (nom, cognom, email)> <!ELEMENT nom (#PCDATA)> <!ELEMENT cognom (#PCDATA)> <!ELEMENT email (#PCDATA)> Regla 5 Per a cada columna en la taula que s una taula anidada, crear un element amb el mateix nom daquella columna i la cardinalitat apropiada. Repetir els pasos des de 2. DTD Resultant <!DOCTYPE llibres [ <!ELEMENT llibress (llibre)*> <!ELEMENT libro (isbn, titol, autors, editorial, preu, any, revisors)> <!ELEMENT isbn (#PCDATA)> <!ELEMENT titol (#PCDATA)> <!ELEMENT autors (autor)+> <!ELEMENT autor (nom, cognom, email)> <!ELEMENT editorial (nom,oficina,homepage) > <!ELEMENT nom (#PCDATA)> <!ELEMENT cognom (#PCDATA)> 19

<!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT

email (#PCDATA)> oficina (#PCDATA)> homepage (#PCDATA)> preu (#PCDATA)> any (#PCDATA)> revisors (revisor)*> revisor (nom,resultat,comentari)> nom (#PCDATA)> resultat (#PCDATA)> comentari (#PCDATA)>]>

Possible document XML resultant <?xml version=1.0> <llibres> <llibre> <isbn> 1-55655-767-6 </isbn> <titol> Fundamento de Bases de Dades </titol> <autors> <autor> <nom> Abraham</nom> <cognom> Silberschatz</cognom> <email> silbers@hotmail.com </email> </autor> <autor> <nom> Henry </nom> <cognom> Korth </cognom> <email> korth@ hotmail.com </email> </autor> </autors> <editorial> <nom> McGraw-Hill </nom> <oficina> Av. Santander s/n </oficina> <homepage> http://www.mcgrawhill.es </homepage> </editorial> <preu> 40 </preu> <any> 2003 </any> <revisors> <revisor> <nom> James Smith </nom> <resultat> 8 </resultat>

20

<comentari> s un llibro de text bsic </comentari> </revisor> </revisors> </llibre> </llibres>

Resumen del Esquema de Transformaci de Relacional a DTD

<!DOCTYPE tabla [ <!ELEMENT tabla (registro)*> <!ELEMENT registro (columna1, columna2,..., columnaN)> <!ELEMENT columna1 (#PCDATA)> <!ELEMENT columna2 (propiedad1, propiedad2,..., propiedadN) > ... <!ELEMENT columnaN (#PCDATA)> <!ELEMENT propiedad1 (#PCDATA)> <!ELEMENT propiedad2 (#PCDATA)> ... <!ELEMENT propiedadN (#PCDATA)> ]>

Resumen de la Transformaci Esquema Relacional Esquema XML <xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema> <xsd:element name=tabla> <xsd:complexType> <xsd:sequence> <xsd:element name=registro minOccurs=0 maxOccurs=unbounded> <xsd:complexType> <xsd:sequence > <xsd:element name=columna1 type=xsd:positiveInteger/> <xsd:element name=columna2/> <xsd:complexType>

21

<xsd:sequence > <xsd:element name=propiedad1 type=xsd:string/> <xsd:element name=propiedad2 type=xsd:boolean/> .... <xsd:element name=propiedadn type=xsd:positiveInteger/> </xsd:sequence> </xsd:complexType> </xsd:element > <xsd:element name=columnaN type=xsd:string/> </xsd:sequence > </xsd:complexType> </xsd:element > </xsd:sequence > </xsd:complexType> </xsd:element > </xsd:schema>

22

Serveis de Directori LDAP LDAP sn les sigles de Lightweight Directory Access Protocol (Protocol Lleuger d'Accs a Directoris) que fan referncia a un protocol a nivell d'aplicaci que permet l'accs a un servei de directori ordenat i distribut per buscar diversa informaci en un entorn de xarxa. LDAP tamb s considerat una base de dades (encara que el seu sistema d'emmagatzematge pot ser diferent) a la qual poden realitzar consultes. Un directori s un conjunt d'objectes amb atributs organitzats en una manera lgica i jerrquica. L'exemple ms com s el directori telefnic, que consisteix en una srie de noms (persones o organitzacions) que estan ordenats alfabticament, amb cada nom tenint una adrea i un nmero de telfon adjunts. Un arbre de directori LDAP de vegades reflecteix diversos lmits poltics, geogrfics o organitzacionals, depenent del model triat. Els desplegaments actuals de LDAP tendeixen a utilitzar noms de Sistema de Noms de Domini (DNS per les seves sigles en angls) per estructurar els nivells ms alts de la jerarquia. Conforme es baixa al directori poden aparixer entrades que representen persones, unitats organitzacionals, impressores, documents, grups de persones o qualsevol cosa que representa una entrada donada en l'arbre (o mltiples entrades). Habitualment, emmagatzema la informaci d'accs (usuari i contrasenya) i s utilitzat per autenticar, encara que s possible emmagatzemar una altra informaci (dades de contacte de l'usuari, ubicaci de diversos recursos de la xarxa, permisos, certificats, etc.). A manera de sntesi, LDAP s un protocol d'accs unificat a un conjunt d'informaci sobre una xarxa. Visi General del Protocol Un client inicia una sessi de LDAP connectant-se a un servidor LDAP, per defecte al port TCP 389. El client desprs envia una petici d'operaci al servidor, i el servidor envia respostes. Amb algunes excepcions, el client no necessita esperar una resposta abans d'enviar la segent petici, i el servidor pot respondre en qualsevol ordre. El client pot requerir les segents operacions: Start TLS - utilitzar l'extensi Transport Layer Security (TLS) LDAPv3 per a una connexi segura Bind - autenticar i especificar una versi del protocol LDAP Search - buscar i obtenir entrades de directori Compare - provar si una entrada anomenada cont un valor d'atribut donat Add - Afegir una nova entrada Delete - Esborrar una entrada Modify - Modificar una entrada Modify Distinguished Name (DN) - Modificar o canviar el nom una entrada Abandon - avortar una petici prvia Extended Operation - operaci genrica usada per definir altres operacions Unbind - tancar la connexi (no s l'invers de Bind) A ms, el servidor pot enviar "notificacions no demanades" que no sn respostes a cap petici, per exemple abans que s'acabi el temps de connexi.

23

Evoluci dels SGBD En els anys 70 hi ha els sistemes jerrquics. A part dels anys 80 apareixen els SGBD que proporcionen independncia fsica. Durant lany 1986 es produeix lestandarditzaci del SQL. Que provoca una expansi dels SGBD relacionals. Durant els anys 90 ens trobem que a les empreses, cada departament ha anat adquirint SGBD relacionals de diferents tipus, i hi havia diferents Bases de Dades en els diferents Departaments (poca de fusions dEmpreses). Calia una nica visi dempresa o sigui que feia falta treballar com una si fos una de sola. Aix saconsegueix si les BD son del mateix fabricant. Si sn de fabricants diferents no s tan senzill, per gracies al SQL es pot treballar amb totes elles. Distribuci desitjada: Tenir les dades en diferents BD. Raons: a) Disponibilitat de les dades Si una de les estacions cau, poden treballar amb les altres (i existeixen repliques), i per tant la resta de les estacions poden treballar. b) Reduir costos En una estaci podem tenir les dades en local. I evitar en aquest casos costoses connexions a un sistema centralitzat. BD central

BD des centralitzada, a cada estaci una part de la BD en local A/B B/C A/C

Llenguatges de quarta generaci (anys 90) Els llenguatges de quarta generaci sn la evoluci dels segents llenguatges: 1a. Generaci llenguatge maquina 2a. Generaci Assemblador (fa servir Memonics) 3a Generaci C, Pascal, Cobol, ... 4a Generaci Visual Basic, Delphi, etc ... (llenguatges visuals)

24

Els llenguatges de quarta generaci disposen deines per gestionar Bases de Dades. Com per exemple Objectes ADO (Activex Data Object) poca Actual: Integraci Multimdia La integraci multimdia permet incloure dintre de la BD objectes multimdia (sons, imatges, ...) Orientaci a Objectes Incloure Tipus abstractes de dades, que porten empaquetades les operacions. Internet Fer consultes i actualitzacions per mitj dInternet (llenguatges PHP, ASP,...) Data WareHouse El DataWareHouse consisteix en tota la informaci que la empresa ha pogut obtenir mitjanant les seves activitats (dhuc de fora de lempresa). Aquesta informaci pot ser avaluada per fer anlisis financers, estudis de mercat, etc... Es demana que els SGBD puguin gestionar tota la informaci.

25

Arquitectura del SGBD Per treballar amb una BD necessitem una estructura. Nivell Fsic Es preocupa d lorganitzaci interna de les dades Nivell Lgic Es preocupa de les entitats, atributs i interrelacions Durant el perode 1975-1982 ANSI (American National Standards Institute) volia establir els estendards a les bases de dades. I el comit ANSI/SPARC (Satndard Planning And Requieriments Comite) va proposar una arquitectura basada en tres nivells. Nivell Extern Nivell Lgic Nivell Conceptual Nivell Intern Nivell Fsic

- Nivell Extern Son les diferents visions lgiques que tenen els diversos usuaris de la BD. Cadascuna de les visions es diu esquema - Nivell Conceptual El nivell conceptual t na nica descripci de la BD, les entitats, atributs i interrelacions de la BD - Nivell Intern Descripci fsica de la BD, estructures internes, camins daccs, etc...

Diagrama ANSI/SPARC
EE 1 EE 2 EE N

Esquemes Externs: com veu cada usuari al BD

EC

Esquema Conceptual: sn les entitats, atributs, ... la descripci de la empresa de la BD Esquema Intern: Mecanismes demmagatzematge i rutes daccs, etc. BD Fsica

EI

BD

26

Els SGBD relacionals no separen clarament en tres nivells, sin que tenen un nic esquema (SCHEMA). En el que sinclouen descripcions de lesquema conceptual (les taules, atributs, interrelacions, regles dintegritat), descripcions dels esquemes externs (vistes view) i tamb la dndex que corresponen a lesquema intern. Aquests SGBD es queden al nivell lgic (en les descripcions) i s el propi SGBD el que sencarrega descriure lesquema intern.

Independncia de les dades Independncia Fsica Es basa en que els canvis en el nivell fsic (a lesquema intern) no han dafectar a la resta desquemes, i els nivells sautoconnecten sols.

EE 1

EE 2

EE N

EC

EI EI

BD Fsica BD Fsica

Independncia Lgica Els Usuaris no es veuen afectats pels canvis al nivell Lgic. 1) Canvis a lesquema Conceptual No afectaran als usuaris (EE) que no faci referncia a les entitats, atributs, ... canviats.
EE 1 EE 2 EE 2 EE N

EC Segons el Canvi Afectar o no En aquesta part

EC

EI EI BD Fsica BD Fsica

27

2) Canvis a lesquema Extern No afectaran a ning.

EE 1 EE 2 EE 2 EE N

EC

EI

BD Fsica

Usuaris de la BD Els podem classificar com a informtic i no informtics de la segent manera: Programadors Informtics Administradors Paramtrics No Informtics Finals - Usuaris Paramtrics Els usuaris paramtrics sols introdueixen parmetres per operacions del programa. No tenen coneixement del contingut de la BD. Els programes que fan servir els creen els programadors, son preconcebuts i compilats. - Usuaris Finals Els usuaris finals realitzen consultes espontnies amb un llenguatge dalt nivell. Sn per ajudar a la presa de decisions. Han de conixer el contingut de la BD (contingut + estructura). Els programes els fan ells, ja que sn espontanis, i sn interpretats.

28

Components d'un sistema de gesti de bases de dades Els SGBD sn paquets de programari molt complexos i sofisticats que han de proporcionar una srie de serveis. No es pot generalitzar sobre els elements que componen un SGBD ja que varien molt els uns dels altres. No obstant aix, s molt til conixer els seus components i com es relacionen quan es tracta de comprendre el que s un sistema de bases de dades. Un SGBD t diversos mduls, cadascun dels quals realitza una funci especfica. El sistema operatiu proporciona serveis bsics al'SGBD, que s construt sobre ell Els principals components del gestor de la base de dades sn els segents: El gestor del diccionari controla els accessos al diccionari de dades i s'encarrega de mantenir-lo. La majoria dels components del SGBD accedeixen al diccionari de dades. Control d'autoritzaci. Aquest mdul comprova que l'usuari t els permisos necessaris per dur a terme l'operaci que heu demanat. Processador de comandes. Una vegada que el sistema ha comprovat els permisos de l'usuari, es passa el control al processador d'ordres. Control de la integritat. Quan una operaci canvia les dades de la base de dades, aquest mdul ha de comprovar que l'operaci a realitzar satisf totes les restriccions d'integritat necessries. Optimitzador de consultes. Aquest mdul determina l'estratgia ptima per a l'execuci de les consultes. Gestor de transaccions. Aquest mdul realitza el processament de les transaccions. Planificador (scheduler). Aquest mdul s el responsable d'assegurar que les operacions que es realitzen concurrentment sobre la base de dades tenen lloc sense conflictes. Gestor de recuperaci. Aquest mdul garanteix que la base de dades roman en un estat consistent en cas que es produeixi alguna fallada. Gestor de buffers. Aquest mdul s el responsable de transferir les dades entre memria principal i els dispositius d'emmagatzematge secundari. A aquest mdul tamb se li denomina gestor de dades.

29

Exemple dutilitzaci dels components pels diferents usuaris

30

Caracterstiques dependents del Sistema Operatiu Memria Compartida La memria distribuda compartida (o Distributed Shared Memory DSM) s un tipus d'implementaci maquinari i programari, en qu cada node d'un clster t accs a una mplia memria compartida que s'afegeix a la memria limitada privada, no compartida, prpia de cada node. Els sistemes de programari DSM poden ser implementats sota un sistema operatiu (SO), o com una biblioteca de programaci. Els sistemes de programari DSM implementats en el sistema operatiu poden concebre com extensions de l'arquitectura de memria virtual subjacent. Aquests sistemes sn transparents al desenvolupador, el que significa que la memria distribuda subjacent est completament oculta per als usuaris. En contrast, els sistemes de programari DSM implementats en una biblioteca no sn transparents i els desenvolupadors han de programar separadament. No obstant aix, aquests ltims sistemes ofereixen millors caracterstiques de portabilitat en la implementaci de sistemes DSM. Els sistemes de programari DSM tamb tenen capacitat per a organitzar la regi de memria compartida de manera flexible. Les aproximacions basades en pgines organitzen la memria compartida en pgines de grandria fixa. Per la seva banda, les aproximacions basades en objectes organitzen la regi com un espai abstracte on es poden emmagatzemar objectes compartits de mida variable. L'arquitectura de memria compartida pot suposar la separaci de la memria en parts compartides distribudes entre els nodes i la memria principal, o la distribuci de tota la memria en els diferents nodes. Un protocol de coherncia, escollit d'acord a una manera de consistncia, s'encarrega de mantenir la coherncia de la memria. En la memria compartida, els processos utilitzen variables que poden llegir / escriure per poder comunicar-se. Semfors Un semfor s una variable especial (o tipus abstracte de dades) que constitueix el mtode clssic per a restringir o permetre l'accs a recursos compartits (per exemple, un recurs d'emmagatzematge del sistema o variables del codi font) en un entorn de multiprocessament (en qu s'executaran diversos processos concurrentment). Van ser inventats per Edsger Dijkstra i es van usar per primera vegada en el sistema operatiu THEOS. Els semfors s'empren per permetre l'accs a diferents parts de programes (anomenats seccions crtiques) on es manipulen variables o recursos que han de ser accedits de forma especial. Segons el valor amb que sn inicialitzats es permeten a ms o menys processos utilitzar el recurs de forma simultnia. Un tipus simple de semfor s el binari, que pot prendre noms els valors 0 i 1. Els semfors s'inicialitzen en 1 i sn usats quan noms un procs pot accedir a un recurs al mateix temps. Quan el recurs est disponible, un procs accedeix i decrementa el valor del semfor amb l'operaci P. El valor queda llavors en 0, el que fa que si un altre procs intenta decrementar s'hagi d'esperar. Quan el procs que decrement el semfor realitza una operaci V, algun procs que estava esperant comena a utilitzar el recurs. Per fer que dos processos s'executin en una seqncia pot usar-se un semfor inicialitzat a 0. El procs que ha d'executar primer en la seqncia realitza l'operaci V sobre el semfor abans del codi que ha de ser executat desprs de l'altre procs. Aquest executa l'operaci P. Si el segon procs en la seqncia s programat per executar abans que l'altre, en fer P dormir fins que el primer procs de la seqncia passi per la seva

31

operaci V. Aquesta manera d's s'anomena senyalitzaci (signaling), i s'usa perqu un procs o fil d'execuci li faci saber a un altre que alguna cosa ha succet. Gesti de Processos Un procs s simplement, un programa en execuci que necessita recursos per realitzar la seva tasca: temps de CPU, memria, arxius i dispositius d'E / S. El SO s el responsable de:: Crear i destruir els processos. Parar i reprendre els processos. Oferir mecanismes perqu es comuniquin i sincronitzin. La gesti de processos podria ser similar al treball d'oficina. Es pot tenir una llista de tasques a realitzar ia aquestes fixar-los prioritats alta, mitjana, baixa per exemple. Hem de comenar fent les tasques de prioritat altes i quan s'acabin seguir amb les de prioritat mitjana i desprs les de baixa. Un cop realitzada la tasca es ratlla. Aix pot portar un problema que les tasques de baixa prioritat potser mai arribin a executar-se. i romanguin en la llista per sempre. Per solucionar aix, es pot assignar alta prioritat a les tasques ms antigues. Gesti de CPU La gesti d'un sistema operatiu monoprograma s simple. Els sistemes operatius multiprogramats o de temps compartit, realitzen les segents funcions: Mant una estructura de dades per a guardar informaci sobre cada un dels processos que s'executen concurrentment en el sistema. Decidir quan s'interromp un procs i determina a quin procs se li assigna la CPU al seu lloc, per a aix s'executa un programa anomenat planificador. Serveis relacionats amb la gesti de la CPU que proporcionen tots els sistemes operatius: Creaci d'un procs. Terminaci d'un procs. Gesti de l'entrada / sortida. s missi del sistema operatiu gestionar directament els perifrics, oferint al programador uns serveis per a la seva utilitzaci molt ms senzills que els que ofereixen aquests a nivell maquinari. A nivell fsic els perifrics sn molt diferents, per aix els serveis que ofereix el sistema operatiu per treballar amb dispositius diferents sn molt semblants, la E / S independent del dispositiu. El sistema operatiu ofereix com a mnim els serveis per realitzar les operacions d'E / S: Obertura d'un perifric. Operacions de lectura i escriptura. Tancament d'un perifric. Gesti de la memria principal La Memria s una gran taula de paraules o bytes que es referencien cadascuna mitjanant una adrea nica. Aquest magatzem de dades de rpid accessos s compartit

32

per la CPU i els dispositius d'E / S, s voltil i perd el seu contingut en les fallades del sistema. El Sistema Operatiu s el responsable de: Conixer quines parts de la memria estan sent utilitzades i per qui. Decidir quins processos es carregaran en memria quan hi hagi espai disponible. Assignar i reclamar espai de memria quan sigui necessari. Administraci de privilegis Privilegi s la capacitat d'anular restriccions del sistema en les accions dels usuaris. Tots els sistemes operatius permeten l'exercici de privilegis especials sota certes condicions, per executar operacions del sistema de naturalesa delicada. Les operacions de naturalesa delicada afecten la configuraci del sistema o a la seva disponibilitat per a la comunitat d'usuaris a la qual serveix. La majoria dels usuaris no poden, per exemple, executar instruccions que afectin la configuraci del maquinari i el programari del sistema. Activitats com muntar i examinar sistemes de fitxers, afegir usuaris, modificar perfils d'usuari, afegir i eliminar perifrics, installar programari d'aplicacions, administrar contrasenyes i administrar lnies de terminal d'usuari, estan restringides a certs usuaris.

33

2. Comunicacions
Tipus dArquitectures Considerem 3 tipus darquitectura: - Arquitectura Centralitzada - Arquitectura de Servidor dArxius - Arquitectura Client/Servidor Arquitectura Centralitzada Es basa en lexistncia duna mquina servidora que emmagatzema les dades i les aplicacions que les processen. Els clients es comporten com a terminals i noms serveixen per introduir dades des del teclat. Avantatges - gran nivell de seguretat - fcil dadministrar Inconvenients - cost alt - mquina servidora molt carregada

Arquitectura Servidor dArxius Es basa en lexistncia duna o varies mquines servidores que emmagatzemen dades i estacions de treball que executen aplicacions que les processen. Els clients en aquest tipus darquitectura son actius. Avantatges - cost baix - s escalable Inconvenients - clients potents - forta dependncia de les comunicacions

34

Arquitectura Client / Servidor Es basa en lexistncia de dos tipus daplicacions executant-se de forma independent. Una de les aplicacions actua com a servidora i laltra com a client. Avantatges - fcil descalar - repartiment de crregues Inconvenients - noves aplicacions - importncia de les comunicacions Comparativa Servidor dArxius i Client / Servidor Servidor dArxius El client demana les dades Senvia una cpia de les dades de la BD Sexecuta la consulta Client / Servidor El client demana les dades Senvien en forma de consulta al servidor El servidor processa la consulta i retorna les dades al client Noms viatgen les dades demanades

Conceptes Bsics Definici Un sistema Client / Servidor s aquell en el qu dos o ms processos funcionen de forma independent per de forma cooperativa. En un sistema Client / Servidor una aplicaci demana dades a una altra, una vegada realitzada la petici elabora la resposta i la retorna a laplicaci que la va demanar.

35

Components Servei dusuari Servei de negoci Servei de dades

Es basa en lexistncia de conjunts de programari distributs de forma que la lgica del programa pugui ser localitzada en servidors centralitzats.

Podem trobar dos models bsics dimplementaci de larquitectura Client /Servidor: Arquitectura en 2 nivells L'arquitectura en 2 nivells s'utilitza per descriure els sistemes client / servidor on el client demana recursos i el servidor respon directament a la sollicitud, amb els seus propis recursos. Aix significa que el servidor no requereix una altra aplicaci per a proporcionar part del servei.

36

El servidor de dades, que proporciona al servidor de aplicacions los dades que requereix Introducci a l'arquitectura en 3 nivells Arquitectura en 3 nivells En l'arquitectura en 3 nivells, hi ha un nivell intermediari. Aix significa que l'arquitectura generalment est compartida per: Un client, s a dir, l'equip que demana els recursos, equipat amb una interfcie d'usuari (generalment un navegador web) per a la presentaci El servidor d'aplicacions (tamb anomenat programari intermedi), la tasca s proporcionar els recursos demanats, per que requereix d'un altre servidor per fer-ho El servidor de dades, que proporciona al servidor d'aplicacions les dades que requereix

L's massiu del terme arquitectura en 3 nivells tamb denota les segents arquitectures: Aplicaci compartida entre un client, un programari intermedi i un servidor empresarial. Aplicaci compartida entre un client, un servidor d'aplicacions i un servidor de base de dades empresarial. Comparaci entre ambds tipus d'arquitectures 37

L'arquitectura en 2 nivells s, per tant, una arquitectura client / servidor en qu el servidor s polivalent, s a dir, pot respondre directament a totes les sollicituds de recursos del client. No obstant aix, en l'arquitectura en 3 nivells, les aplicacions al nivell del servidor sn descentralitzades de l'un a laltre, s a dir, cada servidor s'especialitza en una determinada tasca, (per exemple: servidor web / servidor de bases de dades). L'arquitectura en 3 nivells permet: Un major grau de flexibilitat Ms seguretat, ja que la seguretat es pot definir independentment per a cada servei i en cada nivell Millor rendiment, ja que les tasques es comparteixen entre servidors Arquitectura de nivells mltiples En l'arquitectura en 3 nivells, cada servidor (nivell 2 i 3) realitza una tasca especialitzada (un servei). Per tant, un servidor pot utilitzar els serveis d'altres servidors per a proporcionar el seu propi servei. Per tant, l'arquitectura en 3 nivells s potencialment una arquitectura en N-nivells

38

Interoperabilitat i Integraci d'Informaci entre Bases de Dades Heterognies i Distribudes Les bases de dades proliferen avui de forma molt abundant en les institucions. Aix exigeix de manera irrevocable que es pugui aconseguir una compartici efectiva de la informaci albergada avui en molt diversos SGBDs, on, generalment, cada sistema suporta moltes BDs diferents, i la ra ms general, de la Interconnexi de BDs i de la interoperabilitat, que pren la rellevncia suma en qualsevol entorn Web. Addicionalment, les institucions no estan disposades a perdre el control sobre les seves dades, residents a cada illa d'informaci -BD centralitzada i allada-, com a preu per aquesta compartici. Els valors de les dades sn, generalment, el recurs informtic ms valus que avui existeix, sobretot si es tracta de dades ntegres, consistents, perdurables i fiables, en l'abast del negoci o activitat d'una empresa. Aquest valor es deu, no noms a l'esfor que suposa la seva recollida, sin tamb al manteniment i salvaguarda de la seva integritat i consistncia. Finalment, la majoria de les institucions estan disseminades geogrficament, i necessiten treballar en cooperaci, com si aquestes distncies geogrfiques no existissin. En aix ltim resideix el principi de la distribuci de qualsevol sistema telemtic en general, i dels Sistemes d'Informaci en particular. Parlar d'una BDDR significa, d'entrada, que cada localitat que participa en la BDDR no s una illa dnformaci, sin un component altament integrat en el conjunt, les dades sn fragments dels que alberga la BDDR en tota la seva globalitat. Aquest captol se centra en descriure els mitjans tcnics que faciliten la Interconnexi de diversos SIS i al concepte d'Interoperabilitat, la finalitat s aconseguir un funcionament global del conjunt com si fos un tot integrat, de manera fiable alhora que efica. Per a aix, recordem que ANSI / SPARC estableix que un Sistema d'Informaci cont generalment a un o diversos Sistemes de Gesti de Bases de Dades. Cada SGBD dna suport a mltiples BDs i, al voltant de cada BD, s'afegeix una part de programari prpia de l'Univers del Discurs que va donar origen a la corresponent BD. Concepte d'Interoperabilitat entre sistemes d'informaci heterogenis. Informalment, la interoperabilitat s la capacitat requerida perqu dos o ms sistemes d'informaci, amb dades locals, interactun conjuntament mitjanant l'execuci dels seus processos amb intercanvi de les seves dades locals per produir certa informaci global. Quan els sistemes estan fsicament distants, la plataforma de comunicacions requerida es basa, com a mnim, en algun servei equivalent al proporcionat pel nivell tres de la torre OSI (nivell de Xarxa, installada sobre el nivell dos d'Enlla, i aquest sobre el nivell un fsic), o en el nivell d'interconnexi equivalent en altres implementacions (nivell IP Internet, installat directament sobre el nivell d'accs a xarxa, en DARP). Si parlem en termes dels objectius que caracteritzen als sistemes i els enfrontem als d'interconnexi, es podria dir que el nivell de xarxa s'encarrega estrictament de la funci de connexi, que permet realitzar una transferncia d'informaci entre dues o ms mquines interconnectades per xarxes. Les xarxes d'ordinadors, en general, sn heterognies i la interconnexi de xarxes heterognies es fa a nivells ms baixos que els ja referits. Els nivells d'interoperabilitat, que passem a descriure, sinstallen, com a mnim, sobre el substrat funcional referit dalt, aqu anomenat la connectivitat. Els objectius de la interoperabilitat sn de molt ms alt nivell que la connectivitat que acaba de ser esmentada. La interoperabilitat t per finalitat la integraci de dades locals 39

(dades tils als aplicatius que resideixen en mltiples i heterognies bases de dades allades) per generar una informaci global produda per un processament integrat. Aconseguir una interoperabilitat entre BDs heterognies i distants implica conixer com poden interactuar diferents SGBD locals. Per aix, cal tenir en compte que cada SGBD pot suportar: SGBDs que poden tenir models de dades diferents als d'altres SGBDs, Esquemes Conceptuals diferents, Control particular de la semntica de les dades i Aplicacions dispars.

L'heterogenetat en BD significa totes aquestes discrepncies, i alguna ms, potser ms important que les ja esmentades. Per exemple, faltaria afegir la consideraci deguda a: Heterogenetat en els valors de les dades prpiament dits,

I aquest ltim aspecte s molt ms difcil i important que tots els anteriors, perqu la semntica ms rellevant i valuosa d'una BD est realment immersa en els valors de les dades prpiament dits. La definici dels esquemes conceptuals, com motlles que sn, recull una semntica molt necessria, imprescindible, per que resulta pobre i rgida. Els valors de les dades sn, en si mateixos, un recurs considerat, cada vegada ms, com el ms valus d'entre tots els recursos. Les dades en si, quan sn fiables, sn les que ajuden a incrementar el rendiment de les empreses, i els que poden permetre viure en una societat millor i ms justa, si s'usen de forma correcta. La interoperabilitat tracta doncs d'aconseguir una funcionalitat que sigui capa d'activar mltiples aplicacions dirigides a actuar sobre diversos SGBDs locals. De tal manera que cada SGBD local activi-al seu torn-els corresponents programes per accedir a la informaci dels seus BDs locals, que estan implicades en el funcionament global. Cada conjunt de dades resultants que prov d'una localitat ha de poder ser integrat amb els que produeixen altres SGBDs que suporten altres BDs. De tal manera, que el resultat final sigui un nou conjunt de dades globals obtingut mitjanant la integraci de les parts. Les dades globals han de ser tan fiables, almenys, com ho eren a cada illa d'informaci d'on provenen. Anomenem dades locals als obtinguts des de cada illa d'informaci, i dades globals aquells que es deriven de dos o ms illes i es perceben com extrets d'una manera integrada. Les dades globals poden, doncs, procedir de diverses localitats o illes d'informaci particulars que estan fsicament disperses. La interoperabilitat s ortogonal a la distribuci dels sistemes, s a dir, ni la implicaci ni l'exclou. La tecnologia que hi ha per aconseguir aquest objectiu s molt recent, est molt diversificada, i no hi ha molt assentament entre les diferents tcniques disponibles per aquest interessantssim aspecte. Anem a classificar, en quatre nivells jerrquics, els conceptes i tcniques que envolten la idea de la interoperabilitat. A la segent figura veiem un exemple senzill d'interoperabilitat on els SGBD resideixen en una nica mquina resideixen en una sola mquina i, per tant, no hi ha distribuci.

40

Mentre que en la figura a continuaci es descriu el mateix exemple d'interoperabilitat, per distribut.

El mn de la Interconnexi: OSI, DARPA, SNA I DNA El tipus de servei bsic de les xarxes d'ordinadors que interessa al tema de la interoperabilitat, entre Sistemes d'Informaci ubicats en mquines diferents i distants, s aquell que ofereix una transmissi de la informaci extrem a extrem, de manera fiable i econmica, que salva l'heterogenetat de les xarxes que suporten la connectivitat, i oculta les seves caracterstiques a les Aplicacions. Anomenem bsic a aquest servei perqu la idea d'interoperabilitat (que ens ocupasinstalla sobre ell com si de maquinari es tracts. Aquest servei bsic l'ofereixen avui diferents tecnologies. Per exemple, el nivell quatre de OSI, la capa de transport, i els seus equivalents en altres implementacions, s'independitza als nivells superiors (siguin o no de la torre) de les caracterstiques fsiques de la xarxa que s'utilitzi. La figura segent compara els nivells de la torre OSI (de ISO) amb les tres implementacions originals ms importants: DARPA orinda d'Arpanet, SNA d'IBM i DNA de DEC. 41

El conjunt de protocols TCP / IP s el ms utilitzat per a la interoperabilitat dels sistemes i, a ms, dna suport a altres serveis immediatament superiors, com vol representar la figura, que a la torre OSI es situen en les capes altes. D'entre ells, destaquem els segents: Accs remot de terminals (Telnet) que s de l'arquitectura de TCP / IP. El seu equivalent en OSI s el "Virtual Terminal Protocol" (VTP, nivell 7), Transferncia de fitxers (FTP), l'equivalent en OSI s FTAM - nivell 7, Correu electrnic (SMTP, 7), l'equivalent en OSI s X.400 - nivell 7, i Crides a procediments remots (RPC) en qu es basa la interacci Client / Servidor.

D'altra banda, la figura segent mostra algunes dependncies jerrquiques entre els diferents protocols i serveis de les xarxes. En ella es reflecteixen dos aspectes que cal destacar: 1) la diversitat d'implementacions tenen poca estructuraci conceptual i l'escassetat de contingut que avui ofereixen els nivells alts d'OSI (5, 6 i 7). Per exemple, mentre els serveis de X.400 (correu electrnic d'OSI) estan en el nivell 7 de la seva torre, el seu equivalent SMTP s'instal directament sobre TCP / IP. 2) destacar al protocol RPC (Remote Procedure Call), per la rellevncia que t en la tecnologia de BDs interconnectades. I a XDR, proposat per SUN (avui d'Oracle), que s un format de representaci externa per a les crides a procediments remots.

42

RPC s una implementaci de SUN (avui propietat d'Oracle), i adoptada com a estndard de facto en la majoria de les implementacions que diuen anomenar distribudes i que funcionen realment sota una arquitectura Client / Servidor. Nivells d'Interoperabilitat. Es defineixen en aquest punt, quatre nivells que, de forma jerrquica i modular, van proporcionant cada vegada serveis ms interoperables, segons es va pujant en la jerarquia. Un nivell sinstalla sobre l'inmediatament inferior i, per a la seva implementaci, utilitza els serveis que li ofereix el seu nivell immediat inferior, per no pot usar els que figurin en les capes superiors a ell. A continuaci es descriu el tipus de funcionalitat que cada nivell ofereix als efectes de la interoperabilitat. Primer Nivell de Interoperabilitat: TCP, Interconnexi d'Aplicacions qualssevol. Basat en els serveis del nivell de transport (com TCP / IP). Amb TCP / IP poden interoperar aplicacions que resideixen en mquines diferents i amb diferents Sistemes Operatius (Unix, VMS, MS-DOS, etc .., i alguns entorns com Windows). Tamb, sobre TCP / IP poden interactuar processos remots dels sistemes que s'executen en plataformes diferents i distants. TCP / IP va ser adoptat per Berkeley per incloure'l en la seva versi de UNIX. Amb aquest primer nivell bsic dInteroperabilitat, l'usuari interactua de forma transparent a la xarxa dInterconnexi d'ordinadors. Garanteix la interconnexi entre Aplicacions qualssevol que resideixen en mquines diferents (amb Sistemes Operatius heterogenis) i interconnectades amb xarxes possiblement heterognies. Segon Nivell de Interoperabilitat: Arquitectura Client / Servidor i Accs Remot a bases de dades. El segon nivell dInteroperabilitat, installat a jerarquia sobre el primer, materialitza, entre altres, el protocol d'interacci Client / Servidor. La idea s considerar noms el paper que juguen els programes en interactuar respecte als processos que s'han d'executar. Un programa que requereix un servei s'erigeix com a client, i el procs -que atn la sollicitud del client actua de servidor. Aquests processos poden residir en Sistemes d'Informaci Heterogenis (com, per exemple: SGBD, Sistemes Experts, Sistemes de

43

Fitxers com els Documentals; Fulles de Clcul, etc.) On uns interoperar amb altres seguint aquesta forma d'interacci C / S. Quan un usuari (o API) d'una mquina necessita l'execuci d'un programa que ella no t (o no pot executar), llavors s'erigeix com a client del sistema interconnectat. La mquina que alberga el SI necessitat ser la servidora. L'usuari, per a aquest nivell dInteroperabilitat, necessita donar en les ordres dInterconnexi dels segents parmetres en sollicitar el servei que requereix: l'adrea o el nom del servidor, invocar el SI en qesti i enviar el codi a executar-se en remot (en BD, el "Query" o la Consulta), donar el nom de la seva mquina client i altres parmetres necessaris al codi en qesti que s'envia. La consulta, o en general l'accs, al SI s'executa en el servidor qui, desprs d'obtenir la resposta al vostre ordinador, envia aquests resultats al Client En aquest nivell nicament es tenen accessos des d'un sol punt client a un altre nic punt que li serveix. La Interconnexi s, doncs, punt-a-punt entre un aplicatiu i un SGBD que actua de servidor. Una de les funcionalitats oferta pel protocol C / S s el Remote Database Access, RDA, Accs Remot a bases de dades. Per a aquest segon nivell dInteroperabilitat, OSI ofereix l'estndard RDA que est per sobre de la modalitat C / S, per els dos pertanyen a la capa set de la seva torre, Al costat de RDA, i per sota d'ell, hi ha els elements de servei ACSE (Association Control Service Element) i ROSE (Remote Operation Service Element), tamb pertanyents a la capa set de la torre OSI (Aplicacions). Finalment, en aquesta capa 7, hi ha el protocol CCR (Commitment Concurrency Recovery) que garanteix l'execuci concurrent, segura i atmica de transaccions que afecten a la representaci de dades. CCR es va dissenyar i implementar en els anys 70 's en, i per, la tecnologia dels SGBD i, posteriorment, OSI el va incorporar en el nivell set de la seva torre.

Cap producte comercial ha seguit aquesta arquitectura per oferir i implementar RDA. Des del punt de vista del tema que ens ocupa, interessa destacar que el RDA proporciona un nivell molt primitiu i baix per al que pretn la interoperabilitat. RDA permet que, des d'una mquina remota, s'accedeixi a una sola BD (normalment, una illa) i res ms. 44

Des del punt de vista de les dades resultants que obt el programa que accedeix a la BD, la cosa s bastant anloga als accessos realitzats a una BD centralitzada i allada. Noms afegeix el RDA, llevat que hi ha distncia geogrfica pel mig. Les implementacions comercials anomenades RDA utilitzen directament els serveis que ofereix TCP / IP (pont als nivells 5 i 6 d'OSI). Aix, el consorci de subministradors SQL Access Group ha millorat les especificacions de l'Accs Remot a bases de dades d'OSI. D'altra banda, XA / XOPEN ha definit directament sobre TCP / IP una collecci de rutines, crides CLI rutines (Call Level Interface). Sobre CLI estan implementades les crides a procediments remots RPC amb format de representaci externa XDR. Aquestes implementacions s'han realitzat per, i per, la tecnologia de BD (els SGBD) de manera que un Client pot accedir a qualsevol Servidor de Bases de dades relacional (per exemple: Sybase, Oracle, Ingres, Informix, etc.) De forma transparent, sense estar obligat a incorporar cada vegada les ordres abans descrits en les crides al servidor. Un dels productes ms utilitzats per a l'accs remot a bases de dades s el de Microsoft, conegut com Open DataBase Connectivity, ODBC. La figura segent mostra el funcionament d'aquestes implementacions de RDA, que sn les que realment funcionen en tota la tecnologia de bases de dades.

Les APIs Les APIs (Application Programming Interface), d'altra banda, ofereixen funcions organitzades en biblioteques (libraries) per a diferents finalitats: Accs a funcions de Comunicaci, Accs a funcions de BDs, etc. A la interfcie de cada nivell de la torre OSI, existeixen diferents APIs. Hi ha productes que tamb materialitzen aquest segon nivell dInteroperabilitat entre diferents SO i diferents SI heterogenis. Tamb, per exemple, Microsoft ha creat una interfcie anomenada ODBC (Open Database Connectivity) per a l'accs a dades de SGBDs heterogenis (relacionals o no). Amb ODBC el programador d'aplicatius pot accedir (consultar i / o actualitzar) a moltes BDs heterognies concurrentment. Per tant ODBC ofereix una API portable a diversos entorns, a ms de contenir al SQL estndard. Una variant de ODBC s Java DataBase Connectivity JDBC que pot considerar-se un estndard de facto en l'arquitectura web (tres o ms capes),. Addicionalment, de forma complementria, i com a exemple prctic, Microsoft comercialitza, sota Windows, una interfcie de programaci, anomenada API 45

(Application Programming Interface), corresponent a la part frontend d'un sistema interconnectat, i, tamb ha elaborat una arquitectura WOSA (Windows Open Service Architecture), que inclou APIs per missatgeria. En el segon nivell dInteroperabilitat s'ha incls tamb el protocol DDE (Dynamic Data Exchange) de Microsoft. DDE s equivalent, en la seva funcionalitat, al nivell 6 d'OSI. Amb DDE, una aplicaci local Windows pot intercanviar dades amb qualsevol altra. El protocol DDE funciona punt-a-punt i pot treballar en forma remota si s'intercala un gestor de xarxa (router) DDE. Aix s com est integrat en la tecnologia Windows for Workgroups. Tamb tenen cabuda en aquest segon nivell dInteroperabilitat les passarelles de software (Gateways programari) que des d'una aplicaci client permeten accedir a dades que resideixen a altres mquines (IBM, UNISYS, VAX, TANDEM, etc). D'ara endavant, coneixerem al segon nivell d'interoperabilitat com l'encarregat de proporcionar el segent servei: Serveis d'Accs Remot a BDs (RDA) i d'Interfcies a altres SI Heterogenis (APIs), basats en la interacci Client / Servidor. Les utilitats dels SGBD comercials anomenen aquest programari amb les paraules LINK (per a accs remot directe punt-a-punt) o NET (mitjanant gateways) amb el nom del producte Tercer Nivell. Interoperabilitat entre BDs Centralitzades i Interconnectades o entre BDs Distribudes Homognies i altament integrades. El nivell tres dInteroperabilitat contempla els problemes d'accs (concurrent) a diversos servidors, amb diferents SGBDs, produt per una aplicaci que accedeix a dades globals. Es diu global perqu necessita integrar informaci provinent de diverses localitats, cadascuna amb un o diversos SGBD. En aquest nivell s'inclouen els algoritmes, tcniques i eines adequats per a la descomposici, planificaci i execuci de consultes distribudes, que es duen a terme pel Processador de Consultes Distribudes (Distributed Query Processor) i Engegada de les Consultes Distribudes. El que significa tamb l'actualitzaci (altes, baixes i modificacions) de dades distribudes, de forma ntegra, consistent i fiable. Els accessos a una BD, abans de ser executats, es tradueixen internament a transaccions per poder ser tractats, si fos necessari, com blocs especials als quals poder exigir caracterstiques tamb especials de: Atomicidad, Consistncia, Allament i Durailitat (o persistent) conegudes com les propietats ACID .. Les transaccions contenen els segents tipus d'instruccions elementals: De lectura de dades,-read (x) -, De escriptura de dades,-write (i) -, Begin-transaction, sentncia prpia dels mecanismes per controlar la concurrncia que assenyala el punt d'inici de la transacci, Commit, sentncia prpia dels mecanismes per controlar la concurrncia que assenyala un punt de final de la transacci que ha acabat amb xit, Abort o rollback, sentncia prpia dels mecanismes per controlar la concurrncia que assenyala un punt de final de la transacci que ha acabat de forma anormal.

Dins dels SBDD, un cop pre-processada la consulta, i traduda a transaccions en aquest tipus de sentncies de baix nivell que acabem d'esmentar, es distingeixen dos grans blocs operatius El primer bloc, anomenat Monitor de Transaccions Distribudes, que garanteix el Allament i la consistncia de les transaccions. Coincideix amb la part de programari encarregada de pre-processar les transaccions a BDD de manera concurrent, distribuda 46

i segura. Cont al Gestor de transaccions Distribudes (Distributed Transaction Manager) i al Planificador de la Concurrncia (Scheduler). El segon bloc, anomenat Gestor de Dades Local, garanteix la Atomicidad i la Persistncia de les dades. Est format pel Gestor de Recuperaci Local (Local Recovery Manager) encarregat de la recuperaci local davant fallades, que executa les sentncies: begin-transaction, commit i abort. La tecnologia de BDs s mestra en aquestes tcniques del programari bsic des de ja molts anys, quan els SGBDs eren i funcionaven noms com centralitzades i com autntiques illes. I, finalment, el gestor de Dades, que executa les operacions de lectura i escriptura a la base de dades. Escriu en molts mitjans diferents, per garantir la persistncia El nivell tres d'interoperabilitat compta avui amb diferents solucions comercialitzades. Per exemple, per a la gesti global de transaccions en entorns de servidor de bases de dades Heterogenis, alguns comercialitzen sistemes de gesti de transaccions utilitzant monitors de transaccions amb interfcies normalitzades d'acord amb XA / XOPEN com a referncia d'estandarditzaci. El protocol per al control de la concurrncia Two Phase Commit (2PC), basat de vegades en el Two Phase Locking, en Timestamping o en Hbrids, assegura una bona execuci de transaccions concurrents i distribudes. Podem dir que la interoperabilitat oferta en aquest nivell es pot conixer com l'encarregada de dos objectius que sn diferents i que solen no ser distingits avui amb claredat pels usuaris: Processament de Consultes a Bases de Dades Distribudes, Homognies i altament integrades (dissenyades "Top-Down") Processament de Consultes Distribudes a mltiples bases de dades Centralitzades i Interconnectades

Els Sistemes Relacionals de BDDs permeten que l'esquema conceptual d'una BDR, i les seves corresponents dades, habiten en una varietat de mquines diferents, amb diferents SOs, i interconnectades per una varietat de xarxes diverses, per funcionar com si tot estigus emmagatzemat en una sola BDR virtual d'una nica mquina. La transparncia oferta pels SGBDs s molt alta, ja que l'usuari (programador d'aplicacions o final) d'una BDD no necessita conixer en absolut cap detall sobre els aspectes de distribuci. Aquest captol descriu un tipus de distribuci ms imperfecte que el de les BDD. Aquest captol noms es refereix al processament distribut de les consultes, quan hi ha moltes BDs i cadascuna d'elles est centralitzada (les seves dades no estan distribudes), i situada en un lloc geogrfic diferent i distant d'on resideixen les altres que, d'alguna manera, participen en un funcionament global. En el processament distribut, el node client (des d'on interactua l'usuari o el seu aplicaci) es considera sempre la part "Front-end", i els nodes servidors d'informaci constitueixen la part "Back-end".

47

Designarem a una o altra part ("Front-end" o "Back-end") com l'encarregada de la interoperabilitat, quan s'hi realitzi la integraci de dades locals per obtenir les dades globals que requereix l'usuari. Aix, per exemple, en la part "Back-end" de la figura es pot veure com les consultes s'executen de forma allada-en cada BD centralitzada-, i la interoperabilitat aconseguida en la part "Front-end" va a crrec de cada aplicatiu de l'usuari (no del sistema). Aquesta soluci no ofereix transparncia a l'usuari, cosa que dificulta enormement el seu s per la seva alta complexitat, alhora que pot resultar vulnerable i insegur. Quart Nivell de Interoperabilitat: BDs Heterognies, Distribudes, Federades i Multidatabases. El quart nivell d'interoperabilitat s l'encarregat d'integrar en una globalitat la informaci heterognia resident en mltiples localitats de forma automtica, transparent a l'usuari, i amb independncia del tipus d'aplicacions que vagin a requerir. Arrenca en considerar l'existncia prvia d'illes d'informaci que van ser dissenyades amb independncia les unes de les altres i es busca una forma viable de cooperaci global, el ms automtica possible, on l'autonomia local s un principi vital i ineludible. De manera que la totalitat del Sistema Interoperable es percebi per l'usuari com si d'un SI centralitzat es tracts. Aquest quart nivell pretn oferir solucions per l'heterogenetat anlogues a les que ja disposa la tecnologia relacional distribuda, homognia i dissenyada 'top-down'. Aquest nivell constitueix un difcil repte encara no aconseguit. Termes afins al quart nivell d'Interoperabilitat sn Data Warehouse i Data Mining. Aquest nivell inclou els segents aspectes: Integraci d'esquemes heterogenis en SGBD diferents, Salvar de forma automtica l'heterogenetat semntica dels valors de les dades, Multidatabases i llenguatges per multisistema (MSQL3 i IPL4).

Per a aquest nivell d'interoperabilitat no es disposa encara de tecnologia comercialitzada, i el tema est tenint un esfor investigador molt alt.

48

Coneixerem al quart nivell descrit com l'encarregat d'oferir una: Interoperabilitat entre Bases de Dades Heterognies i Pre-existents, per aconseguir una Cooperaci Global Distribuda, b per disseny "Bottom Up" (BDs integrades per federaci d'esquemes) o b per un llenguatge per "multidatabases", que oculti la seva inherent complexitat als usuaris. La segent figura mostra una panormica dels quatre nivells d'interoperativitat descrits.

49

3. SGBD Distributs
Fins ara hem considerat sistemes en els quals els dispositius demmagatzematge estan connectats directament a un processador central. s ms, les primeres bases de dades tenien una forta centralitzaci i es van convertir en grans magatzems de dades monoltiques. Aquesta tendncia va canviar a finals de la dcada de 1980 a causa de lanlisi de moltes situacions en les quals ls dun sol processador central no era la millor soluci i dels avenos produts en els sistemes operatius respecte al processament distribut.. Hi ha diverses raons que ens poden aconsellar portar les dades a un processament distribut: - Raons funcionals un sistema sol realitzar un cert nombre de funcions diferents y pot resultar convenient desenvolupar i gestionar aquestes funcions per separat. - Raons geogrfiques si existeixen usuaris en diferents localitzacions pot resultar eficient realitzar una part important del processament de forma local. - Autonomia quan una empresa sorganitza en departaments o rees amb una certa autonomia s usual que cada rea tingui accs a una zona dinformaci restringida. - Fiabilitat Si un sistema es composa de diferents parts allades, gran part del sistema seguir funcionant quan es produeixi una fallada en alguns dels processadors o dispositius demmagatzematge. - Creixement Si augmenta molt la demanda sobre una part del sistema, pot afegir-se una nou node que proporcioni la capacitat addicional necessria sense afectar a la resta del sistema. A causa daquesta raons, s important distribuir el processament total del sistema de forma que el processament local redueixi les demandes sobre la xarxa. De manera informal, un sistema de bases de dades distribudes est composat per un conjunt de nodes (localitats) separats fsicament i connectats entre s mitjanant una xarxa de comunicacions de forma que: - Cada node s un SGBD en s mateix. - Els nodes poden intercanviar dades i treballar conjuntament si s necessari amb el propsit que si un usuari de qualsevol localitat pugui tenir accs a les dades de qualsevol node de la xarxa, com si estiguessin emmagatzemades en el seu propi node. s important destacar que cada node s un SGBD que t els seus propis usuaris, els seus programes daplicaci i el seu propi administrador local. En particular, un usuari pot realitzar operacions sobre les dades de la seva BD local sense tenir coneixement de que aquesta BD participa en un sistema distribut. Poden donar-se dues situacions diferents depenent del nivell dacoblament i de similitud que sexigeix entre cadasc dels nodes participants: - SGBD Distribut homogeni estem exigint que els nodes participants tinguin idntic software (SGBD) i que tots ells siguin conscients de lexistncia de la resta de nodes, amb els que tindran que cooperar en el processament de les transaccions. - SGBD heterogenis els nodes participants poden utilitzar diferents SGBD i diferents esquemes de BD, incls pot donar-se el cas de que algunes localitats no

50

spiguen que existeixen les altres i la seva cooperaci es limiti a proporcionar certes facilitats de processament. En el primer cas tots els nodes renuncien a part de la seva autonomia (sobretot pel que respecta a modificar lesquema de la BD o el software de gesti) en benefici del sistema en la seva globalitat. En el segon cas, cada node conserva completament la seva autoritat, la qual cosa condueix a grans problemes denteniment.

Sistema Distribut de Bases de Dades Caracterstiques Principals duna BD Distribuda El principi fonamental de les BD Distribudes pot expressar-se com Des del punt de vista de lusuari, un sistema distribut haur de ser idntic a un sistema no distribut. s a dir, el comportament de lusuari ha de ser el mateix tant si el sistema s distribut com si no. En termes dSQL, la lgica de les operacions SELECT, INSERT, UPDATE i DELETE no ha de patir canvis. Les operacions de DDL, en canvi, han de patir canvis, aix, per exemple, quan es crea una taula en el node X, el creador podr especificar que sha demmagatzemar al node Y. Conceptes Fonamentals Podem considerar que un SGBD posseeix una estructura composada per dues parts: una secci posterior i un conjunt de seccions frontals.

51

La secci posterior s el propi SGBD. Permet portar a termini totes les funcions bsiques prpies: definici de dades, manipulaci de dades, seguretat, integritat, etc. O sigui, tots els aspectes dels nivells extern, conceptual i intern. Les seccions frontals son les diverses aplicacions, tant les escrites pels usuaris com les integrades, que son proporcionades pel provedor del SGBD o per altres provedors de programes, executades sobre el SGBD.

Vist aix, podem concloure que, donat que el sistema general es pot dividir amb tanta claredat en dos parts, apareix la possibilitat dexecutar-les en mquines diferents, s a dir, existeix el potencial per un processament distribut (s possible connectar varies mquines que formen algun tipus de xarxa de comunicaci, de tal mode que una sola tasca de processament de dades pot repartir-se entre varies mquines. LAdministrador de Comunicacions de Dades (Administrador DC) Les sollicituds dun usuari final adreades a la base de dades es transmeten, en la prctica, des del terminar de lusuari fins alguna aplicaci en lnia (integrada o no) i des daqu al SGBD en forma de missatges de comunicaci. De manera similar, les respostes a lusuari (des del SGBD i laplicaci en lnia, de tornada al terminal de lusuari) tamb es transmeten com a missatges daquest tipus. Totes aquestes transmissions sefectuen sota el control dun altre sistema de programes, ladministrador de comunicaci de dades. Aquest no s un component del SGBD sin un sistema autnom. Tanmateix, com que el SGBD i Administrador DC han de treballar junts, de vegades sels considera com a socis equitatius en una empresa cooperativa de major nivell denominada DB/DC, en el qual el SGBD sencarrega de la BD i lAdministrador DC de tots els missatges que arriben a la BD i surten della. Processament Distribut El terme processament distribut significa que varies mquines poden connectar-se entre s per tal de formar una xarxa de comunicacions, de forma que una sola tasca de processament de dades pogu implicar a varies mquines de la xarxa. Un cas senzill consistiria en executar la secci posterior del SGBD en una mquina i les seccions de frontals daplicaci en una altra. Un sistema client/servidor, en el qual la secci frontal s el client i la posterior s el servidor t molts arguments al seu favor: Processament en parallel distribuir el processament de la secci posterior (SGBD) i el de la secci frontal (aplicacions) de manera que es realitzin en parallel, millorant el temps de resposta i el rendiment. 52

La mquina servidor (secci posterior) podria estar construda a propsit per la funci de SGBD (mquina de BD) i tenir millor rendiment. La mquina client (aplicacions) podria ser una estaci de treball personal, adaptada a les necessitats de lusuari final i per tant, capa de proporcionar-li millors interfcies, alta disponibilitat, respostes ms rpides i, en general, facilitat ds. Varies mquines client diferents podrien ser capaces daccedir a la mateixa mquina servidor. Aix, una sola BD podria compartir-se entre varis sistemes de secci frontal, potser molt diferents.

Larquitectura client/servidor pot portar-se ms lluny encara amb la participaci de varis servidors. Aquesta idea concorda amb la forma real doperar de moltes empreses en les qu es disposa de moltes mquines de tipus servidor i aix, les dades duna part de lempresa semmagatzemen en una mquina i els duna altra part semmagatzemen en una altra mquina. Tamb ocorre molt sovint que els usuaris duna mquina necessiten accs a les dades emmagatzemades en una altra de manera ocasional. Per tant, la mquina de secci posterior podria tenir tamb aplicacions prpies de secci frontal (cada mquina funcionar com a servidor per alguns usuaris, i com a client per a uns altres). Hem de deixar clar que una sola mquina client podria ser capa daccedir a varis servidors diferents. Existeixen dues formes bsiques de permetre aquest accs: Una certa aplicaci de secci frontal podria tenir accs a qualsevol quantitat de sistemes de secci posterior, per noms un a la vegada, s a dir, cada sollicitud individual a la BD haur danar adreada a noms una de les seccions posteriors i no s possible, dintre de la mateixa sollicitud, combinar dades de dues o ms seccions posteriors diferents. A ms a ms, lusuari haur de conixer quina secci posterior cont certs elements dinformaci. Un sistema daquestes caracterstiques s el que sanomena Sistema dAccs Remot a les Dades. Una aplicaci de secci frontal podria tenir accs a qualsevol quantitat de sistemes de secci posterior de forma simultnia, s a dir, una sola sollicitud a la BD podria ser capa de combinar dades de varies seccions posteriors. En aquest cas, la secci frontal percep a les diferents seccions posteriors com si fossin en realitat un sol sistema (des del punt de vista lgic), i el usuari no necessita conixer la ubicaci de cada element dinformaci. Un sistema daquest tipus s el que es denomina Sistema de Bases de Dades Distribut.

Avantatges de la Distribuci de les Dades Utilitzaci compartida de les dades un sistema distribut permet que lestructura de la BD reflecteixi lestructura de la prpia empresa. Fiabilitat i Disponibilitat si es produeix una fallada en un dels nodes la resta del sistema distribut podr continuar treballant (encara que amb un menor grau doperativitat). Agilitzaci del Processament de Consultes si una consulta comprn dades de varis nodes, s possible dividir-la en varies subconsultes que sexecutin en parallel en cadasc dells.

Inconvenients de la Distribuci de les Dades

53

Major cost de desenvolupament del programari s ms difcil estructurar un sistema distribut. - Major possibilitat de que es produeixin errors Donat que els nodes operen en parallel, s ms difcil garantir que els algorismes siguin correctes. - Major temps de processament lintercanvi de missatges i els clculs addicionals que es requereixen per coordinar els nodes son una despesa de temps extra que no existeix en els sistemes centralitzats. - Un altres problema s que les xarxes de comunicacions son lentes (almenys les de llarga distncia) pel volum de missatges que circula. En escollir el disseny duna BD sha de fer un balan entre els avantatges i els inconvenients de la distribuci de dades. Hi ha varis enfocaments pel disseny de BD distribudes que van des de la distribuci total fins dissenys que inclouen un alt grau de centralitzaci. Components dun SGBD Distribut Maquinari involucrat El maquinari utilitzat no difereix molt del maquinari utilitzat en un servidor normal. Al principi es creia que si els components d'una base de dades eren especialitzats serien ms eficients i rpids, per es va comprovar que el descentralitzar tot i adoptar un enfocament "res compartit" (shared-nothing) resultava ms barat i efica. Pel que el maquinari que compon una base de dades distribuda es redueix a servidors i la xarxa Programari Sistema Gestor de Base de Dades Distribuda (DDBMS) Aquest sistema est format per les transaccions i els administradors de la base de dades distribudes. Un DDBMS implica un conjunt de programes que operen en diversos ordinadors, aquests programes poden ser subsistemes d'un nic DDBMS d'un fabricant o podria consistir d'una collecci de programes de diferents fonts. Administrador de transaccions distribudes (DTM) Aquest s un programa que rep les sollicituds de processament dels programes de consulta o transaccions i les tradueix en accions per als administradors de la base de dades. Els DTM s'encarreguen de coordinar i controlar aquestes accions. Aquest DTM pot ser propietari o desenvolupat a casa. Sistema Gestor de base de dades (DBMS) s un programa que processa certa porci de la base de dades distribuda. S'encarrega de recuperar i actualitzar dades de l'usuari i generals d'acord amb les ordres rebuts dels DTM. Node Un node s un ordinador que executa un DTM o un DBMS o ambds. Un node de transacci executa un DTM i un node de base de dades executa un DBM. El Diccionari de dades El diccionari de dades sestn per tal de recollir informaci sobre la distribuci de dades sobre la xarxa.

54

Al diccionari de la BDD es guardar informaci sobre la ubicaci de les dades, sobre els fragments de cada relaci i sobre la duplicaci de les dades. Base de dades amb metadades de fragmentaci i replicaci. Centralitzat: global en una nica seu, coll d'ampolla. Manca d'autonomia local Dividit: local a la seu, cerca no local costosa o b manca de transparncia Replicat: global en cada seu, molt redundant. Costs de mantenir. Es perd autonomia local Centralitzat / Dividit: global en una nica seu i local en cada seu. Redundncia. Dependncia d'una seu central a accessos a la BDD Mestre centralitzat i locals en cada seu: Redundncia. Dependncia d'una seu central a accessos a la BDD Mestre i locals en cada seu: Certa redundncia Planificador distribut El planificador est encarregat d'ordenar un conjunt de transaccions o operacions que es desitgin realitzar sobre una base de dades. Qualsevol ordre en el qual es decideixin fer aquest conjunt d'operacions es denomina planificaci. Part del treball del planificador s realitzar aquestes operacions de manera que siguin serialitzats i recuperables. Dos planificadors sn equivalents si Cada operaci de lectura llegeix valors de les dades que sn produts per la mateixa operaci d'escriptura en ambdues planificacions (s a dir sn iguals) L'operaci final d'escriptura en cada element de la data s la mateixa en ambdues planificacions Concepte de Transparncia en un SGBDD La transparncia en un SGBDD fa referncia al fet que els usuaris no han de percebre que es troben treballant en un entorn distribut. La transparncia oculta a lusuari els detalls dimplementaci i t com a objectiu fer que ls duna BD distribuda sigui equivalent al duna BD centralitzada. Tanmateix, a certs nivells daccs a la BD s impossible ocultar totalment la distribuci. Els nivells de transparncia que considerarem son els segents: Nivell de xarxa de comunicacions Nivell de noms de les dades Nivell de cpia i fragmentaci Nivell de localitzaci de fragments i cpies Nivell dactualitzacions Transparncia de Xarxa Una taula pot emmagatzemar-se de varies formes: pot dividir-se en varis fragments i cada fragment ubicar-se en un node diferent. La transparncia de xarxa oculta els detalls de la distribuci de la informaci en la xarxa, doncs s essencial que el sistema redueixi al mnim la necessitat de que lusuari sadoni de com est emmagatzemada una taula. s un concepte molt lligat a lautonomia local, que pot definir-se com el grau fins al qual el dissenyador o administrador duna localitat pot ser independent de la resta del sistema distribut.

55

Transparncia i Assignaci de Noms Tot element dinformaci duna BD ha de tenir un nom nic. En una BD que no estigui distribuda aix sassegura perqu tots els identificadors dels objectes es troben emmagatzemats en el diccionari de dades. En el cas duna BD distribuda, les diferents localitats han dassegurar-se de no fer servir el mateix nom per dos objectes diferents encara que es trobin en localitats diferents. Una soluci es demanar que es registrin tots els noms en un assignador central de noms que portar el control de la no duplicitat, per aix t una srie de problemes: - s possible que lassignador de noms es converteixi en un coll dampolla. - Si lassignador cau, s possible que cap localitat pugui continuar treballant. - Es redueix lautonomia local, ja que lassignaci de noms es controla de forma centralitzada. Un enfocament diferent i que origina una major autonomia local consisteix en exigir que cada localitat posi com a prefix un identificador de localitat a qualsevol nom que generi. Aix garanteix que dos nodes mai utilitzaran el mateix nom. A ms, aquesta soluci no requereix un control centralitzat. El problema daquesta soluci s que resta transparncia de xarxa, ja que sagreguen identificadors de localitat als noms. Transparncia de Cpia i Fragmentaci La rplica dinformaci s desitjable almenys per dos raons: - Pot produir un millor aprofitament en operacions de lectura o consulta, ja que les aplicacions poden operar sobre cpies locals en comptes de tenir que comunicarse amb nodes remots. - Tamb pot significar una millor disponibilitat, ja que un objecte estar accessible per al seu processament si est disponible almenys una cpia. No s convenient que els usuaris hagin de fer referncia a una cpia especfica dun element dinformaci. Ha de ser el sistema el que determini a quina cpia sha daccedir quan shagi sollicitat una lectura, i el que modifiqui totes les cpies existents quan es produeixi una petici descriptura. Per all, el sistema utilitza una taula-catleg que linforma de quines son les cpies daquesta dada i on sha de buscar. De manera similar, no ha dexigir-se als usuaris que spiguen com est fragmentat un element dinformaci. Un sistema manega fragmentaci de dades si s possible dividir una taula en parts o fragments per propsits demmagatzematge fsic. La fragmentaci s desitjable per raons de productivitat: les dades poden estar emmagatzemades en la localitat on sutilitzen amb ms freqncia, de manera que la major part de les operacions siguin locals i es redueixi el trnsit en la xarxa. Ms endavant veurem el tema de la fragmentaci Transparncia de Localitzaci Si el sistema s transparent en quant a repetici i fragmentaci, soculta a lusuari gran part de lesquema de la BD distribuda, per els components dels noms que identifiquen a la localitat i tamb als fragments i cpies obliguen a que lusuari sadoni que el sistema est distribut.

56

La transparncia de localitzaci saconsegueix creant un conjunt de pseudnims o alies per a cada node, permetent als usuaris de dit node referir-se a les dades utilitzant noms senzills que el sistema tradueix, posteriorment, a noms complerts. Amb ls de pseudnims, no s necessari que lusuari conegui la localitzaci fsica duna dada. A ms a ms, ladministrador de la base de dades pot canviar una dada duna localitat a una altra sense que aix afecti als usuaris ni a les aplicacions. Transparncia de les Actualitzacions s molt ms difcil fer transparent la distribuci de la base de dades pels usuaris que actualitzen dades, que per aquells que noms les llegeixen. El problema principal s assegurar-se de qu sactualitzen totes les cpies duna dada i tamb tots els fragments afectats. En el cas ms general, el problema dactualitzaci dinformaci repetida i fragmentada est relacionat amb el problema dactualitzaci de vistes. Disseny de Bases de Dades Distribudes Quan volem dissenyar un SGBDD shan de tenir en compte, a part de les consideracions prpies dun SGBD centralitzat, una srie de caracterstiques particulars exclusives del seu carcter distribut. Parlarem de les particularitats del Diccionari de Dades distribut i de les regles enunciades per C.I. Date pel correcte disseny de SGBDD. El Diccionari de Dades en les BD Distribudes Tota la informaci especfica sobre la distribuci de la BD ha demmagatzemar-se del mateix mode en el que es feia en una BD centralitzada, s a dir en el DD,, per, en aquest cas, el propi DD pot ser gestionat com a una BD distribuda i pot trobar-se fraccionat o replicat com si de qualsevol conjunt de taules es tracts. Al DD distribut que emmagatzema la informaci sobre la prpia estructura del sistema sel denomina Diccionari de Dades Global (o Catleg Global). Si el DD global semmagatzema de forma centralitzada en un node concret, el sistema seria molt vulnerable, doncs qualsevol problema en aquell node afectaria a tota la resta de components del sistema. Per altra banda, si el catleg global es copia en totes les localitats, qualsevol modificaci del mateix en un determinat node obligaria a aquest a comunicar-ho de forma immediata a la resta dels nodes perqu sactualitzessin, amb la qual cosa sestarien enviant missatges contnuament a travs de la xarxa i posant en perill la integritat del DD. Una situaci intermdia que resulta bastant ms eficient s la de mantenir un DD local en cadasc dels nodes, en el qual semmagatzema tota la informaci (metadades) sobre les dades emmagatzemades en aquell node. Ser responsabilitat del DD local de cada node registrar la definici de cada cpia i cada fragment per aquelles taules que hagin estat creades en ell. Aix doncs, per localitzar un fragment duna determinada taula shaur daccedir al DD local del node on va ser creada i consultar la ubicaci actual. s necessari que en cada DD local es registri el node de creaci de cadascuna de les taules de la BD distribuda. Podem dir que DD global s un DD virtual constitut per la informaci que es recull en tots i cadasc dels DD locals que semmagatzemen en els diferents nodes del sistema.

57

Les Dotze Regles de Date El principi fonamental s que lusuari ha de funcionar de la mateixa manera que si el sistema no estigus distribut. Les dotze regles van ser formulades per Christopher J. Date (matemtic britnic especialitzat en tecnologia de les bases de dades). 1. Autonomia local: els nodes dun sistema distribut han de ser autnoms en el major grau possible. 2. Independncia dun node central: tots els nodes han de ser tractat com a iguals. 3. Operaci contnua: En un sistema distribut, a ligual que en un no distribut, idealment no hauria dhaver necessitat dapagar-lo. s a dir, sempre hauria destar funcionant. 4. Independncia de localitzaci: per lusuari la localitzaci fsica de les dades ha de ser transparent. 5. Independncia respecte a la fragmentaci: els usuaris no necessiten conixer els fragments fsics en els quals est dividida cada collecci lgica de dades. 6. Independncia de replica: a nivell lgic els usuaris no necessiten tenir en compte si les dades tenen rpliques o no. 7. Processament distribut de consultes: el sistema distribut ha de disposar de mecanismes per a optimitzar les consultes i en especial, per reduir la crrega de trnsit necessria. 8. Gesti distribuda de transaccions: el sistema distribut ha de disposar de mecanismes (protocols) adients per al control de concurrncia i la recuperaci de transaccions distribudes. 9. Independncia del maquinari: sha de poder executar el mateix SGBD en llocs amb diferents plataformes de maquinari. 10. Independncia del sistema operatiu: sha de poder executar el mateix SGBD en llocs amb diferents sistemes operatius. 11. Independncia de la xarxa: el sistema distribut ha de poder operar amb diferents xarxes de comunicacions. 12. Independncia del SGBD: sha de permetre la heterogenetat, s a dir, cada node ha de poder funcionar amb un SGBD diferents, incls basat en un model de dades diferent, sempre i quan comparteixin una interfcie com. Fragmentaci Anem a veure de quines maneres podem particionar la BD. Hi ha els tipus de fragmentaci segents: - Fragmentaci Horitzontal : Per tuples Selecci o SemiJoin Uni - Fragmentaci Vertical : Per columnes Projecci Join - Fragmentaci Mixta : Segons esquema de fragmentaci La semijoin entre les taules R1 i R2 : Genera una taula R3 a partir de R1 y R2 que cont els atributs dR1 juntament amb les tuples dR1 ajuntades amb almenys una tupla de R2. Es equivalent a una join de R1 y R2 seguida duna projecci sobre els atributs dR1. 58

La fragmentaci saconsegueix aplicant una expressi en algun llenguatge relacional sobre la BD. Totes les dades de les relacions globals han de quedar en algun fragment. La fragmentaci s completa quan el conjunt de qualificadors s complet. Sha de donar la disjuntivitat dels fragments, s a dir, els fragments han de ser disjunts. s una condici molt important ja que el control de rpliques a la BD s a nivell de fragment. La relaci global ha de poder ser reconstruda a partir dels seus fragments. Loperaci duni serveix per a la reconstrucci. Fragmentaci Horitzontal Particiona el conjunt de tuples de la relaci global en subconjunts horitzontals. Sutilitza la operaci selecci o restricci. Exemple : PROVEDORS ( PR#, NOM, CD ) PROV_SF = PROVEDORS ( CD = SF ) Provedors de San Francisco PROV_LA = PROVEDORS ( CD = LA ) Provedors de Los Angeles Reconstrucci: Amb la uni dels fragments podem tenir la relaci global. Fragmentaci Horitzontal Derivada s basa en el mateix que la fragmentaci horitzontal per sense prendre cap dels atributs de la relaci com a criteri de fragmentaci. Loperaci utilitzada s el semijoin. Exemple: COMANDES ( PROV, ART, QTAT ) Volem tenir les comandes fragmentades per ciutat, per ciutat no s cap atribut. Busquem una altra fragmentaci horitzontal existent i la que volem la derivem daquella : Exemple : Comandes de NY i LA COMANDES, NY = COMANDES PROVEDORS, NY COMANDES, LA = COMANDES PROVEDORS, LA On A B = A B [atributs A] Si no disposem de PROVEDORS, NY, podem obtenir-lo : PROVEIDORS PROVEDORS ( CD = NY) Reconstrucci: s senzilla de comprovar : Uni. Fragmentaci Vertical Fragmentem el conjunt datributs de la relaci global en subconjunts verticals, de columnes o atributs. La operaci s la Projecci. Exemple: TREB ( SS#, NOM, TEL, ADR, SOU, CTE, DEPT ) Al departament de Personal li interessa : TREB1 = ( SS#, NOM, TEL, ADR, DEPT ) Al departament de Comptabilitat : TREB2 = (SS#, SOU, CTE )

59

Reconstrucci: Join TREB = TREB1 TREB2 Fragmentaci Mixta Consisteix en una combinaci de la horitzontal i la vertical. A causa de la possible complexitat de la fragmentaci, es defineix un arbre o esquema de fragmentaci que ens indica com particionar la relaci. Ens dna el mapping entre la Relaci Global i els fragments. Exemple: EMP ( SS#, NOM, SOU, TAX, CAP, DEPT ) Esquema de Fragmentaci: EMP1 = EMP (DEPT < 10 ) EMP2 = EMP (DEPT < 10 ) EMP3 = EMP (DEPT >= 10 ) EMP4 = EMP (DEPT >= 10 ) horitzontal En forma darbre : [ SS#, NOM, SOU, TAX ] [ SS#, CAP, DEPT ] [ SS#, NOM, DEPT ] [ SS#, SOU, TAX, CAP ] vertical

Reconstrucci: Aplicar els operadors convenientment recorrent larbre comenant per les fulles fins larrel. Ex: EMP = ( EMP1 EMP2 ) U ( EMP3 EMP4 ) Recuperaci en Sistemes Distributs En una BD distribuda, al igual que en una centralitzada, ha de garantir-se que les transaccions sexecuten de forma atmica, s a dir, sexecuten totes les seves instruccions o no sen executa cap. Quan treballem amb un SGBDD resulta molt ms difcil garantir la propietat datomicitat de les transaccions, ja que s possible que hi participin varies localitats en loperaci i la fallada duna delles o de la lnia de comunicacions afecten a la finalitzaci correcta de la mateixa.

60

La funci del gestor de transaccions distribudes dun SGBDD s assegurar que lexecuci de les transaccions (locals i distribudes) conserva latomicitat. Al igual que en el cas centralitzat, cada localitat compta amb el seu propi gestor local de transaccions, per els diferents gestors cooperen perqu lexecuci de les transaccions globals siguin correctes. Per tant, cada localitat del sistema cont dos subsistemes: 1. Gestor local de transaccions: t la funci de gestionar lexecuci daquelles transaccions i subtransaccions que accedeixen a dades emmagatzemades en aquella localitat. Observem que cada transacci pot ser o b local a la localitat o b part duna transacci global. 2. Coordinador de transaccions: la seva funci s coordinar lexecuci de les transaccions distribudes iniciades en aquella localitat. Funcions del gestor local de transaccions: - Mantenir una bitcola (diari) o taula de modificacions per a la recuperaci. - Participar en un esquema de control de concurrncia apropiat per coordinar lexecuci entrellaada de les transaccions que sexecuten en el node. Funcions del coordinador de transaccions: - Iniciar lexecuci de la transacci distribuda. - Dividir la transacci en varies subtransaccions, les quals ha de transferir a les localitat adients per a la seva execuci. - Decidir sobre la terminaci de la transacci, de manera que aquesta quedi executada en tots els nodes, o b avortada totalment. Protocols de Comproms Per garantir latomicitat duna transacci T en un entorn distribut , s necessari que totes les localitats en les qual es vagi a executar un fragment de la mateixa (agent) coincideixin en la decisi final sobre lexecuci (executada o avortada) de manera que T quedi globalment executada o avortada. Per garantir aquesta propietat, el coordinador de transaccions encarregat de T ha dexecutar un protocol de comproms. Entre els ms comuns i ms amplament utilitzats estan el protocol de comproms en dues fases i el protocol de comproms en tres fases. Protocol de Comproms en Dues Fases Sigui T una transacci que sinicia en el node N i i Ci el coordinador de transaccions daquesta localitat. Una vegada que T ha estat desglossada en varis agents o subtransaccions i aquests han estat transferits a travs de la xarxa de comunicacions Ci inicia el protocol Fase 1 el coordinador escriu en el diari el registre <preparar T>. Envia un missatge amb aquest contingut a tots els nodes implicats en la transacci. Cada procs implicat decideix si est preparat per fer el comproms, escriu en el seu diari la decisi <llest T> o <no llest T> i lenvia en un missatge al coordinador Ci. Fase 2 si el coordinador Ci rep alguna resposta negativa o obt algun error de resposta decideix avortar la transacci. En cas contrari decideix realitzar el comproms. El coordinador escriu en el diari la decisi i envia un missatge aols processos implicats.

61

Cada procs que rep el missatge escriu en els seu diari la decisi del coordinador C i i realitza lacci corresponent. La terminaci duna transacci es fa mitjanant la regla del comproms global. El coordinador avorta una transacci si i noms si almenys un procs implicat decideix avortar. El coordinador fa un comproms de la transacci si i noms si tots els participants decideixen realitzar el comproms. Comportament davant una fallada en un node: El node N es recupera desprs duna caiguda transitria i detecta que la transacci T no estava acabada. Si el diari cont <comproms T> es realitza la transacci. Si cont <avorta T> savorta la transacci, si cont <llest T> ha de consultar al coordinador per determinar si es compromet o avorta la transacci, si no hi ha missatges en el diari, savorta T. Comportament davant fallades del coordinador: Cada node implicat N ha de decidir sobre la transacci T. Si el diari cont <comproms T> es realitza la transacci. Si cont <avorta T> s'avorta, si no cont <llest T> el coordinador no ha pogut decidir el comproms, per tant, el ms apropiat s avortar la transacci. Si tots els nodes tenen <llest T> per cap t <comproms T> o <avorta T> no es pot determinar la decisi del coordinador. Shauria d'esperar que es recupers. Protocol de Comproms en Tres Fases El protocol de comproms en tres fases est dissenyat per tal dimpedir la possibilitat dun bloqueig en el cas de qu el coordinador hagi fallat i tots els nodes actius tinguin un registre <llest T>. El protocol afegeix una fase extra merament informativa, en la qual es posa en coneixement de les localitats participants certa informaci que les permet prendre una decisi malgrat la fallada del coordinador. Fase 1 s idntica a la fase 1 del protocol de comproms en dues fases. Fase 2 si Ci rep el missatge davortar T duna localitat o si C i no rep resposta dintre dun interval de temps especificat duna localitat, llavors, C i decideix avortar T. Si pel contrari Ci rep un missatge <llest T> de totes les localitats participants, prendr la decisi preliminar de preexecutar T. Ci envia un missatge <preexecutar T> a totes les localitats participants. Aix informa a cada localitat participant de qu totes les altres estan llestes Les localitats enviaran un missatge de reconeixement a Ci <registrat>. Fase 3 aquesta fase noms sexecuta si la decisi en la fase 2 s la de preexecutar. Desprs de que els missatges de <preexecutar> hagin estat enviats a totes les localitats participants, el coordinador espera fins rebre almenys un cert nombre K de missatges de reconeixement. Ci es conforma amb que la informaci de preexecutar hagi estat guardada en K taules de modificacions, resultat molt poc probable que es produeixi un bloqueig del sistema en cas de caiguda de Ci. Seguint el procs, Ci pren la decisi final i envia <executar T> a totes les localitats participants. Comportament davant una fallada en un node: El node N es recupera desprs duna caiguda transitria i detecta que la transacci T no estava acabada. Si el diari cont <executar T> es realitza la transacci. Si cont <avorta T> savorta la transacci, si cont <llest T> i cap <avortar T> ha de consultar al coordinador i si aquest respon <preexecutar T> envia el reconeixement al coordinador per si el coordinador respon amb el missatge de qu T sha executat, el node executar. I si el coordinador falla en respondre dintre dun interval de temps, el node executar el protocol de fallada del coordinador. Per ltim, si la taula de modificacions cont un registre <preexecutar T> i 62

cap registre <avortar T> o <executar T> haur de consultar al coordinador, si C i respon que T ha estat executada o avortada, el node executar o avortar respectivament. Si Ci respon que T est en estat de preexecuci, la localitat continuar el protocol en aquest punt. Si Ci no respon en un interval de temps, la localitat executar el protocol de fallada del coordinador. Comportament davant fallades del coordinador: Les localitats participants trien un nou coordinador utilitzant un protocol de selecci. El nou coordinador C envia un missatge a cada localitat participant demanant lestat local de T. Cada localitat, inclosa C, determina lestat local de T (mirant en la seva taula de modificacions) i envia aquest estat a C. Depenent de la resposta rebuda, C decideix si executar o avortar T o b reiniciar el protocol segons els casos: - si almenys una localitat t lestat local dexecutada, executa - si almenys una localitat t lestat local davortada, avorta - si almenys una localitat t lestat local de preexecutada, C reprn el protocol enviant missatges <preexecutar T> nous - en la resta de casos, avorta Donat el funcionament del protocol, s necessari que: - No pugui ocrrer una fragmentaci de la xarxa, ja que, de produir-se, podrien ser triats dos coordinadors (un per cada subxarxa) les decisions dels quals podrien no coincidir. - Ha dhaver, com a mnim, un nombre K de participant actius en qualsevol moment (sent K el nombre mnim de missatges de reconeixement que ha de rebre el coordinador en la fase2 per continuar endavant amb el protocol. Control de Concurrncia En un SGBDD ha de donar-se tamb el principi de transparncia de la concurrncia, que diu que els resultats de les transaccions (tant locals com distribudes) executades de manera concurrent han dobtenir-se de manera independent i coincidir amb els resultats que shaguessin obtingut a travs duna execuci en srie de les mateixes. Tanmateix, ara tenim la complexitat de qu lexecuci pot realitzar-se en diferents nodes i sha de garantir que les transaccions locals i distribudes no interfereixen entre s. A tot aix sha dafegir la complexitat de la possible presncia de rpliques, la qual cosa complica encara ms lexecuci concurrent. Hi ha dos mecanismes generals per controlar la concurrncia i garantir laccessibilitat de les transaccions en curs: - Ordenar les transaccions segons lhora darribada o instant en qu comena la seva execuci. - Utilitzar el mecanisme de bloqueig en dos fases, on les transaccions sordenen segons linstant en que aconsegueixen acaparar tots els toms sobre els que han de portar a termini alguna operaci. Ordenaci per hora darribada La primera cosa que sha de fer s desenvolupar un esquema per generar hores dentrada niques, doncs, por donar-se el cas de qu en dos nodes sassigni la mateixa prioritat a dues transaccions que han dexecutar-se de mode distribut. En general, existeixen dos mtodes per generar hores dentrada niques. Un centralitzat i un altre distribut.

63

A lesquema centralitzat es tria una sola localitat per a encarregar-se de generar hores dentrada. Aquesta localitat pot utilitzar un comptador lgic o el seu propi rellotge per evitar la duplicitat en les assignacions. A lesquema distribut, cadascuna de les localitats ha de generar una hora dentrada nica en tot el sistema. Una forma daconseguir-lo s utilitzar un comptador lgic o el rellotge local i concatenar aquest comptador amb lidentificador de la prpia localitat, de forma anloga a com s fa amb la generaci de noms nics. Tanmateix, aqu lordre de concatenaci s important i lidentificador de la localitat ha de posar-se en la posici menys significativa per tal de garantir que les hores dentrada globals que es generin en una localitat no siguin sempre ms grans que les generades per altres. Poden produir-se problemes si una localitat genera hores dentrada locals amb ms freqncia que en altres, ja que, el comptador lgic daquesta localitat ser ms gran que les altres. Per tal que les hores dentrada locals es generin de forma equilibrada en tot el sistema existeix un mecanisme que consisteix en definir un rellotge lgic dintre de cada localitat, que sencarregar de generar una hora dentrada local nica, per que no incrementar sempre el seu valor a intervals fixes de temps ni d1 en 1, sin que el rellotge lgic simplementar per mig dun comptador que sincrementa en 1 per cada transacci generada en aquest node, per tamb cada vegada que una transacci Tj amb una hora dentrada <tj> visiti el node N, que compleixi que <tj> sigui ms gran que lltim valor subministrat pel rellotge daquest node en el moment <tj> llavors, el valor que prendr el rellotge ser tj + 1. Exemple: si un node t una referncia 123.Node1 de lltima entrada generada pel seu rellotge, en la segent transacci local el rellotge sincrementar en 1 i generar lentrada 124.Node1. Per si una subrtransacci dun altre node amb hora dentrada 150.Node6 inicia la seva execuci en el primer node, el rellotge lgic daquest prendr el valor 151.Node1, per tal dequiparar el seu comptador al daltres nodes. A ligual que passa en el cas centralitzat, el principal inconvenient dels algorisme dordenaci de transaccions per hores dentrada s que els conflictes entre transaccions es resolen per mig de retrocessos <avortar T>, en comptes desperes. En el cas distribut es provoquen multitud de retrocessos en cascada durant lexecuci duna transacci. Per eliminar aquest inconvenient, poden retardar-se les diverses operacions de lectura i escriptura fins un moment en qu es pugui garantir la seva execuci sense provocar que savorti la transacci complerta. En concret, es podria combinar lesquema dhores dentrada bsic amb el protocol de comproms de dues fases, obtenint un protocol que garanteixi la seriabilitat i labsncia de freqents retrocessos en cascada. El procs seria daquesta manera: Sigui T una transacci amb hora ti que sollicita una operaci de lectura READ(Ti, a); llavors Ti ha de retardar-se si existeix una transacci Tj amb hora tj que vulgui executar una operaci descriptura WRITE(Tj, a), per encara no lha feta i es verifica que tj < ti. De forma similar, si Ti sollicita una operaci WRITE(Ti, a) aquesta ha de retardar-se si existeix una transacci Tj que vulgui executar READ(Tj, a) i que compleixi, igualment, que tj < ti. Per tal de poder gestionar les esperes, sexigeix que cada localitat mantingui una cua de lectura i escriptura formada per totes les sollicituds READ i WRITE que shan dexecutar en aquesta localitat i que es necessitin retardar per conservar la serialitzaci sense retrocessos en cascada. Protocols de Bloqueig

64

Els protocols de bloqueig son lalternativa a lordenaci per hores dentrada i es basen en la petici, per part de transaccions de bloquejar un cert tom per a la realitzaci duna operaci sobre ell. Veurem diferents esquemes que es poden utilitzar segons com estigui dissenyat el sistema. Esquema sense rpliques Cada localitat mant un gestor de bloqueig amb la funci dadministrar sollicituds de bloqueig i desbloqueig per les dades emmagatzemades en aquella localitat. Quan una transacci generada en el node Nj desitja bloquejar un tom en el node Ni, enviar un missatge de petici de bloqueig al gestor de bloquejos dNi. Si ltom ja es troba bloquejat de forma incompatible amb la transacci, es retarda. Una vegada que el gestor de bloquejos determini que s possible atendre la sollicitud de bloqueig, enviar un missatge a Nj concedint el bloqueig. Linconvenient daquest esquema s que necessita dos missatges. Enfocament de coordinador nic Aquest esquema permet el manteniment de rpliques. El sistema mant un nic gestor de bloqueig en una localitzaci escollida per tal fi. Totes les sollicituds de bloqueig i desbloqueig es fan a aquest node. El gestor rep un missatge demanant el bloqueig i quan pot atendre la sollicitud envia un missatge de resposta. Avantatges: - Senzillesa dimplementaci - Senzillesa en la gesti dels bloquejos Inconvenients: - El gestor pot convertir-se en un coll dampolla - Vulnerabilitat en el cas que el node del gestor quedi fora de servei Podria arribar-se a un equilibri comptant amb ms dun node gestor, que evitaria els inconvenients per que complicaria les sollicituds de bloqueig. Protocol de Majoria El sistema mant un gestor en cada localitat que administra els bloquejos en les dades emmagatzemades en la seva localitat. Quan una transacci desitja bloquejar una dada a que es repeteix en n localitats diferents, ha denviar una sollicitud de bloqueig a ms de la meitat de les n localitats en les que existeix cpia da. Cadasc dels gestors de bloquejos determina si pot atendre la sollicitud (en all qu a ell respecta) . La transacci no operar fins que satenguin les peticions de bloqueig en ms de la meitat de les cpies da. Aquest esquema t lavantatge de que les dades repetides es gestionen de forma descentralitzada. Per t alguns inconvenients: - Realitzaci complicada - Existeix la possibilitat de bloqueig total o abraada mortal Protocol Preferencial Aquest protocol es basa en un model similar al protocol de majoria amb la diferncia que es dona un tractament preferencial a les sollicituds de bloqueig compartit (lectures)

65

sobre els bloquejos exclusius (escriptures). El sistema mant un gestor de bloquejos en cadascuna de les localitats. Quan una transacci necessita bloquejar la dada a per lectura fa la sollicitud a qualsevol localitat que contingui una cpia.. Quan una transacci necessita bloquejar la dada a per actualitzar-la ha de sollicitar-ho als gestors de totes les localitats on existeixi una cpia. El sistema t lavantatge de que les operacions de lectura consumeixen menys temps extra que en el protocol de majoria. Tanmateix t linconvenient de que les operacions descriptura necessiten temps extra. I, al igual, que en el protocol de majoria, s ms complexa la gesti de bloquejos. Protocol de cpia primria Quan tenim repetici de dades s possible escollir una de les cpies com a cpia primria, que residir en una localitat que direm localitat primria daquella dada. Quan una transacci necessita bloquejar una dada, ho sollicita a la localitat primria daquella dada. Si laccs s per lectura, ser suficient amb accedir a aquesta localitat, per si laccs s per escriptura llavors, sactualitzaran en cascada posteriorment totes les cpies existents per mantenir la integritat del sistema. Aquesta actualitzaci en cascada s responsabilitat del sistema i no retarda laccs per escriptura. Podem veure que amb aquest protocol s possible manegar el control de concurrncia de dades repetides de manera molt similar a com es maneguen les no repetides, a part de que la implementaci daquest esquema s molt senzilla. T linconvenient de qu si la localitat primria duna dada queda fora de servei, no es podria accedir a aquella dada, encara que existeixin altres localitats accessibles que en tinguessin una cpia.

66

4. Control i Gesti dun SGBD Corporatiu

Control i Gesti dun SGBD Funcions de l'Administrador o DBA: Installaci i actualitzaci del programari d'Oracle (servidor i aplicacions). Canviar claus inicials de les 2 comptes DBA que Oracle crea automticament en crear una BD: SYS / CHANGE_ON_INSTALL: Totes les taules i vistes del diccionari de dades pertanyen a l'esquema de SYS, i ning hauria de modificar-les. Tampoc s'han de crear noves taules de la BD en els comptes del DBA. SYSTEM / MANAGER: Crea noves taules i vistes amb informaci administrativa. Avaluaci del maquinari: Avaluar discos, memria ... assignar espais d'emmagatzematge i planificar requeriments futurs. Planificaci dels parmetres de creaci de la BD. Creaci de la BD: Estructures d'emmagatzematge (tablespaces. ..). Implementaci del disseny de la BD: Objectes (taules, vistes ...) i restriccions. Modificar l'estructura de la BD quan sigui necessari. Obertura i tancament de la BD. Gesti d'usuaris i Sistemes de seguretat: Permisos i Rols. Auditoria: Controlar i monitoritzar l'accs a la BD. Cpies de seguretat (backup) i les seves recuperacions (recovery). Afinament de la BD (optimitzar el seu rendiment).

Utilitats dAdministraci SQL * Loader: S'usa per carregar dades des de fitxers del SO a taules de la base de dades. o Pot usar-se per usuaris i administradors. o Permet especificar el format d'entrada de les dades. Export i Import: Permeten moure dades entre diferents BD Oracle. o Export guarda les dades en fitxers, i Import llegeix aquests fitxers i carrega els dades en les taules: Es poden utilitzar com a mitjans per backup. o Pot ser entre versions d'Oracle de diferents SO o Veure les Versions dels diferents productes Oracle (nucli, PL / SQL ...): o Es pot fer consultant la vista del diccionari de dades anomenada: PRODUCT_COMPONENT_VERSION. o Hi ha Dos Privilegis Importants per a l'Administraci (no sn rols): SYSOPER: Pot fer gaireb totes les tasques d'administraci, excepte concedir l'administraci a altres, crear una BD i poc ms. SYSDBA: Cont tots els privilegis del sistema WITH ADMIN OPTION (incloent SYSOPER) i permet utilitzar CREATE DATABASE. Es concedeixen normalment: GRANT SYSDBA TO scott; I es revoquen de similar manera: REVOKE SYSDBA FROM scott; Usuari es pot connectar amb: CONNECT scott / tiger ES SYSDBA 67

o Es connecta a l'esquema per defecte (PUBLIC i SYS respectivament), i no a l'esquema associat a l'usuari, de manera que aquest no podr veure les seves taules sense qualificar-les amb el seu nom d'usuari. Creaci de rols La creaci de rols permet assignar un grup de permisos a un usuari, i poder modificar aquest grup de permisos sense haver d'anar modificant tots els usuaris. La seva sintaxi s: CREATE ROLE nom_rol {[NOT IDENTIFIED | IDENTIFIED [BY clau | externally]]}; Una vegada que el rol ha estat creat ser necessari afegir permisos a travs d'instrucci GRANT (s'explica en privilegis del sistema). Tipus de rols en un usuari CONNECT Tots els permisos necessaris per iniciar sessi en Oracle. RESOURCE Tots els permisos necessaris per tenir recursos per a la creaci d'objectes. D BA : Tots els permisos per a un administrador de bases de dades (DBA). EXP_FULL_DATABASE Permisos per poder exportar tota la base de dades. IMP_FULL_DATABASE Permisos per poder importar tota la base de dades. Un usuari bsic ha de tenir almenys dos permisos: CONNECT RESOURCE

68

Components dun SGBD Motor del SGBD Accepta les peticions lgiques de diversos altres subsistemes de DBMS, els converteix en el seu equivalent fsic, i de fet accedeix a la base de dades i diccionari de dades que existeixen en un dispositiu d'emmagatzematge. Subsistema de Definici de Dades Ajuda l'usuari a crear i mantenir el diccionari de dades i definir l'estructura dels arxius en una base de dades. Subsistema de manipulaci de dades Ajuda l'usuari a afegir, canviar i esborrar informaci en una base de dades i consulta per obtenir informaci valuosa. Eines de programari en el subsistema de manipulaci de dades sn sovint la principal interfcie entre l'usuari i la informaci continguda en una base de dades. Permet que l'usuari especifiqui els seus requeriments d'informaci lgica. Subsistema de generador d'aplicacions Cont facilitats per ajudar els usuaris desenvolupar aplicacions de processament intensiu de transaccions. En general, requereix que l'usuari realitzi una srie detallada de les tasques per processar una transacci. Facilita ls de pantalles d'entrada de dades, llenguatges de programaci i les interfcies. Subsistema d'Administraci de dades Ajuda als usuaris a gestionar l'entorn de base de dades global perqu proporcioni serveis de backup i recuperaci, gesti de gesti de la seguretat, optimitzaci de consultes i control de concurrncia

69

Planificaci de tasques. Oracle Jobs Aqu mostrarem com Oracle gestiona les tasques planificades (Oracle Jobs) i quins parmetres i procesos afecten a aquesta planificaci i tamb la manera de crear-los fcilment a travs de TOAD. La base de dades ORACLE ofereix una cua per planificar algunes operacions que es fan rutinries en una base de dades ORACLE. La funcionalitat dels Jobs de oracle s semblant al cron de UNIX en el qual es pot planificar una tasca a una determinada hora i amb una periodicitat concreta. La diferncia notable que podrem tenir entre el cron de UNIX i el job de oracle s bvia. El job d'oracle es programa dins de la base de dades per tant si la base de dades no est funcionant, el job no s'executar La planificaci (en Oracle9i) es porta a terme a travs del paquet DBMS_JOB. Donada la diferncia anotada anteriorment entre cron i job podem dir que la utilitzaci de jobs seria convenient realitzar-la quan la tasca que es realitzi afecti la base de dades, que s la que ha d'estar funcionat. Per tasques del sistema en aquests casos seria ms propi utilitzar el cron o "gestor" de tasques programades que tingui el sistema operatiu. ORACLE iniciar un procs coordinador d'aquesta cua de tasques coordinador cua de treballs (CJQ0) per gestionar la planificaci dels jobs. Parmetres en init.ora / spfile.ora Per tal que qualsevol Job de oracle es pugui executar correctament hem de tenir en compte el parmetre job_queue_processes el qual ens indica el nombre de cues que gestionaran els nostres jobs. Si aquest parmetre est a zero, per molts Jobs que programem a la nostra base de dades, no s'executaran. En aquest cas no sexecutaran els nostres Jobs SQL> show parameter job_queue_processes NAME TYPE VALUE --------------------------------------job_queue_processes integer 0 En aquest cas disposem duna cua que gestionar tots els nostres Jobs. SQL> show parameter job_queue_processes NAME TYPE VALUE --------------------------------------job_queue_processes integer 1 Aquest parmetre ha de ser ms gran que el nombre de jobs que es desitja executar de forma simultnia. El mxim el posa Oracle en 1000. Una de les formes de canviar aquest parmetre s llanant la segent sentncia : ALTER SYSTEM SET job_queue_processes = numero_colas Perqu aquesta operaci tingui efecte s'ha de reiniciar la base de dades ja que s un parmetre esttic.

70

Vistes per veure els jobs de la base de dades Aquestes son les vistes a travs de les quals es poden veure els jobs que estan planificats a la base de dades. DBA_JOBS: Mostra la informaci de tots els jobs de la base de dades. ALL_JOBS: Mostra la mateixa informaci que dba_jobs per noms els jobs als quals pot accedir l'usuari actual amb el qual s'est realitzant la consulta. USER_JOBS: Mostra la mateixa informaci que dba_jobs per noms amb els jobs del qual s propietari l'usuari amb el qual es realitza la consulta. DBA_JOBS_RUNNING: Aquesta vista cont la informaci de tots els jobs que actualment estan corrent a la base de dades. Gesti de jobs amb TOAD Mitjanant el client TOAD s molt senzill gestionar els Jobs dOracle, tant la seva creaci com la seva modificaci i planificaci. En la Pestanya Jobs podem gestionar aquestes tasques a travs duna senzilla interfcie.

Quan seleccionem el job que volem modificar s'activen els altres botons per gestionar aquests jobs. La primera icona indica la "creaci d'un nou Job". La segona icona indica la "modificaci del Job seleccionat". La tercera icona que no est ressaltada indicaria la posada en marxa d'aquest Job ja que significaria que estaria parat. La quarta icona seria per aturar l'execuci d'aquest job. La cinquena icona seria per executar la tasca en aquest precs instant. I l'ltima icona seria per la qual el job seleccionat.

71

A continuaci es mostra la pantalla que TOAD utilitzaria per crear i modificar aquests Jobs.

Com podem veure s tan senzill com indicar el moment en qu volem que s'executi per primera vegada (At this time), la periodicitat (Interval) amb la qual volem que s'executi i el codi que volem que s'executi. (What to execute) NOTA: Oracle 10g modifica alguns conceptes sobre els Jobs.

72

Optimitzaci de Bases de Dades La gran part dels problemes de rendiment son resultat del disseny del sistema. Les accions a prendre per crear una BD son: Planificaci Implementaci Supervisi Optimitzaci

Anem a veure diferents aspectes per optimitzar el rendiment de la BD Optimitzaci del disseny daplicacions Disseny efectiu de taules s desitjable que les taules estiguin normalitzades per, donats els requisits dusuari, pot resultar necessari desnormalitzar (per exemple, si una consulta molt freqent implica moltes columnes fent una combinaci entre varies taules) Distribuci dels requisits del processador Un factor que pot limitar el rendiment de la BD pot ser la disponibilitat de recursos de la CPU. Hi ha varies opcions per gestionar els recursos disponibles: La crrega de treball del processador ha de planificar-se, aix les consultes de llarga durada poden programar-se per a les hores de menor intensitat de treball i amb prioritat normal, en comptes de prioritat reduda, aix evitarem conflictes de bloquejos, anullacions u dutilitzaci del processador. Traslladar fsicament la necessitat de processament dun servidor a un altre distribuci. Utilitzar la tecnologia Real Application Cluster per a distribuir els requisits daccs a una mateixa BD entre diferents instncies. Utilitzar lAdministrador de recursos de BD per a establir plans dassignaci de recursos i grups de consumidors de recursos. Utilitzar lopci de consulta en parallel PQO (Parallel Query Option) per tal de distribuir els requisits de processament dinstruccions SQL al llarg de varis processadors. A ms, les aplicacions han de minimitzar el nombre de vegades que demanen dades a la BD. I restringir ls dSQL dinmic (incls en el paquet DBMS_SQL) que sempre es processa de nou encara que existeixi una consulta idntica en lrea compartida. Optimitzaci del codi SQL Sha de minimitzar la ruta de cerca que fa servir la BD per trobar les dades. En executar una consulta sense clusula WHERE, la BD requerir una exploraci complerta de la taula. Podem utilitzar ndex per accelerar les consultes.

73

s fonamental que les dades de la taula estiguin ordenades. Si els usuaris executen consultes per rangs, en tenir les dades ordenades tindrem que llegir menys blocs. Si dues taules es consulten conjuntament amb certa freqncia, llavors un cluster de taules millorar el rendiment. Els clusters emmagatzemen files de varies taules en els mateixos blocs de dades fsics, basant-se en els seus valors lgics (la clau del cluster). Optimitzaci de ls de la memria En Oracle es disposa del joc deines STATSPACK que serveix per obtenir informaci resumida dels canvis en les estadstiques de la BD durant un determinat perode de temps. Podem utilitzar-lo juntament amb consultes al diccionari de dades per identificar rees problemtiques en lassignaci de memria de la BD. La cache de buffers de blocs de dades i lrea compartida es gestionen mitjanant un algorisme LRU (Least Recent Used). Es reserva un rea predeterminada per a guardar la informaci i quan somple, les dades menys recentment usades seliminen de la memria i sescriuen a disc. La tasa dencerts s una mesura del grau dencert amb el qu la cache del buffer de dades est gestionant les peticions de dades. Tasa dencerts = (lectures lgiques lectures fsiques) / lectures lgiques Mitjanant la vista VSSQL podem veure les consultes que estan realitzant lectures fsiques i lgiques en la BD. VSSQL ens informa del nombre acumulat de lectures lgiques i fsiques que cada consulta est realitzant actualment en lrea compartida, aix com el nombre de vegades que sexecuta cada consulta. Select Buffer_Gets, Disk_Reads, Executions, Buffer_Gets / Executions E_E, SQL_Text From VSSQL Order by Disk_Reads desc Podem consultar la vista V$SESS_IO per tal de conixer la tasa dencerts de cada sessi (registra les lectures lgiques acumulades i les lectures fsiques realitzades en cada sessi dusuari). Select SESS.Username, SESS_IO.Block_Gets, SESS_IO.Consistent_Gets, SESS_IO.Physical_Reads, Round (100 * (SESS_IO.Consistent_Gets + SESS_IO.Block_Gets SESS_IO.Physical_Reads) / (decode (SESS_IO.Consistent_Gets, 0, 1, SESS_IO..Consistent_Gets + SESS_IO.Block_Gets)),2) session_hit_ratio From V$SESS_IO sess_io, V$SESSION sess Where SESS.Sid = SESS_io.Sid and SESS.Username is not null Order by SESS.Username;

74

Podem manipular les accions dels algoritmes LRU en la cache de buffer de blocs de dades mitjanant lopci cache. Normalment, quan sexecuta una exploraci complerta de taula, els blocs de la taula se situen en la zona de blocs menys recentment utilitzats de la llista LRU, de forma que seran els primers en ser sobrescrits. En utilitzar lopci cache, Oracle situar aquests blocs en la zona de blocs ms recentment utilitzats de la llista LRU i aix romandran ms temps en la SGA (rea global del sistema). Lopci cache pot manipular-se mitjanant create table i alter table, aix com mitjanant indicacions en les consultes. Per veure els objectes els blocs dels quals estan actualment en la cache de buffers de blocs de dades podem consultar la taula X$BH en lesquema SYS. Select Object_Name, Object_Type, count (*) Num_Buff from SYS.X$BH a, SYS.DBA_OBJECTS b where a.Obj = b.Object_Id and Owner not in (SYS, SYSTEM) group by Object_Name, Object_Type Quan les rees de memria SGA tenen la mida adient poden millorar enormement el rendiment de les consultes individuals i el de la BD en general. Especificaci de la mida de la SGA Shan despecificar valors per als arguments segents: SGA_MAX_SIZE mida mxima fins a la que pot crixer. SHARED_POOL_SIZE mida de larea compartida DB_BLOCK_SIZE mida de bloc de BD predeterminat per a la BD, tal i com shagi establert en crear la BD. DB_CACHE_SIZE sespecifica en bytes en comptes den blocs. Oracle arrodoneix la mida a unitats de 4 MB si la mida indicada per SGA_MAX_SIZE s menor que 128 MB. En cas contrari, arrodoneix a 16MB. DB_nk_CACHE_SIZE si utilitzarem mides diferents de blocs de BD dintre de la mateixa BD,hem despecificar un valor pel parmetre DB_CACHE_SIZE i almenys un valor per DB_nk_CACHE_SIZE. Exemple: SGA_MAX_SIZE = 500 M SHARED_POOL_SIZE = 80 M DB_BLOCK_SIZE = 8192 DB_CACHE_SIZE = 160 M DB_nk_CACHE_SIZE = 4 M .Mentre la BD estigui oberta podem canviar els valors dels parmetres SHARED_POOL_SIZE i DB_CACHE_SIZE mitjanant el comandament alter system.

75

Optimitzaci de lemmagatzematge de dades La manera com semmagatzemen les dades t efectes sobre el rendiment de les consultes. Si les dades estan fragmentades en varies extensions, llavors resoldre una consulta pot provocar que la BD busqui les files associades en diferents ubicacions. Quan es crea un objecte de BD sassigna un tablespace mitjanant valors determinats es crea un segment en aquest tablespace per albergar les dades associades a aquest objecte. Lespa assignat mai sallibera fins que sesborra. Un segment est format per seccions anomenades extensions, aquestes son conjunts de blocs dOracle contigus. Quan les extensions existents ja no poden albergar dades noves, el segment obtindr una altra extensi, procs que seguir fins que no hi hagi ms espai lliure disponible en els datafiles del tablespace, o fins que sarribi al nombre mxim intern dextensions per segment. Per simplificar la gesti de segment hem dutilitzar un conjunt coherent de mides dextensions. Les mides escollides han de ser mltiple de la mida del bloc dE/S del sistema operatiu i han de ser mltiples un de laltre. Per exemple: Taules petites mida dextensi 1 M Taules mitjanes mida dextensi 4 M Taules grans mida dextensi 16 M Avaluaci de ls dndex Podem avaluar si un ndex sest utilitzant, en cas contrari podem esborrar-lo per estalviar espai. La supervisi dels ndex sactiva i desactiva en el nivell del sistema ha de fer-se quan lactivitat de la BD sigui mnima o en iniciar-la. Sha dutilitzar ndex per ndex. Per activar: alter index EMPLOYEE_IDX monitoring usage Per desactivar: alter index EMPLOYEE_IDX nomonitoring usage Per veure els resultats poden consultar la vista V$OBJECT_USAGE, que mostra informaci sobre els noms de lndex, de la taula, si est activa la supervisi, si sestan utilitzant els ndex i les hores a les que es va activar i desactivar la supervisi. Defragmentaci dextensions lliures Quan sesborra un segment, les seves extensions queden lliures (no estan assignades) per no sempre es combinen amb altres extensions lliures contiges. El procs en segon pla SMON agrupa peridicament extensions lliures contiges si el valor predeterminat pctincrease per espai de taules s diferent de zero. Si aquest parmetre es zero, llavors no hi haur agrupament peridic. Amb lopci coalesce del comandament alter tablespace podem fer que les extensions lliures sagrupin independentment del valor del parmetre pctincrease. No forar lagrupament dextensions lliures afecta a lassignaci despai dintre del tablespace. Per activar el procs SMON, hem de configurar el valor predeterminat de pctincrease pel tablespace a un valor diferent de zero. alter tablespace DEMONDX default storage (pctincrease 1); 76

Els valors baixos de pctincrease reflecteixen el creixement lineal normal del nombre de files de la BD. Per agrupar manualment les extensions lliures del tablespace utilitzarem lopci coalesce alter tablespace DEMONDX coalesce; Es produir un mxim de 8 reagrupaments. Si hi ha moltes extensions lliures localitzades entre extensions de dades, llavors shaur de crear de nou el tablespace. Reducci del trnsit de xarxa A mesura que les BD i les aplicacions que hi operen es van distribuint, la xarxa que suporta els servidors pot convertir-se en un coll dampolla en el procs de lliurament de dades a lusuari. Reduir el trnsit de xarxa disminuir tamb la dependncia de la xarxa. Duplicaci de dades Per reduir la quantitat de dades que senvien a travs de la xarxa shan de tenir en comte diferents opcions de duplicaci de dades. Utilitzaci de crides a procediments remots Quan sutilitzen procediments en un entorn de BD distribut hi ha dos opcions: Crear un procediment local que faci referncia a taules remotes. Crear un procediment remot que sigui cridat per una aplicaci local.

La ubicaci adient del procediment depn de la distribuci de les dades i del node en que aquestes es van a utilitzar. Sha de posar nfasi en minimitzar la quantitat de dades que shan denviar a travs de la xarxa per resoldre la petici de dades. El procediment ha de residir dintre de la BD que cont la major part de les dades que sutilitzaran durant les operacions del procediment. En un principi tenim:

create procedure mi_proc (n_emp IN NUMBER, raise IN NUMBER) as begin update empleat@hr_link set sou = sou + raise where num_emp = n_emp; end;

77

La segona opci ser:

Utilitzan el segon model eliminem lenlla de la clusula update i fem la crida: create procedure mi_proc (n_emp IN NUMBER, raise IN NUMBER) as begin update empleat set sou = sou + raise where num_emp = n_emp; end; execute mi_proc@hr_link(1234, 2000); El benefici que sobt en executar un procediment remot s que tot el procs del procediment es realitza en la BD en la que resideixen les dades. La crida al procediment minimitza el trnsit de xarxa necessari per completar el procs. Fitxers Log Un fitxer de registre, LOG o bitcola, emmagatzema informaci sobre els nombrosos esdeveniments produts en un SGBD, tant en la seva instal laci, com en la seva explotaci i administraci. Aix, aquests fitxers sn essencials per conixer el comportament d'un SGBD i ajuden l'administrador a esbrinar les causes de possibles malfuncionaments I a auditar totes les operacions que els clients realitzen. Qualsevol fitxer de log suposa un apunt d'informaci per part del programa que s'estigui executant. Generalment es poden distingir tres tipus d'anotacions: Informaci d'esdeveniments, alertes i altres accions que es duguin a terme sobre o des de la instncia o bases de dades que la componen. Estat general dels parmetres de la instncia o les seves bases de dades, aix com consells d'actuaci en cas que algun sobrepassi o no un determinat llindar de funcionament programat Transaccions i operacions que afectin a les dades o l'estructura dels mateixos, s a dir, sentncies DML i DDL respectivament Fitxers log en Oracle

78

Els fitxers logs ms interessants en Oracle sn els segents Log d'Alerta (Alert Log) s un fitxer de text que registra errors i successos de la gesti de la base de dades cronolgicament Log de processos en backgroung Un altre fitxer de text que registra els errors produts pels processos en background d'Oracle (Simn, PMON, DBWR, etc.) Fitxers LOG d'usuaris (USER TRACE) De vegades s necessari rastrejar (traci) l'activitat de determinats usuaris. Quan aquests rastrejos s'activen es creen fitxers de text amb l'activitat generada per aquests usuaris. Activitat 1: Consulta la ubicaci dels arxius de LOG del teu instncia Oracle mitjanant les segents consultes: select va1ue from v $ parameter where name = 'background_dump_dest'; s = lect value from v $ parameter where name = 'user_dump_dest'; A ms d'aquests fitxers de text, Oracle disposa d'uns fitxers binaris anomenats redo log que emmagatzemen un histric de tots els canvis a la base de dades .. Si: una BBDD es corromp, l'SGBD aplica totes les transaccions pendents, usant informaci existent en els redo logs. Aquests redo logs tamb es poden emmagatzemar (A: boc redologs o arxivi logs) per implementar cpies de seguretat en calent i bases de dades en standby. Activitat 2: Activa el mode arxivi lag en la instncia del teu BBDD Oracle mitjanant el segent procediment 1. L'arxiu init $ ORACLE_SID.ora ha de contenir les segents lnies log_archive_start = true log_archive_desLl = "location = / archivelog / bbdd reopen = 5" log_Archive_format = arch_% t_% s.arc 2 A continuaci, des sqlplus, per a la base de dades i arrenca en mode mount shutdown immediate; startup nomount 3. Canvia a manera archivelog, obre la base de dades i inicia el arxivat: Alter database archivelog Alter database open; Alter system archive log start;

79