 Revista Do Linux

 Tipo de Pesquisa

 [ No Site ...................
 ]

 ______________ OK

 SEES

 Anunciantes

 Publicidade

 Humor

 Dicas e Truques

 Notcias On-Line

 Comunidade

 Colaborao

 Contato

 Frum

 Artigos On-Line

 Enquetes

 Edies Anteriores

 IFRAME : Texto 45 _arquivos / B1329161 ; sz = 468x60 ; ord = [ timestamp ].htm

 Click Here Click Here

 / Artigos On-Line / ARTIGOS / BANCO DE DADOS / 984661649.html

 Seo Bancos de Dados

 AVALIAO DO MECANISMO DE RECOVERY DO SGBD INTERBASE EM AMBIENTE LINUX

 Taisy Silva Weber

 Paulo Ricardo Rodegheri

 Neste artigo , avaliamos o mecanismo de tolerncia a falhas ( recovery ) do

 Sistema Gerenciador de Banco de Dados Interbase .
 Os experimentos sero rodados

 em computadores pessoais , em ambiente Linux , com o banco de dados centralizado

 Interbase .
 O levantamento do modelo de falhas adequado para avaliar o

 comportamento sob falha do banco de dados e a determinao da forma de conduo

 do experimento de validao serviro de base para desenvolver uma ferramenta de

 injeo de falhas especfica para mecanismos de recovery em bancos de dados

 centralizados .

 Introduo

 Aplicaes de bancos de dados tm , tradicionalmente , sido um campo com

 necessidades de tolerncia a falhas , principalmente visando integridade de

 dados e disponibilidade .
 Aplicaes que empregam Sistemas Gerenciadores de

 Bancos de Dados ( SGBDs ) requerem que a integridade dos dados seja preservada

 durante a operao normal , bem como aps a recuperao ocasionada por uma

 falha .
 Preservar a integridade e a disponibilidade implica em medidas extras de

 segurana na forma de verificao de consistncia e redundncia .
 Falhas que

 afetam o hardware e os meios de armazenamento so inevitveis .
 Em caso de

 falhas , informaes vitais podem ser perdidas .
 Desta forma , uma parte essencial

 no sistema de banco de dados  um esquema de recuperao responsvel pela

 deteco de erros e pela restaurao do banco de dados para um estado

 consistente , que existia antes da ocorrncia da falha .
 Quando baseados em

 arquivos de log , estes esquemas de recuperao tendem a ser demorados .

 O trabalho se prope a avaliar o mecanismo de recovery do SGBD atravs de

 experimentos que provoquem , de forma deliberada , a indisponibilidade do sistema

 quando o SGBD estiver processando um conjunto de transaes .
 Os experimentos

 provocam o colapso do banco de dados atravs de duas tcnicas :

 * eliminao ( comando kill ) do processo pai e conseqentemente dos processos

 filhos que estiverem atualizando dados no banco de dados ,

 * reset geral no equipamento quando um processo estava processando transaes

 que atualizam o banco de dados .

 Falhas transientes e permanentes de hardware podem ser simuladas por programas

 chamados injetores de falhas .
 Para este trabalho , a primeira tcnica

 corresponde a uma injeo de falhas por software , simples mas eficiente , dado o

 modelo de falhas do Interbase .
 A segunda tcnica corresponde a uma injeo de

 falhas de hardware , conduzida manualmente .
 Como resultados da avaliao

 descrita neste trabalho , so esperados : um modelo de falhas mais genrico ,

 adequado para aplicao de injetores de falhas em um nmero maior de SGBDs , uma

 metodologia para injetar falhas em SGBDs centralizados e a determinao de como

 o comportamento sob falhas deve ser analisado .

 Modelo de falhas e injeo de falhas

 Para determinar como o sistema deve recuperar-se ,  necessrio identificar as

 falhas mais comuns que afetam os SGBDs .
 Com base no modelo de falhas ,

 projetistas de SGBDs implementam algoritmos para assegurar a consistncia do

 banco de dados e a atomicidade das transaes .
 Estes algoritmos so compostos

 de duas partes : 1 ) aes tomadas durante o processamento normal da transao

 com o objetivo de assegurar que existam informaes suficientes para a

 recuperao ; 2 ) aes tomadas em seguida  deteco , para assegurar a

 consistncia do banco de dados e a atomicidade da transao .

 Para verificar se o SGBD trata adequadamente a recuperao das falhas que se

 prope tratar , pode-se partir para a coleta de dados em campo , esperando pela

 ocorrncia real das falhas durante um longo perodo de tempo , ou simular a

 ocorrncia de falhas atravs de tcnicas de injeo de falhas de hardware por

 software .
 A segunda tcnica  ideal para validar o mecanismo de recuperao

 antes da aplicao do SGBD em sistemas crticos .

 Um injetor de falhas ideal para sistemas centralizados deve permitir a injeo

 de falhas de transao , de sistema e de mdia .
 Os experimentos aqui relatados

 se restringem  falhas de crash .
 Como no existe a disponibilidade do cdigo do

 SGBD a injeo de falhas  realizada atravs dos recursos do sistema

 operacional , eliminando processos , e outros recursos disponveis como reset

 geral do sistema .

 Escopo de uma transao

 Uma transao  uma unidade de programa que faz o acesso e possivelmente

 atualiza vrios itens de dados .
 Requer-se que as transaes no violem qualquer

 restrio de consistncia do banco de dados .
 Isto  , se era consistente quando

 uma transao iniciou , o banco de dados deve ser consistente quando a transao

 terminar com sucesso .
 Entretanto , durante a execuo de uma transao , pode ser

 necessrio temporariamente permitir a inconsistncia .
 Essa inconsistncia

 temporria , ainda que necessria , pode levar a dificuldades se ocorrer uma

 falha .
 Quando uma transao  finalizada com sucesso , todas as mudanas feitas

 por ela so tornadas estveis no banco de dados ( committed ) .
 Quando uma

 transao  cancelada , todas as mudanas feitas por ela devem ser desfeitas

 ( rolled-back ) .

 Arquivo de log

 A estrutura mais largamente usada para registrar modificaes no banco de dados

  o log .
 Na ocorrncia de uma falha de sistema , o log permite levar o banco de

 dados estvel a um estado consistente .
 Na literatura existem vrios trabalhos

 que tratam de diferentes tipos de sistemas de log e sua aplicao .

 Plataforma experimental

 O projeto visa determinar inicialmente a aplicabilidade da tcnica de injeo

 de falhas na validao de mecanismos de recuperao em bancos de dados .

 Posteriormente , os resultados experimentais obtidos com o projeto permitiro

 criar modelos genricos aplicveis a classes de tcnicas de recuperao usadas

 por diferentes tipos de banco de dados .

 Sistema Operacional

 A plataforma de experimentao  baseada no sistema operacional Linux e no SGBD

 centralizado Interbase .
 No primeiro experimento , provoca-se a indisponibilidade

 do banco de dados atravs da eliminao ( kill ) de um processo pai , que possui

 um processo filho , que atualiza dados no banco de dados , e ser

 conseqentemente tambm eliminado .
 O segundo experimento provoca a

 indisponibilidade do banco de dados atravs do reset geral do sistema , no

 momento em que um processo estiver atualizando dados do banco de dados .

 O SGBD Interbase

 O Interbase  um SGBD relacional que possui diversas caractersticas que o

 diferenciam consideravelmente de seus concorrentes .
 Tradicionais SGBDs

 comerciais ( Sybase , SQL Server , Oracle , Progress ) utilizam mecanismos de log e

 de checkpointing para obter um estado consistente aps a deteco de uma falha .

 Estes mecanismos geralmente geram um overhead de processamento e so

 potencialmente lentos .

 O Interbase no usa o conceito de log de transaes e de checkpointing .
 Ao

 invs disto , mantm informaes em TIPs ( Transaction Information Pages ) .

 A TIP  uma pgina inventrio de cada transao e contm dois bits que

 descrevem quatro possveis estados : 0 ativo , 1 committed , 2 - rolled back e 3

 limbo .
 Este ltimo estado para um commit de duas fases .
 Registros TIP tm suas

 verses anteriores ligadas  transao .
 Aps um colapso , transaes falham ,

 deixando seu estado registrado no TIP como ativo .
 Quando outra transao vier a

 ler um registro criado por uma destas transaes que falharam ( mortas ) , ela

 ignora a verso primria e l a primeira verso anterior committed .
 Quando

 outra transao procura atualizar um registro criado por uma das transaes

 mortas , ela testa o estado daquela transao atravs do bloqueio que toda

 transao trata em seu prprio identificador .
 Se o bloqueio est feito , ento a

 transao est morta .
 A transao atual reseta o estado da transao morta de

 zero para 3 , e descarta o dado por ela criada .

 No caso de uma falha de sistema , to logo o servidor  posto on-line , o

 Interbase automaticamente busca nos registros TIP por transaes uncommitted .

 Qualquer registro encontrado em um estado uncommitted  rolled back e o sistema

  imediatamente disponibilizado .
 Segundo o fornecedor , no Interbase ,

 restauraes automticas aps um colapso levam tipicamente menos de um segundo ,

 e no necessitam da interveno do administrador como na maioria dos bancos de

 dados .
 Portanto , recovery no Interbase  cooperativo e gradual e no preemptivo

 e imediato .
 Alm disto , Interbase apenas executa UNDO .

 Os experimentos

 Os experimentos objetivam avaliar o mecanismo de recovery do SGBD Interbase , 

 razo do nmero de vezes que o mecanismo de recovery foi acionado em relao s

 falhas injetadas .
 Adicionalmente , visam tambm avaliar a eficincia do

 mecanismo de deteco de falhas .
 Nas subsees a seguir so definidos : a carga

 de trabalho estipulada para o banco de dados , os procedimentos realizados em

 cada uma das tcnicas , o conjunto de instrues que manipulam o banco de dados

 e os resultados obtidos .

 A Carga de Trabalho

 Os experimentos foram realizados em tabelas que contm 60 mil , 180 mil , 240

 mil , ou 300 mil registros .
 Cada registro lgico das tabelas ocupa 78 bytes .
 A

 menor tabela tem 4,6 MB e a maior tabela tem 22,3 MB .
 As aplicaes foram

 escritas em SQL ( Structured Query Language ) .
 Foram realizadas transaes de

 insero de 60 mil registros ( insert ) , alterao de 240 mil e 300 mil registros

 ( update ) e excluso de 300 mil registros ( delete ) .

 O Processo do Experimento

 Por default , o Interbase executa escritas bufferizadas , tambm chamadas de

 escritas assncronas .
 Diferentemente de uma escrita forada ( FW = forced

 write ) , quando executa escritas bufferizadas , ele no escreve fisicamente dados

 no disco at que um evento predefinido ocorra ( quando uma certa quantidade de

 informao  coletada para uma escrita , um evento associado tenha ocorrido , ou

 um certo intervalo de tempo tenha passado ) .
 Se escritas foradas no esto

 disponveis , igualmente o Interbase executa uma escrita interna .
 Os dados podem

 no ser fisicamente escritos em disco , porque o sistema operacional utiliza

 buffers para escrita em disco .
 Se ocorrer uma falha de sistema antes da escrita

 de dados em disco , ento informaes podem ser perdidas .
 Executando-se escritas

 foradas garante-se integridade dos dados e segurana , mas perde-se desempenho ,

 isto  , operaes que envolvem modificaes de dados sero mais lentas .

 A Primeira Tcnica de Experimentao ( Eliminao do processo pai )

 A primeira tcnica consiste em eliminar ( comando kill ) um processo pai que

 contm um processo filho que estabelece atualizaes ( inseres , alteraes e

 delees ) no banco de dados .
 No total foram executados 350 experimentos ,

 descritos a seguir e acompanhados de seus resultados e cujo resumo  mostrado

 na tabela 1 .

 50 execues de um processo que inclua ( insert ) 60 registros em uma tabela que

 continha 240 mil registros sem parmetro forced write .
 O Interbase obteve

 sucesso no processo de recovery em 100 % dos casos , de maneira rpida e

 eficiente , isto  , o banco de dados era prontamente disponibilizado .

 50 execues de um processo que inclua ( insert ) 60 mil registros em uma tabela

 que continha 240 mil registros com o parmetro forced write .
 O Interbase obteve

 sucesso no processo de recovery em 100 % dos casos , de maneira rpida e

 eficiente , isto  , o banco de dados era prontamente disponibilizado .

 50 execues de um processo que alterava ( update ) um campo tipo char de 50

 bytes em 240 mil registros de uma tabela , sem o parmetro forced write .
 O

 Interbase obteve sucesso no processo de recovery em 100 % dos casos , de maneira

 rpida e eficiente , isto  , o banco de dados foi prontamente disponibilizado .

 100 execues de um processo que alterava ( update ) um campo tipo char de 50

 bytes em 300 mil registros de uma tabela , com o parmetro forced write .
 O

 Interbase obteve sucesso no processo de recovery em 99 execues ( 99 % dos

 casos ) , de maneira rpida e eficiente , isto  , o banco de dados foi prontamente

 disponibilizado.O mecanismo de deteco , neste caso , no foi eficiente , uma vez

 que nenhuma mensagem de erro foi exibida .
 A tabela travava quando acessada ,

 aps alguns segundos .
 Foi necessria a interveno do usurio ( usando o comando

 drop table ) .

 50 execues de um processo que exclua ( delete ) todos os registros de uma

 tabela que continha 300 mil registros sem o parmetro forced write .
 O Interbase

 obteve sucesso no processo de recovery em 100 % dos casos , de maneira rpida e

 eficiente , isto  , o banco de dados era prontamente disponibilizado .

 50 execues de um processo que exclua ( delete ) todos os registros de uma

 tabela que continha 300 mil registros com o parmetro forced write .
 O Interbase

 obteve sucesso no processo de recovery em 100 % dos casos , de maneira rpida e

 eficiente , isto  , o banco de dados era prontamente disponibilizado .

 OPERAO

 REALIZADA

 #

 PROCESSOS PAI ELIMINADOS ( KILL )

 #

 RECOVERY COM SUCESSO

 %

 SUCESSO

 # RECOVERY COM ERRO

 %

 ERRO

 Insert 60.000 regs - sem FW

 50

 50

 100,00 %

 0

 0,00 %

 Insert 60.000 regs - com FW

 50

 50

 100,00 %

 0

 0,00 %

 Update 240.000 regs sem FW

 50

 50

 100,00 %

 0

 0,00 %

 Update 300.000 regs com FW

 100

 99

 99,00 %

 1 ( * )

 1,00 %

 Delete 300.000 regs sem FW

 50

 50

 100,00 %

 0

 0,00 %

 Delete 300.000 regs com FW

 50

 50

 100,00 %

 0

 0,00 %

 Tabela 1 .
 Eficincia de recovery matando processo pai - ( * ) = Erro no

 detectado

 A Segunda Tcnica de Experimentao ( reset geral do sistema )

 A segunda tcnica consiste em resetar o equipamento no momento em que

 um processo estava sendo executado e estabelecia atualizaes

 ( inseres , alteraes e delees ) no banco de dados .
 No total foram

 executados 25 experimentos , descritos a seguir e acompanhados de seus

 resultados e cujo resumo  mostrado na tabela 2 .
 Os experimentos

 realizados utilizando a segunda tcnica foram em menor nmero porque o

 experimento consome uma quantidade de tempo muito maior e apresenta

 tambm um risco maior de comprometer a integridade de todo o ambiente

 de experimentao ( equipamento , sistema operacional , banco de dados ,

 procedimentos e aplicaes ) .

 12 execues de um processo que inseria ( insert ) 60 mil registros em

 uma tabela que j continha 240 mil , sem o parmetro forced write .
 O

 Interbase obteve sucesso no processo de recovery em nove execues ( 75

 % dos casos ) , de maneira rpida e eficiente , isto  , o banco de dados

 foi prontamente disponibilizado .
 Nas trs execues em que ocorreram

 erros ( 25 % dos casos ) , a tabela ficou danificada e inacessvel ( foi

 necessrio usar o comando drop table ) .
 Nas tentativas de acessar o

 banco de dados foi exibida a seguinte mensagem de erro :

 database file appear corrupt ( )

 wrong page type

 page " xxxxx " is of wrong type ( expected 7 , found 5 )

 13 execues de um processo que alterava ( update ) um campo tipo char

 de 50 bytes em 300 mil registros de uma tabela , sem o parmetro forced

 write .
 O Interbase obteve sucesso no processo de recovery em sete

 execues ( 53,8 % dos casos ) , de maneira rpida e eficiente , isto  , o

 banco de dados foi prontamente disponibilizado .
 Nas seis execues em

 que ocorreram erros ( 46,2 % dos casos ) , a tabela ficou danificada e

 inacessvel ( foi necessrio usar o comando drop table ) .
 Nas tentativas

 de acessar o banco de dados foram exibidas as seguintes mensagens de

 erros :

  Internal GDS software consistency check ( cannot find record back

 version ( 291 )) ( 3 ocorrncias )

  Internal GDS software consistency check ( wrong record length ( 183 ))

  Internal GDS software consistency check ( applied diferences will not

 fit in record ( 177 ))

  database file appear corrupt ( )

 wrong page type

 page " xxxxx " is of wrong type ( expected 5 , found 4 )

 OPERAO .

 REALIZADA

 #

 RESET NO EQUIP .

 #

 RECOVERY COM SUCESSO

 %

 SUCESSO

 #

 RECOVERY COM ERRO

 %

 ERRO

 nsert 60.000 regs - sem FW

 12

 9

 75,00 %

 3 ( * )

 25,00 %

 Update 300.000 regs sem FW

 13

 7

 53,80 %

 6 ( * )

 46,20 %

 Tabela 2 .
 Eficincia de recovery com resetgeral do sistema

 ( * ) = Houve a deteco do erro ( mensagem foi exibida ao usurio ) .

 Concluses

 A partir dos resultados obtidos pelos experimentos pode-se constatar ,

 preliminarmente , que o mecanismo de recovery do SGBD Interbase 

 bastante confivel numa determinada situao e no confivel em outra

 situao .
 O mecanismo mostrou-se bastante confivel quando foi

 utilizada a primeira tcnica , que consistia em eliminar ( comando kill )

 um processo pai que continha um processo filho que estabelecia

 atualizaes no banco de dados .
 Como mostram os dados da tabela 1 , nos

 350 experimentos realizados , em apenas um o mecanismo de recovery no

 foi eficiente , o que representa 0,29 % , sendo , portanto eficiente em

 99,71 % dos casos .
 Por outro lado , o mecanismo de recovery foi

 ineficiente quando utilizada a segunda tcnica , que consistia em

 resetar o equipamento no momento em que um processo estabelecia

 atualizaes no banco de dados .
 Como mostram os dados da tabela 2 , nos

 25 experimentos realizados , em nove o mecanismo de recovery no foi

 eficiente , o que representa 36,00 % dos casos , sendo portanto

 eficiente em apenas 64,00 % dos casos .

 Conclui-se tambm que o mecanismo de deteco de erros do SGBD

 Interbase  bastante eficiente .
 Em todas as vezes , com exceo de uma

 ( 99,73 % dos casos ) , o mecanismo de recovery conseguiu levar o banco

 de dados a um estado consistente aps um erro .
 No caso do erro , o SGBD

 no permitiu que o banco de dados incosistente fosse acessado .
 Este

 tipo de comportamento  interessante e desejvel , uma vez que um banco

 de dados que esteja em um estado inconsistente e permita acesso aos

 dados dele pode gerar informaes inconsistentes .

 Pode-se verificar tambm que , com relao ao desempenho , o mecanismo

 de recovery do Interbase mostrou-se bastante eficiente , visto que o

 tempo necessrio para disponibilizar o banco de dados ao usurio foi

 extremamente baixo ( aproximadamente um segundo ) , mesmo quando o

 conjunto de operaes e o tamanho das tabelas atualizadas eram

 grandes .
 Esta eficincia no desempenho  graas ao mecanismo utilizado

 pelo Interbase , que utiliza TIPs ao invs de arquivos de log .

 Espera-se que com os resultados preliminares at aqui obtidos e com os

 dados que sero obtidos com a tcnica de injeo de falhas atravs de

 um injetor , se possa solidificar as concluses e observaes aqui

 mostradas .

 Para saber mais

 A Comparasion of Interbase vs. SQL Server .

 http : // www.borland.com / interbase / papers - July 2000 .

 SABARATNAM , M. , TORBJORNSEN , O. , Cost of Ensuring Safety in

 Distributed Database Management Systems .
 Proceedings of the 1999

 Pacific Rim International Symposium on Dependable Computing .

 ARLAT , J. et. ali .
 Fault-injection for dependability validation : a

 methodology and some applications .
 IEEE Transactions on Software

 Engineering , v. 16 , n. 2 , Feb .
 1990 .

 CARREIRA , J. et. al. Xception : A Technique for the Experimental

 Evaluation of Dependability in Modern Computers .
 IEEE Transactions on

 Software Engeneering , v. 24 , n. 2 , Feb .
 1998 .

 BARCELOS , P.P.A. ; LEITE , O. ; WEBER , T. S. Implementao de um Injetor

 de Falhas de Comunicao .
 In : anais do VIII Simpsio de Computadores

 Tolerantes a Falhas , SCTF'99 , Unicamp-SBC , Campinas , 7-9 de julho de

 1999 .
 pp 225-239 .

 SOTOMA , IRINEU ; WEBER , TAISY S. , AFIDS - Arquitetura para Injeo de

 Falhas em Sistemas Distribudos .
 In : Anais do 15 Simpsio Brasileiro

 de Redes de Computadores - SBRC .
 UFScar - Ufscar .
 19-22 de maio de

 1997 .
 So Carlos - SP .
 P. 294-309 .

 BERNSTEIN , P. , HADZILACOS , V. , GOODMAN , N. Concurrency Control and

 Recovery in Database Systems .
 Reading , Massachusetts : Addison-Wesley ,

 , 1987 .

 [ LINK ] Salvar [ LINK ] Imprimir [ LINK ] Enviar por e-mail

 ltimas Notcias

 Declarao sobre o trmino da Revista do Linux

 KDE disponibiliza nova verso

 Lanada a verso mais rpida e usvel do KDE , a 3.2

 Incluso Digital

 MinC prepara acordo com o ITI , da Casa Civil , e cria setor de Cultura Digital

 Unicamp oferece estgios para programao em software livre

 Vagas so para alunos do terceiro ou quarto ano de engenharia da computao ,

 cincia da computao , matemtica ou anlise de sistemas com experincia em

 Linux

 Novo e-zine em portugus para usurios do Slackware

 Slackzine disponibiliza artigos tcnicos e tutoriais para fs do slack

 Prxima verso do Conectiva Linux disponvel para testes

 Atravs de download , usurios podem testar e verificar as principais novidades

 da prxima verso do programa , primeira do mundo a contar com o novo Kernel 2.6

 A Revista do Linux  editada pela Conectiva S / A

 Todos os Direitos Reservados .

 _________________________________________________________________

 Poltica de Privacidade

 Anuncie na Revista do Linux

 [ LINK ] [ LINK ]

