Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur Problème de lenteur lié à une base de donnée (et non au serveur)

Problème de lenteur lié à une base de donnée (et non au serveur)

6 réponses
Avatar
Laure Lafont
Bonjour à tous,

J'ai une base chez un client qui se met à être très lente sur certaines
procèdures stockées. J'ai rapatrié cette base sur mon serveur de test et j'ai
les mêmes problèmes. Si je rapatrie les données sur une ancienne base
(toujours sur le même serveur), tout est OK. La même procédure stockée met
2min32 sur la base lente et 0min08 sur l'ancienne.
Savez-vous d'où ça peut venir? J'ai fais une réindexation, mais ça n'a rien
donné.

Merci.
Signaler un problème avec ce contenu

6 réponses

Supprimer
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
Avatar
Med Bouchenafa
Un premier reflexe est de mettre à jour les statistiques
UPDATE STATISTICS NomTable WITH FULLSCAN
Commmence par les tables utilisées par ta procedure stockée

--
Bien cordialement
Med Bouchenafa

"Laure Lafont" a écrit dans le
message de news:
Bonjour à tous,

J'ai une base chez un client qui se met à être très lente sur certaines
procèdures stockées. J'ai rapatrié cette base sur mon serveur de test et
j'ai
les mêmes problèmes. Si je rapatrie les données sur une ancienne base
(toujours sur le même serveur), tout est OK. La même procédure stockée met
2min32 sur la base lente et 0min08 sur l'ancienne.
Savez-vous d'où ça peut venir? J'ai fais une réindexation, mais ça n'a
rien
donné.

Merci.


Avatar
Laure Lafont
Merci pour ton aide.
J'ai mis à jour les statistiques de toutes mes tables.
Et j'ai les mêmes résultats.
Faut-il faire autre chose ensuite?
Cordialement
Laure Lafont

"Med Bouchenafa" a écrit :

Un premier reflexe est de mettre à jour les statistiques
UPDATE STATISTICS NomTable WITH FULLSCAN
Commmence par les tables utilisées par ta procedure stockée

--
Bien cordialement
Med Bouchenafa

"Laure Lafont" a écrit dans le
message de news:
> Bonjour à tous,
>
> J'ai une base chez un client qui se met à être très lente sur certaines
> procèdures stockées. J'ai rapatrié cette base sur mon serveur de test et
> j'ai
> les mêmes problèmes. Si je rapatrie les données sur une ancienne base
> (toujours sur le même serveur), tout est OK. La même procédure stockée met
> 2min32 sur la base lente et 0min08 sur l'ancienne.
> Savez-vous d'où ça peut venir? J'ai fais une réindexation, mais ça n'a
> rien
> donné.
>
> Merci.





Avatar
Med Bouchenafa
Regarde si tu as le même nombre d' I/O en executant ta procedure sur les
deux bases

SET STATISTICS IO ON
GO
EXEC Proc
GO
SET STATISTICS IO OFF


--
Bien cordialement
Med Bouchenafa

"Laure Lafont" a écrit dans le
message de news:
Merci pour ton aide.
J'ai mis à jour les statistiques de toutes mes tables.
Et j'ai les mêmes résultats.
Faut-il faire autre chose ensuite?
Cordialement
Laure Lafont

"Med Bouchenafa" a écrit :

Un premier reflexe est de mettre à jour les statistiques
UPDATE STATISTICS NomTable WITH FULLSCAN
Commmence par les tables utilisées par ta procedure stockée

--
Bien cordialement
Med Bouchenafa

"Laure Lafont" a écrit dans le
message de news:
> Bonjour à tous,
>
> J'ai une base chez un client qui se met à être très lente sur certaines
> procèdures stockées. J'ai rapatrié cette base sur mon serveur de test
> et
> j'ai
> les mêmes problèmes. Si je rapatrie les données sur une ancienne base
> (toujours sur le même serveur), tout est OK. La même procédure stockée
> met
> 2min32 sur la base lente et 0min08 sur l'ancienne.
> Savez-vous d'où ça peut venir? J'ai fais une réindexation, mais ça n'a
> rien
> donné.
>
> Merci.







