Thema "Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster" in CoDe SAS German

SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

basefan — Fri, 28 Jul 2017 09:49:55 GMT

Hallo zusammen,

im "alten" SAS Display Manager bzw. dem sas.exe auf dem PC wurde im Explorer-Fenster (ziemlich schmal und links aussen) in der Spalte "Modified" Datum/Uhrzeit der letzten Änderung angezeigt.

Das war bzw. ist hilfreich, wenn man seine Daten aufräumen will, z.B. alle alten Data Sets löschen will.

Im EG gibt es unten links das Fenster "Server", dort werden alle Libraries angezeigt. Wenn ich eine Library aufklappe sehe ich die Data Sets innerhalb der Library, aber ohne die Details (Size, Type, Description, Modified). Im Windows-Explorer kann man die Details mit Ansicht->Details einschalten. Gibt es diese Möglichkeit im SAS-EG auch?

Als Not-Lösung habe ich versucht das Data-Set-Datum über rechte Maustaste -> Properties zu finden, aber in dem Properties-Fenster gibt es im Reiter "General" zwar Type, Description, Server, Library, Indexed und Read Only, aber kein "Modified". Über die Properties komme ich also auch nicht an Datum/Uhrzeit der letzten Änderung.

Kann es wirklich sein, dass diese Grundfunktion im EG fehlt?

Gruß aus Betzdorf

Hans

Wir arbeiten mit dem EG 7.13 (64-bit) bzw. mit SAS 9.4 (TS1M3) auf dem Win-7-Client und SAS 9.4 (TS1M3) auf dem Linux-Server.

Re: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

andreas_lds — Fri, 28 Jul 2017 09:55:25 GMT

Ja, die Funktion fehlt an der Stelle wirklich.

Interessant ist aber: sobald man ein Dataset geöffnet hat und dann die Eigenschaften öffnet, also nicht über das Server-Fenster, sonder über die Dataset-Ansicht, dann steht dort wann das Dataset erstellt und wann es zuletzt modifiziert wurde.

Spontane Idee: Über sashelp.vtable sollte das Modifikationsdatum ermittelbar sein, dann könne man das Löschen via Code erledigen.

Die gute alte Catalog-Ansicht fehlt im EG leider auch.

Re: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

CKothenschulte — Fri, 28 Jul 2017 10:05:57 GMT

andreas_lds schrieb:

Spontane Idee: Über sashelp.vtable sollte das Modifikationsdatum ermittelbar sein, dann könne man das Löschen via Code erledigen.

Alternativ über die beliebte Prozedur CONTENTS:

proc contents data=sashelp._all_ out=work.test noprint;
run;

Die Spalten CRDATE und MODATE enthalten dann die entsprechenden Zeitstempel.

Re: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

mfab — Fri, 28 Jul 2017 10:06:53 GMT

Tatsächlich nehme ich für solche Abfragen auch immer "sashelp" bzw. "dictionary".

Interessant finde ich in dem Zusammenhang allerdings, dass auch die Anwendungsroutine "Dateien und Formate löschen ..." zwar eine Spalte "Modifiziert" anbietet, diese allerdings leider nicht befüllt ist. Dies würde die eigentliche Anforderung (Manuelle Prüfung und ggf. Löschen anhand letztem Änderungsdatum) genau erfüllen - wäre denn die Spalte "Modifiziert" befüllt... (eGuide 7.13)

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

Dennis_V — Fri, 28 Jul 2017 10:21:37 GMT

Es gibt auch die Alternative mit der ATTRN-Funktion im Makro zu Arbeiten.

%LET DSID = %SYSFUNC(OPEN(SASHELP.CLASS));
%LET MODTE = %SYSFUNC(ATTRN(&DSID,MODTE),DATETIME.);

%PUT &MODTE.;

Viele Grüße

Dennis

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

Kurt_Bremser — Fri, 28 Jul 2017 10:33:11 GMT

Ich habe das schon mal als Idee zur Abstimmung vorgelegt:

