probleme de temps de reponses differents entre deux serveurs

> Il y a le même matos inside OK
mais sont elles configurées exactement de la même façon ?
ex : Cache en écriture sur une machine mais pas l'autre ...

Pourquoi alors quand je fais un update brutal a null de ectte colonne j'ai
lele meme temps de reponse sur les deux machines?

> -1) Antivirus sur les machines ?

=>Oui : les memes configurés de la meme facon, nous avons aussi essayé en
arretant les anti-virus : resultat idem

-2) Sont elle sur le même domaine ?

Aucun domaine de configuré, serveur stand-alone

-3) Installation SQL SERVER identique ?

Oui

-4) Version du mdac identique ?

Oui 2.7

De mieux en mieux !!!
Pourrais-tu publier ici le contenu de cette procédure stockée si elle est
raisonnablement compréhensible et pas trop volumineuse

Il doit bien avoir une explication à cette différence de temps

--
Bien cordialement
Med Bouchenafa

"Cymryr" <Cymryr@hotmail.com> a écrit dans le message de news:
OSCmGZ1DFHA.3728@TK2MSFTNGP14.phx.gbl...

Oui ce sont les meme (je les ai deployés moi-meme) et ils font appel a un
proc strock, quand on la lance unitairement ca fait pareil



"Med Bouchenafa" <com.tetraset@Bouchenafa> wrote in message
news:ONaVyNuDFHA.1668@TK2MSFTNGP10.phx.gbl...

>... la connection du dts qui lance le traitement ...
C'est peut-être çà la clef du mystère.
Regarde bien si tes deux lots DTS ont exactement les même propriétés
Au pire sauvegarde les sous forme de fichiers VB et fait une comparaison

--
Bien cordialement
Med Bouchenafa

"Cymryr" <Cymryr@hotmail.com> a écrit dans le message de news:
ek9KupsDFHA.936@TK2MSFTNGP12.phx.gbl...
> les requetes se passent la nuit, application web fermées, aucun backup

en

> cours pendant le batch, si on regarde les process il n'y a que les

process

> system, la connection du dts qui lance le traitement et la connection
> de
> l'enterprise manager avec lequel je regarde la partie management
>
>
>
> "Med Bouchenafa" <com.hotmail@bouchenafa> wrote in message
> news:%23fvR%23XsDFHA.3888@TK2MSFTNGP09.phx.gbl...
> > Si pendant l'UPDATE, tu as d'autres process qui tournent , il est
> > fort
> > possible que les deux serveurs ne vont pas se comporter de la même

manière

> > Pour le moment, la seule hypothèse reste le fait que les ressources

sont

> > sollicitées différemment sur les deux serveurs
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> >
> >
> >
> > "Cymryr" <Cymryr@hotmail.com> a écrit dans le message de news:
> > u4FwTorDFHA.3976@tk2msftngp13.phx.gbl...
> > > oui idem sur les deux serveurs pour tempdb
> > >
> > > un autre point : sur ce meme serveur j'ai eu en meme temps un

probleme

> > > avec
> > > olap, impossible de processer une cube (il n'arrivait pas a locker

un

> axe)
> > > Le seul truc qui a fonctionner c'ets de retirer une autre base olap

qui

> > > avait la meme structure, pb de repository?
> > >
> > >
> > > "Med Bouchenafa" <com.hotmail@bouchenafa> wrote in message
> > > news:%235lwj%23qDFHA.1408@TK2MSFTNGP10.phx.gbl...
> > >> Une piste possible serait tempDB
> > >> Est-elle pareille sur les deux serveurs ?
> > >> Voir non seulement ses emplacements disque mais aussi sa collation
> > >>
> > >> --
> > >> Bien cordialement
> > >> Med Bouchenafa
> > >>
> > >> "Cymryr" <Cymryr@hotmail.com> a écrit dans le message de news:
> > >> %23ejXBXqDFHA.2232@TK2MSFTNGP14.phx.gbl...
> > >> > Bonjour, j'ia un énorme problème dont je n'arrive pas a sortir

depuis

> > > une
> > >> > dizaine de jours
> > >> >
> > >> > J'ai un datawarehouse, avec une table de faits d'environ 8

millions

> de
> > >> > lignes
> > >> > toutes les nuits j'ai un batch qui tourne et qui fait un gros

