SAS Daten nicht sperren beim Lesezugriff

[Ilja]

Hallo zusammen,

wir haben im Unternehmen immer wieder das gleiche leidige Thema:

Im zentralen Data Warehouse werden verschiedene SAS Tabellen angeboten, auf die mehrere Dutzend Anwender lesend zugreifen - soweit kein Problem.
Sobald die Tabellen aber aktualisiert werden, muss aber sichergestellt werden, dass niemand die entsprechende Tabelle derzeit im Zugriff hat - ansonsten bricht der Schreibvorgang ab ("A lock is not available..."), mit unterschiedlich schwerwiegenden Folgen.

Bislang hat das einigermaßen funktioniert, indem die Tabellen nur nachts im Batch-Betrieb geändert wurden. Durch neue Anforderungen wird es aber immer häufiger notwendig, auch tagsüber Änderungen durchzuführen. Hier bleibt uns bislang nur der Weg des try&error: Anwender per Mail über die anstehende Änderung informieren, hoffen, dass alle zur verabredeten Zeit aus den Daten raus sind, und dann den Updatevorgang starten. Wenns nicht klappt - nochmal von vorne.

Hat jemand eine Idee, wie man diesen unhaltbaren Zustand verbessern könnte?

Folgende Optionen könnte ich mir vorstellen:

- Beim reinen Lesezugriff wird der Datensatz nicht gesperrt und eine Aktualisierung ist möglich, auch wenn sich noch Anwender auf den Daten befinden.

Ich dachte an sowas wie die Libname-Option access=readonly, diese führte aber bisher nicht zum gewünschten Ergebnis.

- Der Schreibjob bekommt Rechte, alle Anwender von der entsprechenden Tabelle runterzuwerfen, bevor der Schreibvorgang beginnt.

Leider kenne ich zu keiner der Optionen eine konkrete Umsetzungsidee.

Die Anwender greifen bei uns i.d. Regel über den SAS Enterprise Guide 5.1 auf die Daten zu. Wir verwenden SAS 9.3 (sofern relevant).

LG Ilja

[Kurt_Bremser]

Unter UNIX kann man einen Eintrag aus dem Directory auch löschen, wenn auf die dahinterliegende Inode zugegriffen wird.

Hat man Schreibrechte auf das Directory, funktioniert ein rm -f File immer.

Ich habe das daher (für AIX) so gelöst, dass ich einen Makro gebaut habe, der den physikalischen Dateinamen aus Library und Dataset-Name ermittelt und dann ein x "rm -f &datasetfile"; ausführt.

Wenn das hilfreich wäre, kann ich das als Codebeispiel posten.

[Ilja]

Schonmal danke für den Hinweis.

Nur für mich zum Verständnis: Was genau tut dieser RM Befehl? Wird da physisch die gesamte SAS Tabelle gelöscht?

Ich fürchte, das wäre für uns nicht praktikabel, weil:

- die Tabellen meist nicht komplett neu aufgebaut sondern nur geändert werden (tlw. auch nur ein append)

- ich bei so einem Eingriff große Auswirkungen auf die Metadatenverwaltung befürchte

- x-Befehle grundsätzlich gesperrt sind (gut, darüber ließe sich vielleicht reden)

- und wir zu guter Letzt auf einem Windows Server arbeiten.

[Kurt_Bremser]

rm ist das UNIX-Äquivalent zu DEL in der DOS/Windows Welt. rm -f bedeutet "force", was zB Hinweise auf das offene Filehandle bzw. mangelnde Schreibrechte auf das File selbst verhindert.

Da SAS selbst bei einem

data test;
set test;
run;

eine neues File erzeugt und das alte löscht, lässt sich ableiten, dass die Metadaten dadurch nicht aus dem Tritt kommen, solange die Struktur gleich bleibt. (wir machen das auch regelmäßig mit Datasets, die als Input für PROC OLAP verwendet werden und daher in den Metadaten registriert sind).

