Bonjour,

Nous avons installé sur un serveur une instance de SQL 2005 et Biztalk2006.
Le but étant de faire tourner des orchestrations permettant de répliquer des
données vers un autre serveur SQL.

Nous rencontrons de gros problème de performances. Le serveur tourne sous
Windows 2003 SP1 et dispose de 4 GB de mémoire

Avez-vous une idée

Bonjour,

des idées, oui mais pour savoir si elles conviennent Ã*** votre cas, il faut
nous en dire un peu plus : votre CPU est Ã*** 100%, votre mémoire saturée,
c'est lent mais la CPU est OK ? Pour votre réplication, vous faîtes du
debatching, des boulces xpath ? Vous avez 4 Go, mais le serveur est-il
configuré en 3 GB ?

Bref, si vous avez quelques informations complémentaires...

Cdt,

P. Manac'h
MCS France

"Robert" <Robert***discussions.microsoft.com> a écrit dans le message de news:
C7DE2ADB-6857-413B-9A61-2065EFFEB97C***microsoft.com...
> Bonjour,
>
> Nous avons installé sur un serveur une instance de SQL 2005 et
> Biztalk2006.
> Le but étant de faire tourner des orchestrations permettant de répliquer
> des
> données vers un autre serveur SQL.
>
> Nous rencontrons de gros problème de performances. Le serveur tourne sous
> Windows 2003 SP1 et dispose de 4 GB de mémoire
>
> Avez-vous une idée
>

Bonjour,

des idées, oui mais pour savoir si elles conviennent Ã*** votre cas, il faut
nous en dire un peu plus : votre CPU est Ã*** 100%, votre mémoire saturée,
c'est lent mais la CPU est OK ? Pour votre réplication, vous faîtes du
debatching, des boulces xpath ? Vous avez 4 Go, mais le serveur est-il
configuré en 3 GB ?

Bref, si vous avez quelques informations complémentaires...

Cdt,

P. Manac'h
MCS France

"Robert" <Robert***discussions.microsoft.com> a écrit dans le message de news:
C7DE2ADB-6857-413B-9A61-2065EFFEB97C***microsoft.com...
> Bonjour,
>
> Nous avons installé sur un serveur une instance de SQL 2005 et
> Biztalk2006.
> Le but étant de faire tourner des orchestrations permettant de répliquer
> des
> données vers un autre serveur SQL.
>
> Nous rencontrons de gros problème de performances. Le serveur tourne sous
> Windows 2003 SP1 et dispose de 4 GB de mémoire
>
> Avez-vous une idée
>

Le CPU est quasi en permancence Ã*** 100%
La mémoire disponible est de 4B.
le /3GB est positionné. L'instance de SQL utilise 3 GB.
On ne pas de debatching ni de boucle xpath.
Nos ochestrations consistent Ã*** importer des fichiers txt vers un serveur
SQL. L'écriture dans le fichier SQL s'effectue par procédue stockée.
Le traçage de l'adaptateur SQL montre qu'il n'effectue que peu d'insertion
(seulement 10 lignes ont été insérée en un week-end).
Pour chaque ochestration, le traitement par lot a été réduit Ã*** 1 dans le
port de réception.

Le CPU est quasi en permancence Ã*** 100%
La mémoire disponible est de 4B.
le /3GB est positionné. L'instance de SQL utilise 3 GB.
On ne pas de debatching ni de boucle xpath.
Nos ochestrations consistent Ã*** importer des fichiers txt vers un serveur
SQL. L'écriture dans le fichier SQL s'effectue par procédue stockée.
Le traçage de l'adaptateur SQL montre qu'il n'effectue que peu d'insertion
(seulement 10 lignes ont été insérée en un week-end).
Pour chaque ochestration, le traitement par lot a été réduit Ã*** 1 dans le
port de réception.

Bonjour,

la CPU est elle Ã*** 100 % seulement quand vous faîtes des imports ? Est-ce SQL
ou Biztalk qui sature la CPU ?

Cdt,

P. Manac'h
MCS France

"Robert" <Robert***discussions.microsoft.com> a écrit dans le message de news:
EF35B937-58F5-472B-ABA4-67E777EF5886***microsoft.com...
> Le CPU est quasi en permancence Ã*** 100%
> La mémoire disponible est de 4B.
> le /3GB est positionné. L'instance de SQL utilise 3 GB.
> On ne pas de debatching ni de boucle xpath.
> Nos ochestrations consistent Ã*** importer des fichiers txt vers un serveur
> SQL. L'écriture dans le fichier SQL s'effectue par procédue stockée.
> Le traçage de l'adaptateur SQL montre qu'il n'effectue que peu d'insertion
> (seulement 10 lignes ont été insérée en un week-end).
> Pour chaque ochestration, le traitement par lot a été réduit Ã*** 1 dans le
> port de réception.

Bonjour,

la CPU est elle Ã*** 100 % seulement quand vous faîtes des imports ? Est-ce SQL
ou Biztalk qui sature la CPU ?

Cdt,

P. Manac'h
MCS France

