PEBKAC #6868

Je reçois ce matin un e-mail de notre responsable des achats, qui me dit que les données de l'application que je développe ne sont pas à jour, et qu'elle ne peut donc pas travailler. Après vérification, la mise à jour s'est bloquée car il ne reste plus un seul octet de libre sur le serveur.

Entre les 50 Go de logs correspondants à chaque requête SQL effectuées sur la base de données depuis 2010, les 150 Go de sauvegardes automatiques (archivage quotidien d'un dossier, contenant la base de donnée réelle, plus des rajouts inutiles comme des bases de données de stagiaires ayant fini leur stage depuis belle lurette), et les divers dossiers que chacun utilise pour stocker ses fichiers alors que nous avons un NAS prévu pour cela... une bonne moitié du serveur est remplie inutilement.

Entre les utilisateurs qui font n'importe quoi, les administrateurs qui laissent faire, et la maintenance inexistante : PEBKAC.

PEBKAC #6868 proposé par Link le 05/02/2013 | 12 commentaires | 👍🏽 👎🏽 +222

Je ne sais pas pourquoi, mais faire des sauvegardes d'une base de données sur un même serveur ma parait assez inutile.

Commentaire #77542 écrit par but2ene le 05/02/2013 à 09h17 | 👍🏽 👎🏽

C'est déjà un minimum, J'ai vu beaucoup plus souvent une base totalement en vrac (souvent de cause humaine d'ailleurs), qu'un DD qui meurt sans la moindre récupération possible.

Commentaire #77546 écrit par Myosotys le 05/02/2013 à 09h28 | 👍🏽 👎🏽

Ce n'est pas le cas. La base de donnée (fichier d'un bon Go qui contient les commandes fournisseurs, commandes clients, inventaires, ..., géré par un programme que j'appellerai Gentil) est sur un serveur A.

Dans le cas présent il s'agit du serveur B, qui faisait une sauvegarde quotidienne (une copie du dossier contenant le fichier voulu, plus d'autres qui n'ont rien à faire là), et se servait de cette sauvegarde pour alimenter des applications internes.

Sauf que on a changé le programme Gentil a la fin de l'année, et donc la base de donnée a changée. Mais le serveur a continué à faire des sauvegardes de l'ancienne base (à laquelle plus personne ne touchait...)

Commentaire #77547 écrit par Link le 05/02/2013 à 09h30 | 👍🏽 👎🏽

dans ce cas, il faudrait le préciser dans le PEBKAC, j'aurais mis BEDP

Commentaire #77561 écrit par achille le 05/02/2013 à 11h10 | 👍🏽 👎🏽

Ça ce fait, ça se fait… http://www.pebkac.fr/pebkac/5102

Commentaire #77566 écrit par BSK le 05/02/2013 à 11h36 | 👍🏽 👎🏽

heu...
il n'y aurait pas une confusion entre G° et M°?
parce que des requêtes qui répondent avec des fichiers de 50 G°, ça me parait ÉNORME.

la dB du catalogue de la redoute (hors illustrations) ne doit pas dépasser 2 G° pour les articles,
et leur fichier clients ne doit pas dépasser 15 G°.

ou alors je n'ai rien compris

@+

ps, sans compter la taille des ddurs, si on te suit, il faut 1 T° par semaine.

Commentaire #77608 écrit par co2 le 05/02/2013 à 14h16 | 👍🏽 👎🏽

La base de donnée fait environ 1Go (un millier de Go). Sur les 6 derniers mois, on est bien à 150Go

Commentaire #77614 écrit par Link le 05/02/2013 à 14h33 | 👍🏽 👎🏽

C'est pas une requête qui fait ça, c'est toutes les requêtes (sans les réponses je pense) exécutées depuis 6 mois. Un fichier de log qui parle beaucoup et qui tourne jamais quoi...

Commentaire #77657 écrit par Myosotys le 05/02/2013 à 16h53 | 👍🏽 👎🏽

@co2 Tes informations sur La Redoute, tu les tiens d'une source fiable ?

J'ai discuté avec un admin DBA qui gère la base de données d'un très gros site marchand, et les données sont largement plus importante que ça. Un chiffre qui m'avait marqué : le plus gros index de la base dépasse les 100Go (je parle bien de 100 000 000 000 octets, il n'y a pas d'erreur).
Je précise que ce n'est pas une base qui sert à afficher des informations aux clients. C'est dans le data warehouse.

Et le DBA et question, c'est pas un clown. Donc si les données sont aussi importantes, c'est que c'est nécessaire.

Commentaire #77703 écrit par Moi le 05/02/2013 à 19h23 | 👍🏽 👎🏽

Tu veux dire 100Gio alors, parce que 100Go c'est 100*1024*1024*1024 octets
Après tout dépend comment sont gérées les photos des-dits produits, si les développeurs ont eu la bonne idée de stocker les images dans la bdd au lieu de ne stocker qu'un nom de fichier et d'y accéder dans un système de fichier prédéfini, et bien cela peut rapidement prendre des proportions énormes.

Commentaire #77767 écrit par Paddy le 06/02/2013 à 07h05 | 👍🏽 👎🏽

>Paddy c'est le contraire
100Gio= 100*1024*1024*1024 Octets
100Go = 100*1000*1000*1000 Octets

Commentaire #77790 écrit par DjYoshi le 06/02/2013 à 09h38 | 👍🏽 👎🏽

Dans la mesure où s'est un data warehouse, les photos des articles ne devraient pas être dedans. Mais je n'ai pas vraiment d'infos à ce sujet. C'est un système auquel je n'ai pas accès.

Commentaire #77933 écrit par Moi le 06/02/2013 à 18h13 | 👍🏽 👎🏽