https://communities.sas.com/t5/SASware-Ballot-Ideas/Activate-Properties-for-Files-and-Folders-in-Enterprise-Guide/idi-p/332927

Hat leider nicht viele Befürworter gefunden.

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

basefan — Mon, 31 Jul 2017 12:01:15 GMT

Hallo zusammen,

danke für die Ideen&Anregungen wie man das Problem umschiffen kann.

Mein Problem ist meine Zielgruppe. Für die soll es so enfach wie möglich sein und schnell mal einen Macro schreiben fällt nicht unter "so einfach wie möglich".

@Kurt_Bremser

Was muss ich tun um die Idee zu befürworten? Reicht es der Idee mit dem Button am linken Rabd einen Kudo zugeben?

Gruß aus Betzdorf

Hans

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

Kurt_Bremser — Mon, 31 Jul 2017 12:04:40 GMT

basefan schrieb:

@@KurtBremser

Was muss ich tun um die Idee zu befürworten? Reicht es der Idee mit dem Button am linken Rabd einen Kudo zugeben?

Ja, mehr kann man da nicht tun. Mein Vorschlag ist zwar schon einige Monate her, aber vielleicht hilft die plötzliche "Zustimmungsaktivität" dem Ganzen auf die Sprünge.

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

AndreasMenrath — Tue, 01 Aug 2017 16:02:16 GMT

Hallo Hans,

also der EG ist halt leider nicht als Tool für das Datenmanagement gedacht.

Wenn deine Zielgruppe wirklich nichts mit SAS Code anfangen kann, gibt es wohl nur noch die Möglichkeit selbst eine Erweiterung für den EG zu programmieren und den Anwendern zur Verfügung zu stellen.

Ein solches Addin hat dann eine eigene Oberfläche und Logik. Der Anwender muss dann nur noch die Oberfläche bedienen.

Der Aufwand für die Programmierung eines Addins ist jedoch nicht zu unterschätzen.

Viele Grüße

Andreas

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

mfab — Wed, 02 Aug 2017 12:21:07 GMT

Vielleicht wäre es auch eine Überlegung wert, den Code für die Nutzer vorzufertigen und für alle zugänglich in den Metadaten abzulegen - ggf. als Stored Process.

Dabei könnte man auch mit Prompts arbeiten (z.B. Anzahl Tage für "liste alle Tabellen älter als &anzahl_tage. Tage auf", etc.).

Alternativ kann auch ein ganzes eGuide-Projekt in den Metadaten hinterlegt werden - auch mit entsprechenden Prompts (Eingabeaufforderungen).

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

basefan — Thu, 03 Aug 2017 13:20:56 GMT

Hallo,

ich muss mich korrigieren. Die Anwender können sehr wohl mit SAS-Code umgehen, aber mit Macro-Programmierung würde man sie (wahrscheinlich) überfordern.

Auch die Variante eine Erweiterung für den EG zu programmieren schließt sich quasi automatisch aus (wegen dem genannten beträchtlichen Aufwand).

Der Vorschlag das Problem mit einem Stored Pocess oder einem eGuide-Projekt, beide ggf. mit Prompts ist bestimmt interessant, aber es erscheint mit mit Kanonen nach Spatzen geschossen, um eine fehlende Funktionalität nachzubilden, die im Vorgänger-Frontend enthalten war.

Aber die Problematik ist eine ganze andere: Der alte SAS Display Manager ist für diese Zielgruppe bei uns 'gesetzt'. Um sie von da weg zu lotsen darf das Ziel-System nicht (wesentlich) schlechter sein, als das abzulösende, also als der SAS Display Manager.

Ein Punkt ist der in diesem Thread angesprochene.

Der nächste Punkt, den ich erst in den letzten Tagen beobachtet habe (davor habe ich praktisch noch nicht mit dem EG gearbeitet) ist, dass der EG langsamer als der Display Manager ist (Display Manager natürlich mit remote submit). Ein kleines Test-Programm bestehend aus 6 data steps und 8 proc prints braucht mit dem Display Manager 26 Sekunden, während der EG 42 Sekunden benötigt. Die Daten leigen für beide auf dem gleichem (Linux-) Server.

