DBA | Isolamento de transacções

As normas ANSI SQL determinam os seguintes três tipos de isolamento transaccional nos sistemas de gestão de bases de dados:

  1. Dirty Read. A transacção T1 modifica um facto. Outra transacção T2 lê esse mesmo facto antes que T1 faça commit ou rollback. Se T1 desistir da transacção (rollback) então T2 leu um facto que nunca foi confirmado e, como tal, nunca existiu.
  2. Non-Repeatable Reads. A transacção T1 lê um facto. Outra transacção T2 modifica ou apaga esse facto e faz commit. Se T1 renovar o pedido desse facto descobre que ele foi modificado ou que já não existe.
  3. Phantom. A transacção T1 lê um conjunto de factos de acordo com uma determinada condição. A transacção T2 insere novos factos, que satisfazem a condição de T1, e confirma-os na base de dados. Se T1 voltar a fazer a mesma leitura-condição obtém um conjunto de factos distintos dos da leitura inicial.

DBA | Gestão de Transacções

O papel da gestão de transacções é o de assegurar que as transacções são gravadas correctamente na base de dados. O gestor de transacções é o componente do SGBDR que processa esses movimentos de dados. Uma transacção é um conjunto de acções ou movimentos de dados considerados de modo a que sejam todos gravados na base de dados ou rejeitados na sua totalidade. Uma transacção é uma unidade atómica de trabalho em que todos os seus elementos têm que ser processados, caso contrário a base de dados ficará inconsistente. O pagamento de uma propina escolar, por exemplo, é uma transacção que se subdivide, em grandes linhas, em dois elementos: a actualização do saldo da conta de propinas da escola, e a actualização dos montantes pagos por esse aluno. A base de dados ficaria inconsistente se se alterasse um único desses elementos: ou se faz tudo ou não se faz nada.

O princípio da atomicidade transaccional exige que todo o conteúdo transaccional seja processado segundo a regra do “tudo-ou-nada”, e que cada conjunto de transacções seja transmissível em série / realizável (serializable). Quando uma transacção é interrompida antes do seu termo o gestor de transacções têm que repor a base de dados no estado em que se encontrava antes do início da operação, desfazendo todas as acções entretanto efectuadas. As transacções, por uma questão de eficiência e de eficácia, não devem durar mais do que o necessário de modo a assegurar a integridade do sistema. No caso da liquidação de uma propina o pagamento do aluno e o crédito na contabilidade da escola é a unidade mínima de trabalho necessária para manter as contas em dia.

ODS vs. Data Warehousing

O ODS (Operational Data Store) é um elemento fundamental do data warehouse empresarial proposto por Bill Inmon, para muitos considerado o pai do Data Warehousing. O ODS é uma estrutura de dados normalizada, uma base de dados normal, construída com todas as regras de integridade inerentes ao modelo de dados relacional, e que serve de transição entre o sistema transaccional e os data marts segundo o pensamento de Inmon. 
Na óptica do modelo dimensional – que é a perspectiva que sigo – o ODS é uma estrutura redundante dado que obriga a que seja desenvolvida de raiz mais uma base de dados completa (diferente do sistema transaccional e do DW) cuja única e exclusiva função é a de abastecer de dados o DW. Então ficaríamos com duas bases de dados transaccionais com a mesma função, e cuja duplicação poderia dar azo a enganos na transição para o DW. 
Em questões de segurança da informação o ODS não tem nenhuma vantagem adicional pois como o seu conteúdo é reescrito diariamente – ou em que período seja – a partir dos dados transaccionais, qualquer erro – intencional ou por incompetência – no processo de carregamento do ODS resultará na sua corrupção. 
De qualquer modo, importa ainda salientar que a informação contida no data warehouse é não-volátil, ou seja, só em casos de erro (por exemplo: nomes incorrectos de pessoas) é que há lugar a modificação dos dados armazenados. 
A única forma de corromper um DW é utilizar uma metodologia errada de carregamento: apagar tudo o que já está no DW e carregar tudo de novo em cada momento de refrescamento, o denominado método da “força bruta”. Ora, como esse método não é casuístico e só se deve utilizar uma única vez (no carregamento inicial do DW) este problema não se coloca. É nessa primeira vez que deverão ser desencadeados mecanismos de auditoria que constatarão, ou não, da conformidade da informação do DW com os objectivos delineados no projecto da sua construção. A partir dai apenas é acrescentada informação ou corrigidos erros. 
O próprio data warehouse devido à sua estrutura em forma de estrela tem as regras de integridade necessárias e suficientes para impedir que sejam carregados dados fora de contexto. 
Em tudo o mais a segurança física do DW tem que ser assegurada de acordo com as políticas de Backup e Recovery em vigor no local de instalação do DW. Devido à importância funcional do DW na empresa (órgãos intermédios e superiores de decisão) é de muito bom senso que essas políticas de seguranças sejam devidamente certificadas.

Máquina do tempo…em Oracle

Acontece por vezes que alguns dados podem inadvertidamente ser apagados ou modificados e não há tempo para os restaurar a partir de um dispositivo de backup. O Oracle possui uma tecnologia bastante útil denominada Flashback que permite que se façam queries “a um passado recente”. O “quanto” é permitido recuar depende do espaço disponível em UNDO.
Suponha-se que na última hora se apagou qualquer linha da tabela Curso e que agora é imperioso saber que dados foram removidos: 

SELECT * FROM  “Curso” AS OF TIMESTAMP SYSDATE-1/24;

Através desta característica é possível fazer o seguinte:

  • Pesquisar dados que já não existem (“do passado”); 
  • Analisar os metadados de modo a evidenciar o historial de alterações à base de dados; 
  • Recuperar tabelas ou linhas para um determinado ponto do tempo; 
  • Fazer rollback de transacções enquanto a base de dados de produção continua activa; 
  • Fazer a gestão de transacções.