Discussion :

[franckcl]

Bonjour,

Je souhaiterai savoir s'il existe une solution via une requete SQL pour connaitre la taille totale du disque dur (ou partition) sur lequel la base est enregistrée.

J'ai fait quelques recherches et je n'arrive pas à trouver.
Je trouve les tailles des tables, par exemple, mais rien sur la taille total du disque.

merci
Franck

[escartefigue]

Bonjour,

SQL n'est pas fait pour consulter les supports physiques des données que sont les disques, mais pour consulter et mettre à jour les éléments de la base de données.
En plus, une base de données peut être hébergée sur plusieurs disques.
Enfin tout SGBD-R doit garantir l'indépendance entre la couche physique et la couche logique, consulter directement les disques serait une entorse à cette règle

[franckcl]

Merci, c'est ce que j'en ai conclu, mais je voulais confirmation pour savoir s'il n'y avait pas un moyen détourné pour faire ça, du coup je passe par un script PHP.

[SQLpro]

Bonjour,

SQL n'est pas fait pour consulter les supports physiques des données que sont les disques, mais pour consulter et mettre à jour les éléments de la base de données.
En plus, une base de données peut être hébergée sur plusieurs disques.
Enfin tout SGBD-R doit garantir l'indépendance entre la couche physique et la couche logique, consulter directement les disques serait une entorse à cette règle

Sauf que c'est faisable sous oracle ou SQL Server les doigts dans le nez et ben pratique pour prévenir de la saturationa.... Exemple sous SQL Server en 1 requête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT DISTINCT vs.volume_mount_point, vs.volume_id, total_bytes
FROM   sys .master_files AS mf  
       CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.file_id) AS vs

A +

[escartefigue]

Sous réserve que le volume soit dédié à 100% à la BDD concernée, certes, c'est une bonne pratique de base, mais rien n'interdit que ce ne soit pas le cas

[Artemus24]

Salut à tous.

Je crois que vous faites une confusion entre l'administration d'une base de données et l'administration d'un système.

Il n'exister pas d'outil dans un SGBDR pour évaluer la disponibilité restante d'un disque dur. Pourquoi ?
Parce que vous n'avez pas toutes les autorisations systèmes pour connaitre la disponibilité restante de l'espace de votre disque dur.
Voire même, ce disque dur peut-être partagé avec d'autres applications dont vous n'avez aucune action possible dessus.

C'est pourquoi, Le tablespace a été créé pour réserver l'espace disque dont vous avez besoin pour bien faire fonctionner votre SGBDR.
Voire même les partitions pour répartir les données sur plusieurs disques afin d'améliorer les performances.
Mais il arrive que votre tablespace vienne a être saturée. D'où une intervention manuelle pour résoudre ce problème.

Pourquoi une intervention manuelle ? Et en quoi elle consiste ?
D'une part, vous n'êtes pas le responsable système et de ce fait, vous ne pouvez pas mettre vos partitions n'importe où.
Il suffit d'être hébergé pour ce rendre compte que l'espace disque est limité mais aussi payante !
Et que vous devez fair une demande d'extension pour obtenir plus d'espace.
Mais aussi, de procéder à une maintenance quotidienne pour prévenir toutes sortes de problèmes.

Vous devez connaitre le taux d'occupation de votre disque dur actuellement où est hébergé votre table.
Vous devez aussi connaitre le taux d'évolution de votre table, disons par jour.
Et donc, savoir évaluer quand le problème va se poser.

De faire du nettoyage en supprimant tout ce qui ne sert plus rien, en l'archivant par exemple sur un autre support.
Créer des partitions si vous constatez un mauvais équilibrage dans la répartition de la volumétrie de vos tables dans vos disque durs.
Si le problème persiste encore, faire une demande d'espace disque supplémentaire à votre ingénieur système ou à l'hébergeur qui vous donnera les autorisations.

Cela ne peut pas se résumer à un simple outil de surveillance.
Vous devez aussi prévoir de faire un backup au cas où vous auriez un plantage.

@+

[SQLpro]

Sous réserve que le volume soit dédié à 100% à la BDD concernée, certes, c'est une bonne pratique de base, mais rien n'interdit que ce ne soit pas le cas

Non, puisque cette requête renvoie TOUS les disques sur lesquels une base de données repose et non pas un disque !

A +

[escartefigue]

Ca ne change rien : si une autre BDD ou une autre application consomme de l'espace sur le même disque, la mesure coté BDD ne présente aucun intérêt puisque le taux de croissance n'est pas maîtrisé.
Quoi qu'il en soit, il faut utiliser SQL pour ce qui est du ressort de la BDD (la taille des tablespace par exemple) mais pas ce qui est du ressort de l'OS

[SQLpro]

Ca ne change rien : si une autre BDD ou une autre application consomme de l'espace sur le même disque, la mesure coté BDD ne présente aucun intérêt puisque le taux de croissance n'est pas maîtrisé.
Quoi qu'il en soit, il faut utiliser SQL pour ce qui est du ressort de la BDD (la taille des tablespace par exemple) mais pas ce qui est du ressort de l'OS

1) en principe un SGBD R doit être sur un serveur dédié. Donc exit les autres applications...
2) cela n'empêche en rien d'auditer régulièrement l'espace libre du disque. Sur les serveurs dont je m'occupe nous le faisons environ toutes les 20 minutes en partant de disques ou il y a toujours, préalablement au moins 30 % d'espace libre (souvent bien plus)...
3) si c'est sur d'autres disques du serveur ou il n'y a pas de bases, cela n'aura pas d'incidence sur le fonctionnement du SGBDR... S'il est bien fait !

A +