bonjour , j'ai ete confronté recemment au probleme suivant :
J'ai mis en place un archivage de certaines tables d'une base qui devient
assez volumineuse , j'ai donc crée une autre base ARCHIVES et j'y ai
transferé les enregistrements anterieurs a 12 mois dans des tables ayant la
meme structure que dans la base de production .
Certains utilisateurs ont besoin d'acceder a la fois a des enregistrements
recents et anterieurs a 12 mois !! , j'ai donc crée pour ces users des vues
de ce type
Select champ1, champ2 , ... , champs n from baseProd..table1
union
Select champ1, champ2, ...., champs n frombaseArchives..table1
(ainsi ils pourront acceder a tous les enregistrmeents de facon transparente)
j'ai aussi indexé les tables de archives exactement comme en prod .
Le resultat c'est que lorsqu'on interroge la vue (select ... from vue where
date < ..)
c'est tres lent....
Le plan d'execution de la requete interrogeant la vue est composé de
parcours d'indexes avec la mention (statistiques manquantes) et un operateur
HASH MATCH UNION (87%)
Y a til un moyen pour optimiser une telle requete ?
Avez vous deja eu a archiver et a fournir un accées aux tables entre deux
bases
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
Rudi Bruchez
hch a écrit:
Y a til un moyen pour optimiser une telle requete ?
Bonjour,
Une requête avec un opérateur > ou < a de bonnes chances d'être lente, elle peut facilement générer un scan. Quelques principes : - Au lieu d'UNION, utilise UNION ALL, cela t'économise l'exclusion des doublons; - Dans chaque table sous-jacente, ajoute une contrainte CHECK sur la date, pour limiter les enregistrements selon la plage de date choisie, cela permet à l'optimiseur de savoir qu'il n'a pas besoin de scanner une table parce qu'elle ne contiendra pas les données recherchées; - indexe la colonne date si ce n'est pas fait; - pour les colonnes où les statistiques sont manquantes, fais un CREATE STATISTICS. Vérifie que tes bases ont l'option AUTO_CREATE_STATSTICS et AUTO_UPDATE_STATISTICS à ON (tu peux lire mon article sur les statistiques: http://rudi.developpez.com/sqlserver/tutoriel/statistiques/) - si tu es sur SQL Server 2005, tu peux songer à créer une table partitionnée http://www.microsoft.com/france/technet/produits/sql/2005/20050519_tables_index_sqlserver2005.mspx
-- Rudi Bruchez Consultant indépendant modélisation, administration, optimisation, Solutions MS SQL Server et informatique libre. MCDBA, MCT, SCJP2 http://www.babaluga.com/ http://rudi.developpez.com/
hch a écrit:
Y a til un moyen pour optimiser une telle requete ?
Bonjour,
Une requête avec un opérateur > ou < a de bonnes chances d'être lente, elle
peut facilement générer un scan.
Quelques principes :
- Au lieu d'UNION, utilise UNION ALL, cela t'économise l'exclusion des
doublons;
- Dans chaque table sous-jacente, ajoute une contrainte CHECK sur la date,
pour limiter les enregistrements selon la plage de date choisie, cela
permet à l'optimiseur de savoir qu'il n'a pas besoin de scanner une table
parce qu'elle ne contiendra pas les données recherchées;
- indexe la colonne date si ce n'est pas fait;
- pour les colonnes où les statistiques sont manquantes, fais un CREATE
STATISTICS. Vérifie que tes bases ont l'option AUTO_CREATE_STATSTICS et
AUTO_UPDATE_STATISTICS à ON (tu peux lire mon article sur les statistiques:
http://rudi.developpez.com/sqlserver/tutoriel/statistiques/)
- si tu es sur SQL Server 2005, tu peux songer à créer une table
partitionnée
http://www.microsoft.com/france/technet/produits/sql/2005/20050519_tables_index_sqlserver2005.mspx
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, MCT, SCJP2
http://www.babaluga.com/
http://rudi.developpez.com/
Y a til un moyen pour optimiser une telle requete ?
Bonjour,
Une requête avec un opérateur > ou < a de bonnes chances d'être lente, elle peut facilement générer un scan. Quelques principes : - Au lieu d'UNION, utilise UNION ALL, cela t'économise l'exclusion des doublons; - Dans chaque table sous-jacente, ajoute une contrainte CHECK sur la date, pour limiter les enregistrements selon la plage de date choisie, cela permet à l'optimiseur de savoir qu'il n'a pas besoin de scanner une table parce qu'elle ne contiendra pas les données recherchées; - indexe la colonne date si ce n'est pas fait; - pour les colonnes où les statistiques sont manquantes, fais un CREATE STATISTICS. Vérifie que tes bases ont l'option AUTO_CREATE_STATSTICS et AUTO_UPDATE_STATISTICS à ON (tu peux lire mon article sur les statistiques: http://rudi.developpez.com/sqlserver/tutoriel/statistiques/) - si tu es sur SQL Server 2005, tu peux songer à créer une table partitionnée http://www.microsoft.com/france/technet/produits/sql/2005/20050519_tables_index_sqlserver2005.mspx
-- Rudi Bruchez Consultant indépendant modélisation, administration, optimisation, Solutions MS SQL Server et informatique libre. MCDBA, MCT, SCJP2 http://www.babaluga.com/ http://rudi.developpez.com/