Avatar
Laure Lafont
J'ai donc fait, et effectivement je ne trouve pas le même nombre d'I/O sur
certaines tables.
Exemple :
Sur base lente : Table 'TDetailContrat'. Compte d'analyses 341, lectures
logiques 5603899, lectures physiques 0, lectures anticipées 0.
sur base de test :Table 'TDetailContrat'. Compte d'analyses 368, lectures
logiques 1999, lectures physiques 0, lectures anticipées 0.

Comment résoudre ces problèmes?

"Med Bouchenafa" a écrit :

Regarde si tu as le même nombre d' I/O en executant ta procedure sur les
deux bases

SET STATISTICS IO ON
GO
EXEC Proc
GO
SET STATISTICS IO OFF


--
Bien cordialement
Med Bouchenafa

"Laure Lafont" a écrit dans le
message de news:
> Merci pour ton aide.
> J'ai mis à jour les statistiques de toutes mes tables.
> Et j'ai les mêmes résultats.
> Faut-il faire autre chose ensuite?
> Cordialement
> Laure Lafont
>
> "Med Bouchenafa" a écrit :
>
>> Un premier reflexe est de mettre à jour les statistiques
>> UPDATE STATISTICS NomTable WITH FULLSCAN
>> Commmence par les tables utilisées par ta procedure stockée
>>
>> --
>> Bien cordialement
>> Med Bouchenafa
>>
>> "Laure Lafont" a écrit dans le
>> message de news:
>> > Bonjour à tous,
>> >
>> > J'ai une base chez un client qui se met à être très lente sur certaines
>> > procèdures stockées. J'ai rapatrié cette base sur mon serveur de test
>> > et
>> > j'ai
>> > les mêmes problèmes. Si je rapatrie les données sur une ancienne base
>> > (toujours sur le même serveur), tout est OK. La même procédure stockée
>> > met
>> > 2min32 sur la base lente et 0min08 sur l'ancienne.
>> > Savez-vous d'où ça peut venir? J'ai fais une réindexation, mais ça n'a
>> > rien
>> > donné.
>> >
>> > Merci.
>>
>>
>>





Avatar
Fred BROUARD
Bonjour,

Laure Lafont a écrit:
J'ai donc fait, et effectivement je ne trouve pas le même nombre d'I/O sur
certaines tables.
Exemple :
Sur base lente : Table 'TDetailContrat'. Compte d'analyses 341, lectures
logiques 5603899, lectures physiques 0, lectures anticipées 0.
sur base de test :Table 'TDetailContrat'. Compte d'analyses 368, lectures
logiques 1999, lectures physiques 0, lectures anticipées 0.



La différence est importante et peu être lié à :
1) une voluùmétrie de données différente
2) une indexation déficientes (certains index n'existent pas dans une des bases)
3) une fragmentation des index.

1) pour obtenir la volumétrie détaillée des éléments :
CREATE TABLE #tmp_volindex
(ObjectName sysname,
ObjectId int,
IndexName sysname,
IndexId int,
Level int,
Pages int,
Rows int,
MinimumRecordSize int,
MaximumRecordSize int,
AverageRecordSize float,
ForwardedRecords int,
Extents int,
ExtentSwitches int,
AverageFreeBytes float,
AveragePageDensity float,
ScanDensity float,
BestCount int,
ActualCount int,
LogicalFragmentation float,
ExtentFragmentation float)
GO

INSERT INTO #tmp_volindex
EXEC ('DBCC SHOWCONTIG (''TDetailContrat'') WITH TABLERESULTS, ALL_INDEXES')

