Discussion :

[aziatedu13]

Bonjour,
j'ai un problème de performance avec mon SQL Express 2005 , amis aussi sur la standard édition.
Ma configuration de travail :

Un poste SERVER SQL sur un XP pro pack 2.
poste en XP pro pack 2 client :
J'ai une table avec 15 colonne, dont 3 de type Image:
Lorsque je fait une requete du style Select * from "nom ma table" ORDER BY "nom colonne" DESC , le nom de la colonne n'étant pas de type image.
J'obtiens bien mes résultats,
Mais lorsque ke je fait une requete de style select , ou update sur la même table a partir de mon 2eme poste server, SQL bloque et met a peut près 10 min pour sortir Un enregistrement !!! dans le code C++, dans le SQLEXEC, je ne reprend la main que 10 min après avoir émis la requête...
J'ai bien configuré le Module MARS,
Je poste donc mon problème car je en suis pas un pro de SQL SERVER, mais je demande donc conseil, et il existe peut etre des module a activer, installer au autre pour pouvoir effectuer des updates et des select en meme temps sr le meme poste server a partir de plusieurs clients.
Merci de vos conseil, Cordialement.

[aziatedu13]

Je rajoute aussi, que lorsque je ferme le premier client, SQL ne se débloque pas, et impossible de faire la moindre requête sur la table en question, ou alors elle prend un temps énorme, du style 15 min,
Il doit y avoir un problème quelque part, et en plsu il s'agit de requete basique....

[SQLpro]

Si vous avez des colonnes de type image, la rapidité d'affichage va dépendre du volume des données des flux d'image et de la qualité de votre réseau. Si vos images font 2 Go, ne vous étonnez pas de cette lenteur ! Ce serait même très rapide !

A +

[aziatedu13]

OK, alors je vous décrit le test exact :

A partir du premier client, je fait la requêtes select * from ma table order by nomcolonne DESC

Les résultat sont bien afficher, ok, dans le l'outil profilerSQL de SQL standard, je peut voir écrit 'SQL:BatchComplete',
Cela me semble bien déja, et donc a partir de là, avec le 2eme client, je fait sur la meme table, select " nom d'une colonne" from "nom de la meme table que précédemment "
Et la , SQL broute, et dans le profiler, il y a marquer 'SQL:BAtchStarting", mais n'en fini plus....
Lorsque je remplace dans ce test, le client par l'éditeur de requête manuel, même problème, LE SQL management tools , est en exécute la requête, mais ne me donne pas de résultat, ou au bout de 15 min, et ceux, avec une simple requête basique...
Il semble que la table soit bloker par la premiere requete...et que l'on ne peut pas demander trop a la BD sur une meme table, meme avec le module Mars enabled,
Cela vous semble t-il dut o image??
Je précise que les images ne sont pas de grosse taille, et elle doivent faire pas plu que 500Ko, en faite ce ne sont pas des image, mais des coordonné en x,y,z pour tracer des image, ce ne sont aps des images a proprement dites, mais des donnée permettant de les tracé, ce tracé se fait dans une fonction a part dans mon logiciel, d'ou leur petite taille, mais elle nécessite quand meme d'étre stoker dans des type IMAGE.
Cordialement.

[SQLpro]

Dans quel outil client faites vous cela ?

Une discussion récente à eut lieu à ce sujet et la réponse que j'ai apportée devrait être la même.

A +

[aziatedu13]

Je suis sur SQL Native client,
pouvez vous me donnez le lien de votre réponse ?
Merci.

[aziatedu13]

J'au trouvé cette discution,
http://www.developpez.net/forums/d65...equete-select/

Mais ma table est bien indexé...

[aziatedu13]

Je tien aprécisé que la consultation de la table par 2 client simultanément fonctionne très bien, mais que si un client consulte la table, avec l'instruction select * from ma table, et que le 2eme client , fait un update ou un insert, apres que la requete du premer s'est bien terminé, sql patine,
les colonne clé sont bien indexé.

J'appele colonne clé les colonne de clé primaire, ou les colonne où les clauses 'where' test souvent d'autre colonne que les clé primaire.
Il y aurai il t-il une autre idée que les index ???
Merci.

[SQLpro]

AMHA c'est le SELECT * qui pose problème (ne JAMAIS utiliser);

A +

[aziatedu13]

