DB2 via serveur lié MSSQL trop lent

Bonjour,

Je dois travailler sur une base de données DB2 dans un serveur AS400 disons SRV1, dont le volume est ~28.000 clients, ~200.000 articles, ~800 fournisseurs.
J’ai un serveur MSSQL disons SRV2 dans lequel j’ai installé tous les outils IBM. J’ai fait un serveur lié dans MSSQL qui se connecte à SRV1.
SRV1 et SRV2 sont dans le même réseau de type Gigabit.

En plus de MSSQL, sur SRV2 est installé :
- MSSQL studio pour faire mes requêtes TSQL ;
- Cwbundbs.exe (un outil ibm), qui permet de faire une requête SQL sur l’AS400 ;

Un SELECT * FROM ARTICLE depuis l’outil IBM se fais en 187 ms.
La même requête dans MSSQL via le serveur lié prend 5 minutes !!!!!
Les performances sont désastreuses…
je veux améliorer les choses.

J'ai posté sur le forum MSSQL :question serveur lié ,
mais je n'ai actuellement pas bcp de résultats...
J'ai publié les codes TSQL de 2 serveurs liés différents : OLE DB et ODBC.

Je viens donc aussi sur ce forum DB2 - AS400 dans l'espoir d'avoir plus de chances :mrgreen:

Est-ce-que quelque sait me dire comment atteindre les performances du client SQL de iSeries Navigator en passant par MSSQL ?

Merci de votre aide,

Nico

ça pourrait être un problème de driver.. il existe des drivers spécifiques pour ce cas s'ils ne sont pas déjà installés

ça pourrait être un problème de mémoire: les requêtes sql server internes utilisent la mémoire allouée au serveur. Les requêtes liées utilisent la mémoire OS. y en a-il assez ?

ici il ne s'agit pas de sql db2 native mais de requêtes ODBC. Si tu remplaces la requête par un appel à une procédure stockée ça ira mieux.

il y a la config d'ODBC
- placer ta datasource ODBC en read-only mode (si le driver le permet)
- activer lazy close support et pre-fetch durant EXECUTE dans ODBC setting
- ajouter "FOR FETCH ONLY" dans le select
- utiliser la requête SELECT * FROM OPENROWSET(serveur lié, 'commande SQL')

Bonjour Otario,

Merci pour ton retour.

Pour les drivers, j'ai installé tous les composants qui étaient avec le cd de iSerie navigator. Je me suis retrouvé avec des nouveaux drivers IBM pour AS400 dans ODBC et OLE DB. S'il existe un autre driver ou un autre moyen... je suis preneur.

Pour la mémoire, je ne connaissais pas ce mécanisme de répartition processus msql ou os. Toutefois, j'ai 4Go sur un serveur 2003 R2 (en 32 bits), et taskmgr.exe indique un usage constant de 1,42 Go actuellement utilisé. Donc je pense que windows peut encore monter à 3,??? Go...

Pour les procédures stockées, je ne connaissais pas non plus. Toutefois je crois bien comprendre l'idée. Comme avec les vues... En mettant le max de code SQL côté AS400, les traitements se font côté AS400. Côté MSSQL, il ne reste plus que le transfert des données. C'est ça ? Si ce n'est pas ça, as-tu un exemple pour que je puisse tester ?

Au niveau ODBC, voici les paramètres avec lesquels j'ai joué :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

/****** Objet : LinkedServer [#HOSTNAME#] Date de génération du script : 10/15/2012 12:17:18 ******/ EXEC master.dbo.sp_addlinkedserver @server = N'#HOSTNAME#', @srvproduct=N'{iSeries Access ODBC Driver}', @provider=N'MSDASQL', @provstr=N'DRIVER={iSeries Access ODBC Driver};SYSTEM=#HOSTNAME#;UID=QSECOFR;PWD=#PASSWORD#;NAM=0;CONNTYPE=2;DBQ=*USRLIBL;CMT=0;UNICODESQL=0;XDYDAMIC=0;BLOCKFETCH=1;BLOCKSIZE=1024;LAZYCLOSE=1;COMPRESSION=0;PREFETCH=1;' /* For security reasons the linked server remote logins password is changed with ######## */ EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'#HOSTNAME#',@useself=N'False',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'collation compatible', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'data access', @optvalue=N'true' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'dist', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'pub', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'rpc', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'rpc out', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'sub', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'connect timeout', @optvalue=N'0' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'collation name', @optvalue=null GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'lazy schema validation', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'query timeout', @optvalue=N'0' GO EXEC master.dbo.sp_serveroption @server=N'#HOSTNAME#', @optname=N'use remote collation', @optvalue=N'false'

---

selon la documentation suivante : http://publib.boulder.ibm.com/infoce...eneralprop.htm

Je suis donc en read-only avec CONNTYPE=2;

J'ai activé le lazyclose et le prefetch avec LAZYCLOSE=1; et PREFETCH=1;

le FOR FETCH ONLY, je n'arrive pas à le donner en TSQL. Toutefois le driver étant paramétré en lecture seule.... ca devrait le faire...

L'usage de la requete sou la forme : SELECT * FROM OPENROWSET(serveur lié, 'commande SQL') me retourne les mêmes performances que sous la forme SELECT * FROM SRVLIE.CATALOGUE.LIB.TABLE .

Sinon j'ai observé des moins bonnes performances BLOCKSIZE=8192. Par contre je n'ai pas su descendre le temps nécessaire à un SELECT * significativement. Je me demande s'il n'y a pas encore d'autres paramètres sur lesquels je pourrais jouer. Peut-être des paramètres SQL-Server ? Le format des données retournées etc... mais je commence à ne plus trop y croire.

C'est frustrant car techniquement le constat est bien là, via iSeries Access, le programme retourne les données en quelques milli-secondes et avec le serveur lié par ODBC, on parle de dizaines de secondes. Si l'encapsulation de couches peut nuire aux performances, à ce point là c'est vraiment mauvais.

Avec une table client de 27000 tuples, ca ne me classe pourtant pas dans les très grosses base de données... je me demande comment font les grands groupes.

Si vous avez d'autres pistes à me conseiller ou l'intuition de creuser plus loin dans une direction. N'hésitez pas pas :)

Merci,

nico

Par procédure stockée, il faut entendre que la requête SQL doit être stockée (créée) sur le serveur DB2 et enveloppée (compilée) par un CREATE PROCEDURE. Celle-ci est ensuite appelée par le client par un CALL SQL pour exécution. De cette façon, la requête SQL tourne en batch sur le serveur DB2 pour un gain en performance côté serveur et client.