Um Sistema de TDM tem de garantir a captura , roteamento , transformação , entrega e verificação das transacções de dados através de ambientes heterógeneos em tempo real

O Mundo do negócio cada vez mais exige o acesso, análise, actuação sobre e verificação de transacções de dados, com cada vez maior rapidez , em tempo real , sem interrupção ou queda do sistema devido a 3 factores :
aumento exponencial dos volumes de dados, a necessidade de gerir e recolher esses dados e a necessidade de trabalhar em ambientes heterógeneos , distribuídos e inter-plataforma (heterogeneous, cross-platform and distributed environments) , de alta disponibilidade e contingência de recuperação de desastres

Sistemas optimizados de alto desempenho em interface com os sistemas de backup , restauração e disaster recovery,bem como sistemas em cluster com load balencers , como condição para a alta disponibilidade

Disaster recovery - A progressiva dependência das organizações do acesso à informação constitui um factor de risco e para a actividade das empresas a nível mundial.

Para além da definição de metodologias a adoptar em caso de catástrofe, os planos de Disaster Recovery incluem um conjunto de tecnologias que possibilitam que a empresa se mantenha em funcionamento numa situação de catástrofe.

Entre os planos de Disaster recovery mais comuns, contam-se a replicação de dados e equipamentos em centros de informática dotados de sistemas de elevada segurança ou a contratação de serviços de empresas de informática que, em caso de catástrofe, asseguram a operacionalidade dos sistemas de informação da empresa.

A instância de uma base de dados não está sempre ligada á rede numa base contínua .
Ao ser ligada novamente, a instância de uma base de dados tem de iniciar um serviço de sincronização para aquela instância da base de dados.

O serviço de sincronização então actualiza todos os dados na instância da base de dados e envia qualquer mudança de dados para as outras instâncias de bases de dados .

Transacção - Conjunto de procedimentos executados por um SGBD que é visto pelo utilizador como uma única acção.
Ex.: transferência de 500,00€ do cliente A para o cliente B. A integridade da transação depende de 4 propriedades (ACID)

Isolation - todos os dados a ser usados durante o processamento de uma transacção não pode ser usada por outra transacção até a primeira transacção estar completa

Exemplo: se duas pessoas depositam 100€ numa conta com 900€, a primeira transacção tem de adicionar 100€ a 900€, e a segunda tem de adicionar 100€ a 1,000€.

Se a segunda transacção lê os 900€ antes da primeira transacção estar completa ambas são bem sucedidas mas desaparecem 100€. A segunda transacção tem de esperar até ela sózinha estar a aceder aos dados.

Defeito ---> Ao aparecer informação errada, se não for percebida e tratada, irá gerar o que se conhece por um defeito.
O sistema simplesmente pára, ou exibe uma mensagem de erro, ou perde os dados do utilizador muitas vezes sem dar feedback. Isto é percebido no universo da interface do utilizador.

A Tolerância a Falhas visa exactamente acabar com as falhas, ou tratá-las enquanto ainda são erros.
Na Alta Disponibilidade permite que máquinas travem ou errem, desde que que exista outra máquina para assumir seu lugar.

Para que uma máquina assuma o lugar de outra, é necessário que descubra de alguma forma que a outra falhou.

Isso é feito através de testes periódicos, cujo período deve ser configurável, nos quais a máquina secundária testa não apenas se a outra está activa, mas também fornecendo respostas adequadas a requisições de serviço.

Um mecanismo de detecção a funcionar mal pode causar instabilidade no sistema. Por serem periódicos, nota-se que existe um intervalo de tempo durante o qual o sistema pode estar indisponível sem que a outra máquina o perceba.

O processo no qual uma máquina assume os serviços de outra, quando esta última apresenta falha, é chamado failover.
O failover pode ser automático ou manual, sendo o automático o que normalmente se espera de uma solução de Alta Disponibilidade.
Ainda assim, algumas aplicações não críticas podem suportar um tempo maior até a recuperação do serviço, e portanto podem utilizar failover manual

Além do tempo entre a falha e a sua detecção, existe também o tempo entre a detecção e o restabelecimento do serviço. As grandes bases de dados, podem exigir um considerável período de tempo até que indexem as suas tabelas, e durante este tempo o serviço ainda estará indisponível.

Para se executar o failover de um serviço, é necessário que as duas máquinas envolvidas possuam recursos equivalentes.
Um recurso pode ser uma placa de rede, um disco rígido, ainda mais importante, os dados neste disco, e todo e qualquer elemento necessário à prestação de um determinado serviço.
É vital que uma solução de Alta Disponibilidade mantenha recursos redundantes com o mesmo estado, de forma que o serviço possa ser retomado sem perdas.

Dependendo da natureza do serviço, executar um failover significa interromper as transacções a decorrer, perdendo-as, sendo necessário reiniciá-las após o failover.
Noutros casos, significa apenas um retardamento até que o serviço esteja novamente disponível. Nota-se que o failover pode ou não ser um processo transparente, dependendo da aplicação envolvida

Quando se calcula a disponibilidade de um sistema, é importante que se tenha em conta o conceito de missão.
Missão de um sistema é o período de tempo no qual ele deve desempenhar suas funções sem interrupção.
Exemplo: uma farmácia, que funcione das 8h às 20h, não pode ter seu sistema fora do ar durante este período de tempo. Se este sistema vier a apresentar defeitos fora deste período, ainda que indesejados, estes defeitos não atrapalham em nada o andamento correcto do sistema quando ele é necessário.
Uma farmácia de serviço 24h obviamente tem uma missão contínua, de forma que qualquer tipo de paragem deve ser mascarada.

A Alta Disponibilidade visa eliminar as paragens não planeadas.
Porém, no caso da primeira farmácia, as paragens planeadas não devem acontecer dentro do período de missão.
Paragens não planeadas decorrem de defeitos, e paragens planeadas são aquelas que são necessárias para actualizações, manutenção preventiva e actividades correlativas.
Desta forma, toda a paragem dentro do período de missão pode ser considerada uma falha no cálculo da disponibilidade.

Uma aplicação de Alta Disponibilidade pode ser projectada inclusivamente para suportar paragens planeadas, o que pode ser importante, por exemplo, para permitir a actualização de programas por problemas de segurança, sem que o serviço deixe de ser prestado.