J'ai mis Select * , pour ne pas dire toute les colonnes,masi je ne met jamasi *, et bien les nom de toutes les colonne, c un abut de language de ma part.

Apres mur réflexion, Ce n'est pas le Select "tt les colonne " ki plante , mais la requete ci-après :

Je penser que c'était el dernier SELECT qui planté, Mais non, il fonctionne très bien,
Le Update n'est meme pas exécuté , et je ne le voit meme pas dans le SQL SERVER PROFILER, et SQL rame bien au niveau de cette requete :

UPDATE _40001000_ SET "_40000002_" = ? , "_40000033_" = ? , "_40000034_" = ? ,

"_40000035_" = ? , "_40000036_" = ? , "_40000037_" = ? , "_40000038_" = ? ,

"_40000039_" = ? , "_40000040_" = ? , "_40000041_" = ? , "_40000042_" = ? ,

"_40000043_" = ? , "_40000046_" = ? , "_40000048_" = ? , "_40000049_" = ? ,

"_40000050_" = ? , "_40000051_" = ? , "_40000052_" = ? , "_40000053_" = ? ,

"_50001011_" = ? , "_40000055_" = ? , "_40000056_" = ? , "_40000060_" = ? ,

"_40000061_" = ? , "_50001008_" = ? , "_40000101_" = ? , "_50001010_" = ? ,

"_40000100_" = ? , "_50001014_" = ? , "_30002180_" = ? , "_50001013_" = ?

WHERE ("_40000002_" = ? )


_30002180_ et _50001013_ sont des colonne de type Image, et les donné passé par "?" ne sont pas NULL,
Peut être que le Update est mal fait et qu'il faut l'optimiser ???
Toute les colonnes son de type int ou Char, sauf les 2 dernières,
_30002180_ et _50001013_ sont de type IMAGE.
En sachant que cette base, et le même code, et les même requête ne pose aucun problème sous ACCES.
Merci.

[SQLpro]

Je comprend maintenant mieux votre problème... Votre modèle n'étant visiblement pas normalisé n'espérez aucune performances... Quel est l'intérêt de mettre à jour simultanément n colonnes redondantes qui plus est de type image ?
Une base de données n'est pas optimisée pour gérer des flux binaires, mais des données requêtables.

A +

[aziatedu13]

Je ne comprend pas votre remarque,
Il n'est pas normalisé d'avoir une table comme suit :

Ma table
{

int id ,PKI + COUNTER
varchar(255) toto
varchar(255) titi
int num1,
int num 2

IMAGE BOBO
IMAGE POPO
}

Vouloir mettre a jour un row de la table, en remplaçant les valeur de certaine colonne, INT,varchar ou Image de ce rows, n'est pas normalisé ????
C'est identique que de faire la meme chose sur une table classique du style :
Mon autre table
{
int id PKI+COUNTER
varchar(255) titi
}
faire un UPADATE sur id et titi en meme temps sur la table "mon autre table" est identique a un update sur certain champs et en meme temps de la table "ma table".

Je ne voit aucune différence, ni ce que vous voulai dire par la redondance de colonne...
Quelles s'apele _40000xx_ ou ID, c'est sans importance.
Peut etre que les '?' pose probleme dans mon cas, mais je fait juste un remplacement de parametre dans ma requete.
Est source de probleme ???
Je n'est pas mis de colonne en trop, je veut effectivement updaté toute les colonne décrite précédement.
Merci.

[SQLpro]

Là vous avez 31 colonnes images numérotés de _40000002_ à _50001008_". Ne vous étonnez donc pas des performances catastrophiques que cela engendre !!! Un SGBDR c'est pas des fichiers COBOL...
Sachez qu'en audit à partir de plus de 20 colonnes par table, je flingue, à moins de me donner une sacrée bonne raison pour ce faire...

Visiblement vous avez dû sécher les cours de modélisation. Dans un cas comme cela vous auriez du faire une table fille du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
T_IMAGE_IMG
(IMG_ID PRIMARY KEY,
 XXX_ID FOREIGN KEY REFERENCES table fille,
 IMG_NUM INT NOT NULL,
 IMG_IMAGE VARBINARY(max))

Et donc vous retrouver avec une table contenant par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
IMG_ID WWW_ID IMG_NUM      IMG_IMAGE
------ ------ ------------ --------------
1      aaa    40000002     ....
2      aaa    50001008     ......
...
493    bbb    40000002     ....