"Robert" <Robert***discussions.microsoft.com> a écrit dans le message de news:
EF35B937-58F5-472B-ABA4-67E777EF5886***microsoft.com...
> Le CPU est quasi en permancence Ã*** 100%
> La mémoire disponible est de 4B.
> le /3GB est positionné. L'instance de SQL utilise 3 GB.
> On ne pas de debatching ni de boucle xpath.
> Nos ochestrations consistent Ã*** importer des fichiers txt vers un serveur
> SQL. L'écriture dans le fichier SQL s'effectue par procédue stockée.
> Le traçage de l'adaptateur SQL montre qu'il n'effectue que peu d'insertion
> (seulement 10 lignes ont été insérée en un week-end).
> Pour chaque ochestration, le traitement par lot a été réduit Ã*** 1 dans le
> port de réception.

Bonsoir,

Le problème peut venir aussi de la taille des fichiers texte importés. Quels
sont leur taille ?
BizTalk supporte des flux jusqu'a 100 Mo mais lorsqu'un flux dépasse les
20Mo, il peut s'avérer que BizTalk peine Ã*** charger le flux et Ã*** le traiter
en mettant le serveur Ã*** genou ! D'autant plus si vous traiter le flux avec
des boucles XPath.

arno - http://www.dotnetguru2.org/acleret/


<DIV>&quot;Patrice Manac'h&quot; &lt;patmanac***online.microsoft.com&gt; wrote
in message news:%238Z2DpC0GHA.3656***TK2MSFTNGP04.phx.gbl...</DIV>> Bonjour,
>
> la CPU est elle Ã*** 100 % seulement quand vous faîtes des imports ? Est-ce
> SQL ou Biztalk qui sature la CPU ?
>
> Cdt,
>
> P. Manac'h
> MCS France
>
> "Robert" <Robert***discussions.microsoft.com> a écrit dans le message de
> news: EF35B937-58F5-472B-ABA4-67E777EF5886***microsoft.com...
>> Le CPU est quasi en permancence Ã*** 100%
>> La mémoire disponible est de 4B.
>> le /3GB est positionné. L'instance de SQL utilise 3 GB.
>> On ne pas de debatching ni de boucle xpath.
>> Nos ochestrations consistent Ã*** importer des fichiers txt vers un serveur
>> SQL. L'écriture dans le fichier SQL s'effectue par procédue stockée.
>> Le traçage de l'adaptateur SQL montre qu'il n'effectue que peu
>> d'insertion
>> (seulement 10 lignes ont été insérée en un week-end).
>> Pour chaque ochestration, le traitement par lot a été réduit Ã*** 1 dans le
>> port de réception.
>

Bonsoir,

Le problème peut venir aussi de la taille des fichiers texte importés. Quels
sont leur taille ?
BizTalk supporte des flux jusqu'a 100 Mo mais lorsqu'un flux dépasse les
20Mo, il peut s'avérer que BizTalk peine Ã*** charger le flux et Ã*** le traiter
en mettant le serveur Ã*** genou ! D'autant plus si vous traiter le flux avec
des boucles XPath.

arno - http://www.dotnetguru2.org/acleret/


<DIV>&quot;Patrice Manac'h&quot; &lt;patmanac***online.microsoft.com&gt; wrote
in message news:%238Z2DpC0GHA.3656***TK2MSFTNGP04.phx.gbl...</DIV>> Bonjour,
>
> la CPU est elle Ã*** 100 % seulement quand vous faîtes des imports ? Est-ce
> SQL ou Biztalk qui sature la CPU ?
>
> Cdt,
>
> P. Manac'h
> MCS France
>
> "Robert" <Robert***discussions.microsoft.com> a écrit dans le message de
> news: EF35B937-58F5-472B-ABA4-67E777EF5886***microsoft.com...
>> Le CPU est quasi en permancence Ã*** 100%
>> La mémoire disponible est de 4B.
>> le /3GB est positionné. L'instance de SQL utilise 3 GB.
>> On ne pas de debatching ni de boucle xpath.
>> Nos ochestrations consistent Ã*** importer des fichiers txt vers un serveur
>> SQL. L'écriture dans le fichier SQL s'effectue par procédue stockée.
>> Le traçage de l'adaptateur SQL montre qu'il n'effectue que peu
>> d'insertion
>> (seulement 10 lignes ont été insérée en un week-end).
>> Pour chaque ochestration, le traitement par lot a été réduit Ã*** 1 dans le
>> port de réception.
>

Les service Biztalk et SQL Server saturent le CPU a part égale.
Même lorsqu'aucune ochestration ne tournait, le simple fait d'exécuter la
console d'administration de Biztalk sature le CPU.

Les service Biztalk et SQL Server saturent le CPU a part égale.
Même lorsqu'aucune ochestration ne tournait, le simple fait d'exécuter la
console d'administration de Biztalk sature le CPU.

La taille des fichiers est de 50 K environ. On souhaite traiter 1000 fichiers
de 50 K. Chaque fichier représente 200 lignes Ã*** insérer.

Est-ce qu'un flux représente un fichier ou l'ensemble des fichiers Ã*** traiter ?