Man muss aber, wie Du richtig beobachtet hast, dann Dinge wie APPEND oder UPDATE umgehen. zB durch Abwicklung im WORK.

Über die Sinnhaftigkeit des NOXCMD bei Servern, die ihren Prozess mit der individuellen UserID starten, lasse ich mich hier nicht näher aus, sonst wirds unschön.

Ob der Trick mit dem "File unter Hintern wegziehen" unter Windows Server geht, weiss ich nicht. Ich verwende fürs DWH ein richtiges Betriebssystem, Spielzeug gehört mM auf die XBox.

Wenn alles andere nicht geht, dann kann man nur mit entsprechenden Utilities die Prozesse suchen, die ein File blockieren, und aus dem System killen. Das ist aber ein Dampfhammer, den ich umgehe. Die einzige Auswirkung, die meine Methode hat, ist die, dass ein User eine veraltete Version sieht, weil er noch die alte Inode und damit den alten Dateiinhalt offen hat. Man muss dann, um zu aktualisieren, einmal schließen und neu öffnen. Wobei das UNIX dann im Hintergrund endgültig die verwaisten Daten entfernt.

[Ilja]

Danke schön für den Ratschlag.

Von der Wirkung her klingt das schon so, wie ich mir das auch vorgestellt habe. Dass User kurzfristig eine veraltete Version des Datensatzes sehen, halte ich für unkritisch.

Ich werde den Vorschlag mal bei unserem IT-Administrator platzieren, vielleicht sind die technischen und administrativen Hürden doch nicht so hoch, wie ich vermute...

Aber davon abgesehen - gibt es keine interne SAS-Komponente, die das erlaubt? Ich habe an mehreren Stellen gelesen, dass mit SAS/SHARE paralleler Zugriff gewährleistet wird. Weisst Du (oder sonst jemand) wie das konkret funkioniert?

[Kurt_Bremser]

Für SAS/SHARE braucht man die Lizenzen für SAS/SHARE auf dem Server und SAS/CONNECT (wegen der Remote Library Services) auf dem Client. SAS/SHARE braucht man auch, um auf SAS Datasets am Server mit dem ODBC Driver zugreifen zu können.

Man müsste also SAS/SHARE lizenzieren und installieren, einen SHARE Server konfigurieren und starten, dann am Server zumindest eine Library mit Zugriff auf den SHARE-Serverprozess definieren und die dann im EG verwenden. Wobei dann aber nur gewisse Update-Prozesse möglich sind, ein komplett-Replace eines Datasets während gleichzeitigem Lesezugriff geht da auch nicht.

[mfab]

Hallo Ilja,

inwiefern funktioniert die Libname-Option access=readonly nicht? Werden die Tabellen trotzdem gesperrt?

Als "SAS-Komponente" wüsste ich ansonsten noch das Mittel mit Information Maps zu arbeiten. Meines Wissens klappt hier der Zugriff durch verschiedene Nutzer (Anwender) und das gleichzeitige Austauschen oder Anpassen der Datenbasis.

Das würde vermutlich aber großflächigere Umstellungen für die Verwendung der Daten durch die Anwender bedeuten.

Viele Grüße

Michael

[Ilja]

Hallo Michael,

Ganz genau, die Tabellen werden bei access=readonly trotzdem gesperrt.

Information Maps haben wir auch im Einsatz, allerdings nur im Zusammenhang mit den OLAP Cubes. Ich denke auch, auf der untersten Data Warehouse Ebene wäre das im Moment nicht praktikabel.

Viele Grüße

Ilja

[jakarman]

Ein variant an die "rm" angriff ist Benutzung des Logical link  https://en.wikipedia.org/wiki/Symbolic_link das Windows ähnliche ist "mklink" Die Benutzer sollen nur die LL benutzen, Das DWH aber har verschiedene Versionen vom die Dateien. Wenn die fertig sind Wechsel die link nach die neuen Name.

