29. März 2012

APEX Entwicklertag: Ende April in München, Düsseldorf und Berlin

Sehen wir uns dort ...?

In 2004 wurde Application Express (APEX) zusammen mit Oracle10g herausgebracht. Acht Jahre später kann sich die Zwischenbilanz sehen lassen: Allein in der deutschsprachigen Community sind 1200 Leser registriert - in Unternehmen mit Oracle-Infrastruktur entstehen neue APEX-Anwendungen teilweise täglich. Und APEX-Entwickler machen weit mehr als Masken zur Datenerfassung: Sie beschäftigen sich mit Themen wie APEX-Anwendungen fürmobile Endgeräte , Entwicklung moderner "Web 2.0"-Oberflächen, Cloud Computing und mehr.
Wichtig ist aber immer das persönliche Kennenlernen, der Austausch und die Diskussion. Aus diesem Grund trifft sich die deutschsprachige APEX Community im April 2012 in München, Düsseldorf und Berlin. Auf diesem Entwicklertag erhalten Sie einen Einblick in aktuelle Entwicklerthemen rund um Application Express: Wir informieren über den aktuellen Stand in APEX 4.1 und werden speziell das Thema "mobile APEX-Anwendungen" beleuchten. Unser Partnern Muniqsoft informiert über Layoutvarianten in APEX-Anwendungen - mit Tipps & Tricks direkt aus der Praxis. Die MT AG schließlich wird Implementierungsvarianten für gängige Aufgabenstellungen vorstellen - wiederum mit ganz konkretem Bezug zu praktischen Projekten.
Lassen Sie sich diese Möglichkeit zum direkten Erfahrungsaustausch nicht entgehen. Genaue Zeiten, Orte, die detaillierte Agenda und Anmeldeinformationen finden Sie auf der Veranstaltungs-Webseite. Die Teilnahme an der Veranstaltung ist kostenlos. Melden Sie sich noch heute an.

This blog posting is about a german-language event in Munich, Dusseldorf and Berlin and therefore in german only.

12. März 2012

Filetransfer mit FTP oder SCP? Nein, mit der Oracle-Datenbank!

Transfer files with FTP or SCP? - No! Use the Oracle DB!
Wusstet Ihr schon, dass Ihr Dateien von eine, Oracle-Datenbankserver auf einen anderen ohne Betriebssystem-Login übertragen könnt ...? Ihr braucht weder SCP, nocht FTP oder andere Dateitransferprogramme - nur die Oracle-Datenbank auf beiden Maschinen. Und solche Situationen sind ja durchaus normal ...
  • Man macht einen Data Pump-Export auf der Quelldatenbank. Die Dump-Datei liegt nun im Dateisystem des Datenbankservers.
  • Diese Datei muss auf den anderen Datenbankserver übertragen werden. Normalerweise nutzt man hierfür dann FTP. SCP oder ähnliche Werkzeuge
  • Auf dem Zielsystem wird der Dump dann per Import wieder eingespielt.
Wenn man nun keinen Betriebssystem-Login hat (oder der System-Admin gerade nicht da ist), geht es in der Tat auch ohne: Mit dem PL/SQL Paket DBMS_FILE_TRANSFER. Ihr braucht dazu:
  • Ein Directory-Objekt auf dem Quellsystem - die zu kopierende Datei sollte in diesem Verzeichnis sein:
    create directory srcdir as '/path/to/src/folder/';
    
    grant read on directory srcdir to send_user;
    
  • Ein Directory-Objekt auf dem Zielsystem:
    create directory dstdir as '/path/to/dest/folder/';
    
    grant write on directory destdir to receive_user;
    
  • Einen Database Link vom Quellsystem zum Zielsystem:
    create database link dblink_dest_system connect to receive_user identified by {password}
    using 'destDatabase'
    
    Übrigens muss die Ziel-Datenbank nicht zwingend in der tnsnames.ora hinterlegt sein. Im Notfall tut es auch ein Easy-Connect wie folgt: using 'destDatabase:1521/service.domain.com'
