Força a compactação do banco de dados para o servidor Lotus Domino?

Question

Recentemente, tivemos algumas experiências desagradáveis em que um banco de dados muito usado do Lotus Notes ultrapassou o limite de 64 gb.

Os bancos de dados tinham algum espaço de armazenamento que nos permitia executar uma compactação de banco de dados para corrigir o problema, mas colocar o banco de dados offline por tempo suficiente para que uma compactação tivesse uso exclusivo do banco de dados era um verdadeiro pesadelo.

Nós tentamos:

• Permitindo aos usuários acesso somente leitura ao banco de dados enquanto o banco de dados estava compactando.
  (a compactação falharia depois de algum tempo, dizendo que o banco de dados foi modificado)
• Removendo o acesso a todos os não administradores do banco de dados
• Desativando a replicação para o banco de dados
• descarte database.nsf - para expulsar todo mundo desse banco de dados
• dbcache flush - para fechar todos os bancos de dados que estavam abertos no cache do banco de dados

Ainda assim, os usuários apareceriam como acessando o banco de dados e não permitiriam uma compactação no modo exclusivo.

Eventualmente, recorremos a:

• Removendo o acesso a todos os não administradores do banco de dados
• reiniciando o servidor
• digitando rapidamente no console do servidor: "compact -c databasename.nsf" antes que alguém tente acessar o banco de dados

Existe uma maneira mais fácil de expulsar todo mundo de um banco de dados e forçar uma compactação de banco de dados exclusiva? Estamos executando o Lotus Domino Server 8.5.3

    

Answer 1

compact -B é "Local com redução do tamanho do arquivo". Experimente se você ainda não o fez.

No meu entendimento, drop db.nsf não funciona. Tente Drop All e, se isso funcionar, você poderá escrever algum código que abandone apenas os usuários que acessam esse banco de dados.

    

Answer 2

Por que não implementar um cluster (configurado para failover), você pode alternar os usuários para o outro. Então você tem tempo para consertar o banco de dados e executar um compacto. Você também pode excluir o banco de dados e permitir que ele seja recriado a partir do segundo servidor (o banco de dados recriado já estará compactado).

A propósito. Gostaria de ativar (se ainda não estiver ativado) Document & Projete Compression junto com LZ1 que pode ajudar a encolher um pouco o DB (depende do conteúdo).

    

Answer 3

Você pode tentar um compacto offline usando o utilitário ncompact do cliente do Notes. Ele tem as mesmas opções que o comando compact do console do Domino, mas ele funciona diretamente no nfs sem abrir o Notes ou executar o Domino.

Se você não quiser mover este enorme nfs, você pode usar um compartilhamento de rede e executar o ncompact sobre ele. Eu sugiro strongmente que você corrija o problema e converta-o em ODS 5.1 se ele usar uma versão antiga do ODS.

Sugiro também verificar o nsf e não deixá-los atingir esse tamanho, arquivar documentos movendo-os para novas cópias do nsf. Tente mantê-los em torno de alguns gigabytes, para que você possa executar a correção e compactar com frequência, tenha certeza da consistência deles.

    

Answer 4

Antes de substituir a réplica no servidor principal por uma nova do cluster, sugiro confirmar que o número de documentos é o mesmo ou razoavelmente próximo e que não há problemas estruturais com a réplica no servidor de cluster. Eu iria verificar isso executando compacto no banco de dados no cluster e analisando o log do console no servidor de cluster para erros.

    

Answer 5

Estou com o mesmo problema com o Compact -C -DAOS ON. Ele falhou dizendo compacto foi interrompido prematuramente porque outro usuário modificou enquanto estava sendo compactado. Parar o roteador, a tarefa SMTP e o replicador solucionam o problema. Eu não sei qual tarefa é responsável neste momento, mas está trabalhando