Ein ganz andere Lösung ist die speziellen SAS Eigenschaften benutzen und nicht in vorgeschriebene dwh Lösung verfahren bleiben. Was ich andeute ist wenn das dwh Dateien zusammen stellt dass Mann wie ein Union oder Join sehen kann mit neuesten Dateien dann mach daraus ein SQL View oder datastep view mit etwas sas-macro dazu um die Tabellen dafür an zu greifen. Wenn neuen Dateien gibt sollen die am Benutzer gegeben würden die die neuen Dateien wünschen.  Alle Files die nicht mehr gültig sind,  dürfen später erlöst werden. Das ist wenn alle Benutzer davon löse sind (keine locks).

[basefan]

Hallo Ilja,

wir haben ein ähnliches Problem auch gehabt und etwas anders gelöst als von Kurt skizziert.

Die neuen Daten werden in einer neuen Tabelle aufgebaut, der Libref dazu ist quasi geheim, also gibt es keine Lock-Probleme. Wenn die neue Tabelle fertigt ist, wird per 'lock'-Statement geprüft, ob die alte Tabelle 'frei' ist (fall nein, dann warten und erneut prüfen, etc pp) und wenn frei wird erst die alte Tabelle mit SAS-Mitteln gelöscht und dann die neue Tabelle per Unix-move-Kommando ('mv') zur alten Tabelle gemacht. Da die neue Tabelle im gleichen Filesystem wie die alte liegt, geht das Ganze extrem fix, was bei einem Copy ('cp') nicht der Fall wäre.

Apropos: 'Ich verwende fürs DWH ein richtiges Betriebssystem (..)' gilt auch bei uns/mir ...!

Zum 'lock'-Statement siehe z.B. Sample 51275: Locking a data set and verifying that a lock is held. Mit 'lock &dataset. CLEAR;' kann man den Lock auch wieder gezielt aufheben.

Im Vorgänger-Forum Redscope gab es das Tihema unter dem Titel 'Vor Schreiben/Update einer Tabelle diese auf "Lock untersuchen"' auch schon. Der Beitrag sollte im 'CoDe SAS'-Archiv zu finden sein. (wo ist das eigentlich ?? im alten 'CoDe SAS' war es auf der 'CoDe SAS'-Startseite).

In 'SAS Macros by Richard A. DeVenezia' hatte ich auch schon mal etwas zum gleichen Thema gefunden, entweder am 06.09.2006 gefunden oder die Fundstelle war vom 06.09.2006.

Gruß Hans

[jakarman]

Hans,
Das unterschied mit das wechslen mit eine logical link nach neuen name is das kien freigabe dem locks benötigt ist.
Sie mussen dass wiederholt controlieren bis alle benutszer das frei gegeven haben, Ich nicht.
Mit enen richtigen betriebssystem ist mit  locks und enqueues nur MVS jezt z/OS die richtige. Es ist dien einzige wo das ACID mit files am OS level consistent is. Nur mit excp methods (DBMS systeme) kan mann das verfehlen. Unix/Linux war spielzeug un bekommt letzte jahre besser met Selinux (confinement) und Cgroups (WLM). Mit Windows is AD viel besser wie mann in Unix/Linux für möglich halt.
Eine shared filed system und clustered servers mit LDAP un MDAC ist an herausforderung mit -nix systeme. (auth_sys limit 16).
Wegen alle probleme ist das Moglich die grund sas SAS a "locked down option" baut womit die OS security durch die SAS admin programmiert soll werden. (kein witz)
        

[Patrick]

Ich nehme mal an dieses SAS Data Warehouse ist ueber die Jahre organisch gewachsen und hat immer mehr Daten integriert und ist immer mehr Anforderungen gerecht geworden.

Irgendwann kommt die Zeit for ein Neudesign. SAS ist keine Datenbank und fuer Schreibzugriff auf Tabellen waehrend Geschaeftsstunden ist keine saubere Loesung vorhanden.

Meine Empfehlung: Migriere das SAS Data Warehouse in eine Datenbank (zB. Oracle). Alles andere sind "Umgehungsloesungen" und nichts wird wirklich befriedigend sein.