Aber das gehört eigentlich nicht in diesen Thread. Zumal ich mit dem EG noch weiteres Problem habe: Bei einem einfachen proc print, der 3 Observations drucken soll kommt nach ewiger Wartezeit die Meldung 'The results are large (116.274.692 bytes) and could take a long time and a large amount of system resources to add to the project.'. Scheinbar hat der EG ein Problem mit den vielen Variablen. Es sind in diesem Beispiel 156. Der Display Manager hat damit überhaupt kein Problem und liefert die Antwort im Null-Komma-Nix.

Gruß aus Betzdorf

Hans

P.S.: Ist das communities.sas.com nur für mich so extrem langsam oder ist das ein allgemeines Problem. Jeder Wechsel von einer Seite zu einer anderen dauert mehrere Minuten!

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

Kurt_Bremser — Thu, 03 Aug 2017 13:30:49 GMT

Die meiste Verzögerung im EG entsteht immer beim Anzeigen von Ergebnissen. Die Durchführung der Codes ist gleich schnell.

Bei mir ist auch die communities extrem langsam, aber nur auf dem Firmen-Desktop. Auf dem Tablet via meinem Telefon ist alles normal. Möglicherweise ein Problem mit den Proxies.

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

mfab — Thu, 03 Aug 2017 14:50:09 GMT

Hallo Hans,

ich verstehe den Hintergrund. Es ist immer etwas schwierig neue Tools einzuführen, wenn gewohnte Abläufe dafür verändert werden müssen.

Da ich kaum mit dem Display Manager würde ich jetzt keinen Vergleich wagen.

Allerdings würde ich es mal so ausdrücken, dass man beim Display Manager eine direkte SAS-Session hat, während der eGuide zwar natürlich auch mit einer SAS-Session arbeitet, jedoch das ganze noch etwas netter verpackt und verschiedene Hilfsmittel bietet. Das fängt ja schon damit an, dass das Log entsprechend gestaltet wird. Man bekommt eine Log-Zusammenfassung und kann aus dieser direkt in die entsprechende Stelle springen. Man kann Abläufe grafisch zusammenklicken, Projekte erstellen, ganze Projekte durchsuchen, Ergebnisse nach Excel senden etc. Grundsätzlich also ein deutlich mächtigeres Tool als der DM, dafür braucht der EG vielleicht an der einen oder anderen Stelle auch manchmal ein paar Sekunden länger.

Was die Ergebnisse angeht, so kann man in den Optionen auch einstellen, dass z.B. direkt ein HTML oder PDF erzeugt wird, wenn man dies denn benötigt. Auch die Warnung bei großen Ergebnissen kann man dort anpassen, aber ich denke, das hat schon auch seine Berechtigung, dass da ein Hinweis kommt. Die Warnung sagt ja nichts anderes, als "Achtung, hier werden jetzt ein paar hundert MB übertragen und müssen anschließend auch angezeigt werden".

Im eGuide führe ich praktisch nie ein PROC PRINT aus, weil ich die Tabelle immer per Doppelklick öffnen kann. Oder das Ergebnis, z.B. eines Data-Steps wird direkt als Tabelle angezeigt. Diese Tabellenansicht war für mich schon immer praktischer und schneller als eine PROC PRINT Ausgabe zu betrachten, da man auch mit den Pfeiltasten navigieren kann.

Bei der Ansicht der Tabelle werden auch immer nur Teile der Tabelle an den eGuide übertragen wodurch nicht von vorneherein die gesamte Tabelle, bzw. das Ergebnis des PROC PRINT übertragen werden muss.

Ganz deutlich wird das z.B. auch bei einem PROC SQL; SELECT ... bei einer großen Tabelle hat man auch hier das Problem, dass das gesamte Ergebnis übertragen werden muss.