Ist das alles getan, so kann der Dateitransfer angestoßen werden: Data Pump Exports sind sicherlich sehr naheliegend - DBMS_FILE_TRANSFER überträgt aber auch andere Dateitypen (deren Dateigröße muss aber ein Vielfaches von 512 sein).
begin
  dbms_file_transfer.put_file(
    source_directory_object      => 'SRCDIR',
    source_file_name             => 'file-to-transfer',
    destination_directory_object => 'DSTDIR',
    destination_file_name        => 'new-filename-on-dest-system',
    destination_database         => 'dblink_dest_system'
  );
end;
Und Voilá. Ein Blick in das Verzeichnis auf dem Zielsystem sollte zeigen, dass die Datei angekommen ist. Besonders interessant ist das übrigens beim Einsatz der ASM-Technologie - denn wenn Dateien aus dem ASM gelesen oder in dieses geschrieben werden sollen, geht das nicht ohne weiteres mit Betriebssystem-Mitteln. Der Weg über DBMS_FILE_TRANSFER ist in solchen Fällen sogar der einfachere ...
Mehr Information zu DBMS_FILE_TRANSFER findet Ihr in der Dokumentation oder in einem Tipp von den Kollegen der DBA Community.
Did you know that you can transfer normal operating system files from one database server to another ... wothout logging into the operating system? You need neither SCP, nor FTP or any other file transfer program - just the Oracle database on both systems - and this is a quite common situation ...
  • One does a datapump export on the source database. The resulting dumpfile is now within a directory on the database server's filesystem.
  • This file needs to be moved to the target system. Most often operating system methods are employed for this task.
  • On the target system the dumpfile is being imported into the database.
So far - so good. But when logging into the operating system is not possible (either we don't have an account and the Sysadmin is not here or our account is locked or ... or ...) we can't transfer the file. But we don't need to - we just need DBMS_FILE_TRANSFER and a bit of preparation ...
  • Create a directory object on the source database - the file to be transferred should reside in that directory:
    create directory srcdir as '/path/to/src/folder/';
    
    grant read on directory srcdir to send_user;
    
  • Then create a directory object on the target database. The file will be placed into that folder:
    create directory dstdir as '/path/to/dest/folder/';
    
    grant write on directory destdir to receive_user;
    
  • And finally we need a database link from the source to the target system:
    create database link dblink_dest_system connect to receive_user identified by {password}
    using 'destDatabase'
    
    BTW: The target database does not need to be contained in tnsnames.ora. Easy Connect Syntax is also possible as follows: using 'destDatabase:1521/service.domain.com'. We just don't need to log into the operating system.
When all preparations are done the file transfer operation can be started - and it is so simple. Datapump Dumpfiles are a quite common scenario - but DBMS_FILE_TRANSFER works with all kind of files (but keep in mind that the filesize must be a multiple of 512).
begin
  dbms_file_transfer.put_file(
    source_directory_object      => 'SRCDIR',
    source_file_name             => 'file-to-transfer',
    destination_directory_object => 'DSTDIR',
    destination_file_name        => 'new-filename-on-dest-system',
    destination_database         => 'dblink_dest_system'
  );
end;
There is also the procedure GET_FILE - which does the operation vice-versa.
Done. Looking into the directory on the target system should show that the file is now present. This technique is particular interesting when it's about reading from or writing to Oracle's ASM - if the source or target database uses ASM (which cannot be easily accessed with normal operating system commands) this approach is the most simple one.
More information about DBMS_FILE_TRANSFER is contained in the documentation.

5. März 2012

APEX und PL/SQL Entwicklerstammtisch in München

Die APEX und PL/SQL Entwicklercommunity trifft sich zum lockeren "APEX Stammtisch" am 13.03.2012 um 19:30 Uhr in München. Einfach nur ein leckeres Bier, gutes Essen, interessante Gespräche rund um APEX und interessante Leute. Ein Tisch ist im "Augustiner Restaurant" in München reserviert.

Neuhauserstr. 27
80331 München

http://augustiner-restaurant.com/

Bitte meldet euch hier kurz an, damit wir wissen, wie viele kommen und ob und wann wir einen größeren Tisch reservieren müssen.
https://apex.oracle.com/pls/apex/f?p=18226:1:::::P1_EVENT_ID:361

This posting is about the "APEX Stammtisch" event in Munich and therefore in German only.

Beliebte Postings