L’alerte Nextcloud missing indices signale que la base ne contient pas tous les index optionnels attendus par la version installée ou par une application active. Nextcloud ne les ajoute pas toujours pendant une mise à niveau, car leur création peut durer et ralentir temporairement les requêtes sur les tables concernées.
La commande prévue est occ db:add-missing-indices. Il ne faut pourtant pas la lancer sans lire l’alerte, identifier l’installation et préparer un retour arrière. Ce guide montre comment distinguer les avertissements de schéma, afficher les requêtes en simulation, appliquer les index puis contrôler le résultat.
Que signifie l’alerte « Database missing indices » ?
Un index de base de données est une structure qui aide le moteur SQL à retrouver des lignes sans parcourir toute une table. Il n’ajoute pas de fichiers à Nextcloud et ne réindexe pas le stockage des utilisateurs. Le tutoriel consacré à files:scan traite un autre sujet : le rapprochement entre les fichiers présents sur le stockage et leur cache dans la base.
Dans le contrôle d’administration actuel, Nextcloud classe les index concernés comme optionnels. Le serveur et les applications actives peuvent déclarer ceux qui leur manquent. L’alerte affiche alors le nom de chaque index avec sa table, puis recommande occ db:add-missing-indices.
La réparation peut améliorer les requêtes qui utilisent ces tables. Elle n’est cependant pas une réponse universelle à une instance lente. Une saturation PHP, un stockage distant instable, un verrouillage mal configuré ou une tâche d’arrière-plan bloquée demande un diagnostic séparé. Le guide général de Nextcloud permet de replacer la base parmi ces autres composants.
Un index SQL n’est pas l’index des fichiers
db:add-missing-indices modifie le schéma SQL attendu par Nextcloud. files:scan examine le stockage et le cache de fichiers. N’enchaînez pas les deux commandes sans avoir identifié deux problèmes distincts.
Quels avertissements de base ne faut-il pas confondre ?
La page Vue d’ensemble peut signaler plusieurs migrations différées. Le message exact détermine la commande à utiliser.
| Avertissement | Commande Nextcloud | Précaution documentée |
|---|---|---|
| Index optionnels manquants | occ db:add-missing-indices | La création peut prendre du temps et réduire temporairement les performances |
| Colonnes optionnelles manquantes | occ db:add-missing-columns | Certaines fonctions peuvent gagner en réactivité après ajout |
| Clés primaires manquantes | occ db:add-missing-primary-keys | L’ajout peut durer sur de grandes tables |
| Conversions BigInt en attente | occ db:convert-filecache-bigint | L’instance doit être hors ligne et l’opération peut durer plusieurs heures |
Ne remplacez pas la commande indiquée par une autre sous prétexte qu’elles commencent toutes par db:. Une conversion BigInt change le type de colonnes. L’ajout d’un index crée ou remplace une structure d’accès. Une clé primaire impose une contrainte propre à la table.
Sur les versions qui proposent db:schema:check, cette commande compare le schéma actif à celui attendu par la version de Nextcloud installée :
sudo -E -u www-data php /var/www/nextcloud/occ db:schema:check
La documentation intégrée précise que certains écarts peuvent venir de réglages ou de valeurs par défaut propres au moteur SQL. Le contrôle doit donc être lu comme un diagnostic, pas comme une autorisation de modifier manuellement toutes les différences affichées. Sur une version plus ancienne qui ne connaît pas cette commande, appuyez-vous sur la Vue d’ensemble et sur l’aide fournie par occ.
Que préparer avant d’ajouter les index ?
Commencez par copier le texte complet de l’avertissement, avec les noms d’index et de tables. Notez ensuite la version, l’état de maintenance et le besoin éventuel de mise à niveau :
sudo -E -u www-data php /var/www/nextcloud/occ status
sudo -E -u www-data php /var/www/nextcloud/occ db:add-missing-indices --help
Adaptez le chemin et le compte système à votre installation. www-data est fréquent sur Debian ou Ubuntu, mais ce n’est pas une valeur universelle. Exécuter occ avec root peut aussi créer des fichiers avec un propriétaire incohérent si une commande écrit dans l’arborescence applicative.
Avant une modification de schéma, vérifiez qu’une sauvegarde récente de la base existe et que sa procédure de restauration est connue. Le guide de sauvegarde Nextcloud rappelle qu’une reprise complète doit conserver la base, la configuration et les données dans un état cohérent. Pour cette intervention ciblée, la copie SQL est le retour arrière direct si la migration échoue.
Choisissez enfin une période de faible activité. Nextcloud explique que les index ne sont pas toujours ajoutés pendant les mises à niveau, car leur création peut prendre du temps et affecter temporairement les performances. La durée dépend des tables, du volume, du moteur SQL, du stockage et de la charge. Aucun délai générique ne permet de promettre une interruption de quelques secondes.
Le mode maintenance n’est pas présenté comme obligatoire pour db:add-missing-indices. Une fenêtre surveillée reste nécessaire. Si votre procédure impose une indisponibilité, utilisez le mode maintenance Nextcloud et validez sa désactivation après l’opération.
Ne créez pas l’index à la main à partir de son seul nom
La commande Nextcloud connaît les colonnes, l’unicité et les éventuels index anciens à remplacer. Une instruction SQL improvisée peut produire un schéma différent de celui attendu ou conserver un index devenu inutile.
Comment simuler db:add-missing-indices avant l’exécution ?
Dans le code de Nextcloud 35, l’option --dry-run demande d’afficher les requêtes SQL au lieu de les exécuter. Lancez-la avec le même environnement PHP et le même utilisateur que la future modification :
sudo -E -u www-data php /var/www/nextcloud/occ \
db:add-missing-indices --dry-run
Conservez la sortie dans le compte rendu d’intervention. Vérifiez que les tables correspondent à l’alerte et que la commande se termine sans erreur d’accès à la base. La simulation ne mesure pas la durée réelle et ne reproduit pas les verrous que le moteur peut prendre pendant la migration.
La syntaxe d’appel change selon le conditionnement, pas la sous-commande Nextcloud :
| Installation | Simulation |
|---|---|
| Archive Linux | sudo -E -u www-data php /var/www/nextcloud/occ db:add-missing-indices --dry-run |
| Image Docker officielle | docker exec --user www-data CONTENEUR php occ db:add-missing-indices --dry-run |
| Docker Compose | docker compose exec --user www-data app php occ db:add-missing-indices --dry-run |
| Nextcloud All-in-One | sudo docker exec --user www-data nextcloud-aio-nextcloud php occ db:add-missing-indices --dry-run |
| Paquet Snap | sudo nextcloud.occ db:add-missing-indices --dry-run |
Remplacez CONTENEUR et app par les noms réellement employés. Pour Compose, app correspond au service de l’exemple officiel et n’est pas imposé à tous les déploiements.
Comment appliquer les index manquants ?
Une fois la sauvegarde contrôlée, la simulation relue et la fenêtre ouverte, retirez seulement --dry-run :
sudo -E -u www-data php /var/www/nextcloud/occ db:add-missing-indices
La commande collecte les index déclarés par Nextcloud et par les applications actives. Pour chaque index absent, elle prépare la modification du schéma. Elle sait aussi ajouter un nouvel index avant de retirer les anciens noms lorsque la définition attendue prévoit un remplacement.
Pendant l’exécution :
- ne lancez pas une deuxième occurrence de la même commande ;
- surveillez la session, le moteur SQL, l’espace disponible et les journaux ;
- ne redémarrez pas la base pour interrompre une opération qui semble longue sans avoir vérifié son activité ;
- conservez le premier message d’erreur complet si la commande échoue ;
- n’ouvrez pas l’instance aux utilisateurs avant la recette si vous aviez activé le mode maintenance.
Une fermeture du terminal ne garantit pas que le moteur a annulé la modification. Contrôlez les processus et l’état de la base avant toute relance. Si l’opération a échoué, analysez la première erreur, comparez le schéma et décidez entre une correction documentée et une restauration. Répéter la commande sans comprendre un manque d’espace, un verrou ou un refus SQL peut aggraver l’indisponibilité.
Comment vérifier la base après la réparation ?
Relancez d’abord la simulation :
sudo -E -u www-data php /var/www/nextcloud/occ \
db:add-missing-indices --dry-run
Revenez ensuite dans Paramètres d’administration, puis Vue d’ensemble. Le contrôle « Database missing indices » ne doit plus lister les index traités. Si votre version fournit db:schema:check, exécutez-le à nouveau et conservez son code de sortie :
sudo -E -u www-data php /var/www/nextcloud/occ db:schema:check
echo $?
Dans Nextcloud 35, ce contrôle renvoie 0 lorsque les écarts bloquants sont absents et 1 lorsqu’il en trouve. Les différences rattachées à des applications désactivées n’affectent pas ce code, même si elles peuvent apparaître en sortie détaillée.
Terminez par une recette fonctionnelle :
- ouvrir la page Fichiers avec un compte de test ;
- parcourir un dossier contenant plusieurs éléments ;
- téléverser puis télécharger un petit fichier ;
- vérifier un partage utilisé par l’équipe ;
- contrôler les journaux Nextcloud et ceux de la base pendant ces actions ;
- confirmer que les tâches planifiées reprennent normalement.
Cette recette ne prouve pas un gain chiffré de performance. Pour mesurer un effet, comparez les mêmes requêtes et la même charge avant et après l’ajout. L’objectif immédiat est plus simple : retrouver le schéma attendu, supprimer l’avertissement correspondant et vérifier que les usages restent fonctionnels.
Pourquoi l’alerte revient-elle ou la commande échoue-t-elle ?
Une alerte qui revient peut provenir d’une application activée après l’intervention, d’une mise à niveau qui déclare un nouvel index ou d’un échec partiel. Comparez toujours la nouvelle liste à celle conservée avant l’opération. Le même bandeau ne signifie pas forcément que le même index manque encore.
Les causes courantes à examiner sont :
- le mauvais répertoire Nextcloud ou le mauvais conteneur ;
- une commande exécutée avec un PHP différent de celui du service web ;
- des identifiants SQL invalides ou une base indisponible ;
- un compte de base sans droit pour modifier le schéma ;
- un manque d’espace temporaire pendant la création de l’index ;
- un verrou ou une autre migration active ;
- une application dont la migration ne correspond pas à la version de son code.
Ne désactivez pas une application au hasard pour faire disparaître la ligne. Identifiez l’index, l’application qui le déclare et sa version. Si la base a été restaurée sans le code correspondant, ou inversement, rétablissez d’abord un ensemble cohérent. Le même principe s’applique après une migration : code, configuration et base doivent appartenir à un état compatible.
Conclusion
Pour corriger Nextcloud missing indices, partez du message exact, préparez une sauvegarde SQL, lancez db:add-missing-indices --dry-run, puis appliquez la commande pendant une période surveillée. Vérifiez ensuite la Vue d’ensemble, le schéma si la version fournit ce contrôle, les journaux et plusieurs actions utilisateur. Les avertissements sur les colonnes, les clés primaires et BigInt exigent leurs propres commandes et leurs propres conditions d’intervention.
Sources officielles
- Commande d’ajout des index manquants dans Nextcloud 35
- Contrôle administratif des index manquants dans Nextcloud 35
- Commande de comparaison du schéma dans Nextcloud 35
- Étapes de migrations longues après une mise à niveau
- Conversion des identifiants BigInt
- Commandes occ de Nextcloud
- Sauvegarder une installation Nextcloud
- Utiliser occ avec l’image Docker officielle
- Utiliser occ avec Nextcloud All-in-One
- Console occ du paquet Nextcloud Snap