Wir führen hier bei uns daher ausschließlich PROC SQL; CREATE TABLE work.x AS SELECT ... aus. Somit wird eine Tabelle erzeugt, die wiederum nicht komplett an den eGuide (Client) übertragen werden muss. Schlau wäre an der Stelle wahrscheinlich auch das Erstellen einer View, aber da wir keine Performanceprobleme haben und meist mit der Tabelle weiterarbeiten nehmen wir oft das Create-Statement.

Ich denke, da sind einfach ein paar Anpassungen in der Arbeitsweise angebracht und ehrlich gesagt glaube ich, dass die Arbeit mit dem eGuide durchaus (mehr) Spaß macht und viele sinnvolle Features bietet 😉

Das mit dem direkten Anzeigen von Tabelleneigenschaften mag jetzt etwas sein, wo der EG wirklich nicht glänzt, bzw. was der DM besser macht... ich hoffe, Ihr findet aber noch viele Punkte, die Ihr braucht und die der EG wirklich gut macht.

Beste Grüße

Michael

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

basefan — Fri, 04 Aug 2017 06:56:30 GMT

Hallo zusammen,

@Kurt_Bremser

Das kann ich nicht bestätigen, Im Log ist die Zeit jeweils deutlich verschieden, die Zeit für die Anzeige kommt noch hinzu. In dem Mini-Beispiel ist die Laufzeit, bis ich die Ergebnisse sehe beim EG 133 Sekunden (!!!) statt 26 beim DM.

@mfab

Auch die Warnung bei großen Ergebnissen kann man dort anpassen, aber ich denke, das hat schon auch seine Berechtigung, dass da ein Hinweis kommt. Die Warnung sagt ja nichts anderes, als "Achtung, hier werden jetzt ein paar hundert MB übertragen und müssen anschließend auch angezeigt werden".

Es sind nur 3 Zeilen, wenn ich die nach Excel kopiere und als xlsx speichers sind es nur 16 KB. Ich glaube nicht, dass das einen Hinweis rechtfertigt. Die in der Meldung ausgebene Zahl abstruß hoch ist (116.772.682 bytes), aber für Excel sind es nur 16 KB. Was um alles in der Welt macht der EG mit den paar Byte Rohdaten?

Im eGuide führe ich praktisch nie ein PROC PRINT aus, weil ich die Tabelle immer per Doppelklick öffnen kann. Oder das Ergebnis, z.B. eines Data-Steps wird direkt als Tabelle angezeigt.

Ich wollte nur mal schnell ein paar Datensätze sehen, 3 aus 3 Millionen. Dazu erzeuge ich nicht erst einen Data Set, den ich dann mit Doppel-Klick öffne, das geht mit dem PROC PRINT schneller. Und wegen "nur mal schnell" auch ohne Einschränkung der VAR-Liste, sondern einfach "alles".

Ganz deutlich wird das z.B. auch bei einem PROC SQL; SELECT ... bei einer großen Tabelle hat man auch hier das Problem, dass das gesamte Ergebnis übertragen werden muss.

>>> Ups <<< das ist aber ein Ding, so ein dicker Lapsus sollte nicht sein!

Ansonsten:

Bitte nicht falsch verstehen. Ich hätte den EG bei uns schon lange als einzigen Client eingeführt. Ich frage mich jetzt aber, ob es gut gewesen wäre ...

Gruß aus Betzdorf

Hans

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

mfab — Fri, 04 Aug 2017 07:19:16 GMT

Hallo Hans,

also das kann ich nicht nachvollziehen.

Wenn ich mit PROC PRINT 3 Zeilen aus einer sehr großen Tabelle im EG anzeigen lasse, geht das sehr schnell und es wird nur eine sehr geringe Menge an Daten übertragen.

Mein Punkt ist, dass ich statt z.B.

proc print

data=in (obs=3);

run;

ein

data work.tmp;

set in (obs=3);

run;

schreibe.

Zugegeben, das mag nicht nötig sein, aber wie gesagt, ich arbeite meist mit den Daten weiter oder mache z.B. im EG ein "senden an Excel".

