Problème taille des tables.

[CoriS-FrosT]

Bonjour tout le monde,

Je ne suis pas sur de poster au bon endroit, veuillez donc m'excuser d'avance au cas où.

Je ne sais pas si quelqu'un a déjà observé ce souci sous SAS/(SHARE?) (proche de celui de Microsoft Access où il faut compacter la base régulièrement pour flusher l'ensemble des données non utilisées mais réellement bien effacées).

En effet, pour éviter les problèmes de lecture/écriture, l'option choisie (peut-être à tort à cause du métier) est de passer par une procédure sql pour supprimer une ligne et une autre pour insérer une nouvelle ligne.

Le souci, est que lors de ces différentes opérations, la table finit par grossir de façon exagérée. Ainsi que les triggers, je veux dire par là que si on a supprimer une ligne avec un champ incrémental à 10 par exemple, le chiffre 10 n'est plus disponible, malgré la suppression. La ligne suivant sera donc 11...

La solution est pour l'instant, de passer par un data set, style data toto set toto. Ce qui a pour effet de réduire la taille de la table toto de 3Go à 300Mo. Comme si on a "compacté" sous Access pour ceux qui connaissent le souci sous Access...

Connaîtriez vous une solution qui permettrait de "compacter" la base ? Car le data set, s'il a pour effet de réduire la taille en flushant les données inutiles, c'est une opération longue car le moteur SAS parcourt ligne à ligne la table initiale de 3Go qui en fait, n'est que de 300Mo après lecture...

C'est un truc assez étrange, si vous avez une idée, solution, ou une documentation, je suis preneur et vous remercie bien d'avance =)

Pour info, la librairie est en option compress=binary


Michel

[datametric]

Si tu veux compacter tes tables de façon automatique il n'y a que COMPRESS=YES lorsque les tables ont plutôt plus de variables alphanumériques et COMPRESS=BINARY lorsque les tables ont plutôt plus de variables numériques.

tu peux dimensionner correctement tes champs également.

Ensuite, tu peux gérer plus finement les observations à supprimer mais je ne suis pas certain que la sueur générée soit payante.

Quant à SAS / SHARE, c'est un module spécifique pour le partage des tables en écriture...

[Manoutz]

Autre possibilité, supprimer les variables inutiles.

De souvenir ce thème à déjà été abordé dans des précédents sujets, en cherchant un peu sur le forum tu devrais trouver des infos plus précises.

Manoutz

[olivier.decourt]

Je n'ai peut-être rien compris, mais j'ai l'impression qu'il ne s'agit pas forcément du problème classique de gain de place.
Si j'ai suivi, les suppressions d'observations via la proc SQL ne sont que des suppressions logiques (cf. la fonction ATTRN et les distinctions subtiles entre les comptages d'observations dans une table). Et que du coup, la table enfle démesurément en mémoire alors que son nombre d'observations logiques reste stable.
L'étape DATA remet tout ça à plat puisqu'elle n'écrit que les observations qui ne sont pas marquées pour une suppression logique.

Je n'ai pas encore eu le temps de faire des tests pour vérifier cette analyse ; mais si c'était le cas, il faudrait chercher un moyen de forcer le SQL à une suppression physique de l'observation et non logique (mais du coup, on reviendrait à un processus coûteux en temps, j'imagine).

[bahraoui]

Bonjour,

Je viens de faire le test suivant :

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
 
/*Suppression à l'aide d'une étape data*/
DATA t;
do i=1 TO 1000000;
	k=i;
	ou1="sdfqsdfsqdfsdf";
	ou2="sdfqsdfsqdfsdf";
	ou3="sdfqsdfsqdfsdf";
	ou4="sdfqsdfsqdfsdf";
	ou5="sdfqsdfsqdfsdf";
	output;
end;
run;
 
 
DATA t; SET t;
WHERE k < 10000;
run;
DATA _null_;
   dsid=open("t");
   NOBS=attrn(dsid,"NOBS");
   NLOBS=attrn(dsid,"NLOBS");
   put "delete etape data" nobs= nlobs;
run;
 
/*suppression des données en sql avec un delete*/
DATA t;
do i=1 TO 1000000;
	k=i;
	ou1="sdfqsdfsqdfsdf";
	ou2="sdfqsdfsqdfsdf";
	ou3="sdfqsdfsqdfsdf";
	ou4="sdfqsdfsqdfsdf";
	ou5="sdfqsdfsqdfsdf";
	output;
