Optimisation de requete SQL avec SAS

[ganjah06]

Bonjour,

Je cherche à optimise des requetes SQL passées à Oracle (PASS_Through).
Mon probleme est que j'ai un temps d'execution sous Oracle de deux minutes (je sais c'est long) mais de vingt minutes dans le programme SAS.

Connaissez-vous des options permettant d'obtenir les memes temps de traitement entre Oracle et SAS ?

Ou un quelconque axe d'amelioration (quelqu'il soit, toutes les options sont bonnes à prendre) ?

Merci d'avance

[MEGAMIND2]

Essaies de mettre: Option COMPRESS=yes au début de ton programme, je sais que c'est réduit vachement le temps de traitement sur de grosse volumétrie dans une étape data mais et Sql, je n'ai jamais éssayé.

[olivier.decourt]

18 minutes de calcul SAS, c'est effectivement beaucoup, mais tout dépend de ce que tu demandes : y a-t-il des calculs dans le SELECT côté SAS ? Dans les données que tu extraies dans le SGBD, toutes les colonnes sont-elles nécessaires (si tu peux réduire le SELECT côté SGBD, ça te fera gagner du temps) ?
Autre piste : l'endroit où tu crées la table SAS. Si c'est un emplacement sur le réseau, ou sur un disque amovible, ça ralentit beaucoup. Si tu peux écrire sur le disque dur local, ça devrait aller plus vite. Quitte à déplacer ensuite la table avec une proc COPY vers une autre bibliothèque.

Bon courage.
Olivier

@Brice : je serais surpris qu'une compression arrive à faire gagner du temps, puisqu'il faut compresser en plus de créer la table. Par contre, pour gagner de la place, c'est une excellente idée.

[MEGAMIND2]

J'ai été confronté à ce problème et ça m'a résolu mon problème. Tant pis!

[Filippo]

Bonjour,
ajouter un index à une table peut faire gagner du temps de traitement sur cette table.

On a parlé des index dans ce sujet :

http://www.developpez.net/forums/d10...r-table-index/

[olivier.decourt]

Envoyé par MEGAMIND2

J'ai été confronté à ce problème et ça m'a résolu mon problème. Tant pis!

Non : je pense avec plutôt "tant mieux !".
Je ne mets pas le résultat en doute, je suis juste surpris. Mais peut-être qu'en cherchant on peut comprendre pourquoi.
Pour moi (mais je ne détiens aucune vérité), la compression est une opération supplémentaire, comme si on zippait la table SAS manuellement. Alors je me dis que "création+compression" ça prend plus de temps que "création" seulement.
Mais puisque tu as un contre-exemple, j'imagine que j'ai mal compris la compression et qu'il y a quelque chose à creuser ici.

[datametric]

Les mécanismes mis en place dans ORACLE sont difficilement reproductibles en SAS car ils sont spécifiques au SGBD. C'est pour cela que le remote pass-through a été initié en SAS. En SAS 9.2 c'est d'ailleurs généralisé avec le concept "in-database" qui permet à des procédures de passer l'ordre au SGBD et non de rapatrier d'abord les données sur le serveur SAS.

Pourquoi dois-tu t'affranchir du pass-through ? Tes données passent en SAS directement ?

[Filippo]

J'aurais pensé intuitivement comme Olivier à propose de compress=yes. Il semblerait que l'option compress=yes puisse quand même accelérer les traitements.

http://heuristically.wordpress.com/2...t-compression/

En revanche, lire une table compressée demande plus de CPU donc peut influer sur d'autres traitements.

http://support.sas.com/documentation...a002733268.htm

[olivier.decourt]

Ah, merci Filippo. Je vais me coucher un peu moins bête ce soir.

Donc Brice, désolé d'avoir douté, c'était ma vision de la compression qui était erronée. C'est un bon moyen de gagner du temps. Mea culpa.

[MEGAMIND2]

De rien Olivier!

[Filippo]

Envoyé par olivier.decourt

Ah, merci Filippo. Je vais me coucher un peu moins bête ce soir.

Donc Brice, désolé d'avoir douté, c'était ma vision de la compression qui était erronée. C'est un bon moyen de gagner du temps. Mea culpa.

Je pensais vraiment comme toi au départ, ça parait intuitif de se dire que la compression a un coût en terme de temps de traitement. J'ai aussi été intrigué par ce que disait Brice.

Mais ceci dit, il faut faire attention aux tables avec peu de variables et des variables numériques, ça ne marche pas à tous les coups.

[datametric]

Quand les tables ont une majorité de variables numériques, il faut privilégier COMPRESS=BINARY

[xav2229]

Afin de debugguer ce que fait SAS, ajoute un peu de trace :

Code :

1
2
3
4
5
6
proc sql _method;
   CREATE TABLE WORK.CLASS AS
   SELECT *
   FROM SASHELP.CLASS
   ;
quit;

ajoute egalement un SASTRACE

Cf la doc pour des commentaires sur _method

Sinon pense a ton ami le DBA qui pourra faire un plan d'exécution de la requête dans TOAD.


xav

[olivier.decourt]

Autre piste qui rejoint l'idée de compression (si SAS prend beaucoup de temps et que tu ne lui demandes aucun calcul, c'est qu'il passe du temps à écrire la table sur le disque) : soigner les LENGTH des variables créées côté SAS, pour qu'elles soient minimales. Par exemple, tous tes champs numériques vont utiliser 8 octets par défaut alors qu'ils pourraient peut-être en prendre moins si ce sont des valeurs entières (ici un morceau de doc pour le plus grand entier stockable avec un length de X octets sur Windows et Unix). Idem pour les variables caractère : peut-être que les CHAR ou VARCHAR Oracle ont été taillés un peu plus grands que nécessaire...

[datametric]

Je ne comprends pas en quoi l'optimisation des longueurs ou le compress modifiera le temps de ses requêtes en RSPT.

ganjah06, peux-tu revenir vers nous en nous clarifiant ton code :utilises-tu une proc SQL + CONNECT TO ORACLE ou bien une proc SQL + libname ?
Dans le cas 1 dans la partie SAS de la proc SQL + CONNECT TO ORACLE, quel type de traitement as-tu ajouté ?

[olivier.decourt]

Envoyé par datametric

Je ne comprends pas en quoi l'optimisation des longueurs ou le compress modifiera le temps de ses requêtes en RSPT.

De ses explications initiales

Envoyé par Ganjah06

Je cherche à optimise des requetes SQL passées à Oracle (PASS_Through).
Mon probleme est que j'ai un temps d'execution sous Oracle de deux minutes (je sais c'est long) mais de vingt minutes dans le programme SAS.

je déduisais : 1) que c'est du vrai pass-thru et pas un Libname et 2) que son temps de traitement long est dû aux opérations côté SAS (18 minutes de "calculs" imputables à SAS). D'où l'idée (compression, longueurs, emplacement du Libname de stockage) d'optimiser l'écriture sur disque côté SAS, qui sera sans doute un goulot d'étranglement (comme le signalait la doc de Filippo).

[datametric]

Ok c'est vrai. Pour le pur RSPT vs. libname , je préfère demander confirmation...

Connaissez-vous des options permettant d'obtenir les memes temps de traitement entre Oracle et SAS ?

Mais j'étais parti là-dessus, soit une substitution du code RSPT.

Bon bref, attendons les réponses de l'intéressé.

Bonne année.

[bahraoui]

Bonjour,

Est ce que tu peux poster ton code sur le forum?
Est ce que tu peux relancer ton code et surveiller la work pour vérifier que SAS ne rapatrie pas les tables en local avant de faire le traitement?