|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||||||||||||||||||||
|
Membre Expert
![]() Analyste / Programmeur Inscription : juillet 2006 Messages : 1 307 ![]() |
Bonjour,
Je plante le décor : Soit une DB nommée "Tickets". Elle contient en fait les transactions caisses des 15 magasins de la chaine pour laquelle je travaille. Ces transactions étant séparées dans une table par année. Voici la structure d'une de ces tables (ici celle de 2012 mais elles sont toutes identiques) Code :
Suite à une formation sur sql server et après en avoir disctuer avec le formateur, j'ai décidé de fusionner toutes ces tables en une seule dont voici la structure : Code :
Code :
Code :
Code :
Code :
Code :
Code :
Code :
Suite à cette fusion des tables par années, j'ai renommé lesdites tables en ajoutant le suffixe '_old' histoire de les garder sous le coude au cas où. Mais vu qu'il y avait des applications se basant sur ces tables, j'ai créé des vues reprenant les mêmes colonnes. Une vue par année donc et portant chacune le même nom que les anciennes tables. Voici la définition de la vue pour 2012 : Code :
Bon, maintenant que le décor est planté (c'était long!), la question est : Pourquoi certaines applications reçoivent une erreur de type 'connection timeout' lorsqu'elles essaient d'accéder aux vues ? A côté de cela, j'ai un service qui récupère les transactions tous les jours par ftp sur les serveurs de chaque magasin. Ces transactions sont contenues dans des fichiers plats et le service injecte les données dans la table dbo.tblTransactions mais en passant par la vue adéquate (vu que je n'ai nullement modifié le code qui existait déjà). Pourquoi ce service fonctionne-t-il correctement et pas les applications clientes ? Y a-t-il des choses supplémentaires à paramétrer pour pouvoir faire des requêtes de sélection les vues sans problèmes ? Bien à vous, Griftou. |
||||||||||||||||||||
|
|
00
|
|
|
#2 |
|
Membre Expert
![]() Inscription : août 2009 Messages : 779 ![]() |
Si je comprend bien, outre les typages, vous aviez avant plusieurs tables (une par année) et maintenant il n'y en a plus qu'une seule ?
=> vous devriez partitionner la table selon year, ce qui améliorera très significativement les accès par année. |
|
|
00
|
|
|
#3 | |
|
Membre Expert
![]() Analyste / Programmeur Inscription : juillet 2006 Messages : 1 307 ![]() |
Citation:
Et euh... Pour partitionner la table ??? Enfin, je vais aller demander à mon pote google ! edit : ça a l'air trop compliqué pour un jeudi soir... |
|
|
|
00
|
|
|
#4 |
|
Membre Expert
![]() Inscription : août 2009 Messages : 779 ![]() |
Avec une vue par année, il faut encore faire un scan de la table (ou passer par l'index, mais sur peu de valeurs distinctes de year ce n'est pas fortement efficace).
Partitionner la table, c'est à peu près équivalent à avoir des tables séparées mais interrogeables en même temps, et soumises à des contraintes communes. Cela permet notamment de gagner beaucoup de temps quand on veut pouvoir requêter en filtrant sur une année. |
|
|
00
|
|
|
#5 |
|
Membre Expert
![]() Analyste / Programmeur Inscription : juillet 2006 Messages : 1 307 ![]() |
Et si, à la place de créer les vues en fonction de la colonne year (index non cluster), je créais les vues en fonction de la colonne date_dt qui elle, fait partie de mon index cluster.
Ne serait-ce pas mieux ? J'avoue que cette histoire de partitionnement me laisse perplexe. J'ai peur que la gestion de ce genre de chose ne soit pas de mon niveau. |
|
|
00
|
|
|
#6 | |
|
Membre Expert
![]() Analyste / Programmeur Inscription : juillet 2006 Messages : 1 307 ![]() |
Citation:
Après avoir supprimer la vue tb2007 et l'avoir recréer en mettant le filtre sur la colonne de l'index cluster, j'ai comparé les plans d'exécution d'une requête SELECT * sur la vue tb2007 et sur la vue tb2008 et ils sont identiques. Ils font tout deux un scan de l'index cluster. Le problème est donc ailleurs. Je ne m'explique toujours pas ce problème de timeout... |
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com