update

> > >> > sur
> > >> > cette table
> > >> >
> > >> > Sur un serveur A , bi processeur 2 Go de ram, le traitement dure

30

> > >> > minutes
> > >> > Sur un serveur B , quadri processeur 4 Go de ram, le traitement

dure

> > > 5h30
> > >> >
> > >> > La volumétrie est strictement la meme
> > >> > Le plan d'indexation est strictement le meme
> > >> > Le plan d'execution est strictement le meme
> > >> >
> > >> > Je n'arrive pas a comprendre les délais d'execution
> > >> > J'ai essayer de passer sql en bi-pro sur le serveur B : temps de
> > >> > traitement
> > >> > idem (normal de toute facon le plan d'execution ne sollicite que
> 2cpu)
> > >> >
> > >> > J'ai joué plusieurs fois des plans de maintenance pour etre sur

de

> > >> > l'integrité de la base
> > >> > Les disques sont defragmentés (raid 5 sur les deux serveurs)
> > >> >
> > >> > Bref je ne sais plus quoi faire et ca deviens tres critique!
> > >> > Merci de vos iddées.
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> >
> >
>
>

Tu peux peut etre essayer :
un log analyseur de perf "toutes les 1seconde", sur processeur, page/fault,
activité disque, file attente disque, activité réseau, file attente
processeur, SQL cache hit ratio, lock wait ...
un profiler stmt end SP et TSQL, batch end, RPC complete

et voir à partir de ça

br

"Cymryr" <Cymryr@hotmail.com> wrote in message
news:#ejXBXqDFHA.2232@TK2MSFTNGP14.phx.gbl...

Bonjour, j'ia un énorme problème dont je n'arrive pas a sortir depuis une
dizaine de jours

J'ai un datawarehouse, avec une table de faits d'environ 8 millions de
lignes
toutes les nuits j'ai un batch qui tourne et qui fait un gros update sur
cette table

Sur un serveur A , bi processeur 2 Go de ram, le traitement dure 30

minutes

Sur un serveur B , quadri processeur 4 Go de ram, le traitement dure 5h30

La volumétrie est strictement la meme
Le plan d'indexation est strictement le meme
Le plan d'execution est strictement le meme

Je n'arrive pas a comprendre les délais d'execution
J'ai essayer de passer sql en bi-pro sur le serveur B : temps de

traitement

