Tout est dans le titre.
Après avoir cherché des heures Le Script qui sort les tailles utilisée
par les tables & index, je pose ma question sur ce forum.
Rien n'a l'air d'être trés simple/clair sur Oracle (7 et 9). Tout le
monde à son script maison, un peux 'usine à gaz'. Oracle ne fournis
pas vraiment de truc pour trouver la volumétrie d'une base existante.
Et encore moins, pour estimer à partir ce çà, la volumétrie d'une base
future.
Je crois avoir finalement trouvé pour la taille utilisés par les
tables :
dbms_utility.analyze_schema('schema1', 'compute') <--- Oracle 7
DBMS_STATS.GATHER_SCHEMA_STATS('PSEVR'); <--- Oracle 9
select tablespace_name, table_name, num_rows*avg_row_len "TAILLE
OCCUPEE (octets)", 8192*blocks "nb block x block_size
(octets)",initial_extent, next_extent, pct_free, pct_used,num_rows,
blocks, empty_blocks, avg_space, avg_row_len from sys.dba_tables where
tablespace_name like 'tbs1'
Par contre pour les INDEX ????????
Le contenus de sys.dba_indexes n'as pas l'air de faire l'affaire...
Une idée (simple :-) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Lionel TETTAMANTI
Bernard Segonnes a écrit :
Bonjour,
Tout est dans le titre. Après avoir cherché des heures Le Script qui sort les tailles utilisée par les tables & index, je pose ma question sur ce forum.
Rien n'a l'air d'être trés simple/clair sur Oracle (7 et 9). Tout le monde à son script maison, un peux 'usine à gaz'. Oracle ne fournis pas vraiment de truc pour trouver la volumétrie d'une base existante. Et encore moins, pour estimer à partir ce çà, la volumétrie d'une base future.
Je crois avoir finalement trouvé pour la taille utilisés par les tables :
dbms_utility.analyze_schema('schema1', 'compute') <--- Oracle 7 DBMS_STATS.GATHER_SCHEMA_STATS('PSEVR'); <--- Oracle 9 select tablespace_name, table_name, num_rows*avg_row_len "TAILLE OCCUPEE (octets)", 8192*blocks "nb block x block_size (octets)",initial_extent, next_extent, pct_free, pct_used,num_rows, blocks, empty_blocks, avg_space, avg_row_len from sys.dba_tables where tablespace_name like 'tbs1'
Par contre pour les INDEX ???????? Le contenus de sys.dba_indexes n'as pas l'air de faire l'affaire... Une idée (simple :-) ?
Avec TOAD 7.6 , tu as un modul qui calcule les volumétries pout les tables et les INDEX.
Bernard Segonnes a écrit :
Bonjour,
Tout est dans le titre.
Après avoir cherché des heures Le Script qui sort les tailles utilisée
par les tables & index, je pose ma question sur ce forum.
Rien n'a l'air d'être trés simple/clair sur Oracle (7 et 9). Tout le
monde à son script maison, un peux 'usine à gaz'. Oracle ne fournis
pas vraiment de truc pour trouver la volumétrie d'une base existante.
Et encore moins, pour estimer à partir ce çà, la volumétrie d'une base
future.
Je crois avoir finalement trouvé pour la taille utilisés par les
tables :
dbms_utility.analyze_schema('schema1', 'compute') <--- Oracle 7
DBMS_STATS.GATHER_SCHEMA_STATS('PSEVR'); <--- Oracle 9
select tablespace_name, table_name, num_rows*avg_row_len "TAILLE
OCCUPEE (octets)", 8192*blocks "nb block x block_size
(octets)",initial_extent, next_extent, pct_free, pct_used,num_rows,
blocks, empty_blocks, avg_space, avg_row_len from sys.dba_tables where
tablespace_name like 'tbs1'
Par contre pour les INDEX ????????
Le contenus de sys.dba_indexes n'as pas l'air de faire l'affaire...
Une idée (simple :-) ?
Avec TOAD 7.6 , tu as un modul qui calcule les volumétries pout les
tables et les INDEX.
Tout est dans le titre. Après avoir cherché des heures Le Script qui sort les tailles utilisée par les tables & index, je pose ma question sur ce forum.
Rien n'a l'air d'être trés simple/clair sur Oracle (7 et 9). Tout le monde à son script maison, un peux 'usine à gaz'. Oracle ne fournis pas vraiment de truc pour trouver la volumétrie d'une base existante. Et encore moins, pour estimer à partir ce çà, la volumétrie d'une base future.
Je crois avoir finalement trouvé pour la taille utilisés par les tables :
dbms_utility.analyze_schema('schema1', 'compute') <--- Oracle 7 DBMS_STATS.GATHER_SCHEMA_STATS('PSEVR'); <--- Oracle 9 select tablespace_name, table_name, num_rows*avg_row_len "TAILLE OCCUPEE (octets)", 8192*blocks "nb block x block_size (octets)",initial_extent, next_extent, pct_free, pct_used,num_rows, blocks, empty_blocks, avg_space, avg_row_len from sys.dba_tables where tablespace_name like 'tbs1'
Par contre pour les INDEX ???????? Le contenus de sys.dba_indexes n'as pas l'air de faire l'affaire... Une idée (simple :-) ?
Avec TOAD 7.6 , tu as un modul qui calcule les volumétries pout les tables et les INDEX.
see
Bernard Segonnes wrote:
Par contre pour les INDEX ????????
Tu trouveras plein d'informations très interessantes dans la vue index_stats.
Cette vue est alimentée par la commande : analyze index <index_name> validate structure;
A noter : - Il n'y a toujours qu'une seule ligne dans index_stats. Une nouvelle insertion efface l'ancienne. - La commande analyze ... validate structure pose un lock sur l'index ...
Je t'invite à regarder dans la documentation le détail des colonnes de cette vue index_stats mais tout y est ! N'hésite pas si tu veux des précisions.
Bernard Segonnes <bsegonnes@free.fr> wrote:
Par contre pour les INDEX ????????
Tu trouveras plein d'informations très interessantes dans la vue
index_stats.
Cette vue est alimentée par la commande :
analyze index <index_name> validate structure;
A noter :
- Il n'y a toujours qu'une seule ligne dans index_stats. Une nouvelle
insertion efface l'ancienne.
- La commande analyze ... validate structure pose un lock sur l'index
...
Je t'invite à regarder dans la documentation le détail des colonnes de
cette vue index_stats mais tout y est !
N'hésite pas si tu veux des précisions.
Tu trouveras plein d'informations très interessantes dans la vue index_stats.
Cette vue est alimentée par la commande : analyze index <index_name> validate structure;
A noter : - Il n'y a toujours qu'une seule ligne dans index_stats. Une nouvelle insertion efface l'ancienne. - La commande analyze ... validate structure pose un lock sur l'index ...
Je t'invite à regarder dans la documentation le détail des colonnes de cette vue index_stats mais tout y est ! N'hésite pas si tu veux des précisions.
bsegonnes
Tu trouveras plein d'informations très interessantes dans la vue index_stats.
Cette vue est alimentée par la commande : analyze index <index_name> validate structure;
A noter : - Il n'y a toujours qu'une seule ligne dans index_stats. Une nouvelle insertion efface l'ancienne. - La commande analyze ... validate structure pose un lock sur l'index ...
Je t'invite à regarder dans la documentation le détail des colonnes de cette vue index_stats mais tout y est ! N'hésite pas si tu veux des précisions.
Merci à tout les 2 pour vos réponses. J'utilise rlogion/telnet donc pas de Toad :-) La table INDEX_STATS à l'air de faire l'affaire (comme DBA_SEGMENTS). Mon pb c'est que je cherchais un nombre d'octets utilisés. Je voulais être trop précis.
En fait, on s'en fout ! Un nombre de blocks suffit pour faire une volumétrie et savoir ce qui va être pris dans le tablespace.
En fait, çà sert à rien de chercher des infos précises avec Oracle, de connaitre la place perdue dans les blocks, etc... Seul le nombre de block ALLOUE est utile.
Mais une question : Lors des ajouts dans les tables (nouvelle version du soft), on ne peux pas dire que l'on a besoin de disons 2 fois plus de blocks. Si çà se trouve les nouvelle données vont remplir la place libre dans les blocks existants... Pas évident de connaitre le nombre de blocks utile pour une future version d'un soft.....
Encore une question : une table/index peut-elle être divisé en plusieur segments ? Je ne maitrise par trop les segments... ?
Tu trouveras plein d'informations très interessantes dans la vue
index_stats.
Cette vue est alimentée par la commande :
analyze index <index_name> validate structure;
A noter :
- Il n'y a toujours qu'une seule ligne dans index_stats. Une nouvelle
insertion efface l'ancienne.
- La commande analyze ... validate structure pose un lock sur l'index
...
Je t'invite à regarder dans la documentation le détail des colonnes de
cette vue index_stats mais tout y est !
N'hésite pas si tu veux des précisions.
Merci à tout les 2 pour vos réponses.
J'utilise rlogion/telnet donc pas de Toad :-)
La table INDEX_STATS à l'air de faire l'affaire (comme DBA_SEGMENTS).
Mon pb c'est que je cherchais un nombre d'octets utilisés. Je voulais
être trop précis.
En fait, on s'en fout ! Un nombre de blocks suffit pour faire une
volumétrie et savoir ce qui va être pris dans le tablespace.
En fait, çà sert à rien de chercher des infos précises avec Oracle, de
connaitre la place perdue dans les blocks, etc... Seul le nombre de
block ALLOUE est utile.
Mais une question :
Lors des ajouts dans les tables (nouvelle version du soft), on ne peux
pas dire que l'on a besoin de disons 2 fois plus de blocks. Si çà se
trouve les nouvelle données vont remplir la place libre dans les
blocks existants... Pas évident de connaitre le nombre de blocks
utile pour une future version d'un soft.....
Encore une question : une table/index peut-elle être divisé en
plusieur segments ? Je ne maitrise par trop les segments... ?
Tu trouveras plein d'informations très interessantes dans la vue index_stats.
Cette vue est alimentée par la commande : analyze index <index_name> validate structure;
A noter : - Il n'y a toujours qu'une seule ligne dans index_stats. Une nouvelle insertion efface l'ancienne. - La commande analyze ... validate structure pose un lock sur l'index ...
Je t'invite à regarder dans la documentation le détail des colonnes de cette vue index_stats mais tout y est ! N'hésite pas si tu veux des précisions.
Merci à tout les 2 pour vos réponses. J'utilise rlogion/telnet donc pas de Toad :-) La table INDEX_STATS à l'air de faire l'affaire (comme DBA_SEGMENTS). Mon pb c'est que je cherchais un nombre d'octets utilisés. Je voulais être trop précis.
En fait, on s'en fout ! Un nombre de blocks suffit pour faire une volumétrie et savoir ce qui va être pris dans le tablespace.
En fait, çà sert à rien de chercher des infos précises avec Oracle, de connaitre la place perdue dans les blocks, etc... Seul le nombre de block ALLOUE est utile.
Mais une question : Lors des ajouts dans les tables (nouvelle version du soft), on ne peux pas dire que l'on a besoin de disons 2 fois plus de blocks. Si çà se trouve les nouvelle données vont remplir la place libre dans les blocks existants... Pas évident de connaitre le nombre de blocks utile pour une future version d'un soft.....
Encore une question : une table/index peut-elle être divisé en plusieur segments ? Je ne maitrise par trop les segments... ?
see
Bernard Segonnes wrote:
Lors des ajouts dans les tables (nouvelle version du soft), on ne peux pas dire que l'on a besoin de disons 2 fois plus de blocks. Si çà se trouve les nouvelle données vont remplir la place libre dans les blocks existants... Pas évident de connaitre le nombre de blocks utile pour une future version d'un soft.....
Par rapport aux calculs de volumétrie, il me parait totalement illusoire de chercher à calculer à l'octet prêt. De toute façon on n'arrive jamais à connaître le nombre de lignes qui seront insérées dans une table. Personnellement, dans mon travail de dba, tout ce qui m'intéresse est d'obtenir un ordre de grandeur du volume de la table : savoir si elle fera plutôt quelques Mo ou quelques Go. Le reste, d'expérience, c'est généralement pipeau. Pour une table, la valeur du hwm (blocks dans dba_tables) donne généralement une bonne estimation du volume occupé de la table. Autrement, tu peux toujours multiplier la longueur moyenne d'une ligne (avg_row_len dans dba_tables) par le nombre de lignes estimés dans la table. Tu ajoutes 20% au résultat obtenu et tu devrais avoir un chiffre pas trop loin de la réalité. Pour les index, le volume global du segment fait généralement l'affaire.
Les valeurs de la vue index_stats sont très utiles pour estimer si un rebuild de l'index est utile ou pas ou pour prendre des décisions dans le cadre d'une réorganisation plus globale. Le calcul de ces valeurs est tout de même très couteux. Il faut voir si cela en vaut la peine.
Les volumétries, c'est beaucoup de pifométrie. Si on sait qu'il va y avoir un chargement important de données, on essaie de tailler large et on espère que cela va passer ! Si on a taillé trop large, de toute façon, l'espace sera utilisé plus tard.
Encore une question : une table/index peut-elle être divisé en plusieur segments ? Je ne maitrise par trop les segments... ?
Une table/index peut être divisé en plusieurs segments avec l'utilisation des partitions. Mais la division d'une table ou index en plusieurs segments (ce qui correspond à un partionnement) est une opération volontaire. Une table/index classique correspond à un et un seul segment. Tous les objets qui prennent de la place sont des segments. Après, il y a plusieurs types de segment : table, index, rollback segment, cluster, .... Pour les volumétries, la vue dba_segments est donc importante.
Bernard Segonnes <bsegonnes@free.fr> wrote:
Lors des ajouts dans les tables (nouvelle version du soft), on ne peux
pas dire que l'on a besoin de disons 2 fois plus de blocks. Si çà se
trouve les nouvelle données vont remplir la place libre dans les
blocks existants... Pas évident de connaitre le nombre de blocks
utile pour une future version d'un soft.....
Par rapport aux calculs de volumétrie, il me parait totalement illusoire
de chercher à calculer à l'octet prêt. De toute façon on n'arrive jamais
à connaître le nombre de lignes qui seront insérées dans une table.
Personnellement, dans mon travail de dba, tout ce qui m'intéresse est
d'obtenir un ordre de grandeur du volume de la table : savoir si elle
fera plutôt quelques Mo ou quelques Go. Le reste, d'expérience, c'est
généralement pipeau.
Pour une table, la valeur du hwm (blocks dans dba_tables) donne
généralement une bonne estimation du volume occupé de la table.
Autrement, tu peux toujours multiplier la longueur moyenne d'une ligne
(avg_row_len dans dba_tables) par le nombre de lignes estimés dans la
table. Tu ajoutes 20% au résultat obtenu et tu devrais avoir un chiffre
pas trop loin de la réalité.
Pour les index, le volume global du segment fait généralement l'affaire.
Les valeurs de la vue index_stats sont très utiles pour estimer si un
rebuild de l'index est utile ou pas ou pour prendre des décisions dans
le cadre d'une réorganisation plus globale.
Le calcul de ces valeurs est tout de même très couteux. Il faut voir si
cela en vaut la peine.
Les volumétries, c'est beaucoup de pifométrie. Si on sait qu'il va y
avoir un chargement important de données, on essaie de tailler large et
on espère que cela va passer ! Si on a taillé trop large, de toute
façon, l'espace sera utilisé plus tard.
Encore une question : une table/index peut-elle être divisé en
plusieur segments ? Je ne maitrise par trop les segments... ?
Une table/index peut être divisé en plusieurs segments avec
l'utilisation des partitions. Mais la division d'une table ou index en
plusieurs segments (ce qui correspond à un partionnement) est une
opération volontaire. Une table/index classique correspond à un et un
seul segment.
Tous les objets qui prennent de la place sont des segments. Après, il y
a plusieurs types de segment : table, index, rollback segment, cluster,
.... Pour les volumétries, la vue dba_segments est donc importante.
Lors des ajouts dans les tables (nouvelle version du soft), on ne peux pas dire que l'on a besoin de disons 2 fois plus de blocks. Si çà se trouve les nouvelle données vont remplir la place libre dans les blocks existants... Pas évident de connaitre le nombre de blocks utile pour une future version d'un soft.....
Par rapport aux calculs de volumétrie, il me parait totalement illusoire de chercher à calculer à l'octet prêt. De toute façon on n'arrive jamais à connaître le nombre de lignes qui seront insérées dans une table. Personnellement, dans mon travail de dba, tout ce qui m'intéresse est d'obtenir un ordre de grandeur du volume de la table : savoir si elle fera plutôt quelques Mo ou quelques Go. Le reste, d'expérience, c'est généralement pipeau. Pour une table, la valeur du hwm (blocks dans dba_tables) donne généralement une bonne estimation du volume occupé de la table. Autrement, tu peux toujours multiplier la longueur moyenne d'une ligne (avg_row_len dans dba_tables) par le nombre de lignes estimés dans la table. Tu ajoutes 20% au résultat obtenu et tu devrais avoir un chiffre pas trop loin de la réalité. Pour les index, le volume global du segment fait généralement l'affaire.
Les valeurs de la vue index_stats sont très utiles pour estimer si un rebuild de l'index est utile ou pas ou pour prendre des décisions dans le cadre d'une réorganisation plus globale. Le calcul de ces valeurs est tout de même très couteux. Il faut voir si cela en vaut la peine.
Les volumétries, c'est beaucoup de pifométrie. Si on sait qu'il va y avoir un chargement important de données, on essaie de tailler large et on espère que cela va passer ! Si on a taillé trop large, de toute façon, l'espace sera utilisé plus tard.
Encore une question : une table/index peut-elle être divisé en plusieur segments ? Je ne maitrise par trop les segments... ?
Une table/index peut être divisé en plusieurs segments avec l'utilisation des partitions. Mais la division d'une table ou index en plusieurs segments (ce qui correspond à un partionnement) est une opération volontaire. Une table/index classique correspond à un et un seul segment. Tous les objets qui prennent de la place sont des segments. Après, il y a plusieurs types de segment : table, index, rollback segment, cluster, .... Pour les volumétries, la vue dba_segments est donc importante.
bsegonnes
Personnellement, dans mon travail de dba, tout ce qui m'intéresse est d'obtenir un ordre de grandeur du volume de la table : savoir si elle fera plutôt quelques Mo ou quelques Go. Le reste, d'expérience, c'est généralement pipeau.
Ouais, mais quand t'as un document à remettre à un client pour justifier tas tailles (TBS), il faut préciser un minimum...
Pour une table, la valeur du hwm (blocks dans dba_tables) donne généralement une bonne estimation du volume occupé de la table. Pour les index, le volume global du segment fait généralement l'affaire.
Pourquoi ne pas se baser sur les infos (BLOCKS) dans DBA_SEGMENTS à la fois pour les tables & index ?
En fait, on veux juste savoir la tailles des segments (nb de blocks). si la prochaine version de la base doit avoir une table 2 fois plus grosse, on multiplie ce nombre de blocks par 2. Bien sur dans la base existante, des blocks peuvent être partiellement vide, et on pourrais penser qu'ils se remplissent plus tard. Mais à mon avis, plus tard de nouveaux blocks (partiellementà vides eux aussi) seront alloués...
Les valeurs de la vue index_stats sont très utiles pour estimer si un rebuild de l'index est utile ou pas ou pour prendre des décisions dans
Je suis un développeur qui est sur un document de volumétrie + script de création de base. Je ne suis pas un DBA qui se demande s'il faut agrandir/optimiser une base. Donc les rebuild des index je m'en f... :-)
Les volumétries, c'est beaucoup de pifométrie. Si on sait qu'il va y
T'as une réf. d'un bouquin où ils indiquent cette méthode :-) ? J'en aurais besoin pour expliquer au client...
Merci, çà me réconforte que tu confirmes que dans Oracle il n'y a rien de précis pour ce genre de pb. J'ai cherché des heures sur le web + pdf de CD d'Oracle, et n'est rien trouvé de clair, simple et répondant vraiment à mes besoins.
Je suis currieux de savoir si Sybase, mySQL, DB2,... sont mieux en ce qui concerne les stats sur les tables/index, et s'il y a des formules qui marchent pour en déduire la taille d'une nouvelle base basée sur l'existant (avec qques modif bien sur)
Personnellement, dans mon travail de dba, tout ce qui m'intéresse est
d'obtenir un ordre de grandeur du volume de la table : savoir si elle
fera plutôt quelques Mo ou quelques Go. Le reste, d'expérience, c'est
généralement pipeau.
Ouais, mais quand t'as un document à remettre à un client pour
justifier tas tailles (TBS), il faut préciser un minimum...
Pour une table, la valeur du hwm (blocks dans dba_tables) donne
généralement une bonne estimation du volume occupé de la table.
Pour les index, le volume global du segment fait généralement l'affaire.
Pourquoi ne pas se baser sur les infos (BLOCKS) dans DBA_SEGMENTS à la
fois pour les tables & index ?
En fait, on veux juste savoir la tailles des segments (nb de blocks).
si la prochaine version de la base doit avoir une table 2 fois plus
grosse, on multiplie ce nombre de blocks par 2. Bien sur dans la base
existante, des blocks peuvent être partiellement vide, et on pourrais
penser qu'ils se remplissent plus tard. Mais à mon avis, plus tard de
nouveaux blocks (partiellementà vides eux aussi) seront alloués...
Les valeurs de la vue index_stats sont très utiles pour estimer si un
rebuild de l'index est utile ou pas ou pour prendre des décisions dans
Je suis un développeur qui est sur un document de volumétrie + script
de création de base. Je ne suis pas un DBA qui se demande s'il faut
agrandir/optimiser une base. Donc les rebuild des index je m'en f...
:-)
Les volumétries, c'est beaucoup de pifométrie. Si on sait qu'il va y
T'as une réf. d'un bouquin où ils indiquent cette méthode :-) ?
J'en aurais besoin pour expliquer au client...
Merci, çà me réconforte que tu confirmes que dans Oracle il n'y a rien
de précis pour ce genre de pb. J'ai cherché des heures sur le web +
pdf de CD d'Oracle, et n'est rien trouvé de clair, simple et répondant
vraiment à mes besoins.
Je suis currieux de savoir si Sybase, mySQL, DB2,... sont mieux en ce
qui concerne les stats sur les tables/index, et s'il y a des formules
qui marchent pour en déduire la taille d'une nouvelle base basée sur
l'existant (avec qques modif bien sur)
Personnellement, dans mon travail de dba, tout ce qui m'intéresse est d'obtenir un ordre de grandeur du volume de la table : savoir si elle fera plutôt quelques Mo ou quelques Go. Le reste, d'expérience, c'est généralement pipeau.
Ouais, mais quand t'as un document à remettre à un client pour justifier tas tailles (TBS), il faut préciser un minimum...
Pour une table, la valeur du hwm (blocks dans dba_tables) donne généralement une bonne estimation du volume occupé de la table. Pour les index, le volume global du segment fait généralement l'affaire.
Pourquoi ne pas se baser sur les infos (BLOCKS) dans DBA_SEGMENTS à la fois pour les tables & index ?
En fait, on veux juste savoir la tailles des segments (nb de blocks). si la prochaine version de la base doit avoir une table 2 fois plus grosse, on multiplie ce nombre de blocks par 2. Bien sur dans la base existante, des blocks peuvent être partiellement vide, et on pourrais penser qu'ils se remplissent plus tard. Mais à mon avis, plus tard de nouveaux blocks (partiellementà vides eux aussi) seront alloués...
Les valeurs de la vue index_stats sont très utiles pour estimer si un rebuild de l'index est utile ou pas ou pour prendre des décisions dans
Je suis un développeur qui est sur un document de volumétrie + script de création de base. Je ne suis pas un DBA qui se demande s'il faut agrandir/optimiser une base. Donc les rebuild des index je m'en f... :-)
Les volumétries, c'est beaucoup de pifométrie. Si on sait qu'il va y
T'as une réf. d'un bouquin où ils indiquent cette méthode :-) ? J'en aurais besoin pour expliquer au client...
Merci, çà me réconforte que tu confirmes que dans Oracle il n'y a rien de précis pour ce genre de pb. J'ai cherché des heures sur le web + pdf de CD d'Oracle, et n'est rien trouvé de clair, simple et répondant vraiment à mes besoins.
Je suis currieux de savoir si Sybase, mySQL, DB2,... sont mieux en ce qui concerne les stats sur les tables/index, et s'il y a des formules qui marchent pour en déduire la taille d'une nouvelle base basée sur l'existant (avec qques modif bien sur)
see
Bernard Segonnes wrote:
> Pour une table, la valeur du hwm (blocks dans dba_tables) donne > généralement une bonne estimation du volume occupé de la table. > Pour les index, le volume global du segment fait généralement l'affaire. Pourquoi ne pas se baser sur les infos (BLOCKS) dans DBA_SEGMENTS à la fois pour les tables & index ?
Je ne t'ai pas indiqué cette solution car j'ai déjà vu des tables qui font 1 Go et qui ne contenait que 100 Mo de données. Dans ce cas, la méthode n'est pas sans conséquence ... Tout dépend de comment sont calculés les extents. Si vous avez cédé à l'obsession de "tout dans un seul extent", alors la valeur de blocks dans dba_segments risque de ne pas être significative. Si vous n'avez pas cette obsession, alors oui, la valeur de blocks pourra être significative.
C'est difficile de répondre sans connaître les particularités d'un site. La méthode simple (blocks ou bytes dans dba_segments) pourra donner des résultats tout à fait correcte ou aberrant. La méthode plus compliquée (blocks dans dba_tables après un analyze) donnera un résultat correcte dans tout les cas.
En fait, on veux juste savoir la tailles des segments (nb de blocks). si la prochaine version de la base doit avoir une table 2 fois plus grosse, on multiplie ce nombre de blocks par 2. Bien sur dans la base existante, des blocks peuvent être partiellement vide, et on pourrais penser qu'ils se remplissent plus tard. Mais à mon avis, plus tard de nouveaux blocks (partiellementà vides eux aussi) seront alloués...
Tu ne peux pas te contenter d'indiquer l'évolution en terme de nombre de lignes dans les tables ? Cela suffira au dba pour qu'il fasse une estimation des besoins en terme de volumétrie. Tu connais l'évolution en terme de lignes, n'est-ce pas ?
> Les volumétries, c'est beaucoup de pifométrie. Si on sait qu'il va y T'as une réf. d'un bouquin où ils indiquent cette méthode :-) ? J'en aurais besoin pour expliquer au client...
Merci, çà me réconforte que tu confirmes que dans Oracle il n'y a rien de précis pour ce genre de pb. J'ai cherché des heures sur le web + pdf de CD d'Oracle, et n'est rien trouvé de clair, simple et répondant vraiment à mes besoins.
Oracle donnait dans la doc "Oracle Concept" des formules précises pour calculer la volumétrie d'une table ou d'un index. Ceci jusqu'à la version 8. Pour les versions suivantes, ces pages ont disparues ! Ils justifient la disparition par la complexité du calcul et que de toute façon, des calculs approximatifs (taille d'une ligne * nombres de lignes) faisaient très bien l'affaire. J'ai tendance à approuver.
Mais n'exagérons pas, je pense quand même t'avoir indiqué des méthodes pour estimer la volumétrie.
Bernard Segonnes <bsegonnes@free.fr> wrote:
> Pour une table, la valeur du hwm (blocks dans dba_tables) donne
> généralement une bonne estimation du volume occupé de la table.
> Pour les index, le volume global du segment fait généralement l'affaire.
Pourquoi ne pas se baser sur les infos (BLOCKS) dans DBA_SEGMENTS à la
fois pour les tables & index ?
Je ne t'ai pas indiqué cette solution car j'ai déjà vu des tables qui
font 1 Go et qui ne contenait que 100 Mo de données. Dans ce cas, la
méthode n'est pas sans conséquence ...
Tout dépend de comment sont calculés les extents. Si vous avez cédé à
l'obsession de "tout dans un seul extent", alors la valeur de blocks
dans dba_segments risque de ne pas être significative. Si vous n'avez
pas cette obsession, alors oui, la valeur de blocks pourra être
significative.
C'est difficile de répondre sans connaître les particularités d'un site.
La méthode simple (blocks ou bytes dans dba_segments) pourra donner des
résultats tout à fait correcte ou aberrant.
La méthode plus compliquée (blocks dans dba_tables après un analyze)
donnera un résultat correcte dans tout les cas.
En fait, on veux juste savoir la tailles des segments (nb de blocks).
si la prochaine version de la base doit avoir une table 2 fois plus
grosse, on multiplie ce nombre de blocks par 2. Bien sur dans la base
existante, des blocks peuvent être partiellement vide, et on pourrais
penser qu'ils se remplissent plus tard. Mais à mon avis, plus tard de
nouveaux blocks (partiellementà vides eux aussi) seront alloués...
Tu ne peux pas te contenter d'indiquer l'évolution en terme de nombre de
lignes dans les tables ?
Cela suffira au dba pour qu'il fasse une estimation des besoins en terme
de volumétrie.
Tu connais l'évolution en terme de lignes, n'est-ce pas ?
> Les volumétries, c'est beaucoup de pifométrie. Si on sait qu'il va y
T'as une réf. d'un bouquin où ils indiquent cette méthode :-) ?
J'en aurais besoin pour expliquer au client...
Merci, çà me réconforte que tu confirmes que dans Oracle il n'y a rien
de précis pour ce genre de pb. J'ai cherché des heures sur le web +
pdf de CD d'Oracle, et n'est rien trouvé de clair, simple et répondant
vraiment à mes besoins.
Oracle donnait dans la doc "Oracle Concept" des formules précises pour
calculer la volumétrie d'une table ou d'un index. Ceci jusqu'à la
version 8. Pour les versions suivantes, ces pages ont disparues ! Ils
justifient la disparition par la complexité du calcul et que de toute
façon, des calculs approximatifs (taille d'une ligne * nombres de
lignes) faisaient très bien l'affaire. J'ai tendance à approuver.
Mais n'exagérons pas, je pense quand même t'avoir indiqué des méthodes
pour estimer la volumétrie.
> Pour une table, la valeur du hwm (blocks dans dba_tables) donne > généralement une bonne estimation du volume occupé de la table. > Pour les index, le volume global du segment fait généralement l'affaire. Pourquoi ne pas se baser sur les infos (BLOCKS) dans DBA_SEGMENTS à la fois pour les tables & index ?
Je ne t'ai pas indiqué cette solution car j'ai déjà vu des tables qui font 1 Go et qui ne contenait que 100 Mo de données. Dans ce cas, la méthode n'est pas sans conséquence ... Tout dépend de comment sont calculés les extents. Si vous avez cédé à l'obsession de "tout dans un seul extent", alors la valeur de blocks dans dba_segments risque de ne pas être significative. Si vous n'avez pas cette obsession, alors oui, la valeur de blocks pourra être significative.
C'est difficile de répondre sans connaître les particularités d'un site. La méthode simple (blocks ou bytes dans dba_segments) pourra donner des résultats tout à fait correcte ou aberrant. La méthode plus compliquée (blocks dans dba_tables après un analyze) donnera un résultat correcte dans tout les cas.
En fait, on veux juste savoir la tailles des segments (nb de blocks). si la prochaine version de la base doit avoir une table 2 fois plus grosse, on multiplie ce nombre de blocks par 2. Bien sur dans la base existante, des blocks peuvent être partiellement vide, et on pourrais penser qu'ils se remplissent plus tard. Mais à mon avis, plus tard de nouveaux blocks (partiellementà vides eux aussi) seront alloués...
Tu ne peux pas te contenter d'indiquer l'évolution en terme de nombre de lignes dans les tables ? Cela suffira au dba pour qu'il fasse une estimation des besoins en terme de volumétrie. Tu connais l'évolution en terme de lignes, n'est-ce pas ?
> Les volumétries, c'est beaucoup de pifométrie. Si on sait qu'il va y T'as une réf. d'un bouquin où ils indiquent cette méthode :-) ? J'en aurais besoin pour expliquer au client...
Merci, çà me réconforte que tu confirmes que dans Oracle il n'y a rien de précis pour ce genre de pb. J'ai cherché des heures sur le web + pdf de CD d'Oracle, et n'est rien trouvé de clair, simple et répondant vraiment à mes besoins.
Oracle donnait dans la doc "Oracle Concept" des formules précises pour calculer la volumétrie d'une table ou d'un index. Ceci jusqu'à la version 8. Pour les versions suivantes, ces pages ont disparues ! Ils justifient la disparition par la complexité du calcul et que de toute façon, des calculs approximatifs (taille d'une ligne * nombres de lignes) faisaient très bien l'affaire. J'ai tendance à approuver.
Mais n'exagérons pas, je pense quand même t'avoir indiqué des méthodes pour estimer la volumétrie.
