31. Januar 2011

Neue Version des Betriebssystem-Packages: 1.0.0RC1

New version of operating system package: 1.0.0RC1
Heute habe ich eine neue Version meines Betriebssystem-Packages für PL/SQL veröffentlicht. Und langsam wird es ja auch mal Zeit, die "Nuller"-Versionen hinter sich zu lassen. Für diejenigen, die es noch nicht kennen: In diesem Paket habe ich Funktionen zusammengestellt, die den Zugriff auf das Dateisystem und die Shell vereinfachen. Zwar kann man mit UTL_FILE problemlos Dateien schreiben und lesen, FILE_PKG kann darüber hinaus jedoch Verzeichnisse auslesen - und zwar mit einem SELECT; wie bei einer Tabelle. OS_COMMAND erlaubt das Ausführen von Betriebssystem-Kommandos - und zwar mit vollem Zugriff auf stdin, stdout, stderr und auf den Return Code. Einfach mal ausprobieren ...
Today I released a new version of my operanting system package for PL/SQL. It now time to say goodbye to the "zero" version numbers and introduce version 1. I'll start with a "release candidate". For those not familiar with the package: It allows easy access to the filesystem, to files or to the operating system shell. Reading from or writing to files is possible with UTL_FILE but FILE_PKG allows to get directory listings with a SQL query - the directory is being exposed like a database table! OS_COMMAND allows executing shell commands - with full access to stdin, stdout, stderr and the Return Code. Just give it a try ...
Und das ist im Release 1.0 RC1:
And that is new to Release 1.0 RC1:
  • Die Prozedur FILE_PKG.SET_FS_ENCODING erlaubt es, für Dateinamen mit einem anderen als dem Datenbankzeichensatz zu arbeiten. Das ist hilfreich bei Dateinamen mit Umlauten.
  • Die EXEC-Prozeduren im Package OS_COMMAND können die Ausgaben von "stdout" und "stderr" nun getrennt voneinander verarbeiten.
  • The new procedure FILE_PKG.SET_FS_ENCODING allows to work with different encodings for file names. If filenames contain special characters (umlauts) this is useful.
  • The EXEC procedures in OS_COMMAND are now able to handle "stdout" and "stderr" separately.
Und schließlich habe ich intern ein wenig optimiert. Es ist manchmal immer wieder beeindruckend, was das Erzeugen von Java-Objekten kostet. Im konkreten Fall habe ich den Code so umgestellt, dass einige interne Objekte nicht mehr jedesmal neu, sondern nur einmal erstellt und danach wiederverwendet werden. Das Ergebnis kann sich sehen lassen. Hier ist ein Directory-Listing mit der vorherigen Version 0.9.2.
And last but not least I did some internal optimizations. I saw that I recreated some internal java object for each call - and decided to create them only once and to reuse them afterwards. When I tested the effect I was stunned ... here is a directory listing with the previous version 0.9.2.
SQL> select count(*), sum(file_size) from table(file_pkg.get_file_list(file_pkg.get_file('/usr/bin')))

  COUNT(*) SUM(FILE_SIZE)
---------- --------------
      1287       76976156

1 Zeile wurde ausgewählt.

Abgelaufen: 00:00:07.62
Und hier die neue Version 1.0.0RC1 (gleiche Maschine, gleiche Datenbank, nur anderes Schema):
And this is the listing with new version 1.0.0RC1 (same machine, same database, just other schema):
SQL> select count(*), sum(file_size) from table(file_pkg.get_file_list(file_pkg.get_file('/usr/bin')))

  COUNT(*) SUM(FILE_SIZE)
---------- --------------
      1287       76976156

1 Zeile wurde ausgewählt.

Abgelaufen: 00:00:00.35
Es lohnt sich also auf jeden Fall, die neue Version auszuprobieren. Über Feedback freue ich mich (wie immer).
Just try it out - if you have feedback for the package, let me know ...

Kommentare:

Anonym hat gesagt…

Hallo Herr Czarski,

das Package ist klasse. Vielen Dank! Nur ein Problem habe ich noch: Ich möchte SQL*Plus Skripte starten. Wenn diese aber einen nicht abgeschlossenen PL/SQL-Block oder kein EXIT enthalten, bleibt der os_command hängen und der Prozeß lässt sich nur noch auf Betriebssystemebene killen. Gibt es die Möglichkeit, eine Kontrolle über den aufgerufenen Prozeß zu bekommen (z.B. über eine Prozeß-ID?)
Grüße,
J. Kropp

Carsten Czarski hat gesagt…

Hallo Herr Kropp,

das funktioniert mit dem Package -Stand heute- noch nicht. Prinzipiell bietet das zugrundeliegende "Java in der Datenbank" eine solche Möglichkeit an (Process.destroy); ich muss mir aber überlegen, wie ich das integriere, da das Package - Stand heute - keine eigene Nebenläufigkeit vorsieht ...

Beste Grüße

-Carsten Czarski

Anonym hat gesagt…

Hallo Herr Czarski,

ich setze Ihr Package (Version 1.0) erfolgreich ein, um aus der Datenbank heraus auf einem Linux-Fileserver (via mount an den Linux-Datenbankserver angebunden) Verzeichnisse und Dateien anzulegen. Die Nutzer der Dateien und Verzeichnisse greifen über Windows/Samba auf die Dateien zu. Nun ist das Problem, dass in die erzeugten Verzeichnisse über Windows keinen Datei hineinkopiert oder daraus gelöscht werden können. Der Systemadministrator sagt, dass es daran liegt, dass bei den Verzeichnissen unter Linux für others die Berechtigungen nicht richtig gesetzt werden.
Ich setze in der Datenbank die Rechte für das aktuelle Schema (mit Hilfe von file_security.grant_permission), dabei kann ich ja gar nicht zwischen Dateien und Verzeichnissen bzw. zwischen others/usergroups/users unter Linux unterscheiden.

Haben Sie eine Idee, was ich machen kann, damit die Berechtigungen für others gesetzt werden können?

Vielen Dank für Ihre Bemühungen.

mfG
K. Budde

Carsten Czarski hat gesagt…

Hallo,

in der Tat - das Paket FILE_SECURITY ist nicht geeignet, um die Unix-Berechtigungen zu setzen. Der einfachste Weg dürfte sein, nach dem Erzeugen des Files oder des Folders, mit dem Paket OS_COMMAND das Linux Utility chmod aufzurufen und die Rechte so anzupassen.

OS_COMMAND.EXEC('chmod o+rwx {path}');

Hilft das weiter ...?

Beste Grüße

Carsten Czarski

Beliebte Postings