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.
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.
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.
> - Mettre en place un profiler SQL et comparer les nombres de read et le
temps CPU générés par la requete. Une différence importante *pourrait*
due a une fragmentation importante des index. Dans ce cas, faire un DBCC
DBREINDEX sur la base.
- Mettre en place un Performance Monitor avec les objets relatifs aux
d'attentes disques et CPU. Un longueur de file d'attente moyenne > 2 peut
indiquer une goulet d'étranglement (possiblement, débit disque moins
important)
> - Mettre en place un profiler SQL et comparer les nombres de read et le
temps CPU générés par la requete. Une différence importante *pourrait*
due a une fragmentation importante des index. Dans ce cas, faire un DBCC
DBREINDEX sur la base.
- Mettre en place un Performance Monitor avec les objets relatifs aux
d'attentes disques et CPU. Un longueur de file d'attente moyenne > 2 peut
indiquer une goulet d'étranglement (possiblement, débit disque moins
important)
> - Mettre en place un profiler SQL et comparer les nombres de read et le
temps CPU générés par la requete. Une différence importante *pourrait*
due a une fragmentation importante des index. Dans ce cas, faire un DBCC
DBREINDEX sur la base.
- Mettre en place un Performance Monitor avec les objets relatifs aux
d'attentes disques et CPU. Un longueur de file d'attente moyenne > 2 peut
indiquer une goulet d'étranglement (possiblement, débit disque moins
important)
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.
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.
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.
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" a écrit dans le message de news:
%
> Bonjour, j'ia un énorme problème dont je n'arrive pas a sortir depuis
> 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
>
> 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.
>
>
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
> 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
>
> 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.
>
>
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" a écrit dans le message de news:
%
> Bonjour, j'ia un énorme problème dont je n'arrive pas a sortir depuis
> 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
>
> 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.
>
>
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" wrote in message
news:%235lwj%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" a écrit dans le message de news:
%
> 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.
>
>
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.
>
>
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" wrote in message
news:%235lwj%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" a écrit dans le message de news:
%
> 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.
>
>
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" a écrit dans le message de news:
> 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
> Le seul truc qui a fonctionner c'ets de retirer une autre base olap qui
> avait la meme structure, pb de repository?
>
>
> "Med Bouchenafa" wrote in message
> news:%235lwj%
>> 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" a écrit dans le message de news:
>> %
>> > 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
>> > 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
>> >
>> > 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.
>> >
>> >
>>
>>
>
>
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
> 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
>> > 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
>> >
>> > 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.
>> >
>> >
>>
>>
>
>
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" a écrit dans le message de news:
> 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
> Le seul truc qui a fonctionner c'ets de retirer une autre base olap qui
> avait la meme structure, pb de repository?
>
>
> "Med Bouchenafa" wrote in message
> news:%235lwj%
>> 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" a écrit dans le message de news:
>> %
>> > 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
>> > 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
>> >
>> > 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.
>> >
>> >
>>
>>
>
>
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" wrote in message
news:%23fvR%
> 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" a écrit dans le message de news:
>
> > 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" wrote in message
> > news:%235lwj%
> >> 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" a écrit dans le message de news:
> >> %
> >> > 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.
> >> >
> >> >
> >>
> >>
> >
> >
>
>
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.
> >> >
> >> >
> >>
> >>
> >
> >
>
>
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" wrote in message
news:%23fvR%
> 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" a écrit dans le message de news:
>
> > 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" wrote in message
> > news:%235lwj%
> >> 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" a écrit dans le message de news:
> >> %
> >> > 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.
> >> >
> >> >
> >>
> >>
> >
> >
>
>
>... la connection du dts qui lance le traitement ...
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" wrote in message
news:%23fvR%
> 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" a écrit dans le message de news:
>
> > 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" wrote in message
> > news:%235lwj%
> >> 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" a écrit dans le message de news:
> >> %
> >> > 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.
> >> >
> >> >
> >>
> >>
> >
> >
>
>
>... la connection du dts qui lance le traitement ...
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.
> >> >
> >> >
> >>
> >>
> >
> >
>
>
>... la connection du dts qui lance le traitement ...
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" wrote in message
news:%23fvR%
> 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" a écrit dans le message de news:
>
> > 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" wrote in message
> > news:%235lwj%
> >> 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" a écrit dans le message de news:
> >> %
> >> > 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.
> >> >
> >> >
> >>
> >>
> >
> >
>
>
> - Mettre en place un profiler SQL et comparer les nombres de read et le
> temps CPU générés par la requete. Une différence importante *pourrait*
être
> due a une fragmentation importante des index. Dans ce cas, faire un DBCC
> DBREINDEX sur la base.
Un plan de maintenance est joué tout les soir avec defragmentation des
> - Mettre en place un Performance Monitor avec les objets relatifs aux
files
> d'attentes disques et CPU. Un longueur de file d'attente moyenne > 2
> indiquer une goulet d'étranglement (possiblement, débit disque moins
> important)
Les deux machines ont le meme materiel de stockage, RAID5 avec les meme
disques
> - Mettre en place un profiler SQL et comparer les nombres de read et le
> temps CPU générés par la requete. Une différence importante *pourrait*
être
> due a une fragmentation importante des index. Dans ce cas, faire un DBCC
> DBREINDEX sur la base.
Un plan de maintenance est joué tout les soir avec defragmentation des
> - Mettre en place un Performance Monitor avec les objets relatifs aux
files
> d'attentes disques et CPU. Un longueur de file d'attente moyenne > 2
> indiquer une goulet d'étranglement (possiblement, débit disque moins
> important)
Les deux machines ont le meme materiel de stockage, RAID5 avec les meme
disques
> - Mettre en place un profiler SQL et comparer les nombres de read et le
> temps CPU générés par la requete. Une différence importante *pourrait*
être
> due a une fragmentation importante des index. Dans ce cas, faire un DBCC
> DBREINDEX sur la base.
Un plan de maintenance est joué tout les soir avec defragmentation des
> - Mettre en place un Performance Monitor avec les objets relatifs aux
files
> d'attentes disques et CPU. Un longueur de file d'attente moyenne > 2
> indiquer une goulet d'étranglement (possiblement, débit disque moins
> important)
Les deux machines ont le meme materiel de stockage, RAID5 avec les meme
disques
>... 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" a écrit dans le message de news:
> les requetes se passent la nuit, application web fermées, aucun backup
> cours pendant le batch, si on regarde les process il n'y a que les
> 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" wrote in message
> news:%23fvR%
> > 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
> > Pour le moment, la seule hypothèse reste le fait que les ressources
> > sollicitées différemment sur les deux serveurs
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> >
> >
> >
> > "Cymryr" a écrit dans le message de news:
> >
> > > oui idem sur les deux serveurs pour tempdb
> > >
> > > un autre point : sur ce meme serveur j'ai eu en meme temps un
> > > avec
> > > olap, impossible de processer une cube (il n'arrivait pas a locker
> axe)
> > > Le seul truc qui a fonctionner c'ets de retirer une autre base olap
> > > avait la meme structure, pb de repository?
> > >
> > >
> > > "Med Bouchenafa" wrote in message
> > > news:%235lwj%
> > >> 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" a écrit dans le message de news:
> > >> %
> > >> > Bonjour, j'ia un énorme problème dont je n'arrive pas a sortir
> > > une
> > >> > dizaine de jours
> > >> >
> > >> > J'ai un datawarehouse, avec une table de faits d'environ 8
> de
> > >> > lignes
> > >> > toutes les nuits j'ai un batch qui tourne et qui fait un gros
> > >> > sur
> > >> > cette table
> > >> >
> > >> > Sur un serveur A , bi processeur 2 Go de ram, le traitement dure
> > >> > minutes
> > >> > Sur un serveur B , quadri processeur 4 Go de ram, le traitement
> > > 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
> > >> > 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.
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> >
> >
>
>
>... 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
> cours pendant le batch, si on regarde les process il n'y a que les
> 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
> > Pour le moment, la seule hypothèse reste le fait que les ressources
> > 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
> > > avec
> > > olap, impossible de processer une cube (il n'arrivait pas a locker
> axe)
> > > Le seul truc qui a fonctionner c'ets de retirer une autre base olap
> > > 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
> > > une
> > >> > dizaine de jours
> > >> >
> > >> > J'ai un datawarehouse, avec une table de faits d'environ 8
> de
> > >> > lignes
> > >> > toutes les nuits j'ai un batch qui tourne et qui fait un gros
> > >> > sur
> > >> > cette table
> > >> >
> > >> > Sur un serveur A , bi processeur 2 Go de ram, le traitement dure
> > >> > minutes
> > >> > Sur un serveur B , quadri processeur 4 Go de ram, le traitement
> > > 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
> > >> > 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.
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> >
> >
>
>
>... 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" a écrit dans le message de news:
> les requetes se passent la nuit, application web fermées, aucun backup
> cours pendant le batch, si on regarde les process il n'y a que les
> 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" wrote in message
> news:%23fvR%
> > 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
> > Pour le moment, la seule hypothèse reste le fait que les ressources
> > sollicitées différemment sur les deux serveurs
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> >
> >
> >
> > "Cymryr" a écrit dans le message de news:
> >
> > > oui idem sur les deux serveurs pour tempdb
> > >
> > > un autre point : sur ce meme serveur j'ai eu en meme temps un
> > > avec
> > > olap, impossible de processer une cube (il n'arrivait pas a locker
> axe)
> > > Le seul truc qui a fonctionner c'ets de retirer une autre base olap
> > > avait la meme structure, pb de repository?
> > >
> > >
> > > "Med Bouchenafa" wrote in message
> > > news:%235lwj%
> > >> 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" a écrit dans le message de news:
> > >> %
> > >> > Bonjour, j'ia un énorme problème dont je n'arrive pas a sortir
> > > une
> > >> > dizaine de jours
> > >> >
> > >> > J'ai un datawarehouse, avec une table de faits d'environ 8
> de
> > >> > lignes
> > >> > toutes les nuits j'ai un batch qui tourne et qui fait un gros
> > >> > sur
> > >> > cette table
> > >> >
> > >> > Sur un serveur A , bi processeur 2 Go de ram, le traitement dure
> > >> > minutes
> > >> > Sur un serveur B , quadri processeur 4 Go de ram, le traitement
> > > 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
> > >> > 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.
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> >
> >
>
>
