Discussion :

[betsoooo]

bonjour,
J'ai besoin de faire fusionner 2 tables lorsque ils ont une variable en commun sous sas.
la proc sql classique est vraiment trop longue (+de 9h pour 900Mo) .
quel est la procedure à executer pour gagner un maximum de temps sachant que une des 2 table contient plus de 100 millions de lignes!
De plus je ne peut pas la modifier sur cette même bibliothèque (oracle) et la copier sur une autre prenderai enormement de temps aussi

[Manoutz]

bonjour Betsoooo,

Je n'ai jamais travaillé sur des jeux de données aussi conséquents, intuitivement j'opterai plutôt vers sql plutôt que l'étape data étant donné que par la première méthode aucun tri n'est nécéssaire... a confirmer.

D'une manière générale il est utile de retirer/réduire tout ce qui est superflu:
1/ colonnes non nécéssaires
2/ lignes non nécéssaires
3/ optimisation de la longueur des variables.

Il est possible que le code sql soit optimisable suivant contexte.
Si tu as sas 9 il existe les hash qui permettent un gain temps non négligeable. Ca n'a rien a voir avec le programmation sas classique et je ne l'ai jamais utilisé.

ce papier compare différentes méthode de merge et expose les résultats (assez édifiants):
http://www2.sas.com/proceedings/sugi31/244-31.pdf

J'espere que ca t'aidera.

Manoutz

[Gaadek]

Hello,

Est-ce que vous avez avancé sur ce sujet?

En effet, je me penche actuellement sur l'optimisation d'un programme SAS dont la durée d'exécution s'approche des 6 heures.

J'ai noté les points qui prennent du temps dans ce programme, et il s'avère que certaines requêtes SQL pointant sur une base Oracle prennent jusqu'à 1h3à d'exécution.

J'ai entendu parlé très récemment de la méthode "hash", mais si la docu que je li est correcte, on peut la forcer sur une étape datastep, mais uniquement voir si l'optimiseur SQL de SAS l'utilise (avec l'option _method)

J'ai déjà (évidemment) limité le nombre de colonnes que je dois récupérer, mais j'ai quand même pas loin de 900Mo de données en SAS dataset après 1h30 d'exécution...

Bref, je suis vivement intéressé par toute source pour orienter mes recherches car là, je sèche un peu!

[Manoutz]

Sujet déjà abordé à plusieurs reprises dans le forum!

Un post qui peut t'aider
http://www.developpez.net/forums/d97...ables-lourdes/

[datametric]

pouvez-vous éclaircir l'usage qui est fait du SQL et le lien avec ORACLE ? est-ce du Pass-through ou de la fusion des tables SAS et ORACLE ou que ORACLE ?
Est-ce un lookup ( enrichissant une table avec des libellés par exemple) ou des fusions de table de faits ?
Si ce sont des proc SQL avec des libnames ORACLE, y-a-t-il des clauses where ?
L'espace ORACLE est-il performant sans passer par SAS ? ont-ils indexé leurs tables ?
Quel est le dimensionnement de ton serveur SAS ?

Le hash oui mais avant il y a plus simple. Tout dépend du problème. Voir un sujet d'avant l'été, j'y avais mis un bout de code montrant l'usage et sa performance.

[pmadfm]

Bonjour.

Attention à vos propos : PROC SQL va plus vite à effectuer ses tris oui mais il ne se passe pas du besoin de trier ses données.

Pour l'optimisation il existe des dizaines de méthodes applicables selon les cas, il n'y à rien de fixe, c'est l'expérience et les essais qui vous feront progresser.

Le in-database ou le passthrough ne fait pas forcement gagner du temps, si vous n'utilisez pas des fonctions inconnues du SGBD alors le SQL PASSTHROUGH implicite fonctionne parfaitement avec des temps identique à l'explicite. Vérifiez avec SASTRACE le code généré et envoyé au SGBD.

La réduction des données en colonnes et en lignes oui ça c'est toujours vrai.

Mais aussi si vous avez une très grosse table avec des petites (<50 / 100 000 lignes) alors faites des formats avec ces petites tables (référentielles) ensuite supprimez vos jointures devenues inutiles et utilisez vos formats.

Essayez d'utiliser les paramètres bufno bufsize corrects; l'option threads et éventuellement dbsliceparm=(all,8), 8 ou plus selon votre machine

Il y a aussi les buffers oracle en read update ...
Il y a aussi le DBIDIRECTEXEC
Il y a aussi le DBCOMMIT
Il y a aussi le dbslice
Il y a aussi l’option MULTI_DATASRC_OPT positionnée sur le LIBNAME (limite 4500 valeurs), sas génère automatiquement des clauses in

Attention les bulks ne sont pas souvent rentables car sas commence par créer une table dans un format particulier avant qu'Oracle ne charge cette table et de ce fait les perfs globales ne sont plus bonnes.

Voilà des pistes pour lire des documents

Mon Job est justement d'aller chez des Clients pour optimiser des requêtes, chaque environnement est différent, volume des données, puissance des machines, charge machine, nombre de FS, charge de ceux-ci ...

Bonnes recherches ...