Bei mir (und das sollte meines Wissens Standard im EG sein) werden die Ergebnisse auch sofort geöffnet. Also muss ich nicht zuerst den DataStep ausführen und dann das Ergebnis öffnen. Ich führe nur den DataStep aus und bekomme das Ergebnis angezeigt. (Oder alternativ kann ich die Ausgangstabelle auch direkt per Doppelklick öffnen und ansehen oder dort z.B. mit einem "Where" arbeiten, um die Tabelle zu filtern.

Dass das SELECT (ohne CREATE) im PROC SQL das komplette Ergebnis übertragen muss ist einfach der Funktionsweise "geschuldet". Man kann im EG einstellen, welche Ergebnisse erzeugt werden sollen. Im Standard wird ein SAS Report erzeugt. Das lässt sich z.B. auch auf PDF umstellen. Das PROC SQL; SELECT... erzeugt also das im EG eingestellte Ergebnis und überträgt dies anschließend auf das System, wo der EG läuft, damit es angezeigt werden kann.

Das ist meines Erachtens ein ganz normales Vorgehen, wobei man freilich darüber diskutieren kann, wie groß das Ergebnis jeweils wird. Aus meiner Sicht wird das Ergebnis als SAS Report immer unverhältnismäßig groß im Vergleich zu den anderen Varianten. Dafür wird es eben direkt im EG angezeigt, wohingegen z.B. für PDF ein separates Tool benötigt wird.

Nochmal: ich denke, es ist einfach eine Frage der Vorgehensweise. Mir ist ein PROC PRINT viel zu unpraktisch, da ich im Ergebnis z.B. nicht mit den Pfeiltasten navigieren und auch keine Zellinhalte kopieren kann.

Wahrscheinlich gibt es auch Verfechter des PROC PRINT, sicherlich auch zurecht, je nach Einsatzzweck. Mein Punkt ist, dass jedes Tool eine gewisse Vorgehensweise begünstigt, das habe ich versucht darzustellen.

Vielleicht kommt Euch das SAS Studio eher entgegen?

Beste Grüße

Michael

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

basefan — Fri, 04 Aug 2017 10:07:35 GMT

Hallo Michael,

mein Beispiel war kein proc print data=test(obs=3); sondern er war mit einer where-Bedingung, aber das geht mit dem data step genauso.

Die Idee im EG statt dem proc print den data step zu nehmen, dessen Ergebnis sich normalerweise sofort+automatisch öffnet, ist gut. Als EG-Neuling hatte ich an daran gar nicht gedacht. Das Feature 'öffnet sich automatisch' war just seit ein paar tagen deaktiviert, weil ich zu diesem Problem ein Ticket bei der Hotline eröffnet hatte und der Kollege meinte, ich sollte das deaktivieren, ob das die Meldung verhindern würde. Hat es nicht, aber ich hatte es immer noch deaktiviert.

Dank Deinem Tipp weiß ich, wie ich es im EG anders als im DM mache.

Das Rätsel, warum der proc print diese unpassende Meldung bringt ist mittlerweile auch gelöst. Lt. SAS-Hotline reagiert der EG bei der where-Bedingung nicht wie man das erwartet (Eingrenzung der Daten ganz unten, ganz nah an der DB), sondern holt alle Daten 'zu sich' und wertet erst dann die where-Bedingung aus. Wenn er so ungeschickt arbeitet, ist die Meldung klar. Aber wer konnte wissen, dass der EG so extrem ungeschickt arbeitet?

Übrigens erzeugt der proc print data=test(obs=3); die gleiche Meldung, also ist auch hier die gleiche ungeschickte Arbeitsweise des EG.

Im SAS-Wiki steht zum Where-Statement genau das drin:

Die Selektion findet also *vor* dem Einlesen der Daten in den eigentlichen Datenschritt statt und ist besonders bei großen Tabellen sehr effizient.

(siehe http://saswiki.org/wiki/WHERE)

Was ist nur in die EG-Entwickler gefahren, dass sie so eine ungeschickte Art der Realisierung gewählt haben? Ich bin entsetzt!

Gruß aus Betzdorf

Hans

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

Kurt_Bremser — Fri, 04 Aug 2017 10:35:22 GMT

Wie sieht Eure Datenhaltung aus?

Ich habe das soeben getestet

(EG 7.1, SAS 9.4 TS1M2 auf AIX 7, native SAS-Tabelle, ca. 1,8 GB groß, > 7.000.000 Obs, 81 Spalten)

Code:

data person;
set xxx.tperson;
where name = 'Bremser';
run;

proc print data=xxx.tperson;
where name = 'Bremser';
run;

Log dazu

41         data person;
42         set xxx.tperson;
43         where name = 'Bremser';
44         run;

NOTE: There were 7 observations read from the data set XXX.TPERSON.
      WHERE name='Bremser';
NOTE: The data set WORK.PERSON has 7 observations and 81 variables.
NOTE: DATA statement used (Total process time):
      real time           5.57 seconds
      cpu time            3.21 seconds
      

45         
46         proc print data=xxx.tperson;
47         where name = 'Bremser';
48         run;

NOTE: There were 7 observations read from the data set XXX.TPERSON.
      WHERE name='Bremser';
NOTE: The PROCEDURE PRINT printed pages 1-5.
NOTE: PROZEDUR PRINT used (Total process time):
      real time           5.73 seconds
      cpu time            3.20 seconds

Der PROC PRINT dauert praktisch genauso lang wie der data step, und die Anzeige war auch sofort da.

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

basefan — Fri, 04 Aug 2017 11:13:36 GMT

Hallo Kurt,

bei uns ist es so:

EG 7.13 HF5 (7.100.3.5486) (64-bit) auf Win-7 PC, SAS 9.4 TS1M3 auf Suse Linux (64bit), native SAS-Tabelle, ca. 4,3 GB groß, > 3.000.000 Obs, 156 Spalten)

Code:

data test6; /* data set has 3 observations and 156 variables */
set dm3_g.a_kopo_G;
if auftnum eq '2100004711';
run;

proc print data=dm3_g.a_kopo_G; /* The results are large (116.274.692 bytes) and could take a long time and a large amount of system resources to add to the project. */
var %varsort( dm3_g.a_kopo_G ); /* 156 variables */
where auftnum eq '2100004711';
run;

Log dazu aus dem EG:

66         data test6;       /* data set has 3 observations and 156 variables */
67           set dm3_g.a_kopo_G;
68           if auftnum eq '2100004711';
69         run;

NOTE: There were 3072064 observations read from the data set DM3_G.A_KOPO_G.
NOTE: The data set WORK.TEST6 has 3 observations and 156 variables.
NOTE: Compressing data set WORK.TEST6 increased size by 100.00 percent.
      Compressed is 2 pages; un-compressed would require 1 pages.
NOTE: DATA statement used (Total process time):
      real time           1.15 seconds
      cpu time            1.16 seconds

70
71
72         proc print data=dm3_g.a_kopo_G;  /* The reults are large (116.274.692 bytes) and could take a long time and a large amount of system resources to add to the project. */
73           var %varsort( dm3_g.a_kopo_G ); /* 156 variables */
MPRINT(LEFT):   ABGRU_AP ANLDAT_A ANLDAT_V ANRSCHL ANSPRNUM ANZFPOS ARBEITSTAG ARCHI_AP ARTINUM ARTINUM8 ARTINUME ARTINUMH ARTINUMW ARTINUMZ ARTINUMZ8 AUDMA AUDMA_AK AUFTART AUFTDAT AUFTJJJJ AUFTNUM
AUFTPOS AUFTPOSH AUFTWOCH BELQUELL BEL_CD BILDPOS BRSCH BSARK BSTDK BSTNK_AK BSTZD BTR00 BTR01 BTR02 BTR03 BTR04 BTR05 BTR06 BTR07 BTR08 CTLPC_AK DUBLETTE EAN01 EAN02 EANANZ FEIERTAG FIL3NR FLIEF
HTN01 HTNANZ INTEXT INTEXTGR2 KAMGEBIE KDARCHI KLASSIFI KONDM KOTX01 KOTX02 KOTX03 KOTX04 KOTX05 KUNDNUM KUNDNUMO KUNDNWE LABOR LAGERJN LAND1 LPRIO MENGE MENGENAFRA MENGE_FPK MMDD_AK MMDD_AP NAFRA_AP
NBEJN NBEJN_O NETWR_AP NETWR_FPK NNWRW_AP PLZ PRLI_AK PRLI_AP PRLI_EP PRLI_EP_ZZ PRODH PRODH2 PRODH4 PRODH6 PRODH8 PRODHAPP PRODH_AP PRODH_AP2 PRODH_AP4 PRODH_AP6 PRODH_AP8 PRODUKT PSTYP RV_WP
SA_ODER_SO SCORNECJ SCORNECW SDABW SEITE SEX SGE SKENNUNG SORTIK SPARTE SPRAS SPRAS2 STKLIPOS STRJN STRJN_O TAGTYP THEMA TITSCHL VAGEBIET VA_NR VGBLPOS VKAUS_AP VKBUR VKGRP VKORG VRWRB_AP VRWRT_AP
VRWRT_FPK VSART_AK VSART_AP VSTEL_AP VTWEG WAERK WAERS WAGRU WAGRU2 WAGRU4 WEBID WERK_AP WE_JN WLDAT ZTERM ZZADH_AK ZZAUH_AK ZZBRS_AK ZZBRS_KD ZZGCI ZZKON_AK ZZKON_KD ZZKWD ZZMON ZZNEUKA ZZNEUKV
ZZSCO_AK ZZSTA ZZVTR_AK ZZWI8
74           where auftnum eq '2100004711';
75         run;

NOTE: There were 3 observations read from the data set DM3_G.A_KOPO_G.
      WHERE auftnum='2100004711';
NOTE: PROCEDURE PRINT used (Total process time):
      real time           2.80 seconds
      cpu time            2.81 seconds

Der Log aus dem DM:

370     data test6;                         /* data set has 3 observations and 156 variables */
371       set dm3_g.a_kopo_G;
372       if auftnum eq '2100004711';
373     run;

374
375
376     proc print data=dm3_g.a_kopo_G;     /* The results are large (116.274.692 bytes) and could take a long time and a large amount of system resources to add to the project. */
377       var %varsort( dm3_g.a_kopo_G );   /* 156 variables */
MPRINT(LEFT):   ABGRU_AP ANLDAT_A ANLDAT_V ANRSCHL ANSPRNUM ANZFPOS ARBEITSTAG ARCHI_AP ARTINUM ARTINUM8 ARTINUME ARTINUMH ARTINUMW ARTINUMZ ARTINUMZ8 AUDMA AUDMA_AK AUFTART AUFTDAT AUFTJJJJ AUFTNUM
AUFTPOS AUFTPOSH AUFTWOCH BELQUELL BEL_CD BILDPOS BRSCH BSARK BSTDK BSTNK_AK BSTZD BTR00 BTR01 BTR02 BTR03 BTR04 BTR05 BTR06 BTR07 BTR08 CTLPC_AK DUBLETTE EAN01 EAN02 EANANZ FEIERTAG FIL3NR FLIEF
HTN01 HTNANZ INTEXT INTEXTGR2 KAMGEBIE KDARCHI KLASSIFI KONDM KOTX01 KOTX02 KOTX03 KOTX04 KOTX05 KUNDNUM KUNDNUMO KUNDNWE LABOR LAGERJN LAND1 LPRIO MENGE MENGENAFRA MENGE_FPK MMDD_AK MMDD_AP NAFRA_AP
NBEJN NBEJN_O NETWR_AP NETWR_FPK NNWRW_AP PLZ PRLI_AK PRLI_AP PRLI_EP PRLI_EP_ZZ PRODH PRODH2 PRODH4 PRODH6 PRODH8 PRODHAPP PRODH_AP PRODH_AP2 PRODH_AP4 PRODH_AP6 PRODH_AP8 PRODUKT PSTYP RV_WP
SA_ODER_SO SCORNECJ SCORNECW SDABW SEITE SEX SGE SKENNUNG SORTIK SPARTE SPRAS SPRAS2 STKLIPOS STRJN STRJN_O TAGTYP THEMA TITSCHL VAGEBIET VA_NR VGBLPOS VKAUS_AP VKBUR VKGRP VKORG VRWRB_AP VRWRT_AP
VRWRT_FPK VSART_AK VSART_AP VSTEL_AP VTWEG WAERK WAERS WAGRU WAGRU2 WAGRU4 WEBID WERK_AP WE_JN WLDAT ZTERM ZZADH_AK ZZAUH_AK ZZBRS_AK ZZBRS_KD ZZGCI ZZKON_AK ZZKON_KD ZZKWD ZZMON ZZNEUKA ZZNEUKV
ZZSCO_AK ZZSTA ZZVTR_AK ZZWI8
378       where auftnum eq '2100004711';
379     run;

NOTE: There were 3 observations read from the data set DM3_G.A_KOPO_G.
      WHERE auftnum='2100004711';
NOTE: The PROCEDURE PRINT printed page 24.
NOTE: PROCEDURE PRINT used (Total process time):
      real time           1.96 seconds
      cpu time            1.95 seconds

Der Data Step ist beiden gleich langsam (langsam, weil if statt where verwendet wurde), aber der proc print ist im EG deutlich langsamer als im DM.

Mittlerweile ist aber klar, woran das liegt, siehe mein voriger Kommentar mit der Aussage von der Hotline.

Es liegt an der ineffektiven Realisierung im EG. Der Code im DM wurde von mir natürlich mit rsubmit gestartet, d.h. es werden keine unnötigen Daten unnötig weit durchs Firmen-Netz bewegt.

Gruß aus Betzdorf

Hans

P.S.: Die obigen Log-Auszüge mit den Laufzeiten sind von meinen Test von gestern. Eben habe ich den Proc Print erneut getestet. Jetzt hat er sogar "real time 17.45 seconds" benötigt! Zwei Tests mit zwei ähnlich schlechten Ergebnissen!

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

mfab — Fri, 04 Aug 2017 13:03:08 GMT

Hallo Hans,

das würde ich ggf. mit dem SAS Support durchgehen.

Aus der Erfahrung bei unseren Systemen kann ich sagen, dass hier durchaus die generelle Systemauslastung durch parallele Prozesse, SAN-Anbindung, etc. eine Rolle spielen können.

Hier kann es immer mal zu einem Bottleneck kommen und die Zeiten schnellen dann teilweise stark nach oben.

Ein guter Indikator ist die Differenz von "real time" zu "cpu time", um zu sehen, ob die Verarbeitung an sich einfach viel Rechenzeit benötigt (Differenz ist klein) oder ob z.B. viel auf I/O gewartet wird => real time deutlich höher als cpu time.

Mit der Option "fullstimer" lassen sich da auch noch weitere Faktoren betrachten.

Ich wünsche viel Erfolg und ich bin mal gespannt, was letztendlich das Ergebnis sein wird 🙂

Schönes Wochenende!

Michael

Betreff: SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

jakarman — Fri, 04 Aug 2017 17:01:40 GMT

Geht es um ganz schnell mit wenig system belastung information uber tabellen ansichtlich zu machen dan:
- schau mal an attrn/atrrc fucntionen. Die greifen am tabellen information selbst an.

http://support.sas.com/documentation/cdl/en/lefunctionsref/69762/HTML/default/viewer.htm#p12uchp7hm5h2zn1om2ut816af7h.htm

- Mit externe DBMS tabellen ist ein count(*) ohne etwas zu filteren sehr schnell weil es das dictionary.tables benutz

Accessing SAS tabellen und external dbms tabellen wirden schrecklich langsam.

http://support.sas.com/documentation/cdl/en/lrcon/69852/HTML/default/viewer.htm#p00cato8pe46ein1bjcimkkx6hzd.htm