Et les index ?
Pour les proc stock, si elles ne sont pas étendues, tu dois avoir accès au code T-SQL.
Malgré tout, la trace te permet de voir les plans d'exécution, et de voir s'il y a des full scan de tables, les différents type de jointure etc....
je comprend mieux maintenant les faibles performances de votre système. Aucune de vos table n'est normalisée !!!!
Ceci joue contre toute optimisation :
[MOUV_ID] [int] IDENTITY(1,1) NOT NULL,
-- redondants :
[CE1] [char](1) NOT NULL,
[CE2] [char](1) NOT NULL,
[CE3] [char](1) NOT NULL,
[CE4] [char](1) NOT NULL,
[CE5] [char](1) NOT NULL,
[CE6] [char](1) NOT NULL,
[CE7] [char](1) NOT NULL,
[CE8] [char](1) NOT NULL,
[CE9] [char](1) NOT NULL,
[CEA] [char](1) NOT NULL,
[CEB] [char](1) NOT NULL,
[CEC] [char](1) NOT NULL,
[CED] [char](1) NOT NULL,
[CEE] [char](1) NOT NULL,
[CEF] [char](1) NOT NULL,
-- créez une table fille avec une colonne position contenant les valeurs de 1 à F et la valeur de la colonne est nécessaire
[DOS] [numeric](3, 0) NOT NULL,
[REF] [char](25) NOT NULL,
-- redondants :
[SREF1] [char](8) NOT NULL,
[SREF2] [char](8) NOT NULL,
-- créez une table fille avec une colonne SREF est nécessaire
[TICOD] [char](1) NOT NULL,
[PICOD] [numeric](1, 0) NOT NULL,
[TIERS] [char](8) NOT NULL,
[DVNO] [numeric](8, 0) NOT NULL,
[DVDT] [datetime] NOT NULL,
[DVLG] [numeric](4, 0) NOT NULL,
[DVSLG] [numeric](2, 0) NOT NULL,
[DVCE4] [char](1) NOT NULL,
[CDNO] [numeric](8, 0) NOT NULL,
[CDDT] [datetime] NOT NULL,
[CDLG] [numeric](4, 0) NOT NULL,
[CDSLG] [numeric](2, 0) NOT NULL,
[CDCE4] [char](1) NOT NULL,
[CDENRNO] [numeric](9, 0) NOT NULL,
[BLNO] [numeric](8, 0) NOT NULL,
[BLDT] [datetime] NOT NULL,
[BLLG] [numeric](4, 0) NOT NULL,
[BLSLG] [numeric](2, 0) NOT NULL,
[BLCE4] [char](1) NOT NULL,
[FANO] [numeric](8, 0) NOT NULL,
[FADT] [datetime] NOT NULL,
[FALG] [numeric](4, 0) NOT NULL,
[FASLG] [numeric](2, 0) NOT NULL,
[FACE4] [char](1) NOT NULL,
[BPNO] [numeric](8, 0) NOT NULL,
[BPDT] [datetime] NOT NULL,
[OP] [char](3) NOT NULL,
-- a priori redondant
[USERCR] [char](20) NOT NULL,
[USERMO] [char](20) NOT NULL,
-- créez une table fille avec une colonne type user et une colonne valeur
[DEPO] [char](3) NOT NULL,
[ETB] [char](3) NOT NULL,
[PROJET] [char](8) NOT NULL,
[MARCHE] [char](8) NOT NULL,
[DES] [char](80) NOT NULL,
[REFFO] [char](25) NOT NULL,
-- redondant
[REPR_0001] [char](8) NOT NULL,
[REPR_0002] [char](8) NOT NULL,
[REPR_0003] [char](8) NOT NULL,
-- créez une table fille...
[ENRNO] [numeric](9, 0) NOT NULL,
[TACOD] [char](2) NOT NULL,
[REMCOD] [char](2) NOT NULL,
-- redondant :
[TAFAMR] [char](8) NOT NULL,
[TAFAMRX] [char](8) NOT NULL,
[REFAMR] [char](8) NOT NULL,
[REFAMRX] [char](8) NOT NULL,
-- créez une table fille avec une colonne pour TAF/REF, une colonne pour MR/MRX et une colonne pour la valeur
[COFAMR] [char](4) NOT NULL,
-- redondant
[COFAMV_0001] [char](4) NOT NULL,
[COFAMV_0002] [char](4) NOT NULL,
[COFAMV_0003] [char](4) NOT NULL,
-- créezune table fille
[DEV] [char](4) NOT NULL,
-- a priori redondant
[VENUN] [char](4) NOT NULL,
[REFUN] [char](4) NOT NULL,
[PUBUN] [char](4) NOT NULL,
[EMBUN] [char](4) NOT NULL,
[EDCOD] [char](5) NOT NULL,
[TXTEDCOD] [char](5) NOT NULL,
[PAGCOD] [char](2) NOT NULL,
[PRIOCOD] [numeric](1, 0) NOT NULL,
-- redondant
[AXE_0001] [char](8) NOT NULL,
[AXE_0002] [char](8) NOT NULL,
[AXE_0003] [char](8) NOT NULL,
[AXE_0004] [char](8) NOT NULL,
[CPTV] [char](8) NOT NULL,
[POSITION] [char](8) NOT NULL,
[SENS] [numeric](1, 0) NOT NULL,
[AVENANT] [char](8) NOT NULL,
[USERCRDH] [char](14) NOT NULL,
[USERMODH] [char](14) NOT NULL,
[CENOTE] [numeric](1, 0) NOT NULL,
[NOTE] [numeric](8, 0) NOT NULL,
[PUB] [numeric](12, 3) NOT NULL,
[PPAR] [numeric](4, 0) NOT NULL,
-- redondant
[REM_0001] [numeric](6, 2) NOT NULL,
[REM_0002] [numeric](6, 2) NOT NULL,
[REM_0003] [numeric](6, 2) NOT NULL,
-- redondant
[REMTYP_0001] [numeric](1, 0) NOT NULL,
[REMTYP_0002] [numeric](1, 0) NOT NULL,
[REMTYP_0003] [numeric](1, 0) NOT NULL,
[REMMT] [numeric](9, 2) NOT NULL,
[PROMOTYP] [numeric](1, 0) NOT NULL,
[PUSTAT] [numeric](17, 6) NOT NULL,
-- redondant
[QTE1] [numeric](12, 2) NOT NULL,
[QTE2] [numeric](12, 2) NOT NULL,
[QTE3] [numeric](12, 2) NOT NULL,
-- à priori redondant
[DVQTE] [numeric](12, 2) NOT NULL,
[CDQTE] [numeric](12, 2) NOT NULL,
[BLQTE] [numeric](12, 2) NOT NULL,
[FAQTE] [numeric](12, 2) NOT NULL,
[REFQTE] [numeric](12, 2) NOT NULL,
[EMBQTE] [numeric](12, 2) NOT NULL,
-- créez une table fille en gérez des types de auantité
-- redondant
[COMP_0001] [numeric](5, 2) NOT NULL,
[COMP_0002] [numeric](5, 2) NOT NULL,
[COMP_0003] [numeric](5, 2) NOT NULL,
-- redondant
[COMMT_0001] [numeric](9, 2) NOT NULL,
[COMMT_0002] [numeric](9, 2) NOT NULL,
[COMMT_0003] [numeric](9, 2) NOT NULL,
[MONT] [numeric](13, 2) NOT NULL,
[FRAISMT] [numeric](12, 2) NOT NULL,
[DECCOD] [numeric](1, 0) NOT NULL,
-- redondant
[PCOD_0001] [numeric](1, 0) NOT NULL,
[PCOD_0002] [numeric](1, 0) NOT NULL,
[PCOD_0003] [numeric](1, 0) NOT NULL,
[PCOD_0004] [numeric](1, 0) NOT NULL,
[PCOD_0005] [numeric](1, 0) NOT NULL,
[STATUS] [numeric](1, 0) NOT NULL,
[STRES] [numeric](1, 0) NOT NULL,
[FILLERSENS] [numeric](1, 0) NOT NULL,
[MVCOD] [numeric](1, 0) NOT NULL,
[PVCOD] [numeric](1, 0) NOT NULL,
[QTETYP] [numeric](1, 0) NOT NULL,
[GADT] [datetime] NOT NULL,
[CRTOTMT] [numeric](17, 6) NOT NULL,
[CMPTOTMT] [numeric](17, 6) NOT NULL,
[TXTCOD] [numeric](1, 0) NOT NULL,
[TXTNOTE] [numeric](8, 0) NOT NULL,
-- redondant
[ENRNOP_0001] [numeric](9, 0) NOT NULL,
[ENRNOP_0002] [numeric](9, 0) NOT NULL,
[ENRNOP_0003] [numeric](9, 0) NOT NULL,
[ENRNOP_0004] [numeric](9, 0) NOT NULL,
[ENRNOC_0001] [numeric](9, 0) NOT NULL,
[ENRNOC_0002] [numeric](9, 0) NOT NULL,
[ENRNOC_0003] [numeric](9, 0) NOT NULL,
[ENRNOC_0004] [numeric](9, 0) NOT NULL,
-- redondant
[REMPIEMT_0001] [numeric](12, 2) NOT NULL,
[REMPIEMT_0002] [numeric](12, 2) NOT NULL,
[REMPIEMT_0003] [numeric](12, 2) NOT NULL,
[REMPIEMT_0004] [numeric](12, 2) NOT NULL,
[MVSTAT] [numeric](1, 0) NOT NULL,
[BLASENRNO] [numeric](9, 0) NOT NULL,
-- redondant
[REMPIEPART_0001] [numeric](12, 2) NOT NULL,
[REMPIEPART_0002] [numeric](12, 2) NOT NULL,
[REMPIEPART_0003] [numeric](12, 2) NOT NULL,
[REMPIEPART_0004] [numeric](12, 2) NOT NULL
) ON [PRIMARY]
En éliminant tout ce qui devrait être dans des tables filles on passe de 154 colonnes à 76 ! , soit une optimisation d'au moins 2 fois.
De plus lorsque je fais des audits, lorsque je voit une table dépasser 20 colonnes, je met en doute les qualités du développeur. Au dela de 35, je frappe. A 75 je tue. Vous êtes mort !
Vous ne faites pas de la base de données relationnelle, vous faites du fichier COBOL. Même avec peu d'update/delete/insert, vos lignes sont tellement longues que la fragmentation est catastrophique. Plus vos table seront petites, plus vos performances seront grande. peu importe le nombre de jointures...
Commencez donc par prendre des cours de modélisation de données. Sans cela vous ne parviendrez JAMAIS à optimiser votre base.
Lisez l'article que j'ai écrit sur ce sujet : http://sqlpro.developpez.com/optimisation/3/
Autres questions : pourquoi utilisez vous du NUMERIC de 1 ? Si c'est pour faire du booléen, utilisez BIT ! Pourquoi utilisez vous du numeric avec 0 décimales ? C'est idiot, cela occupe plus de place que de l'entier !!!!
Lisez SVP l'article que j'ai mentionné ci dessus. Vous y trouverez toutes vos erreurs. Il n'y a pas de magie, la lenteur de vos requêtes est à 99% lié à votre modèle, n'ayons pas peu des mots, totalement pourri !
A +
PS : bon courage quand même !
note pour + tard ne pas hésiter à utilise code/code
quel couillon ! au temps pour moi !
si j'ai des index qui sont du style :
Mais ça avance à quoi objectivement ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 CREATE NONCLUSTERED INDEX [INDEX_A] ON [dbo].[ENT] ( [DOS] ASC, [TICOD] ASC, [PICOD] ASC, [PIDT] ASC, [PINO] ASC, [ENT_ID] ASC )
C'est pareil j'ai plein de TRIGGER mais "je m'en fou" tant que je sais qu'il ne font pas d'UPDATE de masse ni d'INSERT non ?
Est-ce que par hasard si on fais des grosses requêtes SELECT sur ces tables le cache des ces requêtes ne deviendrait pas PERSISTENT et du coup un simple UPDATE derrière ferait qu'il est très lent puisque le cache "n'est pas le bon", d'ou la reconstruction d 'index qui fonctionne ?
Je remarque que j'ai beaucoup de exec sp_cursorfetch 180150021,2,1,1
qui me prennent du temps processeur et pas mal de 'Reads' aussi
cursorfetch ... ça sent le parcours de colonne pas terrible ça ( j'en ai des centaines en fait ! )
Les curseurs sont aussi sources de ralentissement... mais je crois que SQLpro a mis le doigt (que dis-je, le pieds !) sur les éléments qu'il faut retravailler....
mouai ....
J'ai commencé par dire "le soft propriétaire blablabla ..."
donc ça veux dire que la base de donnée, je ne peux pas la toucher ..CQFD
Ensuite, mon souci c'est que j'ai un logiciel propriétaire, avec cette base de donnée là, et que je ne peux pas rien modifier sur la base, vous comprenez pourquoi je suppose ?
Ma question de départ, outre le fait que la base ne ressemble à rien c'est plutôt pourquoi en réindexant ça repars comme en 40 !?
et ensuite pourquoi sous SQL 2000 jamais aucun souci alors que sous 2005...
est-ce qu'un automatisme aurait disparu dans sql2005 qui existerait sous sql 2000 par ex que j'aurai pas vu ?
Je précise que le nbre de requête n'a pas changé entre temps on à "juste" basculer les bdd, le soft est le même.
bon enfin en tout cas merci de m'avoir lu :-)
non parce que "jamais aucun souci" n'est pas vrai, des ralentissements oui
mais là, c'est carrément hallucinant !
version : Microsoft SQL Server 2005 - 9.00.3054.00 (Intel X86) Mar 23 2007 16:28:52 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
backup/restore la méthode !
attach/detach j'aurai même pas osé
Quand vous dites en réindexant, quelle commande SQL faites vous exactement ?
evidemment les cursors et notamment la balayage ligne à ligne qui se traduite par un sp_cursorfetch est aussi quelquechose de bloquant : chaque fois qu'une ligne est lue et maintenue en attente de modif dans le sp_cursorfetch alors la lecture n'est pas possible....
A +
As-tu essayer de supprimer tous les index (DROP INDEX) puis les recréer ?
Sinon, Microsoft avait reconnu il y a peu ce genre de phénomène (je parle d'une baisse de perf en restaurant une base niveau 80 sous SQL Server 2005). Le support technique Microsoft à l'époque recommandait de passer en version 9.00.3156 je crois.
Peux-tu essayer de mettre à jour ton instance avec par exemple le cumulative update package 7 sorti récemment ? Cela te fera passer en version 9.00.3239.
Puis constate une éventuelle amélioration.
Attention, cela est sans garantie étant donné le pauvre design de la base.... comme l'a indiqué SQLpro.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager