Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur SQL envoie trop de données

SQL envoie trop de données

7 réponses
Avatar
atchoum
sur une mise à jour de données entre un poste client msde 2000 et le serveur
sql 2000, 10 fois trop de données transitent, la connection se fait sur un
reseau IP avec un client en connection RTC 56 k .

quelqu'un a t il eu un jour se genre de pb ?

au lieu de transferrer 1 meg celui-ci va en passer 10 .

est du au serveur ? à la ligne, au protocole tcp / ip ?

si qqn peut m'eclairer , merci
Signaler un problème avec ce contenu

7 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
bruno reiter [MVP]
ça ne fait pas beaucoup d'indications pour chercher.

br



"atchoum" wrote in message
news:3f8e305a$0$2786$
sur une mise à jour de données entre un poste client msde 2000 et le serveur
sql 2000, 10 fois trop de données transitent, la connection se fait sur un
reseau IP avec un client en connection RTC 56 k .

quelqu'un a t il eu un jour se genre de pb ?

au lieu de transferrer 1 meg celui-ci va en passer 10 .

est du au serveur ? à la ligne, au protocole tcp / ip ?

si qqn peut m'eclairer , merci




Avatar
Fred BROUARD
quel est la nature du transfert : fichier de données, ordres SQL ?


atchoum a écrit:
sur une mise à jour de données entre un poste client msde 2000 et le serveur
sql 2000, 10 fois trop de données transitent, la connection se fait sur un
reseau IP avec un client en connection RTC 56 k .

quelqu'un a t il eu un jour se genre de pb ?

au lieu de transferrer 1 meg celui-ci va en passer 10 .

est du au serveur ? à la ligne, au protocole tcp / ip ?

si qqn peut m'eclairer , merci





--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************
Avatar
papouasia
alors aprés test : le transfert de données , (normalement ce sont bien des
données qui passent), se fait à 0.5 Ko /s au lieu de 5 ko/s en RTC 56 kb
alors qu'un fichier normal passe au taux normal de 5 à 7 ko/ s pour du 56 k
et ils reste à ce taux tout le long du telechargement.

cela vient bien de SQL ou du 9 qui restreint le protocole SQL du port 1433 ?
est ce possible ?
j'ai demandé, pour le moment pas de reponse du 9 sur leur offre vpn 9IP9 .

SQL est en mode SQL et windows. pas de spécificité particulière autre. les
nomades accèdent par RTC comme si ils étaient réseau local, on leur a
interdit le web donc ils ne sortent pas du reseau interne de la société sauf
pour le service smtp et pop je suppose mais pas sur.
la mise à jour entre la base msde et le serveur sql s'est déjà faite mais se
fait donc trés trés lentement en plus des données excessive qu'envoie SQL .

il paraitrait que en plus des requetes visible sql génère une multitude de
requète, est cela qui justifie une multiplication des données et une baisse
du débit ? je pense pas.
Avatar
papouasia
ce sont des ordres SQL

"
Avatar
Fred BROUARD
C'est assez curieux de voir des gens qui réclament de l'aide et mettent
en doute les conseils qu'on leur donne.

Donc, je répète UNE REQUETE UTILISATEUR = N REQUÊTES INTERNE.

Voila pour convaincre notre individu, je me suis amusé à tapper la
requête suivante :
SELECT *
FROM sysobjects
avec un outil de pistage.

Voici les requêtes effectuées

1 23:41:32 SQL Prepare: SQL Server - SELECT *
FROM sysobjects

2 23:41:32 SQL Execute: SQL Server - SELECT *
FROM sysobjects