idem (normal de toute facon le plan d'execution ne sollicite que 2cpu)

J'ai joué plusieurs fois des plans de maintenance pour etre sur de
l'integrité de la base
Les disques sont defragmentés (raid 5 sur les deux serveurs)

Bref je ne sais plus quoi faire et ca deviens tres critique!
Merci de vos iddées.

Voila le code incriminé

UPDATE FACTTABLE
set FACTTABLE.MATRIX_ID=RFM.MATRIX_ID
from FACTTABLE
inner join dbo.RF_ACCNATURE LGLACCOUNT
on LGLACCOUNT.ACCNATURE_IDúCTTABLE.ACCNATURE_ID
inner join dbo.RF_UNIT_GLACCOUNT RFUG
on (RFUG.UNIT_ID = LGLACCOUNT.UNIT_ID and RFUG.CODE=LGLACCOUNT.ACCNATURE)
inner join RF_MATRIX RFM
on RFM.COMMCODE_ID=RFUG.COMMCODE_ID and RFM.MATRIX_ID <>
@UNCLASSIFIED_MATRIX_ID
inner join CPP_LOCAL_REFERENTIAL
on CPP_LOCAL_REFERENTIAL.LOCAL_REF_UPLOAD_ID = RFUG.LOCAL_REF_UPLOAD_ID
where
CPP_LOCAL_REFERENTIAL.ACTIVE = 1
and RFUG.ISSHEET = 1

Quelle est la signification de @UNCLASSIFIED_MATRIX_ID
Est-ce un paramètre de la procédure stockée ?
Si oui, il est préferable de le sortir de le jointure et de la mettre dans
la clause WHERE
Même s'il est probable que cela ne change pas le plan d'exécution, cela
reste plus propre.
Avec cette nouvelle ecriture il serait interessant que tu relances ta
procédure avec l'option WITH RECOMPILE et voir si cela change quelque chose
Mon idée serait que le plan d'exécution en cache est basé sur la première
valeur @UNCLASSIFIED_MATRIX_ID passée à la procédure


UPDATE FACTTABLE
SET FACTTABLE.MATRIX_ID=RFM.MATRIX_ID
FROM dbo.FACTTABLE INNER JOIN dbo.RF_ACCNATURE LGLACCOUNT ON
LGLACCOUNT.ACCNATURE_ID = FACTTABLE.ACCNATURE_ID
INNER JOIN dbo.RF_UNIT_GLACCOUNT RFUG ON RFUG.UNIT_ID =
LGLACCOUNT.UNIT_ID
AND RFUG.CODE = LGLACCOUNT.ACCNATURE
INNER JOIN dbo.RF_MATRIX RFM ON RFM.COMMCODE_ID =
RFUG.COMMCODE_ID
INNER JOIN dbo.CPP_LOCAL_REFERENTIAL CPPLR ON
CPPLR.LOCAL_REF_UPLOAD_ID = RFUG.LOCAL_REF_UPLOAD_ID
WHERE CPPLR.ACTIVE = 1
AND RFUG.ISSHEET = 1
AND RFM.MATRIX_ID <> @UNCLASSIFIED_MATRIX_ID

--
Bien cordialement
Med Bouchenafa

"Cymryr" <Cymryr@hotmail.com> a écrit dans le message de news:
uOn1Mt2DFHA.2756@TK2MSFTNGP15.phx.gbl...

Voila le code incriminé

UPDATE FACTTABLE
set FACTTABLE.MATRIX_ID=RFM.MATRIX_ID
from FACTTABLE
inner join dbo.RF_ACCNATURE LGLACCOUNT
on LGLACCOUNT.ACCNATURE_IDúCTTABLE.ACCNATURE_ID
inner join dbo.RF_UNIT_GLACCOUNT RFUG
on (RFUG.UNIT_ID = LGLACCOUNT.UNIT_ID and RFUG.CODE=LGLACCOUNT.ACCNATURE)
inner join RF_MATRIX RFM
on RFM.COMMCODE_ID=RFUG.COMMCODE_ID and RFM.MATRIX_ID <>
@UNCLASSIFIED_MATRIX_ID
inner join CPP_LOCAL_REFERENTIAL
on CPP_LOCAL_REFERENTIAL.LOCAL_REF_UPLOAD_ID = RFUG.LOCAL_REF_UPLOAD_ID
where
CPP_LOCAL_REFERENTIAL.ACTIVE = 1
and RFUG.ISSHEET = 1

Je vais voir ca mais cette valeur ne change jamais dans la vie de
l'application (elle est initalisée au chargement d'un fichier et ensuite ne
bouge jamais)
Est ce que ce "cache" est persistant meme apres un reboot?


"Med Bouchenafa" <com.hotmail@bouchenafa> wrote in message
news:u0RoPb3DFHA.4052@TK2MSFTNGP09.phx.gbl...

Quelle est la signification de @UNCLASSIFIED_MATRIX_ID
Est-ce un paramètre de la procédure stockée ?
Si oui, il est préferable de le sortir de le jointure et de la mettre dans
la clause WHERE
Même s'il est probable que cela ne change pas le plan d'exécution, cela
reste plus propre.
Avec cette nouvelle ecriture il serait interessant que tu relances ta
procédure avec l'option WITH RECOMPILE et voir si cela change quelque

chose

Mon idée serait que le plan d'exécution en cache est basé sur la première
valeur @UNCLASSIFIED_MATRIX_ID passée à la procédure


UPDATE FACTTABLE
SET FACTTABLE.MATRIX_ID=RFM.MATRIX_ID
FROM dbo.FACTTABLE INNER JOIN dbo.RF_ACCNATURE LGLACCOUNT ON
LGLACCOUNT.ACCNATURE_ID = FACTTABLE.ACCNATURE_ID
INNER JOIN dbo.RF_UNIT_GLACCOUNT RFUG ON RFUG.UNIT_ID > LGLACCOUNT.UNIT_ID
AND RFUG.CODE = LGLACCOUNT.ACCNATURE
INNER JOIN dbo.RF_MATRIX RFM ON RFM.COMMCODE_ID > RFUG.COMMCODE_ID
INNER JOIN dbo.CPP_LOCAL_REFERENTIAL CPPLR ON
CPPLR.LOCAL_REF_UPLOAD_ID = RFUG.LOCAL_REF_UPLOAD_ID
WHERE CPPLR.ACTIVE = 1
AND RFUG.ISSHEET = 1
AND RFM.MATRIX_ID <> @UNCLASSIFIED_MATRIX_ID

