J'ai besoin d'optimiser une table, car elle devient de plus en plus
grosse (17,5 G) alors que le nombre de donn=E9es dans la table est
relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans
cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal
(10,2)), il devrait y avoir une moyenne d'environ 25 millions de
lignes dedans. Nous conservons 7 jours roulants de donn=E9es dans cette
table. Apr=E8s 7 jours nous les supprimons de la table. Donc, les
transactions se r=E9sument =E0 ceci. Au cours de l'avant-midi, plusieurs
insertions, tout au long de la journ=E9e, de nombreuses s=E9lections et en
soir=E9e, lorsque la bd n'est plus occup=E9e, suppression des donn=E9es
d=E9pass=E9es 7 jours. Jamais de mises =E0 jour. L'index fait 13.5 G. Il me
semble que quelque chose ne tourne pas rond. Il y a un index PK
(Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index
IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes
croisant.
il semble qu'une table partitionnée serait indiquée dans ce cas (edition enterprise). Une partition par jour.
BR
"orange" wrote in message news: Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus grosse (17,5 G) alors que le nombre de données dans la table est relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal (10,2)), il devrait y avoir une moyenne d'environ 25 millions de lignes dedans. Nous conservons 7 jours roulants de données dans cette table. Après 7 jours nous les supprimons de la table. Donc, les transactions se résument à ceci. Au cours de l'avant-midi, plusieurs insertions, tout au long de la journée, de nombreuses sélections et en soirée, lorsque la bd n'est plus occupée, suppression des données dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me semble que quelque chose ne tourne pas rond. Il y a un index PK (Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes croisant.
Merci d'avance pour votre aide.
Charles
il semble qu'une table partitionnée serait indiquée dans ce cas (edition
enterprise).
Une partition par jour.
BR
"orange" <cm.mathieu@gmail.com> wrote in message
news:63e0bb14-5c62-4a77-a3de-204d9cbd08d4@m18g2000vbi.googlegroups.com...
Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus
grosse (17,5 G) alors que le nombre de données dans la table est
relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans
cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal
(10,2)), il devrait y avoir une moyenne d'environ 25 millions de
lignes dedans. Nous conservons 7 jours roulants de données dans cette
table. Après 7 jours nous les supprimons de la table. Donc, les
transactions se résument à ceci. Au cours de l'avant-midi, plusieurs
insertions, tout au long de la journée, de nombreuses sélections et en
soirée, lorsque la bd n'est plus occupée, suppression des données
dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me
semble que quelque chose ne tourne pas rond. Il y a un index PK
(Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index
IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes
croisant.
il semble qu'une table partitionnée serait indiquée dans ce cas (edition enterprise). Une partition par jour.
BR
"orange" wrote in message news: Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus grosse (17,5 G) alors que le nombre de données dans la table est relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal (10,2)), il devrait y avoir une moyenne d'environ 25 millions de lignes dedans. Nous conservons 7 jours roulants de données dans cette table. Après 7 jours nous les supprimons de la table. Donc, les transactions se résument à ceci. Au cours de l'avant-midi, plusieurs insertions, tout au long de la journée, de nombreuses sélections et en soirée, lorsque la bd n'est plus occupée, suppression des données dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me semble que quelque chose ne tourne pas rond. Il y a un index PK (Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes croisant.
Merci d'avance pour votre aide.
Charles
bruno reiter
autre chose, pourquoi un index sur ID, NUMEROPAS si le cluster est sur ID, NUMEROPAS? ça fait double emploi. et est-ce que les index sont reconstruits régulièrement?
BR
"orange" wrote in message news: Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus grosse (17,5 G) alors que le nombre de données dans la table est relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal (10,2)), il devrait y avoir une moyenne d'environ 25 millions de lignes dedans. Nous conservons 7 jours roulants de données dans cette table. Après 7 jours nous les supprimons de la table. Donc, les transactions se résument à ceci. Au cours de l'avant-midi, plusieurs insertions, tout au long de la journée, de nombreuses sélections et en soirée, lorsque la bd n'est plus occupée, suppression des données dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me semble que quelque chose ne tourne pas rond. Il y a un index PK (Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes croisant.
Merci d'avance pour votre aide.
Charles
autre chose, pourquoi un index sur ID, NUMEROPAS si le cluster est sur ID,
NUMEROPAS? ça fait double emploi.
et est-ce que les index sont reconstruits régulièrement?
BR
"orange" <cm.mathieu@gmail.com> wrote in message
news:63e0bb14-5c62-4a77-a3de-204d9cbd08d4@m18g2000vbi.googlegroups.com...
Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus
grosse (17,5 G) alors que le nombre de données dans la table est
relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans
cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal
(10,2)), il devrait y avoir une moyenne d'environ 25 millions de
lignes dedans. Nous conservons 7 jours roulants de données dans cette
table. Après 7 jours nous les supprimons de la table. Donc, les
transactions se résument à ceci. Au cours de l'avant-midi, plusieurs
insertions, tout au long de la journée, de nombreuses sélections et en
soirée, lorsque la bd n'est plus occupée, suppression des données
dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me
semble que quelque chose ne tourne pas rond. Il y a un index PK
(Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index
IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes
croisant.
autre chose, pourquoi un index sur ID, NUMEROPAS si le cluster est sur ID, NUMEROPAS? ça fait double emploi. et est-ce que les index sont reconstruits régulièrement?
BR
"orange" wrote in message news: Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus grosse (17,5 G) alors que le nombre de données dans la table est relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal (10,2)), il devrait y avoir une moyenne d'environ 25 millions de lignes dedans. Nous conservons 7 jours roulants de données dans cette table. Après 7 jours nous les supprimons de la table. Donc, les transactions se résument à ceci. Au cours de l'avant-midi, plusieurs insertions, tout au long de la journée, de nombreuses sélections et en soirée, lorsque la bd n'est plus occupée, suppression des données dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me semble que quelque chose ne tourne pas rond. Il y a un index PK (Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes croisant.
Merci d'avance pour votre aide.
Charles
orange
Bonjour M. Reiter,
Nous n'avons pas de DBA spécifiquement pour notre base de données. Une autre personne et moi essayons du mieux que nous pouvons à maintenir et optimiser la base de données. On apprend graduellement. De ce que je comprends de votre dernier message, l'index sur ID, NUMEROPAS n'est qu'une redondance, elle ne sert à rien en soit puisqu'il n'y en a un identique sur le cluster. Je devrais donc pouvoir le supprimer. Nous avons 2 autres tables avec la même structure, mais contenant des données à pas de temps différents. Celle qui pose problème contient des données journalières. Une deuxième table contient des données hebdomadaires et une troisième contient des données mensuelles. J'ai remarqué qu'elles n'ont qu'un cluster (ID, NUMEROPAS) sur chacune d'elle.
Pour ce qui est des tâches d'optimisations, il y a une job qui optimise la base de données toutes les fins de semaine. Compactage et réindexation. Une sauvegarde est faite tous les soirs.
Ce matin, l'index fait 18G alors que la table fait 17G.
Charles
Bonjour M. Reiter,
Nous n'avons pas de DBA spécifiquement pour notre base de données. Une
autre personne et moi essayons du mieux que nous pouvons à maintenir
et optimiser la base de données. On apprend graduellement. De ce que
je comprends de votre dernier message, l'index sur ID, NUMEROPAS n'est
qu'une redondance, elle ne sert à rien en soit puisqu'il n'y en a un
identique sur le cluster. Je devrais donc pouvoir le supprimer. Nous
avons 2 autres tables avec la même structure, mais contenant des
données à pas de temps différents. Celle qui pose problème contient
des données journalières. Une deuxième table contient des données
hebdomadaires et une troisième contient des données mensuelles. J'ai
remarqué qu'elles n'ont qu'un cluster (ID, NUMEROPAS) sur chacune
d'elle.
Pour ce qui est des tâches d'optimisations, il y a une job qui
optimise la base de données toutes les fins de semaine. Compactage et
réindexation. Une sauvegarde est faite tous les soirs.
Ce matin, l'index fait 18G alors que la table fait 17G.
Nous n'avons pas de DBA spécifiquement pour notre base de données. Une autre personne et moi essayons du mieux que nous pouvons à maintenir et optimiser la base de données. On apprend graduellement. De ce que je comprends de votre dernier message, l'index sur ID, NUMEROPAS n'est qu'une redondance, elle ne sert à rien en soit puisqu'il n'y en a un identique sur le cluster. Je devrais donc pouvoir le supprimer. Nous avons 2 autres tables avec la même structure, mais contenant des données à pas de temps différents. Celle qui pose problème contient des données journalières. Une deuxième table contient des données hebdomadaires et une troisième contient des données mensuelles. J'ai remarqué qu'elles n'ont qu'un cluster (ID, NUMEROPAS) sur chacune d'elle.
Pour ce qui est des tâches d'optimisations, il y a une job qui optimise la base de données toutes les fins de semaine. Compactage et réindexation. Une sauvegarde est faite tous les soirs.
Ce matin, l'index fait 18G alors que la table fait 17G.
Charles
Fred BROUARD
Mettre deux index (la clef primaire genère un index) sur les mêmes colonnes ne sert à rien, ci ce n'est qu'au doubler artificiellement le volume de vos données.
A +
orange a écrit :
Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus grosse (17,5 G) alors que le nombre de données dans la table est relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal (10,2)), il devrait y avoir une moyenne d'environ 25 millions de lignes dedans. Nous conservons 7 jours roulants de données dans cette table. Après 7 jours nous les supprimons de la table. Donc, les transactions se résument à ceci. Au cours de l'avant-midi, plusieurs insertions, tout au long de la journée, de nombreuses sélections et en soirée, lorsque la bd n'est plus occupée, suppression des données dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me semble que quelque chose ne tourne pas rond. Il y a un index PK (Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes croisant.
Merci d'avance pour votre aide.
Charles
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************
Mettre deux index (la clef primaire genère un index) sur les mêmes
colonnes ne sert à rien, ci ce n'est qu'au doubler artificiellement le
volume de vos données.
A +
orange a écrit :
Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus
grosse (17,5 G) alors que le nombre de données dans la table est
relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans
cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal
(10,2)), il devrait y avoir une moyenne d'environ 25 millions de
lignes dedans. Nous conservons 7 jours roulants de données dans cette
table. Après 7 jours nous les supprimons de la table. Donc, les
transactions se résument à ceci. Au cours de l'avant-midi, plusieurs
insertions, tout au long de la journée, de nombreuses sélections et en
soirée, lorsque la bd n'est plus occupée, suppression des données
dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me
semble que quelque chose ne tourne pas rond. Il y a un index PK
(Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index
IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes
croisant.
Merci d'avance pour votre aide.
Charles
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Mettre deux index (la clef primaire genère un index) sur les mêmes colonnes ne sert à rien, ci ce n'est qu'au doubler artificiellement le volume de vos données.
A +
orange a écrit :
Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus grosse (17,5 G) alors que le nombre de données dans la table est relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal (10,2)), il devrait y avoir une moyenne d'environ 25 millions de lignes dedans. Nous conservons 7 jours roulants de données dans cette table. Après 7 jours nous les supprimons de la table. Donc, les transactions se résument à ceci. Au cours de l'avant-midi, plusieurs insertions, tout au long de la journée, de nombreuses sélections et en soirée, lorsque la bd n'est plus occupée, suppression des données dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me semble que quelque chose ne tourne pas rond. Il y a un index PK (Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes croisant.
Merci d'avance pour votre aide.
Charles
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************
laarif
orange a écrit le 20/07/2009 à 18h55 :
Bonjour à vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus grosse (17,5 G) alors que le nombre de données dans la table est relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal (10,2)), il devrait y avoir une moyenne d'environ 25 millions de lignes dedans. Nous conservons 7 jours roulants de données dans cette table. Après 7 jours nous les supprimons de la table. Donc, les transactions se résument à ceci. Au cours de l'avant-midi, plusieurs insertions, tout au long de la journée, de nombreuses sélections et en soirée, lorsque la bd n'est plus occupée, suppression des données dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me semble que quelque chose ne tourne pas rond. Il y a un index PK (Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes croisant.
Merci d'avance pour votre aide.
Charles
essayer de reindexer vos tables avant de compacter
orange a écrit le 20/07/2009 à 18h55 :
Bonjour =E0 vous tous,
J'ai besoin d'optimiser une table, car elle devient de plus en plus
grosse (17,5 G) alors que le nombre de donn=E9es dans la table est
relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans
cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal
(10,2)), il devrait y avoir une moyenne d'environ 25 millions de
lignes dedans. Nous conservons 7 jours roulants de donn=E9es dans cette
table. Apr=E8s 7 jours nous les supprimons de la table. Donc, les
transactions se r=E9sument =E0 ceci. Au cours de l'avant-midi, plusieurs
insertions, tout au long de la journ=E9e, de nombreuses s=E9lections et en
soir=E9e, lorsque la bd n'est plus occup=E9e, suppression des donn=E9es
d=E9pass=E9es 7 jours. Jamais de mises =E0 jour. L'index fait 13.5 G. Il me
semble que quelque chose ne tourne pas rond. Il y a un index PK
(Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index
IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes
croisant.
Merci d'avance pour votre aide.
Charles
essayer de reindexer vos tables avant de compacter
J'ai besoin d'optimiser une table, car elle devient de plus en plus grosse (17,5 G) alors que le nombre de données dans la table est relativement stable. Il y a un peu plus d'un an, elle faisait 8G. Dans cette table de trois colonnes (ID int, NUMEROPAS int, VALEUR decimal (10,2)), il devrait y avoir une moyenne d'environ 25 millions de lignes dedans. Nous conservons 7 jours roulants de données dans cette table. Après 7 jours nous les supprimons de la table. Donc, les transactions se résument à ceci. Au cours de l'avant-midi, plusieurs insertions, tout au long de la journée, de nombreuses sélections et en soirée, lorsque la bd n'est plus occupée, suppression des données dépassées 7 jours. Jamais de mises à jour. L'index fait 13.5 G. Il me semble que quelque chose ne tourne pas rond. Il y a un index PK (Cluster) sur ID, NUMEROPAS, les deux colonnes croisant et un index IDX (unique, non-cluster) sur ID, NUMEROPAS, les deux colonnes croisant.
Merci d'avance pour votre aide.
Charles
essayer de reindexer vos tables avant de compacter