3 23:41:32 SQL Vendor: ODBC - SQLAllocStmt
4 23:41:32 SQL Vendor: ODBC - SQLExecDirect
5 23:41:32 SQL Vendor: ODBC - SQLNumResultCols
6 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
7 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
8 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
9 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
10 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
11 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
12 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
13 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
14 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
15 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
16 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
17 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
18 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
19 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
20 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
21 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
22 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
23 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
24 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
25 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
26 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
27 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
28 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
29 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
30 23:41:32 SQL Vendor: ODBC - SQLDescribeCol
31 23:41:32 SQL Misc: SQL Server - Set rowset size
32 23:41:32 SQL Vendor: ODBC - SQLBindCol
33 23:41:32 SQL Vendor: ODBC - SQLBindCol
34 23:41:32 SQL Vendor: ODBC - SQLBindCol
35 23:41:32 SQL Vendor: ODBC - SQLBindCol
36 23:41:32 SQL Vendor: ODBC - SQLBindCol
37 23:41:32 SQL Vendor: ODBC - SQLBindCol
38 23:41:32 SQL Vendor: ODBC - SQLBindCol
39 23:41:32 SQL Vendor: ODBC - SQLBindCol
40 23:41:32 SQL Vendor: ODBC - SQLBindCol
41 23:41:32 SQL Vendor: ODBC - SQLBindCol
42 23:41:32 SQL Vendor: ODBC - SQLBindCol
43 23:41:32 SQL Vendor: ODBC - SQLBindCol
44 23:41:32 SQL Vendor: ODBC - SQLBindCol
45 23:41:32 SQL Vendor: ODBC - SQLBindCol
46 23:41:32 SQL Vendor: ODBC - SQLBindCol
47 23:41:32 SQL Vendor: ODBC - SQLBindCol
48 23:41:32 SQL Vendor: ODBC - SQLBindCol
49 23:41:32 SQL Vendor: ODBC - SQLBindCol
50 23:41:32 SQL Vendor: ODBC - SQLBindCol
51 23:41:32 SQL Vendor: ODBC - SQLBindCol
52 23:41:32 SQL Vendor: ODBC - SQLBindCol
53 23:41:32 SQL Vendor: ODBC - SQLBindCol
54 23:41:32 SQL Vendor: ODBC - SQLBindCol
55 23:41:32 SQL Vendor: ODBC - SQLBindCol
56 23:41:32 SQL Vendor: ODBC - SQLBindCol
57 23:41:32 SQL Stmt: SQL Server - Fetch
58 23:41:32 SQL Vendor: ODBC - SQLSetStmtOption
59 23:41:32 SQL Vendor: ODBC - SQLExtendedFetch
60 23:41:32 SQL Data Out: SQL Server - Column = 2, Name = id, Type
= fldINT32, Precision = 10, Scale = 0, Data = 1
61 23:41:32 SQL Data Out: SQL Server - Column = 3, Name = xtype,
Type = fldZSTRING, Precision = 2, Scale = 0, Data = S
62 23:41:32 SQL Data Out: SQL Server - Column = 4, Name = uid,
Type = fldINT16, Precision = 5, Scale = 0, Data = 1
63 23:41:32 SQL Data Out: SQL Server - Column = 5, Name = info,
Type = fldINT16, Precision = 5, Scale = 0, Data = 25
64 23:41:32 SQL Data Out: SQL Server - Column = 6, Name = status,
Type = fldINT32, Precision = 10, Scale = 0, Data = -536870909
65 23:41:32 SQL Data Out: SQL Server - Column = 7, Name =
base_schema_ver, Type = fldINT32, Precision = 10, Scale = 0, Data = 96
66 23:41:32 SQL Data Out: SQL Server - Column = 8, Name =
replinfo, Type = fldINT32, Precision = 10, Scale = 0, Data = 0
67 23:41:32 SQL Data Out: SQL Server - Column = 9, Name =
parent_obj, Type = fldINT32, Precision = 10, Scale = 0, Data = 0
68 23:41:32 SQL Data Out: SQL Server - Column = 10, Name = crdate,
Type = fldTIMESTAMP, Precision = 23, Scale = 3, Data = 8/6/2000
1:29:12:717000000
69 23:41:32 SQL Data Out: SQL Server - Column = 11, Name =
ftcatid, Type = fldINT16, Precision = 5, Scale = 0, Data = 0
70 23:41:32 SQL Data Out: SQL Server - Column = 12, Name =
schema_ver, Type = fldINT32, Precision = 10, Scale = 0, Data = 96
71 23:41:32 SQL Data Out: SQL Server - Column = 13, Name =
stats_schema_ver, Type = fldINT32, Precision = 10, Scale = 0, Data = 0
72 23:41:32 SQL Data Out: SQL Server - Column = 14, Name = type,
Type = fldZSTRING, Precision = 2, Scale = 0, Data = S
73 23:41:32 SQL Data Out: SQL Server - Column = 15, Name =
userstat, Type = fldINT16, Precision = 5, Scale = 0, Data = 1
74 23:41:32 SQL Data Out: SQL Server - Column = 16, Name =
sysstat, Type = fldINT16, Precision = 5, Scale = 0, Data = 113
75 23:41:32 SQL Data Out: SQL Server - Column = 17, Name =
indexdel, Type = fldINT16, Precision = 5, Scale = 0, Data = 0
76 23:41:32 SQL Data Out: SQL Server - Column = 18, Name =
refdate, Type = fldTIMESTAMP, Precision = 23, Scale = 3, Data = 8/6/2000
1:29:12:717000000
77 23:41:32 SQL Data Out: SQL Server - Column = 19, Name =
version, Type = fldINT32, Precision = 10, Scale = 0, Data = 0
78 23:41:32 SQL Data Out: SQL Server - Column = 20, Name =
deltrig, Type = fldINT32, Precision = 10, Scale = 0, Data = 0
79 23:41:32 SQL Data Out: SQL Server - Column = 21, Name =
instrig, Type = fldINT32, Precision = 10, Scale = 0, Data = 0
80 23:41:32 SQL Data Out: SQL Server - Column = 22, Name =
updtrig, Type = fldINT32, Precision = 10, Scale = 0, Data = 0
81 23:41:32 SQL Data Out: SQL Server - Column = 23, Name =
seltrig, Type = fldINT32, Precision = 10, Scale = 0, Data = 0
82 23:41:32 SQL Data Out: SQL Server - Column = 24, Name =
category, Type = fldINT32, Precision = 10, Scale = 0, Data = 2
83 23:41:32 SQL Data Out: SQL Server - Column = 25, Name = cache,
Type = fldINT16, Precision = 5, Scale = 0, Data = 0