--
Bien cordialement
Med Bouchenafa

"Cymryr" <Cymryr@hotmail.com> a écrit dans le message de news:
uOn1Mt2DFHA.2756@TK2MSFTNGP15.phx.gbl...
> Voila le code incriminé
>
> UPDATE FACTTABLE
> set FACTTABLE.MATRIX_ID=RFM.MATRIX_ID
> from FACTTABLE
> inner join dbo.RF_ACCNATURE LGLACCOUNT
> on LGLACCOUNT.ACCNATURE_IDúCTTABLE.ACCNATURE_ID
> inner join dbo.RF_UNIT_GLACCOUNT RFUG
> on (RFUG.UNIT_ID = LGLACCOUNT.UNIT_ID and

RFUG.CODE=LGLACCOUNT.ACCNATURE)

> inner join RF_MATRIX RFM
> on RFM.COMMCODE_ID=RFUG.COMMCODE_ID and RFM.MATRIX_ID <>
> @UNCLASSIFIED_MATRIX_ID
> inner join CPP_LOCAL_REFERENTIAL
> on CPP_LOCAL_REFERENTIAL.LOCAL_REF_UPLOAD_ID = RFUG.LOCAL_REF_UPLOAD_ID
> where
> CPP_LOCAL_REFERENTIAL.ACTIVE = 1
> and RFUG.ISSHEET = 1
>
>

Non, si elle ne bouge effectivement pas mon idée de départ est fausse.
Par contre, il serait interessant que tu fasses le test sur la requête
suivante sur les deux serveurs.
C'est juste un SELECT qui renvoie le résultat dans une table temporaire
#tblTest.
C'est un peu ce que devrait faire l'optimiseur avant de faire son UPDATE

SELECT RFM.MATRIX_ID, LGLACCOUNT.ACCNATURE_ID
INTO #tblTest
FROM dbo.RF_ACCNATURE LGLACCOUNT INNER JOIN dbo.RF_UNIT_GLACCOUNT RFUG
ON RFUG.UNIT_ID = LGLACCOUNT.UNIT_ID


AND RFUG.CODE = LGLACCOUNT.ACCNATURE

INNER JOIN dbo.RF_MATRIX RFM ON
RFM.COMMCODE_ID = RFUG.COMMCODE_ID

INNER JOIN dbo.CPP_LOCAL_REFERENTIAL CPPLR ON CPPLR.LOCAL_REF_UPLOAD_ID =
RFUG.LOCAL_REF_UPLOAD_ID
WHERE CPPLR.ACTIVE = 1
AND RFUG.ISSHEET = 1
AND RFM.MATRIX_ID <> @UNCLASSIFIED_MATRIX_ID


--
Bien cordialement
Med Bouchenafa




"Cymryr" <Cymryr@hotmail.com> a écrit dans le message de news:
eknlPq3DFHA.3972@TK2MSFTNGP15.phx.gbl...

Je vais voir ca mais cette valeur ne change jamais dans la vie de
l'application (elle est initalisée au chargement d'un fichier et ensuite
ne
bouge jamais)
Est ce que ce "cache" est persistant meme apres un reboot?


"Med Bouchenafa" <com.hotmail@bouchenafa> wrote in message
news:u0RoPb3DFHA.4052@TK2MSFTNGP09.phx.gbl...

Quelle est la signification de @UNCLASSIFIED_MATRIX_ID
Est-ce un paramètre de la procédure stockée ?
Si oui, il est préferable de le sortir de le jointure et de la mettre
dans
la clause WHERE
Même s'il est probable que cela ne change pas le plan d'exécution, cela
reste plus propre.
Avec cette nouvelle ecriture il serait interessant que tu relances ta
procédure avec l'option WITH RECOMPILE et voir si cela change quelque

chose

Mon idée serait que le plan d'exécution en cache est basé sur la première
valeur @UNCLASSIFIED_MATRIX_ID passée à la procédure


