Como otimizar com segurança os índices do banco de dados ownCloud 10
Uma listagem lenta de pastas no ownCloud, sincronização atrasada ou uma tarefa cron de longa duração podem indicar um gargalo no banco de dados, mas adicionar índices indiscriminadamente pode tornar o servidor menos confiável. No ownCloud Server 10, o ponto de partida seguro é verificar a versão e o banco de dados exatos, fazer backup da instância e, em seguida, usar apenas as alterações de esquema documentadas para aquela versão do ownCloud. Os índices podem auxiliar em buscas e junções seletivas; eles também consomem armazenamento e aumentam o trabalho de inserções e atualizações.
Existe uma distinção importante entre as versões: a documentação oficial atual do ownCloud Server 10.16 descreve operações de banco de dados, como conversão, mas não inclui um db:add-missing-indicescomando geral de reparo. Esse comando aparece no guia do Nextcloud, que é um produto separado. Verifique os comandos no seu próprio servidor antes de executar um comando copiado de outro projeto.
O occ statuscomando confirma que a CLI está alcançando a instalação do ownCloud antes do início do trabalho no banco de dados.
O que um índice de banco de dados pode — e não pode — corrigir
Um índice de banco de dados é uma estrutura auxiliar que ajuda o banco de dados a localizar linhas correspondentes sem precisar percorrer a tabela inteira. Ele pode melhorar uma consulta que filtra, une ou classifica colunas indexadas quando a consulta e a distribuição dos dados tornam esse índice útil. Não se trata de uma alteração geral de velocidade: o otimizador de banco de dados pode escolher corretamente uma varredura completa da tabela para tabelas pequenas ou consultas que retornam uma grande parte das linhas.
Os índices também têm custos. Eles ocupam espaço em disco, precisam ser mantidos quando as linhas são alteradas e podem tornar mais lentas as operações de escrita intensiva. Índices extras em tabelas principais do ownCloud podem entrar em conflito com migrações de esquema ou com as expectativas do aplicativo. Não adicione um índice apenas porque o nome de uma coluna parece importante; primeiro identifique a solicitação lenta e confirme se o plano de consulta real é ineficiente.
1. Confirme a compilação e o banco de dados do ownCloud.
Execute comandos a partir do diretório de instalação do ownCloud como a conta do servidor web. Em uma instalação típica do Debian ou Ubuntu, essa conta é www-data:
cd /var/www/owncloud
sudo -u www-data php occ status
sudo -u www-data php occ list
Use o caminho e a conta de serviço configurados no seu host. No Docker, use o formato de comando documentado do contêiner — por exemplo, o manual do ownCloud usa `docker- docker compose exec owncloud occ …compose up`. A saída do status identifica a versão do ownCloud e o tipo de banco de dados. A lista de comandos mostra o que esta instalação realmente suporta; se um comando de reparo de banco de dados não estiver listado, não assuma que as instruções do Nextcloud se aplicam.
Verifique a visão geral do administrador do ownCloud em busca de avisos de configuração e anote os nomes exatos das tabelas e índices caso seja relatado um índice ausente. Registre também o que está lento: uma pesquisa de arquivo específica, uma página de compartilhamento, uma tarefa em segundo plano ou uma operação de sincronização. Uma reclamação vaga como "o ownCloud está lento" não é suficiente para justificar uma alteração de esquema.
Use a occlista de comandos instalados como verificação de versão; a disponibilidade de comandos pode variar entre o ownCloud e o Nextcloud.
2. Faça backup antes de alterar as estruturas do banco de dados.
Antes de criar qualquer índice, migrar ou reparar um banco de dados, faça um backup consistente do banco de dados e da configuração do ownCloud e certifique-se de saber como restaurá-lo. O guia de backup do ownCloud recomenda ativar o modo de manutenção antes de fazer um backup do banco de dados. O comando exato para fazer o dump do banco de dados depende se o servidor usa MySQL, MariaDB, PostgreSQL ou SQLite; use as ferramentas do fornecedor do banco de dados correspondente e proteja as credenciais e os arquivos de backup.
sudo -u www-data php occ maintenance:mode --on
# Back up the database and ownCloud configuration with your vendor's procedure
# Confirm that the backup can be restored before proceeding
O modo de manutenção impede o uso normal enquanto a manutenção estiver em andamento; planeje uma janela de serviço para produção. Não copie um arquivo de banco de dados ativo como substituto para um backup compatível com o banco de dados. Assim que o trabalho e as verificações básicas forem concluídos, retorne a instância ao modo normal.
sudo -u www-data php occ maintenance:mode --off
Tenha um backup restaurável do banco de dados e da configuração antes de tentar qualquer alteração de índice ou esquema.
3. Utilize migrações gerenciadas pelo ownCloud para alterações de esquema do ownCloud.
Primeiro, atualize o ownCloud e seus aplicativos compatíveis para uma versão suportada, seguindo as instruções oficiais de atualização e as notas de versão. As atualizações do ownCloud executam migrações de banco de dados que alteram o esquema, incluindo as mudanças necessárias para o núcleo e os aplicativos. As orientações oficiais recomendam executar a atualização do banco de dados passo a passo occpara sistemas maiores, onde uma solicitação da web pode expirar.
Se a visão geral do administrador ainda indicar um índice ausente, verifique sudo -u www-data php occ lista documentação oficial relevante para a sua versão específica do ownCloud. Alguns guias de terceiros mostram db:add-missing-indiceso comando `index.sql`, mas ele não está documentado na seção de comandos de banco de dados do ownCloud 10.16 analisada neste artigo. Se a sua versão listar esse comando, leia a ajuda local e confirme o procedimento com a documentação ou o fornecedor do aplicativo para essa versão antes de executá-lo. Se o comando estiver ausente, não instale um comando do Nextcloud, não edite as tabelas principais do ownCloud manualmente nem copie SQL de outra versão. Compartilhe o aviso, a versão do ownCloud, o tipo de banco de dados e os logs relevantes com o ownCloud ou o mantenedor do aplicativo.
Os comandos de banco de dados mostrados no manual do ownCloud — como `SET` db:convert-typeou ` db:convert-mysql-charsetSET` — servem para tarefas de conversão específicas; eles não são comandos genéricos de ajuste de índice. Não use um comando de conversão para tentar melhorar a velocidade de consulta.
4. Investigue uma consulta lenta com ferramentas nativas do banco de dados.
Ao identificar uma consulta SQL lenta, utilize as ferramentas de análise fornecidas pelo seu banco de dados. MySQL e MariaDB oferecem o `analyze` EXPLAIN; o PostgreSQL também oferece o `analyze` EXPLAIN, com sua própria saída e opções. Comece com um plano que explique a consulta sem executá-la. Tenha cuidado com a opção `analyze`: algumas variantes de banco de dados executam a instrução `SELECT`, o que pode ser inseguro para gravações ou custoso em um banco de dados de produção com alta carga.
EXPLAIN SELECT ... FROM oc_filecache WHERE ...;
Verifique se o plano lê muito mais linhas do que a consulta retorna, se o índice esperado é considerado e se a classificação ou junção domina o trabalho. Um índice não escolhido pelo otimizador não significa necessariamente que ele esteja ausente: se a consulta retornar muitas linhas, uma varredura completa pode ser mais eficiente. Compare a mesma carga de trabalho em uma cópia de teste representativa antes de fazer alterações específicas do banco de dados. O SQL principal e os layouts de tabela do OwnCloud podem mudar entre as versões, portanto, um índice que parece útil hoje pode se tornar redundante ou inseguro após uma atualização.
Antes de considerar qualquer índice personalizado, leia o plano de consulta específico do banco de dados para identificar a consulta realmente lenta.
5. Verifique novamente o sintoma original.
Após a conclusão de uma migração suportada ou reparo de índice aprovado, verifique novamente a visão geral do administrador do ownCloud e revise os logs do servidor e do banco de dados em busca de erros. Repita a mesma ação do usuário ou tarefa em segundo plano que apresentou lentidão, utilizando volume de dados e condições semelhantes. Compare o tempo de resposta, o uso de CPU ou E/S do banco de dados e o número de linhas examinadas nos locais onde seu banco de dados disponibiliza essas medições. Não relate um ganho de desempenho a partir de um único teste pequeno ou de um carregamento de página não relacionado.
Se o aviso desaparecer, mas a mesma ação ainda estiver lenta, o gargalo pode estar em outro lugar: latência de armazenamento, processos PHP, requisições à rede, atrasos no cron, bloqueio de arquivos ou cache de memória. O ownCloud recomenda o uso de cache de memória e bloqueio de arquivos transacionais externos para reduzir a carga do banco de dados. Essas configurações lidam com tarefas diferentes da indexação do banco de dados, portanto, configure-as de acordo com o manual oficial e a topologia da sua implantação.
Lista de verificação rápida
Registre a versão do ownCloud, o tipo de banco de dados, a ação afetada e qualquer aviso de configuração específico.
Verifique a occlista de comandos instalados; diferencie as instruções do ownCloud das instruções do Nextcloud.
Antes de trabalhar com o esquema, faça e verifique se o banco de dados e a configuração estão corretos.
Utilize os procedimentos de atualização e migração de aplicativos do ownCloud suportados; não altere manualmente as tabelas principais sem instruções específicas da versão.
Utilize as ferramentas de planejamento de consultas do fornecedor do banco de dados na consulta realmente lenta e, em seguida, repita a mesma carga de trabalho para verificar o resultado.
Não existe um conjunto de índices universal que torne todas as instalações do ownCloud 10 mais rápidas. A abordagem mais eficaz consiste em manter o esquema suportado atualizado, diagnosticar a consulta real, alterar apenas o que o fornecedor ou mantenedor relevante documenta e verificar a mesma carga de trabalho posteriormente.