SELECT 1 AS N, ObjectId, ObjectName, IndexId, IndexName,
CAST(Pages as FLOAT) * 8 / 1024.0 AS VolumeOccupeMO,
CAST(Rows as FLOAT) * AverageRecordSize / 1024 AS VolumeDonneesKO
FROM #tmp_volindex
UNION
SELECT 2,ObjectId, ObjectName, NULL, '<TOTAUX>',
SUM(CAST(Pages as FLOAT) * 8 / 1024.0),
SUM(CAST(Rows as FLOAT) * AverageRecordSize / 1024)
FROM #tmp_volindex
GROUP BY ObjectId, ObjectName
ORDER BY N, ObjectName, IndexId


2) Pour voir les différences d'index dans la table considérée :
sp_helpindex 'TDetailContrat'

3) pour voir la fragmentation des index :
DBCC SHOWCONTIG ('TDetailContrat') WITH ALL_INDEXES
en particulier le nombre de switch sur le nombre d'extents.


Comment résoudre ces problèmes?



Un audit de la base serait sans doute intéressant pour débusquer les problèmes...

A +

--
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
********************* http://www.datasapiens.com ***********************
Avatar
Med Bouchenafa
Cela prouve que SQL Server n'a pas exactement la même configuration pour les
deux bases
Si j'ai bien compris mais j'aimerais que tu confirmes
- Tu travailles sur un même serveur
- Tu as fait une sauvegarde de la base1 et tu la restaures sur la base2
- Tu executes la meme procedure avec les mêmes parametres sur chacune des
deux bases
- Tu obtiens des temps de reponse très differents

Si c'est vraiment le cas, cela me semble effectivement assez étrange au vu
de la difference d'IO que tu cites
Essaie d'analyser les plans de requetes produits dans chacun des deux cas.

SET SHOWPLAN_ALL ON
GO
EXEC Proc
GO
SET SHOWPLAN_ALL OFF
GO

--
Bien cordialement
Med Bouchenafa


"Laure Lafont" a écrit dans le
message de news:
J'ai donc fait, et effectivement je ne trouve pas le même nombre d'I/O sur
certaines tables.
Exemple :
Sur base lente : Table 'TDetailContrat'. Compte d'analyses 341, lectures
logiques 5603899, lectures physiques 0, lectures anticipées 0.
sur base de test :Table 'TDetailContrat'. Compte d'analyses 368, lectures
logiques 1999, lectures physiques 0, lectures anticipées 0.

Comment résoudre ces problèmes?

"Med Bouchenafa" a écrit :

Regarde si tu as le même nombre d' I/O en executant ta procedure sur les
deux bases

SET STATISTICS IO ON
GO
EXEC Proc
GO
SET STATISTICS IO OFF


--
Bien cordialement
Med Bouchenafa

"Laure Lafont" a écrit dans le
message de news:
> Merci pour ton aide.
> J'ai mis à jour les statistiques de toutes mes tables.
> Et j'ai les mêmes résultats.
> Faut-il faire autre chose ensuite?
> Cordialement
> Laure Lafont
>
> "Med Bouchenafa" a écrit :
>
>> Un premier reflexe est de mettre à jour les statistiques
>> UPDATE STATISTICS NomTable WITH FULLSCAN
>> Commmence par les tables utilisées par ta procedure stockée
>>
>> --
>> Bien cordialement
>> Med Bouchenafa
>>
>> "Laure Lafont" a écrit dans le
>> message de news:
>> > Bonjour à tous,
>> >
>> > J'ai une base chez un client qui se met à être très lente sur
>> > certaines
>> > procèdures stockées. J'ai rapatrié cette base sur mon serveur de
>> > test
>> > et
>> > j'ai
>> > les mêmes problèmes. Si je rapatrie les données sur une ancienne
>> > base
>> > (toujours sur le même serveur), tout est OK. La même procédure
>> > stockée
>> > met
>> > 2min32 sur la base lente et 0min08 sur l'ancienne.
>> > Savez-vous d'où ça peut venir? J'ai fais une réindexation, mais ça
>> > n'a
>> > rien
>> > donné.
>> >
>> > Merci.
>>
>>
>>