end;
run;
proc sql;
DELETE FROM t 
WHERE k > 10000;
quit;
DATA _null_;
   dsid=open("t");
   NOBS=attrn(dsid,"NOBS");
   NLOBS=attrn(dsid,"NLOBS");
   put "delete sql " nobs= nlobs;
run;
/*suppression des données en sql : création d'une nouvelle table*/
 
DATA t;
do i=1 TO 1000000;
	k=i;
	ou1="sdfqsdfsqdfsdf";
	ou2="sdfqsdfsqdfsdf";
	ou3="sdfqsdfsqdfsdf";
	ou4="sdfqsdfsqdfsdf";
	ou5="sdfqsdfsqdfsdf";
	output;
end;
run;
proc sql;
CREATE TABLE t AS
SELECT * 
FROM t 
WHERE k < 10000;
quit;
DATA _null_;
   dsid=open("t");
   NOBS=attrn(dsid,"NOBS");
   NLOBS=attrn(dsid,"NLOBS");
   put "delete create table sql " nobs= nlobs;
run;

le delete en sql : les données sont supprimées logiquement et non physiquement.
Pour supprimer les données physiquement il faut recréer la table.
Sauf si il y a des options qui nous permettrons de le faire avec un delete sql.
Exécuter le code ci-dessus et regarder à chaque étape la taille des tables à partir de l'explorateur windows.

Cordialement

[datametric]

REMOVE permet la suppression physique d'une observation. Il faut utiliser MODIFY et non SET dans ce cas.

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

[bahraoui]

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

Note: For PROC SQL tables, SAS deletes the data in the rows but retains the space in the table.

La proc SQL ne libère pas l'espace dans la table après suppression.

[Géraldine_Cade_SAS]

Bonjour,

C'est en effet le fonctionnement normal et documenté de l'instruction DELETE.

Pour que les suppressions logiques soient appliquées physiquement, il y a 2 solutions :
- relire en étape DATA :
data MaTable ; set MaTable ;
- ou bien trier la table
proc sort data=MaTable.

Géraldine Cade-Deschamps

[olivier.decourt]

Bonjour.
J'ajouterai une 3e solution à la liste de Géraldine : la proc Copy.
En effet, comme je viens de le lire dans une doc (ce qui m'a fait repenser à cette discussion) :

In the world of PROC COPY, a true copy of a data set means exactly that — take this data set in this library and create a new
data set in another library that contains exactly the same attributes and observations. Exactly the same observations are in the
output data set with one slight difference: all the deleted observations are removed and not copied to the output data set.

Mais malheureusement la proc Copy ne peut copier qu'une table de même nom d'une bibliothèque à une autre ; et on ne peut pas truander en indiquant sous deux noms logiques (librefs) différents le même emplacement physique.

Alors continuons le même article et glissons à la proc APPEND : là on tient quelque chose qui fonctionne.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
DATA t;
do i=1 TO 1000000;
    k=i;
    ou1="sdfqsdfsqdfsdf";
    ou2="sdfqsdfsqdfsdf";
    ou3="sdfqsdfsqdfsdf";
    ou4="sdfqsdfsqdfsdf";
    ou5="sdfqsdfsqdfsdf";
    output;
end;
run;
proc sql;
DELETE FROM t
WHERE k > 10000;
quit;
PROC APPEND DATA=work.t BASE=work.t2 FORCE ;
RUN ;

On obtient une copie rétrécie de la table. Certes c'est une copie, mais il n'est pas coûteux en temps de virer l'existant et de renommer la copie (un tour de magie classique) :

Code :

1
2
3
4
PROC DATASETS LIB=work NOLIST ;
  DELETE t ;
  CHANGE t2=t ;
RUN ; QUIT ;

Est-ce qu'au final on ira plus vite qu'en faisant une étape DATA ? il faudra bien sûr tester sur les vraies données.
A tester.

Olivier

[xav2229]

si tu enleves des lignes tu dois egalement en ajouter de temps en temps non?

tu peux mettre REUSE=YES sur la table et voir ce qui ce passe coté taille de fichier.

cela devrait marcher meme pour du SHARE

[xav2229]

Oui cela fonctionne :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
proc sql;
   CREATE TABLE UTPE.TESTLOAD(compress=yes reuse=yes)
   (i num
   ,a char(20)
   )
   ;
 
quit;
 
Ajout de 100 000 observations, taille : 3 219 456
 
DELETE de 100 000 observations, taille : 3 219 456
 
Ajout de 100 000 observations, taille : 3 260 416

xav