A +

[aziatedu13]

Merci de vos réponse , mai on a du mal se comprendre,
Je n'ai que 2 colonne de type Image, les deux dernières de ma requete,
Les autres Colonnes sont de type int ou varchar,
Vous affirmé que jusqu'a 20, cela est acceptable, donc 2 convient dans mon cas.

Donc en reprenant ma question précedente, le Update sur ma requete décrite plus haut, avec 2 colonne Imagine, est ce génant ?

CADRE DE MES QUESTION :
Je suis en apprentissage, je n'ai pas eu de cours poussez en Base de données, mais mon patron me demande de travailler sur un programme vieux de 20 ans,
donc je fait de mon mieu avec ce que j'ai.
Si vous avez de bon cours a me conseiller sur les modélisatio net conception de BD, je les prend volontiers.
Merci.

[aziatedu13]

OK, alors je suis sur que le type image , la conception etc , n'est pas en cause, ( meme si la conception n'est pas forcmement optimisé, ) ,
Je m'explique :

Je lance Sur mes 2 poste client le SQL management TOOL ,qui se connecte a un 3eme poste, le serveur:

Sur le premier client je fait la requete :

SELECT "NOM DE TOUTES MES COLONNE" from "ma table" ORDER BY "une colonne" DESC

la requête s'effectue , en a peut pres 15 seconde.
Mais si pendant ces 15 secondes, a partir du 2eme client, je lance une requête de UPDATE sur une des colonne de "ma table", le 2eme client est obliger d'attendre que le premier client ai récupéré toute les enregistrement de sa requête, pour donné le droit au 2eme client de faire un UPDATE sur "ma table",
Est ce normale ??
Mon probleme est plutot celui la, peut importe l'update sur des champs Image ou non, un simple Update d'une colonne n'est pas possible si le premeire client n'a pas fini de faire la requete SELECT...Je penser que MARS servai a ça...

[mikedavem]

Bonjour,

Cette situation est normale. Vous sélectionnez l'ensemble des enregistrements de votre table.

SQL Server va poser un verrou partagé sur l'ensemble de votre table avec le niveau d'isolations de transactions par défaut (READ COMMITED). Ceci garantit que les données remontées de votre instruction SELECT soit correcte.

Voici un ptit lien pour plus de détails

++

[aziatedu13]

J'ai fait des recherche, et j'ai trouver mon genre de problème,
Il s'agit des "connections concurrente",
Dans un billet de blog intitulé SQL Server : Gestion des transactions, verrous et concurrence d’accès aux données de Christian Robert il est dit que cela est bien gérer, et qu'il n'y a pas de soucis...

Je n'ai pas toucher à la conf de base du server...
Big problème la....

[aziatedu13]

OK super, c'est bien mon problème,
Donc si je comprend bien, pour résoudre mon pb, je doit mettre
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
Je vais essayer ça, et je vous dit,

[aziatedu13]

Bah...
Ca ne marche toujours pas...
J'ai bien configuré en mode READ UNCOMMITED, mais je plante toujours quan je veux faire un UPDATE sur des enregistrements qui sont lu avec un SELECT...
De ce que j'ai compris, le READ UNCOMMITED ne met aucun verrous sur les enregistrement lu, donc on devrai pouvoir UPDATE quand on veut...
Est je bien compris ou suis je à la ramasse ?

[aziatedu13]

OK, j'ai résolu mon problème en exécutant directement avant chaque requête de mon programme la configuration en READ UNCOMMITED, c'est assez brutale,
mais ça me débloque,
Le soucis est que je suis maintenant quoi qui se passe dans ce mode, et il y a beaucoup de problème lier a celui la.
Je ne voit pas comment faire autrement si 1 client veut lire une table, et un autre client veut en mêmetemps, mettre a jour cette même table,
Somme nous obliger d'être dans ce mode dans tout le programme ?
Sachant qu'il n'y a pas de mode consultation uniquement ou écriture uniquement dans mon programme.
C'est un programme déployer sur des machine différent, qui peut a tout moment, lire dans la base, et la mettre a jour.
Donc 2 client cohabitant, cela pose problème...
Il y a t-il des solutions ?
Si vous avez des explication, ou des liens expliquant cela, ou aide a gérer tout ça, je vous en remercie.
Cordialement.