ToDo Liste für die Installation von Oracle XE auf Ubuntu
1. Download Oracle XE von der Oracle Seite (z.B. oracle-xe-11.2.0-1.0.x86_64.rpm.zip)
# unzip oracle-xe-11.2.0-1.0.x86_64.rpm.zip
3. Folgende Pakete installieren:
# sudo apt-get install alien libaio1 unixodbc vim
4. Konvertieren RedHat Package (RPM) to Ubuntu Package
# sudo alien --scripts -d oracle-xe-11.2.0-1.0.x86_64.rpm
On our mobile phones we are used to have very convenient widgets to ease the handling of mobile applications. One of these widgets is a flipswitch which is perfect to show "two-state" values. For this kind of widget here is my new APEX plugin. This kind of widget will come "out of the box" with APEX 5.1 but if you will have it earlier, here it is!
Oracle Developers are often faced with the problem to handle LOB data between several oracle instances via a database link. With plain SQL it is not allowed to select, insert or update a LOB on the remote system. This ends up with a error like this: "ORA-22992 cannot use lob locators selected from remote tables". There are three solutions for this:
Customers often ask, how to make sure, that a particular PL/SQL-code which runs in several sessions at the same time, process the data for the FIFO paradigm. The answer is: no problem at all. Oracle offers the dbms_lock package which is very helpful there to solve problems arround locking and synchronizing.
From time to time I will be faced the problem to move data from one table to another. Under normal circumstances this is not a big deal, but if the source table contains a long-/raw column this is impossible to manage that with plain SQL. So here is a suitable workaround to solve this problem with a few lines of PL/SQL code
Starting point is a table with a long raw column:
insert into long_table select 'new id', long_column /* LONG-Feld */ from long_table a where a.long_id = 'some old id';
This ends up with "ORA-00997: illegal use of LONG datatype error"
The workaround is:
This article describes how to tokenize a string, just with plain "out of the box" Oracle SQL. In the IT we often encounter requirements to split a string in parts. With Oracle PL/SQL we have a quite elegant solution for that.
The solution is based on the ability of oracle to use regular expressions within a SQL statement. In the first example we have comma seperated string, containing the most important crew members of the USS Enterprise:
SELECT regexp_substr(str, '[^,]+', 1, LEVEL) AS splitted_element, LEVEL AS element_no FROM (SELECT rownum AS id, 'Kirk,Spock,Scotty,McCoy,Uhura' str FROM dual) CONNECT BY instr(str, ',', 1, LEVEL - 1) > 0 AND id = PRIOR id AND PRIOR dbms_random.value IS NOT null;
... exactly this was the question of a customer, because he wants to join tables between two Oracle databases. Well, the idea for this solution is based upon the fact, that we can have a foreign key constraint on a view. So let's go ahead:
1. We create a view which points to a table/view on the foreign database, using a database link:
create view test_view_dblink as select * from some_table@external_oracle_database;
2. We create a foreign key constraint on that view
alter view test_view_dblink add constraint test_view_dblink_fk foreign key (column_name) references table_in_local_database(column_name) disable;
The "disable" clause at the end of the statement is the important thing because constraints on views must be disabled.
2b. If we would need a primary key we also can define one:
alter view test_view_dblink add constraint test_view_dblink_pk primary key (column_name) disable;
Last but not least: with this technique, we can create relations to all databases for which we have a oracle connector/gateway (e.g. IBM DB2, ...). Check it out!
This article is about how Java programs can be developed directly in the Oracle database and in particular, it shows an example how to access the file system of the operating system. Since the Oracle version 8, it is possible to write Java code direct within the database. So it would be possible, to write stored procedures with Java instead of using PL/SQL. Nevertheless, the advantages of PL/SQL are the safe and stable processing of mass data, so there is no need to change to Java in this part. But if we have issues who are located outside of the database, we will reach the limits of PL/SQL very quickly. This is the point where Java starts, because the language itself is independent of the operating system and therefore it is predestined for tasks like this. In addition, we can rely on a vast range of finished Java solutions, who can than operate within the Oracle database. Maybe there are a few slightly modifications needed but in general it is not a big deal.
However, a weak point of this is the actuality of Java! The version within the database is "lagging" behind the current versions. This is because that a stable Java version is the base of the development of a new database release. While this new release than is productive for years, there are no changes in the internal version of Java, whereas the Java world outside of the Oracle database has already seen significant developments. The result is, that a Oracle version 11.2, which is very common right now (the first release dates from 2007), has the Java Runtime version 1.5.0_10 (2005!) included.
The entire source code of the directory list example you will find here!
Stored Procedures with Java?
The most common language within the Oracle database is still PL/SQL. This is the prefered language to develop Stored Procedures, Packages or Triggers. In order to develop with Java, the Java sources must be uploaded into the database. From this, the classes are extracted and displayed in the Data Dictionary as a schema object. It allows Java sources (.java) and class files (.class) or archives (.jar, .zip) to be uploaded.