UPDATE FACTTABLE
SET FACTTABLE.MATRIX_ID=RFM.MATRIX_ID
FROM dbo.FACTTABLE INNER JOIN dbo.RF_ACCNATURE LGLACCOUNT ON
LGLACCOUNT.ACCNATURE_ID = FACTTABLE.ACCNATURE_ID
INNER JOIN dbo.RF_UNIT_GLACCOUNT RFUG ON RFUG.UNIT_ID >> LGLACCOUNT.UNIT_ID
AND RFUG.CODE = LGLACCOUNT.ACCNATURE
INNER JOIN dbo.RF_MATRIX RFM ON RFM.COMMCODE_ID >> RFUG.COMMCODE_ID
INNER JOIN dbo.CPP_LOCAL_REFERENTIAL CPPLR ON
CPPLR.LOCAL_REF_UPLOAD_ID = RFUG.LOCAL_REF_UPLOAD_ID
WHERE CPPLR.ACTIVE = 1
AND RFUG.ISSHEET = 1
AND RFM.MATRIX_ID <> @UNCLASSIFIED_MATRIX_ID

--
Bien cordialement
Med Bouchenafa

"Cymryr" <Cymryr@hotmail.com> a écrit dans le message de news:
uOn1Mt2DFHA.2756@TK2MSFTNGP15.phx.gbl...
> Voila le code incriminé
>
> UPDATE FACTTABLE
> set FACTTABLE.MATRIX_ID=RFM.MATRIX_ID
> from FACTTABLE
> inner join dbo.RF_ACCNATURE LGLACCOUNT
> on LGLACCOUNT.ACCNATURE_IDúCTTABLE.ACCNATURE_ID
> inner join dbo.RF_UNIT_GLACCOUNT RFUG
> on (RFUG.UNIT_ID = LGLACCOUNT.UNIT_ID and

RFUG.CODE=LGLACCOUNT.ACCNATURE)

> inner join RF_MATRIX RFM
> on RFM.COMMCODE_ID=RFUG.COMMCODE_ID and RFM.MATRIX_ID <>
> @UNCLASSIFIED_MATRIX_ID
> inner join CPP_LOCAL_REFERENTIAL
> on CPP_LOCAL_REFERENTIAL.LOCAL_REF_UPLOAD_ID = RFUG.LOCAL_REF_UPLOAD_ID
> where
> CPP_LOCAL_REFERENTIAL.ACTIVE = 1
> and RFUG.ISSHEET = 1
>
>

En observant attentivement les traces on s'appercoit que sur le serveur qui
vas bien il y une execution supplementaire qui est la suivante :
SELECT statman([ACCNATURE_ID],[REF],@PSTATMAN)
FROM (SELECT TOP 100 PERCENT [ACCNATURE_ID],[REF]
FROM [dbo].[FACTTABLE]
WITH(READUNCOMMITTED,SAMPLE 1.281155e+000 PERCENT)
ORDER BY [ACCNATURE_ID],[REF])
AS _MS_UPDSTATS_TBL OPTION (BYPASS OPTIMIZER_QUEU

Je n'ai aps ce code la sur le serveur qui ne vas pas


(désolé la trace du query analyzer ne me donne pas la suite)

Regarder si la mise des statistiques est (des)activée pareillement sur les
deux serveurs

--
Bien cordialement
Med Bouchenafa

"Cymryr" <Cymryr@hotmail.com> a écrit dans le message de news:
OKAD$sFEFHA.3416@TK2MSFTNGP09.phx.gbl...

En observant attentivement les traces on s'appercoit que sur le serveur
qui
vas bien il y une execution supplementaire qui est la suivante :
SELECT statman([ACCNATURE_ID],[REF],@PSTATMAN)
FROM (SELECT TOP 100 PERCENT [ACCNATURE_ID],[REF]
FROM [dbo].[FACTTABLE]
WITH(READUNCOMMITTED,SAMPLE 1.281155e+000 PERCENT)
ORDER BY [ACCNATURE_ID],[REF])
AS _MS_UPDSTATS_TBL OPTION (BYPASS OPTIMIZER_QUEU

Je n'ai aps ce code la sur le serveur qui ne vas pas


(désolé la trace du query analyzer ne me donne pas la suite)