arrow_back_ios

Main Menu

arrow_back_ios

Main Menu

arrow_back_ios

Main Menu

O que devo fazer para proteger os meus dados ReliaSoft numa base de dados padrão?

 

Todas as aplicações ReliaSoft a partir da Versão 8, bem como versões anteriores do XFMEA/RCM++, funcionam com bases de dados padrão que utilizam o formato de ficheiro Microsoft Access no backend para armazenar dados de análise. Isto torna possível instalar e utilizar o software sem necessidade de adquirir licenças adicionais para um sistema de base de dados empresarial (tais comoSQL ServerouOráculo) e sem necessidade de infraestrutura e suporte de TI especiais. No entanto, ficheiros de base de dados padrão (por exemplo, *.rsr22, *.rsr21) e ficheiros de biblioteca padrão (por exemplo, *.lb22, *.lb21) estarão sujeitos às mesmas limitações e vulnerabilidades que qualquer outra base de dados do Access. Por exemplo, o tamanho máximo do ficheiro é~2GB, o número máximo de utilizadores simultâneos é 255, etc. Além disso, algumas vulnerabilidades específicas da base de dados são discutidas numa publicação da Microsoft emhttp://support.microsoft.com/kb/283849/EN-US/. Como afirma esta publicação:

"O Microsoft Jet, o motor de base de dados utilizado no Microsoft Access, é um sistema de base de dados de partilha de ficheiros. Quando o Microsoft Jet é utilizado num ambiente multiutilizador, múltiplos processos clientes utilizam operações de leitura, escrita e bloqueio de ficheiros numa base de dados partilhada. Como múltiplos processos clientes estão a ler e escrever na mesma base de dados e porque o Jet não utiliza um registo de transações (como os sistemas de bases de dados mais avançados, como o SQL Server),não é possível prevenir de forma fiável qualquer corrupção da base de dados." [ênfase adicionada]

Embora os desenvolvedores da ReliaSoft tenham feito todos os esforços para reduzir ou eliminar a possibilidade de o software induzir um erro na base de dados, não há forma absoluta de prevenir a corrupção que possa ser causada por outros fatores, como um hardware de rede defeituoso, um "crash" inesperado no seu PC ou uma interrupção da rede. Por isso, este documento fornece algumas recomendações gerais para precauções padrão que todos os utilizadores podem tomar para proteger os dados nas suas bases de dados padrão contra este tipo de corrupção e reduzir o impacto da perda de dados caso a corrupção seja inevitável.

Para instruções específicas sobre como seguir estas precauções numa determinada versão do software, pode procurar por "prevenir corrupção" no ficheiro de ajuda.

 

1. Crie backups regularmente

Tal como em qualquer ficheiro que contenha uma grande quantidade de informação valiosa que seria difícil de recriar, é essencial garantir que é diligente na criação e armazenamento de ficheiros de backup.

 

2. Compacte e repare a base de dados regularmente

A utilização da funcionalidade "Compactar e Reparar" ajudará a reduzir o tamanho do ficheiro da base de dados e a proteger contra problemas no funcionamento da base de dados.

 

3. Não guarde a base de dados numa localização partilhada de rede se suspeitar que a sua ligação e/ou hardware de rede possam ser pouco fiáveis

Segundo a Microsoft, o hardware de rede defeituoso é uma das principais razões pelas quais um ficheiro que utiliza o formato de base de dados do Microsoft Access pode ficar corrompido. Como a publicação da Microsoft emhttp://support.microsoft.com/kb/283849/EN-US/Afirma:

A causa pode ser um ou mais elos na cadeia de hardware entre o computador onde a base de dados reside e o computador que tem a base de dados aberta. Esta lista inclui, mas não se limita a, placas de interface de rede, cablagem de rede, routers e hubs.
A corrupção baseada em hardware é tipicamente indicada por ficheiros .mdb que não podem ser restaurados através do uso de compactação, reparação ou Jetcomp. A corrupção de hardware normalmente recorre até que o hardware responsável seja reparado ou substituído." [ênfase adicionada] 
[Note que no software ReliaSoft, as extensões são coisas como *.rsr22 ou *.lb22 em vez de *.mdb.]

 

Se já experienciou este tipo de corrupção num ficheiro de base de dados padrão, recomenda-se que tome medidas para corrigir o problema de rede ou que evite aceder a ficheiros de base de dados através da rede. Nesses casos, pode optar por usar uma base de dados empresarial (ou seja, Oracle ou SQL Server), que seria menos vulnerável a interrupções de rede. Alternativamente, pode manter a análise inteira num único ficheiro de base de dados padrão partilhado, mas pedir aos utilizadores que importem a análise para uma base de dados "funcional" separada nos seus próprios computadores quando for necessário fazer modificações substanciais. Os utilizadores podem então exportar os dados de volta para o repositório partilhado após a conclusão das modificações.

 

4. Não permita que o tamanho do ficheiro da base de dados cresça demasiado

O desempenho será afetado pelo tamanho da base de dados e pelo número de utilizadores simultâneos. Por isso, é importante que os utilizadores monitorizem o tamanho dos seus ficheiros de base de dados e, se estes se tornarem demasiado grandes, tomem medidas para exportar os dados para vários ficheiros mais pequenos e geríveis. Por favor, esteja ciente dos seguintes fatores, que podem levar a ficheiros de base de dados muito grandes:

  • Falha em "compactar e reparar" a base de dados regularmente.
  • Usar um número muito grande de documentos "anexos". Em alguns casos, usar um "link" em vez de um "anexo" pode fornecer funcionalidades equivalentes com um impacto muito menor no tamanho do ficheiro da base de dados.

 

Se tentar abrir uma base de dados padrão através do software e receber uma mensagem a dizer "Não é possível abrir a base de dados", isto indica que o ficheiro da base de dados pode estar corrompido. Por favor, contacte Apoioe forneça o máximo de informação possível sobre exatamente o que estava a fazer quando a corrupção ocorreu. Sempre que possível, por favor forneça uma cópia do ficheiro corrompido. Em alguns casos, a ReliaSoft pode prestar assistência na recuperação de parte ou de todos os dados afetados. No entanto, em muitos casos, a melhor solução pode ser restaurar a última cópia de segurança anterior à corrupção. 

 

A informação é fornecida "tal como está", sem qualquer tipo de garantia.