[RÉGLÉ] Purger la base de données

[lostinjoom]

Bonjour à tous,
je regarde par hasard ma base de données sur OVH et me rends compte qu'elle a dangereusement pris de l'ampleur. Donc je regarde la table et je vois que la table la plus chargée est xxxx_finder_terms avec 60,7 Mio,
xxxx_ucm_history avec 15,5 Mio
ainsi que plusieurs table identifiées par xxxx_finder_links_terms suivi de lettres (sb, sc, sd) ou d'un chiffre de 1 à 8) quelqu'un sait à quoi ça correspond ? Quand je regarde je ne vois que des chiffres…

Merci pour votre aide.
Bonne journée

[RobertG]

Bonjour,

Les tables "finder" sont liées au composant de recherche avancée. Pour info et par défaut, Akeeba backup ne sauvegrade le contenu que de finder_filters, finder_term_commons et finder_types. On peut en déduire qu'il est possible de vider les autres tables finder (les vider, pas les supprimer).

Quant à ucm_history, elle enregistre les diverses versions des articles et d'autres données afin de pouvoir aisément revenir à une version antérieure, donc si tu n'as pas besoin de conserver cet historique, tu peux aussi vider cette table ou au moins dans un premier temps changer les paramètres du nombre de version à conserver qui est par défaut à 10.

[lostinjoom]

Merci pour ces précisions. N'y a-t-il pas un moyen de purger cette base de données pour ne conserver que l'essentiel ? Ils disent de le faire sur ovh mais je ne sais pas comment…

[cavo789]

Bonsoir

Je te poste ici un script que j'ai écris et qui peut nettoyer ta base de données mais ****à utiliser strictement si tu sais ce que tu fais**** : https://github.com/cavo789/joomla_fr...kill_db_tables

Comme tu le sais peut-être ton site Joomla utilise un préfixe pour nommer les tables ("jos_xxx" sous J1.5 et un préfixe dynamique depuis J2.5).

Si ta base de données ne contient qu'un et un seul site (==> faut être certaine de cela) et si tu sais que ton préfixe est p.ex. "monsite_xxx" (là encore faut être sûre) alors si tu as des tables préfixes avec p.ex. "back_xxx", "old_xxx", etc. tu peux donc virer ces tables à l'aide de mon script.

Une fois encore : très utile mais très risqué dans le cas où tu tâtonnes. Faut savoir ce qu'on fait en l'utilisant.

Autre cas d'exemple : tu as des tables avec ton préfixe (imaginons "monsite_xxx") et tu repères des tables pour une extension que tu sais que tu n'as plus (p.ex. "monsite_com_old_xxxxx"). Tu peux donc virer toutes les tables dont le nom commence par "monsite_com_old". C'est le but du script que je propose.

(Note : le script ne prends pas de backup ! gaffe à son utilisation du coup)

Bonne soirée.

[lostinjoom]

Merci cavo789 oui je n'ai qu'un seul site sur la base de données, mais non, je ne sais pas exactement ce que je fais si j'utilise ton script car je ne suis pas super à l'aise avec le fonctionnement de la BDD. Et je n'ai pas des masses d'extensions, et je n'en ai pas de supprimées.

Par contre, ce qui est bizarre, c'est toutes ces tables (j evous la fait courte) xxxx_finder_links_terms0 ; xxxx_finder_links_terms1 -2 -3---jusqu'à 9 qui font en tout près de 36 Mo, + xxxx_finder_terms qui fait à elle seule presque 61 Mo.

J'ai supprimé la presque totalité de la base ucm_history mais je ne comprends pas pourquoi elle toujours aussi lourde (15,5 Mio)…
Je ne regarde pas tous les jours le poids de la base de données mais il me semble que son poids a brusquement augmenté après la dernière mise à jour.
Pour ces tables (xxxx_finder_links_terms0 ; xxxx_finder_links_terms1 -2 -3---jusqu'à 9) vous les avez aussi ? Elle sont ausii lourdes ?
Parce que si c'est juste à cause du module de recherche, je le supprime.

Mais j'ai un peu peur de faire des bêtises…
Merci pour votre aide

[RobertG]

Dans ma première réponse, j'ai précisé que trois tables "finder" seulement sont conservées par Akeeba backup lors d'une sauvegarde, ce qui veut dire que les autres "finder" ne sont pas nécessaire en cas de restauration d'un site, et que donc les autres peuvent être vidées depuis phpMyAdmin.
Comment as-tu partiellement vidé la table ucm_history ? Si elle reste lourde c'est peut-être que le calcul de sa taille n'est pas instantané (je n'ai pas essayé chez OVH), ou qu'il y a encore de très nombreuses données : combien de lignes sont signalées en haut de la page, quand tu affiches le contenu de cette table ?
La seule table qui a assez récemment augmenté de taille est la table "sessions" en lien avec un changement de son nettoyage automatique. Pour réduire sa taille et la présence de données déjà périmées, il faut que tu accèdes au plugin de purge et que tu augmentes l'avant-dernier paramètre ou diminue le dernier pour changer le pourcentage résultant et accélérer le nettoyage régulier de cette table.

Si tu n'as pas besoin de la recherche avancée, tu peux en effet la désactiver, puis voir si les tables "finder" se sont ou non vidées, ou si tu dois le faire manuellement (là encore "vider" et non "supprimer").

[lostinjoom]

RobertG il n'y a plus que 48 lignes sur la table ucm_history. Je l'avais partiellement vidée hier et encore ce matin (je n'ai pas osé supprimer les lignes concernant l'année 2019) Par contre, elle fait toujours 15,5 Mio.
J'avais déjà été alertée sur la table session. Je l'ai vidée, elle ne fait que 48 Kio pour 65 lignes. Donc ça va.

Je vais désactiver la recherche et vider les tables correspondantes. Je vous dirai demain si ça a eu un effet sur le poids…
Merci pour votre aide

[lostinjoom]

Bon, j'ai vidé (pas supprimé) les tables dont je vous ai parlé plus haut, de 147 Mo la table est passée à 38 Mo. Ce qui est tout de même énorme !
Du coup j'ai désactivé les plug-ins de recherche avancée et même le module de recherche (qui n'est pas très utile dans mon cas)
Je respire mieux. Ouf !
Merci à tous pour votre aide.
Bonne soirée !