Alors, convaincu ou toujours aussi borné ???

papouasia a écrit:
alors aprés test : le transfert de données , (normalement ce sont bien des
données qui passent), se fait à 0.5 Ko /s au lieu de 5 ko/s en RTC 56 kb
alors qu'un fichier normal passe au taux normal de 5 à 7 ko/ s pour du 56 k
et ils reste à ce taux tout le long du telechargement.

cela vient bien de SQL ou du 9 qui restreint le protocole SQL du port 1433 ?
est ce possible ?
j'ai demandé, pour le moment pas de reponse du 9 sur leur offre vpn 9IP9 .

SQL est en mode SQL et windows. pas de spécificité particulière autre. les
nomades accèdent par RTC comme si ils étaient réseau local, on leur a
interdit le web donc ils ne sortent pas du reseau interne de la société sauf
pour le service smtp et pop je suppose mais pas sur.
la mise à jour entre la base msde et le serveur sql s'est déjà faite mais se
fait donc trés trés lentement en plus des données excessive qu'envoie SQL .

il paraitrait que en plus des requetes visible sql génère une multitude de
requète, est cela qui justifie une multiplication des données et une baisse
du débit ? je pense pas.






--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************
Avatar
Med Bouchenafa [MVP]
SQL/Server s'appuie totalement sous les couches réseau de l'OS pour le transfert de données.
Le moteur lui même n'a aucune connaissance de ce que la librairie réseau peut en faire ni comment
elle peut les reconfectionner.
Voila comment les choses se passent plus ou moins.
SQL/Server confectionne des paquets TDS dont la taille par défaut est d'environ 4Ko.
Il confie ces paquets aux couches réseaux de l'OS comme tout autre application Windows.
La seule chose que l'on peut modifier est la taille des paquets confectionnés par SQL/Server.
Voir sp_confiure et l'option network packet size dans l'Aide En Ligne.
Certaines API permettent aussi de modifier ceci dans la chaine de connexion
Regarde aussi, dans l'Aide En Ligne, les fonctions globales
@@PACK_SENT
@@PACK_RECEIVED

--
Salutations
Med Bouchenafa
TETRASET
75015 Paris
"papouasia" a écrit dans le message de news:
bmm5o6$olb$
alors aprés test : le transfert de données , (normalement ce sont bien des
données qui passent), se fait à 0.5 Ko /s au lieu de 5 ko/s en RTC 56 kb
alors qu'un fichier normal passe au taux normal de 5 à 7 ko/ s pour du 56 k
et ils reste à ce taux tout le long du telechargement.

cela vient bien de SQL ou du 9 qui restreint le protocole SQL du port 1433 ?
est ce possible ?
j'ai demandé, pour le moment pas de reponse du 9 sur leur offre vpn 9IP9 .

SQL est en mode SQL et windows. pas de spécificité particulière autre. les
nomades accèdent par RTC comme si ils étaient réseau local, on leur a
interdit le web donc ils ne sortent pas du reseau interne de la société sauf
pour le service smtp et pop je suppose mais pas sur.
la mise à jour entre la base msde et le serveur sql s'est déjà faite mais se
fait donc trés trés lentement en plus des données excessive qu'envoie SQL .

il paraitrait que en plus des requetes visible sql génère une multitude de
requète, est cela qui justifie une multiplication des données et une baisse
du débit ? je pense pas.





Avatar
atchoum
merci à tous pour ces pistes