Pour ownCloud 10, commencez par appliquer les modifications de schéma fournies par le noyau et les applications installés, puis vérifiez quelles requêtes de base de données sont réellement lentes. N'ajoutez pas d'index sans discernement et ne présumez pas que la commande Nextcloud db:add-missing-indicesest une commande de réparation prise en charge par ownCloud 10 : la documentation de référence actuelle d'ownCloud Server 10.15 OCC ne la mentionne pas. Les index peuvent accélérer les lectures correspondantes, mais chaque index ajouté consomme de l'espace de stockage et augmente la charge de travail des insertions, mises à jour et suppressions.
Cette approche convient à un administrateur confronté à une lenteur d'affichage des pages ownCloud, de la liste des fichiers ou du fonctionnement d'une application, et qui a accès au serveur et à la base de données. Si l'instance entière est lente, ou si elle utilise SQLite avec plusieurs utilisateurs actifs, il est conseillé de vérifier la configuration globale de la base de données et du déploiement avant d'incriminer les index.
Un index de base de données est une structure auxiliaire qui permet à la base de données de localiser les lignes sans avoir à parcourir l'intégralité de la table. ownCloud et ses applications définissent les tables, les colonnes et les index dans leur schéma. Les mises à jour du noyau et des applications peuvent inclure des migrations de schéma qui créent ou modifient ces index. Maintenir le schéma de l'application à jour est donc la première étape la plus sûre.
Avant de modifier quoi que ce soit, tenez compte des distinctions suivantes :
Un index n'améliore pas la vitesse de manière générale. L'ajout d'index peut optimiser certaines recherches, mais au prix d'une augmentation de la taille de la base de données et de la latence d'écriture. Le résultat dépend de la structure de la requête, de la taille de la table, de la distribution des données, du moteur de base de données et de l'état du cache.
sudo -u www-data ./occ status. Notez la version d'ownCloud, les versions des applications installées, le type de base de données et le préfixe des tables config/config.php. Remplacez [nom_du_compte_serveur_web] www-datapar le compte du serveur web de votre distribution.mysqldump --single-transactioncomme exemple les bases de données compatibles MySQL ; adaptez les valeurs d'hôte, d'utilisateur et de base de données à votre configuration. Ne saisissez jamais le mot de passe de la base de données directement dans l'historique du terminal ou dans la liste des processus.Si une mise à jour du noyau ou de l'application ownCloud est en attente, suivez la procédure de mise à niveau documentée correspondant à votre méthode d'installation. Sur une installation Linux classique, la commande OCC s'exécute en tant qu'utilisateur HTTP depuis le répertoire racine d'ownCloud. Lors d'une mise à niveau manuelle, la commande est :
sudo -u www-data ./occ upgrade
N’exécutez pas cette commande sur une installation dont les fichiers n’ont été que partiellement mis à jour. Commencez par installer les fichiers de la version correspondante et suivez la procédure de mise à niveau officielle. Pour les déploiements Docker, utilisez la commande OCC documentée du conteneur plutôt qu’un chemin d’accès à l’hôte pointant vers un environnement PHP différent.
Lisez attentivement la sortie complète de la commande et les journaux. Une commande réussie devrait se terminer sans signaler d'échec de migration ; cela ne garantit cependant pas la résolution de toutes les requêtes lentes. Si la mise à jour signale une erreur de migration, interrompez-la et examinez-la attentivement au lieu de relancer la commande à répétition ou de modifier manuellement les tables du schéma. Consultez la documentation de mise à niveau d'ownCloud spécifique à votre version et contactez le responsable de l'application si une migration est concernée.
La documentation de référence d'ownCloud 10.15 répertorie les commandes de base de données telles que db:convert-type` docker run`, db:convert-mysql-charset`docker run` et db:restore-default-row-format`docker run`, mais pas `docker run` db:add-missing-indices. La disponibilité des commandes pouvant varier selon la version et le code installé, vous pouvez inspecter votre instance avec ` docker run` sudo -u www-data ./occ list dbou ` sudo -u www-data ./occ help db:add-missing-indicesdocker run`. Si cette dernière indique une commande inconnue, ne copiez pas la commande d'un tutoriel Nextcloud dans ownCloud. Consultez la documentation correspondant à votre version d'ownCloud et suivez la procédure de mise à niveau ou de migration d'application recommandée.
L'exécution manuelle de SQL est une option réservée aux administrateurs de bases de données pour résoudre un problème de requête avéré, et non une optimisation de routine d'ownCloud. Commencez par capturer la requête lente exacte et exécutez l'outil d'inspection du plan d'exécution du moteur, par exemple EXPLAINpour MySQL/MariaDB ou PostgreSQL. Vérifiez si le plan analyse un nombre inutilement élevé de lignes et si un index existant est ignoré. Le préfixe des tables ownCloud est configurable ; ne présumez donc jamais que les noms de tables commencent par «oc_ . ».
Avant de créer un index, comparez les colonnes proposées avec les filtres, jointures et l'ordre de tri de la requête. L'ordre des colonnes d'un index composite est important ; dupliquer un index existant peut engendrer des coûts supplémentaires sans améliorer le plan d'exécution. Demandez à un administrateur de base de données (DBA) de prendre en compte le comportement de la version de la base de données, la prise en charge de la création d'index en ligne ou simultanée, l'espace disque disponible, l'impact sur les verrous et la procédure de restauration. Ces détails étant spécifiques au moteur et à la version, il n'existe pas de requête SQL unique et sûre pour toutes les installations d'ownCloud 10.
Ne modifiez pas les tables ownCloud et ne supprimez pas les index sous prétexte qu'un nom semble redondant. De telles modifications peuvent entraîner des conflits lors d'une migration ultérieure du noyau ou de l'application, et rendre inutilisable une fonctionnalité utilisant une requête différente de celle que vous avez examinée. Conservez une trace écrite de toute modification manuelle du schéma et assurez-vous qu'il puisse être recréé après une restauration ou une migration. Privilégiez un correctif ownCloud ou une nouvelle version de l'application si l'index manquant est dû à un défaut du schéma du produit.
Si le plan utilise déjà un index approprié, l'ajout d'un autre ne résoudra probablement pas un retard causé par ailleurs. Comparez ces options au goulot d'étranglement observé :
Changer de moteur de base de données est un projet de migration, et non une simple modification d'index. ownCloud propose occ db:convert-typedes conversions prises en charge ; consultez ses prérequis, effectuez une sauvegarde au préalable et testez l'instance convertie avant de la mettre à disposition des utilisateurs.
Répétez la même action utilisateur dans des conditions comparables et comparez la durée de la requête, le plan d'exécution, le nombre de lignes examinées, les E/S de la base de données et la charge du serveur. Vérifiez que la page ou l'application ownCloud concernée s'exécute correctement et que les journaux ne signalent aucune erreur de base de données ou de migration. Un résultat plus rapide sur une seule requête ne prouve pas une amélioration globale ; comparez plusieurs requêtes représentatives et tenez compte des caches actifs.
Si la même requête reste lente malgré l'utilisation d'un index approprié, examinez les verrous, le stockage, la latence réseau, les processus PHP et les limites des ressources de la base de données. Si le plan d'exécution ou la structure de la table est obscur, arrêtez-vous avant d'exécuter manuellement les instructions DDL et demandez à un administrateur de base de données ou au support ownCloud de les analyser. Le résultat optimal est un schéma aligné sur la version d'ownCloud installée et des requêtes mesurées, sans modifications d'index non enregistrées.
Découvrez quand les index de la base de données ownCloud 10 nécessitent une attention particulière, comment appliquer en toute sécurité les mises à jour de schéma prises en charge et quand l'optimisation des requêtes ou une modification de la base de données constitue la meilleure solution.
Connectez un partage réseau Windows ou Samba à ownCloud via un stockage externe, vérifiez les identifiants et résolvez les problèmes d'accès aux dossiers en toute sécurité.
Supprimez toutes les versions de fichiers ownCloud Server Classic stockées pour un compte ou pour tous les utilisateurs, et faites la distinction entre une purge complète et une expiration basée sur la rétention.
Pour identifier la cause d'un refus de connexion mobile ownCloud, vérifiez dans le bon ordre l'URL du serveur, le réseau téléphonique, le point de terminaison HTTPS et les journaux du serveur.
Remplacez les exécutions de tâches à la demande par une minuterie systemd qui exécute la commande système occ:cron prise en charge par ownCloud toutes les 15 minutes.
Suivez la requête WebDAV via Apache, Nginx ou un proxy inverse, puis vérifiez que la synchronisation ownCloud fonctionne avec un test PROPFIND authentifié.
Corrigez l'avertissement concernant l'adresse sortante manquante de Nextcloud en définissant son URL canonique et en vérifiant le DNS, le HTTPS et le routage du proxy inverse depuis le serveur lui-même.
Configurez APCu et Redis via un socket Unix local pour la mise en cache et le verrouillage des fichiers Nextcloud, avec les étapes pour les versions actuelles et antérieures de Nextcloud.
Vérifiez le mode cron de Nextcloud, réparez son service systemd et son minuteur, et assurez-vous que les tâches en arrière-plan s'exécutent après le démarrage et toutes les cinq minutes.
Activez le verrouillage fiable des fichiers Nextcloud, choisissez le bon backend Redis ou Valkey et vérifiez que l'avertissement disparaît sans risque de modifications simultanées des fichiers.
